MÉTODO Y SISTEMA PARA ORQUESTACIÓN DE PROCESAMIENTO DE CONTENIDO EN ESTRUCTURAS DE DISTRIBUCIÓN MÓVIL DESCRIPCIÓN DE LA INVENCIÓN La presente descripción se refiere generalmente a distribución de contenido móvil y en particular a la utilización de habilitadores para facilitar la distribución de contenido móvil. Los usuarios de dispositivos móviles o equipo de usuario móvil (UE) se están volviendo cada vez 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 del contenido dinámico permite a usuarios tener información suscrita o datos dinámicamente distribuidos a los mismos en lugar de tener que ir y buscar los datos. Ejemplos de datos podrían incluir cotizaciones de bolsa, actualizaciones climáticas, actualizaciones de tráfico, papel tapiz dinámico, anuncios, aplicaciones u otros datos deseables para el usuario. La distribución de contenido con frecuencia requiere varios habilitadores en el lado del servidor y en el lado del dispositivo. Estos habilitadores no son parte de la funcionalidad central de un habilitador de distribución y un sistema y método se requieren para poder coordinar el procesamiento de contenido con otros habilitadores.
El presente sistema y método pueden proporcionar la integración de referencias externas y reglas de coordinación de procesamiento de contenido dentro de metadatos de distribución de contenido móvil. En particular, se proporciona un método para expresar las reglas de coordinación para los metadatos de distribución móvil como un diagrama de estado empacado de XML. Un proveedor de contenido puede integrar metadatos para varios elementos de procesamiento dentro de la estructura de distribución. Se incluyen en los metadatos instrucciones para el habilitador de distribución de contenido. Además, pueden proporcionarse declaraciones externas de espacio de nombre para habilitadores externos. Los espacios de nombre que se refieren a los esquemas de XML que representan el enlace a habilitadores externos pueden incluirse para coordinar el procesamiento de contenido móvil mientras se está distribuyendo un paquete de contenido. Esto se logra al integrar elementos y atributos definidos en los esquemas de XML correspondientes dentro de un elemento de XML para el estado de procesamiento. Pueden utilizarse verbos de acción para mapear instrucciones de coordinación en funciones de habilitador externo. Este nivel de indirección permite el acoplamiento bajo entre servicios. La presente descripción por lo tanto puede
proporcionar un método para coordinar el procesamiento de contenido en una estructura de distribución móvil que comprende las etapas de: integrar, dentro de una envoltura de metadatos asociada con contenido, referencias externas a los habilitadores externos; e insertar reglas de coordinación de procesamiento de contenido en la envoltura de metadatos. La presente descripción además puede proporcionar un sistema para la coordinación de procesamiento de contenido que comprende: un proveedor de contenido, el proveedor de contenido adaptado para integrar referencias externas y reglas de coordinación de procesamiento de contenido dentro de los metadatos de distribución de contenido móvil asociados con contenido proporcionado por el proveedor de contenido; un habilitador de distribución de contenido que comprende: un servidor de distribución, el servidor de distribución adaptado para procesar metadatos dirigidos al servidor de distribución; y un cliente de distribución, el cliente de distribución adaptado para procesar los metadatos dirigidos al cliente de distribución; habilitadores externos adaptados para procesar el contenido basándose en las reglas de coordinación de procesamiento de contenido a través del habilitador de distribución de contenido; y un cliente de contenido adaptado para consumir el contenido del proveedor de contenido. La presente descripción además puede proporcionar
un paquete de contenido que comprende: contenido; y una envoltura de metadatos, la envoltura de metadatos tiene referencias externas a los habilitadores externos y reglas de coordinación de procesamiento de contenido integradas en los mismos . 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 que muestra componentes lógicos dentro de una arquitectura de distribución; la Figura 2 es un diagrama de bloque que ilustra el flujo de metadatos entre los componentes lógicos de la Figura 1. la Figura 3 es un diagrama de bloque que ilustra un modelo envuelto para procesamiento de metadatos entre los componentes lógicos de la Figura 1. la Figura 4 es un diagrama de bloque que muestra un paquete de contenido ejemplar que incluye contenido y una envoltura de metadatos. la Figura 5 es un diagrama de bloque que muestra un bloque de función; la Figura 6 es un diagrama de estado que muestra la coordinación ejemplar de metadatos entre un habilitador de distribución de contenido y habilitadores externos; y
la Figura 7 es un diagrama de bloque que muestra un dispositivo móvil ejemplar que puede utilizarse junto con el método y sistema de la presente descripción. Ahora se hace referencia a la Figura 1. Se ilustra un sistema de inserción para distribuir contenido dinámico a una aplicación de cliente. El sistema de la Figura 1 es un sistema simplificado y muestra componentes lógicos que necesitan estar en una arquitectura de distribución de contenido dinámico. Sin embargo, como se apreciará por aquellos con experiencia en la técnica, otros componentes podrían existir o varios componentes podrían agruparse j untos . La arquitectura 100 incluye un proveedor 110 de contenido. El proveedor 110 de contenido se dispone para proporcionar contenido dinámico a usuarios. Este puede incluir, por ejemplo, un sitio web que vende libros. El proveedor 110 de contenido puede proporcionar periódicamente una lista de libros recién puestos en circulación que pueden ya sea enviarse a suscriptores que están suscritos al sitio web o a un servidor de distribución que administra las suscripciones . Un servidor 120 de distribución se comunica sobre una red 130 inalámbrica con un cliente 140 de distribución que se localiza en un dispositivo móvil en una modalidad preferida. El cliente 140 de distribución recibe el contenido
que se está distribuyendo desde el proveedor 110 de contenido y puede comunicar el contenido con un cliente 150 de contenido. El cliente 150 de contenido al final consume el contenido . Como se apreciará por aquellos con experiencia en la técnica, un habilitador en la presente descripción es equivalente a una estructura. De este modo, el habilitador de distribución comprende el servidor 120 de distribución y el cliente 140 de distribución. Como se apreciará por aquellos con experiencia en la técnica, varias funciones externas pueden requerirse para la distribución del contenido al cliente 150 de contenido. Estas funciones externas pueden existir en el lado 102 del servidor y el lado 104 de dispositivo. En la Figura 1, las funciones externas se muestran como funciones 132, 134 y 136 externas en el lado 102 del servidor y las funciones 144, 146 y 148 externas en el lado 104 del dispositivo. Ejemplos de funciones externas pueden incluir pero no se limitan a presencia, ubicación, clasificación de contenido y compresión, entre otros. Ahora se hace referencia a la Figura 2. 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
distribución de contenido genérico requiere que metadatos permitan que varios proveedores de contenido y clientes de contenido existan dentro del sistema. Los metadatos pueden tener varias formas, incluyendo parámetros o reglas de procesamiento, o una administrador de procesamiento, código o referencia proporcionadas directamente o un enlace a un administrador de procesamiento, código o reglas en otra ubicación . Como puede observarse en la Figura 2, el contenido pasa desde el proveedor 110 contenido hasta el cliente 150 de contenido, como se ilustra por la flecha 210. Los metadatos, los cuales proporcionan instrucciones para varios componentes de la arquitectura 100 también pueden pasar entre los componentes dentro de la arquitectura 100, normalmente junto con el contenido. Por ejemplo, la flecha 200 ilustra los metadatos para el cliente de contenido que se origina en el proveedor 110 de contenido y está oculta al sistema de distribución hasta que alcance a un cliente 150 de contenido. La flecha 230 muestra metadatos creados por un proveedor 110 de contenido que se pretende para el cliente 140 de distribución y de este modo sólo fluye hacia el cliente 140 de distribución. La flecha 240 ilustra metadatos generados por el servidor 120 de distribución y se pretende para el cliente 140 de distribución y de este modo primero se asocia con el
contenido en el servidor 120 de distribución y se desprende del contenido en el cliente 140 de distribución. Ejemplos de donde esto podría presentarse incluyen acuerdos entre un usuario y un proveedor de servicio con respecto a un plan de facturación y el nivel de servicio que va ha proporcionarse, donde el proveedor de servicio puede utilizar los metadatos para limitar los servicios disponibles o proporcionar servicios mejorados. Ahora se hace referencia a la Figura 3. La Figura 3 ilustra un modelo de envoltura de varias capas para los metadatos de contenido. Un servidor 120 de distribución recibe una envoltura 310 de inserción que incluye metadatos 312 de procesamiento de contenido para el servidor 120 de distribución y una envoltura 314 de cliente de distribución. El servidor 120 de distribución extrae los metadatos 312 de procesamiento de contenido y utiliza estos metadatos para procesar la envoltura 314 de cliente de distribución. Los metadatos 312 dictan al servidor 120 de distribución qué hacer con la envoltura 314 de cliente de distribución. La envoltura 314 de cliente de distribución se pasa al cliente 140 de distribución, donde se descompone en una envoltura 320 de contenido y metadatos 322 de procesamiento de contenido. Los metadatos 322 de procesamiento de contenido se utilizan por el cliente 140 de distribución para procesar
en la envoltura 320 de contenido. Por ejemplo, esto puede utilizarse para instruir al cliente 140 de distribución para realizar una sustitución de la envoltura 320 de contenido previamente distribuida con la última envoltura si el cliente 150 de contenido sólo esta interesado en la última versión del contenido. La envoltura 320 de contenido se pasa al cliente 150 de contenido. La envoltura 320 de contenido incluye metadatos 330 de procesamiento de contenido para el cliente 150 de contenido y la carga útil 332 de contenido que va ha consumirse por el cliente 150 de contenido. Como se apreciará por aquellos con experiencia en la técnica, la inserción de envolturas de acuerdo con la Figura 3 proporciona un ambiente dinámico rico en el cual el procesamiento puede presentarse en cualquier elemento de procesamiento de la arquitectura y en el cual el proveedor 110 de contenido puede especificar cómo va ha tratarse el contenido especifico. En una modalidad, los metadatos se dirigen a un elemento lógico particular y están ocultos a otros elementos de procesamiento. Como se apreciará adicionalmente, los metadatos solamente pueden incluirse para varias fases de la distribución de contenido. Por ejemplo, los metadatos sólo pueden requerirse entre el servidor 120 de distribución y el cliente 140 de distribución y de este modo no pueden
incluirse los metadatos para el cliente 150 de contenido. Otras alternativas pueden ser evidentes para aquellos con experiencia en la técnica. Mientras lo anterior describe metadatos para un habilitador de distribución de contenido, en algunos casos un habilitador de distribución de contenido móvil puede necesitar encargarse de otras estructuras y habilitadores mientras distribuye el contenido a un cliente 150 de contenido. Similarmente, un habilitador de distribución puede necesitar encargarse de otras estructuras y habilitadores mientras distribuye el contenido al cliente 150 de contenido. Como se indica en lo anterior, ejemplos de funciones externas incluyen presencia, ubicación, clasificación de contenido, comprensión, entre otras. Por ejemplo, una habilitador externo puede ser un habilitador de presencia. Un usuario puede haber especificado una regla para que cierto contenido sólo deba distribuirse cuando el usuario está en una red local para evitar cargos por itinerancia de datos. Tal habilitador necesita utilizar la funcionalidad de otros habilitadores tal como un habilitador de ubicación para encontrar donde se localiza el dispositivo móvil. Otros ejemplos de habilitadores incluyen clasificación de contenido que podría prevenir que ciertos tipos de contenido se distribuyan al dispositivo móvil. En el lado del dispositivo, un ejemplo de un
habilitador puede ser un habilitador de comprensión que puede necesitar descomprimir cierto contenido antes de que se pase a un cliente 150 de contenido. Un habilitador de distribución de contenido puede no tener típicamente la funcionalidad de los habilitadores externos y de este modo necesitar acceder habilitadores externos para proporcionar una estructura de distribución de contenido rica. Como se apreciará por aquellos con experiencia en la técnica, el contenido debe estar oculto para la estructura de distribución. La única forma de indicar por lo tanto la necesidad de procesamiento de contenido externo y para coordinar este procesamiento es a través del uso de metadatos . Ahora se hace referencia a la Figura 4. La Figura 4 ilustra un paquete 410 de contenido ejemplar 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 envoltura 420 de metadatos. Como se indica en lo anterior, el contenido 412 debe estar oculto para la estructura de distribución. Por lo tanto, la única forma de indicar la necesidad de procesamiento de contenido externo, y de coordinar este procesamiento, es a través del uso de metadatos en la envoltura 420 de metadatos.
La envoltura 420 de metadatos incluye un cuadro 430 de declaración de espacio de nombre, el cual permite declaraciones de espacio de nombre para servicios externos que se utilizarán para procesar el contenido 412. Dos declaraciones de espacio de nombre ejemplares se muestran con el número 435 de referencia. La envoltura 420 de metadatos además incluye de preferencia un bloque 440 de metadatos para el procesamiento por un servidor de distribución tal como el servidor 120 de distribución de la Figura 1. El bloque 440 de metadatos incluye varios metadatos para procesamiento por el servidor de distribución. El bloque 440 de metadatos además incluye varios bloques de función para encargarse de funciones externas. Estas se ilustran por los bloques 442 y 444 de función en la Figura 4. La envoltura 420 de metadatos también incluye un bloque 450 de metadatos para procesamiento por un cliente de distribución tal como el cliente 140 de distribución de la Figura 1. El bloque 450 de metadatos incluye metadatos que se procesan por el cliente de distribución junto con los bloques 452 y 454 de función. Como se apreciará por aquellos con experiencia en la técnica, el uso de dos bloques de función para encargarse de funciones externas en el bloque 450 solamente es un ejemplo y la presente descripción no es para que se limite a
un cierto número de funciones externas encargadas por bloques de función externa. En otras palabras, el bloque 440 de metadatos o el bloque 450 de metadatos no podrían incluir instrucciones o reglas para encargarse de funciones externas y de este modo ningún bloque de función, o podría encargarse de múltiples funciones externas a través de muchos bloques de función . Un ejemplo de un bloque de función, tal como el bloque 442 de función, se ilustra por el número 460 .de referencia. El número 460 de referencia señala 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 en un árbol de estados. El bloque de función de preferencia incluye un identificador 462 de estado, el cual identifica el estado del bloque de función en el árbol de estados. El bloque de función además puede incluir una expresión de protección y/o una condición 464, la cual incluye una expresión lógica que, si se satisface, provoca que el procesamiento del estado se realice. El bloque de función además podría incluir un servicio externo o identificador 466 de función para identificar el servicio o función externo que se utiliza. El bloque de función podría incluir además verbos 468 de acción que definen que función de un servicio externo
debe utilizar el habilitador de distribución de contenido. El bloque de función podría incluir además parámetros 470 que definen la lista de parámetros que necesitan pasarse al habilitador externo cuando se involucra la función definida en este bloque de función. El bloque de función podría incluir además una transición 472 de estado basándose en los resultados de los verbos de acción para indicar que estado mover al siguiente. Ahora se hace referencia a la Figura 5. La Figura 5 ilustra una estructura de capas del bloque 510 de función, el cual es una representación de un estado de procesamiento. Varios bloques integrados existen dentro del bloque 510 de función como se describe en lo siguiente. Un primer bloque 520 es un conjunto de elementos comunes de XML que definen el diagrama de estado. Como se apreciará por aquellos con experiencia en la técnica, el término "elemento" es un término amplio e incluye un subconjunto de un documento de XML que comienza y finaliza con etiquetas correspondientes de XML. El bloque 520 incluye elementos que son referidos por el espacio de nombre que define la sintaxis XML para un lenguaje de presentación de diagrama de estados. Ejemplos incluyen lenguaje de marcación extensible de diagrama de estados (SCXML) , lenguaje de ejecución de proceso comercial (BPEL) y Xproc, entre otros.
Un bloque 530 integrado adicional contiene metadatos definidos por el habilitador de distribución, que incluyen enlaces a habilitadores externos. El bloque 530 incluye XML que es referido por el espacio de nombre para el habilitador de distribución e incluye todos los enlaces de XML a habilitadores externos e instrucciones de procesamiento interno, si las hubiera. Un bloque 540 integrado adicional se define por metadatos para su utilización por habilitadores externos. Este bloque es referido por el espacio de nombre para el habilitador externo e incluye elementos definidos en el esquema de habilitador externo. Estos elementos están ocultos al habilitador de distribución. Como se apreciará por aquellos con experiencia en la técnica, los elementos dentro del bloque 530 especifican un comportamiento predefinido del habilitador de distribución que incluye el enlace de elementos sobre funciones/parámetros del habilitador externo. Estos elementos deben entenderse por la capa de interpretación de metadatos del habilitador de distribución. Inversamente, los elementos dentro del bloque 540 están ocultos para el habilitador de distribución y se pasan al habilitador externo "como son". Estos elementos representan construcciones definidas por el esquema del habilitador externo y por lo tanto se entienden por el habilitador externo.
Lo anterior por lo tanto proporciona un método para utilizar espacios de nombre y esquemas que representan enlaces a habilitadores externos para poder coordinar el procesamiento de contenido móvil mientras está en distribución. Esto se logra al integrar elementos definidos en esquemas correspondientes dentro de un elemento de X L para el estado de procesamiento. Lo anterior se entenderá más claramente con referencia al siguiente segmento de código de SCXML ejemplar y con referencia a la Figura 6. Lo siguiente ilustra un ejemplo de metadatos de coordinación expresados en SCXML: <scxml xmlns="http://www.w3.org/2005/07/scxml" xmlns:dcd="http://oma.org/dcd/1.0" xmlns:dp="http://oma.org/dcd/1.0/dcap" xmlns:l="http://xyz.com/locat¡on/1.0 xmlns:p="http://abc.net/presence/1.0/" ¡nitialstate-'Content Rece¡ved"> <state id="Content Received"> <invoke src="checkMemory"> <dcd:action funct¡on-¡d="DCAP:checkMemory"> <dcd:verb>validateMemorySize</dc:verb> <dcd:param>ContentHeader:dev¡celD<dcd:param> <dcd:param>ContentHeader:contentSize<dcd:param> <dp:funct¡on>checkMemory</dp:function> <dp:resultType>boolean</dp:resultType> </dcd:action> </invoke> <transition event="success" cond="checkMemory.result" target- 'Check Roaming7> <transition event="failure" cond="!checkMemory.result" target- 'Check Fragmentat¡on"/> </state>
<state id="Check Roaming"> <invoke src="isRoaming"> <dcd:action function-id="LOC:isRoaming"> <dcd:verb>isHomeNetwork</dcd:verb> <dcd:param>ContentHeader:devicelD<dcd:param> <dcd:someExoticElement>"if not in Finland"<dcd:someExoticElement> <l:name>isRoaming</l:name> <l:param>"ignoreNetworkAgreements=truen</l:param> </dcd:action> </invoke> <transition event="success" cond="isRoaming.result" target="Check Availability7> <transition event="failure" cond="!isRoaming.result" target="Send Rejected"/> </state> <state id="Check Availability"> <invoke src="isAvailable"> <dcd:action function-id="PRES:isAvailable"> </dcd:action>
</scxml>
Las primeras cinco lineas del segmento de código anterior son parte del bloque 430 de la Figura 4. Específicamente, estas son declaraciones de espacio de nombre para la versión de XML, así como declaraciones de nombre de espacio para la distribución de contenido dinámico, un habilitador con capacidades de dispositivo, un habilitador de ubicación de dispositivo y un habilitador de presencia de dispositivo. Como se apreciará, estos son ejemplos solamente de varios habilitadores que podrían utilizarse y declararse como parte de las declaraciones de espacio de nombre. Además,
las declaraciones de espacios de nombre mostradas en lo anterior se incluyen solamente como un ejemplo y no representan URL reales para habilitadores . La siguiente linea del código indica ? initialstate="content received"' , Esto muestra el estado inicial para proceder con el procesamiento de contenido. La siguiente linea indica ^state id = "content received'" . Esta es parte del bloque 520 de la Figura 5 y define el estado del bloque de función. Además, la linea ^invoke src = "checkMemory"' es parte del bloque 520 de la Figura 5 y le está diciendo al SCXML para que invoque una función externa. La siguiente linea indica cdraction function-id="DCAP : checkMemory" ' . Esta acción define que la función externa checkMemory en habilitador de capacidades de distribución debe utilizarse. La siguiente linea es
<dcd: verb>validateMemorySize</dcd: verb> . Este es un verbo de acción que el habilitador de distribución de contenido dinámico entiende. Las siguientes dos lineas indican parámetros que la función externa checkMemory utiliza. La siguiente linea es
<dp : function>checkMemory</dp : function> . Este mapea el verbo de acción dcd validateMemorySize en la función externa. En
este caso, la función externa es check emory y es parte del habilitador de capacidad de dispositivo definido utilizando el nombre "dp" en la definición de espacio de nombre. La siguiente linea define el tipo de resultados que se espera de la función externa. A partir del segmento de código anterior, los parámetros dcd:action, dcd:verb y dcd : parameters pertenecen al bloque 530 de la Figura 5. Estos son un comportamiento predefinido del habilitador de distribución e incluyen enlace de elementos sobre funciones o parámetros del habilitador externo . Las lineas dp:function y dprresult pertenecen al bloque 540 y están ocultas al habilitador de dcd. La linea: <transition event="success" cond="checkMemory . result" target="Check Roaming"/> es una comprobación para ver si un evento especifico ocurrió o no si se ha satisfecho una condición. Si el evento ha ocurrido y la condición se ha satisfecho, entonces esta linea define el siguiente estado para proceder. En este caso, el siguiente estado es "Check Roaming" . En la linea <transition event="failure" cond=" ! isRoaming . result" target="Send Rejected"/>, el evento falla y la memoria de comprobación se vuelve xfalsa' , entonces el estado procede a "Check Fragmentation" . Como se apreciará por aquellos con experiencia en
la técnica, los eventos de transición definidos en lo anterior pertenecen al bloque 520 de la Figura 5. Con referencia a la FIGURA 6, lo anterior se ilustra con referencia a los diagramas de estado. Específicamente, el estado 610 inicial es el estado: "Content Received". Un verbo de acción validateMemorySize se utiliza dentro del habilitador 602 de distribución de contenido y se interpreta en la capa 604 de interpretación de metadatos. En la capa 604 de interpretación de metadatos, se invoca la función externa checkMemory 620, pasando los parámetros del dispositivo eviceID' y xcontentSize' . El habilitador 622 de capacidades de dispositivo entonces devuelve un resultado 624 nuevamente a la capa 604 de interpretación de metadatos, la cual entonces pasa el parámetro nuevamente a través del verbo validateMemorySize 612, y el resultado 614 se pasa nuevamente al estado 610. El resultado 614 se comprueba en la etapa 630 y si es verdadero, el estado hace transición al estado 640 de "Check Roaming" y si es falso, el estado hace transición a un estado "Check Fragmentation" [no mostrado] . Con referencia nuevamente al segmento de código anterior, un bloque de función adicional se define por 'state ID ="check roaming". La acción se define para la distribución de contenido dinámico utilizando la 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 siguiente linea como ContentHeader : devicelD. La distribución de contenido dinámico puede utilizar cualesquier elementos arbitrarios definidos en su esquema tal como la expresión "someExoticElement" . La dos siguientes lineas, particularmente: <1 : name>isRoaming</l : name> <1 : param>"ignoreNetworkAgreements=true" </l : param> definen una función externa que se mapea en el verbo "isHomeNetwork" . La función externa es la función "isRoaming" e incluye un parámetro de "ignoreNetworkAgreements" . Como se apreciará por aquellos con experiencia en la técnica, el habilitador de ubicaciones se adapta para manejar esta función y la función está oculta al habilitador de distribución de contenido dinámico. Las siguientes dos lineas definen las transiciones. Si el "isRoaming" se vuelve verdadero, entonces la transición de estado hace transición a un estado de disponibilidad de comprobación. Si el resultado "is roaming" es falso, entonces el estado hace transición a un estado de "Send Rejected". Esto se ilustra en la Figura 6. En la Figura 6, el estado 640 es el estado "CheckRoaming" y el verbo 642 de
acción "isHomeNetwork" puede utilizarse del estado 640. La capa 604 de interpretación de metadatos interpreta el "isHomeNetwork" y utiliza el verbo de acción para invocar una función 650 de "isRoaming" en un habilitador 652 de ubicación. El habilitador 652 de ubicación devuelve un resultado 654, el cual se propaga a través de la capa 604 de interpretación de metadatos al verbo 642 de "isHomeNetwork", el cual devuelve un resultado 644 al estado 640 de itinerancia de comprobación. El resultado entonces se comprueba en 660, el cual corresponde a los comandos de "transición" en el código anterior. Si el resultado en 660 es verdadero, el estado hace transición al estado 670 a un estado "Check Availability". De otra manera, el estado procede 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 de "isUserAvailable" e invoca la función 680 "isAvailable" del habilitador 682 de presencia. Un resultado 684 se devuelve y entonces se devuelve como resultado 674 al estado 670. Basándose en esto, puede presentarse una transición de estado . Lo anterior proporciona por lo tanto un método para
utilizar grupos de acción externos para mapear instrucciones de coordinación en funciones de habilitador externo. Una capa de interpretación para mapear verbos de acción definidos en el habilitador de distribución sobre funciones externas permite un acoplamiento bajo entre servicios. Como se apreciará por aquellos con experiencia en la técnica, los metadatos de coordinación se definen utilizando representación de XML de un diagrama de estado tal como un estado Harel, diagrama de estado UML, Petri net, entre otros. Cada estado en el diagrama corresponde con una función expuesta por un servicio móvil externo que podría utilizarse para procesar contenido móvil mientras está en distribución. Servicios externos, estructuras y habilitadores , tales como de ubicación, presencia, capacidades de distribución, perfil de usuario, entre otros, podrían utilizares para personalizar la distribución de contenido y la presentación de contenido de acuerdo con el dispositivo y los ajustes de usuario, ubicación de usuario y estado. El servicio podría tener más de una función expuesta. Funciones y servicios se definen por identificadores que podrían ser un identificador de recursos uniforme (URI), nombre, un identificador único global (GUID) , una etiqueta, entre otros. Expresiones de protección, verbos de acción, parámetros y resultados se expresan en términos definidos por
el esquema del habilitador de distribución y la estructura de distribución, y/o por el esquema de un servicio externo particular. El esquema del habilitador de distribución define los elementos de XML entendidos por el habilitador de distribución e incluye enlaces predefinidos a funciones de habilitador externo y parámetros. El esquema para el habilitador externo define parámetros adicionales que podrían ayudar a procesar el contenido móvil por el habilitador externo. Esos parámetros están ocultos al habilitador de distribución y se integran dentro de los metadatos del habilitador de distribución utilizando un mecanismo de extensión de esquema XML. El habilitador de distribución puede estar en cualquiera del lado del dispositivo o el lado del servicio, como se indicó en lo anterior. En una modalidad adicional, toda la funcionalidad del servidor puede cambiarse al lado del dispositivo, y de este modo sólo un lado del dispositivo podría existir para el habilitador de distribución. El cliente de distribución y el cliente de contenido pueden encontrarse en cualquier dispositivo móvil. Un dispositivo móvil particular que se ilustra como un ejemplo se proporciona en la Figura 7. Ahora se hace referencia a la Figura 7. La Figura 7 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 700 móvil de preferencia es un dispositivo de comunicación inalámbrico de dos vías que tiene por lo menos capacidades de comunicación de voz y datos. La estación 700 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 referirse 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 mensajes de datos, un aparato de Internet inalámbrico, o un dispositivo de comunicación de datos, como ejemplos. Donde la estación 700 móvil es habilitada para la comunicación de dos vías, incorporará un subsistema 711 de comunicación, que incluye un receptor 712 y un transmisor 714 asi como componentes asociados tales como uno o más, de preferencia integrados o internos, elementos 716 y 718 de antena, osciladores locales (LO) 713, y un módulo de procesamiento tal como un procesador digital de señales (DSP) 720. Como será aparente para aquellos con experiencia en el campo de las comunicaciones, el diseño particular del subsistema 711 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 719. En algunas redes de
CDMA, el acceso de red se asocia con un suscriptor o usuario de la estación 700 móvil. Una estación móvil de CDMA puede requerir que una tarjeta de módulo de identidad de usuario removióle (RUIM) o un módulo de identidad de suscriptor (SIM) opere en una red de CDMA. La interfaz 744 de SIM/RUIM normalmente es similar a una ranura para tarjeta en la cual una tarjeta de SIM/RUIM puede insertarse y expulsarse como un disquete o tarjeta de PCMCIA. La tarjeta de SIM/RUIM puede tener aproximadamente 64K de memoria y contener muchas configuraciones 751 de teclas, y otra información 753 tal como la identificación, y la información relacionada con el suscriptor . Cuando se ha completado los procedimientos de registro o activación de red requeridos, la estación 700 móvil puede enviar y recibir señales de comunicación sobre la red 719. Como se ilustra en la Figura 7, la red 719 puede consistir de múltiples estaciones base que se comunican con el dispositivo móvil. Por ejemplo, en un sistema lx EVDO de CDMA 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 ambos simultáneamente. Las estaciones base EVDO y CDMA lx utilizan diferentes intervalos de bú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 se ingresan en el receptor 712, el
cual puede realizar las funciones comunes del receptor como amplificación de señal, conversión descendente de frecuencia, filtración, selección de canal y similares, y en el sistema ejemplar mostrado en la Figura 7, la conversión de análogo a digital (A/D) . La conversión A/D de una señal recibida permite se realicen funciones de comunicación más complejas tales como desmodulación y descodificación en el DSP 720. En una forma similar, se transmiten las señales que se procesan, incluyendo modulación y codificación por ejemplo, por DSP 720 y se ingresan al transmisor 714 para la conversión de digital a análogo, la conversión ascendente de frecuencia, la filtración, amplificación y transmisión sobre la red 719 de comunicación mediante la antena 718. DSP 720 no sólo procesa señales de comunicación, sino también proporciona control del receptor y transmisor. Por ejemplo, las ganancias aplicadas a las señales de comunicación en el receptor 712 y el transmisor 714 pueden controlarse en forma adaptable a través de algoritmos de control de ganancia automáticos implementados en DSP 720. La estación 700 móvil de preferencia incluye un microprocesador 738 el cual controla la operación general del dispositivo. Funciones de comunicación, que incluyen por lo menos comunicaciones de datos y voz, se realizan a través del subsistema 711 de comunicación. El microprocesador 738 también interactúa con subsistemas adicionales del
dispositivo tales como la pantalla 722, la memoria 724 flash, la memoria de acceso aleatorio (RAM) 726, subsistema 728 auxiliares de entrada/salida (E/S), puertos 730 en serie, uno o más teclados o teclados numéricos 732, altavoz 734, micrófono 736, otros subsistemas 740 de comunicación tal como un subsistema de comunicación de corto alcance y cualquier otro subsistema de dispositivo generalmente designados como 742. El puerto 730 en serie podría 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 7 realizan funciones relacionadas con la comunicación, mientras otros subsistemas pueden proporcionar funciones "residentes" o en el dispositivo. Notablemente, algunos subsistemas, tales como, por ejemplo, el teclado 732 y la pantalla 722, 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 738 de preferencia se almacena en un almacén persistente tal como la memoria 724 flash, la cual puede ser de hecho 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, aplicaciones especificas del dispositivo, o partes del mismo, pueden cargarse temporalmente en una memoria volátil tal como una RAM 726. Las señales de comunicación recibidas también pueden almacenarse en RAM 726. Como se muestra, la memoria 724 flash puede segregarse en diferentes áreas para programas 758 de cómputo y almacenamiento 750, 752, 754 y 756 de datos de programas. Estos diferentes tipos de almacenamiento indican que cada programa puede asignar una porción de la memoria 724 flash a sus propios requerimientos de almacenamiento de datos. El microprocesador 738, 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 controlan las operaciones básicas, que incluyen por lo menos, por ejemplo, aplicaciones de comunicación de datos y voz, normalmente se instalarán en la estación 700 móvil durante la fabricación. Otras aplicaciones podrían instalarse subsecuente o dinámicamente. Una aplicación de software preferida puede ser una aplicación de administrador de información personal (PIM) que tiene la capacidad de organizar y administrar elementos de datos que se relacionan con el usuario de la estación móvil tal como, pero no limitados a, un correo electrónico, eventos de calendario, correos de voz, citas y elementos de tareas.
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 de preferencia puede tener la capacidad de enviar y recibir elementos de datos, mediante la red 719 inalámbrica. En una modalidad preferida, los elementos de datos de PIM se integran continuamente, se sincronizan y actualizan, mediante 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 de cómputo central. Aplicaciones adicionales también pueden cargarse en la estación 700 móvil a través de la red 719, un subsistema 728 auxiliar de E/S, puerto 730 en serie, subsistema 740 de comunicación de corto alcance, o cualquier otro subsistema 742 adecuado, e instalados por un usuario en la RAM 726 o de preferencia un almacén no volátil (no mostrado) para la ejecución por el microprocesador 728. Tal flexibilidad en la instalación de aplicaciones incrementa la funcionalidad del dispositivo y puede proporcionar funciones mejoradas en el dispositivo, funciones relacionadas con la comunicación o ambas. Por ejemplo, aplicaciones de comunicación segura pueden permitir que funciones de comercio electrónico y otras transacciones financieras se realicen 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 página web descargada se procesarán por el subsistema 711 de comunicación y se ingresarán en el microprocesador 738, el cual de preferencia procesa además la señal recibida para sus salidas en la pantalla 722, o alternativamente en un dispositivo 728 auxiliar de E/S. Un cliente 760 de distribución, el cual puede ser equivalente al cliente 140 de distribución también podría procesar la entrada. Un usuario de la estación 700 móvil también puede componer elementos de datos tales como, por ejemplo, mensajes de correo electrónico, utilizando un teclado 732, el cual de preferencia es un teclado alfanumérico completo o un teclado numérico tipo teléfono, junto con la pantalla 722 y posiblemente un dispositivo 728 auxiliar de E/S. Tales elementos compuestos entonces pueden transmitirse sobre una red de comunicación a través del subsistema 711 de comunicación . Para comunicaciones de voz, la operación general de la estación 700 móvil es similar, excepto que las señales recibidas de preferencia pueden producirse en un altavoz 734 y las señales para la transmisión pueden generarse por un micrófono 736. Subsistemas de voz o audio de E/S alternativos, tales como un subsistema de grabación de mensajes de voz, también pueden implementarse en la estación 700 móvil. Aunque la señal de voz o audio producida de
preferencia se logra principalmente a través del altavoz 734, la pantalla 722 también puede utilizarse para proporcionar, por ejemplo, una indicación de la identidad de una parte que llama, la duración de una llamada de voz, u otra información relacionada con la llamada de voz. El puerto 730 en serie en la Figura 7, normalmente puede implementarse en una estación móvil tipo asistente digital personal (PDA) para la cual la sincronización con la computadora de escritorio de un usuario (no mostrada) puede ser deseable, pero es un componente de dispositivo opcional. Tal puerto 730 puede permitir a un usuario establecer preferencias a través de un dispositivo externo o aplicación de software y puede extender las capacidades de la estación 700 móvil al proporcionar la información o descargas de software a la estación 700 móvil en forma diferente a través de una red comunicación inalámbrica. La trayectoria de descarga alternativa por ejemplo, puede utilizarse para cargar una clave de encriptación en el dispositivo a través de una conexión directa y de este modo fiable y confiable para permitir por consiguiente comunicación de dispositivo segura. Como se apreciará por aquellos con experiencia en la técnica, el puerto 730 en serie además puede utilizarse para conectar el dispositivo móvil a una computadora para actuar como un modem. Otros subsistemas 740 de comunicación, tal como un
subsistema de comunicación de corto alcance, es un componente opcional adicional el cual puede proporcionar comunicación entre la estación 700 móvil y diferentes sistemas o dispositivos, que no necesariamente necesitan ser dispositivos similares. Por ejemplo, el subsistema 740 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 similarmente habilitados. Las modalidades descritas en la presente son ejemplos de estructuras, sistemas o métodos que tienen elementos que corresponden con elementos de las técnicas de esta solicitud. Esta descripción escrita puede permitir que aquellos con experiencia en la técnica hagan y utilicen modalidades que tienen elementos alternativos que de igual forma corresponden con elementos de las técnicas de esta solicitud. El alcance pretendido de las técnicas de esta solicitud incluye de este modo otras estructuras, sistemas o métodos que no difieren de las técnicas de esta solicitud como se describe en la presente, y además incluye otras estructuras, sistemas o métodos · con diferencias insustanciales de las técnicas de esta solicitud como se describe en la presente.