Procedimiento de comunicación entre un dispositivo que ejecuta Java ME y un servidor por vía aérea con mensajes SOAP bajo APDU desde/hacia un operador en un anfitrión, y sistema correspondiente.

Procedimiento de comunicación por medio de HTTP o HTTPS entre un dispositivo portátil que ejecuta Java MEcon una tarjeta inteligente y un servidor por vía aérea,

recibiendo y transmitiendo dicho servidor datos APDUencapsulados en mensajes SOAP desde/hacia un operador en un anfitrión a través de una red y transmitiendo yrecibiendo datos APDU contenidos en mensajes binarios desde/hacia el dispositivo portátil, traduciéndose cadamensaje SOAP a partir de/en mensajes binarios de acuerdo con un protocolo en el servidor, intercambiándosedichos mensajes binarios con el dispositivo portátil,

y en caso de que los datos APDU no puedan estar contenidos en un mensaje binario, el intercambio se efectúa enuna transmisión por lotes de una pluralidad de mensajes binarios,

caracterizado porque para ejecutar una comunicación según el protocolo con el dispositivo portátil que ejecutaJava ME y su tarjeta inteligente, y usando lotes de órdenes APDU completas, se implementan las etapassiguientes:

- el dispositivo portátil en primer lugar envía al servidor un mensaje binario que incluye una solicitud deintercambio APDU e información de inicialización de servicio para identificar un operador,

- como respuesta, el servidor envía de vuelta al dispositivo portátil un mensaje binario que contiene un lote deórdenes APDU o un fragmento del lote de órdenes APDU, conteniendo cada mensaje binario un segmento deEncabezamiento, un segmento de Cuerpo y un segmento de Información, presentando el segmento deEncabezamiento un campo de Secuencia de paquete fragmentado que proporciona información sobre laexistencia o no de una fragmentación y, en caso de fragmentación, sobre el número de secuencia delfragmento, presentando el segmento de Encabezamiento un campo de índice de segmento de Información, yporque, dicho lote de órdenes APDU o su fragmento se almacena en el segmento de Cuerpo del mensajebinario, presentando el segmento de Información un campo de código de Información que describe lainformación enviada, a continuación:

- si dicho lote de órdenes APDU no se fragmenta, el dispositivo portátil envía un mensaje binario que incluye unresultado de ejecución de dicho lote de órdenes APDU para completar la transacción para dicho lote,

- si dicho lote de órdenes APDU se fragmenta, el dispositivo portátil envía un mensaje de solicitud binario de másfragmento con la siguiente secuencia de fragmento y espera un mensaje de respuesta binario para másfragmento, del servidor, para el siguiente fragmento y, cuando se reciben todos los fragmentos, el dispositivoportátil ejecuta dicho lote, a continuación el dispositivo portátil envía un mensaje binario que incluye unresultado de ejecución de dicho lote,

y cuando se completa la transacción para dicho lote, el dispositivo espera un mensaje binario del servidor paraun posible lote sucesivo.

Procedimiento de comunicación entre un dispositivo que ejecuta Java ME y un servidor por vía aérea con mensajes SOAP bajo APDU desde/hacia un operador en un anfitrión, y sistema correspondiente.

La presente invención define un nuevo procedimiento de comunicaciones con un protocolo que permite una fragmentación adaptativa de paquetes de datos, un formato de mensaje optimizado y funcionalidades de autorecuperación para una aplicación Java ME® (JME) con el fin de comunicarse con un servidor de aplicaciones a través del aire por medio de HTTP o HTTPS. El servidor de aplicaciones, el cual puede entender el protocolo, realiza una traducción a otro protocolo de mensajes y lo encamina hacia el anfitrión de punto extremo. El mensaje de punto extremo puede ser un mensaje XML privativo o del Protocolo Simple de Acceso a Objetos (SOAP) de normativa abierta. El protocolo proporciona autorecuperación al volver a enviar el último mensaje una y otra vez cuando no se recibe ningún mensaje de respuesta dentro de un cierto periodo de tiempo. Encuentra aplicación especialmente en las industrias de comunicación. Se describe también un sistema.

Cada vez se están usando más dispositivos portátiles con tarjetas inteligentes. Dichos dispositivos están destinados a comunicarse con operadores en un anfitrión a través de una red. La comunicación entre el dispositivo de la red se efectúa a través de un servidor al que se denomina generalmente pasarela de canal. Algunos de dichos dispositivos ejecutan una aplicación Java ME® y esto se lleva a cabo habitualmente con recursos limitados en términos de memoria y poder de procesado. Por otra parte, la tecnología de comunicaciones usada en el dispositivo es lenta y posiblemente no fiable con una velocidad, siendo realista, de hasta 56 Kbps.

A medida que el servidor de aplicaciones cambia hacia una arquitectura orientada a servicios web, el protocolo de mensajería por defecto para comunicarse con el servidor es un mensaje SOAP a través de HTTP o HTTPS. No obstante, el análisis sintáctico y la serialización del mensaje SOAP requiere un procesado y una memoria mucho mayores que un mensaje binario. Por otra parte, el tamaño del mensaje es mucho mayor que el de un mensaje binario.

Tal como se ha mencionado anteriormente, un sistema de gestión de tarjetas inteligentes SOA encapsula mensajes APDU en SOAP y realiza transmisiones a través de una red de cable o inalámbrica. Para una aplicación Java ME que se ejecuta en un dispositivo móvil con conexión inalámbrica GPRS® o 3G® con el fin de comunicarse con el sistema, el dispositivo requiere una memoria mayor para el almacenamiento temporal de SOAP y un procesador más rápido para analizar sintácticamente y extraer los datos APDU fuera del mensaje SOAP. Los datos transmitidos por vía aérea se podrían limitar en cuanto a tamaño según la conexión por parte del operador móvil.

Por tanto, existe un límite sobre la magnitud de la transferencia de datos controlada en la pasarela del operador móvil. Es necesario que los datos de los paquetes intercambiados entre el dispositivo y el servidor se dividan en paquetes de menor tamaño el cual sea inferior a la magnitud del límite de manera que el paquete se pueda transmitir uniformemente a través de la red del operador. El paquete resultará determinado por la ubicación de la célula en la cual se registró el dispositivo.

Por ello, para superar esto, se define un ajuste adaptativo bajo demanda, del tamaño de los datos según la conexión.

El transporte de datos APDU en el tiempo es una conexión fiable no garantizada. Junto a ello, la JVM subyacente que se ejecuta en el dispositivo puede no realizar una recolección correcta de basura sobre los recursos dentro de un cierto periodo de tiempo, y por lo tanto puede derivar en el bloqueo de la subsiguiente operación de conexión abierta.

El documento WO-2006/087438 trata sobre un método y un dispositivo para acceder a una tarjeta SIM alojada en un terminal móvil por medio de una pasarela doméstica. La comunicación se efectúa a través de un enlace inalámbrico y especialmente del Bluetooth®.

La presente invención está destinada a superar dichos problemas y a proporcionar ventajas que se pondrán de 55 manifiesto a partir de la descripción.

La invención trata sobre un procedimiento de comunicación por medio de HTTP o HTTPS entre un dispositivo que ejecuta Java ME® y un servidor por vía aérea, recibiendo y transmitiendo dicho servidor mensajes SOAP (Protocolo Simple de Acceso a Objetos) desde/hacia un operador en un anfitrión a través de una red y teniendo la capacidad de 60 intercambiar mensajes SOAP bajo un formato de datos de Unidad de Datos de Protocolo de Aplicación (APDU) con el dispositivo.

Según la invención, los mensajes SOAP se traducen a partir de/en mensajes binarios según un protocolo en el servidor, intercambiándose dichos mensajes binarios con el dispositivo,

y en caso de que el mensaje no pueda ser contenido en un mensaje binario, el intercambio se efectúa en una transmisión por lotes de una pluralidad de mensajes binarios,

y para que se ejecute una comunicación según el protocolo, se implementan las siguientes etapas:

- el dispositivo en primer lugar envía al servidor un mensaje binario que incluye una solicitud de intercambio APDU e información de inicialización de servicio para identificar un operador,

- como respuesta, el servidor envía de vuelta al dispositivo un mensaje binario de un lote de órdenes APDU con detalles fragmentados en un Segmento de Información, a continuación:

- si dicho lote de órdenes APDU no está fragmentado, el dispositivo envía un mensaje binario que incluye un resultado de ejecución de dicho lote de órdenes APDU para completar la transacción correspondiente a dicho lote,

- si dicho lote de órdenes APDU está fragmentado, el dispositivo envía una solicitud de más fragmento con la siguiente secuencia de fragmentos y espera por un mensaje binario del servidor para el siguiente fragmento y, cuando se reciben todos los fragmentos, el dispositivo ejecuta dicho lote,

y, cuando la transacción se ha completado para dicho lote, el dispositivo espera por un mensaje binario del servidor en relación con un posible lote sucesivo.

De forma más precisa, la presente invención se refiere a un procedimiento según la reivindicación 1 y a un sistema según la reivindicación 10.

En la invención se consideran también los siguientes medios, posiblemente usados en todas las combinaciones técnicas posibles:

- los mensajes binarios son mensajes de solicitud binarios y mensaje de respuesta binario,

- el mensaje de solicitud binario tiene una parte de segmento de encabezamiento de siete bytes, una parte de segmento de cuerpo de n bytes y una parte de segmento de información de cinto bytes,

- el mensaje de respuesta binario tiene una parte de segmento de encabezamiento de siete bytes, una parte de segmento de cuerpo de n bytes y una parte de segmento de información de tres bytes,

- los mensajes binarios son de acuerdo con las tablas descritas en este documento,

- la parte de segmento de cuerpo de los mensajes binarios es fragmentable,

- se puede solicitar más fragmento con un mensaje de solicitud binario de más fragmento con una parte de segmento de encabezamiento de dos bytes y una parte de segmento de cuerpo de un byte, siendo la respuesta de la solicitud de más fragmento un mensaje de respuesta binario para más fragmento con una parte de segmento de encabezamiento de dos bytes y una parte de segmento de cuerpo de un byte,

- se implementan unos medios de recuperación y de autoreintento, memorizándose mensajes antes de ser enviados en puntos de memorización predefinidos del procedimiento,

- los puntos de memorización se producen, en el servidor, cada vez que el servidor envía al dispositivo un mensaje binario que incluye órdenes APDU, y, en el dispositivo, cada vez que el dispositivo envía al servidor un mensaje binario que incluye un resultado de ejecución de órdenes APDU,

- se inicia un contador de tiempo en el dispositivo cada vez que el dispositivo envía un mensaje de resultado de ejecución de órdenes APDU y, si el servidor no reacciona después de un recuento de tiempo predeterminado, el dispositivo ejecuta un reintento volviendo a enviar el mensaje desde el punto de memorización relacionado,

- se autoriza un número predeterminado de reintento para cada punto de memorización antes de abortar el procedimiento,

- en caso de que se aborte el procedimiento, el código de respuesta es un código de error y, en otro caso, el código de respuesta es un código de éxito.... [Seguir leyendo]

1. Procedimiento de comunicación por medio de HTTP o HTTPS entre un dispositivo portátil que ejecuta Java ME con una tarjeta inteligente y un servidor por vía aérea, recibiendo y transmitiendo dicho servidor datos APDU

encapsulados en mensajes SOAP desde/hacia un operador en un anfitrión a través de una red y transmitiendo y recibiendo datos APDU contenidos en mensajes binarios desde/hacia el dispositivo portátil, traduciéndose cada mensaje SOAP a partir de/en mensajes binarios de acuerdo con un protocolo en el servidor, intercambiándose dichos mensajes binarios con el dispositivo portátil,

y en caso de que los datos APDU no puedan estar contenidos en un mensaje binario, el intercambio se efectúa en una transmisión por lotes de una pluralidad de mensajes binarios,

caracterizado porque para ejecutar una comunicación según el protocolo con el dispositivo portátil que ejecuta Java ME y su tarjeta inteligente, y usando lotes de órdenes APDU completas, se implementan las etapas 15 siguientes:

- el dispositivo portátil en primer lugar envía al servidor un mensaje binario que incluye una solicitud de intercambio APDU e información de inicialización de servicio para identificar un operador,

- como respuesta, el servidor envía de vuelta al dispositivo portátil un mensaje binario que contiene un lote de órdenes APDU o un fragmento del lote de órdenes APDU, conteniendo cada mensaje binario un segmento de Encabezamiento, un segmento de Cuerpo y un segmento de Información, presentando el segmento de Encabezamiento un campo de Secuencia de paquete fragmentado que proporciona información sobre la existencia o no de una fragmentación y, en caso de fragmentación, sobre el número de secuencia del

fragmento, presentando el segmento de Encabezamiento un campo de índice de segmento de Información, y porque, dicho lote de órdenes APDU o su fragmento se almacena en el segmento de Cuerpo del mensaje binario, presentando el segmento de Información un campo de código de Información que describe la información enviada, a continuación:

- si dicho lote de órdenes APDU no se fragmenta, el dispositivo portátil envía un mensaje binario que incluye un resultado de ejecución de dicho lote de órdenes APDU para completar la transacción para dicho lote,

- si dicho lote de órdenes APDU se fragmenta, el dispositivo portátil envía un mensaje de solicitud binario de más fragmento con la siguiente secuencia de fragmento y espera un mensaje de respuesta binario para más

fragmento, del servidor, para el siguiente fragmento y, cuando se reciben todos los fragmentos, el dispositivo portátil ejecuta dicho lote, a continuación el dispositivo portátil envía un mensaje binario que incluye un resultado de ejecución de dicho lote,

y cuando se completa la transacción para dicho lote, el dispositivo espera un mensaje binario del servidor para 40 un posible lote sucesivo.

2. Procedimiento según la reivindicación 1, caracterizado porque los mensajes binarios son mensajes de solicitud binarios y mensaje de respuesta binario, presentando el mensaje de solicitud binario una parte de segmento de Encabezamiento de siete bytes, una parte de segmento de Cuerpo de n bytes, y una parte de segmento de 45 Información de cinco bytes, presentando el mensaje de respuesta binario una parte de segmento de Encabezamiento de siete bytes, una parte de segmento de Cuerpo de n bytes y una parte de segmento de Información de tres bytes.

3. Procedimiento según la reivindicación 2, caracterizado porque, para el mensaje de solicitud binario de acuerdo 50 con:

Segmento de Encabezamiento Segmento de Cuerpo Segmento de Información

h (1) h (2) h (3) (h4) h (5) h (6) h (7) b (1) b (2) ... b (n1) b (n) i (1) i (2) i (3) i (4) i (5)

el Segmento de Encabezamiento que es obligatorio es: el segmento de Cuerpo, el cual es opcional, es:

n.º Campo Longitud (Bytes) Descripción

1 h (1) 1 Código de orden – describe la solicitud de orden que se debe entregar al servidor, por ejemplo, intercambio APDU.

2 h (2) 1 Longitud total del segmento de encabezamiento – describe el tamaño total del segmento de encabezamiento excluyendo el código de información.

3 h (3) 1 Longitud de ID de sesión – el valor de id de sesión es un campo opcional en la medida en la que es asignado por el servidor. Por tanto, la longitud puede ser 0

n.º Campo Longitud (Bytes) Descripción

para la primera solicitud al servidor.

4 h (4) variable Valor de ID de sesión – un valor de id de sesión asignado por el servidor.

5 h (5) 1 Secuencia de lote – esto describe la secuencia actual del lote APDU de órdenes. El intervalo de la secuencia es de 1 a 255.

6 h (6) 1 Secuencia de paquete fragmentado – esto identifica la secuencia del paquete de datos en caso de que el mismo esté fragmentado. Si no existe fragmentación, el valor se fija a 0. El intervalo de la secuencia es de 1 a 255.

7 h (7) 1 Índice de segmento de información – indica el índice de la información si el segmento existe para un mensaje particular. Si el segmento no existe, el valor se fija a 0. El intervalo del índice es de 1 a 255.

n.º Campo Longitud (Bytes) Descripción

1 b (1) 1 Longitud de datos APDU – describe la longitud del primer conjunto de órdenes APDU dentro de un lote.

2 b (2) variable Valor de datos APDU – el primer conjunto de datos de órdenes APDU dentro de un lote.

3 b (n-1) 1 Longitud del conjunto N de APDU.

4 b (n) variable Datos del conjunto N de APDU.

y el segmento de Información, el cual es opcional, es:

n.º Campo Longitud (Bytes) Descripción

1 i (1) 1 Código de información – describe la información que se debe entregar al servidor, por ejemplo, info de Inicialización de Servicio.

2 i (2) 1 Longitud de ID de aplicación.

3 i (3) variable Valor de ID de aplicación – esta es una id de aplicación única asignada a cada aplicación.

4 i (4) 1 Longitud de datos de información opcional.

5 i (5) variable Valor de datos de información opcional.

4. Procedimiento según la reivindicación 2, caracterizado porque, para el mensaje de respuesta binario de acuerdo con:

Segmento de Encabezamiento Segmento de Cuerpo Segmento de Información

h (1) h (2) h (3) h (4) h (5) h (6) h (7) b (1) b (2) ... b (n1) b (n) i (1) i (2) i (3)

el segmento de Encabezamiento, el cual es obligatorio, es:

n.º Campo Longitud (Bytes) Descripción

1 h (1) 1 Código de respuesta – identifica el estado de respuesta del servidor. El código 0 representa habitualmente éxito, si no, representa estado fallido.

2 h (2) 1 Longitud de ID de sesión.

3 h (3) variable Valor de ID de sesión – Este campo es un valor de id de sesión asignado por el servidor.

4 h (4) 1 Código de error – esto describe el código de error de la transacción. Este campo es válido si el código de respuesta no es 0.

5 h (5) 1 Secuencia de lote – esto describe la secuencia actual del lote APDU de órdenes.

6 h (6) 1 Secuencia de paquete fragmentado – esto identifica la secuencia del paquete de datos en caso de que el mismo esté fragmentado.

7 h (7) 1 Índice de segmento de información – indica el índice de la información si el segmento existe para un mensaje particular.

el segmento de Cuerpo, el cual es opcional, es: y el segmento de Información, el cual es opcional, es:

n.º Campo Longitud (Bytes) Descripción

1 b (1) 1 Longitud de datos APDU – describe la longitud del primer conjunto de órdenes APDU dentro de un lote.

2 b (2) variable Valor de datos APDU – el primer conjunto de datos de órdenes APDU dentro de un lote.

3 b (n-1) 1 Longitud del conjunto N de APDU.

4 b (n) variable Datos del conjunto N de APDU.

n.º Campo Longitud (Bytes) Descripción

1 i (1) 1 Código de información – describe la información que se debe responder desde el servidor, por ejemplo, tamaño de datos fragmentados tanto para el emisor como para el receptor.

2 i (2) 1 Longitud de datos de información opcional.

3 i (3) variable Valor de datos de información opcional.

5. Procedimiento según la reivindicación 2, 3 o 4, caracterizado porque el dispositivo portátil puede solicitar más segmentos con un mensaje de solicitud binario de más fragmento que presenta una parte de segmento de Encabezamiento de dos bytes y una parte de segmento de Cuerpo de un byte, siendo la respuesta de la solicitud de más fragmento del servidor un mensaje de respuesta binario de más fragmento que presenta una parte de segmento de Encabezamiento de dos bytes y una parte de segmento de Cuerpo de un byte.

6. Procedimiento según la reivindicación 5, caracterizado porque, para la solicitud binaria de más fragmento de acuerdo con:

el segmento de encabezamiento, el cual es obligatorio, es:

n.º Campo Longitud (Bytes) Descripción

1 h (1) 1 Código de orden – existen diferentes órdenes para describir dos casos. 1. La parte solicitante solicita más fragmentos del servidor. 2. La parte solicitante envía más fragmentos al servidor.

2 h (2) 1 Secuencia de paquetes fragmentados – depende de la fragmentación de la parte solicitante o de la parte respondedora. Si es una fragmentación de la parte solicitante, la secuencia identifica la secuencia fragmentada actual que se envía, si no, la parte solicitante solicita la secuencia fragmentada esperada del servidor.

y el segmento de Cuerpo, el cual es opcional, es:

n.º Campo Longitud (Bytes) Descripción

1 b (1) variable Los datos APDU fragmentados. Se hacen variar de acuerdo con el tamaño de paquete fragmentado definido, asignado por el servidor. El segmento de cuerpo existe si y solo si la fragmentación es desde el lado solicitante.

7. Procedimiento según la reivindicación 5, caracterizado porque, para el mensaje de respuesta binario de más fragmento de acuerdo con:

el segmento de Encabezamiento, el cual es obligatorio, es: y el segmento de Cuerpo, el cual es opcional, es:

n.º Campo Longitud (Bytes) Descripción

1 h (1) 1 Código de respuesta. El código 0 habitualmente representa éxito, si no, representa estado fallido. 1. La parte solicitante solicita más fragmentos del servidor. 2. La parte solicitante envía más fragmentos al servidor.

2 h (2) 1 Secuencia empaquetada fragmentada – depende de la fragmentación de la parte

solicitante o la parte respondedora. Si es una fragmentación de la parte respondedora, la secuencia identifica la secuencia fragmentada actual que se envía a la aplicación, si no, es la siguiente secuencia fragmentada esperada que se recibirá desde el servidor.

n.º Campo Longitud (Bytes) Descripción

1 b (1) variable Los datos APDU fragmentados. Se hacen variar de acuerdo con el tamaño de paquete fragmentado definido, asignado por el servidor. El segmento de cuerpo existe si y solo si la fragmentación es desde el lado respondedor.

8. Procedimiento según cualquiera de las reivindicaciones anteriores, caracterizado porque se implementan unos medios de recuperación y de autoreintento, memorizándose mensajes antes de ser enviados en puntos de memorización predefinidos del procedimiento, estando los puntos de memorización, en el servidor, cada vez que el servidor envía al dispositivo un mensaje binario que incluye órdenes APDU, y, en el dispositivo portátil, cada vez que el dispositivo portátil envía al servidor un mensaje binario que incluye un resultado de ejecución de órdenes APDU.

9. Procedimiento según la reivindicación 8, caracterizado porque se inicia un contador de tiempo en el dispositivo portátil cada vez que el dispositivo portátil envía un mensaje de resultado de ejecución de órdenes APDU y porque si el servidor no reacciona después de un recuento de tiempo predeterminado, el dispositivo portátil ejecuta un reintento al volver a enviar el mensaje desde el punto de memorización relacionado, y porque se autoriza un número predeterminado de reintentos para cada punto de memorización antes de abortar el procedimiento.

10. Sistema, caracterizado porque presenta unos medios para la ejecución del procedimiento según cualquiera de las reivindicaciones anteriores.