ES2348052T3 - Metodo y sistema para la organizacion del tratamiento de contenidos en estructuras de envio moviles. - Google Patents

Metodo y sistema para la organizacion del tratamiento de contenidos en estructuras de envio moviles. Download PDF

Info

Publication number
ES2348052T3
ES2348052T3 ES07104833T ES07104833T ES2348052T3 ES 2348052 T3 ES2348052 T3 ES 2348052T3 ES 07104833 T ES07104833 T ES 07104833T ES 07104833 T ES07104833 T ES 07104833T ES 2348052 T3 ES2348052 T3 ES 2348052T3
Authority
ES
Spain
Prior art keywords
content
external
metadata
enabler
sending
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES07104833T
Other languages
English (en)
Inventor
Michael Shenfield
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
Research in Motion Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Research in Motion Ltd filed Critical Research in Motion Ltd
Application granted granted Critical
Publication of ES2348052T3 publication Critical patent/ES2348052T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/951Indexing; Web crawling techniques
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10Services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/2876Pairs of inter-processing entities at each side of the network, e.g. split proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/561Adding application-functional data or data for application control, e.g. adding metadata
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/564Enhancement of application control based on intercepted application data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/567Integrating service provisioning from a plurality of service providers

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Un método para coordinar el tratamiento o procesamiento de contenidos en una estructura de envío móvil que comprende los pasos de: integrar, dentro de una envuelta (420) de metadatos asociada con contenido (412), referencias externas a habilitadores y metadatos (440) externos para un habilitador de envío; y insertar, dentro de los metadatos (440) para un habilitador de envío, reglas de coordinación de tratamiento o procesamiento de contenidos con el fin de conectar con la funcionalidad de los habilitadores externos referenciados para procesar el contenido por el habilitador de envío.

Description

Método y sistema para la organización del tratamiento de contenidos en estructuras de envío móviles.
La presente explicación se refiere de forma general al envío de contenido móvil y en concreto a la utilización de habilitadores para facilitar el envío de contenido móvil.
Los usuarios de dispositivos móviles o de equipo móvil de usuario (UE) se están volviendo cada vez más sofisticados en cuanto a la funcionalidad que piden a sus dispositivos móviles y la forma en que acceden a datos desde los dispositivos móviles.
El envío de contenido dinámico permite a los usuarios disponer de información o datos suscritos enviados a ellos en lugar de tener que ir y buscar los datos. Ejemplos de datos podrían incluir cotizaciones de acciones, partes meteorológicos actualizados, actualizaciones sobre el tráfico, fondos de pantalla dinámicos, anuncios, aplicaciones u otros datos deseables para el usuario.
El envío de contenidos a menudo requiere diferentes habilitadores en el lado del servidor y en el lado del dispositivo. Estos habilitadores no forman parte de la funcionalidad central de un habilitador de envío y se necesita un sistema y un método para coordinar con otros habilitadores el tratamiento o procesamiento de contenidos.
El documento US2004/073613 A1 explica un método para el tratamiento o procesamiento automático de documentos digitales que comprende integrar un perfil de tratamiento o procesamiento con un documento digital, y procesar el documento digital en respuesta al perfil de tratamiento o procesamiento integrado.
El documento US2005/240530 A1 explica un sistema de distribución de contenidos, en el cual un proveedor de contenidos transmite un contenido de película y metadatos de reglas de uso a un aparato reproductor.
General
El presente invento define un método de acuerdo con la reivindicación 1, un sistema de acuerdo con la reivindicación 15, un paquete de contenidos de acuerdo con la reivindicación 16 y un medio que puede leer un ordenador que almacena código de programa de acuerdo con la reivindicación 28. En las reivindicaciones independientes 2-14 y 17-27 se exponen realizaciones específicas.
El presente sistema y método puede garantizar la integración de referencias externas y reglas de coordinación de tratamiento o procesamiento de contenidos dentro de metadatos de envío de contenido móvil. En concreto, se proporciona un método para expresar reglas de coordinación para metadatos de envío móvil como un diagrama de estados empaquetado XML.
Un proveedor de contenidos puede integrar metadatos para diferentes elementos de tratamiento o procesamiento dentro de la estructura de envío. Se encuentran incluidas en los metadatos instrucciones para el habilitador de envío de contenido. Además, se pueden proporcionar declaraciones de espacios de nombres externas para habilitadores externos. Se pueden incluir espacios de nombres que hagan referencia a los esquemas XML que representan enlace a habilitadores externos con el fin de coordinar el tratamiento o procesamiento de contenido móvil mientras se está enviando un paquete de contenido. Esto se consigue integrando elementos y atributos definidos en esquemas XML correspondientes dentro de un elemento XML para el estado de tratamiento o procesamiento.
Se pueden usar verbos de acción para mapear o correlacionar instrucciones de coordinación a funciones habilitadoras externas. Este nivel de acción indirecta permite un bajo acoplamiento entre servicios.
Por lo tanto, la presente explicación puede proporcionar un método para coordinar el tratamiento o procesamiento de contenidos en una estructura de envío móvil que comprende los pasos de: integrar, dentro de una envuelta de metadatos asociada con contenido, referencias externas a habilitadores externos y metadatos para un habilitador de envío; e insertar, dentro de los metadatos para un habilitador de envío, reglas de coordinación de tratamiento o procesamiento de contenidos.
La presente explicación puede además proporcionar un sistema para coordinación de tratamiento o procesamiento de contenidos que comprende: un proveedor de contenido, estando adaptado dicho proveedor de contenido para integrar referencias externas a habilitadores externos y metadatos para un habilitador de envío dentro de metadatos de envío de contenido móvil asociados con contenido suministrado por dicho proveedor de contenido, y estando adaptado dicho proveedor de contenido para insertar en los metadatos para un habilitador de contenido reglas de coordinación de tratamiento o procesamiento de contenidos para conectar con la funcionalidad de los habilitadores externos referenciados para el tratamiento o procesamiento del contenido por el habilitador de envío; un habilitador de envío de contenido que comprende: un servidor de envío, estando dicho servidor de envío adaptado para procesar metadatos dirigidos a dicho servidor de envío; y un cliente de envío, estando dicho cliente de envío adaptado para procesar metadatos dirigidos a dicho cliente de envío; habilitadores externos adaptados para procesar contenido basándose en las reglas de coordinación de tratamiento o procesamiento de contenidos mediante dicho habilitador de envío de contenido; y un cliente de contenido adaptado para consumir contenido procedente del proveedor de contenido.
La presente explicación puede además proporcionar un paquete de contenido que comprende: contenido; y una envuelta de metadatos, comprendiendo la envuelta de metadatos referencias externas a habilitadores externos y metadatos para un habilitador de envío, teniendo los metadatos para un habilitador de contenidos reglas de coordinación de tratamiento o procesamiento de contenidos integradas en su interior.
\vskip1.000000\baselineskip
Breve descripción de los dibujos
La presente explicación se entenderá mejor con referencia a los dibujos, en los cuales:
la figura 1 es un diagrama de bloques que muestra componentes lógicos dentro de una arquitectura de envío;
la figura 2 es un diagrama de bloques que ilustra el flujo de metadatos entre los componentes lógicos de la
figura 1.
la figura 3 es un diagrama de bloques que ilustra un modelo envuelto para tratamiento o procesamiento de metadatos entre los componentes lógicos de la figura 1.
la figura 4 es un diagrama de bloques que muestra un paquete de contenido de ejemplo que incluye contenido y una envuelta de metadatos;
la figura 5 es un diagrama de bloques que muestra un bloque de función;
la figura 6 es un diagrama de estado que muestra un ejemplo de coordinación de metadatos entre un habilitador de envío de contenido y habilitadores externos; y
la figura 7 es un diagrama de bloques que muestra un ejemplo de dispositivo móvil que se puede usar en asociación con el método y sistema de la presente explicación.
\vskip1.000000\baselineskip
Descripción de realizaciones preferentes
Se hace ahora referencia a la Figura 1. Se ilustra un sistema de empuje (push) para enviar contenido dinámico a una aplicación cliente. El sistema de la figura 1 es un sistema simplificado y muestra componentes lógicos que tienen que estar dentro de una arquitectura de envío de contenido dinámico. Sin embargo, como apreciarán aquellos con experiencia en la técnica, podrían existir otros componentes o se podrían agrupar entre sí diferentes componen-
tes.
La arquitectura 100 incluye un proveedor 110 de contenido. El proveedor 110 de contenido está diseñado para proporcionar contenido dinámico a usuarios. Esto puede incluir, por ejemplo, una página web de venta de libros. El proveedor 110 de contenido puede proporcionar de manera periódica una lista de libros puestos a la venta recientemente, la cual puede ser enviada a subscriptores que estén subscritos a la página web o a un servidor de envío que gestiona las subscripciones.
Un servidor 120 de envío se comunica por una red 130 inalámbrica con un cliente 140 de envío que, en una realización preferente, está situado en un dispositivo móvil. El cliente 140 de envío recibe el contenido que está siendo enviado desde el proveedor 110 de contenido y puede comunicar el citado contenido a un cliente 150 de contenido. Por último, el cliente 150 de contenido consume el contenido.
Como apreciarán aquellos con experiencia en la técnica, en la presente explicación un habilitador es equivalente a una estructura. De esta forma, el habilitador de contenido comprende un servidor 120 de envío y un cliente 140 de envío.
Como apreciarán aquellos con experiencia en la técnica, pueden ser necesarias diferentes funciones externas para el envío del contenido al cliente 150 de contenido. Estas funciones externas pueden existir en el lado 102 del servidor y en el lado 104 del dispositivo. En la Figura 1, las funciones externas se muestran como funciones 132, 134 y 136 externas en el lado 102 del servidor y funciones 144, 146 y 148 externas en el lado 104 del dispositivo. Ejemplos de funciones externas pueden incluir presencia, localización, filtrado de contenido y compresión, entre otros, pero no están limitadas a estos ejemplos.
Se hace ahora referencia a la Figura 2. Con el fin de añadir inteligencia a un sistema, se asocia el contenido a metadatos. En este caso, los metadatos se definen como datos que pueden ser usados por un elemento de tratamiento o procesamiento para manipular el contenido. Como se apreciará, un sistema de envío de contenido genérico necesita metadatos para permitir que existan dentro del sistema diferentes proveedores de contenido y diferentes clientes de contenido. Los metadatos pueden estar en diferentes formas, incluyendo parámetros o reglas de tratamiento o procesamiento, o un gestor, código o referencia de tratamiento o procesamiento proporcionado directamente o un enlace a un gestor, código o reglas de tratamiento o procesamiento en otra localización.
Como se puede ver en la Figura 2, el contenido pasa del proveedor 110 de contenido al cliente 150 de contenido, como ilustra la flecha 210. Los metadatos, los cuales proporcionan instrucciones a diferentes componentes dentro de la arquitectura 100, pueden también pasar entre componentes de la arquitectura 100, normalmente junto con el contenido. Por ejemplo, la flecha 220 ilustra metadatos para el cliente de contenido que se originan en el proveedor 110 de contenido y que son opacos para el sistema de envío hasta que llegan a un cliente 150 de contenido.
La flecha 230 muestra metadatos creados por un proveedor 110 de contenido que están destinados al cliente 140 de envío y de esta forma sólo fluyen hacia el cliente 140 de envío.
La flecha 240 ilustra metadatos generados por el servidor 120 de envío y que están destinados al cliente 140 de envío y de esta forma se asocian primero con el contenido en el servidor 120 de envío y se separan del contenido en el cliente 140 de envío. Ejemplos de casos en los que esto se podría producir incluyen acuerdos entre un usuario y un proveedor de servicios con respecto a un plan de facturación y al nivel de servicio a proporcionar, donde el proveedor de servicio puede usar los metadatos para limitar los servicios disponibles o para proporcionar servicios mejorados.
Se hace ahora referencia a la Figura 3. La Figura 3 ilustra un modelo de envuelta multicapas para metadatos de contenido.
Un servidor 120 de envío recibe una envuelta 310 de empuje (push) que incluye metadatos 312 de tratamiento o procesamiento de contenidos para el servidor 120 de envío y una envuelta 314 de cliente de envío. El servidor 120 de envío extrae los metadatos 312 de tratamiento o procesamiento de contenidos y utiliza estos metadatos para procesar la envuelta 314 de cliente de envío. Los metadatos 312 indican al servidor 120 de envío qué hacer con la envuelta 314 de cliente de envío.
La envuelta 314 de cliente de envío se hace pasar al cliente 140 de envío, donde se separa en una envuelta 320 de contenido y unos metadatos 322 de tratamiento o procesamiento de contenidos. Los metadatos 322 de tratamiento o procesamiento de contenidos son usados por el cliente 140 de envío para procesar la envuelta 320 de contenido. Por ejemplo, esto se puede usar para dar instrucciones al cliente 140 de envío para que realice una sustitución de la envuelta 320 de contenido enviada previamente por la última envuelta si el cliente 150 de contenido sólo está interesado en la última versión del contenido.
La envuelta 320 de contenido se hace pasar el cliente 150 de contenido. La envuelta 320 de contenido incluye metadatos 330 de tratamiento o procesamiento de contenidos para el cliente 150 de contenido y carga útil 332 de contenido a ser consumida por el cliente 150 de contenido.
Como apreciarán aquellos con experiencia en la técnica, el anidamiento de envueltas de acuerdo con la Figura 3 garantiza un entorno dinámico rico en el cual el tratamiento o procesamiento se puede realizar en cualquier elemento de tratamiento o procesamiento de la arquitectura y en el cual el proveedor 110 de contenido puede especificar cómo se tiene que tratar el contenido específico. En una realización, los metadatos son dirigidos hacia un elemento lógico concreto y son opacos para otros elementos de tratamiento o procesamiento.
Como se podrá apreciar además, los metadatos pueden ser incluidos sólo para diferentes etapas del envío de contenido. Por ejemplo, se pueden necesitar metadatos sólo entre el servidor 120 de envío y el cliente 140 de envío y de esta manera no se incluiría ningún metadato para el cliente 150 de contenido.
Para aquellos con experiencia en la técnica resultarían evidentes otras alternativas.
Aunque lo anterior describe metadatos para un habilitador de envío de contenido, en algunos casos un habilitador de envío de contenido móvil puede necesitar conectar con otras estructuras y habilitadores mientras envía el contenido al cliente 150 de contenido. Como se ha indicado anteriormente, ejemplos de funciones externas incluyen presencia, localización, filtrado de contenido, compresión, entre otros. Por ejemplo, un habilitador externo puede ser un habilitador de presencia. Un usuario puede haber especificado una regla por la que cierto contenido debería ser enviado sólo cuando el usuario está en una red doméstica con el fin de evitar costes de itinerancia de datos. Un habilitador de este tipo necesita usar la funcionalidad de otros habilitadores tales como un habilitador de localización para descubrir dónde está situado el dispositivo móvil.
Otros ejemplos de habilitadores incluyen filtrado de contenido que podría impedir que ciertos tipos de contenido sean enviados al dispositivo móvil.
En el lado del dispositivo, un ejemplo de un habilitador puede ser un habilitador de compresión que necesitaría descomprimir cierto contenido antes de que éste se haga pasar a un cliente 150 de contenido.
Típicamente, un habilitador de envío de contenido no tendría la funcionalidad de los habilitadores externos y de esta manera necesita acceder a habilitadores externos para garantizar una estructura rica de envío de contenido.
Como apreciarán aquellos con experiencia en la técnica, el contenido debería ser opaco para la estructura de envío. Por lo tanto, la única forma de indicar la necesidad de tratamiento o procesamiento de contenidos externo y de coordinar este tratamiento o procesamiento es mediante el uso de metadatos.
Se hace ahora referencia a la Figura 4. La Figura 4 ilustra un ejemplo de paquete 410 de contenido recibido de un proveedor de contenido tal como el proveedor 110 de contenido de la Figura 1.
El paquete 410 de contenido incluye contenido 412 y una envuelta 420 de metadatos. Como se ha indicado anteriormente, el contenido 412 debería ser opaco para la estructura de envío. Por lo tanto, la única forma de indicar la necesidad de tratamiento o procesamiento de contenido externo, y de coordinar este tratamiento o procesamiento, es mediante el uso de los metadatos de la envuelta 420 de metadatos.
La envuelta 420 de metadatos incluye una caja 430 de declaración de espacios de nombres, la cual permite declaraciones de espacios de nombres para servicios externos que se deben usar para procesar el contenido 412. Con el número de referencia 435 se muestran dos ejemplos de declaraciones de espacios de nombres.
Preferiblemente, la envuelta 420 de metadatos incluye además un bloque 440 de metadatos para su tratamiento o procesamiento por un servidor de envío tal como el servidor 120 de envío de la Figura 1.
El bloque 440 de metadatos incluye diferentes metadatos para su tratamiento o procesamiento por el servidor de envío. El bloque 440 de metadatos incluye además diferentes bloques de función para conectar con funciones externas. Estos son ilustrados por los bloques 442 y 444 de función de la Figura 4.
La envuelta 420 de metadatos también incluye un bloque 450 de metadatos para su tratamiento o procesamiento por un cliente de envío tal como el cliente 140 de envío de la Figura 1. El bloque 450 de metadatos incluye metadatos que deben ser procesados por el cliente de envío junto con bloques 452 y 454 de función.
Como apreciarán aquellos con experiencia en la técnica, el uso de dos bloques de función para conectar con funciones externas en el bloque 450 es sólo un ejemplo y la presente explicación no pretende estar limitada a un cierto número de funciones externas a las que se han conectado bloques de función externos. En otras palabras, el bloque 440 de metadatos o el bloque 450 de metadatos podrían no incluir ninguna instrucción o regla para conectar con funciones externas y de esta forma podrían no incluir ningún bloque de función, o podrían conectar con múltiples funciones externas mediante muchos bloques de función.
Un ejemplo de un bloque de función, tal como un bloque 442 de función, se ilustra mediante el número de referencia 460. El número de referencia 460 señala a una representación lógica de un bloque de función. En el ejemplo de la Figura 4, el bloque de función es un nodo de un árbol de estados.
Preferiblemente, el bloque de función incluye un identificador 462 de estado, el cual identifica el estado del bloque de función del árbol de estados.
El bloque de función puede además incluir una expresión y/o condición 464 de vigilancia, la cual incluye una expresión lógica que, si se cumple, provoca que se realice el tratamiento o procesamiento para el estado.
El bloque de función podría además incluir un servicio externo o identificador 466 de función para identificar el servicio o función externo que está siendo utilizado.
El bloque de función podría además incluir verbos 468 de acción que definen qué función de un servicio externo debería usar el habilitador de envío de contenido.
El bloque de función podría además incluir parámetros 470 que definen la lista de parámetros que es necesario hacer pasar al habilitador externo cuando se llama a la función definida en este bloque de función.
El bloque de función podría además incluir una transición 472 de estado basada en los resultados de los verbos de acción para indicar a qué estado pasar a continuación.
Se hace ahora referencia a la Figura 5. La Figura 5 ilustra una estructura en capas del bloque 510 de función, la cual es una representación de un estado de tratamiento o procesamiento. Como se describe más adelante, existen diferentes bloques integrados dentro del bloque 510 de función.
Un primer bloque 520 es un conjunto de elementos XML comunes que definen un diagrama de estados. Como apreciarán aquellos con experiencia en la técnica, el término "elemento" es un término amplio e incluye un subconjunto de un documento XML que comienza y termina con etiquetas XML correspondientes.
El bloque 520 incluye elementos que son referenciados por el espacio de nombres que define la sintaxis XML para un lenguaje de representación de diagrama de estados. Ejemplos incluyen lenguaje de marcado extensible de diagrama de estados (SCXML), lenguaje de ejecución de procesos de negocio (BPEL) y XProc, entre otros.
Un bloque 530 integrado adicional contiene metadatos definidos por el habilitador de envío, incluyendo enlaces a habilitadores externos. El bloque 530 incluye XML que es referenciado por el espacio de nombres para el habilitador de envío e incluye todos los enlaces XML a habilitadores externos e instrucciones de tratamiento o procesamiento internas, si existe alguna.
Un bloque 540 integrado adicional es metadatos definidos para su uso por habilitadores externos. Este bloque es referenciado por el espacio de nombres para el habilitador externo e incluye elementos definidos en el esquema del habilitador externo. Estos elementos son opacos para el habilitador de envío.
Como apreciarán aquellos con experiencia en la técnica, los elementos dentro del bloque 530 especifican un comportamiento predefinido del habilitador de envío que incluye el enlace de elementos a funciones/parámetros del habilitador externo. Estos elementos deberían ser comprendidos por la capa de interpretación de metadatos del habilitador de envío. En cambio, los elementos dentro del bloque 540 son opacos para el habilitador de envío y se hacen pasar al habilitador externo "tal cual". Estos elementos representan construcciones definidas por el esquema del habilitador externo y por lo tanto son comprendidos por el habilitador externo.
Por lo tanto, lo anterior proporciona un método para usar espacios de nombres y esquemas que representan enlaces a habilitadores externos con el fin de coordinar el tratamiento o procesamiento de contenido móvil mientras se está realizando el envío. Esto lo consiguen elementos de integración definidos en esquemas correspondientes dentro de un elemento XML para el estado de tratamiento o procesamiento.
Lo anterior se entenderá con mayor claridad haciendo referencia al siguiente ejemplo de segmento de código SCXML y haciendo referencia a la Figura 6.
\vskip1.000000\baselineskip
Lo siguiente ilustra un ejemplo de metadatos de coordinación expresados en SCXML:
\vskip1.000000\baselineskip
1
2
Las primeras cinco líneas del segmento de código anterior forman parte del bloque 430 de la Figura 4. En concreto, estas líneas son declaraciones de espacios de nombres para la versión XML, así como declaraciones de espacios de nombres para el envío de contenido dinámico, un habilitador de capacidades de dispositivo, un habilitador de localización de dispositivo y un habilitador de presencia de dispositivo. Como se apreciará, estos son sólo ejemplos de diferentes habilitadores que se podrían usar y declarar como parte de las declaraciones de espacios de nombres. Además, las declaraciones de espacios de nombres mostradas anteriormente se incluyen sólo como ejemplo y no representan URLs reales para habilitadores.
La siguiente línea del código indica 'initialstate = "content received"'. Esto muestra el estado inicial al que avanzar para el tratamiento o procesamiento del contenido.
La siguiente línea indica 'state id = "content received"'. Esto es parte del bloque 520 de la Figura 5 y define el estado del bloque de función.
Además, la línea 'invoke src = "checkMemory"' es parte del bloque 520 de la Figura 5 y está diciendo al SCXML que llame a una función externa.
La siguiente línea indica 'dcd:action function-id="DCAP:checkMemory"'. Esta acción define que se debería utilizar la función externa checkMemory en el habilitador de capacidades de envío.
La siguiente línea es <dcd:verb>validateMemorySize</dcd:verb>. Este es un verbo de acción que comprende el habilitador de envío de contenido dinámico.
Las dos líneas siguientes indican parámetros que usa la función externa checkMemory.
La siguiente línea es <dp:function>checkMemory</dp:function>. Esto mapea el verbo de acción dcd validateMemorySize a la función externa. En este caso, la función externa es checkMemory y es parte del habilitador de capacidad del dispositivo definido utilizando el nombre "dp" en la definición del espacio de nombres.
La siguiente línea define el tipo de resultados que se espera obtener de la función externa.
Del segmento de código anterior, los dcd:action, dcd:verb y dcd:parameters pertenecen al bloque 530 de la Figura 5. Estos son un comportamiento predefinido del habilitador de envío e incluyen enlace de estos elementos a funciones o parámetros del habilitador externo.
Las líneas dp:function y dp:result pertenecen al bloque 540 y son opacas para el habilitador dcd.
La línea: <transition event="success" cond="checkMemory.result" target="Check Roaming"/> es una comprobación para ver si se produjo o no un suceso específico y si se ha cumplido una condición. Si se ha producido el suceso y se ha cumplido la condición, entonces esta línea define el siguiente estado al que pasar. En este caso, el siguiente estado es "Check Roaming".
En la línea <transition event="failure" cond=!isRoaming.result'' target="Send Rejected"/> el suceso no se produce y la memoria de comprobación devuelve 'false', entonces el estado pasa a "Check Fragmentation".
Como apreciarán aquellos con experiencia en la técnica, los sucesos de transición definidos anteriormente pertenecen al bloque 520 de la Figura 5.
Haciendo referencia a la Figura 6, lo anterior se ilustra con referencia a los diagramas de estado. En concreto, el estado 610 inicial es el estado: "Content Received". Se usa un verbo de acción validateMemorySize dentro del habilitador 602 de envío de contenido y se interpreta en la capa 604 de interpretación de metadatos.
En la capa 604 de interpretación de metadatos, se llama a la función externa 620 checkMemory, pasando parámetros de dispositivo 'deviceID' y 'contentSize'. El habilitador 622 de capacidades de dispositivo devuelve entonces un resultado 624 a la capa 604 de interpretación de metadatos, la cual a continuación devuelve el parámetro a través del verbo 612 validateMemorySize, y el resultado 614 se devuelve al estado 610.
El resultado 614 se comprueba en el paso 630 y, si es verdadero, el estado cambia al estado 640 "Check Roaming" y, si es falso, el estado cambia a un estado "Check Fragmentation" (no mostrado).
Haciendo de nuevo referencia al segmento de código anterior, un bloque de función adicional es definido por 'state ID = "check roaming"'.
La acción para el envío de contenido dinámico se define utilizando el ID de función "LOC:isRoaming".
La expresión <dcd:verb>isHomeNetwork</dcd:verb> proporciona un verbo de acción. Los parámetros para el verbo de acción se definen en la línea siguiente como ContentHeader:deviceID.
El envío de contenido dinámico puede usar cualesquiera elementos arbitrarios definidos en su esquema tales como la expresión "someExoticElement".
Las dos líneas siguientes, a saber:
3
4
definen una función externa que es mapeada al verbo "isHomeNetwork". La función externa es la función "isRoaming" e incluye un parámetro de "ignoreNetworkAgreements". Como apreciarán aquellos con experiencia en la técnica, el habilitador de localización está adaptado para manejar esta función y la función es opaca para el habilitador de envío de contenido dinámico.
Las dos líneas siguientes definen las transiciones. Si la "isRoaming" devuelve un verdadero, entonces la transición de estado cambia a un estado "checkAvailability". Si el resultado de "isRoaming" es falso, entonces el estado cambia a un estado "Send Rejected".
Esto se ilustra en la Figura 6. En dicha Figura 6, el estado 640 es el estado "Check Roaming" y se puede usar el verbo de acción 642 "isHomeNetwork" desde el estado 640. La capa 604 de interpretación de metadatos interpreta el "isHomeNetwork" y utiliza el verbo de acción para llamar a una función 650 "isRoaming" en un habilitador 652 de localización.
El habilitador 652 de localización devuelve un resultado 654, el cual se propaga a través de la capa 604 de interpretación de metadatos hasta el verbo 642 "isHomeNetwork", el cual devuelve un resultado 644 al estado 640 "Check Roaming".
A continuación se comprueba el resultado en 660, lo cual corresponde a los comandos "transition" en el código anterior. Si el resultado en 660 es verdadero, el estado cambia a un estado 670 "Check Availability". En el caso contrario, el estado pasa a un estado "Send Rejected" (no mostrado).
Una funcionalidad similar aplica para el estado 670. El verbo de acción en este caso es "isUserAvailable". La capa 604 de interpretación de metadatos utiliza el verbo 672 "isUserAvailable" y llama a la función 680 "isAvailable" del habilitador 682 de presencia. Se devuelve un resultado 684 y es a continuación devuelto al estado 670 como un resultado 674. Basándose en esto, se puede producir un cambio de estado.
Por lo tanto, lo anterior proporciona un método para utilizar grupos de acción externos para mapear o correlacionar instrucciones de coordinación a funciones habilitadoras externas. Una capa de interpretación para mapear o correlacionar verbos de acción definidos en el habilitador de envío a funciones externas permite un pequeño acoplamiento entre servicios.
Como apreciarán aquellos con experiencia en la técnica, los metadatos de coordinación se definen usando representación XML de un diagrama de estado tal como un diagrama de estado de Harel, un diagrama de estado UML, una red de Petri, entre otros. Cada estado del diagrama se corresponde con una función expuesta por un servicio móvil externo que se podría usar para procesar contenido móvil mientras se está realizando el envío. Se podrían usar servicios, estructuras y habilitadores externos, tales como capacidades de localización, de presencia, de envío, perfil de usuario, entre otros, para personalizar el envío de contenido y la presentación de contenido de acuerdo con los ajustes del dispositivo y del usuario, la localización del usuario y el estado. El servicio podría tener más de una función expuesta.
Las funciones y servicios son identificadas por identificadores que podrían ser un identificador de recursos uniforme (URI), un nombre, un identificador único global (GUID), una etiqueta, entre otros.
Expresiones de vigilancia, verbos de acción, parámetros y resultados se expresan en términos definidos por el esquema del habilitador de envío y la estructura de envío, y/o por el esquema del servicio externo concreto. El esquema de habilitador de envío define elementos XML comprendidos por el habilitador de envío e incluye enlaces predefinidos a funciones y parámetros del habilitador externo. El esquema para el habilitador externo define parámetros adicionales que podrían ayudar al tratamiento o procesamiento de contenido móvil por el habilitador externo. Estos parámetros son opacos para el habilitador de envío y se integran dentro de los metadatos del habilitador de envío utilizando un mecanismo de extensión de esquema XML.
El habilitador de envío puede estar en el lado del dispositivo o en el lado del servicio, como se ha indicado anteriormente. En una realización adicional, se puede mover toda la funcionalidad del servidor al lado del dispositivo, y de esta forma podría existir sólo un lado del dispositivo para el habilitador de envío.
El cliente de envío y el cliente de contenido se pueden encontrar en cualquier dispositivo móvil. En la figura 7 se proporciona un dispositivo móvil concreto que se ilustra como ejemplo. Se hace ahora referencia a la Figura 7.
La Figura 7 es un diagrama de bloques que ilustra una estación móvil apropiada para ser usada con realizaciones preferentes del aparato y del método de la presente solicitud de patente. Preferiblemente, la estación 700 móvil tiene la capacidad de comunicarse con otros sistemas informáticos de Internet. Dependiendo de la funcionalidad exacta proporcionada, se puede hacer referencia al dispositivo inalámbrico como un dispositivo de mensajería de datos, un buscapersonas de dos direcciones, un dispositivo inalámbrico de correo electrónico, un teléfono móvil con capacidades de mensajería de datos, un aparato inalámbrico de Internet, o un dispositivo de comunicación de datos, como ejemplos.
En los casos en que la estación 700 móvil está habilitada para comunicación en dos direcciones, ésta incorporará un subsistema 711 de comunicación, incluyendo un receptor 712 y un transmisor 714, así como componentes asociados, preferiblemente integrados o internos, tales como uno o más elementos 716 y 718 de antena, osciladores locales (LOs) 713, y un módulo de tratamiento o procesamiento tal como un procesador 720 de señales digitales (DSP). Como resultará evidente para aquellos con experiencia en el campo de las comunicaciones, el diseño concreto del subsistema 711 de comunicación será dependiente de la red de comunicación dentro de la cual se quiera que opere el dispositivo.
Los requisitos de acceso a la red también variarán dependiendo del tipo de red 719. En algunas redes CDMA el acceso a la red está asociado con un subscriptor o usuario de la estación 700 móvil. Una estación móvil CDMA puede requerir un módulo desmontable de identidad del usuario (RUIM) o una tarjeta de módulo de identidad del subscriptor (SIM) para operar en una red CDMA. Normalmente, el interfaz 744 SIM/RUIM es similar a una ranura para tarjeta dentro de la cual una tarjeta SIM/RUIM se puede insertar y expulsar como un disquete o como una tarjeta PCMCIA. La tarjeta SIM/RUIM puede tener aproximadamente 64K de memoria y puede tener una configuración 751 de muchas claves, y otra información 753 tal como identificación, e información relacionada con el subscriptor.
Cuando se han completado los procedimientos necesarios de registro o activación de red, la estación 700 móvil puede enviar y recibir señales de comunicación por la red 719. Como se ilustra en la Figura 7, la red 719 puede consistir en múltiples estaciones base que se comunican con el dispositivo móvil. Por ejemplo, en un sistema CDMA 1x EVDO híbrido, una estación base CDMA y una estación base EVDO se comunican con la estación móvil y la estación móvil está conectada a ambas de manera simultánea. Las estaciones base EVDO y CDMA 1x utilizan diferentes ranuras de radiobúsqueda para comunicarse con el dispositivo móvil.
Las señales recibidas por la antena 716 a través de la red 719 de comunicación son entrada para el receptor 712, el cual puede realizar funciones de receptor tan comunes como amplificación de señal, conversión hacia abajo de frecuencia, filtrado, selección de canales y similares y, en el sistema de ejemplo mostrado en la Figura 7, conversión de analógico a digital (A/D). La conversión A/D de una señal recibida permite que se realicen funciones de comunicación más complejas en el DSP 720 tales como demodulación y decodificación. De una manera similar, las señales a transmitir son procesadas por el DSP 720, incluyendo por ejemplo modulación y codificación, y son entrada para el transmisor 714 para conversión de analógico a digital, conversión hacia arriba de frecuencia, filtrado, amplificación y transmisión por la red 719 de comunicación a través de la antena 718. El DSP 720 no sólo procesa señales de comunicación, sino que también garantiza control de receptor y transmisor. Por ejemplo, las ganancias aplicadas a las señales de comunicación en el receptor 712 y en el transmisor 714 pueden ser controladas de forma adaptativa mediante algoritmos de control de ganancia automáticos implementados en el DSP 720.
Preferiblemente, la estación 700 móvil incluye un microprocesador 738 que controla el funcionamiento global del dispositivo. Las funciones de comunicación, que incluyen al menos comunicaciones de voz y de datos, se realizan a través del subsistema 711 de comunicación. El microprocesador 738 también interactúa con subsistemas de dispositivo adicionales tales como la pantalla 722, la memoria flash 724, la memoria de acceso aleatorio (RAM) 726, subsistemas 728 auxiliares de entrada/salida (I/O), puerto serie 730, uno o más teclados o teclados numéricos 732, el altavoz 734, el micrófono 736, otro subsistema 740 de comunicación tal como un subsistema de comunicaciones de corto alcance y cualesquiera otros subsistemas de dispositivo designados de forma general como 742. El puerto serie 730 podría incluir un puerto USB u otro puerto conocido por aquellos con experiencia en la técnica.
Algunos de los subsistemas mostrados en la Figura 7 realizan funciones relacionadas con comunicación, mientras que otros subsistemas pueden proporcionar funciones "residentes" o del propio dispositivo. En particular, algunos subsistemas, tales como el teclado 732 y la pantalla 722, por ejemplo, se pueden usar para funciones relacionadas con comunicación, tales como introducir un mensaje de texto para su transmisión por una red de comunicaciones, y también para funciones residentes en el dispositivo tales como una calculadora o una lista de tareas.
El software de sistema operativo utilizado por el microprocesador 738 se almacena preferiblemente en un elemento de almacenamiento persistente tal como una memoria flash 724, la cual en lugar de esto puede ser una memoria de sólo lectura (ROM) o un elemento de almacenamiento similar (no mostrado). Aquellos con experiencia en la técnica apreciarán que las aplicaciones de sistema operativo, específicas del dispositivo, o partes de las mismas, se pueden almacenar temporalmente en una memoria volátil tal como una RAM 726. Las señales de comunicación recibidas también se pueden almacenar en la RAM 726.
Como se muestra, la memoria flash 724 puede estar segregada en diferentes áreas para programas 758 informáticos y para almacenamiento de datos de programa 750, 752, 754 y 756. Estos diferentes tipos de almacenamiento indican que cada programa puede destinar una porción de memoria flash 724 a sus propias necesidades de almacenamiento de datos. El microprocesador 738, además de sus funciones de sistema operativo, preferiblemente permite la ejecución de aplicaciones software en la estación móvil. Un conjunto predeterminado de aplicaciones que controlan operaciones básicas, incluyendo al menos por ejemplo aplicaciones de comunicación de datos y de voz, se instalará normalmente en la estación 700 móvil durante la fabricación. Otras aplicaciones se podrían instalar posteriormente o de forma dinámica.
Una aplicación software preferente puede ser una aplicación de gestor de información personal (PIM) que tenga la capacidad de organizar y gestionar elementos de datos relativos al usuario de la estación móvil tales como correo electrónico, eventos en el calendario, mensajes de voz, citas, y elementos de tareas, pero sin estar limitado a éstos. Naturalmente, uno o más elementos de almacenamiento de memoria estarían disponibles en la estación móvil para facilitar el almacenamiento de elementos de datos PIM. Preferiblemente, una aplicación PIM de este tipo tendría la capacidad de enviar y recibir elementos de datos, a través de la red 719 inalámbrica, con los elementos de datos correspondientes del usuario de la estación móvil almacenados o asociados con un sistema informático principal. Aplicaciones adicionales serían también almacenadas en la estación 700 móvil a través de la red 719, un subsistema 728 I/O auxiliar, un puerto serie 730, un subsistema 740 de comunicaciones de corto alcance o cualquier otro subsistema 742 apropiado, y serían instaladas por un usuario en la RAM 726 o preferiblemente en un elemento de almacenamiento no volátil (no mostrado) para su ejecución por el microprocesador 738. Tal flexibilidad en la instalación de aplicaciones aumenta la funcionalidad del dispositivo y puede proporcionar funciones mejoradas en el propio dispositivo, funciones relacionadas con comunicación, o ambas. Por ejemplo, las aplicaciones de comunicación seguras pueden hacer posible que se realicen funciones de comercio electrónico y otras transacciones financieras similares utilizando la estación 700 móvil.
En un modo de comunicación de datos, una señal recibida tal como un mensaje de texto o una descarga de una página web será procesada por el subsistema 711 de comunicación y será entrada para el microprocesador 738, el cual preferiblemente sigue procesando la señal recibida para su salida a la pantalla 722, o de forma alternativa a un dispositivo 728 I/O auxiliar. Un cliente 760 de envío, el cual podría ser equivalente al cliente 140 de envío, podría también procesar la entrada.
Un usuario de la estación 700 móvil puede también componer elementos de datos tales como mensajes de correo electrónico por ejemplo, utilizando el teclado 732, el cual es preferiblemente un teclado alfanumérico completo o un teclado numérico de tipo teléfono, en conjunto con la pantalla 722 y posiblemente con un dispositivo 728 I/O auxiliar. Elementos compuestos de este tipo se pueden transmitir a continuación por una red de comunicación a través del subsistema 711 de comunicación.
Para comunicaciones de voz, el funcionamiento global de la estación 700 móvil es similar, excepto en que las señales recibidas serían preferiblemente salida hacia un altavoz 734 y las señales para transmisión serían generadas por un micrófono 736. Subsistemas alternativos I/O de voz o de audio, tales como un subsistema de grabación de mensajes de voz, se pueden también implementar en la estación 700 móvil. Aunque preferiblemente la salida de voz o de audio se consigue principalmente a través del altavoz 734, la pantalla 722 también se puede usar para proporcionar una indicación de la identidad de una llamada entrante, la duración de una llamada de voz, u otras información relacionada con llamadas de voz por ejemplo.
El puerto serie 730 de la Figura 7 se implementaría normalmente en una estación móvil del tipo asistente digital personal (PDA) para la cual puede ser deseable la sincronización con un ordenador (no mostrado) de sobremesa del usuario, pero es un componente de dispositivo opcional. Un puerto 730 de este tipo permitiría a un usuario establecer preferencias mediante un dispositivo externo o una aplicación software y aumentaría las capacidades de la estación 700 móvil garantizando descargas de información o de software a la estación 700 móvil además de a través de una red de comunicación inalámbrica. El camino de descarga alternativo se puede utilizar por ejemplo para cargar una clave de cifrado en el dispositivo a través de una conexión directa y por lo tanto fiable y de confianza para permitir de este modo la comunicación segura de dispositivos. Como apreciarán aquellos con experiencia en la técnica, el puerto serie 730 se puede usar además para conectar el dispositivo móvil a un ordenador para que actúe como un modem.
Otros subsistemas 740 de comunicación, tales como un subsistema de comunicaciones de corto alcance, son un componente opcional adicional que puede garantizar comunicación entre la estación 700 móvil y diferentes sistemas o dispositivos, los cuales no tienen por qué ser necesariamente dispositivos similares. Por ejemplo, el subsistema 740 puede incluir un dispositivo infrarrojo y circuitos y componentes asociados o un módulo de comunicación Bluetooth® para garantizar comunicación con sistemas y dispositivos habilitados de manera similar.
Las realizaciones descritas en este documento son ejemplos de estructuras, sistemas o métodos que tienen elementos que corresponden a elementos de las técnicas de esta solicitud de patente. Esta descripción escrita puede permitir a aquellos con experiencia en la técnica fabricar y usar realizaciones con elementos alternativos que también corresponden a los elementos de las técnicas de esta solicitud de patente. De esta manera, el alcance deseado de las técnicas de esta solicitud de patente incluye otras estructuras, sistemas o métodos que no difieren de las técnicas de esta solicitud tal como se describen en este documento, e incluye además otras estructuras, sistemas o métodos con diferencias no substanciales con respecto a las técnicas de esta solicitud de patente tal como se describen en este documento.

Claims (28)

1. Un método para coordinar el tratamiento o procesamiento de contenidos en una estructura de envío móvil que comprende los pasos de:
integrar, dentro de una envuelta (420) de metadatos asociada con contenido (412), referencias externas a habilitadores y metadatos (440) externos para un habilitador de envío; y
insertar, dentro de los metadatos (440) para un habilitador de envío, reglas de coordinación de tratamiento o procesamiento de contenidos con el fin de conectar con la funcionalidad de los habilitadores externos referenciados para procesar el contenido por el habilitador de envío.
2. El método de la reivindicación 1, en el cual las reglas de coordinación de tratamiento o procesamiento de contenidos son un diagrama de estado empaquetado en lenguaje de marcado extensible 'XML'.
3. El método de la reivindicación 2, en el cual el diagrama de estado empaquetado XML comprende un bloque (510) de función con capas integradas.
4. El método de la reivindicación 3, en el cual las capas integradas comprenden una primera capa (520) que define elementos XML comunes; una segunda capa (530) que define metadatos para un habilitador de envío que tiene enlaces a habilitadores externos; y una tercera capa (540) que define metadatos para habilitadores externos.
5. El método de la reivindicación 4, en el cual la tercera capa (540) es opaca para el habilitador de envío.
6. El método de la reivindicación 4 o de la reivindicación 5, en el cual la segunda capa (530) comprende expresiones, instrucciones o parámetros que tienen un comportamiento predefinido que comprende enlace de las expresiones, instrucciones o parámetros a funciones del habilitador externo.
7. El método de cualquiera de las reivindicaciones 4 a 6, en el cual la primera capa (520) es referenciada por una sintaxis XML que define un espacio de nombres para un lenguaje de representación de diagrama de estado.
8. El método de cualquiera de las reivindicaciones 3 a 7, en el cual el bloque (510) de función contiene cualquiera o una combinación de: un identificador de estado; una expresión de vigilancia; un identificador de servicio externo; un verbo de acción; un parámetro; y/o una transición de estado.
9. El método de la reivindicación 8, en el cual el verbo de acción se usa para mapear o correlacionar instrucciones de coordinación a funciones de habilitador.
10. El método de la reivindicación 9, en el cual el mapeado es realizado por una capa de interpretación de metadatos.
11. El método de cualquiera de las reivindicaciones 8 a 10, en el cual la transición de estado se basa en un resultado recibido de usar un verbo de acción para llamar a una función externa.
12. El método de cualquiera de las reivindicaciones 1 a 11, en el cual las referencias externas son declaraciones de espacios de nombres para servicios externos.
13. El método de la reivindicación 12, en el cual los servicios externos comprenden cualquiera de entre un servicio de presencia, un servicio de localización, un servicio de filtrado de contenido, y/o un servicio de compresión.
14. El método de cualquiera de las reivindicaciones 1 a 13, en el cual el citado paso de inserción define esquemas para habilitadores externos dentro de un elemento para un estado de tratamiento o procesamiento.
15. Un sistema para coordinación de tratamiento o procesamiento de contenido que comprende:
un proveedor (110) de contenido, estando dicho proveedor (110) de contenido adaptado para integrar referencias externas a habilitadores externos y metadatos para un habilitador de envío dentro de metadatos de envío de contenido móvil asociados con contenido (332) suministrado por el citado proveedor (110) de contenido, y adaptado para insertar en los metadatos reglas de tratamiento o procesamiento de contenido para un habilitador de envío con el fin de conectar con la funcionalidad de los habilitadores externos referenciados para procesar el contenido por el habilitador de envío;
un habilitador de envío de contenido que comprende:
un servidor (120) de envío, estando dicho servidor (120) de envío adaptado para procesar metadatos (312) dirigidos a dicho servidor (120) de envío; y
un cliente (140) de envío, estando dicho cliente (140) de envío adaptado para procesar metadatos (314) dirigidos a dicho cliente (140) de envío;
habilitadores externos adaptados para procesar contenido basándose en las reglas de coordinación de tratamiento o procesamiento de contenido a través de (mediante) dicho habilitador de envío de contenido; y
un cliente (150) de contenido adaptado para consumir contenido procedente del proveedor (110) de contenido.
16. Un paquete de contenido que comprende:
contenido (412); y
una envuelta (420) de metadatos, comprendiendo la envuelta (420) de metadatos referencias externas a habilitadores externos y metadatos (440) para un habilitador de envío, teniendo los metadatos (440) para un habilitador de envío reglas de coordinación de tratamiento o procesamiento de contenido integradas en él con el fin de conectar con la funcionalidad de los habilitadores externos referenciados para el tratamiento o procesamiento del contenido por el habilitador de envío.
17. El paquete de contenido de la reivindicación 16, en el cual las reglas de coordinación de tratamiento o procesamiento de contenido son un diagrama de estados empaquetado en lenguaje de marcado extensible (XML).
18. El paquete de contenido de la reivindicación 17, en el cual el diagrama de estados empaquetado XML comprende un bloque (510) de función con capas integradas.
19. El paquete de contenido de la reivindicación 18, en el cual las capas integradas comprenden una primera capa (520) que define elementos XML comunes; una segunda capa (530) que define metadatos para un habilitador de envío que tiene enlaces a habilitadores externos; y una tercera capa (540) que define metadatos para habilitadores externos.
20. El paquete de contenido de la reivindicación 19, en el cual la tercera capa (540) es opaca para el habilitador de envío.
21. El paquete de contenido de la reivindicación 19 o de la reivindicación 20, en el cual la segunda capa (530) comprende expresiones, instrucciones o parámetros que tienen un comportamiento predefinido que comprende enlace de las expresiones, de las instrucciones o de los parámetros a funciones del habilitador externo.
22. El paquete de contenido de cualquiera de las reivindicaciones 19 a 21, en el cual la primera capa (520) es referenciada por una sintaxis XML de definición de espacio de nombres para un lenguaje de representación de diagrama de estados.
23. El paquete de contenido de cualquiera de las reivindicaciones 18 a 22, en el cual el bloque (510) de función contiene cualquier elemento o cualquier combinación de: un identificador de estados; una expresión de vigilancia; un identificador de servicio externo; un verbo de acción; un parámetro; y/o una transición de estado.
24. El paquete de contenido de la reivindicación 23, en el cual el verbo de acción está adaptado para ser usado para mapear o correlacionar instrucciones de coordinación a funciones de habilitador.
25. El paquete de contenido de cualquiera de las reivindicaciones 16 a 24, en el cual las referencias externas son declaraciones de espacio de nombres para servicios externos.
26. El paquete de contenido de la reivindicación 25, en el cual los servicios externos comprenden cualquiera de un servicio de presencia, un servicio de localización, un servicio de filtrado de contenido, y/o un servicio de compresión.
27. El paquete de contenido de cualquiera de las reivindicaciones 16 a 26, que comprende además esquemas para habilitadores externos dentro de un elemento para un estado de tratamiento o procesamiento.
28. Un medio que puede leer un ordenador que almacena un código de programa para hacer que un dispositivo informático realice los pasos del método de cualquiera de las reivindicaciones 1 a 14.
ES07104833T 2007-03-23 2007-03-23 Metodo y sistema para la organizacion del tratamiento de contenidos en estructuras de envio moviles. Active ES2348052T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP07104833A EP1973300B1 (en) 2007-03-23 2007-03-23 Method and system for orchestration of content processing in mobile delivery frameworks

Publications (1)

Publication Number Publication Date
ES2348052T3 true ES2348052T3 (es) 2010-11-29

Family

ID=38372384

Family Applications (1)

Application Number Title Priority Date Filing Date
ES07104833T Active ES2348052T3 (es) 2007-03-23 2007-03-23 Metodo y sistema para la organizacion del tratamiento de contenidos en estructuras de envio moviles.

Country Status (11)

Country Link
EP (2) EP2214377B1 (es)
JP (1) JP4864022B2 (es)
KR (1) KR101076354B1 (es)
CN (1) CN101272401B (es)
AT (1) ATE473588T1 (es)
CA (1) CA2626176C (es)
DE (1) DE602007007573D1 (es)
ES (1) ES2348052T3 (es)
HK (1) HK1122434A1 (es)
MX (1) MX2008003300A (es)
TW (1) TWI367016B (es)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI414991B (zh) * 2010-03-17 2013-11-11 Kye Systems Corp The method of implementing multi-touch and its system
CN101867914A (zh) * 2010-06-10 2010-10-20 中兴通讯股份有限公司 动态内容分发的同步方法、***、服务器及客户端

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003234851A (ja) * 2002-02-08 2003-08-22 Nippon Telegraph & Telephone East Corp 複数ネットワークによる提供情報配信システムおよびその方法、提供情報配信プログラムとそのプログラムを記録した記録媒体、提供情報配信装置、回線課金装置、利用者装置、および各装置を機能させるためのプログラムとそのプログラムを記録した記録媒体
GB2386978B (en) * 2002-03-25 2007-03-28 Sony Uk Ltd Data communications network
US7228357B2 (en) * 2002-09-23 2007-06-05 Sharp Laboratories Of America, Inc. System and method for automatic digital document processing
JP2005157475A (ja) * 2003-11-20 2005-06-16 Dainippon Printing Co Ltd 情報伝達システム
JP4321340B2 (ja) * 2004-04-22 2009-08-26 ソニー株式会社 再生装置
JP2005352945A (ja) * 2004-06-14 2005-12-22 Matsushita Electric Ind Co Ltd スタイルシート作成装置
JP2006040259A (ja) * 2004-06-25 2006-02-09 Fuji Photo Film Co Ltd 通信端末、サーバ、再生制御方法及びプログラム
JP4899295B2 (ja) * 2004-07-01 2012-03-21 富士通株式会社 メタデータエディタプログラム、メタデータエディタ装置およびメタデータエディタ方法
JP2006134102A (ja) * 2004-11-05 2006-05-25 Fuji Xerox Co Ltd ディレクトリ編集支援プログラム、ディレクトリ編集支援方法及びディレクトリ編集支援装置
JP4456992B2 (ja) * 2004-12-01 2010-04-28 ソフトバンクモバイル株式会社 コンテンツ提供方法及びサーバ
JP2006350735A (ja) * 2005-06-16 2006-12-28 Nippon Signal Co Ltd:The 情報配信システム
JP2007034743A (ja) * 2005-07-27 2007-02-08 Nippon Telegraph & Telephone East Corp コンテンツ配信システムおよび方法、プログラム

Also Published As

Publication number Publication date
KR20080086813A (ko) 2008-09-26
ATE473588T1 (de) 2010-07-15
MX2008003300A (es) 2009-02-26
JP2008245258A (ja) 2008-10-09
HK1122434A1 (en) 2009-05-15
CA2626176C (en) 2012-05-22
DE602007007573D1 (de) 2010-08-19
TWI367016B (en) 2012-06-21
CN101272401A (zh) 2008-09-24
TW200904102A (en) 2009-01-16
CA2626176A1 (en) 2008-09-23
EP2214377A3 (en) 2010-10-13
JP4864022B2 (ja) 2012-01-25
EP1973300B1 (en) 2010-07-07
KR101076354B1 (ko) 2011-10-25
CN101272401B (zh) 2012-06-27
EP2214377B1 (en) 2017-03-01
EP1973300A1 (en) 2008-09-24
EP2214377A2 (en) 2010-08-04

Similar Documents

Publication Publication Date Title
US7187660B2 (en) System and method for continuously provisioning a mobile device
US8769125B2 (en) Method and apparatus for ensuring transport of user agent information
US8605667B2 (en) Systems and methods for exposing different service facades of an underlying network
KR101362469B1 (ko) 컨텍스트-기반 규칙들을 이용하여 비신뢰적인 네트워크들 상에서 트랜잭션들과 데이터를 스위칭하기 위한 적응적 게이트웨이
US20170195165A1 (en) Defining configurable characteristics of a product and associating configuration with enterprise resources
US20060282516A1 (en) System and method for discovering component applications
US20110208801A1 (en) Method and apparatus for suggesting alternate actions to access service content
US8954041B1 (en) System and method for ID platform
Russello et al. A policy-based publish/subscribe middleware for sense-and-react applications
CN102291243A (zh) 业务处理服务器、***和方法
US8589956B2 (en) Method and apparatus for providing application with interface to composite network service
US20160054984A1 (en) Method and apparatus for providing template-based applications
US20060259577A1 (en) System and method for customizing services for applications
CN102594859B (zh) 一种业务数据的呈现方法、终端、服务器及***
US20100223263A1 (en) Method and system for orchestration of content processing in mobile delivery frameworks
ES2348052T3 (es) Metodo y sistema para la organizacion del tratamiento de contenidos en estructuras de envio moviles.
EP1962467B1 (en) Method and system for correlation of mobile channel subscription with delivery context
BRPI0704532B1 (pt) método e produto de programa de computador para adição de inteligência de processamento, envelope de conteúdo, e método, sistema e produto de programa de computador para o processamento de um envelope
US8407320B2 (en) Method and system for correlation of mobile channel subscription with delivery context
Curran Understanding the Internet: a glimpse into the building blocks, applications, security and hidden secrets of the Web
OKUMBOR et al. WEB SERVICES ON MOBILE PLATFORM FOR ADVANCING DEVELOPMENT GROWTH
KR20090051718A (ko) 컨텐츠 전달 시스템에 대한 애플리케이션 선호도 등록을 위한 방법 및 시스템
GB2503571A (en) Enabling updates of a mobile application