ES2840176T3 - Instalación de un perfil en un módulo de identidad de abonado integrado - Google Patents

Abstract

Método de control puesto en práctica por un módulo de identidad de abonado integrado (eUICC1) capaz de cooperar con un terminal de comunicación (T), comprendiendo dicho método: - la recepción (C2) de al menos un identificador (ID) de un servicio respectivo, de un perfil de comunicación (P), a poner en práctica cuando dicho perfil de comunicación esté instalado y en estado activo en el módulo de identidad de abonado integrado; estando el método caracterizado porque comprende, además: - la determinación (C4) de si cada servicio (S) está soportado por un sistema operativo (OS1) del módulo de identidad de abonado integrado; - en caso contrario, el envío (C8) de una solicitud para actualizar el sistema operativo; - si se recibe una actualización (UPD) del sistema operativo (C10) en respuesta a dicho envío (C8), la instalación (C12) de dicha actualización permite al sistema operativo poner en práctica al menos parcialmente dicho perfil de comunicación (P); y - tras la finalización de dicha instalación, el envío (C14) de una solicitud para recibir o continuar recibiendo el perfil de comunicación (P), incluyendo dicho al menos un servicio (S), para ser instalado en dicho módulo de identidad de abonado integrado.

Description

DESCRIPCIÓN

instalación de un perfil en un módulo de identidad de abonado integrado

ANTECEDENTES DE LA INVENCIÓN

La presente invención se refiere al campo de los módulos de identidad de abonado integrados, también denominados módulos eUICC (por "embedded Universal Integrated Circuit Chip" en inglés), y se refiere más en particular a dichos módulos eUICC capaces de gestionar perfiles de comunicación.

De manera conocida, una tarjeta SIM convencional está configurada con el fin de permitir que un terminal de comunicación (tal como por ejemplo un teléfono móvil), con el que coopera, utilice la red de comunicación de un único operador telefónico. Para ello, la tarjeta SIM incluye datos de abonado tal como, por ejemplo, un identificador IMSI (por “International Mobile Subscriber Identity en inglés), claves criptográficas y algoritmos específicos del operador asociado. Estos datos de abonado se almacenan permanentemente en una memoria de solamente lectura.

Cuando un teléfono móvil intenta utilizar los servicios de una red celular, envía todos los datos de abonado, almacenados en la tarjeta SIM, necesarios para que el operador de la red obtenga acceso a los servicios requeridos. De este modo, el operador puede autenticar al usuario y verificar mediante una base de datos HLR (por ""Home Location Registef’ en inglés) que el usuario se ha suscrito efectivamente al servicio solicitado. Si es así, el operador autoriza entonces el acceso al teléfono móvil que lleva la tarjeta SIM, cuyos datos se utilizaron para la autenticación y el registro en la red del operador.

Además, actualmente se conocen tarjetas SIM reprogramables, y más en particular módulos de identidad de abonado integrados, también denominados módulos eUICC. Estos módulos reprogramables permiten al usuario cambiar de operador sin tener que sustituir físicamente la tarjeta SIM en el teléfono móvil. Las principales especificaciones de un módulo eUICC están definidas por el grupo GSMa (por ""Global System for Mobile Communications Association" en inglés) en la norma GSMA SGP.02 v3.1 titulada "Arquitectura de aprovisionamiento a distancia para UICC integrado -Especificación técnica - Versión 3.1" con fecha 27 de mayo de 2016. Un módulo eUICC es un elemento de hardware seguro, generalmente de pequeño tamaño, que puede integrarse en un terminal de comunicaciones (en un terminal móvil, por ejemplo) para poner en práctica las funciones de una tarjeta SIM tradicional.

En particular, un módulo eUICC puede contener uno o más perfiles de comunicación (también denominados "perfiles" en lo sucesivo). Cada perfil está contenido en un campo seguro dedicado denominado ISD-P de conformidad con dicha norma GSMA. Cuando un perfil de comunicación está activo, permite que el terminal de comunicación en donde está integrado, acceda de forma segura a la red de comunicación de un operador asociado, así como a los servicios definidos por el perfil en cuestión. Al cambiar el perfil de comunicación activo en el módulo eUICC, es posible cambiar de operador o modificar el acceso a los servicios asociados (servicios de voz y/o datos, por ejemplo).

Actualmente es posible que un módulo eUICC, integrado en un terminal de comunicación, reciba a distancia un nuevo perfil de comunicación. La provisión de dicho perfil es generalmente iniciada por el operador de la red de comunicación asociada al perfil, por ejemplo, mediante un servidor SM-SR encargado de la gestión a distancia de los perfiles en el módulo eUICC.

Una vez recibido, el módulo eUICC instala el perfil con el fin de permitir que el terminal se comunique con la red de comunicación asociada al perfil cuando este último se encuentra en estado activo en dicho terminal.

La norma SIMALLIANCE titulada "Paquete de perfiles eUICC: Especificación técnica de formato interoperable" (versión 2.0) de fecha 18 de abril de 2016 (en adelante denominada simplemente "SIMALLIANCE") especifica, en particular, la estructura de un perfil de comunicación durante una fase de carga en un terminal y la forma en que un módulo eUICC recupera a distancia dicho perfil y procede a su instalación.

La norma SIMALLIANCE prevé, en particular, que se envíe un perfil a un módulo eUICC bajo la forma de una pluralidad de elementos de perfil (denominados "Profile Elements" o PE en inglés). Estos elementos de perfil se definen en un lenguaje descriptivo (denominado ASN.1) que puede ser interpretado por el módulo eUICC, siendo este lenguaje definido, de manera conjunta, por la Organización Internacional de Normalización, la Comisión Electrotécnica Internacional y la Unión Internacional de Telecomunicaciones.

El primer elemento de perfil enviado al módulo eUICC durante la telecarga a distancia suele ser una cabecera de perfil (denominada PEH por "Profil Element Header’ en inglés). De conformidad con la norma SIMALLIANCE, esta cabecera de perfil contiene una cierta cantidad de información relacionada con el perfil correspondiente, en particular, una lista de los servicios de perfil que debe soportar el módulo eUICC receptor.

Aún de conformidad con la norma SIMALLIANCE, cada servicio en el perfil se especifica en la lista de servicios en la cabecera como obligatorio u opcional dependiendo del nivel de importancia del servicio descrito. Si un servicio de perfil se especifica como obligatorio en la cabecera, es imperativo que el módulo eUlCC destinatario del perfil admita el servicio en cuestión; de lo contrario, el módulo eUICC rechaza el perfil y el proceso de instalación es abandonado.

En consecuencia, existe actualmente un problema en el sentido de que una instalación de un perfil en un módulo eUICC puede fallar si dicho módulo eUICC no es capaz de poner en práctica ciertos servicios, en particular, servicios especificados como obligatorios en la cabecera de dicho perfil. El fallo en la instalación de un perfil es indeseable ya que se han solicitado recursos en vano y ni el operador ni el usuario del terminal pueden beneficiarse de un nuevo perfil cuando este último requiera la puesta en práctica de un servicio no soportado por el módulo eUICC. Lo que antecede da como resultado una falta de flexibilidad y un riesgo de obsolescencia prematura de los módulos eUICCs.

En la actualidad, ninguna solución satisfactoria permite superar los problemas mencionados con anterioridad y, de manera más general, gestionar de más eficientemente la instalación de un perfil de comunicación en un módulo de identidad de abonado integrado (o módulo eUICC).

El documento EP 3029968 A1 de fecha 8 de junio de 2016 describe un método para proporcionar un perfil de abonado en un módulo seguro. El método comprende recibir una solicitud de aprovisionamiento de un perfil de abonado acompañado de parámetros de un terminal móvil asociado al perfil de abonado, configurando el terminal cuando se recibe una notificación de activación del perfil, siendo la notificación desde el módulo seguro.

El documento titulado "Documento oficial no confidencial de la Asociación GSM SGP.02 - Arquitectura de aprovisionamiento a distancia de especificación técnica UICC integrada para Clasificación de Seguridad de Especificación Técnica de UICC: Suministro a distancia no confidencial de la Asociación GSM no confidencial" con fecha 27 de marzo de 2016, da a conocer un sistema que permite la actualización de perfiles de las tarjetas eUICCs.

OBJETO Y RESUMEN/SUMARIO DE LA INVENCIÓN

Con este fin, la presente invención se refiere a un primer método de control puesto en práctica por un módulo de identidad de abonado integrado (o módulo eUICC) capaz de cooperar con un terminal de comunicaciones, comprendiendo dicho módulo electrónico:

- la recepción de al menos un identificador de un servicio respectivo, de un perfil de comunicación, para ser puesto en práctica cuando dicho perfil de comunicación está instalado y en el estado activo en el módulo de identidad de abonado integrado;

- la determinación de si cada servicio está soportado por un sistema operativo del módulo de identidad de abonado integrado;

- si no es así, el envío de una solicitud para actualizar el sistema operativo;

- si se recibe una actualización del sistema operativo en respuesta a dicho envío, la instalación de dicha actualización que permite que el sistema operativo ponga en práctica al menos parcialmente dicho perfil de comunicación; y

- una vez finalizada dicha instalación, el envío de una solicitud para recibir o continuar recibiendo el perfil de comunicación, incluyendo dicho al menos un servicio (S), para ser instalado en dicho módulo de identidad de abonado integrado.

Cuando un módulo eUICC detecta que su sistema operativo no soporta al menos un servicio especificado en un perfil a instalar, la invención permite, de manera ventajosa, que dicho módulo eUICC obtenga la actualización necesaria para mitigar, al menos en parte, su incapacidad para poner en práctica dicho al menos un servicio no soportado. Una vez realizada la actualización, el módulo eUICC puede instalar el perfil para ofrecer, cuando el perfil en cuestión se encuentre en estado activo, el acceso a uno o más servicios asociados a dicho perfil.

Según una forma de realización particular, el método comprende, en respuesta a dicha solicitud de recibir o de continuar dicha recepción, una recepción de la totalidad o parte del perfil de comunicación con el fin de permitir la instalación del perfil en el módulo de identidad de abonado integrado.

Según una forma de realización particular, el método comprende la instalación del perfil de comunicación en el módulo de identidad de abonado integrado una vez obtenido dicho perfil en su totalidad.

Según una forma de realización particular, dicho perfil de comunicación autoriza, cuando se encuentra instalado y en estado activo en el módulo de identidad de abonado integrado, al terminal de comunicación comunicarse con una red de comunicación asociada a dicho perfil de comunicación.

Según otra forma de realización particular, el método comprende una comparación de las capacidades del sistema operativo con cada servicio (S) asociado con dicho al menos un identificador;

la determinación de si al menos uno de dichos servicios no está soportado por el sistema operativo se realiza a partir del resultado de dicha comparación.

Según otra forma de realización particular, la recepción de dicho al menos un identificador comprende la recepción de una primera parte del perfil de comunicación, comprendiendo dicha primera parte dicho al menos un identificador. Según otra forma de realización particular, la primera parte es una parte de cabecera del perfil de comunicación. Según otra forma de realización particular, el método comprende, una vez completada dicha instalación de la actualización, enviar dicha solicitud para continuar recibiendo el perfil de comunicación con el fin de recibir al menos una segunda parte del perfil de comunicación completando dicha primera parte para obtener el perfil de comunicación completo para ser instalado en el módulo de identidad de abonado integrado.

Según otra forma de realización particular, dicho al menos un identificador se recibe desde un servidor de suministro de perfil, comprendiendo el método, si al menos uno de dichos servicios no es soportado por el sistema operativo, el envío de una solicitud de puesta en espera al servidor de suministro de perfil con el fin de diferir la recepción de al menos parte del perfil de comunicación.

Según una forma de realización particular, al recibir dicho al menos un identificador, el método comprende:

- la recepción, en asociación con cada identificador de servicio, de un grado de importancia de dicho servicio, indicando dicho grado de importancia si el servicio correspondiente debe ser necesariamente soportado por el sistema operativo cuando el perfil de comunicación está instalado en el módulo identidad de abonado integrado. Según una forma de realización particular, el módulo de identidad de abonado integrado envía dicha solicitud para recibir o continuar recibiendo el perfil de comunicación solamente si el sistema operativo, una vez actualizado, soporta al menos cada servicio del perfil de comunicación indicado por el grado asociado de importancia que tiene que ser soportado de manera obligatoria por el sistema operativo.

Según una forma de realización particular, si el sistema operativo, una vez actualizado, no soporta al menos un servicio del perfil de comunicación indicado por el grado de importancia asociado como no necesariamente teniendo que ser soportado por el sistema operativo, el módulo de identidad del abonado integrado:

- procede a enviar dicha solicitud para recibir o continuar recibiendo el perfil de comunicación; y

- realiza un marcado del perfil de comunicación, una vez instalado dicho perfil en el módulo de identidad de abonado integrado, para indicar que al menos un servicio del perfil de comunicación, que no tiene que ser necesariamente soportado por dicho sistema operativo, no es soportado por dicho sistema operativo.

Según una forma de realización particular, el marcado comprende una modificación, en el perfil de comunicación instalado en el módulo de identidad de abonado integrado, de un parámetro para indicar que el módulo de identidad de abonado integrado está configurado para poner en práctica, de forma restringida, dicho al menos un servicio del perfil de comunicación.

Según una forma de realización particular, si el sistema operativo, una vez actualizado, no soporta al menos un servicio del perfil de comunicación indicado por el grado de importancia asociado como no necesariamente teniendo que ser soportado por el sistema operativo, el método comprende:

- enviar una notificación que indique que el módulo de identidad de abonado integrado está configurado para poner en práctica dicho al menos un servicio del perfil de comunicación de manera restringida.

Según una forma de realización particular, durante dicha recepción, dicho al menos un identificador y cada grado de importancia asociado se recibe en una cabecera de dicho perfil de comunicación, comprendiendo dicha cabecera además un parámetro,

en donde, una vez completada dicha instalación, el módulo de identidad de abonado integrado envía dicha solicitud para continuar recibiendo el perfil de comunicación solamente si el parámetro está en un estado predefinido.

En una forma de realización particular, las diversas etapas del primer método de control tal como se definió con anterioridad se determinan mediante instrucciones de programa informático.

En consecuencia, la invención también se refiere a un programa informático en un soporte de información, pudiendo este programa ser puesto en práctica en un módulo de identidad de abonado integrado, o más generalmente en un ordenador, incluyendo este programa instrucciones adaptadas a la puesta en práctica de las etapas del primer método de control tal como se definió con anterioridad.

La invención también se refiere a un medio de soporte de registro (o soporte de información) legible por un ordenador, y que comprende instrucciones de un programa informático tal como se mencionó con anterioridad.

De manera correlativa, la invención se refiere a un segundo método de control puesto en práctica por un servidor de suministro de perfil para proporcionar un perfil de comunicación a un módulo de identidad de abonado integrado que coopera con un terminal de comunicación, que comprende:

- el envío, a dicho módulo de identidad de abonado integrado, de al menos un identificador de un servicio respectivo, de un perfil de comunicación, para ser puesto en práctica cuando dicho perfil de comunicación esté instalado y en el estado activo en el módulo identidad de abonado integrado;

- puesta en espera del envío de al menos una parte del perfil de comunicación al módulo de identidad de abonado integrado;

- después de la actualización de dicho sistema operativo mediante el módulo de identidad de abonado integrado, la recepción de una solicitud para enviar o continuar enviando el perfil de comunicación, incluyendo dicho al menos un servicio; y

- en respuesta a dicha solicitud para enviar o continuar enviando el perfil de comunicación, el envío de la totalidad o parte del perfil de comunicación con el fin de permitir la instalación de dicho perfil en el módulo de identidad de abonado integrado.

En una forma de realización particular, las diversas etapas del segundo método de control tal como se definió con anterioridad están determinadas por las instrucciones del programa informático.

En consecuencia, la invención también se refiere a un programa informático en un soporte de información, pudiendo este programa ser puesto en práctica en un servidor, o más generalmente en un ordenador, comprendiendo este programa instrucciones adecuadas para la puesta en práctica de las etapas del segundo método de control tal como se definió con anterioridad.

La invención también se refiere a un medio de soporte de registro (o soporte de información) legible por ordenador y que comprende instrucciones de un programa informático tal como se mencionó con anterioridad.

Conviene señalar que los programas mencionados en la presente descripción pueden usar cualquier lenguaje de programación y tener la forma de código fuente, código objeto o código intermedio entre el código fuente y el código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.

Además, el medio de soporte de registro mencionado con anterioridad puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el medio puede comprender un medio de almacenamiento, tal como una memoria ROM, por ejemplo, un CD ROM o una memoria ROM de circuito microelectrónico, o también un medio de soporte de registro magnético, por ejemplo, un disquete (disco flexible) o un disco duro.

Por otro lado, el medio de soporte de registro puede corresponder a un medio transmisible tal como una señal eléctrica u óptica, que puede ser transportada a través de un cable eléctrico u óptico, por radio o por otros medios. El programa según la invención se puede descargar, en particular, desde una red de tipo Internet.

De manera alternativa, los medios de soporte de registro pueden corresponder a un circuito integrado en donde se incorpora el programa, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución del método en cuestión.

La invención también se refiere a un módulo de identidad de abonado integrado configurado para poner en práctica el primer método de control tal como se definió con anterioridad. Más concretamente, la invención se refiere a un módulo de identidad de abonado integrado (o módulo eUICC) capaz de cooperar con un terminal de comunicación, comprendiendo dicho módulo de identidad de abonado integrado:

- un módulo de recepción configurado para recibir al menos un identificador de un servicio respectivo, de un perfil de comunicación, para ser puesto en práctica cuando dicho perfil de comunicación está instalado y en estado activo en el módulo de identidad de abonado integrado;

- un módulo de determinación configurado para determinar si cada servicio es soportado por un sistema operativo del módulo de identidad de abonado integrado;

- un módulo de actualización configurado, si cada servicio no es soportado con dicho sistema operativo, para enviar una solicitud de actualización del sistema operativo,

estando configurado dicho módulo de actualización, si se recibe una actualización del sistema operativo en respuesta a dicha solicitud de actualización, para instalar dicha actualización permitiendo que el sistema operativo ponga en práctica al menos parcialmente dicho perfil de comunicación; y

- un módulo de envío configurado, después de completar dicha instalación de actualización, para enviar una solicitud para recibir o continuar recibiendo el perfil de comunicación, incluyendo dicho al menos un servicio, para ser instalado en dicho módulo de identidad de abonado integrado.

Conviene señalar que las diversas formas de realización mencionadas con anterioridad en relación con el primer método de control de la invención, así como las ventajas asociadas, se aplican de manera similar al módulo de identidad de abonado integrado de la invención.

La invención también se refiere a un servidor de suministro de perfil configurado para poner en práctica el segundo método de control tal como se define con anterioridad. Más concretamente, la invención se refiere a un servidor de suministro de perfil para proporcionar un perfil de comunicación a un módulo de identidad de abonado integrado que coopera con un terminal de comunicación, que comprende:

- un módulo de envío, a dicho módulo de identidad de abonado integrado, de al menos un identificador de un servicio respectivo, de un perfil de comunicación, para ser puesto en práctica cuando dicho perfil de comunicación esté instalado y en el estado activo en el módulo de identidad de abonado integrado;

- estando configurado el módulo de envío para poner en espera el envío de al menos parte del perfil de comunicación al módulo de identidad de abonado integrado;

- un módulo de recepción configurado, después de la actualización de dicho sistema operativo por el módulo de identidad de abonado integrado, para recibir una solicitud para enviar o continuar enviando el perfil de comunicación, incluyendo dicho al menos un servicio; y

- un módulo de envío configurado, en respuesta a dicha solicitud para enviar o continuar enviando el perfil de comunicación, para enviar la totalidad o parte del perfil de comunicación con el fin de permitir la instalación de dicho perfil en el módulo de identidad de abonado integrado.

Según una forma de realización, la invención se pone en práctica mediante componentes de software y/o de hardware. Desde esta perspectiva, el término “módulo” puede corresponder en este documento tanto a un componente de software, como a un componente de hardware o a un conjunto de componentes de hardware y software.

La invención también se refiere a un sistema que comprende un módulo de identidad de abonado integrado tal como se definió con anterioridad y un servidor de suministro de perfil para proporcionar un perfil de comunicación a dicho módulo de identidad de abonado integrado que coopera con un terminal comunicación, comprendiendo dicho servidor de suministro de perfil:

- un módulo de envío, a dicho módulo de identidad de abonado integrado, de al menos un identificador de un servicio respectivo, de un perfil de comunicación, para ser puesto en práctica cuando dicho perfil de comunicación esté instalado y en el estado activo en el módulo de identidad de abonado integrado;

- estando configurado el módulo de envío para poner en espera el envío de al menos parte del perfil de comunicación al módulo de identidad de abonado integrado; y

- un módulo de recepción configurado, después de la actualización de dicho sistema operativo por el módulo de identidad de abonado integrado, para recibir una solicitud para enviar o continuar enviando el perfil de comunicación, incluyendo dicho al menos un servicio; y configurándose el módulo de envío, en respuesta a dicha solicitud para enviar o continuar enviando el perfil de comunicación, para enviar la totalidad o parte del perfil de comunicación con el fin de permitir la instalación de dicho perfil en el módulo de identidad de abonado integrado.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Otras características y ventajas de la presente invención surgirán de la descripción que se da a continuación, con referencia a los dibujos adjuntos que ilustran formas de realización de la misma sin ningún carácter limitativo. En las figuras:

La Figura 1 representa, de manera esquemática, un módulo eUICC que coopera con un servidor de suministro de perfil y un servidor de actualización a través de un terminal, según una forma de realización particular de la invención;

La Figura 2 representa, de manera esquemática, una lista de capacidades de un módulo eUICC de la Figura 1, según una forma de realización particular de la invención;

La Figura 3 representa, de manera esquemática, un módulo eUlCC, según una forma de realización particular de la invención;

La Figura 4 representa, de manera esquemática, un servidor de suministro de perfil, según una forma de realización particular de la invención;

La Figura 5 representa, de manera esquemática, la estructura de un perfil de comunicación a instalar en un módulo eUICC, según una forma de realización particular de la invención;

La Figura 6 representa, bajo la forma de un diagrama, las etapas de un método de control puesto en práctica por un módulo eUICC y por un servidor de suministro de perfil, según una forma de realización particular de la invención; La Figura 7 representa, de manera esquemática, una lista de identificadores de servicio, según una forma de realización particular de la invención;

La Figura 8 representa, bajo la forma de un diagrama, las etapas de un método de control puesto en práctica por un módulo eUICC y por un servidor de suministro de perfil, según una forma de realización particular de la invención; La Figura 9 representa, de manera esquemática, una lista de identificadores de servicio, según una forma de realización particular de la invención;

La Figura 10 representa, en la forma de un diagrama, las etapas de un método de control puesto en práctica por un módulo eUICC y por un servidor de suministro de perfil, según una forma de realización particular de la invención; La Figura 11 representa, de manera esquemática, una lista de identificadores de servicio, según una forma de realización particular de la invención; y

La Figura 12 representa, en la forma de un diagrama, las etapas de un método de control puesto en práctica por un módulo eUICC y por un servidor de suministro de perfil, según una forma de realización particular de la invención. DESCRIPCIÓN DETALLADA DE DIVERSAS FORMAS DE REALIZACIÓN

La invención se propone preparar la instalación de un perfil de comunicación en un módulo eUICC ofreciendo a este último la posibilidad de actualizar su sistema operativo cuando uno o más servicios proporcionados por el perfil a instalar no son soportados con el sistema operativo del módulo eUICC en cuestión. La invención tiene como objetivo, además, instalar el perfil en cuestión una vez que se haya actualizado el sistema operativo del módulo eUICC destinatario.

La invención se refiere, en particular, a un método puesto en práctica por un módulo eUICC (y en el módulo eUICC en cuestión) con el fin de permitir dicha actualización cuando un perfil deba ser instalado en el módulo eUICC. La invención también se refiere a un método puesto en práctica por un servidor a distancia (y en el propio servidor) que coopera con el módulo eUICC para preparar la instalación de un perfil en el módulo eUICC.

En la presente descripción, por perfil "activo", o perfil en estado "activo", se entiende el hecho de que se activa un perfil de comunicación en un módulo eUICC con el fin de autorizar al terminal de comunicación (con el que coopera el módulo eUICC) para comunicarse con la red de comunicación asociada al perfil en cuestión. De conformidad con la norma GSMA SGP.02 v3.1 antes mencionada (en adelante, la norma "GSMA"), un perfil (o el campo seguro ISD-P en donde está contenido) se dice que está "activo" (ENABLE) cuando su parámetro de estado, denominado "ciclo de vida", se establece en el estado '3F'. Según esta misma norma GSMA, por el contrario, se dice que un perfil está "inactivo" (DISABLE) cuando su parámetro de estado de "ciclo de vida" se establece en el estado "1F".

En la presente descripción, el término "servicio" se entiende que significa cualquier servicio (o funcionalidad) especificado en un perfil de comunicación y capaz de ser puesto en práctica por un módulo eUICC cuando el perfil está instalado y en el estado activo en el módulo eUICC, siempre que este servicio sea soportado por el sistema operativo del módulo eUICC en cuestión.

A modo de ejemplo, se pueden citar los siguientes servicios que pueden ser puestos en práctica por un módulo eUICC, de conformidad con la norma SIMALLIANCE:

- servicio sin contacto (permite operaciones sin contacto);

- aplicación USIM según lo define 3GPP;

- aplicación ISIM según lo definido por 3GPP;

- algoritmo de autenticación AKA;

- TUAK128: algoritmo de autenticación TUAK AKA con una longitud de clave de 128 bits;

- cliente de UICC EAP;

- Javacard;

- múltiples USIM, lo que permite el soporte de varios USIM al mismo tiempo;

- etc.

En la presente descripción, el concepto de "sistema operativo" se entiende en sentido amplio e incluye cualquier módulo de software, bloque de software o programa informático ejecutable por el módulo eUICC para gestionar y poner en práctica uno o más perfiles de comunicación.

A menos que se indique lo contrario, los elementos comunes o similares a diversas figuras llevan los mismos signos de referencia y tienen características idénticas o similares, de modo que estos elementos comunes generalmente no se describen de nuevo en aras de la simplicidad.

La Figura 1 muestra, de manera esquemática, la estructura de un módulo eUICC (indicado aquí como eUICC1) configurado para cooperar con un terminal de comunicación T con el fin de permitir el acceso a una red de comunicación R. El módulo eUICC1 está, por ejemplo, soldado o integrado en el terminal T.

En el ejemplo aquí expuesto, la red de comunicación R es una red de telefonía móvil y el terminal T es un terminal de comunicación móvil, tal como, por ejemplo, un teléfono móvil. Sin embargo, son posibles otros ejemplos de redes de comunicación R y terminales de comunicación T dentro del marco de la invención.

En la forma de realización aquí descrita, el terminal móvil T puede utilizar el módulo eUICC1 para acceder de forma segura a la red R, así como a los servicios proporcionados por el operador telefónico respectivo MNO (por "Mobile Network Operatoí en inglés).

En esta forma de realización particular, el terminal móvil T comprende un sistema operativo OS2 capaz de controlar, en particular, una interfaz de radio INT. La interfaz de radio INT del terminal T está configurada para enviar y recibir comunicaciones de radio con el exterior a través de, por ejemplo, una antena (no ilustrada). Esta interfaz de radio INT comprende, por ejemplo, de manera conocida, una unidad de transmisor/receptor de radio acoplada a una antena (no ilustrada). También es posible prever la presencia en el terminal T de una pluralidad de interfaces de radio.

En la forma de realización aquí descrita, el módulo eUICC1 comprende un sistema operativo OS1 (almacenado en una memoria no volátil, una memoria de solamente lectura o memoria instantánea, por ejemplo) acoplado a una memoria MR no volátil regrabable.

El sistema operativo OS1 constituye un ejemplo de programa informático en el sentido de la invención, comprendiendo este programa instrucciones para la ejecución de las etapas de un método de control según una forma de realización particular de la invención. La memoria en donde se encuentra el sistema operativo OS1 constituye así un ejemplo de medio de soporte de registro en el sentido de la invención, legible por un procesador (no ilustrado) del módulo eUICC1. Tal como se muestra en la Figura 1, la memoria no volátil MR del módulo eUICC1 comprende, además, un campo de seguridad privilegiado ISD-R y dos campos de seguridad secundarias ISD-P, aquí indicados ISD-P1 e ISD-P2. Cada campo de seguridad ISD-P (o campo seguro) constituye un compartimento seguro del módulo eUICC1. Se entenderá que la forma de realización particular aquí descrita constituye solamente un ejemplo no limitativo de puesta en práctica de la invención, pudiendo adaptarse el número de campos ISD-P, en particular, según el caso de uso.

El campo de seguridad ISD-R tiene el privilegio de que, en particular, puede crear, eliminar, activar o desactivar campos de seguridad secundarias ISD-P en la memoria no volátil MR.

Cada campo de seguridad secundaria ISD-P puede contener un único perfil de comunicación P (o perfil operativo) asociado con un operador de telefonía MNO en particular. Por lo tanto, cada perfil P está contenido en un campo de seguridad ISD-P que le está dedicado. De manera conocida, un perfil de comunicación P comprende datos de abonado (por ejemplo, identificadores (IMSI, etc.), claves criptográficas, algoritmos (por ejemplo, autenticación), ...) y también puede incluir un sistema de archivos, aplicaciones, y/o reglas de ejecución predeterminadas. En el ejemplo aquí expuesto, los perfiles P se ajustan a la norma GSMA citada con anterioridad.

En el ejemplo ilustrado en la Figura 1, se supone que la memoria MR del módulo eUICC1 comprende dos campos de seguridad secundarias ISD-P1, ISD-P2, siendo cada campo de seguridad secundaria capaz de contener un perfil único P1, P2, respectivamente, cada uno en el estado activo o inactivo.

Cada uno de los perfiles P1, P2 está configurado para autorizar, cuando está activo, al terminal T a comunicarse de forma segura con una red móvil R de un operador de comunicaciones MNO asociado a dicho perfil. En aras de la simplicidad, se supondrá en este ejemplo que cada uno de los perfiles P1, P2 está asociado a la misma red de comunicación R asociada a un único operador MNO, tal como se muestra en la Figura 1.

Cada perfil P1, P2, específica, además, al menos un servicio S que puede ser puesto en práctica por el módulo eUICC1 cuando el perfil descrito está en el estado activo, siempre que el sistema operativo OS1 del módulo eUICC1 admita el servicio en cuestión. Cada perfil incluye, por ejemplo, datos de abonado requeridos por el operador MNO de la red de comunicación R para obtener acceso a los servicios requeridos. Por tanto, estos datos de abonado permiten al operador verificar (por ejemplo, utilizando una base de datos HLR) que el usuario se ha abonado efectivamente al servicio solicitado.

El sistema operativo OS1 del módulo eUICC1 está configurado para admitir al menos un servicio. Los ejemplos de servicios que probablemente sean soportados por el sistema operativo OS1 se definen en la norma SIMALLIANCE (por ejemplo, el servicio "sin contacto", USIM, ISIM, SIM, "Milenage", "Cave", EAP, GBA, "Javacard"...), sin embargo, son posibles otros tipos de servicio. La capacidad del sistema operativo OS1 para poner en práctica un servicio especificado en un perfil puede variar según el caso. En el ejemplo ilustrado en la Figura 1, la memoria MR del módulo eUICC1 contiene una lista TB de las capacidades del sistema operativo OS1 para poner en práctica servicios de perfil. A partir de esta lista TB, el módulo eUICC1 puede determinar si admite, o no, un servicio determinado.

La Figura 2 representa, de manera esquemática, el contenido de la lista TB según un ejemplo particular. En este ejemplo, la lista TB define cuatro capacidades distintas CAP1 - CAP4, denominadas colectivamente CAP. Conviene señalar que una CAP de capacidad caracteriza la capacidad del sistema operativo OS1 para poner en práctica un único servicio o varios servicios distintos según corresponda.

En el ejemplo que se muestra en la Figura 1, el módulo eUICC1 es además capaz de comunicarse, a través del terminal T (y, en particular, de su interfaz de radio INT), de manera segura con un servidor SV1 de suministro de perfil que, en este ejemplo, es un servidor SM-SR (por "Subscription Manager-Secure Routing" en inglés). En este ejemplo, el servidor SV1 pertenece a la red de comunicación R asociada a los perfiles P1, P2.

La comunicación entre el módulo eUICC1 y el terminal T se realiza, por ejemplo, a través de un enlace L conforme a la norma ISO 7816 (más concretamente de conformidad con la norma ISO 7816-3 e ISO 7816-4).

En el ejemplo aquí descrito, el servidor SM-SR pone en práctica un sistema operativo OS3 registrado en un soporte de información (no ilustrado).

El módulo eUICC1 está configurado para recibir, desde el servidor a distancia SV1, un nuevo perfil P y para instalar este último en un campo de seguridad secundaria ISD-P. El envío de un nuevo perfil P al módulo eUICC1 es controlado, por ejemplo, por el operador MNO (por ejemplo, a través del servidor SM-DP tal como se muestra en la Figura 1). Una vez que se ha recibido e instalado el nuevo perfil P en el módulo eUICC1, el campo de seguridad privilegiado ISD-R puede configurar el nuevo perfil P para que esté activo o inactivo según corresponda.

Tal como se explica con más detalle a continuación, el módulo eUICC1 también está configurado para recibir, antes de la telecarga del perfil P, una lista LT1 de al menos un identificador ID de un servicio respectivo S especificado en el perfil P a instalar. Esta lista LT1 permite al módulo eUICC1 determinar qué servicios S deben ser soportados con su sistema operativo OS1 para poner en práctica el perfil P una vez que este último ha sido instalado y en estado activo en el módulo eUICC1.

Además, el módulo eUICC1 está configurado para cooperar con un servidor a distancia SV2 para recuperar, en su caso, una actualización UPD del sistema operativo OS1 de dicho módulo eUICC1. En este caso se supone que el servidor SV2 es un servidor de actualización que pone en práctica un sistema operativo OS4 registrado en un soporte de información (no ilustrado).

El módulo eUICC1, el terminal T, el servidor de suministro de perfil SV1 y el servidor de actualización SV2 forman conjuntamente un sistema SY.

Conviene señalar que ciertos elementos generalmente presentes en un módulo eUICC, en un terminal de comunicación T o incluso en una red de comunicación R de un operador MNO se han omitido de manera intencional porque no son necesarios para la comprensión de la presente invención. Además, los expertos en esta técnica comprenderán que en el presente documento se describen ciertos elementos para facilitar la comprensión de la invención, aunque no son obligatorios ni están directamente implicados para la puesta en práctica de la invención. La estructura del sistema SY ilustrado en la Figura 1 constituye solamente un ejemplo no limitativo de puesta en práctica de la invención.

Tal como se representa en la Figura 3, el sistema operativo OS1 del módulo eUICC1 pone en práctica, en un ejemplo de forma de realización particular, un cierto número de módulos definidos tal como sigue: un módulo de recepción MD2, un módulo de determinación MD4, un módulo de actualización MD6, un módulo de envío MD8, un módulo de instalación de perfil MD10. Según un ejemplo particular, el sistema operativo OS1 también pone en práctica un módulo de marcado MD12.

El módulo de recepción MD2 está configurado para recibir al menos un identificador ID de un servicio S, de un perfil de comunicación P, para ser puesto en práctica cuando dicho perfil P esté instalado y en estado activo en el módulo eUICC1. En el ejemplo descrito en la Figura 1, el o los identificadores de ID de servicio son recibidos por el módulo de recepción MD2 en forma de lista LT1, transmitida por el servidor SV1 a través del terminal T. El módulo de recepción MD2 recibe, por ejemplo, dicho al menos un identificador ID en una cabecera (o parte de cabecera) del perfil P, tal como se explica con más detalle a continuación, siendo posibles sin embargo otros ejemplos de forma de realización.

El módulo de determinación MD4 está configurado para determinar si cada servicio S, especificado por el identificador o identificadores ID recibidos por el módulo de recepción MD2, está soportado por el sistema operativo OS1 del módulo eUICC1. Para ello, el módulo eUICC1 compara, por ejemplo, los identificadores ID recibidos por el módulo de recepción MD2 con las capacidades CAP definidas en la lista TB registrada en la memoria MR, y determina, a partir del resultado de esta comparación, si cada servicio S especificado por los identificadores de ID recibidos es soportado por el sistema operativo OS1.

El módulo de actualización MD6 se configura, en el caso de que el módulo de determinación MD4 detecte que al menos un servicio S no es soportado por el sistema operativo OS1, para enviar, al servidor de actualización de SV2, una solicitud para actualizar el sistema operativo OS1.

El módulo de actualización MD6 se configura, además, si se recibe una actualización UPD del sistema operativo OS1 en respuesta a dicha solicitud de actualización, para instalar la actualización de modo que permita el sistema operativo OS1 para poner en práctica (total, o al menos parcialmente) el perfil de comunicación P.

El módulo de envío MD8 se configura, una vez completada la instalación de la actualización UPD por el módulo de actualización MD6, para enviar una solicitud para recibir o continuar (en el caso particular donde parte del perfil ya ha sido recibido por el módulo eUICC1) la recepción del perfil de comunicación P, incluyendo (o especificando) dicho al menos un servicio S, para ser instalado en el módulo eUICC1. En el ejemplo ilustrado en la Figura 1, esta solicitud es enviada por el módulo de envío MD8 al servidor SV1.

El módulo de instalación del perfil MD10 se configura, atendiendo a la solicitud mencionada con anterioridad, para recibir o seguir recibiendo la totalidad o parte del perfil de comunicación P de manera que permita la instalación de dicho perfil P en el módulo eUICC1. Una vez que se ha recuperado todo el perfil P, el módulo de instalación MD10 se configura para instalar el perfil P en el módulo eUICC1.

El módulo de marcado MD12 permite, en su caso, marcar un perfil de comunicación P instalado en el módulo eUICC con el fin de indicar que el sistema operativo OS1 no admite al menos un servicio del perfil de comunicación siendo cada servicio no admitido opcional en el sentido de que no es obligatorio que el sistema operativo OS1 lo admita para que el perfil se ponga en práctica en el módulo eUICC1. Si se marca un servicio opcional de este tipo, el perfil P correspondiente solamente es soportado de manera parcial con el módulo eUICC1 pero, sin embargo, se puede poner en práctica dentro de los límites de los servicios de perfil soportados con el módulo eUICC1.

Se entenderá que la definición anterior de los módulos M2 a M12 constituye solamente una forma de realización no limitativa de la invención y solamente formas de realización, sin incluir al menos una entre estos módulos, son posibles dentro del alcance de la invención. Al menos dos de estos módulos pueden formar uno y el mismo módulo puesto en práctica en el módulo eUICC1.

Tal como se muestra en la Figura 4, el sistema operativo OS3 del servidor de suministro de perfil SV1 pone en práctica, en una forma de realización a modo de ejemplo particular, un cierto número de módulos definidos tal como sigue: un módulo de envío MD20, un módulo de recepción MD22 y un módulo de determinación MD24.

El módulo de envío MD20 está configurado para enviar, al módulo eUICC1, al menos un identificador ID de un servicio S, de un perfil de comunicación P, para ser puesto en práctica por el módulo eUICC1 cuando dicho perfil P es instalado y activado en el módulo eUICC1. El módulo de envío MD20, por ejemplo, transmite los identificadores ID al módulo eUICC1 en una cabecera (o parte de cabecera) del perfil P, tal como se explica con más detalle a continuación.

El módulo de envío MD20 está configurado, además, para poner en espera el envío de al menos parte del perfil de comunicación P al módulo eUICC1.

Más concretamente, en la forma de realización a modo de ejemplo aquí descrita, el módulo de recepción MD22 está configurado para recibir, si al menos un servicio no es soportado por el sistema operativo OS1, una solicitud para poner en espera procedente del módulo eUICC1 de modo que el servidor SV1 (y más en particular, el módulo de envío MD20) difiera el envío, o la continuación del envío (en el caso de que ya se haya enviado parte del perfil al módulo eUICC1), desde el perfil P al módulo eUICC1.

Una vez que el sistema operativo OS1 ha sido actualizado por el módulo eUICC1, el módulo receptor MD22 del servidor SV1 se configura para recibir, desde el módulo eUICC1, una solicitud que requiera el envío o la continuación del envío (en el caso en donde una parte del perfil haya sido ya enviada al módulo eUICC1) del perfil P.

El módulo de envío MD20 se configura, además, en respuesta a la solicitud antes mencionada para enviar o continuar enviando el perfil de comunicación P, para enviar la totalidad o parte del perfil P al módulo eUICC1 con el fin de permitir la instalación de dicho perfil P en el módulo eUICC1. Por tanto, la recepción de la solicitud de envío o de envío continuado pone fin a la espera del módulo de envío MD20.

En las formas de realización descritas a continuación, el módulo eUICC1 coopera, a través del terminal T, con el servidor de suministro de perfil SV1 y con el servidor de actualización SV2. Son posibles diversas puestas en práctica con el fin de permitir que el módulo eUICC1 interactúe con el exterior a través del terminal T en donde está integrado. El terminal T puede, por ejemplo, desempeñar simplemente la función de relé entre el módulo eUICC1 y el exterior (caso, por ejemplo, del protocolo "Consumer" según la norma SGP.22 [Especificación técnica RSP - Versión 1.1 - 9 de junio de 2016]). Según otro ejemplo, el terminal T puede participar en mayor medida en la cooperación entre el módulo eUICC1 y el exterior (caso, por ejemplo, del protocolo M2M para “Machine to Machine” según la norma SGP.02 [Remote Provisioning Architecture para la especificación técnica de UICC integrada - Versión 3.1 - 27 de mayo de 2016]). Excepto en un caso particular, la forma en que el terminal T forma la interfaz entre el módulo eUICC1 y el exterior no se describirá en detalle a continuación, ya que esto no es necesario para comprender la invención.

Además, en las formas de realización que siguen, el operador MNO controla la instalación en el módulo eUICC1 de un perfil de comunicación P1 tal como se ilustra en la Figura 5, según un ejemplo particular. El perfil de comunicación P1 puede comprender una pluralidad de elementos de perfil (PE), denominados PE1 a PEn, siendo n un número entero mayor o igual a 2. En este ejemplo, el primer elemento de perfil PE1 constituye la cabecera PEH de perfil P1. En los ejemplos de forma de realización siguientes, la cabecera de perfil PEH constituye una primera parte PR1 del perfil P1 y los elementos de perfil PE2 a PEn constituyen, en combinación, una segunda parte PR2 del perfil P1.

Tal como se ilustra en la Figura 5, la cabecera PEH del perfil P1 comprende una lista LT1 de al menos un identificador ID de un servicio asociado con dicho perfil P1. Se describirán con más detalle varios ejemplos de la lista LT1 con referencia a las Figuras 7, 9 y 11.

En un ejemplo particular, el perfil P1 ilustrado en la Figura 5 es, desde el punto de vista estructural, de conformidad con la norma GSMA antes mencionada.

En un ejemplo particular, durante las fases de carga e instalación en el módulo eUICC1, el perfil P1 representado en la Figura 5 tiene la forma de una descripción compacta según la norma SIMALLIANCE.

Una forma de realización particular de la invención, puesta en práctica por el módulo eUICC1, el servidor de suministro de perfil SV1 y el servidor de actualización SV2, se describen ahora con referencia a las Figuras 5, 6 y 7. Para este propósito, el módulo eUICC1 ejecuta el sistema operativo OS1 para poner en práctica un método de control según una forma de realización particular, y el servidor de suministro de perfil SV1 ejecuta el sistema operativo OS3 para poner en práctica un método de control según una forma de realización particular.

Se supone aquí inicialmente que el perfil de comunicación P1 no está presente en el campo de seguridad secundaria ISD-P1 del módulo eUICC1, y que el operador MNO asociado con el perfil P1 intenta instalar el perfil P1 en el módulo eUCC1 con el fin de permitir el acceso, en el terminal T, a al menos un servicio S asociado al perfil P1.

Tal como se muestra en la Figura 5, la cabecera de perfil PEH comprende una lista LT1 de al menos un identificador ID de un servicio respectivo S asociado con el perfil P1. Tal como se ilustra en la Figura 7, se supone, en este caso, que la lista LT1, denominada LT1a en este ejemplo de forma de realización, comprende dos identificadores ID1, ID2 (denominados de manera colectiva ID) correspondientes respectivamente a los servicios S1, S2 (denominados colectivamente S). Se entenderá que el número y la naturaleza de los servicios asociados con el perfil P1 pueden variar según el caso.

Tal como se muestra en la Figura 6, el servidor de suministro de perfil SV1 envía (A2), al módulo eUICC1, la lista LT1a de los identificadores ID1 e ID2 de los respectivos servicios S1 y S2, del perfil de comunicación P1, a ponerse en práctica cuando dicho perfil P1 esté instalado y en estado activo en el módulo eUICC1.

El módulo eUICC1 recibe entonces (C2) la lista LT1a que identifica los servicios S1, S2 del perfil P1 a ponerse en práctica por el módulo eUICC1 cuando dicho perfil P1 está instalado y en estado activo en el módulo eUICC1.

En el ejemplo aquí descrito, durante la etapa de envío A2, el servidor SV1 envía al módulo eUICC1 una primera parte PR1 del perfil P1, comprendiendo esta parte la lista LT1a de los identificadores ID1 e ID2. Tal como se ilustra en la Figura 5, en esta forma de realización a modo de ejemplo se supone que la primera parte PR1 constituye la cabecera PEH del perfil P1, aunque son posibles otras puestas en práctica. El módulo eUICC1 recibe así en C2 la primera parte PR1 (la cabecera PEH en este ejemplo) del perfil P1 que comprende la lista LT1 a.

Una vez que se ha enviado la primera parte PR1 (A2) al módulo eUICC1, el servidor SV1 se pone en modo espera (A9) hasta la etapa A14 descrita a continuación. En un ejemplo particular, después de enviar a A2 el ID de los identificadores, el servidor SV1 se pone en modo espera (A9) al recibir una solicitud para ponerse modo de espera (o de suspensión) enviada por el módulo eUICC1. Tal como se indica a continuación, esta puesta en espera A9 significa que el servidor SV1 (en este caso su módulo de envío MD20) difiere el envío al módulo eUICC1 de al menos parte del perfil P1, es decir, de la segunda parte PR2 en el presente caso.

Además, después de la recepción C2 de la primera parte PR1, el módulo eUICC1 determina (C4) si cada servicio S especificado en la lista LT1a recibida (es decir, los servicios S1 y S2 en este ejemplo) está soportado por el sistema operativo OS1 del módulo eUICC1.

En el caso de que cada servicio S (a saber, S1 y S2 en este ejemplo) sea soportado por el sistema operativo OS1, el método finaliza. En este caso, el módulo eUICC1 instala (C6) por ejemplo el perfil de comunicación P1 en el campo de seguridad secundaria ISD-P1, después de haber recibido todas las partes faltantes que constituyen el perfil.

Si, por otro lado, el módulo eUICC1 determina en C4 que al menos un servicio S identificado en la lista LT1a recibida en C2 no es soportado por el sistema operativo OS1, el módulo eUICC1 pasa a la etapa C8.

En C8, el módulo eUICC1 envía, al servidor de actualización SV2, una solicitud RQ1 para actualizar el sistema operativo OS1. El servidor SV2 recibe la solicitud de actualización RQ1 en B8. En un ejemplo particular, el módulo eUICC1 envía la solicitud de actualización RQ1 a una dirección de red predefinida, estando esta dirección preregistrada, por ejemplo, en la memoria del módulo eUICC1.

En respuesta a la solicitud RQ1, el servidor SV2 determina si una actualización UPD del sistema operativo OS1 está disponible y, si es así, envía (B10) la actualización UPD al módulo eUICC1.

Si dicha actualización UPD del sistema operativo OS1 está disponible, el módulo eUICC1 la recibe en C10, a continuación, procede a su instalación (C12) con el fin de permitir que el sistema operativo OS1 ponga en práctica al menos parcialmente el perfil de comunicación P1. En un ejemplo particular, la instalación C12 de la actualización UPD en el módulo eUICC1 permite que su sistema operativo OS1 soporte al menos un servicio S especificado en la lista LT1a que dicho sistema operativo OS1 no soportaba (C4) antes de dicha actualización de C12. En un ejemplo particular, la instalación C12 de la actualización UPD permite, en este caso, que el sistema operativo OS1 admita cada servicio S especificado en la lista LT 1 a recibida en C2.

Después de completar la instalación C12 de la actualización UPD, el módulo eUICC1 envía (C14), al servidor de suministro de perfil SV1, una solicitud RQ3 para continuar (es decir, reanudar) la recepción del perfil de comunicación P1 a instalar en dicho módulo eUICC1. Tal como se indicó con anterioridad, el módulo eUICC1 ya ha recibido en C2 la primera parte PR1 (es decir, la cabecera PEH en este ejemplo) del perfil P1, comprendiendo esta parte la lista LT 1 a. Actualizando el sistema operativo OS1, el módulo eUICC1 solicita (C14) al servidor SV1 la continuación de la recepción del perfil P1 con el fin de recibir la parte faltante del perfil P1, a saber, la segunda parte PR2 tal como se ilustra en Figura 5. El servidor SV1 recibe en A14 la solicitud RQ3 para continuar recibiendo el perfil P1 y, en respuesta a esta solicitud RQ3, finaliza su fase de espera A9 y envía (A16) al módulo eUICC1 la totalidad o parte del perfil P1 con el fin de permitir la instalación del perfil P1 en el módulo eUICC1. En el ejemplo aquí descrito, el módulo eUICC1 ya ha recibido en C2 una primera parte PR1 (la cabecera PEH en este ejemplo) del perfil P1. Según este ejemplo, el servidor de suministro de perfil SV1 envía en A16 la segunda parte PR2 (ilustrada en la Figura 5) del perfil P1 complementario a la primera parte PR1 recibida en C2, de modo que permita al módulo eUICC1 obtener la totalidad del perfil P1 para instalar. En un ejemplo particular, estas primera y segunda partes PR1, PR2 conjuntamente forman el perfil P1 en su totalidad (en este caso, la parte PR2 comprende los elementos de perfil PE2 a PEn del perfil P1 tal como se ilustra en la Figura 5).

A partir de las partes de perfil PR1 y PR2 recibidas respectivamente en C2 y C16, el módulo eUICC1 recupera así la totalidad del perfil P1. El módulo eUICC1 puede realizar cualquier procesamiento apropiado sobre los datos contenidos en las partes PR1 y PR2 para obtener el perfil P1 a instalar.

Durante una etapa de instalación C18, el módulo eUICC1 instala el perfil P1. En este ejemplo, el perfil P1 se instala en el campo de seguridad secundaria ISD-P1 del módulo eUICC1.

Una vez que se ha instalado el perfil de comunicación P1 (C18), el módulo eUICC1 (y más en particular su campo de seguridad privilegiado IDS-R) es capaz de conmutar el perfil P1 entre un estado activo y un estado inactivo. Cuando se configura en estado activo, el perfil P1 autoriza al terminal de comunicación T a comunicarse con la red de comunicación R asociada a dicho perfil P1 con el fin de, por ejemplo, acceder a los servicios S1, S2 especificados en el perfil P1. Tal como ya se ha indicado, el perfil P1 comprende, por ejemplo, datos de abonado que permiten identificar y/o autenticar al usuario abonado a los servicios S1, S2, con el operador MNO de la red R.

Se entenderá que son posibles otras variantes de forma de realización, en las que, en particular, el identificador o los identificadores ID recibidos por el módulo eUICC1 en C2 no están incluidos en una primera parte PR1 del perfil P1 (los identificadores ID se envían por ejemplo en cualquier mensaje independiente del perfil P1). En este caso, después de completar la instalación C12 de la actualización UPD, el módulo eUICC1 envía en C14, al servidor de suministro de perfil SV1, una solicitud RQ3 para recibir (y no continuar recibiendo) el perfil de comunicación P1 para instalar en el módulo eUICC1.

Cuando un módulo eUICC detecta que su sistema operativo no soporta al menos un servicio especificado en un perfil a instalar, la invención permite, de manera ventajosa, que dicho módulo eUICC obtenga la actualización necesaria para mitigar, al menos en parte, su incapacidad para poner en práctica dicho al menos un servicio no soportado. Una vez realizada la actualización, el módulo eUICC puede instalar el perfil para ofrecer, cuando el perfil en cuestión se encuentre en estado activo, el acceso a uno o más servicios asociados a dicho perfil.

Una forma de realización particular de la invención, puesta en práctica por el módulo eUICC1, el servidor de suministro de perfil SV1 y el servidor de actualización SV2 ilustrados en la Figura 1, se describe ahora con referencia a las Figuras 8 y 9. Para este propósito, el módulo eUICC1 ejecuta el sistema operativo OS1 para poner en práctica un método de control de conformidad con una forma de realización particular, y el servidor de suministro de perfil SV1 ejecuta el sistema operativo OS3 para poner en práctica un método de control según una forma de realización particular.

Se supone de nuevo que el perfil de comunicación P1 no está presente en el campo de seguridad secundaria ISD-P1 del módulo eUICC1, y que el operador MNO asociado con el perfil P1 intenta instalar el perfil P1 en el módulo eUCC1 con el fin de permitir el acceso, en el terminal T, a al menos un servicio asociado al perfil P1.

En este ejemplo, el perfil de comunicación P1 a instalar en el módulo eUICC1 se ilustra en la Figura 5, tal como ya se describió con anterioridad. La cabecera PEH del perfil P1 comprende, en este ejemplo, una lista LT1, esta vez denominada LT1b, tal como se representa en la Figura 9. En cuanto a la lista LT1a descrita con anterioridad, la lista LT1b ahora contenida en la cabecera PEH del perfil P1 comprende los identificadores ID1, ID2 (denominado colectivamente ID) de los servicios S1, S2 (denominados colectivamente S). La lista LT1b aquí contenida en la cabecera PEH comprende, además, en asociación con cada identificador de servicio ID1, ID2, un respectivo grado de importancia DG1, DG2 (denominado colectivamente DG) del servicio, indicando este grado de importancia DG si el servicio S correspondiente debe obligatoriamente ser soportado por el sistema operativo OS1 cuando el perfil de comunicación P1 está instalado en el módulo eUICC1.

Cada grado de importancia DG puede tomar, por ejemplo, uno de dos estados distintos, a saber: un primer estado que indica que el servicio asociado S debe ser soportado obligatoriamente por el sistema operativo OS1 cuando el perfil de comunicación P1 está instalado en el módulo eUICC1, y un segundo estado que indica que el servicio asociado S no tiene que ser soportado obligatoriamente por el sistema operativo OS1 cuando el perfil de comunicación P1 está instalado en el módulo eUICC1.

Tal como se representa en la Figura 8, el servidor de suministro de perfil SV1 envía (A2), al módulo eUICC1, la cabecera PEH del perfil P1, de la misma manera que en la etapa de envío A2 representada en la Figura 6. Tal como se indicó con anterioridad, la lista LT1b presente en la cabecera PEH del perfil P1 comprende los identificadores de servicio ID1, ID2, así como los grados de importancia asociados DG1, DG2. El número y la naturaleza de los servicios especificados en la lista LT1b pueden variar según el caso.

Se supone, en este ejemplo, que los servicios S1, S2 son servicios obligatorios en el sentido de que los grados de importancia asociados DG1, DG2 indican que estos servicios S1, S2 deben ser soportados obligatoriamente por el sistema operativo OS1 cuando el perfil de comunicación P1 está instalado en el módulo eUICC1.

El módulo eUICC1 recibe la cabecera PEH en C2, a continuación, determina (C4), tal como ya se describió con referencia a la Figura 6, si cada servicio S especificado en la lista LT1b recibida (es decir, los servicios S1 y S2 en este ejemplo) es soportado por el sistema operativo OS1 del módulo eUICC1.

Para ello, el módulo eUICC1 compara en este caso, durante la etapa de determinación C4, la capacidad o capacidades CAP del sistema operativo OS1 con cada servicio S especificado en la lista LT1 recibida en C2. Para este propósito, el módulo eUICC1 consulta su lista TB mostrada en la Figura 2 y compara sus capacidades CAP1 - CAP4 con los servicios S1, S2 correspondientes respectivamente a los identificadores ID1, ID2 contenidos en la lista LT1b.

En el caso de que los servicios S1 y S2 sean soportados con el sistema operativo OS1, el método finaliza. En este caso, el módulo eUICC1 instala (C6) por ejemplo el perfil de comunicación P1 en el campo de seguridad secundaria ISD-P1.

Si, por el contrario, el módulo eUICC1 determina en C4 que al menos uno de entre los servicios S1, S2 identificados en la lista LT1b no es soportado por el sistema operativo OS1, el método continúa en etapa C7.

En este ejemplo, se supone que el módulo eUICC1 detecta en C4 que el servicio S1 es soportado con OS1 pero que el servicio S2 no es soportado con OS1.

Tal como se representa en la Figura 8, el módulo eUICC1 envía en C7 una solicitud RQ2 para poner en modo espera (o solicitud de suspensión) al servidor de suministro de perfil SV1 con el fin de diferir la continuación de la recepción del perfil P1. El servidor SV1 recibe RQ2 en A7. Tal como ya se indicó con anterioridad, el módulo eUICC1 ya ha recibido en C2 una primera parte PR1 del perfil P1 a instalar, a saber, la cabecera PEH que contiene la lista LT1b en este ejemplo. El envío de la solicitud de puesta en espera RQ2 permite diferir el envío, por parte del servidor SV1, de la parte PR2 faltante del perfil P1 que comprende los elementos de perfil PE2 a PEn. En respuesta a esta solicitud RQ2, el servidor SV1 se pone en modo espera (A9), para darle al módulo eUICC1 el tiempo necesario para actualizar (si es posible) su sistema operativo OS1.

En C8, el módulo eUICC1 envía, al servidor de actualización SV2, una solicitud RQ1 para actualizar su sistema operativo OS1, tal como ya se describió con referencia a la Figura 6. El servidor SV2 recibe la solicitud RQ1 de actualización en B8. En este ejemplo, la solicitud RQ1 comprende una lista LT2 que incluye el identificador IDN del servicio o servicios S identificados en C4 como no soportados por el sistema operativo OS1. El servicio S2 no es soportado con OS1 en este ejemplo, por lo que la lista LT2 contiene el identificador ID2 como un identificador IDN del servicio no admitido.

En un ejemplo particular, el módulo eUICC1 envía en C8, al servidor de actualización SV2, la lista LT1. Dicho de otro modo, la lista LT2 enviada en C8 es entonces idéntica a la lista LT1 recibida en C2. La lista LT1 permite al servidor de actualizaciones SV2 determinar si hay una actualización útil disponible para el módulo eUICC1.

Tal como ya se describió con referencia a la Figura 6, en respuesta a la solicitud RQ1, el servidor SV2 determina si una actualización UPD del sistema operativo OS1 está disponible y, si es así, envía (B10) la actualización UPD al módulo eUICC1.

Si dicha actualización UPD del sistema operativo OS1 está disponible, el módulo eUICC1 procede a las etapas C10 y C12 tal como ya se describió con referencia a la Figura 6. Más en particular, el módulo eUICC1 recibe (C10) la actualización UPD y luego prosigue con su instalación (C12) con el fin de permitir que el sistema operativo OS1 ponga en práctica al menos parcialmente el perfil de comunicación P1.

Una vez realizada la actualización C12, el módulo eUICC1 determina (C20) si el sistema operativo OS1 soporta al menos cada servicio S del perfil de comunicación P1 indicado por el grado asociado de importancia DG como debiendo ser obligatoriamente soportado por el sistema operativo OS1. Dicho de otro modo, el módulo eUICC1 comprueba en C20 si el sistema operativo OS1, una vez actualizado en C12, es capaz de poner en práctica cada servicio obligatorio S especificado como tal en la lista LT1b. Si es así, el proceso continúa en C14. En caso contrario, el proceso finaliza (el módulo eUICC1, por ejemplo, notifica al servidor de suministro de perfil SV1 que abandona el proceso de instalación del perfil P1).

Se supone aquí que los servicios S1 y S2 son obligatorios y que, gracias a su actualización UPD, el sistema operativo OS1 ahora soporta los servicios S1, S2. En este caso, el módulo eUICC1 realiza las etapas C14, C16 y C18 y el servidor SV1 realiza las etapas A14, A16, tal como ya se describió con referencia a la Figura 6.

De este modo, el módulo eUICC1 envía en C14, al servidor de suministro de perfil SV1, una solicitud RQ3 para continuar (o reanudar) la recepción del perfil P1 a instalar en el módulo eUICC1. Tal como se indicó con anterioridad, el módulo eUICC1 ya ha recibido en C2 la primera parte PR1 (es decir, la cabecera PEH en este ejemplo) del perfil P1, comprendiendo esta parte la lista LT1 b. Con el sistema operativo OS1 actualizado y capaz de poner en práctica los servicios S1 y S2, el módulo eUICC1 solicita (C14) al servidor SV1 la continuación de la recepción del perfil P1 con el fin de recibir la parte PR2 faltante del perfil P1. El servidor SV1 recibe en A14 la solicitud RQ3 para continuar recibiendo el perfil P1 y, en respuesta a esta solicitud RQ3, envía (A16) al módulo eUICC1 la totalidad o parte del perfil P1 (es decir, la segunda parte PR2 en este ejemplo) con el fin de permitir la instalación del perfil P1 en el módulo eUICC1.

A partir de las partes de perfil PR1 y PR2 recibidas respectivamente en C2 y C16, el módulo eUICC1 recupera así la totalidad del perfil P1 e instala este último en el campo de seguridad secundaria ISD-P1 durante una etapa de instalación C18, tal como ya se describió con referencia a la Figura 6.

Una vez instalado el perfil de comunicación P1 (C18), el módulo eUICC1 (y más en particular su campo de seguridad privilegiado IDS-R) es capaz de conmutar el perfil P1 entre un estado activo y un estado inactivo, tal como también se describe con referencia a la Figura 6.

También se entenderá aquí que son posibles otras variantes de las formas de realización, en las que, en particular, el módulo eUICC1 no reciba en C2 los identificadores ID de servicio S en una primera parte PR1 del perfil P1 sino en cualquier otra forma adecuada (en cualquier mensaje independiente del perfil P1, por ejemplo). En este caso, el módulo eUICC1 envía en C14, al servidor de suministro de perfil SV1, una solicitud RQ3 para recibir (y no continuar recibiendo) el perfil de comunicación P1 para ser instalado en el módulo eUICC1.

La invención permite actualizar, si fuere necesario, el sistema operativo de un módulo eUICC antes de la instalación de un perfil de comunicación con el fin de asegurar que el perfil se pueda utilizar de la forma más eficiente posible por el módulo eUICC. La invención permite, en particular, asegurar que el módulo eUICC sea capaz de poner en práctica cada servicio obligatorio especificado en el perfil descrito antes de proceder a la instalación del perfil en el módulo eUICC en cuestión.

La invención también permite dotar al módulo eUICC de tiempo suficiente para actualizar su sistema operativo, cuando dicha actualización sea necesaria, antes de recibir la parte o partes faltantes del perfil a instalar. De manera ventajosa, el módulo eUICC puede eventualmente abandonar la telecarga del perfil en cuestión si detecta que ninguna actualización le permite soportar cada servicio obligatorio asociado a dicho perfil, ahorrando así recursos a nivel de red, del módulo eUICC1 y del servidor de suministro de perfil SV1.

Una forma de realización particular de la invención, puesta en práctica por el módulo eUICC1, el servidor de suministro de perfil SV1 y el servidor de actualización SV2, se describe a continuación con referencia a las Figuras 10 y 11. Para para ello, el módulo eUICC1 ejecuta el sistema operativo OS1 para poner en práctica un método de control de conformidad con una forma de realización particular, y el servidor de suministro de perfil SV1 ejecuta el sistema operativo OS3 para poner en práctica un método de control según una forma de realización particular.

Se supone de nuevo que el perfil de comunicación P1 no está presente en el campo de seguridad secundaria ISD-P1 del módulo eUICC1, y que el operador MNO asociado con el perfil P1 intenta instalar el perfil P1 en el módulo eUCC1 con el fin de permitir el acceso, en el terminal T, a al menos un servicio asociado al perfil P1.

En este ejemplo, el perfil de comunicación P1 a instalar en el módulo eUICC1 se ilustra en la Figura 5, tal como ya se describió con anterioridad. La cabecera PEH del perfil P1 comprende en este ejemplo una lista LT1, denominada esta vez LT 1 c, tal como se muestra en la Figura 11. Ahora se supone que la lista LT 1 c contenida en la cabecera PEH del perfil P1 comprende los identificadores ID1 a ID4 (denominados colectivamente ID) de los servicios respectivos S1 a S4 (denominados colectivamente S). La lista LT1c comprende, además, en asociación con cada identificador ID1 a ID4, un respectivo grado de importancia DG1 a DG4 (denominado colectivamente DG) tal como ya se describió con referencia a la Figura 9, indicando este grado de importancia DG si el servicio S correspondiente debe ser soportado obligatoriamente con el sistema operativo OS1 cuando el perfil de comunicación P1 está instalado en el módulo eUICC1.

Se supone en este ejemplo que los servicios S1, S2 se indican como servicios obligatorios por su grado de importancia DG1, DG2 asociado, y que los servicios S3, S4 se indican como servicios opcionales por su grado de importancia respectivo DG3, DG4.

En esta forma de realización a modo de ejemplo ilustrada en la Figura 10, el servidor SV1 realiza las etapas A2 a A9 y el módulo eUICC1 realiza las etapas C2 a C12 y C20, tal como se describió con anterioridad con referencia a la Figura 8. Se supone, por ejemplo, en este caso, que los servicios obligatorios S1, S2 no son soportados inicialmente (en C4) por el sistema operativo OS1 provocando así una actualización C12 del sistema operativo OS1 tal como ya se describió con referencia a la Figura 8.

Durante la etapa de determinación C20, el módulo eUICC1 determina si su sistema operativo OS1, ahora actualizado, soporta al menos cada servicio obligatorio S del perfil P1, es decir cada servicio (S1 y S2 en este ejemplo) indicado por el grado asociado de importancia DG que debe ser soportado de manera obligatoria por el sistema operativo OS1. Si es así, el proceso continúa en C30. En caso contrario, el proceso finaliza (el módulo eUICC1, por ejemplo, notifica al servidor de suministro de perfil SV1 que abandona el proceso de instalación del perfil P1).

Durante una etapa de determinación C30, el módulo eUICC1 determina si su sistema operativo OS1, ahora actualizado, también soporta cada servicio opcional S del perfil P1, es decir cada servicio (S3 y S4 en este ejemplo) indicado por el grado asociado de importancia DG que no necesariamente tiene que ser soportado por el sistema operativo OS1. Si es así, el proceso se reanuda en C14 tal como ya se describió con referencia a la Figura 8. De lo contrario, el proceso continúa en C32.

Conviene señalar que las etapas C20 y C30 pueden realizarse una tras otra, o de manera simultánea por el módulo eUICC1.

En este ejemplo, se supone que el módulo eUICC1 determina en C30 que el servicio opcional S3 está soportado por el sistema operativo OS1 pero que el servicio opcional S4 no está soportado por el sistema operativo OS1.

En esta etapa, son posibles diversas puestas en práctica de la invención. En el ejemplo aquí expuesto, el módulo eUICC1 determina en C32 si se ha recibido un parámetro PR en la cabecera PEH durante la etapa de recepción C2, indicando este parámetro si el módulo eUICC1 está autorizado (o debe) poner en práctica el servicio o servicios S del perfil P1 de manera restringida. Se entiende, en este caso, por utilización (o puesta en práctica) restringida el hecho de que, cuando el perfil se encuentra en estado activo, el módulo eUICC1 solamente pone en práctica parcialmente dicho perfil en el sentido de que al menos un servicio opcional de dicho perfil no es soportado con el módulo eUICC. En el caso de uso restringido de un perfil (o más precisamente de los servicios del perfil), el módulo eUICC1 opera en modo MD2 denominado “uso restringido”.

En la forma de realización aquí descrita, el servidor SV1 envía, por ejemplo, en A2 la primera parte PR1 (en este caso la cabecera PEH) que incluye el parámetro PR. Para ello, un servidor SM-DP (tal como se muestra en la Figura 1), por ejemplo, inserta este parámetro PR de antemano en la primera parte PR1 del perfil P1 durante una fase de preparación o personalización (creación del perfil, etc.). El parámetro PR lo inserta, por ejemplo, por el servidor SM-DP en las reglas de ejecución (o "Policy Rules" en inglés) presentes en el perfil P1. Estas reglas cumplen con la norma, por ejemplo. El servidor SM-DP a continuación transmite la totalidad o parte del perfil P1 al servidor SV1, para enviar (A2) al módulo eUICC1 de la primera parte PR1 con el parámetro PR.

Dependiendo de cómo esté configurado, el servidor SV1 (cooperando con el servidor SM-DP tal como se indicó con anterioridad) puede indicar utilizando este parámetro PR que el módulo eUICC1 está autorizado a, o debe, ser configurado en modo de uso restringido cuando al menos un servicio opcional no sea soportado.

Si el módulo eUICC1 determina en C32 que el parámetro PR se ha recibido efectivamente en la cabecera PEH durante la etapa de recepción C2, el método continúa en C34. De lo contrario, el módulo eUICC1 envía un mensaje MSG1 preguntando al servidor SV1 si está autorizado (o si debe) operar en modo MD2 de uso restringido. En un ejemplo particular, el mensaje MSG1 comprende, además, una lista LT3 que incluye el identificador IDN2 del servicio o servicios opcionales S del perfil P1 que el sistema operativo OS1 no soporta. Según un ejemplo particular, el mensaje MSG1 comprende un identificador del perfil P1 a instalar y a poner en práctica en el módulo eUICC1.

En respuesta al mensaje MSG1 recibido en A32, el servidor de suministro de perfil SV1 determina (DE) si el módulo eUICC1 está autorizado para (o debe) poner en práctica el perfil P1 de conformidad con el modo de uso restringido MD2. Esta determinación A34 puede realizarse de manera eventual en función de la lista LT3 y/o del identificador del perfil P1 si estos elementos están presentes en el mensaje MSG1. El operador del servidor SV1 puede indicar, así, a distancia, a cada módulo eUICC si el modo MD2 de uso restringido puede (o debe) aplicarse.

Si determina en A34 que el modo MD2 de uso restringido está autorizado (o es requerido), el servidor SV1 envía (A36) en respuesta un segundo mensaje MSG2 indicando que el módulo eUICC1 está autorizado para (o debe) poner en práctica de forma restringida (modo MD2) los servicios S del perfil P1.

El módulo eUICC1 recibe el mensaje MSG2 en C36 y determina (C38), a partir del mensaje MSG2 del servidor SV1, si debe poner en práctica el perfil P1 en modo MD2 de uso restringido. Si no es así, el proceso finaliza. De lo contrario (modo MD2 autorizado/requerido), el método continúa en la etapa C18 durante la cual el módulo eUICC1 instala el perfil P1 tal como se describió con anterioridad. Para ello, el módulo eUICC1 realiza, por ejemplo, las etapas C14 y C16 (no representadas en la Figura 10) tal como ya se ha descrito con referencia a las Figuras 6 y 8 con el fin de recibir la parte PR2 faltante del perfil P1. De manera alternativa, el módulo eUICC1 recibe la parte PR2 del perfil P1 en respuesta al mensaje MSG1, sin que sea necesario el envío de una solicitud específica por parte del módulo eUICC1.

Si, además, el módulo eUICC1 determina en C32 que el parámetro PR ha sido efectivamente recibido en la cabecera PEH durante la etapa de recepción C2, el método continúa en C34. Durante la etapa de determinación C34, el módulo eUICC1 determina, a partir del parámetro PR recibido previamente, si debe poner en práctica el perfil P1 en modo MD2 de uso restringido. Si no es así, el proceso finaliza. De lo contrario (modo MD2 autorizado/requerido), el método continúa en la etapa C18 tal como ya se indicó con anterioridad.

En un ejemplo particular, el módulo eUICC1 determina en C34 que debe poner en práctica el perfil P1 en modo MD2 de uso restringido solamente si el parámetro PR recibido en C2 está en un estado predefinido. El parámetro PR puede definirse por ejemplo mediante un bit codificado en la cabecera PEH recibido en C2, activando, o no, este bit el paso del módulo eUICC1 en el modo MD2 de uso restringido según el valor que se le haya asignado.

Una vez completada la etapa de instalación C18, se configura el módulo eUICC1, cuando este perfil P1 se encuentra en estado activo, para poner en práctica parcialmente (en modo MD2 de uso restringido) los servicios S del perfil P1 (en este ejemplo, solamente se pone en práctica los servicios S1, S2 y S3).

El módulo eUICC1 envía opcionalmente al servidor SV1 una notificación indicando que dicho módulo eUICC1 está configurado para poner en práctica los servicios S del perfil P1 de forma restringida (modo MD2).

La invención permite así que un módulo eUICC ponga en práctica parcialmente un perfil de comunicación cuando al menos un servicio opcional del perfil no es soportado por el sistema operativo del módulo eUICC, en la medida en que una dicha puesta en práctica parcial está autorizada o requerida por el operador MNO asociado.

En una forma de realización particular, tras la instalación C18 del perfil P1, el módulo eUICC1 realiza (C40) un marcado del perfil de comunicación P1 para indicar que al menos un servicio opcional S del perfil P1 (es decir, el servicio S4 en este ejemplo) no es soportado por el sistema operativo OS1. Este marcado permite indicar a un tercero que el módulo eUICC1, y por tanto el terminal T, pone en práctica el perfil P1 en modo MD2 de uso restringido. El terminal T se configura, por ejemplo, a partir de este marcado, para proporcionar una notificación a un usuario para indicarle que el perfil P1 se utiliza de forma restringida (modo MD2).

En un ejemplo particular, durante la etapa de marcado C40, el módulo eUICC1 modifica (o asigna un valor a), en el perfil de comunicación P1 instalado en dicho módulo eUICC1, un parámetro para indicar que está configurado para poner en práctica los servicios S del perfil P1 de manera restringida. En un ejemplo particular, esta modificación se realiza en un registro, asociado al perfil P1. Este registro está contenido, por ejemplo, en el campo de seguridad secundaria ISD-P1, o en el campo de seguridad privilegiado ISD-R del módulo eUICC1, o más generalmente en una memoria del módulo eUICC1.

En una variante del ejemplo descrito con anterioridad con referencia a la Figura 10, en respuesta a la solicitud RQ1 de actualización del sistema operativo OS1, el módulo eUICC1 recibe una notificación del servidor de actualización SV2 que indica los servicios no admitidos por el sistema operativo OS1 que serían admitidos si la actualización UPD disponible se instalara en el módulo eUICC1. El módulo eUICC1 puede así determinar, a partir de esta notificación, si se requiere el funcionamiento en el modo MD2 de uso restringido incluso antes de actualizar el sistema operativo. En un ejemplo particular, si se requiere el funcionamiento en modo MD2, el módulo eUICC1 determina, antes de actualizar el sistema operativo OS1, si el servidor SV1 autoriza (o solicita) el funcionamiento en modo MD2 de uso restringido, como, por ejemplo, se describió con anterioridad con referencia a las etapas C32-C38. De esta manera, en particular, es posible evitar una actualización del sistema operativo del módulo eUICC si dicha actualización no permite que el módulo eUICC ponga en práctica posteriormente el perfil de comunicación a instalar, lo que permite economizar recursos en la red.

También debe tenerse en cuenta que en el caso de que el módulo eUICC1 ponga en práctica el perfil P1 según el modo MD2 de uso restringido, el módulo eUICC1 puede llevar a cabo una actualización posterior del sistema operativo OS1 para para reducir el número de servicios opcionales no admitidos o, en su caso, para que cada servicio opcional del perfil P1 sea admitido por el módulo eUICC1. En este último caso, el módulo eUICC1 puede operar en modo MD1 de utilización no restringida (normal) de manera que cada servicio obligatorio y opcional del perfil P1 se pone en práctica cuando este último se encuentra en estado activo en el módulo eUICC1.

Conviene señalar a continuación una forma de realización particular según la cual el método descrito con referencia a la Figura 10 prosigue en la Figura 12. Se supone en este caso que el módulo eUICC1 pone en práctica el perfil P1 de manera restringida ya que su sistema operativo OS1 no admite el servicio opcional S4 del perfil P1.

Más en particular, después de un intervalo de tiempo determinado, el módulo eUICC1 envía (C50) una nueva solicitud RQ4 para actualizar su sistema operativo OS1. En respuesta a esta solicitud RQ4 recibida en B50, el servidor SV2 envía (B52) una actualización UPD2 del sistema operativo OS1 que el módulo eUICC1 recibe en C52. Las etapas C50-C52 y B50-B52 se llevan a cabo, por ejemplo, de forma idéntica a las etapas C8-C10 y B8-B10 descritas con anterioridad con referencia a las Figuras 6, 8 y 10.

Si se recibe realmente una actualización UPD2 en C52, el módulo eUICC1 instala (C54) esta actualización de la misma manera que en la etapa de actualización C12 descrita con anterioridad, y luego determina (C56) si cada servicio S opcional del perfil P1 es ahora soportado por el sistema operativo OS1 (de la misma manera que en la etapa C30 descrita con anterioridad). Si este es el caso, el proceso continúa en C58. De lo contrario, el proceso finaliza.

En C58, el módulo eUICC1 se configura en modo MD1 de uso no restringido del perfil P1 y, de manera opcional, modifica el marcado (o elimina el marcado) del perfil P1 realizado con anterioridad en C40 (Figura 10) para indicar que cada servicio opcional S del perfil P1 (es decir, los servicios S3, S4 en este ejemplo) está soportado por el sistema operativo OS1.

El módulo eUICC1 envía (C60) una notificación MSG3 al servidor de suministro de perfil SV1 para indicarle que ahora está operando en modo MD1 de uso no restringido con respecto al perfil P1. Después de esta notificación MSG3 recibida en A60, el servidor SV1 envía (A62) posiblemente un mensaje de confirmación MSG4, recibido por el módulo eUICC1 en C62.

Claims (18)

REIVINDICACIONES

1. Método de control puesto en práctica por un módulo de identidad de abonado integrado (eUICC1) capaz de cooperar con un terminal de comunicación (T), comprendiendo dicho método:

- la recepción (C2) de al menos un identificador (ID) de un servicio respectivo, de un perfil de comunicación (P), a poner en práctica cuando dicho perfil de comunicación esté instalado y en estado activo en el módulo de identidad de abonado integrado;

estando el método caracterizado porque comprende, además:

- la determinación (C4) de si cada servicio (S) está soportado por un sistema operativo (OS1) del módulo de identidad de abonado integrado;

- en caso contrario, el envío (C8) de una solicitud para actualizar el sistema operativo;

- si se recibe una actualización (UPD) del sistema operativo (C10) en respuesta a dicho envío (C8), la instalación (C12) de dicha actualización permite al sistema operativo poner en práctica al menos parcialmente dicho perfil de comunicación (P); y

- tras la finalización de dicha instalación, el envío (C14) de una solicitud para recibir o continuar recibiendo el perfil de comunicación (P), incluyendo dicho al menos un servicio (S), para ser instalado en dicho módulo de identidad de abonado integrado.

2. Método según la reivindicación 1, que comprende, en respuesta a dicha solicitud para recibir o continuar dicha recepción, una recepción (C16) de la totalidad o parte del perfil de comunicación con el fin de permitir la instalación del perfil en el módulo de identidad de abonado integrado.

3. Método según la reivindicación 1 o 2, que comprende la instalación (C18) del perfil de comunicación (P) en el módulo de identidad de abonado integrado una vez obtenido dicho perfil en su totalidad.

4. Método según cualquiera de las reivindicaciones 1 a 3, autorizando dicho perfil de comunicación, cuando está instalado y en estado activo en el módulo de identidad de abonado integrado, al terminal de comunicación para comunicarse con una red de comunicación (R) asociada a dicho perfil de comunicación.

5. Método según cualquiera de las reivindicaciones 1 a 4, en donde el método comprende una comparación de las capacidades del sistema operativo con cada servicio (S) asociado con dicho al menos un identificador (ID);

la determinación de si al menos dicho servicio (S) no está soportado por el sistema operativo se lleva a cabo a partir del resultado de dicha comparación.

6. Método según cualquiera de las reivindicaciones 1 a 5, en donde la recepción de dicho al menos un identificador comprende la recepción de una primera parte del perfil de comunicación, incluyendo dicha primera parte dicho al menos un identificador.

7. Método según la reivindicación 6, siendo la primera parte una parte de cabecera del perfil de comunicación.

8. Método según la reivindicación 6 o 7, comprendiendo el método, una vez completada dicha instalación de la actualización, el envío de dicha solicitud para continuar recibiendo el perfil de comunicación (P1) con el fin de recibir al menos una segunda parte (PR2) del perfil de comunicación que completa dicha primera parte (PR1) para obtener la totalidad del perfil de comunicación completo (P1) a instalar en el módulo de identidad de abonado integrado.

9. Método según cualquiera de las reivindicaciones 1 a 8, en donde dicho al menos un identificador (ID) se recibe desde un servidor de suministro de perfil (SV1), comprendiendo el método, si al menos uno de dichos servicios (S) no es soportado por el sistema operativo (OS1), el envío (C7) de una solicitud (RQ2) para poner en espera al servidor de suministro de perfil con el fin de diferir la recepción de al menos una parte (PR2) del perfil de comunicación.

10. Método según cualquiera de las reivindicaciones 1 a 9, en donde, durante la recepción de dicho al menos un identificador, el método comprende:

- la recepción (C2), en asociación con cada identificador de servicio (ID), de un grado de importancia (DG) de dicho servicio, indicando dicho grado de importancia si el servicio correspondiente debe ser obligatoriamente soportado por el sistema operativo (OS1) cuando el perfil de comunicación está instalado en el módulo de identidad del abonado integrado.

11. Método según la reivindicación 10, en donde el módulo de identidad de abonado integrado envía (C14) dicha solicitud (RQ3) para recibir o continuar recibiendo el perfil de comunicación (P1) solamente si el sistema operativo (OS1), una vez actualizado, soporta al menos cada servicio (S1, S2) del perfil de comunicación indicado por el grado de importancia (DG1, DG2) asociado al tener que ser soportado de manera obligatoria por el sistema operativo.

12. Método según la reivindicación 10 u 11, en donde si el sistema operativo (OS1), una vez actualizado, no soporta al menos un servicio (S4) del perfil de comunicación indicado por el grado de importancia asociado (DG4) como no debiendo obligatoriamente ser soportado por el sistema operativo, el módulo de identidad de abonado integrado: - procede al envío (C14) de dicha solicitud para recibir o continuar recibiendo el perfil de comunicación (P1); y - realiza (C40) un marcado del perfil de comunicación (P1), una vez instalado dicho perfil en el módulo de identidad de abonado integrado, para indicar que al menos un servicio (S4) del perfil de comunicación, que no debe ser obligatoriamente soportado por dicho sistema operativo, no es soportado por dicho sistema operativo.

13. Método según la reivindicación 12, en donde el marcado (C40) comprende una modificación, en el perfil de comunicación (P1) instalado en el módulo de identidad de abonado integrado, de un parámetro para indicar que el módulo de identidad el abonado integrado está configurado para poner en práctica, de manera restringida, dicho al menos un servicio del perfil de comunicación.

14. Método según cualquiera de las reivindicaciones 10 a 13, en donde si el sistema operativo (OS1), una vez actualizado, no soporta al menos un servicio (S4) del perfil de comunicación (P1) indicado por el grado de importancia asociado (DG4) como no debiendo ser obligatoriamente soportado por el sistema operativo, el método comprende: - el envío de una notificación que indique que el módulo de identidad de abonado integrado está configurado para poner en práctica dicho al menos un servicio del perfil de comunicación de manera restringida.

15. Método según cualquiera de las reivindicaciones 10 a 14, en donde, durante dicha recepción (C2), dicho al menos un identificador (ID) y cada grado de importancia asociado (DG) se recibe en una cabecera (PR1) de dicho perfil de comunicación (P1), comprendiendo, además, dicha cabecera un parámetro (PR),

en donde, una vez completada dicha instalación (C12) de la actualización, el módulo de identidad de abonado integrado (eUICC1) envía (C14) dicha solicitud para continuar recibiendo el perfil de comunicación (P) solamente si el parámetro (PR) está en un estado predefinido.

16. Programa informático (OS1; OS3) que comprende instrucciones para ejecutar las etapas de un método de control según cualquiera de las reivindicaciones 1 a 15 cuando dicho programa es ejecutado por un ordenador.

17. Módulo de identidad de abonado integrado capaz de cooperar con un terminal de comunicación (T), comprendiendo dicho módulo de identidad de abonado integrado:

- un módulo de recepción (MD2) configurado para recibir al menos un identificador (ID) de un servicio respectivo, de un perfil de comunicación (P), para ser puesto en práctica cuando dicho perfil de comunicación esté instalado y en el estado activo en el módulo de identidad de abonado integrado;

estando el módulo de identidad de abonado integrado caracterizado porque comprende, además:

- un módulo de determinación (MD4) configurado para determinar si cada servicio es soportado por un sistema operativo (OS1) del módulo de identidad de abonado integrado;

- un módulo de actualización (MD6) configurado, si cada servicio no es soportado por dicho sistema operativo, para enviar una solicitud de actualización del sistema operativo,

estando configurado dicho módulo de actualización (MD6), si se recibe una actualización (UPD) del sistema operativo en respuesta a dicha solicitud de actualización, para instalar dicha actualización que permite al sistema operativo poner en práctica al menos parcialmente dicho perfil de comunicación (P); y

- un módulo de envío (MD8) configurado, después de la finalización de dicha instalación de actualización, para enviar una solicitud para recibir o continuar recibiendo el perfil de comunicación (P), incluyendo dicho al menos un servicio (S), para instalar en dicho módulo de identidad de abonado integrado.

18. Sistema (SY) caracterizado porque comprende un módulo de identidad de abonado integrado según la reivindicación 17 y un servidor de suministro de perfil para proporcionar un perfil de comunicación a dicho módulo de identidad de abonado integrado que coopera con un terminal de comunicación,

Comprendiendo dicho servidor de suministro de perfil:

- un módulo de envío, a dicho módulo de identidad de abonado integrado, de al menos un identificador de un servicio respectivo, de un perfil de comunicación, para ser puesto en práctica cuando dicho perfil de comunicación esté instalado y en el estado activo en el módulo de identidad de abonado integrado;

estando configurado el módulo de envío para poner en espera el envío de al menos una parte del perfil de comunicación al módulo de identidad de abonado integrado; y

- un módulo de recepción configurado, después de la actualización de dicho sistema operativo por el módulo de identidad de abonado integrado, para recibir una solicitud para enviar o continuar enviando el perfil de comunicación, incluyendo dicho al menos un servicio; y

estando configurado el módulo de envío, en respuesta a dicha solicitud de envío o continuación de envío del perfil de comunicación, para enviar la totalidad o parte del perfil de comunicación con el fin de permitir la instalación de dicho perfil en el módulo de identidad de abonado integrado.