ES2368949T3 - Sistema y método para correlacionar mensajes dentro de una transacción inalámbrica. - Google Patents

Abstract

Un método implementado por ordenador para la correlación de mensajes en una transacción inalámbrica de entrega de contenido, el método que comprende: asociar un identificador del mensaje único con un mensaje que inicia la transacción inalámbrica de entrega de contenido, el identificador del mensaje único que se define por un identificador de transacción único y un valor del índice del mensaje; y asociar los mensajes posteriores de la transacción inalámbrica de entrega de contenido con los identificadores de mensaje únicos, los identificadores de mensaje únicos que se definen por el identificador de la transacción único y otros valores de índice del mensaje, en el que los otros valores del índice del mensaje corresponden con números de los mensajes posteriores dentro de dicha transacción inalámbrica de entrega de contenido y caracterizado porque en cada identificador del mensaje único el índice del mensaje es el sufijo del identificador de la transacción en un campo identificador del mensaje.

Description

Sistema y método para correlacionar mensajes dentro de una transacción inalámbrica.

La presente revelación se refiere de manera general a las comunicaciones eficientes de mensajes y transacciones en un entorno de comunicaciones asíncrono y en particular a la correlación de mensajes en una red inalámbrica.

En el entorno de comunicaciones inalámbricas, los mensajes se envían entre un dispositivo inalámbrico y un elemento de red tal como un servidor. Estos mensajes típicamente incluyen un identificador único para identificar el mensaje. Este identificador único se llama de aquí en adelante el “id del mensaje”.

Además, un mensaje incluirá típicamente un campo que identifica el tipo de mensaje para permitir o bien al dispositivo inalámbrico o bien al elemento de red interpretar más fácilmente el mensaje.

Los mensajes en sí mismos se pueden agrupar a menudo en un grupo lógico de mensajes discretos entre el dispositivo y el elemento de red. Por ejemplo, un mensaje saliente puede tener correlación de alguna manera con un mensaje entrante recibido posteriormente. El grupo lógico de mensajes discretos entre el dispositivo y el servidor forman una transacción. A menudo es deseable tener correlación de los mensajes dentro de una transacción.

En comunicaciones inalámbricas la ordenación de mensajes es, no obstante, a menudo asíncrona. De esta manera, por ejemplo, se pueden enviar múltiples mensajes salientes y los mensajes entrantes se pueden recibir en un orden que es distinto del orden en el que los mensajes salientes fueron enviados. Para superar esto, una solución típica es usar un campo identificador de la transacción en cada mensaje. Este campo se añade además al identificador del mensaje y los campos de tipo de mensaje. La añadidura de un campo identificador de la transacción es, no obstante, problemático porque el identificador de la transacción necesita ser lo bastante grande para distinguirlo de otros identificadores de transacción y de esta manera el sobredimensionamiento en términos de recursos de red para añadir un campo identificador de la transacción a cada mensaje es bastante grande.

La EP-A-1694025 revela una cola direccionable para comunicar mensajes correlacionados sobre una red en la cual los mensajes en la misma sesión tienen un identificador de sesión asignado a ellos y también se puede usar un identificador de orden opcional.

GENERAL El presente sistema y método puede relacionarse con las desventajas de direccionamiento de la técnica anterior construyendo un campo identificador del mensaje como una combinación de un identificador de la transacción y un índice del mensaje. Se proporciona por ello un campo identificador del mensaje único a nivel global o local, mientras que se reduce el tamaño del mensaje, ahorrando por ello capacidad de red.

En un aspecto adicional, se puede identificar un tipo de transacción para la transacción a través de varios mecanismos. Un primer mecanismo puede ser la adición al identificador del mensaje de un índice de tipo de transacción.

Se puede usar un segundo mecanismo del índice del mensaje de un primer mensaje en una transacción para especificar un tipo de transacción. Un dispositivo móvil y un elemento de red pueden reconocer un nuevo identificador de la transacción y de esta manera ignorar el índice del mensaje, dado que éste se asume que sea el primer mensaje dentro de la transacción. El campo del índice se puede sustituir con el índice del tipo de transacción y de esta manera se puede usar para identificar el tipo de transacción del mensaje.

Un tercer mecanismo puede ser el uso de heurísticos para identificar un tipo de transacción. Específicamente, se podría usar el tamaño del mensaje, el portador de radio usado, u otro rasgo del mensaje para identificar preliminarmente el tipo de transacción. Si se descubre posteriormente que la asignación del tipo de transacción es incorrecta debido al tipo de transacción entonces se podría reasignar.

Un cuarto mecanismo podría ser que ningún tipo de transacción esté presente, sino que un mensaje incluye la información del tipo de mensaje. Como se apreciará, el tipo de mensaje de un primer mensaje en una transacción a menudo identificará únicamente la transacción.

La identificación del tipo de transacción también puede proporcionar el seguimiento de los tipos de mensajes dentro de la transacción. Específicamente, una transacción tiene un número limitado de tipos de mensaje que se esperan en un orden específico, y de esta manera mediante el seguimiento de una transacción se puede derivar el siguiente tipo de mensaje. Esto puede provocar la eliminación de la necesidad de tener un campo de tipo de mensaje separado si el tipo de transacción se puede identificar a partir del identificador del mensaje.

La presente revelación puede proporcionar por lo tanto un método implementado por ordenador para la correlación de mensajes que define una transacción de entrega de contenido, el método que comprende: asociar un identificador del mensaje único con un mensaje que inicia la transacción de entrega de contenido, el identificador del mensaje único que se define por un identificador de transacción único y un valor del índice del mensaje; y

asociar los mensajes de respuesta posteriores de la transacción de entrega de contenido con los identificadores de mensajes únicos, los identificadores de mensajes únicos que se definen por el identificador de transacción único y otros valores del índice del mensaje,

en el que los otros valores del índice del mensaje corresponden a números de los mensajes posteriores dentro de dicha transacción de entrega de contenidos y en cada identificador del mensaje único el índice del mensaje es el sufijo del identificador de transacción en un campo de identificador del mensaje.

La presente revelación puede además aún proporcionar un medio legible por ordenador que almacena las instrucciones de programa ejecutables por un procesador de un dispositivo de cálculo para hacer a dicho dispositivo de cálculo que realice todos los pasos del método proporcionado por la presente revelación.

La presente revelación puede además aún proporcionar un elemento de red para la correlación de los mensajes de respuesta que definen una transacción de entrega de contenido, el elemento de red que comprende: un procesador adaptado a hacer que elemento de red realice todos los pasos de cualquiera de los métodos proporcionados por la presente revelación; y un sistema para la correlación de los mensajes de respuesta que definen una transacción de entrega de contenidos, el sistema que comprende: un cliente de entrega de contenido; y un servidor de entrega de contenido, en el que el cliente de entrega de contenido y el servidor de entrega de contenido comunica el uno con el otro para realizar todos los pasos del método proporcionado por la presente revelación.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La presente solicitud se entenderá mejor con referencia a los dibujos en los cuales:

La Figura 1 es un diagrama de flujo que ilustra la naturaleza asíncrona de las comunicaciones inalámbricas; La Figura 2 es un diagrama de flujo de una transacción de entrega de contenido típica para una entrega de contenidos basada en entrega por demanda con notificación de disponibilidad de contenidos entregados por oferta; La Figura 3 es un diagrama de flujo que ilustra una transacción de entrega de tipo entrega por demanda; La Figura 4 es un diagrama de flujo que ilustra una transacción de entrega de contenidos de entrega por oferta; La Figura 5 es un diagrama de flujo que ilustra un método ejemplar para la utilización del identificador de transacción combinada y el índice del mensaje; La Figura 6 es un diagrama de bloques de un sistema simplificado usado para el método de la presente revelación; y La Figura 7 es un diagrama de bloques de un dispositivo móvil ejemplar que se podría usar con el presente método y sistema.

DESCRIPCIÓN DE LAS REALIZACIONES PREFERENTES Se hará ahora referencia a la Figura 1. La Figura 1 ilustra un diagrama de flujo ejemplar para las comunicaciones entre un dispositivo 10 y un servidor 20. El ejemplo de la Figura 1 se entiende que es ilustrativo de las comunicaciones entre un dispositivo 10 y un servidor 20 y no limita la presente revelación.

Un dispositivo 10 puede enviar varios mensajes al servidor 20. En el ejemplo de la Figura 1, los mensajes 30, 32, 34 y 36 se envían al servidor 20. Cada uno de los mensajes 30, 32, 34 y 36 pertenecen a un asunto diferente y de esta manera se ilustran en la Figura 1 con distinto tipo de línea. Ejemplos de los mensajes 30, 32, 34 o 36 podrían ser las peticiones de contenido, confirmaciones de recepción de contenido, peticiones de contenido adicional, una respuesta de contenido, entre otras.

El dispositivo 10 puede enviar numerosos mensajes tales como los mensajes 30, 32, 34 y 36 al servidor 20. No obstante, debido a la naturaleza asíncrona de las comunicaciones inalámbricas, la respuesta desde el servidor 20 al dispositivo 10 basada en los mensajes 30, 32, 34 y 36 puede no corresponder en orden al orden en el cual el servidor 20 recibió los mensajes 30, 32, 34 y 36.

En el ejemplo de la Figura 1, se recibe una respuesta 40 que se refiere al mensaje 32 en el dispositivo 10 primero. Posteriormente, se recibe una respuesta 42 por el dispositivo 10 con referencia al mensaje 36.

En el ejemplo de la Figura 1, se recibe a continuación una respuesta 44 que corresponde a un mensaje 34. Finalmente, se recibe una respuesta 46 la cual corresponde al mensaje 30.

Un problema con lo anterior es cómo un dispositivo correlaciona el mensaje 30 con la respuesta 46, el mensaje 32 con la respuesta 40, el mensaje 34 con la respuesta 44, y el mensaje 36 con la respuesta 42. Según se usan aquí dentro, los mensajes 30 y la respuesta 46 son parte de la misma transacción. De manera similar, el mensaje 32 y la respuesta 40 son parte de la misma transacción; el mensaje 34 y la respuesta 44 son parte de la misma transacción; y el mensaje 36 y la respuesta 42 son parte de la misma transacción, donde cada una de las cuatro transacciones es única la una de la otra.

La solución a lo anterior es construir un campo identificador del mensaje como una combinación del identificador de la transacción y un número de mensaje o índice dentro de la transacción. Esto se puede ilustrar:

[Identificador de la Transacción] [Índice del mensaje]

Como se apreciará por aquellos expertos en la técnica, la combinación de un identificador de transacción y el índice del mensaje proporciona ahorros de recursos de red. Específicamente, el identificador de la transacción necesita serúnico. Único aquí podría ser definido como un valor único globalmente o un valor único dentro de un contexto tal como un dominio de portadora, dispositivo, servidor, servicio, canal, entre otros. También, como se apreciará por aquellos expertos en la técnica, único puede no necesariamente significar completamente único, sino estadísticamente que tiene una baja probabilidad de tener el mismo valor que otro identificador de transacción.

Dado que el identificador del mensaje también necesita ser único, la combinación del identificador de la transacción único con un índice para un mensaje dentro de la transacción proporciona un identificador del mensaje único. La eliminación de un valor único ahorra recursos, dado que un valor único requiere un número significativo de bytes en cada mensaje a ser implementado.

De esta manera, por ejemplo, si el identificador de la transacción es “1234”, se podría añadir un índice del mensaje después del identificador de la transacción. El índice del mensaje podría ser, por ejemplo, 01 y de esta manera el identificador del mensaje es “123401”. Como se apreciará por aquellos expertos en la técnica, esto forma un identificador mucho más corto para identificar tanto la transacción como el mensaje.

El ejemplo de “1234” anterior es meramente una simplificación y en la práctica, el número de bytes requerido para hacer globalmente un dominio de portadora, dispositivo, servidor, servicio, o canal, entre otros, los identificador únicos tendrán que ser usados. Tal identificador se puede generar, por ejemplo, con un generador de números aleatorios en base a un sello de tiempo en el dispositivo o el servidor.

El índice del mensaje de arriba puede ser muy pequeño. Por ejemplo, las transacciones inalámbricas son típicamente cortas y normalmente requieren menos de 16 mensajes. De esta manera, el índice del mensaje podría añadir de dos a cuatros bit al identificador de transacción. Esto se entiende, no obstante, que es ilustrativo de un ejemplo de un índice del mensaje y no se entiende que sea limitante. Otros tamaños de índice del mensaje se podrían usar y serían evidentes a aquellos expertos en la técnica.

Lo anterior proporciona la ventaja de que el identificador de la transacción, que típicamente puede estar entre 32 y digamos 256 bytes, no necesita ser añadido a un identificador del mensaje separado, el cual también podría ser de 32 a 256 bytes. Por ello, se ahorra el sobredimensionamiento de cabecera.

En un aspecto adicional, el campo del identificador del mensaje único que tiene un identificador de transacción y el índice del mensaje se puede usar para sustituir el identificador de la transacción, el identificador del mensaje y preferentemente el campo de tipo de mensaje.

En particular, en un marco de entrega de contenido los tipos de transacción están predefinidos, de manera que los tipos de mensajes que participan en la transacción también están predefinidos. Además, el orden de estos mensajes dentro de la transacción está predefinido también.

Esto se ilustrará en más detalle con referencia a las Figuras 2, 3, y 4.

Con referencia a la Figura 2, se ilustra un diagrama de flujo para una notificación de entrega por oferta típica con el sistema de contenido entregado por oferta.

En la Figura 2, un dispositivo 10 y un servidor 20 comunican el uno con el otro. La transacción en el ejemplo de la Figura 2 ilustra un primer mensaje 210, que es una notificación al dispositivo 10 de que el contenido está disponible. En respuesta, el dispositivo 10 envía un mensaje 212 al servidor 20 que contiene una petición de contenido para obtener el contenido que está disponible.

El servidor entonces, en el mensaje 214, envía una respuesta del contenido.

El dispositivo 10 entonces envía opcionalmente una confirmación 216.

Como se apreciará, los mensajes 210, 212, 214 y 216 forman una transacción para una notificación de entrega por oferta con el sistema de contenido de entrega por demanda. El tipo de transacción define el tipo de mensajes y el orden de estos mensajes.

También, en el caso de un error para cualquiera de los mensajes 210, 212 o 214, se podría enviar un mensaje de error en los pasos 212, 214 o 216 en lugar de los mensajes definidos anteriormente.

Con referencia a la Figura 3, se proporciona un sistema de entrega por demanda. En el ejemplo de la Figura 3, un dispositivo 10 comunica con el servidor 20. Un primer mensaje 310 se envía desde el dispositivo 10 al servidor 20 y forma una petición de contenido.

En respuesta al mensaje 310, el servidor 20 envía un mensaje 312 que proporciona una respuesta de contenido. El dispositivo 10 puede entonces enviar opcionalmente un mensaje de confirmación 314.

Como con el ejemplo anterior de la Figura 2, los mensajes 310, 312 y 314 de la Figura 3 forman una transacción única. Además, en base al tipo de transacción, los mensajes en la transacción están predeterminados y el orden de los mensajes está predeterminado.

Como se apreciará además por aquellos expertos en la técnica, en el caso de un error en los mensajes 310 o 312, se puede enviar un mensaje de error en lugar de los mensajes 312 o 314.

Con referencia a la Figura 4, esta figura ilustra un diagrama de flujo ejemplar para un sistema de entrega por oferta. En el ejemplo de la Figura 4, el contenido en sí mismo se envía a un dispositivo 10, más que meramente una notificación de contenido, como en el ejemplo de la Figura 2.

En la Figura 4, un dispositivo 10 comunica con un servidor 20. El servidor 20 puede enviar, en el mensaje 410, el contenido o parte del contenido al dispositivo 10.

En respuesta, el dispositivo 10 puede enviar opcionalmente una confirmación en el mensaje 412. Alternativamente, el dispositivo 10 podría enviar una petición de contenido adicional o un mensaje de error en el mensaje 412.

El servidor 20 podría enviar entonces, cuando el contenido llega a estar disponible o si se recibe una petición de contenido adicional, más contenido en el mensaje 414. Esto se podría usar por ejemplo para la fragmentación de contenido donde un dispositivo tiene limitaciones de espacio o el portador de entrega por oferta tiene limitaciones de tamaño. En el mensaje 416, el dispositivo puede confirmar opcionalmente la recepción del contenido, solicitar contenido adicional o enviar un mensaje de error.

Como en los ejemplos anteriores de la Figura 2 y la Figura 3, los mensajes 410 y 412 en la Figura 4 forman una transacción única. Además, si el mensaje 412 es una petición de contenido adicional, entonces el mensaje 414 y 416 también podrían formar parte de esta misma transacción. En una realización, un índice del mensaje podría restablecerse después de alcanzar un máximo. De esta manera por ejemplo, si 16 mensajes son parte de la transacción, el índice del mensaje podría volver a cero después del mensaje decimoquinto.

En base al tipo de transacción, los tipos de mensaje para los mensajes 410 y 412 se conocen y además, el orden de los mensajes 410 y 412 es conocido.

El uso propuesto de un identificador de transacción y un número o índice del mensaje dentro de la transacción permite la identificación de los tipos de mensajes que participan en la transacción, dado que en una transacción el tipo de mensaje y la ordenación están predefinidas.

En particular, existen varias opciones para identificar únicamente un tipo de transacción.

En una primera opción el tipo de transacción se puede integrar en el identificador de la transacción de un identificador del mensaje. Esto provoca solamente el requerimiento de que exista un segundo subconjunto para identificar un índice del mensaje dentro de la transacción. Específicamente, si un dispositivo puede recibir dieciséis tipos de transacciones, entonces se podría añadir al tipo de transacción cuatro bits en algún lugar dentro del identificador de la transacción. De esta manera, por ejemplo el identificador de la transacción se podría extender añadiendo un índice del tipo de transacción en el comienzo del identificador de la transacción. Esto se ilustra como:

[identificador de la transacción][índice del mensaje]

donde el identificador de la transacción del subconjunto del identificador del mensaje contiene el tipo de transacción.

No obstante, esto no se entiende que sea limitativo y el tipo de transacción se puede añadir en cualquier sitio dentro del campo identificador de la transacción. Varias formas adicionales de la combinación de los dos se conocerían por aquellos expertos en la técnica.

Una segunda opción es si el tipo de transacción no está integrada en el identificador de transacción del subconjunto del campo identificador del mensaje. En su lugar, cuando un dispositivo o un servidor recibe un número de transacción que un dispositivo o un servidor no ha visto antes, esto se interpretará típicamente como el primer mensaje dentro de la transacción. De esta manera, en lugar de añadir un tipo de transacción separadamente de un índice del mensaje, el índice del mensaje para el primer mensaje dentro de una transacción debería identificar el tipo de transacción. Se entenderá por el dispositivo o el servidor que el índice del mensaje identifica un tipo de transacción y que el mensaje es el primer mensaje en la transacción.

Esta segunda opción se ilustra para un primer mensaje en una transacción en la que el identificador del mensaje es:

[identificador de la transacción][índice del tipo de transacción]

y para los mensajes posteriores en la transacción el identificador del mensaje es:

[identificador de la transacción][índice del mensaje]

De esta manera los mensajes consecutivos dentro de la transacción transportan un índice del mensaje dentro de la parte del mensaje del identificador.

Una tercera opción es que el tipo de transacción no esté integrada en el identificador de la transacción del subconjunto del identificador de mensaje. En la mayoría de los casos, el tipo del primer mensaje dentro de la transacción únicamente identifica el tipo de transacción. La decisión sobre el tipo de transacción y las secuencias anticipadas de mensajes dentro de la transacción podrían ser hechas dinámicamente en el procesamiento del primer mensaje. Alternativamente, el tipo de transacción se podría identificar en base al portador o interfaz de radio que fue usado para entregar el mensaje, el tamaño del mensaje, entre otros. Por ejemplo, el tamaño del mensaje se podría usar para distinguir entre el contenido entregado por oferta y una notificación de entrega por oferta de los mensajes de disponibilidad de contenido, separando de esta manera las transacciones mostradas en la Figura 2 y la Figura 4. Este ejemplo aún requiere solamente un índice del mensaje para un subconjunto del mensaje del campo identificador. Esto se ilustra como:

[identificador de la transacción][índice del mensaje]

El uso de los heurísticos anteriores permite la identificación del nivel de la estructura de procesamiento en la que se procesará el mensaje. En este caso, incluso si los heurísticos está equivocados y se descubre que el mensaje ha sido procesado en el nivel equivocado, el mensaje entonces podría ser vuelto a procesar en el nivel correcto provocando un retardo menor para ese mensaje. En conjunto, no obstante, se logrará un ahorro de tiempo usando estos tipos de heurísticos.

Una cuarta opción es que el identificador de la transacción no contenga información sobre el tipo de transacción. En este caso, la información del tipo de mensaje se incluye en el subconjunto del mensaje. Esto se ilustra como:

[Identificador de la transacción][subconjunto del mensaje]

El subconjunto del mensaje se ilustra por ejemplo como:

[índice del mensaje][tipo de mensaje]

El anterior uso de los tipos de transacción se muestra además con referencia a la Figura 5. La Figura 5 ilustra un diagrama de flujo de un método ejemplar para la utilización de la transacción combinada y los identificadores del mensaje. En el ejemplo de la Figura 5, el método empieza en el paso 510 cuando se recibe un mensaje. El método entonces pasa al paso 512 en el cual el identificador de la transacción se extrae a partir del mensaje recibido.

El método entonces pasa al paso 514 en el cual un dispositivo o servidor comprueba para ver si el identificador de la transacción que fue extraído en el paso 512 es un nuevo identificador de transacción. Como se apreciará por aquellos expertos en la técnica, el dispositivo o servidor (por ejemplo el dispositivo 10 o servidor 20 de las Figuras 1, 2, 3 o 4) almacenará los identificadores de transacción y si se recibe un identificador de transacción que no coincide con ninguno de los identificadores de transacción almacenados, entonces este será considerado que es un nuevo identificador de transacción durante el paso 514.

A partir del paso 514, si se identifica un nuevo identificador de transacción, entonces el proceso pasa al paso 516 en el cual se crea y almacena un registro de transacción en el dispositivo o servidor.

A partir del paso 516, el proceso pasa entonces al paso 518 en el cual se hace una comprobación para ver si está disponible o no un tipo de transacción. El paso 518 podría usar varias opciones tales como aquellas enseñadas anteriormente para identificar el tipo de transacción. Esto puede incluir, por ejemplo, la extracción del campo de tipo de transacción a partir de una transacción si se añade un campo de tipo de transacción discreta al campo del identificador. Alternativamente, dado que este puede ser el primer mensaje, el índice del mensaje podría ser sustituido por un índice del tipo de transacción para identificar el tipo de transacción. En una alternativa adicional, se podría usar un modelo heurístico para identificar el tipo de transacción. En una alternativa adicional, se puede usar un tipo de mensaje para identificar el tipo de transacción.

A partir del paso 518, si está disponible el tipo de transacción, el proceso pasa entonces al paso 520 en el cual se actualiza un registro de transacción para incluir el tipo de transacción.

El proceso pasa al paso 530 desde el paso 514 si el identificador de transacción no es nuevo, desde el paso 518 si el tipo de transacción no está disponible, o desde el paso 520. En el paso 530, se procesa el mensaje que fue recibido en el paso 510.

El proceso pasa entonces al paso 532 en el que se actualiza el estado de transacción. Por ejemplo, si se utiliza el tipo de transacción de la Figura 2, una vez ha sido recibido el mensaje de disponibilidad de contenido, el estado de transacción podría indicar que el siguiente mensaje esperado en el dispositivo es una petición a ser enviada para recuperar el contenido. Como se apreciaría, cada transacción tiene un protocolo específico con mensajes y la ordenación de mensajes que se usan.

El proceso pasa desde el paso 532 al paso 534 en el cual el dispositivo o el servidor continúa con el flujo de transacción según los datos del protocolo.

Como se apreciará por aquellos expertos en la técnica, el ejemplo de la Figura 5 es meramente ilustrativo de un método que usamos para extraer información que incluye un identificador de transacción llamado un identificador del mensaje y tipo de mensaje del tipo de transacción a partir de un mensaje recibido. Otros ejemplos serán evidentes a aquellos expertos en la técnica.

Con referencia a la Figura 6, la Figura 6 ilustra un diagrama de bloques de un sistema típico. En el sistema, un dispositivo 610 comunica con un servidor 620. El dispositivo 610 incluye un procesador de mensajes 612 adaptado para procesar los mensajes recibidos.

El procesador de mensajes 612 comunica con un almacenamiento de datos de protocolo 614. El almacenamiento de datos de protocolo 614 almacena los diversos protocolos que el dispositivo 610 espera. Estos protocolos incluyen las progresiones de la transacción como, por ejemplo, se ilustran por las Figuras 2, 3 y 4.

El procesador de mensajes 612 comunica además con un almacenamiento de estados de transacción 616 que almacena el estado actual de las diversas transacciones con las que está implicado el dispositivo 610. De esta manera, por ejemplo, si el dispositivo está progresando a través de una transacción tal como aquella ilustrada en la Figura 2 y ha recibido un primer mensaje desde el servidor que proporciona una notificación de disponibilidad de contenido junto con un identificador de transacción, y ha enviado entonces una petición de contenido que usa el mismo identificador de transacción, el almacenamiento de estado de transacción 616 puede indicar que en el siguiente mensaje asociado con ese identificador de transacción debería estar una respuesta de contenido desde el servidor 620.

De manera similar, el servidor 620 incluye un procesador de mensajes 622 adaptado a procesar los mensajes que se reciben. Además, un almacenamiento de datos de protocolo 624 incluye varios protocolos que el servidor puede adoptar para comunicar con un dispositivo 610, o que el servidor 620 puede usar cuando comunica con el dispositivo

610.

El servidor 620 además incluye un almacenamiento de estado de transacción 626 para identificar el estado actual de las diversas transacciones con las que está implicado el servidor 620. En este sentido, los mensajes 630 se pasan entre el dispositivo 610 y el servidor 620.

Como se apreciará por aquellos expertos en la técnica, el dispositivo 10 de las Figuras 1, 2, 3 y 4, y el dispositivo 610 de la Figura 6 puede ser cualquier dispositivo móvil. Un dispositivo móvil ejemplar se ilustra en la Figura 7.

La Figura 7 es un diagrama de bloques que ilustra una estación móvil apta para ser usada con las realizaciones preferentes del aparto y el método de la presente revelación. La estación móvil 700 es preferentemente un dispositivo de comunicación inalámbrico de dos vías que tiene al menos capacidades de comunicación de voz y datos. Dependiendo de la funcionalidad exacta proporcionada, el dispositivo inalámbrico se puede conocer como un dispositivo de mensajería de datos, un buscapersonas de dos vías, un dispositivo de correo electrónico inalámbrico, un teléfono celular con capacidades de mensajería de datos, un aparato de Internet inalámbrico, o un dispositivo de comunicación de datos, como ejemplos.

Donde la estación móvil 700 esté habilitada para la comunicación de dos vías, se incorporará un subsistema de comunicación 711, que incluye tanto un receptor 712 como un transmisor 714, así como los componentes asociados tales como uno o más, preferentemente integrados o internos, elementos de antena 716 y 718, osciladores locales (LO) 713, y un módulo de procesamiento tal como un procesador digital de señal (DSP) 720. Como será evidente para aquellos expertos en el campo de las comunicaciones, el diseño particular del subsistema de comunicación 711 será dependiente de la red de comunicación en la cual el dispositivo está intentando funcionar.

Los requerimientos de acceso de red también varían dependiendo del tipo de red 719. En algunas redes CDMA el acceso de red se asocia con un abonado o usuario de la estación móvil 700. Una estación móvil de CDMA puede requerir una tarjeta de módulo de identidad de usuario extraíble (RUIM) o una de módulo de identidad de abonado (SIM) para operar en una red de CDMA. El interfaz SIM/RUIM 744 es normalmente similar a una ranura de tarjeta en la cual se puede insertar y expulsar una tarjeta SIM/RUIM como un disquete o tarjeta PCMCIA. La tarjeta SIM/RUIM puede tener aproximadamente 64K de memoria y mantener mucha configuración clave 751, y otra información 753 tal como identificación, e información relacionada con el usuario.

Cuando el registro de red requerido o los procedimientos de activación han sido completados, la estación móvil 700 puede enviar y recibir las señales de comunicación sobre la red 719. Como se ilustra en la Figura 7, la red 719 puede constar de múltiples estaciones base que comunican con el dispositivo móvil. Por ejemplo, en un sistema híbrido CDMA 1x EVDO, una estación base CDMA y una estación base EVDO comunica con la estación móvil y la estación móvil se conecta a ambas simultáneamente. Las estaciones base EVDO y CDMA 1X usan distintas ranuras de búsqueda para comunicar con el dispositivo móvil.

Las señales recibidas por la antena 716 a través de la red de comunicación 719 se introducen al receptor 712, el cual puede realizar tales funciones de receptor común como la amplificación de la señal, la conversión hacia abajo en frecuencia, el filtrado, la selección del canal y similares, y en el sistema ejemplo mostrado en la Figura 7, conversión analógica a digital (A/D). La conversión A/D de una señal recibida permite funciones de comunicación más complejas tales como la demodulación y la descodificación a ser realizada en el DSP 720. De una manera similar, las señales a ser transmitidas se procesan, incluyendo la modulación y la codificación por ejemplo, por el DSP 720 y se introducen al transmisor 714 para la conversión digital a analógica, la conversión hacia arriba en frecuencia, el filtrado, la amplificación y la transmisión sobre la red de comunicación 719 a través de la antena 718. El DSP 720 no solamente procesa las señales de comunicación, sino que también proporciona el control del receptor y del transmisor. Por ejemplo, las ganancias aplicadas a las señales de comunicación en el receptor 712 y el transmisor 714 se pueden controlar adaptativamente a través de algoritmos de control automático de ganancia implementados en el DSP 720.

La estación móvil 700 incluye preferentemente un microprocesador 738 que controla el funcionamiento del dispositivo en conjunto. Las funciones de comunicación, incluyendo al menos las comunicaciones de voz y datos, se realizan a través del subsistema de comunicación 711. El microprocesador 738 también actúa con otros subsistemas de dispositivo tales como la pantalla 722, la memorial rápida 724, la memoria de acceso aleatorio (RAM) 726, los subsistemas de entrada/salida (I/O) auxiliares 728, el puerto serie 730, uno o más teclados o paneles 732, el altavoz 734, el micrófono 736, otro subsistema de comunicación 740 tal como un subsistema de comunicaciones de corto alcance y cualesquiera otros subsistemas de dispositivo generalmente designados como 742. El puerto serie 730 podría incluir un puerto USB u otro puerto conocido por aquellos expertos en la técnica.

Algunos de los subsistemas mostrados en la Figura 7 realizan funciones relacionadas con la comunicación, mientras que otros subsistemas pueden proporcionar funciones “residentes” o en el dispositivo. Señaladamente, algunos subsistemas, tales como el teclado 732 y la pantalla 722, por ejemplo, se pueden usar tanto para funciones relacionadas con la comunicación, tales como la introducción de un mensaje de texto para la transmisión sobre una red de comunicación, como las funciones residentes en el dispositivo tales como una calculadora o la lista de tareas.

Los componentes lógicos del sistema operativo usados por el microprocesador 738 se almacenan preferentemente en un almacén persistente tal como la memoria rápida 724, que en su lugar puede ser una memoria solamente de lectura (ROM) o elemento de almacenamiento similar (no se muestra). Aquellos expertos en la técnica apreciarán que el sistema operativo, las aplicaciones de dispositivo específicas, o partes de las mismas, se pueden cargar temporalmente en una memoria volátil tal como la RAM 726. Las señales de comunicación recibidas también se pueden almacenar en la RAM 726.

Como se muestra, la memoria rápida 724 se puede segregar en distintas zonas tanto para los programas de ordenador 758 como el almacenamiento de datos de programa 750, 752, 754 y 756. Estos distintos tipos de almacenamiento indican que cada programa puede asignar una parte de la memoria rápida 724 para sus propios requerimientos de almacenamiento de datos. El microprocesador 738, además de sus funciones de sistema operativo, preferentemente permite la ejecución de las aplicaciones de componentes lógicos en la estación móvil. Un conjunto predeterminado de aplicaciones que controlan las operaciones básicas, incluyendo al menos las aplicaciones de comunicación de voz y datos por ejemplo, se instalarán normalmente en la estación móvil 700 durante la fabricación. Otras aplicaciones se podrían instalar posteriormente o dinámicamente.

Una aplicación de componentes lógicos preferente puede ser una aplicación de gestor de información personal (PIM) que tiene la capacidad de organizar y gestionar los elementos de datos relativos al usuario de la estación móvil tales como, pero no limitados a, el correo electrónico, los eventos del calendario, los correos de voz, las citas, y los asuntos de tareas. Naturalmente, uno o más almacenes de memoria estarían disponibles en la estación móvil para facilitar el almacenamiento de los elementos de datos del PIM. Tal aplicación de PIM tendría preferentemente la capacidad de enviar y recibir elementos de datos, a través de la red inalámbrica 719. En una realización preferente, los elementos de datos del PIM se integran, sincronizan y actualizan, sin problemas a través de la red inalámbrica 719, con los elementos de datos correspondientes del usuario de la estación móvil almacenados o asociados con un sistema de ordenador central. También se pueden cargar aplicaciones adicionales en la estación móvil 700 a través de la red 719, un subsistema I/O auxiliar 728, el puerto serie 730, el subsistema de comunicaciones de corto alcance 740 o cualquier otro subsistema adecuado 742, e instalar por un usuario en la RAM 726 o preferentemente un almacén no volátil (no se muestra) para la ejecución por el microprocesador 738. Tal flexibilidad en la instalación de la aplicación aumenta la funcionalidad del dispositivo y puede proporcionar funciones en el dispositivo mejoradas, funciones relacionadas con la comunicación, o ambas. Por ejemplo, las aplicaciones de comunicación seguras pueden permitir funciones de comercio electrónico y otras tales como transacciones financieras a ser realizadas usando la estación móvil 700.

En un modo de comunicación de datos, una señal recibida tal como un mensaje de texto o descarga de página web se procesará por el subsistema de comunicación 711 e introducirá al microprocesador 738, el cual preferentemente procesa además la señal recibida para sacar a la pantalla 722, o alternativamente a un dispositivo de I/O auxiliar

728. Un cliente de entrega 760, que podrían ser equivalente al cliente de entrega 140 podría procesar también la entrada.

Un usuario de la estación móvil 700 también puede componer los elementos de datos tales como mensajes de correo electrónico por ejemplo, usando el teclado 732, que es preferentemente un teclado alfanumérico completo o el panel tipo teléfono, en conjunto con la pantalla 722 y posiblemente un dispositivo I/O auxiliar 728. Tales elementos compuestos se pueden transmitir entonces sobre una red de comunicación a través del subsistema de comunicación

711.

Para las comunicaciones de voz, la operación total de la estación móvil 700 es similar, excepto que las señales recibidas preferentemente fueran sacadas a un altavoz 734 y las señales para la transmisión fuesen generadas por un micrófono 736. Los subsistemas de I/O de voz o audio alternativos, tales como un subsistema de grabación de mensajes de voz, también se pueden implementar en la estación móvil 700. Aunque la salida de la señal de voz o audio se consuma preferentemente en primer lugar a través del altavoz 734, la pantalla 722 también se puede usar para proporcionar una indicación de la identidad de un parte que llama, la duración de una llamada de voz, u otra información relacionada con la llamada de voz por ejemplo.

El puerto serie 730 en la Figura 7 se implementaría normalmente en una estación móvil tipo asistente digital personal (PDA) para la cual la sincronización con un ordenador de sobremesa del usuario (no se muestra) puede ser deseable, pero es un componente de dispositivo opcional. Tal puerto 730 permitiría a un usuario fijar las preferencias a través de un dispositivo externo o aplicación de componentes lógicos y extendería las capacidades de la estación móvil 700 proporcionando información o descargas de componentes lógicos a la estación móvil 700 distintas de a través de una red de comunicación inalámbrica. El camino de descarga alternativo se puede usar por ejemplo para cargar una clave de cifrado en el dispositivo a través de una conexión directa y de esta manera fiable y de confianza para permitir por ello la comunicación del dispositivo segura. Como se apreciará por aquellos expertos en la técnica, el puerto serie 730 se puede usar además para conectar el dispositivo móvil a un ordenador para actuar como un módem.

Otros subsistemas de comunicación 740, tales como un subsistema de comunicaciones de corto alcance, es un componente opcional adicional que puede proporcionar comunicación entre la estación móvil 700 y distintos sistemas o dispositivos, los cuales no necesitan ser necesariamente dispositivos similares. Por ejemplo, el subsistema 740 puede incluir un dispositivo de infrarrojos y los circuitos y componente asociados o un módulo de comunicación Bluetooth® para proporcionar comunicación con sistemas y dispositivos habilitados de manera similar.

Las realizaciones descritas aquí dentro son ejemplos de estructuras, sistemas o métodos que tienen elementos que corresponden a elementos de las técnicas de esta solicitud. Esta descripción escrita puede permitir a aquellos expertos en la técnica hacer y usar las realizaciones que tienen elementos alternativos que igualmente corresponden a los elementos de las técnicas de esta solicitud. El alcance pretendido de las técnicas de esta solicitud incluye de esta manera otras estructuras, sistemas o métodos que no difieren de las técnicas de esta solicitud según se describe aquí dentro, y además incluye otras estructuras, sistemas o métodos con diferencias insustanciales de las técnicas de esta solicitud según se describe en las reivindicaciones.

Claims (8)

1. REIVINDICACIONES

   1.

   Un método implementado por ordenador para la correlación de mensajes en una transacción inalámbrica de entrega de contenido, el método que comprende:

   asociar un identificador del mensaje único con un mensaje que inicia la transacción inalámbrica de entrega de contenido, el identificador del mensaje único que se define por un identificador de transacción único y un valor del índice del mensaje; y asociar los mensajes posteriores de la transacción inalámbrica de entrega de contenido con los identificadores de mensaje únicos, los identificadores de mensaje únicos que se definen por el identificador de la transacción único y otros valores de índice del mensaje, en el que los otros valores del índice del mensaje corresponden con números de los mensajes posteriores dentro de dicha transacción inalámbrica de entrega de contenido y caracterizado porque en cada identificador del mensaje único el índice del mensaje es el sufijo del identificador de la transacción en un campo identificador del mensaje.

2. 2.

   El método de la reivindicación 1, en el que la asociación además comprende la definición de los identificadores del mensaje únicos que usan un tipo de transacción.

3. 3.

   El método de la reivindicación 1 en el que el valor del índice del mensaje para el mensaje que inicia la transacción de entrega de contenido identifica un tipo de transacción.

4. 4.

   El método de cualquiera de las reivindicaciones 1 a 3, en el que uno o más de dicho identificador de transacción único, dicho identificador del mensaje, y dichos identificadores de mensaje únicos es único globalmente o dentro de un contexto que comprende cualquiera de un dominio de portadora, un servidor, un servicio, y/o un canal.

5. 5.

   Un elemento de red dentro de una red inalámbrica para la correlación de los mensajes de respuesta que definen una transacción inalámbrica de entrega de contenido, el elemento de red que comprende:

   un procesador (612) adaptado a hacer que el elemento de red realice todos los pasos del método de cualquiera de las reivindicaciones 1 a 4.

6. 6.

   El elemento de red de la reivindicación 5, en el que el elemento de red es un cliente de entrega o un servidor de entrega.

7. 7.

   Un medio legible por ordenador que almacena las instrucciones del programa ejecutable por un procesador de un dispositivo de cálculo para hacer que dicho dispositivo de cálculo realice todos los pasos del método de cualquiera de las reivindicaciones 1 a 4.

8. 8.

   Un sistema para la correlación de los mensajes de respuesta que definen una transacción inalámbrica de entrega de contenido, el sistema que comprende:

   un cliente de entrega de contenido (760); y un servidor de entrega de contenido (20),

   en el que el cliente de entrega de contenido y el servidor de entrega de contenido comprenden medios para la correlación de mensajes adaptados para realizar todos los pasos del método de cualquiera de las reivindicaciones 1 a 4.