ES2309903T3 - Metodo y sistema de envolturas multicapas para metadatos de contenidos de empuje. - Google Patents
Metodo y sistema de envolturas multicapas para metadatos de contenidos de empuje. Download PDFInfo
- Publication number
- ES2309903T3 ES2309903T3 ES06113364T ES06113364T ES2309903T3 ES 2309903 T3 ES2309903 T3 ES 2309903T3 ES 06113364 T ES06113364 T ES 06113364T ES 06113364 T ES06113364 T ES 06113364T ES 2309903 T3 ES2309903 T3 ES 2309903T3
- Authority
- ES
- Spain
- Prior art keywords
- metadata
- content
- push
- client
- application
- 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
- 238000000034 method Methods 0.000 title claims abstract description 247
- 238000012545 processing Methods 0.000 claims abstract description 23
- 238000012384 transportation and delivery Methods 0.000 claims abstract description 14
- 230000008569 process Effects 0.000 claims description 180
- 238000009826 distribution Methods 0.000 claims description 42
- 239000000284 extract Substances 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 6
- 230000000644 propagated effect Effects 0.000 claims description 2
- 230000001902 propagating effect Effects 0.000 claims 1
- 230000006854 communication Effects 0.000 description 38
- 238000004891 communication Methods 0.000 description 38
- 238000003860 storage Methods 0.000 description 33
- 238000011084 recovery Methods 0.000 description 24
- 238000010586 diagram Methods 0.000 description 21
- 230000003068 static effect Effects 0.000 description 17
- 239000003795 chemical substances by application Substances 0.000 description 15
- 238000007726 management method Methods 0.000 description 14
- 238000013467 fragmentation Methods 0.000 description 13
- 238000006062 fragmentation reaction Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 13
- 230000009466 transformation Effects 0.000 description 10
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000003111 delayed effect Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 4
- 230000002349 favourable effect Effects 0.000 description 4
- 239000012634 fragment Substances 0.000 description 4
- 238000006467 substitution reaction Methods 0.000 description 4
- 230000006978 adaptation Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000003321 amplification Effects 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 238000003199 nucleic acid amplification method Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000011218 segmentation Effects 0.000 description 2
- 230000003442 weekly effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000007175 bidirectional communication Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000009414 blockwork Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000005236 sound signal Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 230000036962 time dependent Effects 0.000 description 1
- 238000000844 transformation Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
- G06Q50/10—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/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- 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/564—Enhancement of application control based on intercepted application data
-
- 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/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/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)
- Computer Networks & Wireless Communication (AREA)
- Library & Information Science (AREA)
- Multimedia (AREA)
- Business, Economics & Management (AREA)
- Tourism & Hospitality (AREA)
- Primary Health Care (AREA)
- General Physics & Mathematics (AREA)
- General Health & Medical Sciences (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Health & Medical Sciences (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Theoretical Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Supplying Of Containers To The Packaging Station (AREA)
Abstract
Un método para añadir inteligencia de proceso a la carga útil de contenidos en una arquitectura de distribución dinámica de contenidos, que tiene al menos un primer elemento de proceso y un segundo elemento de proceso, comprendiendo el método los pasos de: crear una primera envoltura (620; 614), comprendiendo dicha primera envoltura la carga útil (632) de los contenidos y metadatos (630; 622) del segundo elemento de proceso, estando adaptados dichos metadatos del segundo elemento de proceso para ejecutarse en dicho segundo elemento de proceso; y formar una segunda envoltura (614; 610), conteniendo dicha segunda envoltura a dicha primera envoltura (620, 614) y metadatos (622; 612) del primer elemento de proceso, adaptados para ejecutarse en dicho primer elemento de proceso.
Description
Método y sistema de envolturas multicapas para
metadatos de contenidos de empuje.
El presente método y sistema están relacionados
con la distribución dinámica de contenidos y, en particular, con
una arquitectura genérica de distribución dinámica de contenidos, en
la cual se pueden añadir las aplicaciones y los proveedores de
contenidos sin cambiar la arquitectura.
Los usuarios de dispositivos móviles o de
equipos móviles de usuarios (UE) se hacen cada vez más sofisticados
en términos de la funcionalidad que requieren de sus dispositivos
móviles y de la manera en la que acceden a los datos desde los
dispositivos móviles.
La distribución dinámica de contenidos permite a
los usuarios hacer que la información o los datos sean empujados
hacia ellos en lugar de tener que ir a buscar los datos. Ejemplo de
esos datos podrían incluir cotizaciones de bolsa, estado del
tiempo, estado del tráfico, pantallas dinámicas, anuncios,
aplicaciones u otros datos deseables por el usuario.
Las tecnologías actuales para los dispositivos
móviles tales como el protocolo de aplicaciones inalámbricas (WAP),
tienen la capacidad de empujar el contenido; sin embargo, el WAP
requiere que los sitios Web sean regrabados para satisfacer el
protocolo de aplicaciones inalámbricas y proporcionar a los usuarios
un sitio uniforme que no cambie para acomodar las capacidades del
usuario para observar el sitio.
Otras alternativas incluyen el empuje y la
difusión basados en SMS o la difusión por células. En el caso de la
difusión, la distribución no puede ser a la medida de las
necesidades de un usuario particular o de las capacidades de un
dispositivo particular. Estos sistemas no tienen por tanto
inteligencia asociada con ellos. Se requiere una solución mejor
para los dispositivos móviles.
El presente sistema y método proporcionan una
arquitectura de distribución dinámica de contenidos y un sistema
que permite a las aplicaciones genéricas y a los proveedores de
servicios ser añadidos al sistema sin necesidad de modificar la
arquitectura. Específicamente, el presente sistema y método permiten
a un dispositivo móvil convertirse en una plataforma dinámica de
aplicaciones en la cual se pueden añadir aplicaciones y contenidos
proporcionados al dispositivo móvil, donde la arquitectura del
sistema de distribución dinámica de contenidos no limita el tipo de
aplicación que puede ser instalada en el dispositivo, ni el tipo de
contenidos que recibe el dispositivo.
En un aspecto de la presente solicitud, se
proporcionan y se asocian preferiblemente metadatos con el
contenido, para añadir inteligencia al contenido de diversos
elementos de proceso dentro de la arquitectura de distribución
dinámica de contenidos. Esta arquitectura incluye componentes
lógicos que proporcionan la provisión de contenidos, la provisión
de servicios incluyendo proxys de empuje, una red inalámbrica,
clientes del empuje y aplicaciones del cliente.
En un aspecto adicional de la presente
solicitud, los metadatos se proporcionan preferiblemente con un
modelo "envuelto" en capas para los metadatos de contenidos de
empuje. El contenido está envuelto con metadatos que pueden ser
utilizados para el proceso en cada elemento dentro de un marco de
empuje. Los metadatos para cada elemento sucesivo están en capas,
permitiendo así que el elemento de proceso extraiga solamente los
metadatos para ese elemento. Por ejemplo, una página de contenidos
que incluya metadatos dirigidos a un proxy de empuje y a una
aplicación de un cliente, puede incluir el contenido con un primer
nivel de metadatos para la aplicación del cliente, y una segunda
capa de metadatos para el proxy de empuje. Por eso, cuando la
envoltura alcanza el proxy de empuje, se extraen los metadatos para
el proxy de empuje y se aplican al contenido, y el contenido
modificado y los metadatos para la aplicación del cliente se pasarán
a un elemento de proceso adicional.
En otro aspecto de la presente solicitud, los
metadatos pueden ser repartidos en metadatos estáticos (denominados
también en esta memoria como metadatos de canal) y metadatos
dinámicos denominados también en esta memoria como metadatos del
contenido). Los metadatos estáticos se establecen preferentemente en
el momento de registrar la aplicación y el proveedor de contenidos.
Sin embargo, los metadatos del canal pueden ser establecidos en un
momento posterior. Los metadatos del canal especifican las normas
del proceso que son específicas para el tipo de contenido que se
está entregando y de los requisitos de la aplicación para el tipo de
contenidos.
Los metadatos dinámicos están asociados, por el
contrario, con el contenido específico que se está pasando.
El documento WO 2006 010979 muestra el uso de
metadatos con respecto a una parte particular de datos de
contenidos, especificando los metadatos la identificación de la
parte de datos del contenido, la versión y la relevancia
temporal.
En otro aspecto de la presente solicitud, se
presenta un modelo de registro de los programas auxiliares
(plug-in) dentro de un marco de empuje. Se
identifica un cliente de empuje genérico y un proxy de empuje, cada
uno de ellos con diversos bloques o módulos de proceso que permiten
a estos elementos procesar tanto el contenido como los metadatos.
Estos bloques pueden ser dirigidos para procesar el contenido que se
está pasando, los metadatos que se están pasando, o ambas cosas,
contenido y metadatos que se están pasando.
El registro de programas auxiliares proporciona
además el pase de manifiestos de servicio y manifiestos de la
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 utilizados para registrar un
proveedor de contenidos en un marco de empuje, y un manifiesto de
aplicación puede ser utilizado para registrar una aplicación en el
marco de empuje.
En otro aspecto de la presente solicitud, se
proporciona preferiblemente un método para empujar contenidos de
compartidos que permite el manejo de datos basados en su prioridad y
basados en factores de red, incluyendo el coste de enviar datos, el
tipo de red conectada o las preferencias de los usuarios. Un modelo
combinado opcional de empujar/tirar para contenidos compartidos
permite que un proxy de empuje realice el empuje del contenido
cuando las condiciones de la red son favorables, o que un cliente
tire del contenido cuando las condiciones de la red son favorables
o cuando el usuario requiere el contenido.
Con el fin de acomodar diversos dispositivos
móviles, un aspecto adicional de la presente invención proporciona
la fragmentación del contenido, incluyendo la fragmentación del
contenido no lineal. La fragmentación del contenido no lineal
incluye el aumento del contenido con metadatos que permite
recomponer los datos una vez que han sido pasados al cliente.
Se identificarán éste y otros aspectos con más
detalle, con respecto a los dibujos.
La presente solicitud proporciona por tanto,
preferiblemente, un método para añadir inteligencia de proceso a la
carga útil de los contenidos en una arquitectura de distribución
dinámica de contenidos, que tiene al menos un primer elemento de
proceso y un segundo elemento de proceso, comprendiendo el método
los pasos de: crear una primera envoltura, incluyendo dicha
envoltura la carga útil del contenido y metadatos del segundo
elemento de proceso, estando adaptados dichos metadatos del segundo
elemento de proceso para ser ejecutados en dicho segundo elemento
de proceso; y formar una segunda envoltura, conteniendo dicha
segunda envoltura dicha primera envoltura y metadatos del primer
elemento de proceso, adaptados para ejecutarse en dicho primer
elemento de proceso.
La presente solicitud proporciona además una
envoltura de contenidos para una arquitectura de distribución
dinámica de contenidos, comprendiendo la envoltura de contenidos:
una carga útil de contenidos; metadatos de contenidos para un
primer elemento de proceso en dicha arquitectura de distribución
dinámica de contenidos, formando dichos metadatos de proceso de
contenidos y la carga útil del contenido una primera envoltura; y
segundos metadatos de contenidos para un segundo elemento de proceso
en la arquitectura de distribución dinámica de contenido, estando
anidados los segundos metadatos de proceso de contenidos en dicha
primera envoltura, para formar una segunda envoltura.
La presente solicitud proporciona además un
método para procesar una envoltura que tiene metadatos para un
elemento de proceso y metadatos y contenidos para elementos de
proceso sucesivos en una arquitectura de distribución dinámica de
contenidos, comprendiendo el método los pasos de: extraer los
metadatos del elemento de proceso desde la envoltura; utilizar los
metadatos en los metadatos y contenidos de los elementos de proceso
sucesivos, para crear así una envoltura procesada anidada; y
entregar la envoltura procesada anidada a uno de los sucesivos
elementos de proceso.
La invención proporciona también un sistema para
procesar una envoltura que tiene metadatos para un elemento de
proceso y metadatos y contenidos para elementos de proceso sucesivos
en una arquitectura de distribución dinámica de contenidos,
comprendiendo el sistema: medios para extraer los metadatos para el
elemento de proceso desde la envoltura; medios para utilizar los
metadatos en los metadatos y contenidos de los elementos de proceso
sucesivos, creando así una envoltura procesada anidada; y medios
para distribuir la envoltura procesada anidada a uno de los
sucesivos elementos de proceso.
La invención proporciona también un producto de
programa informático para añadir inteligencia de proceso a la carga
útil del contenido, en una arquitectura de distribución dinámica de
contenidos que tiene al menos un primer elemento de proceso y un
segundo elemento de proceso, comprendiendo el producto de programa
informático un medio legible por ordenador que materializa medios
de código de programa ejecutable en un dispositivo, sistema o
aparato informático, para implementar el método para añadir
inteligencia de proceso a la carga útil del contenido en una
arquitectura de distribución dinámica de contenidos como se ha
descrito anteriormente.
La invención proporciona también un producto de
programa informático para procesar una envoltura que tiene
metadatos para un elemento de proceso y metadatos y contenidos para
elementos de proceso sucesivos en una arquitectura de distribución
dinámica de contenidos, comprendiendo el producto de programa
informático un medio legible por ordenador que materializa medios
de código de programa ejecutable por un dispositivo, sistema o
aparato informático para implementar el método de proceso de una
envoltura que tiene metadatos, como se ha descrito anterior-
mente.
mente.
\newpage
La presente solicitud se comprenderá mejor con
referencia a los dibujos, en los cuales:
La figura 1 es un diagrama de bloques de una
arquitectura básica para un sistema de distribución dinámica de
contenidos;
La figura 2 es un diagrama de bloques que
muestra arquitecturas alternativas del sistema de distribución
dinámica de contenidos de la figura 1;
La figura 3 es el diagrama de bloques de la
figura 1, mostrando el flujo del contenido y los metadatos;
La figura 4 es un diagrama de bloques que
muestra un proxy de empuje que puede ser utilizado en asociación
con el presente sistema y método;
La figura 5 es un diagrama de bloques que
muestra un cliente de empuje, que puede ser utilizado en asociación
con el presente sistema y método;
La figura 6 es un diagrama de bloques que
muestra un modelo de envoltura en capas del contenido y de los
metadatos;
La figura 7 es el diagrama de bloques de la
figura 6, que muestra los metadatos dinámicos de los pasos de
proceso para cada envoltura;
La figura 8 es el diagrama de bloques de la
figura 6, mostrando adicionalmente el proceso que utiliza metadatos
estáticos y dinámicos;
La figura 9 es un diagrama de bloques que
muestra un proceso de registro de una aplicación para un solo
cliente de empuje compartido;
La figura 10 es un diagrama de bloques que
muestra un proceso de registro de una aplicación para un contenedor
de empuje que gestiona una agrupación de clientes de empuje;
La figura 11 es un diagrama de bloques que
muestra una aplicación que se registra en un procesador de
contenidos y un oyente de dispositivos de transporte de datos;
La figura 12 es un diagrama de bloques que
muestra un proveedor de contenidos que se registra en un solo proxy
de empuje compartido;
La figura 13 es un diagrama de bloques que
muestra un proveedor de contenidos que se registra en un contenedor
de empuje que gestiona una agrupación de proxys de empuje;
La figura 14 es un diagrama de flujo que muestra
los mensajes de registro entre un proveedor de contenidos y una
aplicación de un cliente;
La figura 15 es un diagrama de bloques que
muestra la interacción durante el registro entre un cliente de
empuje y un proxy de empuje;
La figura 16 es un diagrama de bloques que
muestra la interacción durante el registro entre un proxy de empuje
y un proveedor de contenidos;
La figura 17 es un diagrama de flujo que muestra
el flujo del contenido y los metadatos entre un proveedor de
contenidos y elementos de proceso;
La figura 18 es un diagrama de bloques que
muestra un ejemplo de aplicación de transformación para el
contenido;
La figura 19 es un diagrama de bloques de un
modelo para compartir contenidos;
La figura 20 es un diagrama de bloques de un
proceso de fragmentación lineal;
La figura 21 es un diagrama de bloques de un
proceso de fragmentación no lineal; y
La figura 22 es un diagrama de bloques de un
ejemplo de dispositivo móvil que podría ser utilizado en asociación
con el presente método y sistema.
\newpage
Se hace referencia ahora a la figura 1. Se
ilustra un sistema de empuje genérico para distribuir contenidos
dinámicos a la aplicación de un cliente. El sistema de la figura 1
es un sistema simplificado y muestra componentes lógicos que
necesitan estar en una arquitectura de distribución dinámica de
contenidos; sin embargo, un experto en la técnica apreciará que
podrían existir otros componentes o que podrían agruparse
conjuntamente diversos componentes.
La arquitectura 100 incluye un proveedor 110 de
contenidos. El proveedor 110 de contenidos está organizado para
proporcionar contenidos dinámicos a usuarios que están abonados al
proveedor 110 de contenidos. Ejemplos de eso pueden incluir, por
ejemplo, un sitio Web que venda libros. Un usuario puede registrase
en el proveedor 110 de contenidos para obtener una lista de libros
recientemente publicados dentro de unos géneros específicos. Otros
ejemplos podrían incluir sitios de noticias que podrían proporcionar
titulares a usuarios periódicamente, sitios de tráfico que podrían
proporcionar información actualizada del tráfico a los usuarios,
durante ciertos periodos del día, sitios del mercado de valores que
podrían proporcionar cotizaciones actualizadas de la bolsa o tasas
de cambio de dinero a los usuarios, entre otros.
Como se describirá con más detalle a
continuación, el proveedor 110 de contenidos se registra en un
proveedor 120 de servicios, con el fin de permitir a los clientes
del proveedor de servicios recibir el contenido desde el proveedor
110 de contenidos. El proveedor 120 de servicios incluye un proxy
122 de empuje que actúa como un proxy para un cliente o una
aplicación de un cliente, y proporciona un destino para el proveedor
110 de contenidos para enviar un contenido.
El proveedor 120 de servicios se comunica por
medio de una red inalámbrica 130 con un cliente 140 de empuje que
está situado sobre un dispositivo móvil. El cliente 140 de empuje
será descrito con más detalle a continuación. El cliente 140 de
empuje recibe el contenido que está siendo entregado desde el
proveedor 110 de contenidos, y puede comunicar el contenido con una
aplicación 150 del cliente, que finalmente es el consumidor del
contenido.
Dentro de la presente memoria, la referencia al
proveedor 110 de contenidos, al proveedor 120 de servicios, el
proxy 122 de empuje, a la red inalámbrica 130, al cliente 140 de
empuje o a la aplicación 150 del cliente, es una referencia a las
hechas en la arquitectura de la figura 1.
Haciendo referencia a la figura 2, los expertos
en la técnica podrán apreciar que los componentes de la figura 1
son meramente componentes lógicos y no son necesariamente
componentes físicos independientes. La figura 1 ilustra una
arquitectura genérica en la cual existe un proveedor 110 de
contenidos, un proxy 122 de empuje, un cliente 140 de empuje y una
aplicación 150 del cliente. En la figura 2 se ilustran
alternativas.
Específicamente, una primera arquitectura
alternativa 210 incluye múltiples proveedores 110 de contenidos que
se comunican con un proxy 122 de empuje. El proxy 122 de empuje,
como en la arquitectura de la figura 1, se comunica por una red
inalámbrica 130 con un cliente 140 de empuje. Además, en la
arquitectura 210 existen múltiples aplicaciones 150 del cliente.
Esto es por tanto un sistema
N-1-1-N que tiene
múltiples proveedores 110 de contenidos y múltiples aplicaciones
150 de clientes.
La arquitectura 220 de la figura 2 incluye un
proveedor 110 de contenidos que se comunica y que está registrado
con un proxy 122 de empuje. Además, el proxy 122 de empuje se
comunica por la red inalámbrica 130 con múltiples clientes 140 de
empuje. Cada cliente 140 de empuje se comunica con una aplicación
150 del cliente. La arquitectura 220 agrupa por tanto los
componentes lógicos de una aplicación 150 del cliente y un cliente
140 de empuje y es un sistema
N(1-1)-1-1.
La arquitectura 230 de la figura 2 tiene
múltiples proxys 122 de empuje, donde cada uno de ellos se comunica
con un proveedor 110 de contenidos. Cada combinación 232 de proxy de
empuje y de proveedores de contenidos se comunican por la red
inalámbrica con un cliente genérico 140 de empuje, que a su vez se
comunica con una aplicación 150 de cliente. Esto es un sistema
1-1-N(1-1).
En la arquitectura 240 de la figura 2, la
agrupación 232 de proveedor 110 de contenidos y proxy 122 de empuje,
se comunica por una red inalámbrica 130 con una combinación de un
cliente genérico 140 de empuje y una aplicación 150 del cliente.
Esto es por tanto un sistema
N(1-1)-N(1-1).
Como podrá apreciarse por los expertos en la
técnica, son posibles otras alternativas. Lo anterior muestra
diversos componentes lógicos que pueden estar en componentes físicos
independientes o agrupados conjuntamente. Por ejemplo, un cliente
de empuje puede estar incorporado en una aplicación, se pueden
utilizar clientes comunes compartidos por múltiples aplicaciones u
otras alternativas.
Se hace referencia ahora a la figura 3. Con el
fin de añadir inteligencia al sistema, se asocia el contenido con
metadatos. Los metadatos, en este caso, se definen como los datos
que pueden ser utilizados por un elemento de proceso para manipular
el contenido. Como podrá apreciarse, un sistema de empuje genérico
requiere metadatos para permitir que existan diversos proveedores
de servicios y aplicaciones dentro del sistema. Los metadatos
pueden ser de diversas formas, incluyendo parámetros o reglas de
proceso, o un gestor, código o referencia de proceso proporcionada
directamente o bien un enlace a un gestor, código o reglas de
proceso en otro lugar.
Como puede verse en la figura 3, el contenido
pasa desde el proveedor 110 de contenidos a la aplicación 150 del
cliente y está ilustrado con la flecha 310. Los metadatos, que
proporcionan instrucciones a diversos componentes dentro de la
arquitectura 100, pueden pasar también entre componentes dentro de
la arquitectura 100, normalmente junto con el contenido. Por
ejemplo, la flecha 320 ilustra metadatos que se originan en el
proveedor de contenidos y son transparentes para el sistema de
distribución hasta que alcanza una aplicación 150 del cliente.
La flecha 330 muestra metadatos creados por el
proveedor 110 de contenidos que están destinados al cliente 140 de
empuje, y por tanto solamente fluyen hacia el cliente genérico 140
de empuje.
La flecha 340 ilustra metadatos generados por el
proveedor 120 de servicios y destinados al cliente 140 de empuje, y
por tanto están asociados primero con el contenido en el proxy 122
de empuje y son extraídos del contenido en el cliente genérico 140
de empuje. Ejemplos de donde eso podría ocurrir incluyen acuerdos
entre un usuario y un proveedor de servicios con respecto a un plan
de facturación y al nivel de servicio a proporcionar, donde el
proveedor de servicios podría utilizar los metadatos para limitar
los servicios disponibles o para proporcionar servicios
mejorados.
El flujo de metadatos y el papel de los
metadatos se describen con más detalle a continuación.
Se hace ahora referencia a la figura 4. La
figura 4 ilustra un ejemplo detallado de un proxy 410 de empuje que
puede ser utilizado en asociación con el presente sistema y método.
Como podrán apreciar los expertos en la técnica, el proxy 410 de
empuje podría ser el mismo que el proxy 122 de empuje de las figuras
1 y 2.
El proxy 410 de empuje de la figura 4 incluye
diversos elementos que permiten que el proxy 410 de empuje funcione
en un entorno de empuje genérico. Esto facilita la flexibilidad, ya
que el proxy de empuje no está limitado a la interacción con
proveedores de servicios o clientes de empuje específicos, sino que
en lugar de eso puede ser adaptado a un entorno dinámico. Los
elementos descritos a continuación para el proxy 410 de empuje están
preferiblemente dentro del proxy 410 de empuje, pero los elementos
no son exhaustivos, y son posibles otros elementos. Además, pueden
omitirse ciertos elementos del proxy 410 de empuje, y los demás
elementos siguen siendo capaces de realizar servicios genéricos de
empuje.
El proxy 410 de empuje incluye proveedores 412
de contenidos registrados en él. Los proveedores 412 de contenidos
se registran en un interfaz 420 del proveedor de servicios (SPI) de
registro de proveedores de contenidos. Como se describe con más
detalle a continuación, es deseable en este registro que el
proveedor 412 de contenidos incluya cierta información del canal a
establecer, denominada en adelante metadatos del canal. Los
proveedores 412 de contenidos pueden ser los mismos que los
proveedores 110 de contenidos de la figura 1.
El proxy 410 de empuje incluye además un bloque
430 de administración de servicios para administrar el servicio del
proxy de empuje.
El proxy 410 de empuje incluye diversos módulos
para tratar tanto con el contenido como con los metadatos asociados
con ese contenido. Un primer módulo es el agente de mensajes y la
cola 440 de distribución, que es un subsistema que consume mensajes
desde el proveedor 412 de contenidos y gestiona la cola de
distribución de contenidos. Como podrá apreciarse por los expertos
en la técnica, no todos los contenidos de todas las aplicaciones de
los clientes pueden ser distribuidos al momento, y necesita
establecerse una cola de distribución con el fin de distribuir el
contenido a su debido tiempo. Por ejemplo, puede haber un
dispositivo fuera de cobertura y ser necesario almacenar el
contenido.
El proxy 410 de empuje incluye además un bloque
442 de gestión del control de flujo. El bloque 442 de gestión del
control de flujo permite el control del flujo de contenidos. Por
ejemplo, una estación móvil con espacio limitado puede ser capaz
solamente de recibir una cierta cantidad de información. En este
caso, el dispositivo móvil, a través del cliente 140 de empuje
ilustrado en la figura 1, puede pedir al proxy 410 de empuje que
detenga el flujo de datos al cliente 140 de empuje. El bloque 442 de
gestión del control de flujo se encarga de eso.
Alternativamente, el dispositivo móvil puede
estar desconectado. El bloque 442 de gestión del control de flujo
detiene e inicia el flujo de datos al cliente 140 de empuje cuando
el contenido no puede ser distribuido cuando se recibe por el proxy
410 de empuje.
Un componente adicional del proxy 410 de empuje
son los agentes 444 de empuje. Los agentes 444 de empuje son
responsables de enviar datos a los clientes.
Como podrá apreciarse por los expertos en la
técnica, los bloques 440, 442 y 444 tratan solamente con la
mensajería y no están relacionados con los metadatos. En otras
palabras, los bloques gestionan el contenido de los mensajes, pero
no con ningún metadato asociado con el contenido.
Un componente adicional del proxy 410 de empuje
es el bloque 450 extractor de metadatos de contenidos y de caché.
El bloque 450 extractor de metadatos de contenidos y de caché
funciona con metadatos de contenidos envueltos. Específicamente, en
el modelo de envoltura del sistema de metadatos, que se describe con
más detalle a continuación, cada componente lógico dentro del
sistema puede tener asociados metadatos con el procesamiento del
contenido. Estos metadatos permiten al componente lógico realizar
acciones sobre el contenido. Cada componente lógico necesita por
tanto ser capaz de extraer los metadatos que están asociados con
él.
El bloque 450 extractor de metadatos de
contenidos y de caché es responsable de extraer metadatos que están
asociados con el proxy 410 de empuje y de poner en caché estos
metadatos. La función de poner en caché permite la optimización
eliminando la necesidad de pasar metadatos idénticos en envolturas
subsiguientes de contenidos desde el mismo proveedor de contenidos.
La extracción y la puesta en caché de los metadatos se describe a
continua-
ción.
ción.
El bloque 452 de almacenamiento de mensajes con
recuperación diferida se utiliza cuando no es eficaz la entrega del
contenido, o partes de él, a una aplicación de cliente. El bloque
452 de almacenamiento de mensajes con recuperación diferida se
puede utilizar para almacenar el contenido que no se entrega al
cliente hasta que el envío de contenido sea eficaz, o hasta que se
tire del contenido por parte del cliente. El almacenamiento de
mensajes con recuperación diferida podría utilizarse también para
poner en caché el contenido auxiliar que podría ser enviado
opcionalmente o tirarse de él por parte del cliente, dependiendo de
la navegación de la aplicación del cliente a través del contenido
ya entregado.
La finalidad del bloque 452 de almacenamiento de
mensajes con recuperación diferida se explica mejor a continuación,
con referencia a la figura 19 y 21. A modo de ejemplo, el bloque 452
de almacenamiento de mensajes con recuperación diferida puede ser
utilizado en el caso de que un usuario haya requerido información de
situación, tal como un restaurante cercano al lugar del usuario. El
proveedor de contenidos o el proveedor de servicios pueden tener un
modelo para proporcionar información en el que los anunciantes
pueden pagar para añadir su información a peticiones de búsqueda.
Así, el usuario que está requiriendo información de restaurantes
para un lugar, puede obtener también información sobre tiendas,
cursos de golf, gimnasios u otros servicios cercanos a su lugar
como respuestas a su petición. Un proveedor de contenidos empaqueta
la información del restaurante requerido con la información
adicional, y la pasa al proxy 410 de empuje.
El proxy 410 de empuje puede crear, basándose en
los metadatos proporcionados, un paquete de contenidos para enviar
al cliente. El paquete de contenidos podría incluir la información
solicitada por el cliente, así como un extracto o resumen de
información relacionada, en la que podría estar interesado el
usuario. El resumen es enviado al usuario, pero el bloque 452 de
almacenamiento de mensajes con recuperación diferida almacena los
datos reales que se recibieron desde el proveedor 110 de contenidos.
Así, si en el futuro el usuario desea obtener información más
detallada sobre la información que está dentro del extracto, esta
información ya está almacenada en el proxy 410 de
empuje.
empuje.
Un uso alternativo del bloque 452 de
almacenamiento de mensajes con recuperación diferida es el caso en
el que 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 podría ser almacenada hasta un
momento posterior, en el que el cliente puede tirar de ella o ser
empujada cuando se cumplan reglas predefinidas. Estas reglas pueden
ser especificadas por la red o las condiciones de servicio para que
se satisfagan ciertas condiciones de red o de servicio. Esto se
describe con más detalle con referencia a la figura 19
posterior.
El programador 454 de empuje programa ventanas
de entrega para los clientes. Como se ha descrito anteriormente, en
algunas situaciones puede no ser eficaz empujar todo el contenido de
una vez. El programador 452 de empuje puede determinar que debe
empujar alguna información inmediatamente y el resto de acuerdo con
una programación predefinida. Además, el programador 454 de empuje
puede utilizar la naturaleza del contenido para determinar cuando
se debe empujar el contenido. Específicamente, los metadatos pueden
indicar que algo del contenido es de alta prioridad o tiene una
caducidad que está limitada en el tiempo, y este contenido puede ser
empujado inmediatamente, mientras que el contenido que ha sido
indicado como de baja prioridad, o sin caducidad, puede ser
empujado más tarde cuando las condiciones para pasar los datos sean
más favorables.
Como podrá apreciarse por los expertos en la
técnica, los bloques 450, 452 y 454 tratan del contenido del
mensaje y de los metadatos que están asociados con el mensaje.
El bloque 460 de la suscripción y de las reglas
hace un seguimiento de las aplicaciones que están registradas para
recibir un servicio, y supervisa las reglas sobre cómo gestionar un
contenido particular que ha de entregarse. El contenido se entrega
típicamente basándose en una suscripción por el cliente, o bien en
nombre del cliente. El usuario, por ejemplo si desea un servicio
particular, puede solicitar suscripciones activamente. Las
suscripciones pueden hacerse en nombre del usuario, por ejemplo, si
el usuario ha firmado un acuerdo con su proveedor 120 de servicios,
para recibir el beneficio de un servicio. Esto podría incluir el
caso en el que un usuario recibe una tarifa preferente siempre que
el usuario esté de acuerdo en recibir un cierto número de anuncios
diarios. En este caso, el proveedor 120 de servicios puede hacer la
suscripción al proveedor de anuncios en nombre del cliente.
Cuando se elimina una aplicación de un
dispositivo móvil o cuando la aplicación deja de estar registrada en
una suscripción, el bloque 460 de suscripciones y reglas puede
quitar la suscripción a ese usuario.
El bloque 462 de dependencias del contenido se
utiliza por el proxy 410 de empuje para anunciar servicios que
puede utilizar un usuario de un dispositivo móvil. Así, si el
usuario del dispositivo móvil no tiene una pantalla o una anchura
de banda o una memoria suficiente para el servicio, el bloque 462 de
dependencias del contenido podría bloquear el anuncio de ese
servicio para el usuario.
El bloque 464 de fragmentación del contenido se
utiliza para fragmentar el contenido. Esto podría usarse, por
ejemplo, si el dispositivo móvil es incapaz de recibir todo el
contenido de una vez. El bloque 464 de fragmentación del contenido
se utiliza para descomponer el contenido en diversos componentes. Se
puede utilizar en asociación con el almacenamiento 452 de mensajes
y recuperación diferida para almacenar el contenido fragmentado que
no haya sido entregado todavía.
El bloque 466 de caducidad y sustitución del
contenido se utiliza para dos fines. En primer lugar, este bloque
se puede utilizar para supervisar suscripciones. Cada suscripción
tiene una fecha de caducidad y cuando se cumple esta fecha de
caducidad, se puede finalizar la suscripción.
Además, el bloque 466 de caducidad y sustitución
del contenido se puede utilizar para supervisar la información.
Ciertos contenidos tienen límites de tiempo en la validez de la
información. Por ejemplo, una aplicación de tráfico utilizada para
supervisar el tráfico en hora punta será muy dependiente del tiempo.
Si por alguna razón, el proxy 410 de empuje es incapaz de entregar
el contenido inmediatamente a un dispositivo móvil, este contenido
es almacenado en el almacenamiento 480 de contenidos para su entrega
futura. Sin embargo, si el contenido no se entrega dentro de un
cierto periodo de tiempo especificado, podría caducar y no ser
entregado en absoluto.
De forma similar, la sustitución de contenidos
trata con una situación en la que se actualiza la información. Por
ejemplo, una aplicación de un cliente que está recibiendo
cotizaciones de bolsa puede desear solamente la última cotización
de bolsa. Por tanto, si el proxy 410 de empuje es incapaz de
entregar la cotización de bolsa al cliente 140 de empuje, y se
recibe posteriormente una cotización de bolsa desde el proveedor 110
de contenidos, los metadatos dentro de la siguiente cotización de
bolsa pueden indicar que deben ser utilizados para sustituir la
cotización de bolsa anterior. La sustitución de información
almacenada en lugar de añadir toda la información a una cola de
entrega, libera espacio dentro del almacenamiento 480 de
contenidos.
El repositorio 470 de metadatos de canal se
utiliza para almacenar metadatos del canal, que se describen con
más detalle a continuación.
En lo que antecede se describe un ejemplo de
proxy 410 de empuje que puede ser utilizado con el método y sistemas
de esta memoria. Los bloques y elementos del proxy 410 de empuje
permiten al proxy 410 de empuje ser utilizado en un sistema
genérico de entrega dinámica de contenidos, en el que el tipo de
contenidos y gestión del contenido en una aplicación puede variar y
no está predeterminado.
Se hace referencia ahora a la figura 5. La
figura 5 ilustra un cliente 510 de empuje que puede ser utilizado
en asociación con el sistema y métodos de la presente memoria. El
cliente 510 de empuje puede ser el mismo que el cliente 140 de
empuje de las figuras 1 y 2.
Como puede apreciarse por los expertos en la
técnica, un cliente 510 de empuje que ha de utilizarse en un
sistema genérico, en el cual el contenido y el procesamiento del
contenido no está predeterminado, debe incluir bloques o módulos
que pueden ser utilizados 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 también
podrían existir otros bloques dentro de un cliente 510 de empuje.
Además, los bloques dentro del cliente 510 de empuje pueden ser
omitidos, en algunos casos, sin restringir la funcionalidad de los
demás bloques dentro del cliente 510 de empuje.
Un cliente 510 de empuje da servicio a las
aplicaciones, y puede registrarse una o más aplicaciones 512 en un
cliente 510 de empuje. El registro de aplicaciones utiliza un
interfaz 514 del proveedor de aplicaciones como interfaz para el
registro y el interfaz 514 del proveedor de aplicaciones puede ser
utilizado además para extraer metadatos del canal para la
aplicación, como se describe con más detalle a continuación.
El cliente 510 de empuje incluye una
administración 520 de clientes, utilizada para administrar el
cliente 510 de empuje.
Como en el servidor 410 de empuje de la figura
4, el cliente 510 de empuje incluye diversos bloques que tratan con
los mensajes, diversos bloques que tratan con los metadatos, y
diversos bloques que tratan con los mensajes y con los
metadatos.
El agente de mensajes y las colas 540 de
aplicaciones gestionan mensajes desde el proxy 410 de empuje para
distribuir las aplicaciones 512. Una cola de aplicaciones es una
cola de mensajes para las aplicaciones 512.
El bloque 542 de gestión del control de flujo se
utiliza para notificar al proxy 410 de empuje de la figura 4 que
detenga el empuje de contenidos o que reanude el empuje de
contenidos. Esto puede ser utilizado, por ejemplo, cuando el
cliente 510 de empuje tiene una cantidad limitada de memoria que
puede aceptar contenidos empujados. En este caso, antes de que el
contenido de empuje sea consumido, el cliente 510 de empuje necesita
detener el flujo de contenidos desde el proxy 410 de empuje. Una
vez que el contenido ha sido consumido, el bloque 542 de gestión de
control del flujo puede ser utilizado para iniciar nuevamente el
flujo de datos.
Los agentes 544 de empuje dentro del cliente 510
de empuje, se utilizan para recibir información desde el proxy 410
de empuje de la figura 4.
Como podrá apreciarse por los expertos en la
técnica, los agentes de mensajes y las colas 540 de aplicaciones,
el bloque 542 de gestión del control del flujo, y los agentes 544 de
empuje tratan exclusivamente con mensajería y no con metadatos.
El bloque 550 extractor de metadatos de
contenidos y de caché se utiliza para extraer metadatos dinámicos
destinados al cliente 510 de empuje. Como se ha indicado
anteriormente con referencia al proxy 410 de empuje de la figura 4,
cualquiera de los elementos de proceso de la arquitectura de
distribución dinámica de contenidos podría tener metadatos
destinados a ellos, y estos metadatos necesitan ser extraídos. Por
tanto, los metadatos destinados al cliente 510 de empuje son
extraídos por el bloque 550 extractor de metadatos de contenidos y
de caché.
Además, el bloque 550 extractor de metadatos de
contenidos y de caché está, preferiblemente, adaptado para poner
los metadatos en caché. Los metadatos para el cliente 510 de empuje
que no necesitan cambiar entre un primer paquete de contenidos y un
segundo paquete de contenidos no es necesario pasarlos, ahorrando
tiempo de proceso en el cliente 510 de empuje, al no requerir la
extracción de estos metadatos, y ahorrando además recursos de red
al no requerir que pasen metadatos para el cliente 510 de empuje por
la red inalámbrica 130.
El gestor 552 de recuperación diferida se
utiliza para analizar los fragmentos de contenidos que se reciben y
para poner juntos los contenidos en la forma correcta. Como se
describe con más detalle a continuación, los datos pueden ser
lineales o no lineales. Si los datos son
no-lineales, se requieren metadatos para
reconstituirlos, y esto se hace por medio del gestor 552 de
recuperación diferida. El gestor 552 de recuperación diferida está
adaptado también para analizar un extracto de la información
disponible en el almacenamiento 452 de recuperación diferida del
proxy 510 de empuje, y dirige al agente 554 que tira de los
contenidos (descrito a continuación) para recuperar esta
información cuando lo requiera el usuario. Esto incluye la
recuperación predecible cuando la navegación de los contenidos
entre en una cierta rama del gráfico de estructuras del contenido o
cuando se satisfacen las condiciones de anchura de banda o de
coste.
El agente 554 que tira del contenido se utiliza
en un modelo de empujar/tirar en el que el cliente 510 de empuje es
capaz también de tirar del contenido en ciertas situaciones. Tales
situaciones se describen a continuación con más detalle, con
referencia a la figura 19.
Como se apreciará por los expertos en la
técnica, el bloque 550 extractor de metadatos de contenidos y de
caché, el gestor 552 de recuperación diferida y el agente 554 que
tira del contenido tratan con el contenido de mensajería y con los
metadatos.
El bloque 560 de gestión de suscripciones es el
mismo que el bloque 460 de suscripciones y normas de la figura 4.
Específicamente, el bloque 560 de gestión de suscripciones se
utiliza para gestionar suscripciones. Si una aplicación deja de
estar registrada o se elimina de un dispositivo móvil, el bloque 560
de gestión de suscripciones finaliza la suscripción. El bloque 560
de gestión de suscripciones también puede volver a suscribir en
nombre de una aplicación del cliente cuando expira el canal de
suscripción.
\vskip1.000000\baselineskip
El bloque 562 de notificación de actualizaciones
trabaja con las aplicaciones del cliente y se utiliza para
notificar a las aplicaciones que hay un nuevo contenido
esperándolas. Esto puede hacerse en una de tres maneras:
- a.
- Una primera manera en la que el bloque 562 de notificación de actualización puede notificar a una aplicación 512 es que el cliente 510 de empuje envíe el contenido a la aplicación 512 directamente.
- b.
- Una segunda manera en la que el bloque 562 de notificación de actualización puede notificar a las aplicaciones 512 de nuevo contenido es almacenar el contenido en el almacenamiento 580 de contenidos y, opcionalmente, notificar a las aplicaciones 512 de que el contenido está esperando. La notificación, en este caso, es opcional. Específicamente, si una aplicación 512 sabe que la información destinada a ella está almacenada dentro de un bloque de memoria específico, una opción para la aplicación que descubre que tiene datos nuevos es interrogar periódicamente al lugar de memoria para ver si hay algo escrito en él. Alternativamente, el bloque 562 de notificación de actualización puede enviar un mensaje a la aplicación 512, que indica que tiene nuevos datos y posiblemente el lugar en que están almacenados los datos.
- c.
- Una tercera manera en la que el bloque 562 de notificación de actualización puede notificar a las aplicaciones 512 de nuevo contenido es almacenar el contenido internamente y notificar a la aplicación. La aplicación puede entonces visitar al cliente de empuje para recuperar el contenido.
\vskip1.000000\baselineskip
El bloque 564 de dependencia del contenido es el
mismo que el bloque 462 de dependencia del contenido de la figura
4, y puede determinar si puede anunciar el servicio al dispositivo
móvil.
El bloque 566 de caducidad del contenido y de
sustitución es el mismo que el bloque 466 de sustitución y caducidad
del contenido de la figura 4. La caducidad del contenido y la
sustitución del contenido pueden así ser gestionadas en el cliente
510 de empuje, además de serlo en el servidor de empuje o el proxy
de empuje.
El repositorio 570 de metadatos del canal se
utiliza para almacenar metadatos del canal para una
aplicación
512.
512.
El módulo 575 de proceso de actualización de
segundo plano se utiliza para efectuar actualizaciones cuando una
aplicación 512 no está disponible. La actualización en segundo plano
permite, por ejemplo, la sustitución de datos por datos nuevos
dentro del almacenamiento de la aplicación. De ahí en adelante,
cuando el usuario inicia la aplicación, los datos presentados por
la aplicación son correctos y actualizados.
El módulo 575 de proceso de actualización de
segundo plano utiliza contenidos de conversión de reglas de proceso
en un formato aceptable para una aplicación. Puede ejecutar y
procesar contenidos del almacenamiento 580 de contenidos.
A modo de ejemplo, una lista de tareas que es
actualizada para un contratista durante la noche podría tener
tareas empujadas hacia él. La aplicación de tareas no se inicia
durante ese tiempo y el módulo 575 de proceso de actualización de
segundo plano puede ser utilizado para actualizar el contenido de la
aplicación de tareas. Esto podría hacerse con código para gestionar
un fichero de lenguaje de marcación extensible (XML), y podría
existir en el dispositivo en un fichero denominado
"handler.exe" ("gestor.exe"). El bloque 575 de proceso de
actualización de segundo plano del cliente 510 de empuje puede
ejecutar el handler.exe, pasando el documento XML como un
parámetro. El gestor construye entonces la tarea en formato interno
de la aplicación.
Una vez que el bloque 575 de proceso de
actualización de segundo plano del cliente 510 de empuje construye
la tarea en formato interno de la aplicación, puede leer la tarea de
la lista de tareas del almacenamiento 580 de contenidos, y añadir
la nueva tarea a la lista. Después puede almacenar de nuevo lo
modificado en el almacenamiento 580 de contenidos, cuando la
aplicación de la tarea se conecta a continuación al cliente 510 de
empuje.
La figura 5 ilustra por tanto un cliente 510 de
empuje que puede ser utilizado en un sistema de distribución
dinámica de contenidos, donde el contenido y el proceso del
contenido son dinámicos y no predeterminados. Los bloques descritos
anteriormente con referencia al cliente 510 de empuje de la figura 5
se utilizan para acomodar la naturaleza dinámica del sistema.
Como se ha indicado anteriormente con referencia
a la figura 3, el contenido está asociado con los metadatos para
proporcionar inteligencia al 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 (del canal) y metadatos dinámicos (del contenido).
Debido a las posibilidades ilimitadas de tipos
de proveedores de contenidos y aplicaciones, los metadatos son
críticos con el fin de construir sistemas genéricos. La única manera
de gestionar el tipo específico de contenido es a través de los
metadatos.
Los metadatos estáticos son metadatos que
proporcionan reglas sobre cómo procesar tipos de contenidos
específicos. Los metadatos estáticos pueden ser descompuestos en
diversos niveles de abstracción e incluir por ejemplo información
estructural sobre el propio contenido. Por ejemplo, un documento de
Reparto Simple en Tiempo Real (RSS) podría ser entregado con una
estructura RSS 2.0.XSD, y todo el contenido de ese proveedor de
contenidos será entregado con esta estructura.
Un nivel adicional de abstracción para los
metadatos estáticos incluye la provisión de reglas de proceso para
el subtipo de contenidos. Esto podría ser específico de la
aplicación. Así, por ejemplo, una aplicación de noticias
financieras indica que los datos deben ser extraídos desde una
cadena RSS de noticias financieras, almacenados en un lugar
predeterminado, y que la aplicación sea notificada al llegar la
información. La aplicación siempre requiere que el contenido
destinado a ella sea gestionado de esta manera.
Los metadatos estáticos (denominados también en
esta memoria como metadatos del canal), permanecen inalterados
durante toda la suscripción entre la aplicación y el proveedor de
contenidos, y de esta manera pueden establecerse los metadatos
estáticos una vez para cada elemento dentro de la arquitectura y
para cada canal de entrega de contenidos. En un modo de
realización, esto se hace en el momento del registro de la
aplicación o del proveedor de contenidos.
Los metadatos dinámicos son metadatos que están
asociados con una parte en particular del contenido. Por ejemplo,
la información de caducidad asociada con una parte particular de los
datos o con las reglas de sustitución e información asociadas con
una parte particular de los datos (es decir, el documento K
sustituye al documento L).
Como se ha indicado anteriormente con referencia
a las figuras 4 y 5, cada entidad de proceso puede recibir
metadatos estáticos y dinámicos, que son dirigidos a esa entidad de
proceso. Así, el proxy 410 de empuje utiliza el bloque 450
extractor de metadatos de contenidos y de caché para extraer los
metadatos dinámicos, y el bloque 466 de caducidad y de sustitución
del contenido se utiliza para sustituir el contenido no entregado
por nuevos contenidos recibidos en el proxy 410 de empuje.
\newpage
Se hace referencia ahora a la figura 6. La
figura 6 ilustra un modelo de envoltura en capas para los metadatos
de contenidos.
Un proxy 410 de empuje recibe una envoltura 610
de empuje que incluye metadatos de proceso de contenidos para el
servidor proxy 612 y una envoltura 614 del cliente de empuje. El
proxy 410 de empuje extrae los metadatos 612 de proceso de
contenidos y utiliza estos metadatos para procesar la envoltura 614
del cliente de empuje. Los metadatos 612 indican al proxy de empuje
lo que tiene que hacer con la envoltura 614 del cliente de
empuje.
La envoltura 614 del cliente de empuje se pasa
al cliente 510 de empuje, donde es descompuesta en la envoltura 620
de contenidos y en metadatos 622 de proceso del contenido. Los
metadatos 622 de proceso de contenidos se utilizan por el cliente
510 de empuje para procesar la envoltura 620 del contenido. Por
ejemplo, esto puede ser utilizado para instruir al cliente 510 de
empuje que realice la sustitución de la envoltura 620 del contenido
previamente entregada por la última envoltura, si la aplicación 150
del cliente solamente está interesada en la última versión
del
contenido.
contenido.
La envoltura 620 del contenido se pasa a la
aplicación 150 del cliente. La envoltura 620 del contenido incluye
los metadatos 630 de proceso del contenido para la aplicación y para
la carga útil 632 del contenido que ha de consumirse por la
aplicación 150 del cliente.
Como apreciarán los expertos en la técnica, el
anidado de envolturas de acuerdo con la figura 6 proporciona un
rico entorno dinámico en el cual el proceso puede tener lugar en
cualquier elemento de proceso de la arquitectura y en el cual el
proveedor 110 de contenidos puede especificar cómo ha de tratarse el
contenido específico. En un modo de realización, los metadatos
dirigidos a un elemento lógico particular son opacos para otros
elementos de proceso.
Alternativamente, el proveedor 120 de servicios
puede añadir también metadatos al proxy 410 de empuje para el
proceso en el cliente 510 de empuje o en la aplicación 150 del
cliente.
Haciendo referencia a la figura 7, esta figura
muestra el modelo de envoltura de la figura 6 y los pasos que toma
cada elemento de proceso con una envoltura. Como se ilustra en la
figura 7, el proxy 410 de empuje extrae primero los metadatos desde
la envoltura 610 de empuje. Esto se hace en el paso 710.
En el paso 712, el proxy 410 de empuje utiliza
los metadatos para procesar la envoltura 614 del cliente de empuje.
En el paso 714, el proxy 410 de empuje entrega la envoltura 614 del
cliente de empuje al cliente 510 de empuje.
De forma similar, el cliente 510 de empuje, en
el paso 720, extrae los metadatos 622 de proceso del contenido
desde la envoltura 614 del cliente de empuje. En el paso 722, el
cliente 510 de empuje utiliza los metadatos 622 de proceso de
contenidos en la envoltura 620 del contenido. En el paso 724, el
cliente 510 de empuje entrega la envoltura 620 del contenido a la
aplicación 150 del cliente.
En el paso 730, la aplicación 150 del cliente
extrae los metadatos 630 de proceso del contenido y en el paso 732
utiliza los metadatos 630 de proceso del contenido en la carga útil
632 del contenido.
Haciendo referencia a la figura 8, esta figura
muestra el método como se ha ilustrado en la figura 7, con el paso
adicional del uso de metadatos estáticos o de canal.
Específicamente, una vez que se han extraído los metadatos en el
paso 710, desde la envoltura 610 de empuje, el proxy 410 de empuje
utiliza después los metadatos estáticos del canal para procesar la
envoltura del cliente de empuje en el paso 810. En el paso 712, el
proxy 410 de empuje procesa a continuación los metadatos dinámicos
612 de proceso del contenido. El proxy 410 de empuje entrega
después la envoltura 614 del cliente de empuje en el paso 714.
De forma similar, el cliente 510 de empuje
extrae los metadatos 622 de proceso del contenido en el paso 720.
El cliente 510 de empuje utiliza después los metadatos del canal, en
el paso 820, en el contenido que está dentro de la envoltura 620
del contenido. El cliente 510 de empuje, en el paso 722, utiliza
después los metadatos dinámicos del contenido en los metadatos 622
de proceso del contenido, antes de entregar la envoltura 620 del
contenido a la aplicación 150 del cliente en el paso 724.
La aplicación 150 del cliente extrae primero, en
el paso 730, los metadatos 630 de proceso del contenido. Después
utiliza los metadatos del canal, en el paso 830, en la carga útil
632 del contenido. La aplicación 150 del cliente utiliza después,
en el paso 732, los metadatos 630 de proceso del contenido en la
carga útil 632 del contenido.
Como apreciarán los expertos en la técnica, el
modelo anterior permite por tanto aplicar los metadatos del canal,
junto con los metadatos dinámicos que están asociados con el
contenido particular que se está enviando.
Se hace referencia ahora a la figura 9. Como
podrá apreciarse por la figura 5, el cliente 510 de empuje puede
dar servicio a múltiples aplicaciones objetivo 512 en un dispositivo
móvil. Se requiere un mecanismo de registro eficaz en el que las
aplicaciones puedan registrarse en el marco de distribución dinámica
de contenidos, sin interrumpir el servicio para otras
aplicaciones.
\newpage
Haciendo referencia a la figura 9, el cliente
510 de empuje incluye tres aplicaciones, específicamente las
aplicaciones 910, 912 y 914, que ya están registradas en el cliente
de empuje. Como podrá apreciarse, el modelo de aplicaciones
auxiliares ("plug-in") es importante, porque
nuevos dispositivos pueden permitir que un número ilimitado de
tipos de aplicaciones sean instaladas en el dispositivo. Además, las
aplicaciones pueden instalarse dinámicamente, conduciendo a un
dispositivo móvil que se convierte en una plataforma de
aplicaciones. Debido a que el dispositivo puede ser una plataforma
de aplicaciones, debe ser capaz de incorporar dinámicamente nuevas
aplicaciones.
Como se observa en la figura 9, la aplicación
916 desea registrarse en el nuevo cliente 510 de empuje. La
aplicación 916 incluye un manifiesto 918 de aplicaciones que, en un
modo de realización preferido, proporciona los metadatos del canal
para la aplicación. Específicamente, el manifiesto 918 de
aplicaciones proporciona información al cliente 510 de empuje, y
finalmente al proxy 410 de empuje y al proveedor 110 de contenidos
de la figura 1, con los metadatos estáticos para la aplicación. Esto
puede incluir, aunque no está limitado a ello, qué tipo de
contenidos espera la aplicación, cómo se entregará el contenido, si
la aplicación necesita notificación, u otra información del canal
que sería evidente para los expertos en la técnica con respecto al
presente sistema y método.
La aplicación 916 se registra por tanto en el
cliente 510 de empuje, proporcionando el manifiesto 918 de
aplicaciones para establecer un canal al proveedor de contenidos
para la aplicación 916 de servicio.
Haciendo referencia 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, se empareja la aplicación 150 del cliente con un cliente
140 de empuje. Cada pareja de aplicación 150 de cliente/cliente 140
de empuje se coordina con un contenedor 1010 de empuje.
Cuando la aplicación 1020 desea registrarse en
el contenedor 1010 de empuje, se crea un cliente 140, o se usa si
ya existe, por el contenedor 1010 de empuje. Además, en el registro,
la aplicación 1020 proporciona un manifiesto 1030 de aplicaciones
al contenedor 1010 de empuje, proporcionando así los metadatos del
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
empuje gestiona/mantiene una agrupación de clientes de empuje.
Cuando una aplicación se registra en un contenedor, obtiene un
cliente exclusivo 510 de empuje, que en el caso sencillo podría
estar representado por una pareja de un oyente 1130 de un
dispositivo de transporte de datos y por un gestor de contenidos. El
cliente de empuje es devuelto a la agrupación cuando la aplicación
deja de estar registrada en el contenedor (y en el servicio de
distribución de contenidos) o es eliminado del dispositivo.
El contenedor 1110 de empuje incluye los
dispositivos 1120 de transporte de datos ("sockets") para la
comunicación. Además, el contenedor 1110 de empuje incluye oyentes
1130 de "sockets" y procesadores 1140 de contenidos asignados
a un "socket" en particular.
Como puede verse en la figura 11, se utilizan
diversas parejas de procesadores de contenidos y de oyentes de
"sockets" en las aplicaciones 150 previamente registradas.
Cuando una nueva aplicación 1150 desea
registrarse en el contenedor 1110 de empuje, se asigna un nuevo
procesador de contenidos y oyente de "sockets" 1120 y 1130,
para dar servicio a la aplicación 1050 de servicio.
Lo que antecede proporciona, por tanto, un marco
genérico de empuje en el cual se puede implementar y registrar una
aplicación 150 de un cliente que es nueva, en un cliente 510 de
empuje o en un contenedor 1010 o 1110 de empuje, permitiendo así
que el dispositivo se convierta en una plataforma de aplicaciones
capaz de incorporar dinámicamente nuevas aplicaciones. El pase de
un manifiesto 1030 0 918 de aplicaciones de las figuras 9 y 10
anteriores permite el establecimiento de metadatos del canal,
permitiendo así que el contenido sea procesado de acuerdo con los
requisitos de la aplicación.
Haciendo referencia a la figura 12, los
proveedores 110 de contenidos necesitan, de forma similar,
registrarse en un proxy 410 de empuje. Como se observa en la figura
12, el proxy 410 de empuje incluye tres proveedores de contenidos,
que son el 1210, 1212 y 1214, ya registrados en el proxy 410 de
empuje. El proveedor 1216 de contenidos desea registrarse en el
proxy 410 de empuje.
De forma similar al manifiesto 918 de
aplicaciones ilustrado en la figura 9, proporcionado por una
aplicación 916 cuando se registra en el cliente 510 de empuje, el
proveedor 1216 de contenidos incluye un manifiesto 1218 de servicio
que es traspasado al proxy 410 de empuje, cuando se registra el
proveedor 1216 de contenidos. El manifiesto 1218 de servicios
incluye información concerniente al tipo de información que va a
proporcionar el proveedor de contenidos, con qué frecuencia
proporciona esta información, el formato de la información, y
cualquier otra información que sea útil para el servicio o para el
anuncio del servicio. También es posible otra información.
El proxy 410 de empuje utiliza el manifiesto
1218 de servicio para establecer metadatos (estáticos) de canal
para el proveedor 1216 de contenidos.
\newpage
Haciendo referencia a la figura 13, un modo de
realización alternativo, representado por la arquitectura 230 de la
figura 2, va a tener un contenedor de empuje con varias parejas de
proxy 122 de empuje y proveedor 110 de contenidos. Como en la
figura 12, podrían estar ya registradas diversas aplicaciones en el
contenedor 1310 de empuje, y en el ejemplo de la figura 12, las
aplicaciones 1312, 1314 y 1316 están ya registradas en los proxys
de empuje 1313, 1315 y 1317, respectivamente.
Una nueva aplicación 1320 quiere registrarse en
el contenedor 1310 de empuje. Por tanto, el contenedor 1310 de
empuje crea un nuevo proxy (no ilustrado) o utiliza un proxy
existente (no ilustrado) con el cual asocia el proveedor 1320 de
contenidos. Además, el proveedor 1320 de contenidos proporciona el
manifiesto 1322 de servicios para describir el contenido que va a
proporcionar el proveedor 1320 de contenidos, permitiendo así el
establecimiento de los metadatos del canal.
Como apreciarán los expertos en la técnica, los
modos de realización de las figura 9 y 10 muestran dos opciones
para los clientes de empuje, ya sean con aplicaciones compartidas o
con cliente de empuje exclusivos por cada aplicación. Un experto en
la técnica se dará cuenta de que son posibles otros modos de
realización. De forma similar, con respecto a las figuras 12 y 13,
se ilustra un proxy de empuje con múltiples proveedores de
contenidos registrados en él, o se ilustra un proxy de empuje
exclusivo para cada proveedor de contenidos, y materializado en un
contenedor de empuje.
Con referencia a la figura 14, se ilustra la
mensajería entre un proveedor 110 de contenidos y una aplicación
150 del cliente. El proveedor 110 de contenidos proporciona un
mensaje de registro al proxy 410 de empuje. Este mensaje puede
incluir el manifiesto de servicios que puede ser utilizado para
proporcionar metadatos del canal al proxy 410 de empuje. Esto se
hace en el paso 1410.
El proveedor 110 de contenidos puede también, o
alternativamente, proporcionar metadatos del canal en un mensaje
posterior, como se ilustra en el paso 1412.
El proxy 410 de empuje añade entonces un
servicio a la lista de servicios disponibles (el catálogo de
servicios) en el paso 1414.
Un paso adicional en el ejemplo de la figura 14
es que el proxy 410 de empuje notifique al cliente 510 de empuje
sobre el nuevo servicio disponible en el paso 1416, y esta
notificación puede ser propagada a una aplicación 110 del cliente
en el paso 1418.
Como apreciarán los expertos en la técnica, los
pasos 1416 y 1418 son opcionales, y otras alternativas incluyen la
aplicación 150 del cliente que tira periódicamente del catálogo de
servicios desde el proxy 410 de empuje, para observar nuevos
servicios.
Cuando un usuario o proveedor de servicios para
la aplicación 150 del cliente decide que la aplicación 150 del
cliente debe suscribirse a un servicio, envía un mensaje de
suscripción en el paso 1420. El mensaje de suscripción se pasa
también al proxy 410 de empuje en el paso 1422.
Una vez que el proxy 410 de empuje recibe el
mensaje de suscripción en el paso 1422, hay disponibles dos
opciones. Una primera opción es enviar un mensaje 1424 al proveedor
110 de contenidos para una suscripción, y después recibir una
envoltura del mensaje que incluye los metadatos devueltos en el paso
1426. Los metadatos podrían ser un dispositivo o un tipo de
dispositivo específico.
Alternativamente, el proxy 410 de empuje puede
recibir el mensaje de suscripción en el paso 1422 e inmediatamente,
basándose en la información ya proporcionada por el proveedor 110 de
contenidos y almacenada en el proxy 410 de empuje, contestar en el
paso 1430 al cliente 510 de empuje. Esta respuesta se propaga a la
aplicación 150 del cliente en el paso 1532. Como podrá apreciarse,
la respuesta puede incluir metadatos del canal específicos del
proveedor 110 de contenidos.
La diferencia en los modelos puede depender de
quién esté adaptando los datos para la aplicación. Como podrá
apreciarse, el proveedor 110 de contenidos proporciona la mejor
adaptación del contenido en comparación con otros elementos de
proceso. Sin embargo, el proveedor 120 de servicios, a través del
proxy 410 de empuje, puede proporcionar también la adaptación del
contenido.
\newpage
Además, como podrá apreciarse, la estructura del
contenido podría depender de los datos que requiere la aplicación.
Por ejemplo, en una aplicación financiera, la aplicación puede
desear cotizaciones de bolsa y tasas de cambio. Se puede utilizar
el XML siguiente:
Si el usuario solamente quisiera cotizaciones y
no tasas de cambio de divisas, la estructura podría cambiar a:
Los metadatos pueden proporcionar información a
la aplicación sobre la estructura con la que deben ser pasados los
datos.
Por tanto, existen dos modelos. Los metadatos
estáticos pueden ser proporcionados al proxy 410 de empuje y al
cliente 510 de empuje, ya sea durante el registro o bien después.
Alternativamente, los metadatos para el proxy 410 de empuje y el
cliente 510 de empuje pueden ser pre-proporcionados,
es decir, se almacena la información en un cliente de empuje o en
un proxy de empuje, hasta que la aplicación se registra en un
cliente.
Se hace referencia ahora a la figura 15. La
figura 15 muestra los pasos lógicos que tienen lugar al registrar
una aplicación en un cliente 510 de empuje.
Una vez que la aplicación se registra en un
cliente 510 de empuje, un primer paso 1510 es adaptar la aplicación
registrada con el tipo de contenido requerido por la aplicación.
Esto es conocido a partir del manifiesto 918 de la aplicación, como
se ilustra en la figura 9.
Un segundo paso 1520 es establecer el entorno de
la aplicación. Esto incluye, aunque no está limitado a ello,
opciones de almacenamiento y distribución para la aplicación. Por
ejemplo, una aplicación puede limitar las transmisiones a una
cantidad de datos predeterminada. El cliente 510 de empuje en un
evento de control de flujo, o si la aplicación o el cliente están
fuera de contacto, puede requerir que los datos se pongan en caché
para la aplicación y, opcionalmente, notificar a la aplicación de
que hay datos esperando.
Un tercer paso 1530, es notificar al proxy 410
de empuje sobre los ajustes de la aplicación. Esto incluye por
ejemplo el almacenamiento disponible para la aplicación o para el
cliente 510 de empuje. Como podrá apreciarse, el proxy 410 de
empuje no debe empujar más datos que los que puede almacenar el
cliente 510 de empuje. Así, los ajustes de la aplicación podrían
incluir un límite superior de los datos que se van a pasar.
Haciendo referencia a las figuras 4 y 5, esto podría invocar al
bloque 464 de fragmentación de contenidos para fragmentar el
contenido si es mayor que lo que la aplicación puede procesar.
Además, si los dato son no-lineales, puede
requerirse el bloque 462 de dependencia de los contenidos para crear
metadatos para el bloque 564 de dependencias del contenido de la
figura 5, con el fin de permitir que el bloque 564 de dependencias
del contenido reconstituya los datos.
Haciendo referencia de nuevo a la figura 15, el
paso 1530 puede indicar también la preferencia en la distribución
de los datos. Por ejemplo, la aplicación puede preferir ciertos
tipos de datos sobre otras, y a estos tipos de datos se les puede
dar prioridad. Así, el paso 1530 puede ser utilizado para establecer
una programación de entregas, en la que los datos del tipo "A"
se entregan inmediatamente, mientras que los datos del tipo
"B" se pueden entregar en un momento posterior.
Se hace referencia ahora a la figura 16. Cuando
un proveedor 110 de contenidos se registra en un proxy 410 de
empuje, se efectúan varios pasos. Un primer paso 1610 incluye el
análisis de los ajustes del cliente requeridos para el
almacenamiento y distribución de los contenidos. Esto se puede
utilizar, por ejemplo, para anunciar servicios con el fin de
identificar clientes 510 de empuje en dispositivos capaces de
consumir contenidos del proveedor 110 de contenidos.
Un segundo paso 1620 permite que el proxy 410 de
empuje establezca el entorno, incluyendo el almacenamiento del
proxy, las opciones de distribución, las opciones de transformación,
entre otras cosas.
En el paso 1630, el proxy 410 de empuje puede
comprobar si la aplicación está ya registrada para obtener
contenidos desde el proveedor 110 de contenidos. Si éste es el
caso, la aplicación está lista para recibir contenidos y se
establece una notificación desde el proxy 410 de empuje al proveedor
110 de contenidos indicando que se ha establecido el canal de
distribución y que la aplicación está lista para que se envíe el
contenido.
El paso 1630 puede tener lugar, por ejemplo, si
una aplicación está pre-instalada en un dispositivo
antes de que el proveedor 110 de contenidos se ponga en línea. Así,
la aplicación está esperando que el proveedor 110 de contenidos
esté disponible o que la aplicación sea del tipo genérico (por
ejemplo, un navegador o un Visor de RSS) y sea capaz de consumir la
información desde múltiples proveedores de contenidos. En una
condición de ajuste alternativa, si el proveedor 110 de contenidos
está disponible antes de que la aplicación esté instalada, el paso
1530 de notificación de la figura 15 se puede utilizar para iniciar
el flujo del comienzo del contenido desde el proveedor 110 de
contenidos a una aplicación 150 del cliente.
Como podrá apreciarse con referencia a la figura
16, los ajustes del cliente pueden incluir cierta información, tal
como el tamaño de almacenamiento disponible utilizado para efectuar
la partición del contenido, el tamaño de la cola utilizada para el
control del flujo, la programación de la entrega incluyendo un
intervalo de empuje, si el cliente está recuperando información
desde el proxy, crear un modo de pseudo-empuje,
opciones de adaptación tales como el tamaño de la pantalla de un
dispositivo móvil, entre otras cosas.
Como se podrá apreciar también, los catálogos de
servicios pueden diferir para clientes diferentes. Por ejemplo,
ciertos clientes pueden ser capaces de utilizar más datos, tener un
tamaño de pantalla diferente u otras condiciones que hacen al
cliente más adecuado para un proveedor 110 de contenidos que un
dispositivo que no puede gestionar esta cantidad de información, o
tiene un tamaño de pantalla menor, etc. Así, el proxy 410 de empuje
puede crear un catálogo de servicios para aplicaciones específicas
del cliente, basándose en el conocimiento de estas aplicaciones del
cliente, y solamente aquellos dispositivos que tienen instalada esa
aplicación 150 del cliente, pueden recibir información concerniente
al proveedor de contenidos.
Como podrá apreciarse también, en algunos casos
la aplicación puede ser instalada basándose en un proveedor de
servicios y en un proveedor de contenidos sin intervención del
usuario. Por ejemplo, si el proveedor 110 de contenidos se registra
en el proxy 410 de empuje, un usuario de un dispositivo móvil puede
tener una obligación contractual para aceptar una cierta
aplicación. Así, el proxy 410 de empuje podría notificar al cliente
510 de empuje que está listo para instalar una aplicación y empujar
la aplicación al cliente 510 de empuje. Esto podría incluir, por
ejemplo, un usuario que ha acordado recibir un cierto número de
anuncios cada mes, con el fin de obtener una tarifa preferente en
su plan de móviles. El proveedor 110 de contenidos podría ser un
proveedor de anuncios y el proxy 410 de empuje podría por tanto
empujar una aplicación de presentación de anuncios hacia el cliente
510 de empuje, que podría ser servida por un instalador de
aplicaciones registrado en el cliente 410 de empuje, haciendo así
que el proveedor 110 de contenidos y el proveedor 120 de servicios
dirijan totalmente el proceso.
Lo que antecede proporciona por tanto un modelo
de registro de aplicaciones auxiliares (plug-in) en
un marco de empuje en el que cada aplicación o proveedor de
contenidos se registra y proporciona un manifiesto de aplicaciones
o un manifiesto de servicios, respectivamente. El manifiesto de
aplicaciones o el manifiesto de servicios se utilizan para
establecer metadatos del canal en el proxy 410 de empuje y en el
cliente 510 de empuje, ya sea durante el registro o posteriormente.
De ahí en adelante, cuando se registra una aplicación 150 y se
registra un proveedor 110 de servicios, el contenido puede empezar
a afluir entre la aplicación 150 y el proveedor 110 de
contenidos.
Con referencia a las figuras 4 y 5, los
metadatos del canal se almacenan en un repositorio 470 y 570 de
metadatos del canal. Sin embargo, también es ventajoso almacenar
metadatos dinámicos en diversos elementos de proceso dentro de la
arquitectura 100, si se repiten los metadatos dinámicos. Como podrá
apreciarse, esto ahorrará proceso en el proxy 410 de empuje, ya que
el extractor 450 de metadatos actuales no necesita extraer los
mismos metadatos repetidamente. Además, el proceso de diversos
módulos, tal como el módulo 466 o 566 de caducidad de contenidos y
de sustitución, no necesita ser actualizado para cada parte del
contenido que se traspasa. Como el proxy 410 de empuje podría estar
trabajando con un número mayor de clientes 510 de empuje, este
ahorro de proceso para cada mensaje de contenidos podría ser
significativo. Además, se podría ahorrar anchura de banda al no
tener que pasar los metadatos por una línea fija entre el proveedor
110 de contenidos y el proxy 410 de empuje, o por el aire entre el
proxy 410 de empuje y el cliente 510 de empuje.
Se hace referencia ahora a la figura 17. La
figura 17 ilustra un ejemplo de flujo en tiempo de ejecución, donde
se almacena la última versión de los metadatos por medio del
elemento de proceso.
Como puede observarse en la figura 17, el
proveedor 110 de contenidos proporciona una envoltura de contenidos
que incluye el contenido [C_{1} + M(p,c,a)_{1}].
Esto significa que se está enviando una primera carga útil de
contenidos junto con metadatos que incluyen metadatos del proxy,
metadatos del cliente y metadatos de la aplicación. Esto se envía
en el paso 1710.
En el paso 1712, el proxy 410 de empuje utiliza
metadatos del proxy, como se ilustra con la frase "utilizar
M(p)_{1}". Además, en el paso 1714, el contenido
más los metadatos que incluyen los metadatos del cliente y los
metadatos de la aplicación son traspasados al cliente 510 de
empuje.
En el paso 1716, el cliente 510 de empuje
utiliza los metadatos del cliente y además, en el paso 1718, pasa
la carga útil del contenido a la aplicación 150 del cliente. La
aplicación 150 del cliente utiliza, en el paso 1720, los metadatos
de la aplicación y además consume la carga útil del contenido.
Como se observa en el paso 1722, la carga útil
de un segundo contenido, designado por C_{2}, tiene los mismos
metadatos que la carga útil del primer contenido. Debido a que cada
elemento de proceso, es decir, el proxy 410 de empuje, el cliente
510 de empuje y la aplicación 150 del cliente, pusieron en caché los
metadatos del proveedor 110 de contenidos, los metadatos no
necesitan ser traspasados nuevamente, sino que en lugar de eso ya
residen en el elemento de proceso.
De ahí en adelante, en el paso 1724, el proxy
140 de empuje utiliza los metadatos que han sido puestos previamente
en caché para el proxy 410 de empuje. De forma similar, en los
pasos 1726 y 1728, el cliente 510 de empuje utiliza los metadatos
del cliente y la aplicación 150 del cliente utiliza los metadatos de
la aplicación, respectivamente. El contenido se pasa, sin los
metadatos, en los pasos 1725 y 1727.
Como se ilustra en el paso 1740, el contenido
puede tener nuevos metadatos para el cliente 510 de empuje y para
la aplicación 150 del cliente, pero puede mantener los antiguos
metadatos para el proxy 410 de empuje. En este caso, los metadatos
que se pasan en el paso 1740 incluyen solamente metadatos del
cliente y metadatos de la aplicación. En el paso 1742, el proxy 410
de empuje utiliza los metadatos del proxy puestos en caché y pasa
la carga útil del contenido junto con los nuevos metadatos del
cliente y metadatos de la aplicación en el paso 1744.
En el paso 1746, el cliente 510 de empuje
utiliza los nuevos metadatos del cliente que fueron pasados a él, y
pasa además la carga útil del contenido y los metadatos de la
aplicación en el paso 1748.
En el paso 1750, la aplicación del cliente
utiliza los nuevos metadatos de la aplicación y además consume la
carga útil del contenido.
Como podrá apreciar un experto en la técnica,
podrían existir diversas configuraciones cuyos metadatos
concernientes hayan cambiado y cuyos metadatos permanezcan
inalterados, y solamente se pasan los metadatos que han cambiado al
elemento de proceso que lo requiera. Como apreciarán los expertos en
la técnica, el elemento de proceso, si no recibe metadatos nuevos,
vuelve a los metadatos en caché que han sido almacenados y utiliza
esto en la carga útil del contenido.
En un modo de realización alternativo adicional,
se pueden hacer también cambios incrementales en los metadatos. Por
ejemplo, en el paso 1760, se puede pasar la carga útil de un nuevo
contenido junto con una versión delta de los metadatos, al proxy
410 de servicio. El delta de los metadatos del proxy puede incluir
una diferencia entre los metadatos del proxy previamente pasados y
los metadatos actuales con los que debe ser procesado el contenido.
El proxy 410 de empuje compone los metadatos sumando los metadatos
anteriores con el delta y utilizando después esto para procesar la
carga útil del contenido en el paso 1762. De ahí en adelante, como
no ha habido cambios, en el paso 1764 la carga útil del contenido es
enviada por sí misma y en el paso 1766 el cliente 510 de empuje
utiliza los metadatos del cliente puestos previamente en caché.
El cliente de empuje pasa entonces la carga útil
del contenido en el paso 1768 a la aplicación 150 del cliente, que
utiliza los metadatos anteriores del lugar de la caché en la carga
útil del contenido en el paso 1770, y después consume la carga útil
del contenido.
Un ejemplo de dónde pueden utilizarse los datos
incrementales es una situación en la que un proveedor de contenidos
dice al proxy que de los campos existentes dentro de la carga útil
del contenido, 30 de ellos deben ser extraídos para enviarlos a la
aplicación 150 del cliente. En una transacción posterior, se puede
estimar como necesario que el proveedor 110 de contenidos pase dos
campos adicionales que son importantes para esa parte de la carga
útil del contenido, hacia la aplicación 150 del cliente. El
proveedor de contenidos podría, por tanto, utilizando un cambio
incremental, decirle al proxy de empuje que extraiga dos campos
adicionales y los añada a los 30 campos que fueron extraídos
previamente. Como solamente se tiene que pasar el delta, es decir,
los dos campos adicionales, el tiempo de proceso para extraer los
metadatos en el proxy 410 se reduce, optimizando así el
proceso.
Como podrá apreciarse también, los metadatos
pueden venir de distintas maneras. Podrían ser compilados por
ejemplo en código nativo o código intérprete, tal como el Java o el
C#. Los metadatos pueden ser también un fichero de
datos/propiedades que indica el uso de ciertas propiedades. En otro
modo de realización alternativo, puede ser un contenido binario,
por ejemplo una transformación tal como una transformación XSLT
sobre un documento
XML.
XML.
Lo que antecede puede ser utilizado para que
diversas aplicaciones proporcionen inteligencia al contenido que se
transfiere a una aplicación específica del cliente. También puede
abastecer a los proveedores de contenidos enriquecedores que pueden
proporcionar contenidos para diversas aplicaciones, basándose
meramente en los metadatos que proporcionan con sus datos. Esto
puede ser ilustrado a modo de ejemplo en la figura 18.
Un proveedor 110 de contenidos podría, por
ejemplo, ser un vendedor de libros en línea. Una aplicación puede
registrarse en el vendedor de libros en línea para indicarle que
desea ser informada de nuevas publicaciones de un género
específico. Esto podría tener lugar sobre una base diaria o semanal
o mensual.
El proveedor 110 de contenidos, por ejemplo,
sobre una base semanal, enviará una envoltura 1810 de contenidos
que tiene una lista 1812 de libros, al proxy 410 de empuje. También
puede enviar metadatos 1814 de una transformada que pueden ser, por
ejemplo, un enlace URL para transformar el contenido específico
basado en la aplicación que lo recibe.
En un modo de realización, la lista 1812 de
libros podría incluir numerosos libros, descripciones de cada
libro, incluyendo el autor y una sinopsis del libro. El fichero
podría tener, por ejemplo, un tamaño de 100 KB.
El proxy 410 de empuje puede recibir este
fichero grande y puede darse cuenta, basándose en la aplicación del
cliente a la que se da servicio, que necesita hacerse una
transformación al fichero grande de contenidos, con el fin de
acomodar mejor al cliente, que puede ser capaz de recibir solamente,
por ejemplo, 10 kilobytes de información. La transformación que se
pasa como metadatos del proxy puede ser aplicada, por tanto, a la
lista de libros para reducir la lista de libros a un documento
modificado 1820 de 10 KB. Esto puede hacerse, por ejemplo,
eliminando la sinopsis, clasificando los libros e incluyendo
solamente los 50 mejores, u otras transformaciones que serían
evidentes para los expertos en la técnica.
Una vez que la transformación se ha completado,
el documento modificado 1820 es enviado después al cliente 510 de
empuje.
Además, el almacenamiento 452 de mensajes de
recuperación diferida, como se observa en la figura 4, puede ser
utilizado para almacenar el contenido extra que fue extraído en el
proceso de transformación.
La ventaja de lo anterior es que el vendedor de
libros puede tener un sitio y enviar una lista a todos sus
clientes. Como varios clientes no serán clientes inalámbricos de
móviles, el fichero de 100 KB puede ser apropiado para estos
clientes. Proporcionando además los metadatos de la transformación,
el vendedor de libros puede tener una lista que envía a cada uno.
Como apreciarán los expertos en la técnica, las tecnologías de web
más actuales requieren un sitio web independiente para un cliente
móvil, y esto se supera con la solución anterior.
Lo que antecede se presta también a un modelo
compartido y se hace referencia ahora a la figura 19.
Como apreciarán los expertos en la técnica, un
dispositivo móvil puede no desear recibir grandes cantidades de
datos cuando las condiciones de la red no son óptimas para recibir
grandes cantidades de datos. Además, los operadores de red pueden
desear evitar el envío de grandes cantidades de datos durante los
periodos de pico de uso de anchura de banda, con el fin de extender
el tráfico de la red más uniformemente con el tiempo. Esto se puede
conseguir utilizando un modelo de empujar/tirar, como se ilustra en
la figura 19.
Como se ha descrito con referencia a la figura 4
anterior, puede proporcionarse un contenido que incluya más
información que la que el usuario necesita actualmente. Por ejemplo,
si el usuario solicita información de situación para restaurantes
dentro de su zona, un proveedor de servicios puede desear añadir
publicidad por ejemplo sobre otros servicios disponibles en la
zona. Sin embargo, el proveedor de servicios puede no desear
empujar este contenido adicional inmediatamente al usuario, sino
proporcionar en lugar de eso un texto básico tal como un titular o
una tabla de contenidos que muestre el contenido adicional.
En otras situaciones, el contenido puede ser
demasiado grande para ser enviado al usuario, y el usuario solamente
puede recibir la primera parte del contenido, y el resto del
contenido se almacena en un almacenamiento 452 de mensajes de
recuperación diferida.
De ahí en adelante, el contenido almacenado
puede ser transferido al cliente 510 de empuje, ya sea por el proxy
410 de empuje o cuando lo pide el cliente 510 de empuje.
El cliente 510 de empuje incluye un supervisor
1910 de estado de la red, que puede supervisar el estado de la red.
El cliente 510 de empuje puede desear recibir solamente datos extra
en ciertas condiciones. Por ejemplo, en un dispositivo móvil
híbrido que tiene un WiFi y una opción celular, es más económico
proporcionar datos en la conexión WiFi, y por tanto el supervisor
1910 de estado de la red podría esperar hasta que el cliente 510 de
empuje se conecte a una red WiFi antes de obtener el contenido
diferido. Alternativamente, el supervisor de estado de la red
podría comprobar si el cliente está en itinerancia en una región
extrajera o está conectado a la red doméstica, con el fin de
minimizar los cargos de itinerancia. El supervisor de estado de la
red puede comprobar también si se ha establecido un canal de datos
exclusivo para el dispositivo. Un experto en la técnica se dará
cuenta de que el supervisor 1910 de estado de la red podría
comprobar también varias otras condiciones previas en la red, antes
de que se transfieran los datos diferidos solicitados al cliente 510
de empuje.
Una red inalámbrica 130 podría proporcionar
también información a uno o a los dos del cliente 510 de empuje y
del proxy 410 de empuje, concerniente a los costes de la
distribución de los datos. Como podrán apreciar los expertos en la
técnica, tienen lugar varios periodos de pico en la entrega de
contenidos. En el caso de información del tráfico, los periodos de
pico pueden ser al comienzo y al final de la jornada de trabajo,
cuando la gente va y vuelve del trabajo. Para las cotizaciones de
bolsa, el periodo de pico puede ser durante el tiempo en el que
está abierto el mercado. Existirán otros periodos de pico. Con el
fin de promediar el tráfico de datos, puede ser deseable que la red
cargue distintas tarifas basándose en la utilización actual de
datos en la red. Así, durante los periodos de pico, se puede cargar
una tarifa más alta que en un periodo fuera del pico, tal como por
la noche. La red inalámbrica 130 proporcionar por tanto
notificaciones de coste de la entrega a un gestor 552 de
recuperación diferida en un cliente 510 de empuje y al programador
454 de empuje en el proxy 410 de empuje.
En un modo de realización, los datos del
proveedor 110 de contenidos y transferidos al proxy 410 de empuje,
pueden ser clasificados basándose en su importancia para el cliente.
Cierta información puede ser designada a través de metadatos para
ser entregada inmediatamente. Otra información puede ser designada
para entregarse cuando el coste de la red es inferior que un primer
valor (por ejemplo, 10 céntimos por megabyte), y otros datos pueden
ser designados para que se entreguen cuando los costes de la red
caen por debajo de un segundo valor (por ejemplo, 5 céntimos por
megabyte). Por tanto, el programador 454 de empuje considera los
datos que están almacenados en el almacenamiento 452 de mensajes de
recuperación diferida e instruye al agente 444 de empuje para que
pase los datos diferidos al agente 544 de empuje en el cliente 510
de empuje.
Alternativamente, el gestor 552 de recuperación
diferida podría supervisar también las condiciones de la red como
se han enviado desde la red inalámbrica 130, y si la velocidad de
los datos está por debajo de una cierta velocidad, puede preguntar
al agente 554 que tira del contenido que tire del contenido del
almacenamiento 452 de mensajes de recuperación diferida.
Alternativamente, el gestor 552 de recuperación
diferida podría ver que el estado de la red es favorable para tirar
de grandes cantidades de datos, tal como si el dispositivo móvil se
ha conectado con una red WiFi, y pide al agente 554 que tira del
contenido, que tire de los datos del almacenamiento 452 de mensajes
de recuperación diferida.
Como podrá apreciarse también, un usuario
siempre puede solicitar que se tire del contenido. Por tanto, la
petición 1940 del usuario podría ser utilizada también para hacer
que el agente 554 que tira del contenido tire de los datos desde el
almacenamiento 452 de mensajes de recuperación diferida.
Las reglas almacenadas en el programador 454 de
empuje y en el gestor 552 de recuperación diferida podrían ser
metadatos estáticos basados en una clasificación del contenido. Las
reglas podrían estar basadas también en metadatos dinámicos para
los datos particulares que han sido transferidos. En este caso, el
proveedor 110 de contenidos ha clasificado los datos.
Se hace referencia ahora a la figura 20. Como
podrá apreciarse por los expertos en la técnica, los datos pueden
ser de una de las dos formas, lineales o no lineales. Los datos
lineales podrían ser, por ejemplo, series o cadenas o contenidos
que fluyen de una manera lineal. Por el contrario, los datos no
lineales son datos que no están relacionados linealmente entre sí y
pueden incluir dependencias complejas con mapas o enlaces de
contenidos.
Para el contenido lineal, la fragmentación
implica meramente la descomposición de los datos en varios
componentes, basándose en una progresión lineal. Los datos son
repartidos en varios segmentos y los segmentos son entregados al
cliente 410 de empuje. Como se indica en la figura 20, el procesador
2010 de fragmentación interactúa con el contenido 2012 y decide que
el contenido puede ser analizado con progresión lineal. El
procesador 2010 de fragmentación divide a continuación los datos en
segmentos 2014, 2016 y 2018 en el ejemplo de la figura 20 y, como
se ilustra en la figura 20, transfiere el primer segmento 2014
mientras que difiere el paso del segundo y tercer segmentos 2016 y
2018, respectivamente.
El módulo 2030 de gestión del cursor mantiene la
pista de qué segmento ha sido entregado, y entrega el siguiente
segmento en el orden pertinente.
Haciendo referencia a la figura 21, el contenido
no lineal necesita ser repartido de una manera más inteligente.
Además, en el otro extremo, con el fin de reconstituir los
segmentos, se requieren los metadatos.
Un procesador 2110 analiza el contenido
basándose en un análisis basado en metadatos. Esto podría incluir
mantener ciertos segmentos o elementos de datos conjuntamente, si se
requiere lógicamente. El procesador 2110 de fragmentación analiza
el contenido 2112 y divide el contenido en segmentos, basándose en
reglas lógicas. Cada segmento incluye el contenido mas los
metadatos que incluyen, por ejemplo, las dependencias, los mapas y
las reglas de navegación para cada segmento.
Una vez dividido, se envía un primer segmento
2114 al cliente 510 de empuje y se difiere el paso del resto de los
segmentos 2116 y 2118 como se ilustra en la figura 21. El bloque
2130 de navegación de segmentos se encarga de qué segmento ha de
enviarse a continuación. Como será apreciado por los expertos en la
técnica, el primer segmento 2114 incluye una parte de datos y una
parte de metadatos. La parte 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
contenidos cómo reconstituir el contenido. La parte de datos del
primer segmento 2114 puede incluir tanto el contenido como los
metadatos asociados con el canal o con el contenido.
El bloque 2130 de navegación de segmentos está
adaptado para procesar cómo un usuario viaja por los datos. Por
ejemplo, si los datos tienen forma de árbol y el usuario baja una
primera rama del árbol, el bloque 2130 de navegación de segmentos
puede pasar al cliente 410 de empuje otras ramas del árbol que
pueden ser alcanzadas desde el elemento al que ha navegado el
usuario.
Por ejemplo, un árbol puede incluir una base de
datos de empleados que tiene nombres de empleados junto con una
estructura para la corporación. Basándose en la figura 21, si el
usuario navega en un departamento específico de la organización, el
bloque 2130 de navegación de la segmentación podría reenviar
fragmentos de grupos a los grupos que están dentro del
departamento. Si el usuario navega en un grupo específico dentro del
departamento, el bloque 2130 de navegación de la segmentación
podría pasar fragmentos de información sobre los empleados que
están dentro del grupo.
Lo que antecede requiere, por tanto, que los
datos sean divididos en componentes lógicos. Se asignan
identificadores a todos los tipos y contenidos, y se crea
información estructural que pasa la información con el texto
básico.
Lo que antecede proporciona por tanto una
arquitectura para la distribución dinámica de contenidos que puede
ser utilizada con sistemas genéricos, donde las aplicaciones y el
contenido pueden añadirse sin cambiar la estructura del sistema. El
contenido puede ser hecho a la medida para adaptarse a la aplicación
que lo recibe, y puede ser fragmentado de acuerdo con lo
anterior.
Como podrá apreciarse, el cliente de empuje y
las aplicaciones del cliente pueden residir en cualquier dispositivo
móvil. Se describe a continuación un ejemplo de dispositivo móvil,
con referencia a la figura 22. Esto no significa que sea
limitativo, sino que se proporciona para fines ilustrativos.
La figura 22 es un diagrama de bloques que
ilustra una estación móvil apta para ser utilizada con modos de
realización preferidos del aparato y método de la presente
solicitud. La estación móvil 2200 es preferiblemente un dispositivo
de comunicaciones inalámbricas bidireccionales que tiene al menos
capacidades de voz y de datos. La estación móvil 2200 tiene
preferiblemente la capacidad de comunicarse con otros sistemas
informáticos de Internet. Dependiendo de la funcionalidad exacta
proporcionada, el dispositivo inalámbrico puede ser denominado como
dispositivo de mensajería de datos, un buscapersonas bidireccional,
un dispositivo inalámbrico para correo electrónico, un teléfono
celular con capacidades de mensajería, un aparato inalámbrico para
Internet, o un dispositivo de comunicaciones de datos, como
ejemplos.
Aunque la estación móvil está capacitada para la
comunicación bidireccional, incorporará un subsistema 2211 de
comunicaciones, incluyendo un receptor 2212 y un transmisor 2214,
así como componentes asociados, tales como uno o más,
preferiblemente incorporados o internos, elementos 2216 y 2218 de
antena, osciladores locales (LO) 2213, y un módulo de proceso tal
como un procesador digital 2220 de señales (DSP). Como será evidente
para los expertos en el campo de las comunicaciones, el diseño
particular del subsistema 2211 de comunicaciones dependerá de la
red de comunicaciones en la cual está destinado el dispositivo para
funcionar.
Los requisitos de acceso a la red variarán
también dependiendo del tipo de red 2219. En algunas redes CDMA, el
acceso está asociado con un abonado o usuario de la estación móvil
2200. Una estación móvil CDMA puede requerir un módulo extraíble de
identidad del usuario (RUIM) o una tarjeta de un modulo de identidad
del abonado (SIM), con el fin de funcionar en una red CDMA. El
interfaz SIM/RUIM 2244 es normalmente similar a una ranura de
tarjetas en la cual se puede insertar una tarjeta SIM/RUIM y ser
expulsada como un disquete o una tarjeta PCMCIA. La tarjeta
SIM/RUIM puede tener aproximadamente 64K de memoria y contener
muchas configuraciones 2251 de claves, y otras informaciones 2253
tal como la identificación, e información relacionada con el
abonado.
Cuando se han completado el registro requerido
de la red o los procedimientos de activación, la estación móvil
2200 puede enviar y recibir señales de comunicaciones por la red
2219. Como se ilustra en la figura 22, la red 2219 puede consistir
en múltiples estaciones base que se comunican con el dispositivo
móvil. Por ejemplo, en un sistema híbrido CDMA 1xEVDO, una estación
base CDMA y una estación base EVDO se comunican con la estación
móvil y la estación móvil está conectada a ambas simultáneamente.
Las estaciones base EVDO y CDMA 1x utilizan distintas ranuras de
búsqueda para comunicarse con el dispositivo móvil.
Las señales recibidas por la antena 2216 a
través de la red 2219 de comunicaciones son introducidas en el
receptor 2212, que puede realizar funciones comunes del receptor,
tales como la amplificación de señales, la conversión de
frecuencias hacia abajo, el filtrado, la selección de canales y
similares, y en el ejemplo de sistema ilustrado en la figura 22, la
conversión de analógico a digital (A/D). La conversión A/D de una
señal recibida permite funciones de comunicaciones más complejas,
tales como la desmodulación y la descodificación a realizar en el
DSP 2220. De una manera similar, se procesan las señales a
transmitir, incluyendo la modulación y codificación por ejemplo,
por el DSP 2220 e introducidas en el transmisor 2214 para la
conversión de digital a analógico, la conversión de frecuencias
hacia arriba, el filtrado, la amplificación y la transmisión por la
red 2219 de comunicaciones, a través de la antena 2218. El DSP 2220
no solamente procesa las señales de comunicaciones, sino que
también proporciona el control del receptor y del transmisor. Por
ejemplo, las ganancias aplicadas a las señales de comunicaciones en
el receptor 2212 y en el transmisor 2214 pueden ser controladas de
manera adaptable por medio de algoritmos de control automático de
ganancia, implementados en el DSP 2220.
La estación móvil 2200 incluye, preferiblemente,
un microprocesador 2238 que controla el funcionamiento global del
dispositivo. Las funciones de comunicaciones, incluyendo al menos
comunicaciones de datos y de voz, se realizan a través del
subsistema 2211 de comunicaciones. El microprocesador 2238
interactúa también con subsistemas de dispositivos adicionales,
tales como la pantalla 2222, la memoria flash 2224, la memoria de
acceso aleatorio (RAM) 2226, los subsistemas auxiliares 2228 de
entrada/salida (E/S), la puerta serie 2230, 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 cualquier otro subsistema de
dispositivos designados en general como 2242. La puerta serie 2230
podría incluir un puerto USB u otro puerto conocido para los
expertos en la técnica.
Algunos de los subsistemas ilustrados en la
figura 22 realizan funciones relacionadas con las comunicaciones,
mientras que otros subsistemas pueden proporcionar funciones
"residentes" o sobre el dispositivo. De manera notable,
algunos subsistemas, tales como el teclado2232 y la pantalla 2222,
por ejemplo, puede ser utilizado tanto para la funciones relativas
a las comunicaciones, tal como la introducción de un mensaje de
texto para la transmisión por una red de comunicaciones, como para
funciones residentes en el dispositivo, tal como una calculadora o
lista de tareas.
El software del sistema operativo utilizado por
el microprocesador 2238 se almacena preferiblemente en un
almacenamiento persistente, tal como una memoria flash 2224, que
puede ser en su lugar una memoria de sólo lectura (ROM) o elemento
de almacenamiento similar (no ilustrado). Los expertos en la técnica
apreciarán que el sistema operativo, las aplicaciones específicas
del dispositivo, o partes de las mismas, pueden ser cargadas
temporalmente en una memoria volátil, tal como la RAM 2226. Las
señales de comunicaciones recibidas pueden ser almacenadas también
en la RAM 2226.
Como está ilustrado, la memoria flash 2224 puede
ser segregada en distintas zonas para los programas informáticos
2258 y como almacenamiento 2250, 2252, 2254 y 2256 de datos de
programa. Estos distintos tipos de almacenamiento indican que cada
programa puede asignar una parte de la memoria flash 2224 para sus
propios requisitos de almacenamiento de datos. El microprocesador
2238, además de las funciones de su sistema operativo, permite
preferiblemente la ejecución de aplicaciones de software en la
estación móvil. Un conjunto predeterminado de aplicaciones, que
controlan las operaciones básicas, incluyendo al menos aplicaciones
de comunicaciones de datos y de voz, por ejemplo, se instalarán
normalmente en la estación móvil 2200 durante la fabricación.
Posteriormente o dinámicamente, podrían instalarse otras
aplicaciones.
Una aplicación preferida de software puede ser
la aplicación de un gestor de información personal (PIM), que tiene
la capacidad de organizar y gestionar elementos de datos relativos
al usuario de la estación móvil, tal como, pero sin limitarse a
ello, correo electrónico, eventos programados, correos de voz, citas
y lista de tareas. Naturalmente, en una estación móvil habría
disponibles uno o más almacenamientos de memoria para facilitar el
almacenamiento de elementos de datos PIM. Tal aplicación PIM tendría
preferiblemente la capacidad de enviar y recibir elementos de
datos, a través de la red inalámbrica 2219. En un modo de
realización preferido, los elementos de datos PIM se integran
transparentemente, se sincronizan y se actualizan, a través de la
red inalámbrica 2219, con los correspondientes elementos de datos
del usuario de la estación móvil, almacenados o asociados con el
sistema del ordenador central. También pueden cargarse otras
aplicaciones en la estación móvil 2200, a través de la red 2219, un
subsistema auxiliar 2228 de E/S, un puerto serie 2230, un subsistema
2240 de comunicaciones de corto alcance o cualquier otro subsistema
adecuado 2242, e instalado por un usuario en la RAM 2226 o,
preferiblemente, en un almacenamiento no volátil (no ilustrado) para
la ejecución por medio del microprocesador 2238. Tal flexibilidad
en la instalación de aplicaciones aumenta la funcionalidad del
dispositivo y puede proporcionar funciones mejoradas en el
dispositivo, funciones relativas a la comunicación, o ambas cosas.
Por ejemplo, las aplicaciones de comunicaciones seguras pueden
permitir realizar funciones de comercio electrónico y otras
transacciones financieras de ese tipo, utilizando la estación móvil
2200.
En un modo de comunicaciones de datos, una señal
recibida, tal como un mensaje de texto o descarga de una página
web, será procesada por el subsistema 2211 de comunicaciones e
introducida en el microprocesador 2238, que preferiblemente
continúa el proceso de la señal recibida para entregarla a la salida
en la pantalla 2222, o alternativamente a un dispositivo auxiliar
2228 de E/S. Un cliente 2260 de empuje, que podría ser equivalente
a los clientes 140 y 510 de empuje, podría procesar también la
entrada.
Un usuario de la estación móvil 2200 puede
componer también elementos de datos, tales como mensajes de correo
electrónico, por ejemplo, utilizando 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 auxiliar 2228 de E/S. Tales
elementos compuestos pueden ser transmitidos después por una red de
comunicaciones a través del subsistema 2211 de comunicaciones.
Para las comunicaciones de voz, el
funcionamiento global de la estación móvil 2200 es similar, excepto
que las señales recibidas serían entregadas, preferiblemente, a un
altavoz 2234, y las señales para la transmisión serían generadas
por un micrófono 2236. Los subsistemas alternativos de E/S de voz o
de audio, tales como un subsistema de grabación de mensajes de voz,
pueden ser implementados también en la estación móvil 2200. Aunque
la salida de la señal de voz o de audio se obtiene principalmente a
través del altavoz 2234, también se puede utilizar la pantalla 2222
para proporcionar una indicación de la identidad de una parte que
llama, la duración de una llamada de voz, u otra información
relativa a la llamada de voz, por ejemplo.
El puerto serie 2230 de la figura 22, se
implementaría normalmente en una estación móvil del tipo de
asistente digital personal (PDA), para lo cual puede ser deseable
la sincronización con el ordenador de mesa (no ilustrado) de un
usuario, pero es un componente de dispositivo opcional. Tal puerto
2230 permitiría al usuario fijar preferencias por medio de un
dispositivo externo o aplicación de software, y ampliaría las
capacidades de la estación móvil 2200 proporcionando información o
descargas de software a la estación móvil 2200, aparte de las que
obtiene a través de una red inalámbrica de comunicaciones. El camino
alternativo de descargas puede ser utilizado, por ejemplo, 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
así la comunicación segura del dispositivo. Como podrá apreciarse
por los expertos en la técnica, el puerto serie 2230 puede ser
utilizado también para conectar el dispositivo móvil a un
ordenador, para actuar como un módem.
Otros subsistemas 2240 de comunicaciones, tales
como un subsistema de comunicaciones de corto alcance, es un
componente adicional opcional que puede proporcionar la comunicación
entre la estación móvil 2200 y distintos sistemas o dispositivos,
que no necesitan 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
comunicaciones por Bluetooth®, para proporcionar la comunicación
con sistemas o dispositivos habilitados de manera similar.
Los modos de realización descritos en esta
memoria 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 construir y utilizar los modos de realización con
elementos alternativos, que corresponden de igual forma a los
elementos de las técnicas de esta solicitud. El alcance pretendido
de las técnicas de esta solicitud incluye por tanto otras
estructuras, sistemas o métodos que no difieren de las técnicas de
esta solicitud, como se describen en esta memoria, y además incluye
otras estructuras, sistemas o métodos con diferencias
insustanciales de las técnicas de esta solicitud, como se describen
es esta memoria.
Claims (24)
-
\global\parskip0.900000\baselineskip
1. Un método para añadir inteligencia de proceso a la carga útil de contenidos en una arquitectura de distribución dinámica de contenidos, que tiene al menos un primer elemento de proceso y un segundo elemento de proceso, comprendiendo el método los pasos de:crear una primera envoltura (620; 614), comprendiendo dicha primera envoltura la carga útil (632) de los contenidos y metadatos (630; 622) del segundo elemento de proceso, estando adaptados dichos metadatos del segundo elemento de proceso para ejecutarse en dicho segundo elemento de proceso; yformar una segunda envoltura (614; 610), conteniendo dicha segunda envoltura a dicha primera envoltura (620, 614) y metadatos (622; 612) del primer elemento de proceso, adaptados para ejecutarse en dicho primer elemento de proceso. - 2. El método de la reivindicación 1, en el que dichos metadatos (622; 612) del primer elemento de proceso y dichos metadatos (630) del segundo elemento de proceso son específicos de la carga útil (632) del contenido.
- 3. El método de la reivindicación 1 o la reivindicación 2, que comprende además el paso de propagar los metadatos relativos a un canal para dicha carga útil (632) del contenido, a dicho primer elemento de proceso y a dicho segundo elemento de proceso.
- 4. El método de la reivindicación 1 o la reivindicación 2, que comprende además el paso de proporcionar a dicho primer elemento de proceso y a dicho segundo elemento de proceso los metadatos relativos a un canal para dicha carga útil (632) del contenido.
- 5. El método de cualquiera de las reivindicaciones 1 a 4, en el que dicho al menos un primer elemento de proceso y un segundo elemento de proceso comprenden cualquiera entre un proxy de empuje, un cliente de empuje o una aplicación del cliente.
- 6. El método de cualquiera de las reivindicaciones 1 a 5, en el que dicho método comprende además los pasos de:extraer, en dicho primer elemento de proceso, dichos metadatos (622; 612) del primer elemento de proceso;utilizar dichos metadatos (622; 612) del primer elemento de proceso en dicha primera envoltura (620; 614), creando una primera envoltura procesada (620; 614); yentregar dicha primera envoltura procesada (620; 614) a dicho segundo elemento de proceso.
- 7. El método de la reivindicación 6, en cuanto que depende de la reivindicación 2 o la reivindicación 3, que comprende además el paso de, antes de dichos pasos de utilización y entrega, aplicar metadatos relacionados con dicho canal en dicha primera envoltura (620; 614).
- 8. El método de cualquiera de las reivindicaciones 1 a 7, en el que dicho método comprende además, en dicho primer elemento de proceso, añadir metadatos (630; 622) a dicha primera envoltura (620; 614).
- 9. El método de cualquiera de las reivindicaciones 1 a 8, en el que dichos pasos de creación y formación los realiza un proveedor de contenidos.
- 10. El método de cualquiera de las reivindicaciones 1 a 9, que comprende además el paso de creación de una tercera envoltura (610), comprendiendo dicha tercera envoltura a dicha segunda envoltura (614) y metadatos (612) de un tercer elemento de proceso para un tercer elemento de proceso.
- 11. El método de cualquiera de las reivindicaciones 1 a 10, en el que dichos metadatos (622; 612) del primer elemento de proceso comprende cualquiera de los parámetros de proceso, reglas de proceso, un gestor de proceso, un código gestor del proceso, una referencia del gestor de proceso, un enlace a un gestor de proceso, un enlace a un código del gestor de proceso, y/o un enlace a unas reglas del gestor del proceso.
- 12. Una envoltura de contenidos para una arquitectura de distribución dinámica de contenidos, comprendiendo la envoltura de contenidos:una carga útil (632) del contenido;metadatos (630; 622) de proceso del contenido, para un primer elemento de proceso en dicha arquitectura de distribución dinámica de contenidos, donde dichos metadatos (630; 622) de proceso del contenido y dicha carga útil (632) del contenido forman una primera envoltura (620; 614); ysegundos metadatos (622; 612) de proceso del contenido, para un segundo elemento de proceso en la arquitectura de distribución dinámica de contenidos, donde los segundos metadatos (622; 612) de proceso del contenido están anidados en dicha primera envoltura (620; 614), para formar una segunda envoltura (614; 610).
\global\parskip1.000000\baselineskip
- 13. La envoltura de contenidos de la reivindicación 12, donde dicho primer elemento de proceso y dicho segundo elemento de proceso comprenden cualquiera entre un proxy de empuje, un cliente de empuje o una aplicación del cliente.
- 14. La envoltura de contenidos de la reivindicación 12 o la reivindicación 13, donde los segundos metadatos (622) del contenido para el segundo elemento de proceso están configurados para proporcionar instrucciones completas a dicho segundo elemento de proceso.
- 15. La envoltura de contenidos de cualquiera de las reivindicaciones 12 a 14, en la que los metadatos (630) de los contenidos para el primer elemento de proceso están configurados para proporcionar instrucciones completas a dicho primer elemento de proceso.
- 16. La envoltura de contenidos de cualquiera de las reivindicaciones 12 a 15, en la que los metadatos (630) de los contenidos comprenden cualquiera de los parámetros de proceso, reglas de proceso, un gestor de proceso, un código gestor del proceso, una referencia del gestor de proceso, un enlace a un gestor de proceso, un enlace a un código del gestor de proceso, y/o un enlace a unas reglas del gestor del proceso.
- 17. Un método para procesar una envoltura que tiene unos primeros metadatos (622) para un elemento de proceso y unos segundos metadatos (630) y contenidos (632) para elementos de proceso sucesivos, en una arquitectura de distribución dinámica de contenidos, comprendiendo el método los pasos de:extraer, los primeros metadatos (622) del elemento de proceso de la envoltura;utilizar dichos primeros metadatos (622) en dichos segundos metadatos (630) y contenidos (632) para los sucesivos elementos de proceso, creando así una envoltura anidada procesada (620); yentregar la envoltura anidada procesada (620) a uno de los sucesivos elementos de proceso.
- 18. El método de la reivindicación 17, en el que el método comprende además:utilizar metadatos (622) del canal para el contenido en dichos metadatos (630) y contenidos (632) para elementos de proceso sucesivos.
- 19. El método de la reivindicación 18, en el que dichos metadatos del canal son proporcionados o propagados hacia el elemento de proceso, antes de que el elemento de proceso reciba la envoltura.
- 20. El método de cualquiera de las reivindicaciones 17 a 19, en el que el elemento de proceso es uno entre un proxy de empuje y un cliente de empuje.
- 21. El método de cualquiera de las reivindicaciones 17 a 20, en el que dichos metadatos para el elemento de proceso comprenden cualquiera de los parámetros de proceso, reglas de proceso, un gestor de proceso, un código gestor del proceso, una referencia del gestor de proceso, un enlace a un gestor de proceso, un enlace a un código del gestor de proceso, y/o un enlace a unas reglas del gestor del proceso.
- 22. Un sistema para procesar una envoltura que tiene unos primeros metadatos (622) para un elemento de proceso, y unos segundos metadatos (630) y contenidos (632) para elementos de proceso sucesivos en una arquitectura de distribución dinámica de contenidos, comprendiendo el sistema:medios para extraer los primeros metadatos (622) para el elemento de proceso desde la envoltura;medios para utilizar dichos primeros metadatos (622) en dichos segundos metadatos (630) y contenidos para los elementos de proceso sucesivos, creando así una envoltura anidada procesada (620); ymedios para entregar la envoltura anidada procesada (620) a uno de los sucesivos elementos de proceso.
- 23. Un producto de programa informático para añadir inteligencia de proceso a la carga útil de los contenidos en una arquitectura de distribución dinámica de contenidos, que tiene al menos un primer elemento de proceso y un segundo elemento de proceso, comprendiendo el producto de programa informático un medio legible por ordenador que materializa unos medios de código de programa ejecutables por un dispositivo, sistema o aparato informático, para implementar todos los pasos del método de cualquiera de las reivindicaciones 1 a 11.
- 24. Un producto de programa informático para procesar una envoltura que tiene metadatos para un elemento de proceso y metadatos y contenidos para elementos de proceso sucesivos, en una arquitectura de distribución dinámica de contenidos, comprendiendo el producto de programa informático un medio legible por ordenador que materializa unos medios de código de programa ejecutables por un dispositivo, sistema o aparato informático, para implementar todos los pasos del método de cualquiera de las reivindicaciones 17 a 21.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP06113364A EP1853043B1 (en) | 2006-05-02 | 2006-05-02 | Multi-layered enveloped method and system for push content metadata |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2309903T3 true ES2309903T3 (es) | 2008-12-16 |
Family
ID=37075821
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06113364T Active ES2309903T3 (es) | 2006-05-02 | 2006-05-02 | Metodo y sistema de envolturas multicapas para metadatos de contenidos de empuje. |
Country Status (12)
| Country | Link |
|---|---|
| EP (3) | EP1853043B1 (es) |
| JP (2) | JP4603008B2 (es) |
| KR (1) | KR100948545B1 (es) |
| CN (1) | CN101110838B (es) |
| AT (2) | ATE400135T1 (es) |
| AU (1) | AU2007201903B9 (es) |
| BR (1) | BRPI0704532B1 (es) |
| CA (1) | CA2582015C (es) |
| DE (2) | DE602006019778D1 (es) |
| ES (1) | ES2309903T3 (es) |
| HK (1) | HK1110719A1 (es) |
| MX (1) | MX2007005141A (es) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2011517231A (ja) * | 2008-04-14 | 2011-05-26 | トムソン ライセンシング | ライブ制作のためにメタデータをコンテンツに関連付けるための方法および装置 |
| BR112012005704A2 (pt) | 2009-09-14 | 2020-08-25 | Nec Corporation | sistema de comunicação, nó arranjado em uma rede para encaminhar dados, servidor de controle criar matriz de operações de processamento, método de comunicação, dispositivo de armazenamento legível por máquina, programa para criar matriz de operações de processamento |
| KR101425518B1 (ko) * | 2012-12-21 | 2014-08-05 | 주식회사 티모넷 | 휴대용 모바일 환경 하 xml 기반 푸쉬 알람시스템 및 그 방법 |
| US10270839B2 (en) * | 2016-03-29 | 2019-04-23 | Snap Inc. | Content collection navigation and autoforwarding |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000132522A (ja) * | 1998-10-27 | 2000-05-12 | Nippon Telegr & Teleph Corp <Ntt> | 分散オブジェクト通信処理方法、分散オブジェクトシステム、及び分散オブジェクト通信プログラムを記録した記録媒体 |
| JP2001134518A (ja) * | 1999-11-02 | 2001-05-18 | Nec Corp | データ通信装置およびデータ通信システム |
| US20020143791A1 (en) * | 2001-03-19 | 2002-10-03 | Dov Levanon | Content deployment system, method and network |
| KR100456025B1 (ko) * | 2002-04-08 | 2004-11-08 | 한국전자통신연구원 | 다단계 컨텐츠 패키징 처리 장치 및 방법 |
| US7698276B2 (en) * | 2002-06-26 | 2010-04-13 | Microsoft Corporation | Framework for providing a subscription based notification system |
| EP1387533A1 (en) * | 2002-07-29 | 2004-02-04 | Motorola, Inc. | Communication of packet data units over signalling and traffic channels |
| EP1387295A1 (en) * | 2002-08-03 | 2004-02-04 | Deutsche Thomson-Brandt Gmbh | Metadata structure consisting of a multi-layer format |
| US7228357B2 (en) * | 2002-09-23 | 2007-06-05 | Sharp Laboratories Of America, Inc. | System and method for automatic digital document processing |
| KR20060103428A (ko) | 2003-09-17 | 2006-09-29 | 리서치 인 모션 리미티드 | 확장 제공이 가능한 동적 컨텐츠 처리 시스템 및 방법 |
| US20050097168A1 (en) * | 2003-10-31 | 2005-05-05 | Debargha Mukherjee | Communications methods, communications session organizers, communications session participants, articles of manufacture, and communications systems |
| CN100345425C (zh) * | 2004-05-25 | 2007-10-24 | 中国移动通信集团公司 | 从信息系统向移动终端推送信息的方法及系统 |
| EP1762071A1 (en) * | 2004-06-30 | 2007-03-14 | Nokia Corporation | Transfer of data objects |
| US8112531B2 (en) * | 2004-07-14 | 2012-02-07 | Nokia Corporation | Grouping of session objects |
-
2006
- 2006-05-02 EP EP06113364A patent/EP1853043B1/en active Active
- 2006-05-02 AT AT06113364T patent/ATE400135T1/de not_active IP Right Cessation
- 2006-05-02 EP EP08159429A patent/EP1973302B1/en active Active
- 2006-05-02 EP EP10176032.0A patent/EP2267981B1/en active Active
- 2006-05-02 DE DE602006019778T patent/DE602006019778D1/de active Active
- 2006-05-02 AT AT08159429T patent/ATE496474T1/de not_active IP Right Cessation
- 2006-05-02 DE DE602006001641T patent/DE602006001641D1/de active Active
- 2006-05-02 ES ES06113364T patent/ES2309903T3/es active Active
-
2007
- 2007-03-16 CA CA2582015A patent/CA2582015C/en active Active
- 2007-04-20 JP JP2007112401A patent/JP4603008B2/ja active Active
- 2007-04-25 BR BRPI0704532-8 patent/BRPI0704532B1/pt active IP Right Grant
- 2007-04-27 MX MX2007005141A patent/MX2007005141A/es active IP Right Grant
- 2007-04-30 AU AU2007201903A patent/AU2007201903B9/en active Active
- 2007-04-30 KR KR1020070041799A patent/KR100948545B1/ko active IP Right Grant
- 2007-04-30 CN CN2007101023621A patent/CN101110838B/zh active Active
-
2008
- 2008-05-06 HK HK08105067A patent/HK1110719A1/xx unknown
-
2010
- 2010-09-30 JP JP2010223146A patent/JP5183710B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CA2582015C (en) | 2012-10-30 |
| EP1853043A1 (en) | 2007-11-07 |
| ATE496474T1 (de) | 2011-02-15 |
| DE602006019778D1 (de) | 2011-03-03 |
| CN101110838B (zh) | 2011-12-07 |
| ATE400135T1 (de) | 2008-07-15 |
| EP1973302B1 (en) | 2011-01-19 |
| JP5183710B2 (ja) | 2013-04-17 |
| CA2582015A1 (en) | 2007-11-02 |
| JP4603008B2 (ja) | 2010-12-22 |
| JP2007305120A (ja) | 2007-11-22 |
| EP2267981B1 (en) | 2013-06-26 |
| CN101110838A (zh) | 2008-01-23 |
| HK1110719A1 (en) | 2008-07-18 |
| AU2007201903B9 (en) | 2009-06-04 |
| AU2007201903B2 (en) | 2009-01-29 |
| KR20070107590A (ko) | 2007-11-07 |
| EP1853043B1 (en) | 2008-07-02 |
| EP1973302A3 (en) | 2008-10-08 |
| BRPI0704532A (pt) | 2008-04-01 |
| MX2007005141A (es) | 2008-12-02 |
| JP2011008827A (ja) | 2011-01-13 |
| AU2007201903A1 (en) | 2007-11-22 |
| BRPI0704532B1 (pt) | 2019-11-26 |
| EP1973302A2 (en) | 2008-09-24 |
| DE602006001641D1 (de) | 2008-08-14 |
| KR100948545B1 (ko) | 2010-03-18 |
| EP2267981A1 (en) | 2010-12-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8024452B2 (en) | Dynamic syndicated content delivery system and method | |
| KR100897841B1 (ko) | 동적 모바일 컨텐츠의 전달을 위한 푸시 프레임워크 | |
| AU2007201902B2 (en) | Dynamic syndicated content delivery system and method | |
| US8095607B2 (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 | |
| ES2340866T3 (es) | Metodo y sistema para optimizar el paso de metadatos. | |
| US20090119375A1 (en) | Method and system for optimizing delivery of mobile content using differential metadata updates | |
| AU2007211960A1 (en) | Mediated plug-in registration of client applications and content providers with push content delivery system | |
| AU2007201901B2 (en) | Plug in registration method and apparatus for push content delivery | |
| ES2309903T3 (es) | Metodo y sistema de envolturas multicapas para metadatos de contenidos de empuje. | |
| US20070260637A1 (en) | System and method for fragmentation of mobile content | |
| US20070276863A1 (en) | Plug in registration method and apparatus for push content delivery | |
| AU2007201895B2 (en) | System and method for fragmentation of mobile content | |
| EP2056560A1 (en) | Method and system for optimizing delivery of mobile content using differential metadata updates |