MX2007010864A

MX2007010864A - Registro de conexion mediada de aplicaciones de cliente y proveedores de contenido con sistema de distribucion de contenido de insercion.

Info

Publication number: MX2007010864A
Application number: MX2007010864A
Authority: MX
Inventors: Michael Shenfield
Original assignee: Research In Motion Ltd
Priority date: 2006-09-07
Filing date: 2007-09-05
Publication date: 2009-02-04
Also published as: SG140563A1; KR100977502B1; JP2011100490A; HK1110457A1; AU2007211960B2; JP5061249B2; TW200820703A; EP1898597B1; CA2600190C; CA2600190A1; DE602006004049D1; KR20080023195A; CN101141479A; JP2008065825A; JP4681588B2; BRPI0703509A; ATE416558T1; AU2007211960A1; TWI357248B; EP1898597A1

Abstract

Un método y aparato para conectar un elemento genérico a una arquitectura de distribución de contenido en un sistema de distribución de contenido de inserción que tiene las etapas de: proporcionar un mediador entre el elemento genérico y la arquitectura de distribución de contenido; extraer en el mediador los metadatos para el elementos genérico; y registrar el elemento genérico con la arquitectura de distribución de contenido.

Description

REGISTRO DE CONEXIÓN MEDIADA DE APLICACIONES DE CLIENTE Y PROVEEDORES DE CONTENIDO CON SISTEMA DE DISTRIBUCIÓN DE CONTENIDO DE INSERCIÓN DESCRIPCIÓN DE LA INVENCIÓN La presente descripción se refiere generalmente a distribución de contenido dinámico en un ambiente móvil, y en particular a distribución de contenido dinámico utilizando aplicaciones genéricas o proveedores de contenido genérico. Usuarios de dispositivos móviles o equipo de usuario móvil (UE) crecientemente están volviéndose más sofisticados en términos de la funcionalidad que requieren de sus dispositivos móviles y la forma en la que acceden a los datos de los dispositivos móviles. La distribución de contenido dinámico permite a los usuarios tener información o datos introducidos en los mismos en lugar de tener que ir y buscar los datos. Ejemplos de datos podrían incluir cotizaciones de bolsa de valores, actualizaciones climáticas, actualizaciones de tráfico, papel tapiz dinámico, anuncios, aplicaciones u otros datos deseables para un usuario. Las tecnologías actuales para dispositivos móviles tales como protocolo para aplicación inalámbrica (WAP) tienen la capacidad de introducir contenido; sin embargo, WAP requiere que los sitios Web se rescriban para satisfacer el protocolo para aplicación inalámbrica y proporcionen a los usuarios con un sitio uniforme que no cambie para acomodar las capacidades de un usuario para ver un sitio. Otras alternativas incluyen inserción basada en SMS y difusión o difusión celular. En el caso de difusión, la distribución no puede ser personalizada a las necesidades de un usuario particular o las capacidades de un dispositivo particular. Estos sistemas por lo tanto no tienen inteligencia asociada con los mismos. Una mejor solución se requiere para dispositivos móviles. En una distribución de contenido dinámico, un cliente de inserción genérica sirve a múltiples aplicaciones objetivo en un dispositivo. Similarmente , el servidor alterno de inserción proporciona servicios a múltiples proveedores de contenido. Es esencial proporcionar mecanismos de registro de tiempo de ejecución donde las aplicaciones y los proveedores de contenido podrían registrarse con la estructura de distribución de contenido dinámico sin interrumpir el servicio para otras aplicaciones o proveedores de contenido. Con frecuencia las aplicaciones de cliente o los proveedores de contenido son genéricos y no tienen conocimiento intrínseco de los sistemas de distribución de contenido específicos . General El presente sistema y método pueden proporcionar una arquitectura de distribución de contenido dinámico y sistema que permite que aplicaciones genéricas y proveedores de contenido se agreguen al sistema sin necesidad de modificar la arquitectura. Específicamente, el presente sistema y método permiten que un dispositivo móvil se vuelva una plataforma de aplicación dinámica en la cual puedan agregarse aplicaciones y pueda agregarse el contenido al dispositivo móvil, donde la arquitectura del sistema de distribución de contenido dinámico no limita el tipo de aplicación que puede instalarse en el dispositivo ni el tipo de contenido que el dispositivo recibe. En un aspecto de la presente invención, los metadatos pueden proporcionarse y asociarse con el contenido para agregar inteligencia al contenido para varios elementos de procesamiento dentro de la arquitectura de distribución de contenido dinámico. Esta arquitectura incluye componentes lógicos que proporcionan provisión de contenido, provisión de servicio que incluye servidores alternos de inserción, una red inalámbrica, cliente de inserción y aplicaciones de cliente . En un aspecto adicional de la presente descripción, los metadatos pueden proporcionarse en un modelo estratificado "envuelto" para los metadatos de contenido de inserción. El contenido puede envolverse con metadatos que pueden utilizarse para procesamiento en cada elemento dentro de una estructura de inserción. Los metadatos para cada elemento sucesivo pueden estratificarse, permitiendo asi que el procesamiento extraiga sólo los metadatos de ese elemento. Por ejemplo, un paquete de contenido que incluye metadatos dirigidos a un servidor alterno de inserción y una aplicación de cliente puede incluir el contenido con un primer nivel de metadatos para la aplicación de cliente, y una segunda capa de metadatos para el servidor alterno de inserción. Por consiguiente, cuando la envoltura alcanza el servidor alterno de inserción, los metadatos para el servidor alterno de inserción pueden extraerse y aplicarse al contenido, y el contenido modificado y los metadatos para la aplicación de cliente se pasan al elemento de procesamiento adicional. En otro aspecto de la presente descripción, los metadatos pueden dividirse en metadatos estáticos (también referidos en la presente como metadatos de canal) y metadatos dinámicos (también referidos en la presente como metadatos de contenido). Los metadatos estáticos pueden establecerse al momento del registro de la aplicación y el proveedor de contenido. Sin embargo, los metadatos de canal pueden establecerse en un momento posterior. Los metadatos de canal pueden especificar las reglas de procesamiento que son especificas para el tipo de contenido que se está distribuyendo y los requerimientos de aplicación para el tipo de contenido. Los metadatos dinámicos pueden asociarse inversamente con el contenido especifico que se pasa. En otro aspecto de la presente descripción, un modelo de registro de conexión puede presentarse dentro de la estructura de inserción. Un cliente de inserción genérico y un servidor alterno de inserción se identifican, cada uno teniendo varios bloques de procesamiento o módulos que permiten que estos elementos procesen contenido y metadatos. Estos bloques pueden dirigirse para procesar ya sea el contenido que se pasa, los metadatos que se pasan o ambos el contenido y los metadatos que se pasan. El registro de conexión además puede proporcionar el paso de manifiestos de servicio y manifiestos de aplicación para permitir el establecimiento de los metadatos de canal entre un proveedor de contenido y una aplicación. Específicamente, los manifiestos de servicio pueden utilizarse para registrar un proveedor de contenido con la estructura de inserción, y un manifiesto de aplicación puede utilizarse para registrar una aplicación con la estructura de inserción . En otro aspecto de la presente descripción, se proporciona un método para insertar contenido afiliado el cual permite el manejo de datos basándose en su prioridad y basándose en factores de red que incluyen el costo de enviar datos, el tipo de red conectada o las preferencias de los usuarios. Un modelo de inserción/extracción mezclado opcional para el contenido afiliado permite que un servidor alterno de inserción inserte contenido cuando las condiciones de red se vuelven favorables o que un cliente extraiga contenido cuando las condiciones de red se vuelven favorables o cuando el usuario requiere el contenido. Para poder acomodar varios dispositivos móviles, un aspecto adicional de la presente descripción puede proporcionar fragmentación de contenido para el contenido, incluyendo fragmentación de contenido no lineal. La fragmentación de contenido no lineal puede incluir el aumento de contenido con metadatos que permite que los metadatos se reformulen una vez que se han pasado al cliente. En un aspecto adicional de la presente descripción, una aplicación genérica o proveedor de contenido podrían conectarse a un habilitador de distribución de contenido (CDE) específico utilizando un modelo de registro de conexión mediada. Con el registro de conexión mediada, el mediador podría ser una aplicación dedicada, una aplicación de mediador genérico utilizando un ambiente de tiempo de ejecución de provisión de metadatos de aplicación en el aire, o de una estructura de distribución. Estos y otros aspectos se identificarán en mayor detalle con respecto a los dibujos. La presente aplicación por lo tanto puede proporcionar un método para conectar un elemento genérico a una arquitectura de distribución de contenido en un sistema de distribución de contenido de inserción que comprende las etapas de: proporcionar un mediador entre el elemento genérico y la arquitectura de distribución de contenido; extraer en el mediador los metadatos para el elemento genérico; y registrar el elemento genérico con la arquitectura de distribución de contenido. Un mediador que conecta el elemento genérico a una arquitectura de distribución de contenido en un sistema de distribución de contenido de inserción, el mediador comprende: medios de extracción para extraer metadatos; y medios de registro para proporcionar información de registro para el elemento genérico a la arquitectura de distribución de contenido. BREVE DESCRIPCIÓN DE LOS DIBUJOS La presente descripción se entenderá mejor con referencia a los dibujos, en los cuales: La Figura 1 es un diagrama de bloque de una arquitectura básica para un sistema de distribución de contenido dinámico; la Figura 2 es un diagrama de bloque que muestra arquitecturas alternativas del sistema de distribución de contenido dinámico de la Figura 1; la Figura 3 es un diagrama de bloque de la Figura 1 que muestra el flujo de contenido y metadatos; la Figura 4 es un diagrama de bloque que muestra un servidor alterno de inserción que puede utilizarse junto con el presente sistema y método; la Figura 5 es un diagrama de bloque que muestra un cliente de inserción que puede utilizarse junto con el presente sistema y método; la Figura 6 es un diagrama de bloque que muestra un modelo de envoltura de varias capas de contenido y metadatos; la Figura 7 es el diagrama de bloque de la Figura 6, que muestra los metadatos dinámicos de las etapas de procesamiento para cada envoltura; la Figura 8 es el diagrama de bloque de la Figura 6, que muestra adiciona lmente el procesamiento que utiliza metadatos estáticos y dinámicos; la Figura 9 es un diagrama de bloque que muestra un proceso de registro para una aplicación en un solo cliente de inserción compartida; la Figura 10 es un diagrama de bloque que muestra un proceso de registro de una aplicación en un contenedor de inserción que maneja un grupo de clientes de inserción; la Figura 11 es un diagrama de bloque que muestra una aplicación que se registra en un procesador de contenido y un oyente de conexión; la Figura 12 es un diagrama de bloque que muestra un proveedor de contenido que se registra con un solo servidor alterno de inserción compartida; la Figura 13 es un diagrama de bloque que muestra un proveedor de contenido que se registra con un contenedor de inserción que maneja un grupo de servidores alternos de inserción; la Figura 14 es un diagrama de flujo que muestra los mensajes de registro entre un proveedor de contenido y la aplicación de cliente; la Figura 15 es un diagrama de bloque que muestra la interacción durante el registro entre un cliente de inserción y un servidor alterno de inserción; la Figura 16 es un diagrama de bloque que muestra la interacción durante el registro entre un servidor alterno de inserción y un proveedor de contenido; la Figura 17 es un diagrama de flujo que muestra el flujo de contenido y metadatos entre un proveedor de contenido y elementos de procesamiento; la Figura 18 es un diagrama de bloque que muestra una aplicación de transformación ejemplar para el contenido; la Figura 19 es un diagrama de bloque de un modelo de afiliación de contenido; la Figura 20 es un diagrama de bloque de un proceso de fragmentación lineal; la Figura 21 es un diagrama de bloque de un proceso de fragmentación no lineal; la Figura 22 es un diagrama de bloque de un modelo de registro de conexión mediada; la Figura 23 es un diagrama de bloque de un mediador de aplicación que opera en el modelo de la Figura 22; y la Figura 24 es un diagrama de bloque de un dispositivo móvil ejemplar que podría utilizarse junto con el presente método y sistema. Ahora se hace referencia a la Figura 1. Se ilustra un sistema de inserción genérico para distribuir contenido dinámico a una aplicación de cliente. Un sistema de la Figura 1 es un sistema simplificado y muestra componentes lógicos que necesitan estar en una arquitectura de distribución de contenido dinámico; sin embargo, alguien con experiencia en la técnica apreciará que otros componentes podrían existir o que varios componentes podrían agruparse juntos. La arquitectura 100 incluye un proveedor 110 de contenido. El proveedor 110 de contenido se dispone para proporcionar contenido dinámico a usuarios que se suscriben con el proveedor 110 de contenido. Ejemplos pueden incluir, por ejemplo, un sitio Web que vende libros. Un usuario puede registrarse con el proveedor 110 de contenido para obtener una lista de los libros recién puestos en circulación dentro de géneros específicos. Otros ejemplos podrían incluir sitios de noticias que pueden proporcionar encabezados a usuarios en una base periódica, sitios de tráfico que pueden proporcionar información de tráfico actualizada a usuarios durante ciertos periodos del día, sitios de mercado de valores que podrían proporcionar cotizaciones de bolsa de valores actualizadas o tasas de cambios de divisas a usuarios, entre otros. Como se describirá en mayor detalle en lo siguiente, el proveedor 110 de contenido se registra con un proveedor 120 de servicio para poder permitir que los clientes del proveedor de servicio reciban contenido del proveedor 110 de contenido. El proveedor 120 de servicio incluye un servidor alterno 122 de inserción que actúa como un servidor alterno para un cliente o una aplicación de cliente y proporciona un destino para que el proveedor 110 de contenido envíe el contenido. El proveedor 120 de servicio se comunica sobre la red 130 inalámbrica con un cliente 140 de inserción que se localiza en un dispositivo móvil. El cliente 140 de inserción se describirá en mayor detalle en lo siguiente. El cliente 140 de inserción recibe el contenido que se está distribuyendo desde el proveedor 110 de contenido y puede comunicar el contenido con una aplicación 150 de cliente, que al final consume el contenido. Dentro de la presente especificación, la referencia al proveedor 110 de contenido, el proveedor 120 de servicio, el servidor alterno 122 de inserción, la red 130 inalámbrica, el cliente 140 de inserción o la aplicación 150 de cliente es una referencia nuevamente a la arquitectura de la Figura 1. Con referencia a la Figura 2, se apreciará por aquellos con experiencia en la técnica que los componentes de la Figura 1 son componentes meramente lógicos y no son necesariamente componentes físicos separados. La Figura 1 ilustra una arquitectura genérica en la cual un proveedor 110 de contenido, un servidor alterno 122 de inserción, un cliente 140 de inserción y una aplicación 150 de cliente existen. Alternativas se ilustran en la Figura 2. Específicamente, una primera arquitectura 210 alternativa incluye múltiples proveedores 110 de contenido que se comunican con un servidor alterno 122 de inserción. El servidor alterno 122 de inserción, como en la arquitectura de la Figura 1, se comunica sobre la red 130 inalámbrica con un cliente 140 de inserción. Además, múltiples aplicaciones 150 de cliente existen en la arquitectura 210. Por lo tanto, éste es un sistema N-l-l-N que tiene múltiples proveedores 110 de contenido y múltiples aplicaciones 150 de cliente. La arquitectura 220 de la Figura 2 incluye un proveedor 110 de contenido que se comunica y se registra en el servidor alterno 122 de inserción. Además, el servidor alterno 122 de inserción se comunica sobre la red 130 inalámbrica con múltiples clientes 140 de inserción. Cada cliente 140 de inserción se comunica con una aplicación 150 de cliente. La arquitectura 220 por lo tanto agrupa los componentes lógicos de una aplicación 150 de cliente y un cliente 140 de inserción y es un sistema N(l-1)-1-1. La arquitectura 230 de la Figura 2 tiene múltiples servidores alternos 122 de inserción, cada uno comunicándose con un proveedor 110 de contenido. Cada combinación 232 de servidor alterno de inserción y proveedor de contenido se comunica sobre la red 130 inalámbrica con un cliente 140 de inserción genérico, el cual a su vez se comunica con la aplicación 150 de cliente. Éste es un sistema l-l-N(l-l). En la arquitectura 240 de la Figura 2, un grupo 232 del proveedor 110 de contenido y el servidor alterno 122 de inserción se comunican sobre la red 130 inalámbrica con una combinación de cliente 140 de inserción genérica y aplicación 150 de cliente. Ésta es por lo tanto un sistema N ( 1-1 ) -N (1-1) · Como se apreciará por aquellos con experiencia en la técnica, otras alternativas son posibles. Lo anterior muestra varios componentes lógicos, los cuales pueden estar en componentes físicos separados o agrupados en conjunto. Por ejemplo, un cliente de inserción puede integrarse en una aplicación, clientes compartidos comunes pueden utilizarse por múltiples aplicaciones u otras alternativas. Ahora se hace referencia a la Figura 3. Para poder agregar inteligencia a un sistema, el contenido se asocia con metadatos. Los metadatos, en este caso, se definen como datos que pueden utilizarse por un elemento de procesamiento para manipular el contenido. Como se apreciará, un sistema de inserción genérico requiere metadatos para permitir que varios proveedores de contenido y aplicaciones existan dentro del sistema. Los metadatos pueden tener varias formas, que incluyen parámetros de procesamiento o reglas, o un administrador de procesamiento, código o referencia proporcionados directamente o un enlace a un administrador de procesamiento, código o reglas en otra ubicación. Como puede observarse en la Figura 3, el contenido pasa desde el proveedor 110 de contenido hasta la aplicación 150 de cliente y se ilustra por la flecha 310. Los metadatos, los cuales proporcionan instrucciones a varios componentes dentro de la arquitectura 100 también pueden pasar 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 contenido y son claros para el sistema de distribución hasta que alcanza una aplicación 150 de cliente. La flecha 330 muestra los metadatos creados por el proveedor 110 de contenido que se pretenden para el cliente 140 de inserción, y de este modo sólo fluyen hacia el cliente 140 de inserción genérico. La flecha 340 ilustra metadatos generados por el proveedor 120 de servicio y pretendidos para el cliente 140 de inserción, y de este modo primero se asocian con el contenido en el servidor alterno 122 de inserción y se derivan del contenido en el cliente 140 de inserción genérico. Ejemplos de donde esto podría ocurrir incluyen acuerdos entre un usuario y un proveedor de servicio con respecto a un plan de facturación y el nivel de servicio que se proporciona, donde el proveedor de servicio puede 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 en mayor detalle en lo siguiente. Ahora se hace referencia a la Figura 4. La Figura 4 ilustra un servidor alterno 410 de inserción ejemplar detallado el cual puede utilizarse en asociación con el presente sistema y método. Como se apreciará por aquellos con experiencia en la técnica, el servidor alterno 410 de inserción podría ser el mismo que el servidor alterno 122 de inserción de las Figuras 1 y 2. El servidor alterno 410 de inserción de la Figura 4 incluye varios elementos que permiten al servidor alterno 410 de inserción operar en un ambiente de inserción genérico. Esto facilita la flexibilidad puesto que el servidor alterno de inserción no se limita a la interacción con proveedores de contenido específicos o clientes de inserción, sino de hecho pueden adaptarse a un ambiente dinámico. Es preferible que los elementos descritos en lo siguiente para el servidor alterno 410 de inserción estén dentro del servidor alterno 410 de inserción, pero los elementos no son exhaustivos, y otros elementos son posibles. Además, ciertos elementos pueden omitirse del servidor alterno 410 de inserción, con los elementos restantes aún siendo capaces de realizar servicios de inserción genéricos. El servidor alterno 410 de inserción incluye proveedores 412 de contenido registrados en el mismo. Los proveedores 412 de contenido se registran con una interfaz 420 del proveedor de servicio (SPI) de registro del proveedor de contenido. Como se describe en mayor detalle en lo siguiente, es deseable en este registro que el proveedor 412 de contenido incluya cierta información para que se establezca el canal, referido en la presente como metadatos de canal. Los proveedores 412 de contenido pueden ser los mismos que los proveedores 110 de contenido de la Figura 1. El servidor alterno 410 de inserción además incluye un bloque 430 de administración de servicio para administrar el servicio del servidor alterno de inserción. El servidor alterno 410 de inserción incluye varios módulos para tratar con el contenido y los metadatos asociados con ese contenido. Un primer módulo es el intermediario de mensajes y la cola 440 de distribución, que es un subsistema que consume mensajes del proveedor 412 de contenido y maneja la cola de distribución de contenido. Como se apreciará por aquellos con experiencia en la técnica, no todo el contenido para todas las aplicaciones de cliente puede distribuirse a la vez y una cola de distribución necesita establecerse para poder distribuir el contenido en un curso correcto. Por ejemplo, un dispositivo puede estar fuera de cobertura y el contenido puede necesitar almacenarse . El servidor alterno 410 de inserción además incluye un bloque 442 de manejo de control de flujo. El bloque 442 de manejo de control de flujo permite el control de flujo de contenido. Por ejemplo, una estación móvil con espacio limitado sólo puede ser capaz de recibir una cierta cantidad de información. En este caso, el dispositivo móvil, a través de un cliente 140 de inserción como se ilustra en la Figura 1, puede pedir al servidor alterno 410 de inserción detener el flujo de datos para el cliente 140 de inserción. El bloque 442 de manejo de control de flujo se encarga de esto. Alternativamente, el dispositivo móvil puede estar fuera de linea. El bloque 442 de manejo de control de flujo detiene y comienza el flujo de datos para el cliente 140 de inserción cuando el contenido no puede distribuirse como recibido por el servidor alterno 410 de inserción. Un componente adicional del servidor alterno 410 de inserción es los agentes 444 de inserción. Los agentes 444 de inserción son responsables de enviar datos a los clientes. Como se apreciará por aquellos con experiencia en la técnica, los bloques 440, 442 y 444 se encargan de mensajería solamente, y no se relacionan con los metadatos. En otras palabras, los bloques manejan el contenido de los mensajes, pero no los metadatos asociados con el contenido. Un componente adicional del servidor alterno 410 de inserción es el bloque 450 de memoria caché y extractor de metadatos de contenido. El bloque 450 de memoria caché y extractor de metadatos de contenido opera en metadatos de contenido envueltos. Específicamente, en el modelo de envoltura del sistema de metadatos, el cual se describe en mayor detalle en lo siguiente, cada componente lógico dentro del sistema puede tener metadatos asociados con el procesamiento de contenido. Estos metadatos permiten que el componente lógico realice acciones sobre el contenido. Cada componente lógico de este modo necesita ser capaz de extraer los metadatos que se asocian con el mismo. El bloque 450 de memoria caché y extractor de metadatos de contenido es responsable de extraer los metadatos que se asocian con el servidor alterno 410 de inserción y de guardar en memoria caché estos metadatos. La función de guardado en memoria caché permite la optimización al eliminar la necesidad de pasar metadatos idénticos en envolturas de contenido subsiguiente del mismo proveedor de contenido. La extracción y guardado en memoria caché de los metadatos se describe en lo siguiente. El bloque 452 de almacenamiento de mensajes de recuperación diferida se utiliza cuando no es efectivo distribuir contenido, o partes del mismo, a una aplicación de cliente. El bloque 452 de almacenamiento de mensajes de recuperación diferida puede utilizarse para almacenar el contenido que no se distribuye al cliente hasta que es efectivo para enviar el contenido, o hasta que el contenido es extraído por el cliente. El almacén de mensajes de recuperación diferida también podría utilizarse para guardar en memoria caché el contenido auxiliar que podría enviarse opcionalmente o extraerse por el cliente dependiendo de la navegación de aplicación de cliente a través del contenido ya distribuido . El propósito del bloque 452 de almacenamiento de mensajes de recuperación diferida se explica mejor en lo siguiente con referencia a la Figura 19 y 21. Por medio del ejemplo, el bloque 452 de almacenamiento de mensajes de recuperación diferida puede utilizarse en el caso donde un usuario ha solicitado información de ubicación, tal como un restaurante cerca de la ubicación del usuario. El proveedor de contenido o el proveedor de servicio pueden tener un modelo para proporcionar información donde anunciantes puedan pagar para agregar su información a las solicitudes de búsqueda. De este modo, el usuario que está solicitando información sobre restaurantes para una ubicación también puede tener información sobre almacenes, campos de golf, gimnasios u otros servicios cerca de su ubicación atendida a su solicitud. Un proveedor de contenido agrupa la información de restaurantes solicitada con la información adicional y la pasa al servidor alterno 410 de inserción. El servidor alterno 410 de inserción, basándose en los metadatos proporcionados, puede crear un paquete de contenido para enviar al cliente. El paquete de contenido podría incluir la información solicitada por el cliente, así como un compendio o resumen de la información relacionada en la que puede estar interesado el usuario. El resumen se envía al usuario, pero el bloque 452 de almacenamiento de mensajes de recuperación diferida almacena los datos actuales que se recibieron del proveedor 110 de contenido. De este modo, si en un futuro el usuario desea obtener información más detallada sobre la información dentro del compendio, esta información ya está almacenada en el servidor alterno 410 de inserción . Un uso alternativo para el bloque 452 de almacenamiento de mensajes de recuperación diferida está en el caso donde un usuario no puede aceptar todo el contenido a la vez. Por ejemplo, si no es viable o económico enviar todo el contenido al dispositivo, parte del contenido puede almacenarse hasta un momento posterior, cuando pueda extraerse por el cliente o insertarse cuando se satisfagan reglas predefinidas. Estas reglas pueden especificarse por las condiciones de red o de servicio mediante ciertas condiciones de red o de servicio que se satisfacen. Esto se describe en mayor detalle con referencia a la Figura 19 siguiente . El programador 454 de inserción programa los intervalos de distribución para los clientes. Como se describe en lo anterior, en algunas situaciones puede no ser eficiente insertar todo el contenido a la vez. El programador 452 de inserción puede determinar que insertará cierta información inmediatamente y el resto de acuerdo con un programa predefinido. También, el programador 454 de inserción puede utilizar la naturaleza del contenido para determinar cuándo debe insertarse el contenido. Específicamente, los metadatos pueden indicar que cierto contenido es de alta prioridad o tiene una expiración que tiene límite de tiempo, y este contenido puede insertarse inmediatamente, mientras que el contenido que se ha indicado que tiene una baja prioridad o sin ninguna expiración puede insertarse posteriormente cuando las condiciones para pasar los datos sean más favorables. Como se apreciará por aquellos con experiencia en la técnica, los bloques 450, 452 y 454 se encargan del contenido del mensaje y los metadatos que se asocian con el mensaj e . El bloque 460 de suscripción y reglas sigue las aplicaciones que se registran para recibir un servicio y monitorea las reglas en cuanto a cómo manejar el contenido particular que se distribuye. El contenido típicamente se distribuye basándose en una suscripción por el cliente o a nombre del cliente. El usuario, por ejemplo si desea un servicio particular, puede solicitar activamente suscripciones. Las suscripciones pueden hacerse a nombre de un usuario, por ejemplo si el usuario ha firmado un acuerdo con su proveedor 120 de servicio para recibir un beneficio por un servicio. Esto podría incluir el caso donde un usuario recibe una tasa preferida siempre y cuando el usuario esté de acuerdo en recibir un cierto número de anuncios publicitarios cada día. En este caso, el proveedor 120 de servicio puede hacer la suscripción en el proveedor de anuncios publicitarios a nombre del cliente. Cuando se borra una aplicación en un dispositivo móvil o cuando la aplicación se desregistra de una suscripción, el bloque 460 de suscripción y reglas puede desuscribir ese usuario. El bloque 462 de dependencias de contenido se utiliza por el servidor alterno 410 de inserción para anunciar servicios que un usuario del dispositivo móvil puede utilizar. De este modo, si un usuario del dispositivo móvil no tiene una pantalla o ancho de banda o suficiente memoria para el servicio, el bloque 462 de dependencias de contenido puede bloquear el anuncio de ese servicio al usuario. El bloque 464 de fragmentación de contenido se utiliza para fragmentar el contenido. Este podría utilizarse, por ejemplo, si el dispositivo móvil es incapaz de recibir todo el contenido a la vez. El bloque 464 de fragmentación de contenido se utiliza para descomponer el contenido en varios componentes. Puede utilizarse en asociación con la recuperación diferida y el almacén 452 de mensajes para almacenar el contenido fragmentado que aún no se ha distribuido . El bloque 466 de expiración de contenido y reemplazo se utiliza para dos propósitos. Primero, este bloque puede utilizarse para monitorear suscripciones. Cada suscripción tiene un tiempo de expiración y cuando este tiempo de expiración se cumple, puede finalizarse la suscripción. También, el bloque 466 de expiración de contenido y reemplazo puede utilizarse para monitorear información. Cierto contenido tendrá límites de tiempo sobre la validez de la información. Por ejemplo, una aplicación de tráfico utilizada para monitorear el tráfico de hora pico será muy dependiente del tiempo. Si por alguna razón, el servidor alterno 410 de inserción es incapaz de distribuir el contenido inmediatamente a un dispositivo móvil, este contenido se almacena en el almacén 480 de contenido para su distribución futura. Sin embargo, si el contenido no se distribuye dentro de un cierto periodo de tiempo especifico, entonces podría expirar y no distribuirse en absoluto. Simi larmente , el reemplazo de contenido trata con una situación donde la información se está actualizando. Por ejemplo, una aplicación de cliente que está recibiendo cotizaciones de bolsa de valores puede desear sólo la última cotización de bolsa de valores. De este modo, si el servidor alterno 410 de inserción es incapaz de distribuir la cotización de bolsa de valores al cliente 140 de inserción y una cotización de bolsa de valores posterior se recibe de un proveedor 110 de contenido, los metadatos dentro de la cotización de bolsa de valores posterior pueden indicar que ésta debe utilizarse para reemplazar la cotización de bolsa de valores previa. El reemplazo de la información almacenada en lugar de agregar toda la información a una cola dé distribución libera espacio dentro del almacén 480 de contenido . El depósito 470 de metadatos de canal se utiliza para almacenar los metadatos de canal, los cuales se describen en mayor detalle en lo siguiente.

Lo anterior describe un servidor alterno 410 de inserción ejemplar que puede utilizarse con el método y sistemas en la presente. Los bloques y elementos del servidor alterno 410 de inserción permiten que el servidor alterno 410 de inserción se utilice en un sistema genérico de distribución de contenido dinámico donde el tipo de contenido y manejo de contenido en una aplicación pueden variar y no se predeterminan . Ahora se hace referencia a la Figura 5. La Figura 5 ilustra un cliente 510 de inserción que puede utilizarse junto con el sistema y métodos en la presente. El cliente 510 de inserción puede ser el mismo que el cliente 140 de inserción de las Figuras 1 y 2. Como se apreciará por aquellos con experiencia en la técnica, un cliente 510 de inserción que va a utilizarse en un sistema genérico en el cual el contenido y procesamiento del contenido no se predeterminan debe incluir bloques o módulos que puedan utilizarse para acomodar el contenido y los metadatos asociados con el contenido. Los bloques definidos con respecto a la Figura 5 no están hechos para ser exhaustivos, y otros bloques podrían existir también dentro de un cliente 510 de inserción. Además, los bloques dentro del cliente 510 de inserción en algunos casos, pueden omitirse sin restringir la funcionalidad de los otros bloques dentro del cliente 510 de inserción.

Un cliente 510 de inserción provee servicio a aplicaciones, y una o más aplicaciones 512 pueden registrarse con el cliente 510 de inserción. El registro de aplicación utiliza una interfaz 514 de proveedor de aplicación como la interfaz para el registro y la interfaz 514 de proveedor de aplicación puede utilizarse además para extraer los metadatos de canal para la aplicación, como se describe en mayor detalle en lo siguiente. El cliente 510 de inserción incluye la administración 520 de cliente utilizada para administrar el cliente 510 de inserción. Como con el servidor 410 de inserción de la Figura 4, el cliente 510 de inserción incluye varios bloques que se encargan del mensaje, varios bloques que se encargan de los metadatos, y varios bloques que se encargan de la mensajería y los metadatos. Las colas 540 del intermediario de mensajes y de aplicación manejan los mensajes del servidor alterno 410 de inserción para la distribución de las aplicaciones 512. Una cola de aplicación es una cola de mensajes para aplicaciones 512. El bloque 542 de manejo de control de flujo se utiliza para notificar al servidor alterno 410 de inserción de la Figura 4 para detener la inserción de contenido o para retomar la inserción de contenido. Esto puede utilizarse por ejemplo, cuando el cliente 510 de inserción tiene una cantidad limitada de memoria que puede aceptar contenido insertado. En este caso, antes de que el contenido de inserción se consuma, el cliente 510 de inserción necesita detener el flujo de contenido del servidor alterno 410 de inserción. Una vez que se ha consumido el contenido, el bloque 542 de manejo de control de flujo puede utilizarse para comenzar el flujo de datos nuevamente. Los agentes 544 de inserción dentro del cliente 510 de inserción se utilizan para recibir información del servidor alterno 410 de inserción de la Figura 4. Como se apreciará por aquellos con experiencia en la técnica, las colas 540 de intermediario de mensajes y de aplicación, el bloque 542 de manejo de control de flujo y los agentes 544 de inserción se encargan exclusivamente de la mensajería y no de los metadatos. El bloque 550 de memoria caché y extractor de metadatos de contenido se utiliza para extraer metadatos dinámicos destinados para el cliente 510 de inserción. Como se indica en lo anterior con referencia al servidor alterno 410 de inserción de la Figura 4, cualquiera de los elementos de procesamiento en la arquitectura de distribución de contenido dinámico podría tener metadatos destinados para los mismos y estos metadatos necesitan extraerse. De este modo, los metadatos destinados para el cliente 510 de inserción se extraen por el bloque 550 de memoria caché y extractor de metadatos de contenido. Además, el bloque 550 de memoria caché y extractor de metadatos de contenido de preferencia se adapta para guardar en memoria caché los metadatos. Los metadatos para el cliente 510 de inserción que no cambian entre un primer paquete de contenido y un segundo paquete de contenido no necesitan pasarse, ahorrando tiempo de procesamiento del cliente 510 de inserción al no requerir la extracción de estos metadatos, y además ahorrando recursos de red al no requerir que metadatos para el cliente 510 de inserción se pasan sobre la red 130 inalámbrica. El gestor 552 de recuperación diferida se utiliza para analizar fragmentos de contenido que se reciben y organizan el contenido en forma correcta. Como se describe en mayor detalle en lo siguiente, los datos pueden ser ya sea lineales o no lineales. Si los datos son no lineales, entonces los metadatos se requieren para poder reconstituirlos, y esto se hace por el gestor 552 de recuperación diferida. El gestor 552 de recuperación diferida también se adapta para analizar un compendio de información disponible en el almacén 452 de recuperación diferida del servidor alterno 510 de inserción e impulsa el intermediario 554 de extracción de contenido (descrito en lo siguiente) para recuperar esa información cuando se requiera por el usuario. Esto incluye recuperación predictiva cuando la navegación de contenido entra a una cierta rama de la gráfica de estructura de contenido o cuando el ancho de banda o condiciones de costo se satisfacen. El intermediario 554 de extracción de contenido se utiliza en un modelo de inserción/extracción donde el cliente 510 de inserción también es capaz de extraer contenido en ciertas situaciones. Tales situaciones se describen en lo siguiente en mayor detalle con referencia a la Figura 19. Como se apreciará por aquellos con experiencia en la técnica, el bloque 550 de memoria caché y extractor de metadatos de contenido, el gestor 552 de recuperación diferida y el intermediario 554 de extracción de contenido se encargan del contenido de mensajes y de los metadatos. El bloque 560 de manejo de suscripción es el mismo que el bloque 460 de suscripción y reglas de la Figura 4. Específicamente, el bloque 560 de manejo de suscripción se utiliza para manejar suscripción. Si una aplicación se desregistra o se borra de un dispositivo móvil entonces el bloque 560 de manejo de suscripción finaliza la suscripción. El bloque 560 de manejo de suscripción también puede resuscribirse a nombre de una aplicación de cliente cuando expire el canal de suscripción. El bloque 562 de notificación de actualización funciona con las aplicaciones del cliente y se utiliza para notificar a las aplicaciones que el nuevo contenido está esperándolas. Esto puede hacerse en una de tres formas: a. Una primera forma que el bloque 562 de notificación de actualización puede notificar a una aplicación 512 es que el cliente 510 de inserción envíe el contenido a la aplicación 512 directamente . b. Una segunda forma que el bloque 562 de notificación de actualización puede notificar a las aplicaciones 512 del nuevo contenido es que almacene el contenido en el almacén 580 de contenido y que notifique opcionalmente a las aplicaciones que el contenido está esperando. La notificación en este caso es opcional. Específicamente, si una aplicación 512 sabe qué información destinada para la misma se almacena dentro de un bloque de memoria específico, una opción para que la aplicación descubra que tiene nuevos datos es consultar periódicamente la ubicación de memoria para ver si existe algo qué escribir en la misma. Alternativamente, el bloque 562 de notificación de actualización puede enviar un mensaje a la aplicación 512 indicando que tiene nuevos datos y posiblemente la ubicación en la que se almacenan los datos. c. Una tercera forma que la notificación 562 de actualización puede notificar a las aplicaciones 512 del nuevo contenido es que almacenen contenido internamente y notifiquen la aplicación. La aplicación entonces puede pedir que el cliente de inserción recupere el contenido . El bloque 564 de dependencia de contenido es el mismo que el bloque 462 de dependencia de contenido de la Figura 4, y puede determinar si anunciar el servicio al dispositivo móvil. El bloque 566 de expiración de contenido y reemplazo es el mismo que el bloque 466 de expiración de contenido y reemplazo de la Figura 4. La expiración de contenido y el reemplazo de contenido de este modo pueden manejarse en el cliente 510 de inserción además del servidor de inserción o servidor alterno de inserción. El depósito 570 de metadatos de canal se utiliza para almacenar metadatos de canal para la aplicación 512. El módulo 575 de procesamiento de actualización de antecedentes se utiliza para realizar actualizaciones cuando no está disponible una aplicación 512. La actualización de antecedentes permite, por ejemplo, el reemplazo de datos con datos más nuevos dentro del almacén de aplicaciones. Después de esto, cuando un usuario comienza la aplicación, los datos desplegados por la aplicación son corregidos y se actualizan. El módulo 575 de procesamiento de actualización de antecedentes utiliza las reglas de procesamiento para traducir el contenido en un formato aceptable para una aplicación. Puede ejecutar y procesar contenido en el almacén 580 de contenido. Por medio del ejemplo, una lista de tareas que se actualiza para un contratista durante la noche puede tener tareas insertadas en el mismo. La aplicación de tareas no se inicia durante este tiempo, y el módulo 575 de procesamiento de actualización de antecedentes puede utilizarse para actualizar el contenido para la aplicación de tareas. Esto podría hacerse con el código para manejar un archivo de lenguaje de marcación extensible (XML) , y podría existir en el dispositivo en un archivo llamado "handler.exe". El bloque 575 de procesamiento de actualización de antecedentes en el cliente 510 de inserción puede ejecutar handler.exe, pasando el documento de XML teniendo un parámetro. El gestor entonces construye la tarea en el formato interno de la aplicación. Una vez que el bloque 575 de procesamiento de actualización de antecedentes del cliente 510 de inserción construye la tarea en el formato interno de la aplicación, entonces puede leer la tarea en la lista de tareas del almacén 580 de contenido y anexar la nueva tarea a la lista. Entonces puede almacenar los antecedentes modificados en el almacén 580 de contenido para cuando la siguiente aplicación de tarea se conecte al cliente 510 de inserción. La Figura 5 por lo tanto ilustra un cliente 510 de inserción que puede utilizarse en un sistema genérico de distribución de contenido dinámico, donde el contenido y procesamiento del contenido es dinámico y no predeterminado. Los bloques descritos en lo anterior con referencia al cliente 510 de inserción de la Figura 5 se utilizan para acomodar la naturaleza dinámica del sistema. Como se indica en lo anterior con referencia a la Figura 3, el contenido se asocia con los metadatos para proporcionar inteligencia para el procesamiento de contenido. De acuerdo con el presente método y sistema, los metadatos pueden dividirse en dos tipos de metadatos. Específicamente, metadatos estáticos (de canal) y metadatos dinámicos (de contenido) . Debido a las posibilidades ilimitadas de tipos de proveedores de contenido y aplicaciones, los metadatos son críticos para poder construir sistemas genéricos. La única forma de manejar el tipo específico de contenido es a través de metadatos. Los metadatos estáticos son metadatos que proporcionan reglas en cuanto a cómo procesar los tipos específicos de contenido. Los metadatos estáticos pueden descomponerse en varios niveles de abstracción e incluyen, por ejemplo, información estructural sobre el contenido mismo. Por ejemplo, un documento de Afiliación Simple en Tiempo Real (RSS) puede distribuirse con una estructura de RSS 2.0.XSD, y todo el contenido de ese proveedor de contenido se distribuirá con esta estructura. Un nivel adicional de abstracción para los metadatos estáticos incluye la provisión de reglas de procesamiento para el subtipo de contenido. Este podría ser la aplicación específica. De este modo, por ejemplo, una indicación de noticias financieras indica que los datos deben extraerse de una corriente de RSS de noticias financieras, almacenada en una ubicación predefinida, y que la aplicación debe notificarse sobre la llegada de la información. La aplicación siempre requiere que el contenido destinado para la misma sea manejado de esta forma. Los metadatos estáticos (también referidos en la presente como metadatos de canal) permanecen iguales a través de la suscripción entre la aplicación y el proveedor de contenido, y de este modo los metadatos estáticos pueden establecerse una vez para cada elemento dentro de la arquitectura y para cada canal de distribución de contenido. En una modalidad, esto se hace al momento del registro de la aplicación o el proveedor de contenido. Los metadatos dinámicos son metadatos que se asocian con una pieza particular de contenido. Por ejemplo, la información de expiración asociada con una pieza particular de datos o reglas de reemplazo e información asociada con una pieza particular de datos (es decir, el documento K reemplaza al documento L) . Como se indica en lo anterior con referencia a las Figuras 4 y 5, cada entidad de procesamiento puede recibir metadatos estáticos y dinámicos que se dirigen a esa entidad de procesamiento. De este modo, el servidor alterno 410 de inserción utiliza el bloque 450 de memoria caché y extractor de metadatos de contenido para extraer los metadatos dinámicos, y el bloque 466 de expiración de contenido y reemplazo se utiliza para reemplazar el contenido no distribuido con contenido más nuevo recibido en el servidor alterno 410 de inserción. Ahora se hace referencia a la Figura 6. La Figura 6 ilustra un modelo de envoltura estratificada para metadatos de contenido. Un servidor alterno 410 de inserción recibe una envoltura 610 de inserción que incluye metadatos 612 de procesamiento de contenido para el servidor de inserción y una envoltura 614 de cliente de inserción. El servidor alterno 410 de inserción extrae los metadatos 612 de procesamiento de contenido y utiliza estos metadatos para procesar la envoltura 614 de cliente de inserción. Los metadatos 612 dictan lo que el servidor alterno de inserción hace con la envoltura 614 de cliente de inserción. La envoltura 614 de cliente de inserción se pasa al cliente 510 de inserción donde se descompone en una envoltura 620 de contenido y metadatos 622 de procesamiento de contenido. Los metadatos 622 de procesamiento de contenido se utilizan por el cliente 510 de inserción para procesar la envoltura 620 de contenido. Por ejemplo, esto puede utilizarse para instruir al cliente 510 de inserción que realice el reemplazo de la envoltura 620 de contenido previamente distribuida con la última envoltura si la aplicación 150 de cliente sólo está interesada en la última versión del contenido. La envoltura 620 de contenido se pasa a la aplicación 150 de cliente. La envoltura 620 de contenido incluye metadatos 630 de procesamiento de contenido para la aplicación y la carga útil 632 de contenido que se consumirá por la aplicación 150 de cliente. Como se apreciará por aquellos con experiencia en la técnica, la subdivisión de envolturas de acuerdo con la Figura 6 proporciona un ambiente dinámico rico en el cual puede presentarse el procesamiento en cualquier elemento de procesamiento de la arquitectura y cuál proveedor 110 de contenido puede especificar cómo será tratado el contenido especifico. En una modalidad, los metadatos dirigidos a un elemento lógico particular se opacan en otros elementos de procesamiento. Alternativamente, el proveedor 120 de servicio también puede agregar metadatos en el servidor alterno 410 de inserción para su procesamiento en el cliente 510 de inserción o aplicación 150 de cliente. Con referencia a la Figura 7, esta figura muestra el modelo de envoltura de la Figura 6 y las etapas que cada elemento de procesamiento toma con la envoltura. Como se ilustra en la Figura 7, el servidor alterno 410 de inserción primero extrae los metadatos de la envoltura 610 de inserción. Esto se hace en la etapa 710. En la etapa 712, el servidor alterno 410 de inserción utiliza los metadatos para procesar la envoltura 614 de cliente de inserción. En la etapa 714, el servidor alterno 410 de inserción distribuye la envoltura 614 de cliente de inserción al cliente 510 de inserción. Similarmente, el cliente 510 de inserción, en la etapa 720 extrae los metadatos 622 de procesamiento de contenido de la envoltura 614 de cliente de inserción. En la etapa 722, el cliente 510 de inserción utiliza los metadatos 622 de procesamiento de contenido en la envoltura 620 de contenido. En la etapa 724, el cliente 510 de inserción distribuye la envoltura 620 de contenido a la aplicación 150 de cliente. En la etapa 730, la aplicación 150 de cliente extrae los metadatos 630 de procesamiento de contenido y en la etapa 732 utiliza los metadatos 630 de procesamiento de contenido en la carga útil 632 de contenido. Con referencia a la Figura 8, esta figura muestra el método como se ilustra en la Figura 7 con la etapa adicional del uso de metadatos estáticos o de canal. Específicamente, después de que los metadatos se han extraído en la etapa 710 de la envoltura 610 de inserción, el servidor alterno 410 de inserción después utiliza los metadatos de canal estáticos para procesar la envoltura de cliente de inserción en la etapa 810. En la etapa 712, el servidor alterno 410 de inserción después procesa los metadatos 612 dinámicos de procesamiento de contenido. El servidor alterno 410 de inserción después distribuye la envoltura 614 del cliente de inserción en la etapa 714. Similarmente, el cliente 510 de inserción extrae los metadatos 622 de procesamiento de contenido en la etapa 720. El cliente 510 de inserción entonces utiliza los metadatos de canal en la etapa 820 en el contenido dentro de la envoltura 620 de contenido. El cliente 510 de inserción entonces, en la etapa 722, utiliza los metadatos de contenido dinámicos en los metadatos 622 de procesamiento de contenido antes de la distribución de la envoltura 620 de contenido a la aplicación 150 de cliente en la etapa 724. La aplicación 150 de cliente primero extrae, en la etapa 730, los metadatos 630 de procesamiento de contenido. Después utiliza los metadatos de canal en la etapa 830 en la carga útil 632 de contenido. La aplicación 150 de cliente entonces utiliza, en la etapa 732, los metadatos 630 de procesamiento de contenido en la carga útil 632 de contenido. Como se apreciará por aquellos con experiencia en la técnica, el modelo anterior por lo tanto permite que metadatos estáticos se apliquen para el canal junto con los metadatos dinámicos que se asocian con el contenido particular que se envía. Ahora se hace referencia a la Figura 9. Como se apreciará a partir de la Figura 5, el cliente 510 de inserción puede servir a múltiples aplicaciones 512 objetivo en un dispositivo móvil. Se requiere un mecanismo de registro de tiempo de ejecución donde las aplicaciones puedan registrarse con la estructura de distribución de contenido dinámico sin interrumpir el servicio para otras aplicaciones. Con referencia a la Figura 9, el cliente 510 de inserción incluye tres aplicaciones, específicamente aplicaciones 910, 912 y 914 que ya están registradas con el cliente de inserción. Como se apreciará, el modelo de conexión es importante debido a que nuevos dispositivos pueden permitir que tipos de aplicación ilimitados se instalen en el dispositivo. Además, aplicaciones pueden instalarse dinámicamente, llevando a un dispositivo móvil que se vuelve una plataforma de aplicación. Debido a que el dispositivo puede ser una plataforma de aplicación, debe ser capaz de incorporar dinámicamente nuevas aplicaciones. El servidor alterno 410 de inserción además incluye un bloque 430 de administración de servicio para administrar el servicio del servidor alterno de inserción. El servidor alterno 410 de inserción incluye varios módulos para tratar con el contenido y los metadatos asociados con ese contenido. Un primer módulo es el intermedia io de mensajes y la cola 440 de distribución, que es un subsistema que consume mensajes del proveedor 412 de contenido y maneja la cola de distribución de contenido. Como se apreciará por aquellos con experiencia en la técnica, no todo el contenido para todas las aplicaciones de cliente puede distribuirse a la vez y una cola de distribución necesita establecerse para poder distribuir el contenido en un curso correcto. Por ejemplo, un dispositivo puede estar fuera de cobertura y el contenido puede necesitar almacenarse . El servidor alterno 410 de inserción además incluye un bloque 442 de manejo de control de flujo. El bloque 442 de manejo de control de flujo permite el control de flujo de contenido. Por ejemplo, una estación móvil con espacio limitado sólo puede ser capaz de recibir una cierta cantidad de información. En este caso, el dispositivo móvil, a través de un cliente 140 de inserción como se ilustra en la Figura 1, puede pedir al servidor alterno 410 de inserción detener el flujo de datos para el cliente 140 de inserción. El bloque 442 de manejo de control de flujo se encarga de esto. Alternativamente, el dispositivo móvil puede estar fuera de linea. El bloque 442 de manejo de control de flujo detiene y comienza el flujo de datos para el cliente 140 de inserción cuando el contenido no puede distribuirse como recibido por el servidor alterno 410 de inserción. Un componente adicional del servidor alterno 410 de inserción es los agentes 444 de inserción. Los agentes 444 de inserción son responsables de enviar datos a los clientes. Como se apreciará por aquellos con experiencia en la técnica, los bloques 440, 442 y 444 se encargan de mensajería solamente, y no se relacionan con los metadatos. En otras palabras, los bloques manejan el contenido de los mensajes, pero no los metadatos asociados con el contenido. Un componente adicional del servidor alterno 410 de inserción es el bloque 450 de memoria caché y extractor de metadatos de contenido. El bloque 450 de memoria caché y extractor de metadatos de contenido opera en metadatos de contenido envueltos. Específicamente, en el modelo de envoltura del sistema de metadatos, el cual se describe en mayor detalle en lo siguiente, cada componente lógico dentro del sistema puede tener metadatos asociados con el procesamiento de contenido. Estos metadatos permiten que el componente lógico realice acciones sobre el contenido. Cada componente lógico de este modo necesita ser capaz de extraer los metadatos que se asocian con el mismo. El bloque 450 de memoria caché y extractor de metadatos de contenido es responsable de extraer los metadatos que se asocian con el servidor alterno 410 de inserción y de guardar en memoria caché estos metadatos. La función de guardado en memoria caché permite la optimización al eliminar la necesidad de pasar metadatos idénticos en envolturas de contenido posterior del mismo proveedor de contenido. La extracción y guardado en memoria caché de los metadatos se describe en lo siguiente. El bloque 452 de almacenamiento de mensajes de recuperación diferida se utiliza cuando no es efectivo distribuir contenido, o partes del mismo, para una aplicación de cliente. El bloque 452 de almacenamiento de mensajes de recuperación diferida puede utilizarse para almacenar el contenido que no se distribuye al cliente hasta que es efectivo para enviar el contenido, o hasta que el contenido es extraído por el cliente. El almacén de mensajes de recuperación diferida puede utilizarse también para guardar en memoria caché el contenido auxiliar que puede enviarse opcionalmente o extraerse por el cliente dependiendo de la navegación de aplicación de cliente a través del contenido ya distribuido . El propósito del bloque 452 de almacenamiento de mensajes de recuperación diferida se explica mejor en lo siguiente con referencia a la Figura 19 y 21. Por medio del ejemplo, el bloque 452 de almacenamiento de mensajes de recuperación diferida puede utilizarse en el caso donde un usuario ha solicitado información de ubicación, tal como un restaurante cerca de la ubicación del usuario. El proveedor de contenido o el proveedor de servicio pueden tener un modelo para proporcionar información donde anunciantes puedan pagar para agregar su información a las solicitudes de búsqueda. De este modo, el usuario que está solicitando información sobre restaurantes para una ubicación también puede tener información sobre almacenes, campos de golf, gimnasios u otros servicios cerca de su ubicación atendida a su solicitud. Un proveedor de contenido agrupa la información de restaurantes solicitada con la información adicional y la pasa al servidor alterno 410 de inserción. El servidor alterno 410 de inserción, basándose en los metadatos proporcionados, puede crear un paquete de contenido para enviar al cliente. El paquete de contenido podría incluir la información solicitada por el cliente, así como un compendio o resumen de la información relacionada en la que puede estar interesado el usuario. El resumen se envía al usuario, pero el bloque 452 de almacenamiento de mensajes de recuperación diferida almacena los datos actuales que se recibieron del proveedor 110 de contenido. De este modo, si en un futuro el usuario desea obtener información más detallada sobre la información dentro del compendio, esta información ya está almacenada en el servidor alterno 410 de inserción . Un uso alternativo para el bloque 452 de almacenamiento de mensajes de recuperación diferida está en el caso donde un usuario no puede aceptar todo el contenido a la vez. Por ejemplo, si no es viable o económico enviar todo el contenido al dispositivo, parte del contenido puede almacenarse hasta un momento posterior, cuando pueda extraerse por el cliente o insertarse cuando se satisfagan reglas predefinidas. Estas reglas pueden especificarse por las condiciones de red o de servicio mediante ciertas condiciones de red o de servicio que se satisfacen. Esto se describe en mayor detalle con referencia a la Figura 19 siguiente . El programador 454 de inserción programa los intervalos de distribución para los clientes. Como se describe en lo anterior, en algunas situaciones puede no ser eficiente insertar todo el contenido a la vez. El programador 452 de inserción puede determinar que insertará cierta información inmediatamente y el resto de acuerdo con un programa predefinido. También, el programador 454 de inserción puede utilizar la naturaleza del contenido para determinar cuándo debe insertarse el contenido. Específicamente, los metadatos pueden indicar que cierto contenido es de alta prioridad o tiene una expiración que tiene límite de tiempo, y este contenido puede insertarse inmediatamente, mientras que el contenido que se ha indicado que tiene una baja prioridad o sin ninguna expiración puede insertarse posteriormente cuando las condiciones para pasar los datos sean más favorables. Como se apreciará por aquellos con experiencia en la técnica, los bloques 450, 452 y 454 se encargan del contenido del mensaje y los metadatos que se asocian con el mensa e . El bloque 460 de suscripción y reglas sigue las aplicaciones que se registran para recibir un servicio y monitorea las reglas en cuanto a cómo manejar el contenido particular que se distribuye. El contenido típicamente se distribuye basándose en una suscripción por el cliente o a nombre del cliente. El usuario, por ejemplo si desea un servicio particular, puede solicitar activamente suscripciones. Las suscripciones pueden hacerse a nombre de un usuario, por ejemplo si el usuario ha firmado un acuerdo con su proveedor 120 de servicio para recibir un beneficio por un servicio. Esto podría incluir el caso donde un usuario recibe una tasa preferida siempre y cuando el usuario esté de acuerdo en recibir un cierto número de publicidades cada día. En este caso, el proveedor 120 de servicio puede hacer la suscripción en el proveedor de publicidad a nombre del cliente . Cuando se borra una aplicación en un dispositivo móvil o cuando la aplicación se desregistra de una suscripción, el bloque 460 de suscripción y reglas puede desuscribir ese usuario. El bloque 462 de dependencias de contenido se utiliza por el servidor alterno 410 de inserción para anunciar servicios que un usuario del dispositivo móvil puede utilizar. De este modo, si un usuario del dispositivo móvil no tiene una pantalla o ancho de banda o suficiente memoria para el servicio, el bloque 462 de dependencias de contenido puede bloquear el anuncio de ese servicio al usuario. El bloque 464 de fragmentación de contenido se utiliza para fragmentar el contenido. Este podría utilizarse, por ejemplo, si el dispositivo móvil es incapaz de recibir todo el contenido a la vez. El bloque 464 de fragmentación de contenido se utiliza para descomponer el contenido en varios componentes. Puede utilizarse en asociación con la recuperación diferida y el almacén 452 de mensajes para almacenar el contenido fragmentado que aún no se ha distribuido . El bloque 466 de expiración de contenido y reemplazo se utiliza para dos propósitos. Primero, este bloque puede utilizarse para monitorear suscripciones. Cada suscripción tiene un tiempo de expiración y cuando este tiempo de expiración se cumple, puede finalizarse la suscripción. También, el bloque 466 de expiración de contenido y reemplazo puede utilizarse para monitorear información. Cierto contenido tendrá limites de tiempo sobre la validez de la información. Por ejemplo, una aplicación de tráfico utilizada para monitorear el tráfico de hora pico seré muy dependiente del tiempo. Si por alguna razón, el servidor alterno 410 de inserción es incapaz de distribuir el contenido inmediatamente a un dispositivo móvil, este contenido se almacena en el almacén 480 de contenido para su distribución futura. Sin embargo, si el contenido no se distribuye dentro de un cierto periodo de tiempo especifico, entonces podría expirar y no distribuirse en absoluto. Similarmente, el reemplazo de contenido trata con una situación donde la información se está actualizando. Por ejemplo, una aplicación de cliente que está recibiendo cotizaciones de bolsa de valores puede desear sólo la última cotización de bolsa de valores. De este modo, si el servidor alterno 410 de inserción es incapaz de distribuir la cotización de bolsa de valores al cliente 140 de inserción y una cotización de bolsa de valores posterior se recibe de un proveedor 110 de contenido, los metadatos dentro de la cotización de bolsa de valores posterior pueden indicar que ésta debe utilizarse para reemplazar la cotización de bolsa de valores previa. El reemplazo de la información almacenada en lugar de agregar toda la información a una cola de distribución libera espacio dentro del almacén 480 de contenido . El depósito 470 de metadatos de canal se utiliza para almacenar los metadatos de canal, los cuales se describen en mayor detalle en lo siguiente. Lo anterior describe un servidor alterno 410 de inserción ejemplar que puede utilizarse con el método y sistemas en la presente. Los bloques y elementos del servidor alterno 410 de inserción permiten que el servidor alterno 410 de inserción se utilice en un sistema genérico de distribución de contenido dinámico donde el tipo de contenido y manejo de contenido en una aplicación pueden variar y no se predeterminan . Ahora se hace referencia a la Figura 5. La Figura 5 ilustra un cliente 510 de inserción que puede utilizarse junto con el sistema y métodos en la presente. El cliente 510 de inserción puede ser el mismo que el cliente 140 de inserción de las Figuras 1 y 2. Como se apreciará por aquellos con experiencia en la técnica, un cliente 510 de inserción que va a utilizarse en un sistema genérico en el cual el contenido y procesamiento del contenido no se predeterminan debe incluir bloques o módulos que puedan utilizarse para acomodar el contenido y los metadatos asociados con el contenido. Los bloques definidos con respecto a la Figura 5 no están hechos para ser exhaustivos, y otros bloques podrían existir también dentro de un cliente 510 de inserción. Además, los bloques dentro del cliente 510 de inserción en algunos casos, pueden omitirse sin restringir la funcionalidad de los otros bloques dentro del cliente 510 de inserción. Un cliente 510 de inserción provee servicio a aplicaciones, y una o más aplicaciones 512 pueden registrarse con el cliente 510 de inserción. El registro de aplicación utiliza una interfaz 514 de proveedor de aplicación como la interfaz para el registro y la interfaz 514 de proveedor de aplicación puede utilizarse además para extraer los metadatos de canal para la aplicación, como se describe en mayor detalle en lo siguiente. El cliente 510 de inserción incluye la administración 520 de cliente utilizada para administrar el cliente 510 de inserción. Como con el servidor 410 de inserción de la Figura 4, el cliente 510 de inserción incluye varios bloques que se encargan del mensaje, varios bloques que se encargan de los metadatos, y varios bloques que se encargan de la mensajería y los metadatos. Las colas 540 del intermediario de mensajes y de aplicación manejan los mensajes del servidor alterno 410 de inserción para la distribución de las aplicaciones 512. Una cola de aplicación es una cola de mensajes para aplicaciones 512. El bloque 542 de manejo de control de flujo se utiliza para notificar al servidor alterno 410 de inserción de la Figura 4 para detener la inserción de contenido o para retomar la inserción de contenido. Esto puede utilizarse por ejemplo, cuando el cliente 510 de inserción tiene una cantidad limitada de memoria que puede aceptar contenido insertado. En este caso, antes de que el contenido de inserción se consuma, el cliente 510 de inserción necesita detener el flujo de contenido del servidor alterno 410 de inserción. Una vez que se ha consumido el contenido, el bloque 542 de manejo de control de flujo puede utilizarse para comenzar el flujo de datos nuevamente. Los agentes 544 de inserción dentro del cliente 510 de inserción se utilizan para recibir información del servidor alterno 410 de inserción de la Figura 4. Como se apreciará por aquellos con experiencia en la técnica, las colas 540 de intermediario de mensajes y de aplicación, el bloque 542 de manejo de control de flujo y los agentes 544 de inserción se encargan exclusivamente de la mensajería y no de los metadatos. El bloque 550 de memoria caché y extractor de metadatos de contenido se utiliza para extraer metadatos dinámicos destinados para el cliente 510 de inserción. Como se indica en lo anterior con referencia al servidor alterno 410 de inserción de la Figura 4, cualquiera de los elementos de procesamiento en la arquitectura de distribución de contenido dinámico podría tener metadatos destinados para los mismos y estos metadatos necesitan extraerse. De este modo, los metadatos destinados para el cliente 510 de inserción se extraen por el bloque 550 de memoria caché y extractor de metadatos de contenido. Además, el bloque 550 de memoria caché y extractor de metadatos de contenido de preferencia se adapta para guardar en memoria caché los metadatos. Los metadatos para el cliente 510 de inserción que no cambian entre un primer paquete de contenido y un segundo paquete de contenido no necesitan pasarse, ahorrando tiempo de procesamiento del cliente 510 de inserción al no requerir la extracción de estos metadatos, y además ahorrando recursos de red al no requerir que metadatos para el cliente 510 de inserción se pasan sobre la red 130 inalámbrica. El gestor 552 de recuperación diferida se utiliza para analizar fragmentos de contenido que se reciben y organizan el contenido en forma correcta. Como se describe en mayor detalle en lo siguiente, los datos pueden ser ya sea lineales o no lineales. Si los datos son no lineales, entonces los metadatos se requieren para poder reconstituirlos, y esto se hace por el gestor 552 de recuperación diferida. El gestor 552 de recuperación diferida también se adapta para analizar un compendio de información disponible en el almacén 452 de recuperación diferida del servidor alterno 510 de inserción e impulsa el intermediario 554 de extracción de contenido (descrito en lo siguiente) para recuperar esa información cuando se requiera por el usuario. Esto incluye recuperación predictiva cuando la navegación de contenido entra a una cierta rama de la gráfica de estructura de contenido o cuando el ancho de banda o condiciones de costo se satisfacen. El intermediario 554 de extracción de contenido se utiliza en un modelo de inserción/extracción donde el cliente 510 de inserción también es capaz de extraer contenido en ciertas situaciones. Tales situaciones se describen en lo siguiente en mayor detalle con referencia a la Figura 19. Como se apreciará por aquellos con experiencia en la técnica, el bloque 550 de memoria caché y extractor de metadatos de contenido, el gestor 552 de recuperación diferida y el intermediario 554 de extracción de contenido se encargan del contenido de mensajes y de los metadatos. El bloque 560 de manejo de suscripción es el mismo que el bloque 460 de suscripción y reglas de la Figura 4.

Específicamente, el bloque 560 de manejo de suscripción se utiliza para manejar suscripción. Si una aplicación se desregistra o se borra de un dispositivo móvil entonces el bloque 560 de manejo de suscripción finaliza la suscripción. El bloque 560 de manejo de suscripción también puede resuscribirse a nombre de una aplicación de cliente cuando expire el canal de suscripción. El bloque 562 de notificación de actualización funciona con las aplicaciones del cliente y se utiliza para notificar a las aplicaciones que el nuevo contenido está esperándolas. Esto puede hacerse en una de tres formas: d. Una primera forma que el bloque 562 de notificación de actualización puede notificar a una aplicación 512 es que el cliente 510 de inserción envíe el contenido a la aplicación 512 directamente . e. Una segunda forma que el bloque 562 de notificación de actualización puede notificar a las aplicaciones 512 del nuevo contenido es que almacene el contenido en el almacén 580 de contenido y que notifique opcionalmente a las aplicaciones que el contenido está esperando. La notificación en este caso es opcional. Específicamente, si una aplicación 512 sabe qué información destinada para la misma se almacena dentro de un bloque de memoria especifico, una opción para que la aplicación descubra que tiene nuevos datos es consultar periódicamente la ubicación de memoria para ver si existe algo qué escribir en la misma. Alternativamente, el bloque 562 de notificación de actualización puede enviar un mensaje a la aplicación 512 indicando que tiene nuevos datos y posiblemente la ubicación en la que se almacenan los datos, f. Una tercera forma que la notificación 562 de actualización puede notificar a las aplicaciones 512 del nuevo contenido es que almacenen contenido internamente y notifiquen la aplicación. La aplicación entonces puede pedir que el cliente de inserción recupere el contenido . El bloque 564 de dependencia de contenido es el mismo que el bloque 462 de dependencia de contenido de la Figura 4, y puede determinar si anunciar el servicio al dispositivo móvil. El bloque 566 de expiración de contenido y reemplazo es el mismo que el bloque 466 de expiración de contenido y reemplazo de la Figura 4. La expiración de contenido y el reemplazo de contenido de este modo pueden manejarse en el cliente 510 de inserción además del servidor de inserción o servidor alterno de inserción. El depósito 570 de metadatos de canal se utiliza para almacenar metadatos de canal para la aplicación 512. El módulo 575 de procesamiento de actualización de antecedentes se utiliza para realizar actualizaciones cuando no está disponible una aplicación 512. La actualización de antecedentes permite, por ejemplo, el reemplazo de datos con datos más nuevos dentro del almacén de aplicaciones. Después de esto, cuando un usuario comienza la aplicación, los datos desplegados por la aplicación son corregidos y se actualizan. El módulo 575 de procesamiento de actualización de antecedentes utiliza las reglas de procesamiento para traducir el contenido en un formato aceptable para una aplicación. Puede ejecutar y procesar contenido en el almacén 580 de contenido. Por medio del ejemplo, una lista de tareas que se actualiza para un contratista durante la noche puede tener tareas insertadas en el mismo. La aplicación de tareas no se inicia durante este tiempo, y el módulo 575 de procesamiento de actualización de antecedentes puede utilizarse para actualizar el contenido para la aplicación de tareas. Esto podría hacerse con el código para manejar un archivo de lenguaje de marcación extensible (XML) , y podría existir en el dispositivo en un archivo llamado "handler.exe". El bloque 575 de procesamiento de actualización de antecedentes en el cliente 510 de inserción puede ejecutar handler.exe, pasando el documento de XML teniendo un parámetro. El gestor entonces construye la tarea en el formato interno de la aplicación. Una vez que el bloque 575 de procesamiento de actualización de antecedentes del cliente 510 de inserción construye la tarea en el formato interno de la aplicación, entonces puede leer la tarea en la lista de tareas del almacén 580 de contenido y anexar la nueva tarea a la lista. Entonces puede almacenar los antecedentes modificados en el almacén 580 de contenido para cuando la siguiente aplicación de tarea se conecte al cliente 510 de inserción. La Figura 5 por lo tanto ilustra un cliente 510 de inserción que puede utilizarse en un sistema genérico de distribución de contenido dinámico, donde el contenido y procesamiento del contenido es dinámico y no predeterminado. Los bloques descritos en lo anterior con referencia al cliente 510 de inserción de la Figura 5 se utilizan para acomodar la naturaleza dinámica del sistema. Como se indica en lo anterior con referencia a la Figura 3, el contenido se asocia con los metadatos para proporcionar inteligencia para el procesamiento de contenido. De acuerdo con el presente método y sistema, lo$ metadatos pueden dividirse en dos tipos de metadatos. Específicamente, metadatos estáticos (de canal) y metadatos dinámicos (de contenido) . Debido a las posibilidades ilimitadas de tipos de proveedores de contenido y aplicaciones, los metadatos son críticos para poder construir sistemas genéricos. La única forma de manejar el tipo específico de contenido es a través de metadatos. Los metadatos estáticos son metadatos que proporcionan reglas en cuanto a cómo procesar los tipos específicos de contenido. Los metadatos estáticos pueden descomponerse en varios niveles de abstracción e incluyen, por ejemplo, información estructural sobre el contenido mismo. Por ejemplo, un documento de Afiliación Simple en Tiempo Real (RSS) puede distribuirse con una estructura de RSS 2.0.XSD, y todo el contenido de ese proveedor de contenido se distribuirá con esta estructura. Un nivel adicional de abstracción para los metadatos estáticos incluye la provisión de reglas de procesamiento para el subtipo de contenido. Este podría ser la aplicación específica. De este modo, por ejemplo, una indicación de noticias financieras indica que los datos deben extraerse de una corriente de RSS de noticias financieras, almacenada en una ubicación predefinida, y que la aplicación debe notificarse sobre la llegada de la información. La aplicación siempre requiere que el contenido destinado para la misma sea manejado de esta forma.

Los metadatos estáticos (también referidos en la presente como metadatos de canal) permanecen iguales a través de la suscripción entre la aplicación y el proveedor de contenido, y de este modo los metadatos estáticos pueden establecerse una vez para cada elemento dentro de la arquitectura y para cada canal de distribución de contenido. En una modalidad, esto se hace al momento del registro de la aplicación o el proveedor de contenido. Los metadatos dinámicos son metadatos que se asocian con una pieza particular de contenido. Por ejemplo, la información de expiración asociada con una pieza particular de datos o reglas de reemplazo e información asociada con una pieza particular de datos (es decir, el documento K reemplaza al documento L) . Como se indica en lo anterior con referencia a las Figuras 4 y 5, cada entidad de procesamiento puede recibir metadatos estáticos y dinámicos que se dirigen a esa entidad de procesamiento. De este modo, el servidor alterno 410 de inserción utiliza el bloque 450 de memoria caché y extractor de metadatos de contenido para extraer los metadatos dinámicos, y el bloque 466 de expiración de contenido y reemplazo se utiliza para reemplazar el contenido no distribuido con contenido más nuevo recibido en el servidor alterno 410 de inserción. Ahora se hace referencia a la Figura 6. La Figura 6 ilustra un modelo de envoltura estratificada para metadatos de contenido. Un servidor alterno 410 de inserción recibe una envoltura 610 de inserción que incluye metadatos 612 de procesamiento de contenido para el servidor de inserción y una envoltura 614 de cliente de inserción. El servidor alterno 410 de inserción extrae los metadatos 612 de procesamiento de contenido y utiliza estos metadatos para procesar la envoltura 614 de cliente de inserción. Los metadatos 612 dictan lo que el servidor alterno de inserción hace con la envoltura 614 de cliente de inserción. La envoltura 614 de cliente de inserción se pasa al cliente 510 de inserción donde se descompone en una envoltura 620 de contenido y metadatos 622 de procesamiento de contenido. Los metadatos 622 de procesamiento de contenido se utilizan por el cliente 510 de inserción para procesar la envoltura 620 de contenido. Por ejemplo, esto puede utilizarse para instruir al cliente 510 de inserción que realice el reemplazo de la envoltura 620 de contenido previamente distribuida con la última envoltura si la aplicación 150 de cliente sólo está interesada en la última versión del contenido. La envoltura 620 de contenido se pasa a la aplicación 150 de cliente. La envoltura 620 de contenido incluye metadatos 630 de procesamiento de contenido para la aplicación y la carga útil 632 de contenido que se consumirá por la aplicación 150 de cliente. Como se apreciará por aquellos con experiencia en la técnica, la subdivisión de envolturas de acuerdo con la Figura 6 proporciona un ambiente dinámico rico en el cual puede presentarse el procesamiento en cualquier elemento de procesamiento de la arquitectura y cuál proveedor 110 de contenido puede especificar cómo será tratado el contenido especifico. En una modalidad, los metadatos dirigidos a un elemento lógico particular se opacan en otros elementos de procesamiento. Alternativamente, el proveedor 120 de servicio también puede agregar metadatos en el servidor alterno 410 de inserción para su procesamiento en el cliente 510 de inserción o aplicación 150 de cliente. Con referencia a la Figura 7, esta figura muestra el modelo de envoltura de la Figura 6 y las etapas que cada elemento de procesamiento toma con la envoltura. Como se ilustra en la Figura 7, el servidor alterno 410 de inserción primero extrae los metadatos de la envoltura 610 de inserción. Esto se hace en la etapa 710. En la etapa 712, el servidor alterno 410 de inserción utiliza los metadatos para procesar la envoltura 614 de cliente de inserción. En la etapa 714, el servidor alterno 410 de inserción distribuye la envoltura 614 de cliente de inserción al cliente 510 de inserción. Similarmente, el cliente 510 de inserción, en la etapa 720 extrae los metadatos 622 de procesamiento de contenido de la envoltura 614 de cliente de inserción. En la etapa 722, el cliente 510 de inserción utiliza los metadatos 622 de procesamiento de contenido en la envoltura 620 de contenido. En la etapa 724, el cliente 510 de inserción distribuye la envoltura 620 de contenido a la aplicación 150 de cliente. En la etapa 730, la aplicación 150 de cliente extrae los metadatos 630 de procesamiento de contenido y en la etapa 732 utiliza los metadatos 630 de procesamiento de contenido en la carga útil 632 de contenido. Con referencia a la Figura 8, esta figura muestra el método como se ilustra en la Figura 7 con la etapa adicional del uso de metadatos estáticos o de canal. Específicamente, después de que los metadatos se han extraído en la etapa 710 de la envoltura 610 de inserción, el servidor alterno 410 de inserción después utiliza los metadatos de canal estáticos para procesar la envoltura de cliente de inserción en la etapa 810. En la etapa 712, el servidor alterno 410 de inserción después procesa los metadatos 612 dinámicos de procesamiento de contenido. El servidor alterno 410 de inserción después distribuye la envoltura 614 del cliente de inserción en la etapa 714.

Similarmente, el cliente 510 de inserción extrae los metadatos 622 de procesamiento de contenido en la etapa 720. El cliente 510 de inserción entonces utiliza los metadatos de canal en la etapa 820 en el contenido dentro de la envoltura 620 de contenido. El cliente 510 de inserción entonces, en la etapa 722, utiliza los metadatos de contenido dinámicos en los metadatos 622 de procesamiento de contenido antes de la distribución de la envoltura 620 de contenido a la aplicación 150 de cliente en la etapa 724. La aplicación 150 de cliente primero extrae, en la etapa 730, los metadatos 630 de procesamiento de contenido. Después utiliza los metadatos de canal en la etapa 830 en la carga útil 632 de contenido. La aplicación 150 de cliente entonces utiliza, en la etapa 732, los metadatos 630 de procesamiento de contenido en la carga útil 632 de contenido. Como se apreciará por aquellos con experiencia en la técnica, el modelo anterior por lo tanto permite que metadatos estáticos se apliquen para el canal junto con los metadatos dinámicos que se asocian con el contenido particular que se envía. Ahora se hace referencia a la Figura 9. Como se apreciará a partir de la Figura 5, el cliente 510 de inserción puede servir a múltiples aplicaciones 512 objetivo en un dispositivo móvil. Se requiere un mecanismo de registro de tiempo de ejecución donde las aplicaciones puedan registrarse con la estructura de distribución de contenido dinámico sin interrumpir el servicio para otras aplicaciones. Con referencia a la Figura 9, el cliente 510 de inserción incluye tres aplicaciones, específicamente aplicaciones 910, 912 y 914 que ya están registradas con el cliente de inserción. Como se apreciará, el modelo de conexión es importante debido a que nuevos dispositivos pueden permitir que tipos de aplicación ilimitados se instalen en el dispositivo. Además, aplicaciones pueden instalarse dinámicamente, llevando a un dispositivo móvil que se vuelve una plataforma de aplicación. Debido a que el dispositivo puede ser una plataforma de aplicación, debe ser capaz de incorporar dinámicamente nuevas aplicaciones. Como se ve en la Figura 9, la aplicación 916 desea registrarse con el cliente 510 de inserción. La aplicación 916 incluye un manifiesto 918 de aplicación que, en una modalidad preferida, proporciona los metadatos de canal para la aplicación. Específicamente, el manifiesto 918 de aplicación proporciona información al cliente 510 de inserción, y al final el servidor alterno 410 de inserción y el proveedor 110 de contenido de la Figura 1 con los metadatos estáticos para la aplicación. Esto puede incluir, pero no se limita a, qué tipo de contenido espera la aplicación, cómo el contenido se distribuirá, si la aplicación necesita notificación, u otra información de canal que puede ser evidente para aquellos con experiencia en la técnica que tienen con respecto al presente sistema y método. La aplicación 916 por lo tanto se registra con el cliente 510 de inserción, proporcionando el manifiesto 918 de aplicación para establecer un canal en un proveedor de contenido para la aplicación 916 de servicio. Con referencia a la Figura 10, un modelo alternativo puede ser el modelo descrito con respecto a la arquitectura 220 de la Figura 2. Específicamente, en el modelo de la Figura 10, una aplicación 150 de cliente se empareja con un cliente 140 de inserción. Cada uno de los pares de aplicación 150 de cliente/cliente 140 de inserción se coordina con un contenedor 1010 de inserción. Cuando la aplicación 1020 desea registrarse con el contenedor 1010 de inserción, un cliente 140 se crea, o si ya existe se utiliza, por el contenedor 1010 de inserción. Además, en el registro, la aplicación 1020 proporciona un manifiesto 1030 de aplicación en el contenedor 1010 de inserción, proporcionando así los metadatos de canal (metadatos estáticos) para la aplicación 1020. Una ilustración alternativa de la Figura 10 se muestra en la Figura 11. Específicamente, un contenedor 1110 de inserción mane a/mantiene un grupo de clientes de inserción. Cuando una aplicación se registra con el contenedor obtiene un cliente 510 de inserción dedicado, el cual en el caso simple puede representarse por un par de oyentes 1130 de conexión y gestor de contenido. El cliente de inserción se regresa al grupo cuando la aplicación se desregistra del contenedor (y el servicio de distribución de contendor) o se borra del dispositivo. El contenedor 1110 de inserción incluye conexiones 1120 para comunicación. Además, el contenedor 1110 de inserción incluye oyentes 1130 de conexión y procesadores 1140 de contenido asignados a una conexión particular. Como se ve en la Figura 11, varios pares de procesador de contenido y oyente de conexión se utilizan por las aplicaciones 150 previamente registradas. Cuando una nueva aplicación 1150 desea registrarse con el contenedor 1110 de inserción, un nuevo procesador 1120 de contenido y oyente 1130 de conexión se asignan a la aplicación 1050 de servicio. Lo anterior por lo tanto proporciona una estructura de inserción genérica en la cual una aplicación 150 de cliente que es nueva puede incrementarse y registrarse con un cliente 510 de inserción o contenedor 1010 ó 1110 de inserción, permitiendo asi que el dispositivo se vuelva una plataforma de aplicación capaz de incorporar dinámicamente nuevas aplicaciones. El paso de un manifiesto 1030 ó 918 de aplicación de las Figuras 9 y 10 permite el establecimiento de metadatos de canal, permitiendo asi que el contenido se procese de acuerdo con los requerimientos de la aplicación. Con referencia a la Figura 12, los proveedores 110 de contenido símilármente necesitan registrarse con un servidor alterno 410 de inserción. Como se ve en la Figura 12, el servidor alterno 410 de inserción incluye tres proveedores de contenido, particularmente, 1210, 1212 y 1214, ya registrados con el servidor alterno 410 de inserción. El proveedor 1216 de contenido desea registrarse con el servidor alterno 410 de inserción. Similarmente al manifiesto 918 de aplicación ilustrado en la Figura 9 proporcionado por una aplicación 916 cuando se registra con el cliente 510 de inserción, el proveedor 1216 de contenido incluye un manifiesto 1218 de servicio que se pasa al servidor alterno 410 de inserción cuando el proveedor 1216 de contenido se registra. El manifiesto 1218 de servicio incluye información con respecto al tipo de información que proporcionará el proveedor de contenido, 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 la publicidad del servicio. Otra información es posible. El servidor alterno 410 de inserción de este modo utiliza el manifiesto 1218 de servicio para establecer los metadatos de canal (estáticos) para el proveedor 1216 de contenido.

Con referencia a la Figura 13, una modalidad alternativa, representada por la arquitectura 230 de la Figura 2, es tener un contenedor de inserción con un cierto número de pares de servidores alternos 122 de inserción y proveedor 110 de contenido. Como con la Figura 12, varias aplicaciones pueden ya sea registrarse con el contenedor 1310 de inserción, y en el ejemplo de la Figura 12, aplicaciones 1312, 1314 y 1316 ya se registran con los servidores alternos 1313, 1315 y 1317 de inserción, respectivamente. Una nueva aplicación 1320 desea registrarse con el contenedor 1310 de inserción. De este modo, el contenedor 1310 de inserción crea un nuevo servidor alterno (no mostrado) o utiliza un servidor alterno (no mostrado) existente con el cual asocia el proveedor 1320 de contenido. Además, el proveedor 1320 de contenido proporciona el manifiesto 1322 de servicio para describir el contenido que el proveedor 1320 de contenido estará proporcionando, permitiendo asi el establecimiento de los metadatos de canal. Como se apreciará por aquellos con experiencia en la técnica, las modalidades de las Figuras 9 y 10 muestran dos opciones para los clientes de inserción, ya sea con aplicaciones compartidas o con clientes de inserción dedicados por aplicación. Alguien con experiencia en la técnica se dará cuenta que otras modalidades son posibles. Similarmente, con respecto a las Figuras 12 y 13, un servidor alterno de inserción con múltiples proveedores de contenido registrados con el mismo se muestra o un servidor alterno de inserción dedicado para cada proveedor de contenido, y representado en un contenedor de inserción se muestra. Con referencia a la Figura 14, se muestra la mensajería entre un proveedor 110 de contenido y una aplicación 150 de cliente. El proveedor 110 de contenido proporciona un mensaje de registro al servidor alterne 410 de inserción. Este mensaje puede- incluir el manifiesto de servicio que puede utilizarse para proporcionar los metadatos de canal al servidor alterno 410 de inserción. Esto se hace en la etapa 1410. El proveedor 110 de contenido también puede o alternativamente proporciona metadatos de canal en un mensaje subsiguiente, como se ilustra por la etapa 1412. El servidor alterno 410 de inserción entonces agrega un servicio a una lista de servicios disponibles (el catálogo de servicio) en la etapa 1414. Una etapa opcional en el ejemplo de la Figura 14 es que el servidor alterno 410 de inserción notifica al cliente 510 de inserción del nuevo servicio disponible en la etapa 1416 y esta notificación puede propagarse a una aplicación 110 de cliente en la etapa 1418. Como se apreciará por aquellos con experiencia en la técnica, las etapas 1416 y 1418 son opcionales, y otras alternativas incluyen aplicación 150 de cliente que extrae el catálogo de servicio periódicamente del servidor alterno 410 de inserción para ver nuevos servicios. Cuando un usuario o proveedor de servicio para la aplicación 150 de cliente decide que la aplicación 150 de cliente debe suscribirse a un servicio, envía un mensaje de suscripción en la etapa 1420. El mensaje de suscripción además se pasa al servidor alterno 410 de inserción en la etapa 1422. Una vez que el servidor alterno 410 de inserción recibe el mensaje de suscripción en la etapa 1422, dos opciones están disponibles. Una primera opción es enviar un mensaje 1424 al proveedor 110 de contenido para una suscripción y después recibir un sobre con mensaje que incluye los metadatos nuevamente en la etapa 1426. Los metadatos podrían ser el dispositivo o tipo de dispositivo específico . Alternativamente, el servidor alterno 410 de inserción puede recibir el mensaje de suscripción en la etapa 1422 e inmediatamente, basándose en la información ya proporcionada por el proveedor 110 de contenido y almacenada en el servidor alterno 410 de inserción, la respuesta en la etapa 1430 para el cliente 510 de inserción. Esa respuesta se propaga a la aplicación 150 de cliente en la etapa 1532. Como se apreciará, la respuesta puede incluir los metadatos de canal específicos para el proveedor 110 de contenido. La diferencia en los modelos puede ser dependiente de quién está personalizando los datos para la aplicación. Como se apreciará, el proveedor 110 de contenido proporciona la mejor personalización de contenido comparada con otros elementos de procesamiento. Sin embargo, el proveedor 120 de servicio, a través del servidor alterno 410 de inserción, también puede proporcionar personalización de contenido. Además, como se apreciará, la estructura del contenido puede ser dependiente de los datos que requiere la aplicación. Por ejemplo, en una aplicación financiera, la aplicación puede desear cotizaciones de bolsa de valores y cambio de divisas. El siguiente XML puede utilizarse: <FIN> <quotes> <quote ticker = ABO 18.54 </quote> <quote ticker = XYZ> 123.45 <quote> </quotes> <rates> <rate id = "US-CAN"> 1.15 </rate> <rate id = "US-EURO"> 0.85 </rate> </rates> </FIN> Si el usuario sólo desea cotizaciones y ningún cambio de divisa, la estructura puede cambiar a: <FIN> <quote ticker = ABO 18.54 </quote> <quote ticker = XYZ> 123.45 </quote> </FIN> Los metadatos pueden proporcionar información a la aplicación sobre la estructura de los datos que se están pasando . De este modo, existen dos modelos. Los metadatos estáticos pueden proporcionarse al servidor alterno 410 de inserción y al cliente 510 de inserción ya sea durante el registro o después. Alternativamente, los metadatos para el servidor alterno 410 de inserción y el cliente 510 de inserción pueden pre-aprovisionarse, es decir, la información se almacena en un cliente de inserción o servidor alterno de inserción hasta que una aplicación se registra con un cliente . Ahora se hace referencia a la Figura 15. La Figura 15 muestra etapas lógicas que se presentan con el registro de una aplicación con cliente 510 de inserción. Una vez que una aplicación se registra con el cliente 510 de inserción, una primera etapa 1510 es correlacionar la aplicación registrada con el tipo de contenido requerido por la aplicación. Esto se conoce a partir del manifiesto 918 de aplicación como se ilustra en la Figura 9. Una segunda etapa 1520 es establecer el ambiente para la aplicación. Este incluye pero no se limita a opciones de almacenamiento y distribución para la aplicación. Por ejemplo, una aplicación puede limitar las transmisiones a una cantidad predeterminada de datos. El cliente 510 de inserción es un evento de control de flujo, o si la aplicación o cliente está fuera de alcance, puede requerir el guardado en memoria caché de los datos para la aplicación y opcionalmente notificar a la aplicación qué datos están esperando. Una tercera etapa 1530, es notificar al servidor alterno 410 de inserción de los ajustes de aplicación. Esto incluye por ejemplo almacenamiento disponible para la aplicación o cliente 510 de inserción. Como se apreciará, el servidor alterno 410 de inserción no debe insertar más datos de los que puede almacenar el cliente 510 de inserción. De este modo, los ajustes de aplicación pueden incluir un limite superior de los datos que se pasan. Con referencia a las Figuras 4 y 5, esto puede invocar al bloque 464 de fragmentación de contenido para fragmentar el contenido si es mayor que la aplicación que puede procesar. También, si los datos no son lineales, se puede requerir que el bloque 462 de dependencias de contenido cree metadatos para el bloque 564 de dependencias de contenido de la Figura 5 para permitir que el bloque 564 de dependencias de contenido reconstituya los datos . Con referencia nuevamente a la Figura 15, la etapa 1530 también puede indicar preferencias sobre la distribución de los datos. Por ejemplo, la aplicación puede preferir ciertos tipos de datos sobre otros y a estos tipos de datos se les puede dar prioridad. De este modo, la etapa 1530 puede utilizarse para establecer un programa de distribución donde los datos de tipo "A" se distribuyen inmediatamente mientras los datos de tipo "B" pueden distribuirse en un momento diferido . Ahora se hace referencia a la Figura 16. Cuando un proveedor 110 de contenido se registra con un servidor alterno 410 de inserción, se realizan varias etapas. Una primera etapa 1610 incluye analizar los ajustes de cliente requeridos para el almacenamiento y distribución de contenido. Esto puede utilizarse por ejemplo, para la publicidad de servicio para poder identificar clientes 510 de inserción sobre dispositivos capaces de consumir contenido del proveedor 110 de contenido. Una segunda etapa 1620 permite que el servidor alterno 410 de inserción establezca el ambiente, que incluye almacenamiento de servidores alternos, opciones de distribución, opciones de transformación, entre otras. En la etapa 1630, el servidor alterno 410 de inserción puede comprobar si la aplicación ya se registró para obtener contenido de un proveedor 110 de contenido. Si éste es el caso, la aplicación está lista para recibir contenido y una notificación del servidor alterno 410 de inserción para el proveedor 110 de contenido de que el canal de distribución se establece y la aplicación está lista para que el contenido pueda enviarse. La etapa 1630 puede presentarse, por ejemplo, si una aplicación se preinstala en un dispositivo antes de que el proveedor 110 de contenido entre en linea. De este modo, la aplicación está esperando que el proveedor 110 de contenido se vuelva disponible o la aplicación sea de tipo genérico (por ejemplo, navegador o Visualizador de RSS) y sea capaz de consumir información de múltiples proveedores de contenido. En un ajuste alternativo, si el proveedor 110 de contenido ya está disponible antes de que la aplicación se instale, la etapa 1530 de notificación de la Figura 15 puede utilizarse para iniciar el inicio de contenido para fluir desde el proveedor 110 de contenido hasta una aplicación 150 de cliente. Como se apreciará con referencia a la Figura 16, los ajustes de cliente pueden incluir cierta información tal como el tamaño de almacenamiento disponible utilizado para la división de contenido, el tamaño de la cola utilizado para el control de flujo, la programación de distribución que incluye un intervalo de inserción, si el cliente esté recuperando información del servidor alterno, crear un modo de seudo-inserción, opciones de personalización tal como el tamaño de la pantalla de un dispositivo móvil, entre otros. Como se apreciará además, los catálogos de servicio pueden diferir para diferentes clientes. 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 contenido que un dispositivo que no puede manejar esta cantidad de información, y un tamaño de pantalla más pequeño, etc. De este modo, el servidor alterno 410 de inserción puede crear un catálogo de servicio para aplicaciones de cliente especificas basándose en el conocimiento de estas aplicaciones de cliente, y solamente aquellos dispositivos con esa aplicación 150 de cliente instalada pueden recibir información con respecto al proveedor de contenido. Como se apreciará adicionalmente , en algunos casos, la aplicación puede instalarse basándose en un proveedor de servicio y proveedor de contenido sin intervención del usuario. Por ejemplo, si el proveedor 110 de contenido se registra con el servidor alterno 410 de inserción, un usuario de un dispositivo móvil puede tener una obligación de contrato para aceptar una cierta aplicación. De este modo, el servidor alterno 410 de inserción puede notificar al cliente 510 de inserción que está listo para instalar una aplicación e insertar la aplicación en el cliente 510 de inserción. Esto por ejemplo, puede incluir un usuario que ha estado de acuerdo en recibir un cierto número de anuncios cada mes para poder obtener una tarifa preferida sobre su plan móvil. El proveedor 110 de contenido puede ser un proveedor de anuncios y el servidor alterno 410 de inserción puede insertar por lo tanto una aplicación de visualización de publicidad en el cliente 510 de inserción, el cual puede ser servido por un instalador de aplicación registrado con el cliente 410 de inserción, haciendo por consiguiente que el proveedor 110 de contenido y el proveedor 120 de servicio dirijan totalmente el proceso. Lo anterior por lo tanto proporciona un modelo de registro de conexión en una estructura de inserción donde cada aplicación o proveedor de contenido se registra y proporciona un manifiesto de aplicación o manifiesto de servicio respectivamente. El manifiesto de aplicación o el manifiesto de servicio se utilizan para establecer los metadatos de canal en el servidor alterno 410 de inserción y el cliente 510 de inserción ya sea durante el registro o después. Después de esto, cuando una aplicación 150 se registra y un proveedor 110 de contenido se registra, el contenido puede comenzar a fluir entre la aplicación 150 y el proveedor 110 de contenido. Con referencia a las Figuras 4 y 5, los metadatos de canal se almacenan en un depósito 470 y 570 de metadatos de canal. Sin embargo, también es ventajoso almacenar metadatos dinámicos en los diversos elementos de procesamiento dentro de la arquitectura 100 si se repiten los metadatos dinámicos. Como se apreciará, esto ahorrará procesamiento sobre el servidor alterno 410 de inserción puesto que el extractor 450 de metadatos actual no necesita extraer los mismos metadatos una y otra vez. Además, el procesamiento por varios módulos, tal como el módulo 466 ó 566 de expiración de contenido y reemplazo no necesitan actualizarse por cada pieza de contenido que se pasa. Puesto que el servidor alterno 410 de inserción puede estar trabajando con un gran número de clientes 510 de inserción, este ahorro de procesamiento para cada mensaje de contenido puede ser importante. Además, el ancho de banda puede ahorrarse al no tener que pasar los metadatos sobre una linea fija entre el proveedor 110 de contenido y el servidor alterno 410 de inserción o sobre el aire entre el servidor alterno 410 de inserción y el cliente 510 de inserción. Ahora se hace referencia a la Figura 17. La Figura 17 ilustra un ejemplo de un flujo de tiempo de ejecución donde su última versión de metadatos se almacena por el elemento de procesamiento. Como se ve en la Figura 17, el proveedor 110 de contenido proporciona un sobre de contenido que incluye el contenido [Ci+M (p, c, a) i] . Esto quiere decir que una primera carga útil de contenido se está enviando junto con los metadatos que incluyen metadatos de servidor alterno, metadatos de cliente y metadatos de aplicación. Esto se envía en la etapa 1710. En la etapa 1712, el servidor alterno 410 de inserción utiliza los metadatos de servidor alterno como se ilustra por la frase "use M(p)i". Además, en la etapa 1714, el contenido más los metadatos que incluyen los metadatos de cliente y los metadatos de aplicación se pasan al cliente 510 de inserción. En la etapa 1716, el cliente 510 de inserción utiliza los metadatos de cliente y además en la etapa 1718, pasa la carga útil de contenido a la aplicación 150 de cliente. La aplicación 150 de cliente utiliza, en la etapa 1720, los metadatos de aplicación y además consume la carga útil de contenido. Como se ve en la etapa 1722, una segunda carga útil de contenido, designada por C2, tiene los mismos metadatos que la primera carga útil de contenido. Debido a que cada elemento de procesamiento, particularmente el servidor alterno 410 de inserción, el cliente 510 de inserción y la aplicación 150 de cliente, guardó en memoria caché los metadatos para el proveedor 110 de contenido, los metadatos no necesitan pasarse una vez más ya que de hecho residen ya en el elemento de procesamiento. Después de esto, en la etapa 1724, el servidor alterno 410 de inserción utiliza metadatos que se guardaron previamente en memoria caché para el servidor alterno 410 de inserción. Similarmente, en las etapas 1726 y 1728, el cliente 510 de inserción utiliza los metadatos de cliente y la aplicación 150 de cliente utiliza los metadatos de aplicación respectivamente. El contenido se pasa, sin metadatos, en las etapas 1725 y 1727. Como se ilustra en la etapa 1740, el contenido puede tener nuevos metadatos para el cliente 510 de inserción y la aplicación 150 de cliente, pero pueden mantener los metadatos antiguos para el servidor alterno 410 de inserción. En este caso, los metadatos que se pasan en la etapa 1740 incluyen sólo metadatos de cliente y metadatos de aplicación. En la etapa 1742, el servidor alterno 410 de inserción utiliza los metadatos de servidor alterno guardados en memoria caché y pasa la carga útil de contenido junto con los nuevos metadatos de cliente y los metadatos de aplicación en la etapa 1744. En la etapa 1746, el cliente 510 de inserción utiliza los nuevos metadatos de cliente que se pasaron al mismo y además pasa la carga útil de contenido y los metadatos de aplicación en la etapa 1748. En la etapa 1750, la aplicación de cliente utiliza los nuevos metadatos de aplicación y además consume la carga útil de contenido. Como se apreciará por aquellos con experiencia en la técnica, varias configuraciones pueden existir con respecto a cuáles metadatos han cambiado y cuáles metadatos siguen siendo iguales, y solamente los metadatos que han cambiado se pasan al elemento de procesamiento que los requiere. Como se apreciará por aquellos con experiencia en la técnica, el elemento de procesamiento, si no recibe nuevos metadatos, regresa los metadatos guardados en memoria caché que ha almacenado y utiliza éstos en la carga útil de contenido . En una modalidad alternativa adicional, los cambios en incremento también pueden hacerse a los metadatos. Por ejemplo, en la etapa 1760, una nueva carga útil de contenido junto con una versión de metadatos delta puede pasarse al servidor alterno 410 de servicio. La delta de los metadatos de servidor alterno puede incluir una diferencia entre los metadatos de servidor alterno previamente pasados y los metadatos actuales con los que debe procesarse el contenido. El servidor alterno 410 de inserción formula los metadatos al agregar los metadatos previos con la delta y después utilizar éstos para procesar la carga útil de contenido en la etapa 1762. Después de esto, puesto que no ha existido ningún cambio, en la etapa 1764 la carga útil de contenido se envía por sí misma y en la etapa 1766, el cliente 510 de inserción utiliza los metadatos de cliente previamente guardados en memoria caché. El cliente de inserción entonces pasa la carga útil de contenido en la etapa 1768 a la aplicación 150 de cliente, la cual utiliza los metadatos de ubicación previamente guardados en memoria caché sobre la carga útil de contenido en la etapa 1770 y después consume la carga útil de contenido. Un ejemplo de dónde los datos en incremento pueden utilizarse es una situación en la cual un proveedor de contenido dice al servidor alterno que de los campos existentes dentro de la carga útil de contenido, 30 deben extraerse para enviar a la aplicación 150 de cliente. En una transacción subsiguiente, dos campos adicionales que son importantes para esa pieza de carga útil de contenido pueden considerarse necesarios para pasarse a la aplicación 150 de cliente por el proveedor 110 de contenido. El proveedor de contenido por lo tanto, utilizando un cambio en incremento, puede decir al servidor alterno de inserción que extraiga los dos campos adicionales y los agregue a los 30 campos que se extrajeron previamente. Al hacer que sólo pase la delta, es decir, los dos campos adicionales, el tiempo de procesamiento para extraer los metadatos en el servidor alterno 410 de inserción se reduce, optimizando asi el proceso. Como se apreciará adicionalmente, los metadatos pueden venir en varias formas. Pueden compilarse como código natural o código interpretado tal como Java o C#. Los metadatos también pueden ser un archivo de datos/propiedades que indica utilizar ciertas propiedades. En otra modalidad alternativa, puede ser contenido binario, por ejemplo una transformación tal como una transformación de XSLT en un documento de XML. Lo anterior puede utilizarse para varias aplicaciones para proporcionar inteligencia para el contenido que se transfiere a una aplicación de cliente especifica. También puede proporcionar proveedores de contenido rico que pueden proporcionar contenido para varias aplicaciones basándose solamente en los metadatos que se proporcionan con sus datos. Esto puede ilustrarse por medio del ejemplo en la Figura 18. Un proveedor 110 de contenido por ejemplo, puede ser un vendedor de libros en linea. Una aplicación puede registrarse con el vendedor de libros en linea para indicar que el vendedor de libros en linea desea ser informado de nuevas puestas en circulación de un género especifico. Esto puede presentarse en una base diaria o semanal o mensual. El proveedor 110 de contenido, por ejemplo en una base semanal enviará un sobre 1810 de contenido que tiene una lista 1812 de libros, al servidor alterno 410 de inserción. También puede enviar metadatos 1814 de transformación, los cuales por ejemplo, pueden ser un enlace de URL para transformar el contenido especifico basándose en la aplicación que recibe. En una modalidad, la lista 1812 de libros puede incluir numerosos libros, descripciones de cada libro que incluyen el autor y una sinopsis del libro. El archivo por ejemplo, puede ser de 100 KB de tamaño. El servidor alterno 410 de inserción puede recibir este gran archivo y puede darse cuenta, basándose en la aplicación de cliente que es servida, que una transformación para el archivo de contenido grande necesita hacerse para poder adaptar mejor al cliente que sólo puede ser capaz de recibir, por ejemplo 10 Kilobytes de información. La transformación que se pasa como metadatos de servidor alterno puede aplicarse por lo tanto a la lista de libros para reducir la lista de libros a un documento 1820 modificado de 10 KB. Por ejemplo, esto puede hacerse al eliminar la sinopsis, clasificar los libros y solamente incluir los 50 primeros u otras transformaciones como puede ser evidente para aquellos con experiencia en la técnica. Una vez que está completa la transformación, el documento 1820 modificado entonces se envía al cliente 510 de inserción. Además, el almacén 452 de mensajes de recuperación diferida, como se ve en la Figura 4, puede utilizarse para almacenar el contenido extra que se descompuso 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. Puesto que varios clientes no serán clientes inalámbricos móviles, el archivo de 100 KB puede ser apropiado para estos clientes. También al proporcionar los metadatos de transformación, el vendedor de libros puede tener una lista que envía a cada uno. Como se apreciará por aquellos con experiencia en la técnica, tecnologías Web más actuales requieren de un sitio Web separado para un cliente móvil, y esto se supera por la solución anterior. Lo anterior también se presta para un modelo de afiliación y ahora se hace referencia a la Figura 19. Como se apreciará por aquellos con experiencia en la técnica, un dispositivo móvil puede no desear recibir grandes cantidades de datos cuando las condiciones de red no son óptimas para la recepción de grandes cantidades de datos. Además, los operadores de red pueden desear evitar enviar grandes cantidades de datos durante periodos pico de uso de ancho de banda para poder propagar el tráfico de red más uniformemente con el tiempo. Esto puede lograrse utilizando el modelo de inserción/extracción como se ilustra en la Figura 19. Como se describe con referencia a la Figura 4 anterior, el contenido puede proporcionarse para que incluya más información que el usuario pueda necesitar actualmente. Por ejemplo, si el usuario solicita información de ubicación sobre restaurantes dentro de su área, un proveedor de servicio puede desear agregar publicidad tal como otros servicios disponibles en el área. Sin embargo, el proveedor de servicio puede no desear insertar este contenido adicional inmediatamente al usuario, sino de hecho proporcionar una guia tal como un encabezado o una tabla de contenido que muestre el contenido adicional. En otras situaciones, el contenido puede ser demasiado grande para enviar al usuario, y el usuario puede recibir sólo la primera parte del contenido y el resto del contenido se almacena en un almacén 452 de mensajes de recuperación diferida. Después de esto, el contenido almacenado puede pasarse al cliente 510 de inserción ya sea mediante el servidor alterno 410 de inserción o cuando fuese pedido por el cliente 510 de inserción. El cliente 510 de inserción incluye un monitor 1910 de estado de red que puede monitorear el estado de la red. El cliente 510 de inserción puede desear recibir solamente datos extras en ciertas condiciones. Por ejemplo, en un dispositivo móvil híbrido que tiene una opción de WiFi y celular, es más barato proporcionar datos en la conexión de WiFi, y de este modo el monitor 1910 de estado de red puede esperar hasta que el cliente 510 de inserción se conecte a una red de WiFi antes de obtener el contenido diferido. Alternativamente, el monitor de estado de red puede comprobar si el cliente está realizando itinerancia en una red foránea o conectada a la red local para poder minimizar los cargos por itinerancia. El monitor de estado de red también puede comprobar para ver si un canal de datos dedicado se establece para el dispositivo. Alguien con experiencia en la técnica se dará cuenta que el monitor 1910 de estado de red también puede comprobar otras diversas condiciones en la red antes de solicitar que los datos diferidos sean pasados al cliente 510 de inserción. Una red 130 inalámbrica también puede proporcionar información a cualquiera o ambos del cliente 510 de inserción y el servidor alterno 410 de inserción con respecto a los costos de la distribución de los datos. Como se apreciará por aquellos con experiencia en la técnica, varios periodos pico se presentan para la distribución de contenido. En el caso de información de tráfico, los periodos pico pueden estar al comienzo y final del día de trabajo cuando las personas vienen y van del trabajo. Para cotizaciones de bolsa de valores, el periodo pico puede ser durante el momento en que se abre el mercado. Otros periodos pico existirán. Para poder promediar el tráfico de datos, puede ser deseable que la red cargue diferentes tarifas basándose en el uso de datos actuales en la red. De este modo, durante periodos pico una mayor tarifa puede cargarse que en un periodo no pico tal como a la mitad de la noche. La red 130 inalámbrica por lo tanto proporciona notificaciones de costo de distribución a un gestor 552 de recuperación diferida en un cliente 510 de inserción y al programador 454 de inserción en el servidor alterno 410 de inserción. En una modalidad, los datos del proveedor 110 de contenido y el paso al servidor alterno 410 de inserción pueden clasificarse basándose en su importancia para el cliente. Cierta información puede designarse a través de metadatos que se distribuyen inmediatamente. Otra información puede designarse para distribuirse cuando el costo de la red sea menor que un primer valor (por ejemplo 1 Oí por megabyte) y otros datos pueden designarse para distribuirse cuando los costos de la red caigan por debajo de un segundo valor (por ejemplo, 5c por megabyte) . De este modo, el programador 454 de inserción considera los datos que se almacenan en el almacén 452 de mensajes de recuperación diferida e instruye al agente 444 de inserción que pase los datos diferidos al agente 544 de inserción en el cliente 510 de inserción. Alternativamente, el gestor 552 de recuperación diferida también puede monitorear las condiciones de red como enviadas desde la red 130 inalámbrica y si la proporción de datos es baja, pedir que el intermediario 554 de extracción de contenido traiga el contenido del almacén 452 de mensajes de recuperación diferida. Alternativamente, el gestor 552 de recuperación diferida puede ver que el estado de la red es favorable para extraer grandes cantidades de datos, tal como si el dispositivo móvil se hubiera conectado con una red de WiFi, y pide al intermediario 554 de extracción de contenido extraer los datos del almacén 452 de mensajes de recuperación diferida . Como se apreciará adicionalmente, un usuario siempre puede solicitar que se le extraiga el contenido. De este modo, la solicitud 1940 de usuario también podría utilizarse para activar el intermediario 554 de extracción de contenido para extraer los datos del almacén 452 de mensajes de recuperación diferida. Las reglas almacenadas en el programador 454 de inserción y el gestor 552 de recuperación diferida pueden ser metadatos estáticos basados en una clasificación de contenido. Las reglas también pueden basarse en los metadatos dinámicos para los datos particulares que se han pasado. En este caso, el proveedor 110 de contenido ha clasificado los datos . Ahora se hace referencia a la Figura 20. Como se apreciará por aquellos con experiencia en la técnica, los datos pueden ser una de dos formas, lineal o no lineal. Los datos lineales por ejemplo, pueden ser series o cadenas o contenido que fluyen en una forma lineal. Los datos no lineales, inversamente, son datos que no se refieren linealmente entre si y pueden incluir dependencias complejas, pares de contenido o enlaces. Para el contenido lineal, la fragmentación simplemente involucra la descomposición de los datos en varios componentes basados en el avance lineal. Los datos se dividen en segmentos, y los segmentos se distribuyen al cliente 410 de inserción. 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 analizarse con avance lineal. El procesador 2010 de fragmentación después divide los datos en segmentos 2014, 2016 y 2018 en el ejemplo de la Figura 20, y como se ilustra en la Figura 20, pasa el primer segmento 2014 mientras difiere el paso del segundo y tercer segmentos 2016 y 2018 respectivamente. El módulo 2030 de manejo de cursor está al tanto de qué segmento se ha distribuido y distribuye el siguiente segmento en orden. Con referencia a la Figura 21, el contenido no lineal necesita dividirse en una forma más inteligente. Además, en el otro extremo, para poder reconstituir los segmentos se requieren dos metadatos. Un procesador 2110 de fragmentación analiza el contenido basándose en un análisis basado en metadatos. Éstos podrían incluir mantener ciertos segmentos o elementos de datos juntos si se requiere lógicamente. El procesador 2110 de f agmentación analiza el contenido 2112 y divide el contenido en segmentos basándose en reglas lógicas. Cada segmento incluye el contenido más los metadatos que incluyen por ejemplo, dependencias, mapas y reglas de navegación para cada segmento. Una vez dividido, un primer segmento 2114 se envía al cliente 510 de inserción y el paso del resto de los segmentos 2116 y 2118 se difiere como se ilustra en la Figura 21. El bloque 2130 de navegación de segmento se encarga de qué segmento enviará después. Como se apreciará por aquellos con experiencia en la técnica, el primer segmento 2114 incluye una porción de datos y una porción de metadatos. La porción de metadatos del segmento 2114 es una capa de metadatos que se agrega por el procesador 2110 de fragmentación para indicar al módulo 546 de dependencia de contenido cómo reconstituir el contenido. La porción de datos del primer segmento 2114 puede incluir contenido y metadatos asociados con el canal o con el contenido. El bloque 2130 de navegación de segmento se adapta para procesar cómo un usuario viaja a través de los datos. Por ejemplo, si los datos están en un formato de árbol y el usuario baja una primera rama del árbol, el bloque 2130 de navegación de segmento puede pasar al cliente 410 de inserción otras ramas en el árbol que puedan alcanzarse desde el elemento que el usuario ha navegado. Por ejemplo, un árbol que incluye una base de datos de empleados 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 especifico de la organización, el bloque 2130 de navegación de segmentación debe enviar los fragmentos de grupo para grupos con ese departamento. Si el usuario entonces navega en un grupo especifico dentro del departamento, el bloque 2130 de navegación de segmentación entonces puede pasar los fragmentos de información sobre los empleados dentro de ese grupo . Lo anterior por lo tanto requiere que los datos sean divididos en componentes lógicos. Identif icadcres se asignan a todos los tipos y contenido, e información estructural se crea pasando la información con la guia. Lo anterior por lo tanto proporciona una arquitectura para la distribución de contenido dinámico que puede utilizarse con sistemas genéricos donde aplicaciones y contenido pueden agregarse sin cambiar la estructura del sistema. El contenido puede diseñarse para ajusfar la aplicación que recibe, y puede fragmentarse de acuerde con lo anterior . Mientras lo anterior proporciona sistemas genéricos en los cuales los proveedores de contenido y las aplicaciones están al tanto del ambiente de distribución de contenido, en una modalidad del método y sistema de la presente descripción ya sea un proveedor de contenido, aplicación, o ambos, no están al tanto del ambiente de distribución de contenido. Se hace referencia ahora a la Figura 22. En la Figura 22, un habilitador 2210 de distribución de contenido (CDE) se adapta para facilitar la distribución de contenido dinámico entre un proveedor 2230 de contenido y una aplicación de cliente y la capacidad de enlazar el proveedor de 2230 de contenido con una aplicación. El habilitador 2210 de distribución de contenido es equivalente a la estructura 100 de inserción de la Figura 1. El habilitador 2210 de distribución de contenido incluye un cliente 2212 de inserción, una red 2214 inalámbrica y un servidor 2216 de inserción. Éstas pueden igualarse con el cliente 140 de inserción, la red 130 inalámbrica y el proveedor 120 de servicio de la Figura 1 respectivamente, y las descripciones de los componentes con relación a la Figura 1 se pueden aplicar a la modalidad de la Figura 22. El proveedor 2230 de contenido, para la modalidad de la Figura 22, es un proveedor de contenido genérico. En otras palabras, el proveedor 2230 de contenido es utilizado por diferentes terminales que utilizan diferentes medios de distribución y por lo tanto es agnóstico a cualquier arquitectura de distribución de contendido particular. Tales proveedores 2230 de contenido de propósito genérico pueden ser conocidos por aquellos con experiencia en la técnica y sirven para una amplia variedad de clientes. Un usuario de dispositivo móvil, en algunas circunstancias, podría acceder al proveedor 2230 de contenido a través de navegación regular. Sin embargo, si se requieren servicios más sofisticados tales como distribución de contenido dinámico de un proveedor 2230 de contenido de propósito general, se requieren medios para poner al proveedor 2230 de contenido genérico en la arquitectura de distribución de contenido como se describe en lo anterior. El proveedor 2230 de contenido debe registrarse con el habilitador 2210 de distribución de contenido para poder asegurar que cualquier aplicación que quiera recibir el contenido del proveedor 2230 de contenido se le otorgará una opción de registrarse con el proveedor 2230 de contenido. Además, el habilitador 2210 de distribución de contenido necesitará hacer que la información de metadatos sobre el contenido se proporcione desde el proveedor 2230 de contenido genérico, para establecer el esquema y programa de distribución, identificar aplicaciones o tipos de aplicación capaces de procesar el contenido, o cualquier otra información necesaria de un habilitador 2210 de distribución de contenido y una perspectiva de aplicación. Similarmente, una aplicación de cliente tal como una aplicación 2240, 2245, 2250 de cliente como se ilustra en la Figura 22, puede ser una aplicación de cliente genérica, referida en la presente como aplicación 2255 genérica. En otras palabras, la aplicación 2255 de cliente podría ser agnóstica a la arquitectura de distribución de contenido. Cuando una aplicación 2255 genérica no está al tanto del modelo de distribución de contenido y no se designa específicamente para interactuar para recibir contenido dinámico a través de un modelo de distribución de contenido, tales aplicaciones 2255 serán incapaces por si mismas de registrarse con un habilitador 2210 de distribución de contenido. Estas aplicaciones 2255 típicamente no tendrán conocimiento del habilitador 2210 de distribución de contenido y de las interfases de registro y de este modo no se ajustan al modelo anterior como se describe con referencia a las Figuras 1 a 21. Como con un proveedor 2230 de contenido genérico, es deseable acoplar aplicaciones 2255 genéricas. Tales aplicaciones proporcionan a un usuario de un dispositivo móvil con más opción con respecto a las aplicaciones cargadas en el dispositivo móvil y la funcionalidad de la aplicación una vez cargada. Para poder acoplar una aplicación tal como una aplicación 2255 genérica, la presente descripción proporciona un mediador 2260. El papel del mediador 2260 es tener conocimiento sobre los metadatos de las aplicaciones que registra y sobre la interfaz de registro que incluye el esquema de metadatos para registrar la aplicación. El mediador 2260 puede ser genérico o de aplicación específica. Por ejemplo, el mediador 2260 puede proporcionarse por un desarrollador de aplicaciones junto con la aplicación. El mediador 2260 entonces se ejecuta, por ejemplo, cuando la aplicación se carga en un dispositivo móvil para registrar la aplicación particular con el habilitador de distribución de contenido particular. En este caso, el mediador 2260 incluye información de metadatos para la aplicación. Alternativamente, un mediador 2260 genérico podría existir en el dispositivo móvil. En ese caso, una vez que se requiere la aplicación, por ejemplo, al tener una aplicación cargada en el dispositivo móvil, tener un registro de solicitud de usuario de la aplicación con un habilitador 2210 de distribución de contenido, recibir datos de inserción destinados para una aplicación, entre otros activadores, el mediador 2260 genérico podría ir a un depósito 2280 y obtener metadatos para la aplicación. Como se apreciará una vez que se reciben los metadatos por un mediador 2260 para una aplicación 2255, entonces se requerirá que el mediador una la aplicación con el habilitador 2210 de distribución de contenido. Ahora se hace referencia a la Figura 23. Un mediador 2370 intenta resolver los metadatos 2320 que se asocian con una aplicación 2310 para el esquema 2340 de metadatos requerido por el habilitador 2345 de distribución de contenido. Específicamente, una aplicación 2310 incluye metadatos asociados con la misma, llamados aquí como metadatos 2320 de aplicación. Los metadatos 2320 de aplicación, incluyen varios parámetros que están esperando la aplicación 2310. Ejemplos incluyen parámetros de almacenamiento, que incluyen donde se almacena el contenido que está llegando, limitaciones de fragmentación o tamaño de los datos que la aplicación está dispuesta a aceptar, entre otros. Otros parámetros incluyen, por ejemplo, parámetros de notificación que incluyen si la aplicación debe notificarse de la llegada del contenido o si el contenido debe proporcionarse directamente a la aplicación tal como al utilizar memoria caché, o si el contenido debe almacenarse en una ubicación predefinida. También se contempla que otros metadatos específicos para una aplicación estén dentro del alcance de la presente descripción. Como además se ve en la Figura 23, el habilitador de distribución de contenido incluye el esquema de metadatos asociado con el mismo, referido en la presente como esquema 2340 de metadatos de habilitador de distribución de contenido. Como se apreciará, el esquema 2340 de metadatos de habilitador de distribución de contenido se encarga de los parámetros relacionados con la aplicación que se necesitan por el habilitador 2345 de distribución de contenido para ser capaces de manejar y distribuir el contenido para la aplicación. Los metadatos 2370 resuelven los metadatos 2320 de aplicación con el esquema 2340 de metadatos de habilitador de distribución de contenido. Tal resolución incluye las etapas de leer los metadatos 2320 de aplicación, extraer los parámetros necesarios y la información, agregar la información relacionada con el manejo de distribución a los metadatos 2320 de aplicación, convertir los datos en un formato aceptable para la aplicación 2310, y proceder a registrar la aplicación 2310 con el habilitador 2345 de distribución de contenido. La adición de información relacionada con el manejo de distribución podría basarse en parámetros preespecificados del dispositivo o podrían incluir entrada de usuario, tal como si se incitara al usuario a especificar información sobre datos que desea recibir o el manejo de esa información. Similarmente, un mediador 2270 de la Figura 22 realiza funciones similares entre los metadatos para un proveedor 2230 de contenido y el servidor 2216 de inserción. El mediador 2270 conecta los parámetros entre los metadatos del proveedor de contenido y los metadatos del habilitador de distribución de contenido. Los mediadores 2260 y 2270 por consiguiente permiten aplicaciones genéricas y proveedores de contenido genérico, respectivamente. Para hacer que el mediador 2260 disponible realice la funcionalidad anterior, están disponibles varias opciones. El ambiente de tiempo de ejecución en un dispositivo móvil será cualquiera de conocimiento de distribución de contenido o de no conocimiento de distribución de contenido. Si el ambiente de tiempo de ejecución es conocimiento de distribución de contenido, entonces el ambiente de tiempo de ejecución podría actuar en una de dos formas. En la primera forma, el ambiente de tiempo de ejecución podría observar que se instala una nueva aplicación, el usuario desea conectar una aplicación a un sistema de distribución de contenido, u otro activador que indica que va a conectarse una aplicación 2255 genérica a un habilitador 2210 de distribución de contenido. En una modalidad, el ambiente de tiempo de ejecución podría entonces iniciar un mediador 2260 específico de aplicación que se descarga de un depósito central. El mediador 2260 puede aprovisionarse sobre el aire en varios momentos, que incluyen cuando primero se carga una aplicación en un dispositivo móvil, cuando el usuario solicita distribución de contenido dinámico de la aplicación, cuando el contenido que llega podría ser servido por el dispositivo móvil, entre otros. Un mediador 2260 específico de aplicación podría proporcionarse desde un depósito manejado por proveedor de servicio de mediadores de aplicación o podría proporcionarse por desarrollador de aplicaciones o minorista en un depósito para aplicaciones proporcionadas por el desarrollador de aplicaciones o el minorista. Una vez que se descarga un mediador 2260 específico de aplicación, el ambiente de tiempo de ejecución puede ejecutar el mediador 2260 descargado, enlazando por consiguiente la aplicación al habilitador de distribución de contenido . Alternativamente, el ambiente de tiempo de ejecución por si mismo podría actuar como aplicación de mediador. En este caso, el ambiente sabe cómo ejecutar el proceso de registro y podría descargar los metadatos para una aplicación desde un depósito central. En este punto, el ambiente de tiempo de ejecución podría utilizar los metadatos para registrar la aplicación con el habilitador 2210 de distribución de contenido. En una modalidad adicional, si el ambiente de tiempo de ejecución no está al tanto de la distribución de contenido, un usuario necesitará iniciar la carga de una aplicación especial para el registro de aplicación genérica. La aplicación especial hace que el dispositivo esté al tanto de la distribución de contenido y entonces podría descargarse una aplicación especial, si ocurre una activación de registro de aplicación genérica, procede para encontrar los metadatos para la aplicación genérica, y registra la aplicación utilizando los metadatos encontrados. Lo anterior por lo tanto describe que la carga, la ejecución y el enlace de una aplicación y los metadatos asociados con la misma podría ser automática o impulsada por el usuario. En otras palabras, el usuario podría iniciar él proceso o el proceso podría ser automático si se descarga una aplicación en el dispositi o. Tres modelos se describen, la carga de un mediador especifico de aplicación desde un depósito por un ambiente de tiempo de ejecución al tanto de la distribución de contenido; la carga de los metadatos de aplicación desde un depósito por un ambiente de tiempo de ejecución al tanto de la distribución de contenido que actúa como un mediador genérico; o la carga de una aplicación especial sobre el dispositivo móvil para hacer que un ambiente de tiempo de ejecución no al tanto de la distribución de contenido esté al tanto de la arquitectura de distribución de contenido, en donde en donde la arquitectura ahora al tanto de la distribución de contenido podría descargar metadatos y actuar como un mediador genérico. Una opción adicional disponible es la inserción metadatos de registro o mediador al dispositivo móvil que ha instalado una aplicación particular. La inserción podría ocurrir desde el proveedor de servicio o desde una entidad de terceros tal como un depósito de aplicación, por ejemplo, con la descarga de la aplicación desde el depósito. Además, cuando un usuario instala un cliente 2212 de inserción en el dispositivo móvil, enlazando por consiguiente la estructura de distribución de contenido, el proveedor de servicio podría en ese momento insertar los metadatos de registro para aplicaciones ya instaladas en el dispositivo móvil. La lista de aplicaciones podría proporcionarse por el dispositivo en este caso. Otras opciones serán aparentes para aquellos con experiencia en la técnica que tienen consideraciones para la presente descripción. Como se indica en lo anterior, una alternativa para un depósito central para conseguir metadatos o la aplicación de mediador misma es proporcionar un depósito con una aplicación. En otras palabras, varios depósitos pueden existir para cada desarrollador de aplicaciones. Cada desarrollador de aplicaciones entonces puede ser capaz de proporcionar un mediador o metadatos que sean específicos para la aplicación. En una modalidad preferida, los metadatos o el mediador también podrían ser específicos para la arquitectura de distribución de contenido que se está utilizando. De esta forma, el mediador 2260 de la Figura 22 ó 2370 de la Figura 23 puede que necesite realizar una correlación de parámetros puesto que los parámetros entre los metadatos 2340 del habilitador de distribución de contenido y los metadatos 2320 de aplicación pueden correlacionarse. Para proveedores 2230 de contenido, la mediación se realiza en el servidor 2216 de inserción y es análoga a la anterior. En otras palabras, el servidor 2216 de inserción puede obtener un mediador para un proveedor de contenido específico o incluir un mediador genérico que pueda obtener metadatos para un proveedor de contenido. La mediación ocurre entre los metadatos 2340 del habilitador de distribución de contenido y los metadatos del proveedor de contenido (no mostrados ) . Lo anterior además puede expandirse al considerar el enlace implícito y explícito. Como se apreciará por aquellos con experiencia en la técnica que tienen consideración para la descripción anterior, una aplicación se enlaza a un proveedor de contenido. En otras palabras, un proveedor de contenido puede indicar la aplicación o tipo de aplicación que espera manejará los datos proporcionados desde el proveedor de contenido. En un ejemplo, un proveedor de contenido puede especificar que sólo una aplicación específica para manejar el contenido a partir de la misma. El habilitador 2210 de distribución de contenido entonces sólo notificará a un dispositivo móvil que tiene la aplicación específica instalada que está disponible el proveedor de contenido. Los metadatos y parámetros para la aplicación se conocen a partir del proveedor de contenido, y el enlace de la aplicación al proveedor de contenido por lo tanto es explícito. El proveedor de contenido anterior y la aplicación podrían ser genéricos. En otras palabras, el proveedor de contenido y la aplicación podrían ser agnósticos a la arquitectura de distribución de contenido. Por lo tanto, lo anterior podría requerir un mediador entre el proveedor de contenido y el habilitador 2210 de distribución de contenido, y entre el habilitador 2210 de distribución de contenido y la aplicación 2255. La aplicación 2255 también puede configurarse para proporcionar enlace explícito. Por ejemplo, la aplicación puede especificar que contenido se requiere de una URI específica para el proveedor 2230 de contenido. Si la aplicación 2255 entonces se registra antes del proveedor 2230 de contenido, al dispositivo móvil se le notificará tan pronto como se registre el proveedor 2230 de contenido solicitado por la aplicación 2255. Las relaciones en el enlace explícito se manejan en el lado del servidor. El habilitador 2210 de distribución de contenido tiene información sobre los dispositivos y aplicaciones 2255 que se conectan al habilitador 2210 de distribución de contenido y sólo enviarán notificaciones a aquellos dispositivos que tienen presente la aplicación 2255. Alternativamente, el enlace implícito puede ocurrir. Por ejemplo, un proveedor 2230 de contenido puede especificar que está proporcionando un cierto tipo de contenido. Si una aplicación 2230 especifica que puede procesar todo o un subconjunto de ese tipo de contenido, puede considerarse que es aceptable para el proveedor 2230 de contenido . En una situación de enlace implícito, el proveedor 2230 de contenido y la aplicación 2255 deben proporcionar una ficha de tipo contenido al habilitador 2210 de distribución de contenido. El habilitador 2210 de distribución de contenido entonces debe correlacionar si el esquema para la ficha de un proveedor de contenido se enlaza con la ficha para la aplicación. En un ejemplo, un proveedor 2230 de contenido indica que proporciona una alimentación de RSS. Si una aplicación indica que puede procesar alimentaciones de RSS, entonces existe una correlación y puede ocurrir el enlace implícito. Como se apreciará, los proveedores de contenido pueden proporcionar numerosos tipos de datos y una aplicación no puede ser capaz de procesar todos esos tipos de datos. Adicionalmente , el proveedor de contenido puede proporcionar información especializada o personalizada y la aplicación sólo puede ofrecer procesamiento genérico. Por ejemplo, si un proveedor de contenido de RSS de cotizaciones de bolsa de valores proporciona una alimentación de RSS especializada, para información de cotizaciones de bolsa de valores, una aplicación genérica de Visualizador de Alimentación de RSS puede no proporcionar la experiencia de usuario esperada. En una modalidad, una métrica de resistencia podría utilizarse para decidir si una aplicación debe atarse a un proveedor de contenido. De este modo, si una aplicación no incluye algún esquema proporcionado por un proveedor de contenido, una resistencia de cero podría registrarse y la aplicación puede no atarse al proveedor de contenido. La resistencia podría referirse al número de tipos de información proporcionado por el proveedor 2230 de contenido que puede interpretarse por la aplicación 2255. De este modo, un número entero de 0 a X, donde X pude ser cualquier número entero, podría ser la métrica de resistencia . La métrica de resistencia puede utilizarse para tomar la decisión sobre enlazar aplicaciones a proveedores de contenido. Por ejemplo, si una resistencia de uno existió, entonces el usuario puede desear enlazar la aplicación al proveedor de contenido y puede proporcionarse una indicación al usuario. Si existió una resistencia de dos, por ejemplo, entonces el enlace podría ocurrir automáticamente. Lo anterior sólo se da a entender como un ejemplo, y varios esquemas de enlace podrían implementarse . Con el ejemplo anterior, si el proveedor de contenido proporcionó por lo tanto una ficha de contenido que contiene segmentos de "RSS", "financieros", y de "cotizaciones de bolsa de valores", y la aplicación genérica de Visualizador de Alimentación de RSS proporcionó la ficha de contenido "RSS", la resistencia puede definirse como una. Si, por otro lado, la aplicación puede diseñarse como Visualizador de RSS personalizado para información financiera y proporcionó la ficha de contenido con los segmentos de "RSS" y "financieros", la resistencia podría ser dos. Se apreciará por aquellos con experiencia en la técnica con referencia a la descripción anterior, el enlace de una aplicación a un proveedor de contenido es importante para la arquitectura del habilitador 2210 de distribución de contenido. Al dispositivo móvil se le notifica cuando se agregan nuevos proveedores de contenido para cuyas aplicaciones pueden procesar su información. Además, cuando una aplicación se está registrando con el habilitador 2210 de distribución de contenido, la aplicación 2255 podría proporcionarse con una lista de proveedores 2230 de contenido que podría utilizar la aplicación. Puesto que no todas las aplicaciones 2255 o los proveedores 2230 de contenido estipularán explícitamente con qué proveedores 2230 o aplicaciones 2255 se pretenden utilizar respectivamente, el atado implícito de una aplicación al proveedor de contenido necesita realizarse por el habilitador 2210 de distribución de contenido. La métrica de resistencia descrita en lo anterior sólo es un ejemplo de una métrica de resistencia que podría utilizarse. Además, el esquema para la ficha de tipo de contenido también es genérico, aunque como se apreciará necesita ser común para la aplicación y el proveedor de contenido. El habilitador 2210 de distribución de contenido debe aplicar algunas heurísticas para identificar candidatos para enlace implícito. Además, el contenido de la ficha puede ser opaco para el habilitador 2210 de distribución de contenido y en algunos casos el esquema de la ficha también podría ser opaco. Esto, por ejemplo, existe donde ocurre el enlace para una correlación exacta del tipo de contenido. Otro ejemplo de una métrica de resistencia es una relación, la cual podría utilizarse en lugar de un número entero absoluto. De este modo, si el proveedor 2230 de contenido proporciona tres segmentos en una ficha de contenido (por ejemplo, "RSS", "financieros" "cotizaciones de bolsa de valores"), entonces la relación de una aplicación genérica de Visualizador de RSS (por ejemplo, "RSS") es de 1/3 y de un Visualizador de RSS especializado para información financiera (por ejemplo, segmentos de "RSS" y "financieros") es de 2/3. Lo anterior por lo tanto proporciona el registro de aplicaciones genéricas y proveedores de contenido genérico con una arquitectura de habilitador de distribución de contenido, y además proporciona el enlace explícito o implícito de aplicaciones a proveedores de contenido dependiendo de la aplicación y el proveedor de contenido. Como se apreciará, el cliente de inserción y las aplicaciones de cliente pueden residir en cualquier dispositivo móvil. Un dispositivo móvil ejemplar se describe en lo siguiente con referencia a la Figura 24. Esto nc quiere decir que sea limitante, pero se proporciona para propósitos ilustrativos . La Figura 24 es un diagrama de bloque que ilustra una estación móvil apta para utilizarse con modalidades preferidas del aparato y método de la presente solicitud. La estación 2400 móvil de preferencia es un dispositivo de comunicación inalámbrica de dos vías que tiene por lo menos capacidades de comunicación de voz y de datos. La estación 2400 móvil de preferencia tiene la capacidad de comunicarse con otros sistemas de cómputo en la Internet. Dependiendo de la funcionalidad exacta proporcionada, el dispositivo inalámbrico puede ser referido como un dispositivo de mensajes de datos, un buscador de dos vías, un dispositivo de correo electrónico inalámbrico, un teléfono celular con capacidades de mensajería de datos, un aparato de Internet inalámbrica, o un dispositivo de comunicación de datos, como ej emplos . Donde la estación 2400 móvil es habilitada para comunicación de dos vías, incorporará un subsistema 2411 de comunicación, que incluye un receptor 2412 y un transmisor 2414, así como componentes asociados, tal como uno o más elementos 2416 y 2418 de antena integrados o internos de preferencia, osciladores 2413 locales (LO) , y un módulo de procesamiento tal como un procesador 2420 digital de señales (DSP). Como será aparente para aquellos con experiencia en el campo de las comunicaciones, el diseño particular del subsistema 2411 de comunicación será dependiente de la red de comunicación en la cual se pretende operar el dispositivo. Los requerimientos de acceso de red también pueden variar dependiendo del tipo de red 2419. En algunas redes de CDMA, el acceso de red se asocia con un suscriptor o usuario de la estación 2400 móvil. Una estación móvil de CDMA puede requerir una tarjeta de módulo de entidad de usuario removióle (RUIM) o módulo de identidad de suscriptor (SIM) para poder operar en una red de CDMA. La interfaz 2444 de SIM/RUIM normalmente es similar a una ranura para tarjeta en la cual una tarjeta de SIM/RUIM puede insertase y ejecutarse como un disco o tarjeta de PCMCIA. La tarjeta de SIM/RUIM puede tener aproximadamente 64K de memoria y contener muchas configuraciones 2451 de claves, y otra información 2453 tal como identificación, e información relacionada con el suscriptor . Cuando se han completado los procedimientos de registro o activación de red requeridos, la estación 2400 móvil puede enviar y recibir señales de comunicación sobre la red 2419. Como se ilustra en la Figura 24, la red 2419 puede consistir de múltiples estaciones base que se comunican con el dispositivo móvil. Por ejemplo, en un sistema de CDMA lx de EVDO híbrido, una estación base de CDMA y una estación base de EVDO se comunican con la estación móvil y la estación móvil se conecta a ambas simultáneamente. Las estaciones base de EVDO y CDMA lx utilizan diferentes intervalos de búsqueda para comunicarse con el dispositivo móvil. Las señales recibidas por la antena 2416 a través de la red 2419 de comunicación se ingresan en el receptor 2412, el cual puede realizar funciones comunes del receptor como amplificación de señal, conversión descendente de frecuencia, filtración, selección de canales similares, y en el sistema ejemplar mostrado en la Figura 24, conversión de análogo a digital (A/D) . La conversión de A/D de una señal recibida permite funciones de comunicación más complejas tal como desmodulación y descodificación que se realizan en el DSP 2420. En una forma similar, las señales que se transmiten se procesan, incluyendo modulación y codificación por ejemplo, por el DSP 2420 y se ingresan al transmisor 2414 para la conversión de digital a análogo, la conversión ascendente de frecuencia, filtración, amplificación y transmisión sobre la red 2419 de comunicación mediante la antena 2418. DSP 2420 no sólo procesa señales de comunicación, sino también proporciona el control del receptor y del transmisor. Por ejemplo, las ganancias aplicadas en las señales de comunicación en el receptor 2412 y el transmisor 2414 pueden controlarse en forma adaptable a través de los algoritmos de control de ganancia automáticos implementados en el DSP 2420. La estación 2400 móvil de preferencia incluye un microprocesador 2438 que controla la operación general del dispositivo. Las funciones de comunicación, que incluyen por lo menos comunicaciones de datos y de voz, se realizan a través del subsistema 2211 de comunicación. El microprocesador 2438 también interactúa con subsistemas adicionales de dispositivo tal como el visualizador 2422, memoria 2424 flash, memoria 2426 de acceso aleatorio (RAM) , subsistemas 2428 de entrada/salida auxiliares (E/S) , puerto 2430 en serie, dos o más teclados o tableros 2432, altavoz 2434, micrófono 2436, otro subsistema 2440 de comunicación tal como un subsistema de comunicación de corto alcance y cualquier otro subsistema de dispositivo generalmente designado como 2442. El puerto 2430 en serie puede incluir un puerto de USB u otro puerto conocido por aquellos con experiencia en la técnica. Algunos de los subsistemas mostrados en la Figura 24 realizan funciones relacionadas con la comunicación, mientras otros subsistemas pueden proporcionar funciones "residentes" o en el dispositivo. Notablemente, algunos subsistemas, tal como el teclado 2432 y el visualizador 2422, por ejemplo, pueden utilizarse para funciones relacionadas con la comunicación, tal como el ingreso de un mensaje de texto para la transmisión sobre una red de comunicación, y las funciones residentes en el dispositivo tales como una calculadora o lista de tareas. El software del sistema operativo utilizado por el microprocesador 2438 se almacena de preferencia en un almacén persistente tal como una memoria 2424 flash, la cual de hecho puede ser una memoria de sólo lectura (ROM) o elemento de almacenamiento similar (no mostrado) . Aquellos con experiencia en la técnica apreciarán que el sistema operativo, las aplicaciones especificas del dispositivo, o partes del mismo pueden cargarse temporalmente en una memoria volátil tal como RAM 2426. Las señales de comunicación recibidas también pueden almacenarse en la RAM 2426. Como se muestra, la memoria 2424 flash puede segregarse en diferentes áreas para los programas 2458 de cómputo y el almacén 2450, 2452, 2454 y 2456 de datos de programación. Estos diferentes tipos de almacenamiento indican que cada programa puede asignar una posición de la memoria 2424 flash para sus propios requerimientos de almacenamiento de datos. El microprocesador 2438, además de sus funciones del sistema operativo, de preferencia permite la ejecución de aplicaciones de software en la estación móvil. Un conjunto predeterminado de aplicaciones que controla las operaciones básicas, que incluyen por lo menos aplicaciones de comunicación de datos y voz por ejemplo, normalmente se instalarán en la estación 2400 móvil durante la fabricación. Otras aplicaciones pueden instalarse subsiguiente o dinámicamente. Una aplicación de software preferida puede ser una aplicación del administrador de información personal (PIM) que tiene la capacidad de organizar y manejar elementos de datos que se refieren al usuario de la estación móvil tal como, pero no limitados a correo electrónico, eventos de calendario, correos de voz, citas y elementos de tarea. Naturalmente, uno o más almacenes de memoria pueden estar disponibles en la estación móvil para facilitar el almacenamiento de los elementos de datos de PIM. Tal aplicación de PIM puede tener de preferencia la capacidad de enviar y recibir elementos de datos, mediante la red 2419 inalámbrica. En una modalidad preferida, los elementos de datos de PIM se integran continuamente, se sincronizan y actualizan mediante la red 2419 inalámbrica, con los elementos de datos correspondientes del usuario de la estación móvil almacenados o asociados con un sistema de cómputo central. Aplicaciones adicionales pueden cargarse también en la estación 2400 móvil a través de la red 2419, un subsistema 2428 de E/S auxiliar, el puerto 2430 en serie, el subsistema 2440 de comunicación de corto alcance, o cualquier otro subsistema 2442 adecuado e instalado por un usuario en la RAM 2426 o de preferencia en un almacén no volátil (no mostrado) para la ejecución por el microprocesador 2438. Tal flexibilidad en la instalación de aplicación incrementa la funcionalidad del dispositivo y puede proporcionar funciones mejoradas en el dispositivo, funciones relacionadas con la comunicación, o ambas. Por ejemplo, las aplicaciones de comunicación seguras pueden permitir que funciones de comercio electrónico y otras transacciones financieras se realicen utilizando la estación 2400 móvil. En un modo de comunicación de datos, una señal recibida tal como mensaje de texto o página Web descargada se procesará por el subsistema 2411 de comunicación y se ingresará al microprocesador 2438, que de preferencia procesa además la señal recibida para su salida en el visualizador 2422, o alternativamente un dispositivo 2228 de E/S auxiliar. Un cliente 2460 de inserción que puede ser equivalente a los clientes 140 y 510, ó 2212 de inserción, también puede procesar la entrada. Un usuario de la estación 2400 móvil también puede compensar elementos de datos tal como mensajes de correo electrónico por ejemplo, utilizando el teclado 2432, el cual de preferencia es un teclado alfanumérico completo o un teclado tipo teléfono, junto con el visualizador 2422 y posiblemente un dispositivo 2428 de E/S auxiliar. Tales elementos compuestos pueden entonces transmitirse sobre una red de comunicación a través de un subsistema 2411 de comunicación.

Para comunicaciones de voz, la operación general de la estación 2400 móvil es similar, excepto que las señales recibidas de preferencia pueden ser producidas en un altavoz 2434 y las señales para la transmisión pueden generarse por un micrófono 2436. Los subsistemas de E/S de voz o de audio alternativos, tal como un subsistema de grabación de mensajes de voz, también pueden implementarse en la estación 2400 móvil. Aunque la salida de señal de voz o de audio de preferencia se logra principalmente a través del altavoz 2434, el visualizador 2422 también puede utilizarse para proporcionar unificación de la entidad de una parte que llama, la duración de una llamada de voz, u otra información relacionada con la llamada de voz, por ejemplo. El puerto 2430 en serie de la Figura 24, normalmente puede implementarse en una estación móvil de tipo asistente digital personal (PDA) para cuya sincronización con una computadora de escritorio de usuario (no mostrada) puede ser deseable, pero es un componente opcional del dispositivo. Tal puerto 2430 puede ser incapaz de establecer las preferencias del usuario a través de un dispositivo externo o aplicación de software y puede extender las capacidades de la estación 2400 móvil al proporcionar información o descarga de software a la estación 2400 móvil diferente a través de una red de comunicación inalámbrica. La trayectoria de descarga alternativa por ejemplo puede utilizarse para cargar una clave de encriptación sobre el dispositivo a través de una conexión directa y de este modo fiable y confiable para permitir por consiguiente una comunicación segura del dispositivo. Como se apreciará por aquellos con experiencia en la técnica, el puerto 2430 en serie además puede utilizarse para conectar el dispositivo móvil a una computadora para actuar como un módem. Otros subsistemas 2440 de comunicación, tal como un subsistema de comunicación de corto alcance, es un componente opcional adicional que puede proporcionar comunicación entre la estación 2400 móvil y diferentes sistemas o dispositivos, que no necesariamente deben ser dispositivos similares. Por ejemplo, el subsistema 2440 puede incluir un dispositivo infrarrojo y circuitos asociados y componentes o un módulo de comunicación Bluetooth™ para proporcionar comunicación con sistemas y dispositivos habilitados similarmente . Las modalidades descritas en la presente son ejemplos de estructuras, sistemas o métodos que tienen elementos que corresponden con elementos de la técnica de esta solicitud. Esta descripción descrita puede permitir que aquellos con experiencia en la técnica hagan y utilicen las modalidades que tienen elementos alternativos que de igual forma corresponden con los elementos de las técnicas de esta solicitud. El alcance pretendido de las técnicas de esta solicitud de este modo incluye otras estructuras, sistemas o métodos que no difieren de las técnicas de esta solicitud como se describe en la presente, y que además incluyen otras estructuras, sistemas o métodos con diferencias insustanciales de las técnicas de esta solicitud como se describe en la presente.

Claims

REIVINDICACIONES 1. Un método para conectar un elemento genérico a una arquitectura de distribución de contenido en un sistema de distribución de contenido de inserción caracterizado porque comprende las etapas de: proporcionar un mediador entre el elemento genérico y la arquitectura de distribución de contenido; extraer en el mediador los metadatos para el elemento genérico; y registrar el elemento genérico con la arquitectura de distribución de contenido.
2. El método de conformidad con la reivindicación 1, caracterizado porque el elemento genérico es un proveedor de contenido genérico.
3. El método de conformidad con la reivindicación 1 ó reivindicación 2, caracterizado porque la etapa de provisión comprende aprovisionar un proveedor de servicio de un depósito externo.
4. El método de conformidad con la reivindicación 2, caracterizado porque la etapa de provisión comprende las etapas de: localizar un mediador genérico en un proveedor de servicio; y obtener, del mediador, metadatos para el proveedor de contenido genérico.
5. El método de conformidad con la reivindicación 4, caracterizado porque la etapa de obtención comprende obtener metadatos de un depósito central o un depósito especifico de proveedor de contenido.
6. El método de conformidad con la reivindicación 1, caracterizado porque el elemento genérico es una aplicación genérica.
7. El método de conformidad con la reivindicación 6, caracterizado porque la etapa de provisión comprende proporcionar un dispositivo móvil desde un depósito externo.
8. El método de conformidad con la reivindicación 3 o reivindicación 7, caracterizado porque el depósito externo es un depósito genérico o un depósito especifico de proveedor de contenido.
9. El método de conformidad con la reivindicación 7 o reivindicación 8, caracterizado porque el mediador especifico para la arquitectura de distribución de contenido.
10. El método de conformidad con la reivindicación 6, caracterizado porque la etapa de provisión comprende las etapas de: localizar un mediador genérico en un dispositivo móvil; y obtener, utilizando el mediador, metadatos para el proveedor de contenido genérico.
11. El método de conformidad con la reivindicación 6, caracterizado porque la etapa de obtención comprende obtener metadatos desde un depósito central o un depósito especifico de aplicación.
12. El método de conformidad con cualquiera de las reivindicaciones 1 a 11, caracterizado porque la etapa de registro utiliza metadatos.
13. El método de conformidad con cualquiera de las reivindicaciones 1 a 11, caracterizado porque la etapa de provisión es impulsada por el usuario.
14. El método de conformidad con cualquiera de las reivindicaciones 1 a 11, caracterizado porque la etapa de provisión es automática.
15. El método de conformidad con cualquiera de las reivindicaciones 1 a 14, caracterizado además porque comprende la etapa de, antes de la etapa de provisión, cargar una aplicación para proporcionar un ambiente al tanto de la distribución de contenido.
16. El método de conformidad con cualquiera de las reivindicaciones 1 a 15, caracterizado porque el elemento genérico es uno de un proveedor de contenido y una aplicación .
17. El método de conformidad con la reivindicación 15, caracterizado porque la etapa de registro enlaza explícitamente el proveedor de contenido a la aplicación.
18. El método de conformidad con la reivindicación 17, caracterizado porque la etapa de registro enlaza implícitamente el proveedor de contenido a la aplicación.
19. El método de conformidad con la reivindicación 18, caracterizado porque el enlace implícito compara una ficha de tipo de contenido proporcionada por la aplicación con una ficha de tipo de contenido proporcionada por el proveedor de contenido.
20. El método de conformidad con la reivindicación 19, caracterizado porque la etapa de comparación cuenta un número de segmentos de solape entre la ficha de tipo de contenido proporcionada por la aplicación y la ficha de tipo de contenido proporcionada por el proveedor de contenido.
21. El método de conformidad con la reivindicación 20, caracterizado porque la etapa de registro utiliza el conteo de la etapa de comparación para determinar si se enlaza una aplicación con un proveedor de contenido.
22. El método de conformidad con cualquiera de las reivindicaciones 1 a 21, caracterizado porque el método además comprende, antes de la etapa de registro: agregar la información de manejo de distribución para el elemento genérico; y convertir la información en un formato predeterminado.
23. Un mediador que conecta un elemento genérico a una arquitectura de distribución de contenido en un sistema de distribución de contenido de inserción, el mediador caracterizado porque comprende: medios de extracción para extraer metadatos; y medios de registro para proporcionar información de registro para el elemento genérico a la arquitectura de distribución de contenido.
24. El mediador de conformidad con la reivindicación 23, caracterizado porque el elemento genérico es un proveedor de contenido genérico.
25. El mediador de conformidad con la reivindicación 23 o reivindicación 24, caracterizado porque el mediador se proporciona sobre un proveedor de servicio desde un depósito externo.
26. El mediador de conformidad con la reivindicación 23, caracterizado porque el elemento genérico es una aplicación genérica.
27. El mediador de conformidad con la reivindicación 26, caracterizado porque el mediador se proporciona sobre un dispositivo móvil desde un depósito externo.
28. El mediador de conformidad con la reivindicación 24 o reivindicación 27, caracterizado además porque comprende: medios de comunicación adaptados para obtener metadatos para el proveedor de contenido genérico.
29. El mediador de conformidad con cualquiera de las reivindicaciones 23 a 28, caracterizado porque el medio de registro se adapta para utilizar metadatos.
30. El mediador de conformidad con cualquiera de las reivindicaciones 23 a 29, caracterizado porque el elemento genérico es uno de un proveedor de contenido y una aplicación .
31. El mediador de conformidad con la reivindicación 30, caracterizado porque el medio de registro se adapta para enlazar explícitamente el proveedor de contenido a la aplicación.
32. El mediador de conformidad con la reivindicación 30, caracterizado porque el medio de registro se adapta para enlazar implícitamente el proveedor de contenido a la aplicación.
33. El mediador de conformidad con la reivindicación 32, caracterizado porque el medio de enlace implícito se adapta para comparar el esquema en una ficha de tipo de contenido proporcionada por la aplicación con el esquema en una ficha de tipo de contenido proporcionada por el proveedor de contenido.
34. El mediador de conformidad con la reivindicación 33, caracterizado porque el medio de enlace implícito se adapta para contar el número de esquemas de solape entre la ficha de tipo de contenido proporcionada por la aplicación y la ficha de tipo de contenido proporcionada por el proveedor de contenido.
35. El mediador de conformidad con la reivindicación 34, caracterizado porque el medio de registro se adapta para utilizar el conteo para determinar si se enlaza una aplicación con un proveedor de contenido.
36. El mediador de conformidad con cualquiera de las reivindicaciones 23 a 35, caracterizado además porque comprende : medios de procesamiento adaptados para agregar la información de manejo de distribución para el elemento genérico; y medios de conversión adaptados para convertir la información en un formato predeterminado.