UN DISPOSITIVO DE TELEFONÍA MÓVIL Y UN MÉTODO DE GESTIÓN DE DATOS
CAMPO DE LA INVENCIÓN La invención se engloba en el campo de la telefonía móvil. Como es sabido, en dicho campo, normalmente se utilizan acrónimos y términos anglosajones para referirse a elementos y conceptos propios del campo. Para facilitar la lectura de esta memoria descriptiva para un lector no experto en la materia, se expone a continuación un listado de acrónimos utilizadas en la presente: GSM Global System for Mobile Communication ICC Integrated Circuit Card ("Tarjeta Chip")
SIM Subscriber Identity Module ("Módulo de Identificación de Usuario").
SAT SIM Application Toolkit ("Aplicaciones SIM Toolkit" o, simplemente,
"Aplicaciones Toolkit"; conjunto de herramientas para aplicaciones sobre la SIM) UMTS Universal Mobile Telecommunications System (también llamado
"Tercera Generación de Telefonía Móvil") UICC UMTS Integrated Circuit Card (la "tarjeta chip" para el UMTS)
USIM Universal Subscriber Identity Module (el Módulo de Identificación de
Usuario en el UMTS) USAT USIM Application Toolkit (el SAT en el caso del UMTS)
OTA Over The Air (Acceso remoto a la tarjeta SIM/USIM)
ANTECEDENTES DE LA INVENCIÓN Actualmente existen diferentes tipos de teléfonos móviles (también llamados "teléfonos portátiles" o "celulares"), que suelen estar dotados de un teclado y de una pantalla con capacidad para mostrar símbolos alfanuméricos y, en muchos casos, también gráficos.
Actualmente existen varios sistemas de telefonía móvil, entre ellos el sistema GSM y el UMTS (también llamado la "Tercera Generación de Telefonía Móvil"). El equipo de usuario comprende, tanto en el sistema GSM como en el sistema
UMTS: a) por una parte un terminal (que es el que muchas veces se denomina "teléfono móvil") (que incluye una carcasa, pantalla, teclado, fuente de alimentación y circuitos diversos); y b) por otra parte una tarjeta ICC o UICC (UMTS Integrated Circuit Card).
En el caso de GSM se trata de una tarjeta ICC llamada tarjeta SIM o simplemente SIM (Subscriber Identity Module) o de una UICC con una aplicación SIM y en el caso de UMTS se tratará de una UICC con una aplicación USIM. Tanto la tarjeta SIM como la tarjeta UICC (con una o varias aplicaciones SIM y/o USIM) contienen un conjunto de ficheros con datos del operador de la red de telefonía móvil y del usuario (subscríber) y están dotadas de medios de ejecutar operaciones asociadas a una serie de comandos que permiten al terminal acceder a esos ficheros (leerlos, escribirlos, seleccionarlos, verificar claves de usuario, etc.). Entre los datos de usuario están los que autentifican al usuario ante la red. Hasta la llegada de UMTS (la llamada Tercera Generación de Telefonía Móvil) no se solía hacer distinción alguna entre el ¡nterfaz físico de la aplicación (dependiente de la propia naturaleza de la tarjeta inteligente ICC) y la propia aplicación: ambos eran llamados SIM. La tercera generación de telefonía móvil (UMTS) introdujo la separación del ¡nterfaz físico y las aplicaciones. El interfaz físico recibe el nombre de UICC; se trata de una plataforma en la que pueden convivir varías aplicaciones simultáneamente; entre ellas puede haber aplicaciones SIM y/o USIM. La aplicación de identificación de usuario propiamente dicha recibe en UMTS el nombre de USIM.
Se considera que una tarjeta inteligente es un dispositivo físicamente seguro, es decir, es un dispositivo en el que los datos almacenados se encuentran protegidos frente a ataques de terceros que pretendan leerlos, modificarlos, borrarlos o falsearlos sin permiso del propietario de la información.
A continuación, en ocasiones nos referimos al módulo de identificación de usuario como SIM tanto para GSM como para UMTS (es decir, con SIM también nos referimos a una UICC con las aplicaciones SIM o USIM correspondientes). En el campo de la telefonía móvil también se conoce el concepto SAT=SIM
Application Toolkit (en UMTS, USAT=USIM Application Toolkit), que consiste en un conjunto de herramientas para aplicaciones sobre la SIM; a continuación, nos referimos a una aplicación basada en dichas herramientas como una "aplicación Toolkit". En un primer momento, los terminales móviles sólo eran capaces de enviar comandos a las SIMs, mientras que las SIMs sólo eran capaces de responder a comandos recibidos desde el terminal móvil.
Posteriormente se produjo una evolución de los terminales móviles y de las tarjetas SIM y se permite, por un lado, a los terminales tanto enviar comandos a la tarjeta SIM como recibir comandos de la misma, y por otro lado, a la tarjeta SIM tanto
responder a comandos recibidos desde el terminal móvil como enviar comandos al mismo. Estos comandos permiten a la SIM, por ejemplo, solicitar al terminal el envío de un mensaje corto (SM), la realización de una llamada, mostrar una lista de opciones al usuario, solicitarle un dato, etc. Las aplicaciones existentes en la tarjeta SIM capaces de enviar comandos al terminal móvil se conocen con el nombre de aplicaciones SAT (SIM Application Toolkit). En UMTS se conocen con el nombre de aplicaciones USAT (USIM Application Toolkit). En general, tanto a unas como a otras se las llama aplicaciones Toolkit.
Las aplicaciones Toolkit son una característica opcional tanto de las tarjetas SIM como de las tarjetas UICC (con las aplicaciones correspondientes). Los procedimientos de alto nivel, contenidos y codificación de los comandos, están especificados en la norma GSM11.14 para GSM y en la norma 3GPP TS 31.111 para UMTS.
También se conoce el concepto OTA (Over The Air), que se refiere al acceso remoto a la tarjeta SIM (o USIM). Inicialmente, cuando las tarjetas salían al mercado, el operador no podía modificar nada en ellas, estaban fuera de su alcance. Sin embargo, parecía interesante poder modificar el contenido de algunos ficheros en la tarjeta, modificar el perfil de personalización y cargar o modificar aplicaciones Toolkit una vez que la tarjeta estaba en posesión del cliente. Por tanto, los fabricantes de tarjetas empezaron a incorporar sistemas OTA (de acceso remoto) que permitían gestionar los contenidos de la tarjeta mediante mensajes cortos especiales. Cada fabricante disponía de una solución propietaria incompatible con las de otros fabricantes. Posteriormente se han generado unas especificaciones estándar para realizar este tipo de modificaciones remotas OTA (GSM 03.48 y 3GPP 23.048). Basándose en estas especificaciones se pueden implementar sistemas OTA compatibles que permiten la gestión de ficheros y de aplicaciones.
En la actualidad se está trabajando en la definición de estándares que permitan emplear otros tipos de portadoras, no solo mensajes cortos, para hacer comunicaciones más rápidas y flexibles, estas portadoras pueden ser GPRS (General Packet Radio Service), Bluetooth, llamada de datos, etc.
En telefonía móvil se están desarrollando multitud de aplicaciones SIM Toolkit que se pretenden gestionar por el operador de forma remota. El problema surge cuando se quiere acceder remotamente a datos de la aplicación como pueden ser los textos que muestra, números de teléfono a los que llama o manda mensajes cortos o
cualquier otro tipo de datos.
Las aplicaciones pueden ser cargadas de forma remota siguiendo los estándares, pero no está definida la creación de ficheros de forma remota, por tanto, si se quiere que una aplicación se pueda cargar y que contenga algún tipo de dato, el dato se debe almacenar en un array y no en un fichero para que se pueda descargar en la tarjeta de forma remota. El problema se encuentra en que no está definido de ninguna forma el acceso remoto (es decir, "vía OTA") a los datos almacenados en arrays.
Por tanto, si se quieren cargar aplicaciones de forma remota, los datos se deben guardar en arrays y no en ficheros, pero los arrays no son modificables de forma remota, por lo que los datos de una aplicación cargada remotamente no podrían modificarse remotamente. Actualmente para modificar uno de estos datos se debe borrar la aplicación y volver a cargarla entera con el dato modificado, perdiendo toda la información que pudiese haber introducido el usuario para personalizar la aplicación. El hecho de tener que eliminar y volver a cargar la aplicación para modificar, por ejemplo, un número de teléfono hace necesario el envío de entre 40 a 60 mensajes cortos para una aplicación típica (depende del tamaño de la aplicación) cuando si el número de teléfono a modificar estuviese en un fichero bastaría con un mensaje corto. La figura 1 ilustra un ejemplo del estado de la técnica: una tarjeta SIM (o
USIM) 1 contiene un gestor de acceso remoto (gestor OTA) 2 que comprende un módulo gestor remoto de aplicaciones 2A y un módulo gestor remoto de ficheros 2F. La tarjeta 1 incluye, además, una primera aplicación Toolkit 3A y una segunda aplicación Toolkit 4A. Las aplicaciones pueden ser aplicaciones SAT o USAT. La primera aplicación Toolkit 3A está relacionada con (lee, escribe, manipula, etc.) datos 3D que se almacenan en un fichero 3F. Dicho fichero se establece durante la personalización de la tarjeta en la fábrica (flecha "a" en la figura 1). La segunda aplicación Toolkit 4A está relacionada con datos 4D almacenados en un array que forma parte de la propia aplicación. La tarjeta 1 puede ser gestionada de forma remota mediante un sistema OTA; los mensajes OTA se reciben en el equipo de usuario y se transmiten a la tarjeta, en la que el gestor de acceso remoto 2 (que en sí constituye una aplicación Toolkit) se hace cargo de realizar las operaciones oportunas. Mediante el módulo gestor remoto de aplicaciones 2A se pueden cargar en la tarjeta las aplicaciones 3A (flecha "b") y 4A (flecha "c") y, si el fichero 3F ha sido establecido en la fábrica durante la
personalización de la tarjeta, los datos 3D se pueden escribir, leer o manipular de forma remota (OTA) mediante el módulo gestor de ficheros (2F) (flecha "d"). (Sin embargo, si el fichero 3F no se ha creado durante la mencionada personalización en la fábrica, no será posible cargar correctamente la primera aplicación Toolkit 3A, ya que no se puede crear el fichero asociado 3F de forma remota (OTA)).
Por otra parte, en cuanto a la segunda aplicación Toolkit 4A, el sistema actual de acceso remoto (OTA) permite cargar la aplicación de forma correcta a pesar de que no tiene fichero asociado, ya que la aplicación no requiere fichero: como hemos indicado, los datos 4D están alojados en un array en la propia aplicación. Sin embargo, el actual sistema de acceso remoto (OTA) a la tarjeta no permite modificar los datos 4D asociados a dicha aplicación de forma remota, ya que el sistema de acceso remoto (incluyendo el gestor de acceso remoto 2) no comprende medios de acceso y manipulación de datos en un array de una aplicación. Por tanto, para modificar cualquier dato 4D sería necesario borrar toda la aplicación 4A y volverla a cargar a través del módulo gestor de aplicaciones 2A, con los inconvenientes que ello implica.
DESCRIPCIÓN DE LA INVENCIÓN Un primer aspecto de la invención se refiere a un dispositivo de telefonía móvil (que puede ser una tarjeta SIM/USIM o un equipo de usuario que comprende un terminal y dicha tarjeta SIM/USIM), que comprende: un dispositivo de almacenaje (por ejemplo, una tarjeta chip (ICC) con un módulo de identificación de usuario (SIM/USIM)) que comprende medios para almacenar, al menos, una aplicación (por ejemplo, una aplicación SAT/USAT); y medios de gestión por acceso remoto (OTA) del dispositivo de almacenaje en base a recepción de mensajes de acceso remoto (OTA) por telefonía móvil (es decir, los medios comentados en lo anterior, incluyendo, por ejemplo, un gestor de acceso remoto -gestor OTA- con su gestor de aplicaciones y gestor de ficheros y las diferentes portadoras que pueden emplearse para hacer llegar los mensajes de acceso remoto a la tarjeta como pueden ser mensajes cortos, llamadas de datos, GPRS, Bluetooth, etc.).
Según la invención, el dispositivo comprende además, al menos, un módulo gestor de arrays de datos de, al menos, una aplicación almacenada en el dispositivo de almacenaje. El módulo gestor de arrays de datos comprende:
- medios de recibir, mediante un mensaje de acceso remoto (OTA), al menos una instrucción de operación sobre al menos un dato contenido en un array de una
aplicación especificada;
- medios de acceder a dicho array en función de dicha instrucción; y
- medios de realizar, al menos, una operación sobre dicho al menos un dato en dicho array, en función de dicha instrucción. El módulo gestor de arrays de datos es el encargado de procesar los datos o instrucciones recibidos en un mensaje OTA, de acceder al array y de modificarlo de acuerdo con las instrucciones.
Desde el punto de vista funcional, el sistema puede componerse de los siguientes elementos: - Una tarjeta GSM, UMTS o similar en la que hay un módulo (ya sea un
API (Application Programming Interface - "interfaz para programar aplicaciones") o una aplicación independiente) que se encarga de la gestión OTA de arrays.
Un terminal que soporte SAT o USAT que soporte Data Download (cada vez más modelos lo soportan -bastantes modelos de Siemens, Nokia, Samsung, Alcatel, etc.-) y/o que sea de clase "e", es decir que soporte los comandos de gestión de canales (actualmente hay pocos terminales que lo soporten pero su número va aumentando).
Un servidor OTA con los sistemas asociados. El módulo gestor de arrays presenta un interfaz adecuado para que pueda acceder a los arrays de las diferentes aplicaciones.
Los medios de acceder al array pueden comprender:
- medios de pedir una referencia del array a la aplicación especificada;
- medios de recibir la referencia solicitada; y
- medios de acceder al array en base a dicha referencia. El módulo gestor de arrays de datos puede estar configurado para poder acceder a arrays de una pluralidad de aplicaciones. Por ejemplo, el módulo puede consistir en una aplicación independiente capaz de acceder a los arrays de una pluralidad de aplicaciones.
Sin embargo, también existe la posibilidad de utilizar un módulo gestor específico para cada aplicación en la que se desea operar sobre datos en un array mediante acceso remoto (OTA). Por ejemplo, el módulo gestor puede formar parte de la aplicación concreta a cuyo array de datos se quiere acceder, por ejemplo, estar constituido por un API (Application Programming Interface - "interfaz para programar aplicaciones"). Los medios de gestión por acceso remoto (OTA) pueden estar basados en la
norma GSM 03.48 o en la norma 3GPP 23.048.
El dispositivo comprende preferiblemente un terminal que soporta SAT o USAT y que soporta Data Download y/o un terminal de clase "e" que soporta los comandos SIM Toolkit para gestión de canales. Otro aspecto de la invención se refiere a un método de gestión de datos en arrays de aplicaciones almacenadas en una tarjeta (por ejemplo, en una tarjeta SIM/USIM) de un equipo de usuario de telefonía móvil, y que comprende los pasos de: recibir un mensaje de un servidor de acceso remoto (OTA), con al menos una instrucción relativa a al menos un dato en un array de una aplicación almacenada en la tarjeta; analizar la instrucción; en base a la instrucción, acceder al array; en base a la instrucción, operar sobre dicho al menos un dato en el array.
El paso de acceder al array puede comprender los pasos de: - pedir una referencia del array a la aplicación; recibir dicha referencia; y acceder al array en base a dicha referencia.
Preferiblemente, el mensaje se recibe en un terminal del equipo de usuario y se envía desde el terminal a la tarjeta, donde un módulo gestor de acceso remoto (OTA) en la tarjeta remite la instrucción a un módulo gestor de arrays de datos identificado en el mensaje. Preferiblemente, el mensaje es del tipo Data Download y se envía a la tarjeta mediante el comando ENVELOPE. La instrucción se puede remitir a un módulo gestor de arrays de datos identificado mediante el campo TAR del mensaje. También existe la posibilidad de enviar el mensaje a la tarjeta a través de un canal basado en el Bearer Independent Protocol (Protocolo Independiente de la Portadora).
Un servicio que requiera la modificación de datos en una aplicación descargada de forma remota (o no) en la tarjeta puede emplear este sistema. El módulo que gestiona los arrays debe ser capaz de identificar diferentes comandos para permitir una gestión más flexible de los arrays. Es interesante emplear comandos que permitan, al menos:
- Escribir
- Leer
A estos se pueden añadir otros que faciliten la gestión como pueden ser
- Borrar - Copiar
- Incrementar
Una buena opción es la de soportar los mismos comandos que se especifican en la norma GSM 1 1.11 y /o en la norma 3GPP 31.101 para gestión de ficheros:
- UPDATE BINARY - UPDATE RECORD
- READ BINARY
- READ RECORD
- INCREASE
Esto permite una gestión flexible de los arrays con un mínimo tamaño de código.
BREVE DESCRIPCIÓN DE LOS DIBUJOS A continuación se pasa a describir de manera muy breve una serie de dibujos que ayudan a comprender mejor la invención y que se relacionan expresamente con una realización de dicha invención que se presenta como un ejemplo ilustrativo y no limitativo de ésta.
La figura 1 refleja, de forma esquemática, algunos componentes de una tarjeta SIM/USIM de acuerdo con el estado de la técnica.
La figura 2 refleja, de forma esquemática, algunos componentes de una tarjeta SIM/USIM que incluye un módulo gestor de arrays de datos, de acuerdo con la invención.
La figura 3 refleja, de forma esquemática, un sistema comprendiendo un dispositivo y operando de acuerdo con la invención.
DESCRIPCIÓN DE UNA REALIZACIÓN PREFERIDA DE LA INVENCIÓN
De forma análoga a la figura 1 , la figura 2 refleja (una gran parte de los componentes pueden ser idénticos a los de la figura 1 y han sido indicados con las mismas referencias numéricas, para mayor claridad) una tarjeta SIM (o USIM) 1 que contiene un gestor de acceso remoto (gestor OTA) 2 que comprende un módulo gestor remoto de aplicaciones 2A y un módulo gestor remoto de ficheros 2F. La tarjeta 1 incluye, además, una primera aplicación Toolkit 3A (SAT o USAT) y una segunda aplicación Toolkit 4A (SAT o USAT). La primera aplicación Toolkit 3A está relacionada con (lee, escribe, manipula, etc.) datos 3D que se almacenan en un fichero 3F. Dicho fichero se ha establecido durante la personalización de la tarjeta en la fábrica (flecha "a" en la figura 2). La segunda aplicación Toolkit 4A está relacionada con datos 4D
almacenados en un array que forma parte de la propia aplicación.
La tarjeta 1 puede ser gestionada de forma remota mediante un sistema de acceso remoto (OTA); los mensajes OTA se reciben en el equipo de usuario y se transmiten a la tarjeta, en la que el gestor de acceso remoto 2 se hace cargo de realizar las operaciones oportunas. Mediante el módulo gestor remoto de aplicaciones 2A se pueden cargar en la tarjeta 1 las aplicaciones 3A (flecha "b") y 4A (flecha "c") y, ya que el fichero 3F ha sido establecido en la fábrica durante la personalización de la tarjeta, los datos 3D se pueden escribir, leer o manipular de forma remota (OTA) mediante el módulo gestor de ficheros (2F) (flecha "d"). Por otra parte y de acuerdo con la invención, la tarjeta 1 contiene un módulo gestor de arrays de datos 5 que comprende: medios de recibir, mediante un mensaje de acceso remoto (OTA), al menos una instrucción de operación sobre al menos un dato contenido en un array de una aplicación especificada (flecha "e" en la figura 2); medios de acceder a dicho array en función de dicha instrucción; y medios de realizar al menos una operación sobre dicho al menos un dato en dicho array, en función de dicha instrucción. Por tanto, el módulo gestor de arrays de datos permite operar sobre los datos 4D en la segunda aplicación Toolkit 4A, sin necesidad de borrar y re-escribir toda la aplicación en la memoria de la tarjeta.
La figura 3 refleja una realización preferida de la invención, en la que el módulo gestor de arrays 5 consiste en una aplicación independiente, que puede implicar una ventaja frente a la alternativa que consiste en que cada aplicación gestione sus propios arrays. La ventaja consiste en que todos los mensajes que lleguen a la aplicación Gestor de Arrays (el módulo gestor de arrays 5) serán tratados como mensajes de gestión de arrays mientras que en la otra solución, en la que cada aplicación gestiona sus propios arrays, es necesario distinguir entre mensajes de gestión de arrays y otro tipo de mensajes que pueda recibir la aplicación para su operativa normal.
La figura 3 refleja el siguiente proceso:
El servidor de acceso remoto OTA 10 manda un mensaje M1 del tipo Data Download a un teléfono móvil.
El terminal 20 del equipo de usuario del teléfono móvil recibe el mensaje y se lo manda a la tarjeta SIM/USIM 1 mediante el comando ENVELOPE M2.
El gestor de acceso remoto (gestor OTA) 2 correspondiente de la tarjeta 1 desempaqueta el mensaje (lo descifra, verifica el checksum, etc) y se lo manda a la aplicación (al módulo gestor de arrays de datos 5) que se indica en el campo TAR del
mensaje, mediante el mensaje M3 que comprende instrucciones relativas a la operación que debe realizarse sobre los datos de la aplicación 4A.
El módulo gestor de arrays de datos 5 recibe las instrucciones (datos, comandos) donde se indica el array a modificar mediante el AID de la aplicación y el número identificador del array que se asignan en tiempo de programación.
En el módulo gestor de arrays de datos 5 se lleva a cabo el siguiente procedimiento, ilustrado en la figura 3:
Desde "inicio" (SO) se pasa a un estado de espera de instrucciones S1. Una vez que se reciben las instrucciones, el módulo gestor analiza las instrucciones (paso S2) y, luego, efectúa una llamada M4 a la aplicación 4A solicitando una referencia al array (paso S3).
La aplicación 4A propietaria del array en cuestión envía una referencia al array al módulo gestor de arrays de datos (5), mediante un mensaje M5. El módulo gestor de arrays de datos (5) recibe dicha referencia (paso S4). Seguidamente (paso S5), el Gestor de Arrays procede a escribir, leer, o lo que corresponda.
Posteriormente (paso S6) manda un mensaje al Servidor OTA indicando el resultado de la operación, preferiblemente, un mensaje corto (SM) utilizando el servicio de mensajes cortos (SMS) del sistema (M6+M7). Se pueden emplear los comandos soportados para gestión de ficheros indicados en las normas GSM 11.11 y 3GPP 31.101.
Adicionalmente se puede emplear el comando SELECT por AID basado (aunque no será igual porque no se espera recibir datos salientes) en la norma 3GPP 31.101 para indicar la aplicación propietaria del array y el comando SELECT para seleccionar el array.
Los códigos de status pueden ser los mismos que se especifican en las normas correspondientes para los respectivos comandos.
De esta forma el mensaje Data Download es una concatenación de comandos como sigue: - SELECT por AID: para indicar la aplicación
- SELECT: para indicar el array
- UPDATE BINARY, UPDATE RECORD, etc: para modificar el array.
La respuesta será la concatenación de los códigos de status, por ejemplo, en caso correcto sería: - 90 00: Aplicación seleccionada correctamente
- 90 00: Array seleccionado correctamente
- 90 00: Escritura correcta
Los arrays pueden estar identificados para su selección por dos bytes como se indica a continuación: Byte 1: codifica la estructura de array. La codificación es la misma que se define para los ficheros en la GSM 11.11 , esto es:
- 00 Binario
- 01 Lineal Fijo
- 03 Cíclico Byte 2: identifica el array. Los arrays serán dados de alta en la aplicación con números secuenciales empezando por 00.
Por ejemplo:
Si el array 03 se pretende gestionar como lineal fijo, su identificador será:
01 03 Y se seleccionará con el comando:
A0 A4 00 00 02 01 03
El resultado de la selección será:
90 00
A lo largo de la presente descripción y reivindicaciones la palabra "comprende" y variaciones de la misma, como "comprendiendo", no pretende excluir otros pasos o componentes.