IT201600069354A1

IT201600069354A1 - Procedimento per effettuare una gestione remota di un modulo sim a sottoscrizione multipla, e corrispondente modulo sim e prodotto informatico

Info

Publication number: IT201600069354A1
Application number: IT102016000069354A
Authority: IT
Inventors: Amedeo Veneroso
Original assignee: St Microelectronics Srl
Priority date: 2016-07-04
Filing date: 2016-07-04
Publication date: 2018-01-04
Also published as: EP3267699A1; EP3267699B1; US9820139B1; US10231118B2; US20180027407A1; US20180295501A1; US10003956B2

Description

“Procedimento per effettuare una gestione remota di un modulo SIM a sottoscrizione multipla, e corrispondente modulo SIM e prodotto informatico”

TESTO DELLA DESCRIZIONE

Campo Tecnico

Le forme di attuazione della presente descrizione sono relative a soluzioni per effettuare una gestione di un modulo SIM a sottoscrizione multipla, detto modulo SIM a sottoscrizione multipla comprendendo almeno una memoria atta a memorizzare almeno un primo e un secondo profilo associati a un primo e a un secondo operatore di rete mobile rispettivi, detta memoria comprendendo una porzione volatile, detta operazione di memorizzare comprendendo di installare o di aggiornare i profili scaricando uno o più profili scaricati da un host remoto, detta gestione comprendendo di selezionare uno o più profili abilitati (Ps) comprendenti un’applicazione da eseguire e di allocare una partizione della porzione volatile della memoria a detti uno o più profili abilitati.

Le forme di attuazione della presente descrizione sono relative in particolare al contesto tecnico della tecnologia di Approvvigionamento di SIM Remoto (“Remote SIM Provisioning”), nota anche come la UICC (Universal Integrated Circuit Card) Embedded.

Sfondo

A causa dei nuovi requisiti di miniaturizzazione e di robustezza, l’industria ha sviluppato un’evoluzione delle schede SIM (“Subscriber Identity Module”, Modulo di Identità di Abbonato) tradizionali, chiamata “UICC embedded” (Universal Integrated Circuit Card). Questa evoluzione prevede che la scheda SIM sia saldata (o in ogni caso resa difficilmente accessibile) nel dispositivo di hosting che può essere un telefono cellulare, un modem, una scheda inserita in un dispositivo, ecc.

La saldatura presenta distinti vantaggi, quali la possibilità di ridurre la dimensione del dispositivo SIM e quindi del modem, il miglioramento della robustezza dei contatti (i contatti saldati sono tipicamente più affidabili delle interfacce tra componenti sostituibili), la maggiore protezione contro i furti.

D’altra parte, saldare una SIM (o renderla difficilmente accessibile) introduce nuovi requisiti e problemi che è necessario affrontare, quali:

- siccome la SIM non è sostituibile, dovrebbero essere disponibili mezzi per consentire di cambiare operatore;

- specifiche operazioni (come una riparazione del dispositivo), che oggi sono tipicamente effettuate dopo la rimozione della SIM, richiedono un modo per disabilitare la scheda SIM.

Per occuparsi dei requisiti precedenti, l’industria ha definito una nuova norma tecnologica chiamata “UICC embedded” o “Approvvigionamento di SIM remoto”.

I concetti di base della nuova norma tecnologica sono i seguenti:

- è definita una entità per consentire di scaricare/abilitare/cancellare i profili (per esempio, l’Issuer Secure Domain Root ISD-R, si veda per esempio “Remote Provisioning Architecture for Embedded UICC, Technical Specification, Version 1.0, 17 December 2013”) - la UICC può contenere varie sottoscrizioni di operatore di rete mobile;

- ciascuna sottoscrizione di operatore è rappresentata da un “profilo”;

- ogni profilo può essere visto come un contenitore (“container”); il contenitore è gestito da un dominio di sicurezza (per esempio, l’Issuer Secure Domain Profile ISD-P).

In questo contesto, la Figura 1 rappresenta una possibile architettura di una “apparecchiatura di utente” 10, quale un dispositivo mobile, per es. uno smartphone o un tablet, oppure un modulo di comunicazione mobile da usare solitamente nei sistemi embedded.

Generalmente, il dispositivo 10 comprende uno o più processori 102 connessi a una o più memorie 104. Il dispositivo 10 comprende inoltre almeno un’interfaccia di comunicazione mobile 106 per la comunicazione con una stazione base BS.

Per esempio, l’interfaccia di comunicazione mobile 106 può comprendere un ricetrasmettitore GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), un ricetrasmettitore W-CDMA (Wideband Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access) e/o LTE (Long Term Evolution).

Spesso, un dispositivo mobile comprende anche un’interfaccia di utente 110, quale uno schermo a sfioramento (“touchscreen”). Per contro, un modulo di comunicazione da usare, per es., nei sistemi embedded, quali i sistemi di allarme, i contatori del gas o altri tipi di sistemi di controllo e/o di monitoraggio remoto, spesso non comprende un’interfaccia di utente 110, ma un’interfaccia di comunicazione 112 al fine di scambiare dati con un’ulteriore unità di elaborazione di un sistema embedded. Per esempio, in questo caso, l’interfaccia 112 può essere un’interfaccia di comunicazione digitale, quale una interfaccia di comunicazione UART (Universal Asynchronous Receiver-Transmitter), SPI (Serial Peripheral Interface) e/o USB (Universal Serial Bus). In generale, l’unità di elaborazione 112 può anche essere direttamente il processore principale di un sistema embedded. In questo caso, l’interfaccia 112 può essere usata per scambiare dati con uno o più sensori e/o attuatori. Per esempio, in questo caso, l’interfaccia 112 può essere implementata per mezzo di una o più interfacce analogiche e/o porte di ingresso/uscita digitali dell’unità di elaborazione 102.

Nella memoria 104 può essere memorizzato per es. un sistema operativo OS che è eseguito dal processore 102 e che gestisce le funzioni generali del dispositivo 10, quali la gestione dell’interfaccia di utente 110 e/o dell’interfaccia di comunicazione 112 e l’instaurazione di una connessione con la stazione base BS attraverso l’interfaccia 106. La memoria 104 può anche contenere applicazioni che sono eseguite dal sistema operativo OS. Per esempio, nel caso di un dispositivo mobile, la memoria 104 spesso comprende un’applicazione di web browser WB.

Per instaurare una connessione con la stazione base BS, il dispositivo 10 è accoppiato a una unità di elaborazione 108 configurata in modo da gestire l’identificazione dell’identità dell’utente. Per esempio, di solito un dispositivo mobile comprende un porta scheda per ricevere una scheda comprendente un Subscriber Identity Module (SIM), che di solito è chiamata scheda SIM. Generalmente, un modulo SIM corrispondente può anche essere installato direttamente all’interno del dispositivo 10. Nell’esempio della Figura 1, è usata una Universal Integrated Circuit Card (UICC) 108, che è una smart-card spesso usata nelle reti GSM e UMTS. La UICC assicura l’integrità e la sicurezza di tutti i generi di dati personali e tipicamente contiene alcune centinaia di kilobyte. Anche una UICC può essere integrata direttamente nel dispositivo 10 e in questo caso è spesso chiamata UICC embedded (eUICC, “embedded UICC”).

Per esempio, in una rete GSM la UICC 108 contiene un’applicazione SIM e in una rete UMTS un’applicazione USIM. Una UICC può contenere varie applicazioni, rendendo possibile che la stessa smart-card dia accesso a reti sia GSM sia UMTS, e può anche fornire la memorizzazione di una rubrica telefonica e di altre applicazioni.

Di conseguenza, il riferimento a un modulo SIM nel seguito della presente descrizione intende comprendere sia i moduli SIM 2G e/o 3G e si applica anche al caso in cui un tale modulo SIM sia fornito su una scheda SIM.

Come rappresentato nella Figura 2, un modulo SIM 108 spesso comprende uno o più processori 1082 e una o più memorie 1084 per eseguire le applicazioni memorizzate nella memoria 1084 del modulo 108. Per esempio, il modulo SIM 108 può comprendere in aggiunta all’applicazione di Subscriber Identity Module (simbolo di riferimento SIM nella Figura 2) almeno una ulteriore applicazione APP. Per esempio, quest’applicazione APP può essere configurata in modo da comunicare (direttamente, o indirettamente attraverso il processore 102 ed eventualmente il sistema operativo OS) con l’interfaccia di comunicazione mobile 106 al fine di inviare dati a e/o di ricevere dati da un host remoto 30. A questo scopo, l’host 30 può essere connesso attraverso una rete 20, quale una rete locale (LAN, “Local Area Network”) o una rete geografica (WAN, “Wide Area Network”), come Internet, alla stazione base BS. Di conseguenza, una connessione tra l’host 30 e la UICC 108 può essere instaurata per mezzo della rete 20, della stazione base BS e dell’interfaccia di comunicazione 108. In generale, la comunicazione può essere iniziata dall’host 30 o dalla UICC 108. Per esempio, l’applicazione APP può essere un’applicazione di web server, che riceve richieste dal web browser WB di un dispositivo mobile 10 e ottiene un rispettivo contenuto da un host remoto 30, quale un web server. L’applicazione APP può anche essere un’applicazione di autenticazione. In questo caso, l’host 30 può inviare una richiesta di autenticazione alla UICC 108 e la UICC 108 può inviare una risposta di autenticazione all’host 30.

La Figura 3 rappresenta a questo riguardo una tipica architettura degli strati software di una scheda UICC. Sostanzialmente, una UICC 108 comprende uno strato hardware UICC_HW che è rappresentato (almeno) dal processore 1082 e dalla memoria 1084. Sopra allo strato hardware UICC_HW è eseguito un sistema operativo UICC_OS della scheda UICC. Generalmente, il sistema operativo UICC_OS può gestire una pluralità di applicazioni. Per esempio, nell’esempio considerato, un Java Card System JCS è eseguito dal sistema operativo UICC_OS, che gestisce ed esegue delle applet, cioè applicazioni che usano le interfacce per la programmazione di applicazioni o API (Application Programming Interface) fornite dal Java Card System JCS.

Per esempio, il Java Card System JCS comprende di solito una API di SIM e/o di USIM (identificata con il simbolo di riferimento (U)SIM API) che gestisce i comandi di base del Subscriber Identity Module e fornisce funzioni alle applet di SIM o di USIM di livello superiore (identificate con il simbolo di riferimento (U)SIM_APP).

In generale, la comunicazione con l’host remoto 30 può essere effettuata attraverso messaggi brevi del servizio di messaggi brevi (SMS, “Short Message Service”) e/o per mezzo di un BIP (Bearer Independent Protocol), quale il GPRS, l’EDGE o l’UMTS. La Java Card<TM>Platform fornisce un ambiente runtime JAVA<TM>, che è particolarmente ottimizzato per le smart-card. Questa tecnologia è ben nota agli esperti nella tecnica, rendendo qui superflua una descrizione più dettagliata.

Spesso il Java Card System JCS comprende un modulo di GlobalPlatform GP secondo la “GlobalPlatform Card specification”, per es. versione 2.2.1. Anche questa norma è ben nota agli esperti nella tecnica, rendendo qui superflua una descrizione più dettagliata. Fondamentalmente, il modulo GP fornisce elementi distintivi quali l’autenticazione di utente attraverso canali sicuri, o l’installazione e la gestione remota delle applet. Per esempio, uno dei possibili meccanismi di crittografia gestiti dal modulo GP può essere il SCP (Secure Channel Protocol) 80 specificato nella specifica tecnica ETSI TS 102 225 “Smart Cards; Secured packet structure for UICC based applications”, per es. versione 9.0.0.

Le funzioni di API summenzionate possono quindi essere usate dalle applet, quali la applet di SIM o di USIM (U)SIM_APP, una applet di base B_APP e/o una applet sicura S_APP.

La UICC 108 può comprendere anche ulteriori applicazioni, quale uno Smart Card Web Server SCWS e possibili applet di Web server SCWS_APP, che eseguono per es. la funzione di web server summenzionata.

In generale, la UICC 108 può comprendere non soltanto delle applet custom ma anche applicazioni native N_APP di basso livello che sono eseguite direttamente dal sistema operativo UICC_OS.

Per esempio, la Figura 4 rappresenta una tipica comunicazione usando il protocollo di gestione remota, quale il protocollo SCP 80 come specificato nelle specifiche tecniche ETSI TS 102 225 “Smart Cards; Secured packet structure for UICC based applications”, per es. versione 9.0.0, e in particolare in ETSI TS 102 226 “Smart Cards; Remote APDU structure for UICC based applications”, per es. versione 9.2.0.

Nell’esempio considerato, l’host remoto 30 può inviare un comando, cioè una unità dati di protocollo di applicazione di comando C-APDU (“Command Application Protocol Data Unit”), a un’applicazione installata sulla UICC 108 e può ricevere dall’applicazione una rispettiva risposta, cioè una unità dati di protocollo di applicazione di risposta R-APDU (“Response Application Protocol Data Unit”).

Per esempio, l’host 30 può inviare il comando C-APDU a un Centro Servizi del Servizio di Messaggi Brevi SMSC (“Short Message Service - Service Centre”), che invia un messaggio breve al dispositivo 10. Il Centro Servizi del Servizio di Messaggi Brevi SMS-SC, può anche crittografare il comando C-APDU, per es. usando il protocollo SCP80, ed incapsula il contenuto crittografato in un messaggio SMS, che è quindi trasmesso per mezzo della stazione base BS al dispositivo 10. Il dispositivo 10 può riconoscere che il messaggio breve contiene un messaggio di gestione remota, per es. un pacchetto SCP80, e può inviare quest’ultimo alla UICC 108 per mezzo di una cosiddetta BUSTA (“ENVELOPE”). La UICC 108, usando eventualmente le funzioni fornite dal sistema operativo UICC_OS e dal Java Card System JCS, determina il contenuto del messaggio SMS, per es. se richiesto la UICC può decrittare il messaggio, e inoltra il contenuto C-APDU all’applicazione target.

Al fine di inoltrare la C-APDU, la UICC 108 dovrebbe essere in grado di identificare la corrispondente applicazione target. A questo scopo, di solito un codice TAR (Toolkit Application Reference), che consiste per es. di 3 byte, è associato a ciascuna applicazione installata nella UICC. Per esempio, nella Figura 4 un codice TAR1 è associato all’applicazione di SIM SIM_APP, un codice TAR2 è associato all’applicazione B_APP e un codice TAR3 è associato all’applicazione sicura S_APP.

Di conseguenza, è sufficiente includere il codice TAR dell’applicazione target nel messaggio breve inviato alla UICC 108, per es. nell’intestazione (“header”) del messaggio breve o nel pacchetto SCP80, e la UICC deve soltanto confrontare il codice TAR ricevuto con i vari codici TAR delle applicazioni installate nella UICC.

Generalmente, invece di usare messaggi brevi, potrebbe essere usata una qualsiasi altra comunicazione per scambiare messaggi di gestione remota con un modulo SIM 108, come una comunicazione basata sul protocollo IP, per es. il protocollo TCP (Transmission Control Protocol) o quello UDP (User Datagram Protocol).

Per esempio, le comunicazioni di gestione remota precedenti possono essere usate al fine di aggiornare la Preferred Roaming List (PRL), cioè la lista e la priorità dei partner di roaming, che può essere memorizzata direttamente all’interno della memoria della UICC 108.

In questo caso, la UICC può comprendere un’applicazione che gestisce la Preferred Roaming List e l’host remoto può inviare una o più C-APDU con le informazioni di roaming aggiornate e il codice TAR dell’applicazione alla UICC 108.

La presente descrizione tratta in particolare di soluzioni per effettuare una gestione di un modulo SIM che ha installate applicazioni fornite da differenti operatori di telefonia mobile, cioè una cosiddetta SIM a sottoscrizione multipla, che è preferibilmente un modulo SIM a sottoscrizione multipla embedded, preferibilmente una eUICC a sottoscrizione multipla. Per esempio, tali moduli SIM a sottoscrizione multipla possono essere usati come moduli SIM embedded, per es. eUICC, o come schede SIM da installare nelle macchine automatiche, che spesso non sono facilmente raggiungibili, quali i sistemi di controllo e/o di monitoraggio remoto, come i contatori del gas.

La Figura 5 rappresenta una forma di attuazione di un modulo SIM a sottoscrizione multipla 108a.

Nella forma di attuazione considerata, il modulo SIM 108a supporta almeno due profili P1 e P2 di due operatori di rete mobile. In generale, il modulo SIM 108a può sopportare anche più di due profili, cioè una pluralità di profili.

Per esempio, nelle forme di attuazione considerate, l’architettura software è basata sul Java Card System descritto con riferimento alla Figura 3. Per esempio, anche in questo caso, un Java Card System JCSa è eseguito da un sistema operativo UICC_OS, che gestisce ed esegue delle applet, cioè applicazioni che usano le API (Application Programming Interface) fornite dal Java Card System JCSa. Per esempio, il Java Card System JCS può comprendere una API di SIM e/o di USIM (identificata con il simbolo di riferimento (U)SIM API) che gestisce i comandi di base del Subscriber Identity Module e fornisce funzioni alle applet di SIM e/o di USIM di livello superiore. Inoltre, la Java Card<TM>Platform può fornire un ambiente runtime JAVA<TM>. In una forma di attuazione, il Java Card System JCSa può anche comprendere un modulo di GlobalPlatform GP secondo la “GlobalPlatform Card specification”, per es. versione 2.2.1. Le funzioni di API summenzionate possono quindi essere usate dalle applet, quali la applet di SIM e/o di USIM (U)SIM_APP, una applet di base B_APP e/o una applet sicura S_APP.

Ciascun profilo P1/P2 è rappresentato da un’area di memoria nella memoria 1084 della scheda SIM per memorizzare delle applet APP, quali una rispettiva applet (U)SIM_APP per ciascun profilo P1/P2. Nell’area di memoria possono anche essere memorizzati i rispettivi dati di autenticazione AUTH della scheda SIM usati per accedere alla rete mobile dell’operatore di rete mobile. In varie forme di attuazione, ciascun profilo P1/P2 può anche avere associata una rispettiva Chiave OTA (Over The Air), che sono usate di solito per crittografare (per es., secondo il protocollo SCP80) i comandi di gestione remota inviati da un operatore di rete mobile a una data scheda SIM. Di solito, mentre i dati di autenticazione AUTH sono specifici per una SIM, spesso una singola chiave OTA è usata da un dato operatore di rete mobile.

In varie forme di attuazione, ciascun profilo P1/P2 può avere associata una rispettiva area di file system FS, per es. al fine di memorizzare nuove applet APP e/o per memorizzare dati di utente, quali la lista dei contatti dell’utente, o la lista dei partner di roaming preferiti summenzionata.

Generalmente, sebbene i dati di profilo siano stati rappresentati nello strato di applicazione/applet, ciascun profilo può anche comprendere applicazioni e/o API nel Java Card System JCSa. Inoltre, i dati di profilo possono anche comprendere dati di configurazione che influenzano direttamente lo strato di API.

Nella forma di attuazione considerata, la UICC 108a comprende inoltre un’applicazione di gestore dei profili PM. Per esempio, nelle forme di attuazione considerate, questo gestore dei profili PM è fornito nello strato di API. Tuttavia, il gestore dei profili PM può anche essere allo strato di applet, o può essere distribuito tra lo strato di API e quello di applet.

La Figura 6 rappresenta a questo riguardo una possibile forma di attuazione di un dispositivo 10a, quale un dispositivo mobile o un modulo di comunicazione mobile, che ha (pre)installato il modulo SIM a sottoscrizione multipla 108a descritto in precedenza, per es. sotto forma di un modulo SIM embedded, per es. una eUICC.

Nella forma di attuazione considerata, in modo simile a ciò che è già stato descritto con riferimento alla Figura 1, il dispositivo 10a può comprendere uno o più processori 102a connessi a una o più memorie 104a. Il dispositivo 10a comprende inoltre almeno un’interfaccia di comunicazione mobile 106a per la comunicazione con una stazione base BS. Per esempio, l’interfaccia di comunicazione mobile 106a può comprendere un ricetrasmettitore GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), un ricetrasmettitore W-CDMA (Wideband Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access) e/o LTE (Long Term Evolution). Il dispositivo 10a può anche comprendere un’interfaccia di utente 110a, quale uno schermo a sfioramento.

Nella forma di attuazione considerata, nella memoria 104a è memorizzato un sistema operativo OSa che è eseguito dal processore 102a e che gestisce le funzioni generali del dispositivo 10a, quali la gestione dell’interfaccia di utente 110a e l’instaurazione di una connessione con una stazione base BS attraverso l’interfaccia 106a.

Nella forma di attuazione considerata, la memoria 104a contiene anche un’applicazione CFG configurata per comunicare con il gestore dei profili PM del modulo SIM 108a al fine di gestire i profili installati nel modulo SIM 108a. Per esempio, in alcune forme di attuazione, l’applicazione CFG è configurata per comunicare con il gestore dei profili PM al fine di selezionare o di abilitare uno dei profili P1/P2 installati nella scheda SIM 108a.

Per esempio, in una forma di attuazione, il modulo SIM 108a può avere preinstallati i profili di una pluralità di operatori di rete mobile e, quando il dispositivo 10a è avviato per la prima volta (o in generale durante una fase di configurazione), l’utente può attivare per mezzo dell’applicazione CFG uno dei profili P1/P2.

In alcune forme di attuazione, l’applicazione CFG può essere configurata in modo da installare e/o aggiornare un profilo nel modulo SIM 108a. Per esempio, l’applicazione CFG può accedere a un host remoto al fine di scaricare una lista degli operatori di rete mobile. In seguito, l’applicazione CFG può essere usata per effettuare una sottoscrizione con uno degli operatori di rete mobile e per ottenere i rispettivi dati di profilo, che possono quindi essere caricati sul modulo SIM 108 per mezzo dell’applicazione CFG e del gestore dei profili PM.

Così, sulla stessa scheda possono essere presenti simultaneamente vari profili che rappresentano vari operatori. In un dato momento qualsiasi può essere abilitato soltanto un profilo, tutti gli altri essendo disabilitati.

I profili possono essere scaricati attraverso un protocollo remoto (OTA) dopo l’emissione della scheda; i profili possono anche essere cancellati.

Nello scenario precedente, è evidente che ciascun profilo da memorizzare richiede risorse di memoria per sistemare i dati e le applicazioni.

La memoria 1084 o 1084a comprende due generi di risorse di memoria sulle smart-card:

- “Memoria Non Volatile” (NVM, “Non Volatile Memory”), che rappresenta una memoria che non è resettata a un ciclo della scheda (spegnimento/accensione). Questa memoria è realizzata tipicamente usando una memoria Flash o una memoria EEPROM

- “Memoria volatile”, che rappresenta una memoria il cui valore è resettato a un ciclo della scheda. Tipicamente, la memoria è realizzata usando una memoria RAM.

Sui prodotti smart-card correnti la quantità di NVM è di gran lunga più elevata della quantità di RAM: come esempio, un prodotto smart-card di fascia alta supporta per esempio 1.2 MB di memoria Flash e 30kb di RAM.

Le strutture di dati (quali i file) sono memorizzate nella NVM; anche il codice applicativo e i dati persistenti sono memorizzati nella NVM, ma le variabili volatili delle applicazioni sono tipicamente memorizzate nella memoria RAM, perché l’accesso in memoria è molto più veloce.

Questo ha come risultato il fatto che la memoria RAM è tipicamente il collo di bottiglia della memoria per scaricare le applicazioni. Nel caso di una UICC Embedded, poiché ci sono vari profili ciascuno dei quali contiene varie applicazioni, il problema è amplificato: ogni profilo ha la sua necessità di memoria volatile che è necessario che sia sistemata.

Il problema può essere affrontato in molti modi. Una soluzione è di effettuare una riservazione al momento del caricamento del profilo. In questa soluzione, la memoria RAM è completamente allocata a ogni singolo profilo al momento del caricamento del profilo, in particolare quando il profilo è scaricato da remoto. La memoria RAM totale richiesta è la somma di tutta la memoria RAM allocata a ogni profilo.

A titolo di esempio, se il profilo P1 contiene 3 applicazioni, che consumano un totale di 10 kb, il profilo P2 contiene 2 applicazioni, che consumano un totale di 7 kb, il profilo P3 contiene 2 applicazioni, che consumano un totale di 9 kb, la memoria è allocata a ciascun profilo P1, P2, P3 quando è scaricato, per un totale di 26 kb richiesti.

Tale soluzione è molto affidabile (tutte le risorse dei profili sono garantite), ma è anche molto inefficiente dal punto di vista dell’utilizzo della memoria: la memoria richiesta per sistemare tutti i profili è la somma di tutta la memoria dei profili, ma una tale quantità di memoria non è sempre richiesta; in effetti, è attivo soltanto un profilo per volta, perciò la memoria allocata agli altri profili non è usata. Se il profilo attivo è cambiato, allora è eseguito un reset del ciclo di spegnimento e riaccensione (“power cycle”) per cambiare il profilo e questo resetta tutti i dati, così la memoria del profilo precedente può essere deallocata.

Un’altra soluzione fornisce una riservazione a richiesta della memoria. In questa soluzione, la memoria RAM è allocata a ciascuna entità ogni volta che l’entità richiede l’utilizzo della memoria (approccio dinamico).

A titolo di esempio, se il profilo P1 contiene 3 applicazioni, il profilo P2 contiene 2 applicazioni, il profilo P3 contiene 2 applicazioni, nessuna memoria è allocata allo scaricamento dei profili. La memoria RAM è allocata soltanto per le applicazioni in esecuzione.

La soluzione precedente implica che le risorse di RAM dei profili crescano nel corso del tempo e, in un dato istante qualsiasi, esse possono provocare un overflow delle risorse di memoria disponibili.

Questo è pericoloso sulle smart-card, poiché un’applicazione che richiede memoria per effettuare un’operazione e che non la ottiene è soggetta a un malfunzionamento. I malfunzionamenti sono spesso usati dagli hacker per identificare le debolezze della sicurezza.

Sintesi

In base alla descrizione precedente, si sente la necessità di soluzioni che superino uno o più degli inconvenienti delineati precedentemente.

Secondo una o più forme di attuazione, un tale scopo è raggiunto attraverso i procedimenti che hanno gli elementi distintivi esposti specificamente nelle rivendicazioni che seguono. Le forme di attuazione riguardano inoltre un relativo modulo SIM così come un corrispondente relativo prodotto informatico, caricabile nella memoria di almeno un elaboratore e comprendente porzioni di codice software per effettuare le fasi del procedimento quando il prodotto è eseguito su un elaboratore. Come usato qui, un riferimento a un prodotto informatico intende essere equivalente a un riferimento a un mezzo leggibile da elaboratore che contiene istruzioni per controllare un sistema di elaborazione per coordinare l’esecuzione del procedimento. Un riferimento ad “almeno un elaboratore” intende evidentemente evidenziare la possibilità che la presente descrizione sia implementata in modo distribuito/modulare.

Le rivendicazioni sono parte integrante dell’insegnamento tecnico della descrizione qui fornita.

Come menzionato in precedenza, la presente descrizione fornisce soluzioni per quanto riguarda un procedimento per effettuare una gestione remota di un modulo SIM a sottoscrizione multipla, detto modulo SIM a sottoscrizione multipla comprendendo almeno una memoria atta a memorizzare almeno un primo e un secondo profilo, cioè una pluralità di profili, associati a un primo e a un secondo operatore di rete mobile rispettivi, o a una prima e a una seconda linea o sottoscrizione rispettive, detta memoria comprendendo una porzione volatile, detta operazione di memorizzare comprendendo di installare o di aggiornare i profili scaricando uno o più profili scaricati da un host remoto, detta gestione comprendendo di selezionare uno o più profili abilitati comprendenti un’applicazione da eseguire e di allocare una partizione della porzione volatile della memoria a detti uno o più profili abilitati, in cui tale procedimento comprende inoltre le operazioni di:

dividere l’area della memoria volatile in una partizione per il sistema operativo, una partizione per ciascuno dell’uno o più profili abilitati e una partizione per un profilo scaricato, detta partizione per il profilo abilitato e detta partizione per un profilo scaricato avendo la stessa dimensione,

allocare la partizione per il profilo abilitato (SPP) al profilo abilitato, mantenendo non accessibile la partizione per un profilo scaricato,

durante un’operazione di scaricamento di un profilo, accedere soltanto alla partizione per un profilo scaricato allocando detta partizione per un profilo scaricato al profilo scaricato,

durante un’operazione di cambiamento di un profilo, scambiare il profilo di scaricamento dalla partizione per un profilo scaricato a una delle partizioni per il profilo abilitato.

In varianti di forme di attuazione, la soluzione qui descritta può comprendere che detta operazione di cambiamento di un profilo è effettuata dopo un reset della scheda, in particolare un ciclo di spegnimento e riaccensione.

In varianti di forme di attuazione, la soluzione qui descritta può comprendere che detto allocare la partizione per il profilo abilitato al profilo abilitato è effettuato all’accensione.

In varianti di forme di attuazione, la soluzione qui descritta può comprendere che detto modulo SIM a sottoscrizione multipla è una scheda eUICC.

In varianti di forme di attuazione, la soluzione qui descritta può comprendere che detta memoria volatile è una memoria RAM.

In varianti di forme di attuazione, la soluzione qui descritta può comprendere che detta gestione di un modulo SIM a sottoscrizione multipla comprende di selezionare un profilo abilitato comprendente un’applicazione da eseguire e di allocare una partizione della porzione volatile della memoria a detto profilo abilitato, e detto procedimento comprende inoltre le operazioni di:

dividere l’area della memoria volatile in una partizione per il sistema operativo, una partizione per il profilo abilitato e una partizione per un profilo scaricato, detta partizione per il profilo abilitato e detta partizione per un profilo scaricato avendo la stessa dimensione,

allocare la partizione per il profilo abilitato al profilo abilitato, mantenendo non accessibile la partizione per un profilo scaricato,

durante un’operazione di cambiamento di un profilo scambiare il profilo di scaricamento dalla partizione per un profilo scaricato alla partizione per il profilo abilitato.

La presente descrizione fornisce anche soluzioni per quanto riguarda un modulo SIM a sottoscrizione multipla comprendente almeno un processore e almeno una memoria atta a memorizzare almeno un primo e un secondo profilo associati a un primo e a un secondo operatore di rete mobile rispettivi, in modo tale che un rispettivo contenuto possa essere associato a ciascun profilo, detta memoria comprendendo una porzione volatile, in cui detto modulo SIM a sottoscrizione multipla è configurato per implementare il procedimento secondo una qualsiasi delle forme di attuazione precedenti.

La presente descrizione fornisce anche soluzioni per quanto riguarda un prodotto informatico che può essere caricato nella memoria di almeno un processore e che comprende porzioni di codice software per implementare il procedimento secondo una qualsiasi delle forme di attuazione precedenti.

Breve descrizione delle figure

Le forme di attuazione della presente descrizione saranno ora descritte con riferimento ai disegni annessi, che sono forniti puramente a titolo di esempio non limitativo, e nei quali:

- le Figure da 1 a 6 sono già state descritte in precedenza;

- la Figura 7 rappresenta una forma di attuazione dell’architettura software di un modulo SIM a sottoscrizione multipla contenente una pluralità di profili;

- la Figura 8 rappresenta una forma di attuazione di un procedimento per abilitare un profilo per mezzo di un dispositivo mobile;

- la Figura 10 rappresenta una forma di attuazione di un procedimento per allocare una memoria volatile in un modulo SIM a sottoscrizione multipla;

- la Figura 9 e quelle da 11 a 13 rappresentano una memoria volatile di un modulo SIM a sottoscrizione multipla in una fase differente del procedimento della Figura 10.

Descrizione Dettagliata

Nella descrizione che segue, sono dati numerosi dettagli specifici per fornire una comprensione approfondita delle forme di attuazione. Le forme di attuazione possono essere attuate senza uno o vari dettagli specifici o con altri procedimenti, componenti, materiali, ecc. In altri casi, operazioni, materiali o strutture ben note non sono rappresentate o descritte in dettaglio in modo da evitare di rendere poco chiari gli aspetti delle forme di attuazione.

Un riferimento a “una forma di attuazione” in tutta questa descrizione significa che una particolare caratteristica, elemento distintivo o struttura descritta con riferimento alla forma di attuazione è inclusa in almeno una forma di attuazione. Così, le comparse delle frasi “in una forma di attuazione” in vari punti in tutta questa descrizione non fanno necessariamente riferimento tutte alla stessa forma di attuazione. Inoltre, le particolari caratteristiche, elementi distintivi o strutture possono essere combinate in un modo adeguato qualsiasi in una o più forme di attuazione.

Le intestazioni fornite qui sono semplicemente per convenienza e non interpretano l’ambito o il significato delle forme di attuazione.

I componenti, gli elementi o le parti delle Figure che sono già stati descritti con riferimento alle Figure da 1 a 5 sono indicati con gli stessi riferimenti usati precedentemente in tali Figure; la descrizione di tali elementi descritti precedentemente non sarà ripetuta in seguito al fine di non sovraccaricare la presente descrizione dettagliata.

Ora, con riferimento alle Figure 7 e 8, è illustrata una possibile procedura per abilitare un profilo in una scheda eUICC 108a che può fare uso della soluzione per allocare lo spazio di memoria della memoria volatile come descritto in seguito. La Figura 7 rappresenta una forma di attuazione, nella quale il gestore dei profili PM può comunicare con un host remoto 30a al fine di installare, aggiornare e/o abilitare un profilo P1/P2 per mezzo di comandi di gestione remota.

Di nuovo, il modulo SIM 108a comprende uno o più processori 1082a e una o più memorie 1084a per eseguire le applicazioni memorizzate nella memoria 1084a del modulo 108a. In questo caso, l’applicazione del gestore dei profili PM può essere configurata in modo da comunicare (direttamente o indirettamente attraverso il processore 102a ed eventualmente il sistema operativo OSa) con l’interfaccia di comunicazione 106a al fine di inviare dati al e/o di ricevere dati dall’host remoto 30a.

Per esempio, l’host 30a può essere connesso attraverso una rete 20, quale una rete locale (LAN) o una rete geografica (WAN), come Internet, alla stazione base BS. Di conseguenza, una connessione tra l’host 30a e il modulo SIM 108a può essere instaurata per mezzo della rete 20, della stazione base BS e dell’interfaccia di comunicazione 106a.

Per esempio, la Figura 8 rappresenta un diagramma di flusso di un possibile procedimento che permette di abilitare un profilo nel modulo SIM 108a. Specificamente, nella forma di attuazione considerata, il modulo SIM 108a ha installato almeno un primo profilo P1.

Dopo una fase di avvio 1000, il dispositivo 10a si connette in una fase 1002 a una stazione base BS usando i dati del profilo P1, per es. usando i dati di autenticazione AUTH del profilo P1. In generale, il dispositivo 10a usa i dati del profilo che sono selezionati come un profilo abilitato attivo al boot, cioè all’accensione del dispositivo 10. All’accensione, il terminale, cioè il dispositivo 10, usa sempre il “profilo abilitato”; cambiare un profilo abilitato nella forma di attuazione descritta richiede un reset, in particolare un ciclo di spegnimento e riaccensione. In alternativa, può essere applicato un hot swap come nell’USB plug-and-play.

In seguito, in una fase 1004, l’host 30a invia uno o più comandi di gestione remota al gestore dei profili PM al fine di installare o di aggiornare un nuovo profilo P2, che è scaricato dall’host remoto 30a.

Una volta che il nuovo profilo P2 è stato installato o aggiornato, l’host 30a invia in una fase 1006 un comando di gestione remota al gestore dei profili PM al fine di abilitare il profilo P2.

Infine, il procedimento termina in una fase di arresto 1008.

Il gestore dei profili PM può essere sostituito in alternativa da un qualsiasi software o firmware che implementa un protocollo remoto, come l’OTA, per consentire di scaricare/abilitare/cancellare i profili per la scheda dopo l’emissione della scheda.

Per esempio, questa forma di attuazione può essere adatta per i sistemi automatici, quali i contatori del gas o qualsiasi altro tipo di sistemi di controllo e/o monitoraggio remoto. In questo caso, l’applicazione CFG può anche non essere richiesta. Tuttavia, il procedimento potrebbe anche essere usato per i dispositivi mobili, quali gli smartphone o i tablet.

Generalmente, le forme di attuazione descritte con riferimento alla Figura 6 e alle Figure 7 e 8 potrebbero anche essere combinate, per es. il modulo SIM 108a potrebbe essere configurato in modo tale che un profilo possa essere installato, aggiornato e/o abilitato per mezzo di un’applicazione installata nel dispositivo 10a e/o per mezzo di un comando di gestione remota ricevuto da un host remoto 30a.

Di conseguenza, indipendentemente dal procedimento usato per installare, aggiornare e/o abilitare i profili, un modulo SIM a sottoscrizione multipla 108a può comprendere una pluralità di profili, in cui ciascun profilo può comprendere rispettive applicazioni e un altro contenuto possibile. Inoltre, come menzionato in precedenza, ciascuna applicazione è identificata di solito per mezzo di un codice TAR al fine di permettere una gestione remota della rispettiva applicazione.

La soluzione proposta prevede fondamentalmente che sul modulo SIM 108a ci siano vari profili, ma che soltanto uno di loro sia disponibile in un certo momento.

Al fine di cambiare da un profilo a un altro, nell’esempio qui descritto dal profilo P1 a quello P2, è richiesto un “ciclo di spegnimento e riaccensione” (cioè, la scheda è spenta/accesa), e il ciclo di spegnimento e riaccensione resetta i valori della RAM nella porzione di RAM della memoria 1084a. Attraverso il ciclo di spegnimento e riaccensione perciò la memoria RAM delle sessioni che precedono il ciclo di spegnimento e riaccensione può essere deallocata quando avviene un cambiamento di profilo.

Dopo il ciclo di spegnimento e riaccensione è tuttavia necessario allocare una parte della memoria RAM per il profilo attivo (nell’esempio, il nuovo profilo attivo sarà P2), per esempio per memorizzare nella memoria RAM le variabili volatili dell’applicazione da eseguire, ma tenendo conto che anche un profilo in corso di caricamento ha necessità di memoria RAM. Se il profilo selezionato come profilo abilitato impegna tutte le risorse di memoria, non ci potrebbe essere abbastanza memoria per effettuare lo scaricamento in memoria.

La soluzione proposta funziona consentendo al modulo SIM 108a di allocare al profilo attivo abilitato, cioè Ps, soltanto una parte della sua memoria volatile. Più specificamente, il modulo SIM 108a è configurato in modo da contenere una memoria volatile per due profili:

il profilo abilitato Ps;

il profilo in corso di scaricamento Pd.

Secondo la norma corrente, c’è soltanto un profilo abilitato Ps e al più un profilo in corso di scaricamento Pd in un momento qualsiasi.

Come meglio rappresentato con riferimento alla Figura 9 nella quale è rappresentata schematicamente una memoria RAM 1084R della memoria 1084a, la Memoria RAM 1084R è partizionata in tre parti:

una partizione di Memoria del Sistema Operativo OSP; una partizione del profilo abilitato SPP;

una partizione del profilo di scaricamento DPP.

La partizione del profilo abilitato SPP e la partizione del profilo di scaricamento DPP hanno la stessa dimensione. Questo garantisce che le partizioni dei profili siano scambiabili.

Nella Figura 6 è rappresentato un diagramma di flusso che rappresenta una forma di attuazione del procedimento qui proposto per gestire la memoria RAM 1084 nella scheda UICC 108a usando profili multipli che contengono rispettivamente una o più applicazioni.

Il procedimento, dopo una fase di avvio 2000, comprende un’operazione 2005 di dividere l’area della memoria RAM 1084R in una partizione per il sistema operativo OSP, una partizione per il profilo abilitato SPP e una partizione per un profilo scaricato DPP, dove la partizione per il profilo abilitato SPP e una partizione per un profilo scaricato DPP hanno la stessa dimensione. Quest’operazione è già stata descritta in dettaglio con riferimento alla Figura 9.

Quindi, al boot, cioè quando il modulo SIM 108a è acceso, cioè posto nello stato di accensione (“on”) di un ciclo di spegnimento e riaccensione, è effettuata un’operazione 2010 di allocare la partizione per il profilo abilitato SPP a un profilo abilitato Ps, mantenendo non accessibile la partizione per un profilo scaricato DPP.

I dettagli di tale operazione 2010 sono rappresentati nella Figura 5, che rappresenta come, al boot, quando il modulo SIM è acceso, uno spazio nella memoria 1084R è allocato allocando un profilo abilitato Ps, per esempio il profilo P1, nella partizione del profilo abilitato SPP, mentre il resto dello spazio di memoria 1084a è mantenuto vuoto. Il profilo abilitato Ps occupa uno spazio nella partizione del profilo abilitato SPP e, se ha una dimensione minore della partizione del profilo abilitato SPP, lascia uno spazio libero SPF, che può essere al meglio di dimensione zero se il profilo abilitato ha la stessa dimensione della partizione del profilo abilitato SPP. D’altra parte, la partizione del profilo di scaricamento DPP non è accessibile, cioè, se il profilo abilitato Ps tenta di allocare memoria, l’allocazione avrebbe insuccesso nel caso in cui la quantità di memoria della partizione del profilo abilitato SPP non fosse sufficiente.

Quindi, durante un’operazione di scaricamento del profilo, è effettuata un’operazione 2015 di accedere soltanto alla partizione per un profilo scaricato DPP allocando uno spazio di memoria in detta partizione al profilo scaricato Pd.

I dettagli di tale operazione 2015 sono rappresentati nella Figura 6, che rappresenta come, durante uno scaricamento di un profilo, per esempio durante la fase 1004, il profilo in corso di scaricamento Pd occupa uno spazio nella partizione del profilo scaricato DPP e, se ha una dimensione minore della partizione del profilo scaricato DPP, lascia uno spazio libero DPF, che può essere al meglio di dimensione zero se il profilo abilitato ha la stessa dimensione della partizione del profilo scaricato DPP. Durante lo scaricamento, il profilo in corso di scaricamento Pd può accedere soltanto alla partizione del profilo di scaricamento DPP e non alla partizione del profilo abilitato SPP. Questo garantisce la disponibilità della memoria sia per il profilo abilitato Ps sia per il profilo di scaricamento Pd.

Quindi, durante un’operazione di cambiamento di un profilo, per esempio durante la fase 1006 di abilitazione del profilo, è prevista un’operazione 2020 di scambio del profilo di scaricamento Pd dalla partizione per un profilo scaricato DPP alla partizione per il profilo abilitato SPP.

L’operazione di cambiamento di un profilo, per esempio la fase 1006 di abilitazione del profilo, è effettuata dopo un reset della scheda eUICC, in particolare dopo un ciclo di spegnimento e riaccensione. In generale, un reset della scheda eUICC o di un modulo SIM non è necessariamente un ciclo di spegnimento e riaccensione. Un ciclo di spegnimento e riaccensione richiede che la tensione di alimentazione vada a zero (stato di spegnimento (“off”)) e quindi ritorni a un valore nominale (stato di accensione). Ciò è equivalente a un cosiddetto ‘reset a freddo’ (“cold reset”). Tuttavia, di solito le schede hanno anche un contatto fisico di reset, cioè un contatto elettrico che può essere attuato per effettuare un cosiddetto ‘reset a caldo’ (“warm reset”). Tale reset a caldo è per esempio quello effettuato per un reboot del telefono. Il reset a caldo è equivalente al reset a freddo, ma non è un ciclo di spegnimento e riaccensione.

Le dimensioni delle due partizioni SPP e DPP sono uguali, cioè la partizione del profilo abilitato SPP ha la stessa dimensione della partizione del profilo di scaricamento DPP. Questo implica che, se il profilo scaricato Pd è selezionato affinché sia il prossimo profilo attivo, è assicurato che la dimensione della sua memoria andrà bene, a un ciclo di spegnimento e riaccensione susseguente la partizione del profilo abilitato SPP, cioè, sarà uguale o minore della dimensione della partizione SPP. Lo scambio 2020 (dopo un reset) è rappresentato nella Figura 7. Come menzionato, l’operazione di cambio di profilo è effettuata dopo un ciclo di spegnimento e riaccensione del modulo SIM 180a.

Infine, il procedimento termina a una fase di arresto 2025.

In varianti possibili delle forme di attuazione è possibile avere più di un profilo abilitato, per esempio in un dispositivo con accesso radio multiplo, quali i telefoni cellulari con doppia SIM. In questo caso, se è abilitato un numero n di profili Ps1…Psn, allora la Memoria RAM 1084R è partizionata come segue:

una partizione di Memoria del Sistema Operativo OSP; n partizioni dei profili abilitati SPP;

una partizione del profilo di scaricamento DPP.

Ciascuna delle n partizioni dei profili SPP ha la dimensione della partizione del profilo di scaricamento DPP e il profilo scaricato Pd è scambiato con una di tali n partizioni dei profili abilitati SPP, che può essere selezionata dal Gestore del Programma o da un qualsiasi altro modulo che gestisce l’abilitazione dei profili attivi.

Perciò, in generale la soluzione qui descritta fornisce un procedimento per effettuare una gestione di un modulo SIM a sottoscrizione multipla 108a, tale modulo SIM a sottoscrizione multipla 108a comprendendo almeno una memoria 1084a atta a memorizzare almeno un primo P1 e un secondo P2 profilo, o una pluralità di profili, associati a un primo e a un secondo operatore di rete mobile, o a un primo e a un secondo contratto o a una prima e a una seconda linea di operatore rispettive, tale memoria 1084 comprendendo una porzione volatile 1084R, l’operazione di memorizzare comprendendo l’operazione 1004 di installare o di aggiornare i profili P1, P2 scaricando uno o più profili scaricati Pd da un host remoto 30a, detta gestione comprendendo di selezionare uno o più profili abilitati Ps comprendenti un’applicazione da eseguire e di allocare una partizione della porzione volatile 1084R della memoria a uno o più profili abilitati Ps, il procedimento comprendendo inoltre le operazioni di:

dividere 2005 l’area della memoria volatile 1084R in una partizione OSP per il sistema operativo, una partizione SPP per ciascuno dell’uno o più profili abilitati Ps e una partizione per un profilo scaricato DPP, dette partizioni per il profilo abilitato SPP e partizione per un profilo scaricato DPP avendo la stessa dimensione,

allocare 2010 la partizione per il profilo abilitato SPP al profilo abilitato Ps, mantenendo non accessibile la partizione per un profilo scaricato DPP,

durante un’operazione di scaricamento di un profilo 1004, accedere 2015 soltanto alla partizione per un profilo scaricato allocando detta partizione per un profilo scaricato DPP al profilo scaricato Pd,

durante un’operazione di cambiamento di un profilo 1006, scambiare 2020 il profilo di scaricamento Pd dalla partizione per un profilo scaricato DPP a una delle partizioni per il profilo abilitato SPP.

La soluzione descritta è più efficiente rispetto ai procedimenti che allocano una memoria RAM per tutti i profili, poiché è necessario contenere soltanto due profili per volta.

La soluzione descritta è più affidabile rispetto ai procedimenti che allocano una memoria RAM su richiesta, dove, nel caso in cui non ci sia abbastanza memoria per un profilo in esecuzione o in corso di scaricamento, un errore è fornito come resoconto (“report”) soltanto al runtime. Nella soluzione proposta, il caricamento di un profilo ha insuccesso e l’operatore può adottare misure correttive.

La soluzione tecnica descritta fornisce così un utilizzo efficiente della memoria RAM in una eUICC garantendo nel contempo una allocazione della memoria al runtime a tutti i sistemi con affidabilità elevata. Altre soluzioni note richiedono di fare un compromesso per quanto riguarda l’efficienza o la disponibilità al runtime.

Perciò, la soluzione descritta fornisce un nuovo gestore della memoria volatile, cioè della RAM, che ottimizza le risorse della RAM in una eUICC (una UICC che supporta sottoscrizioni multiple), conservando nel contempo la disponibilità delle risorse al runtime.

Naturalmente, fermi restando i principi di fondo dell’invenzione, i dettagli di costruzione e le forme di attuazione possono variare, anche in modo apprezzabile, rispetto a quanto è stato descritto e illustrato qui, puramente a titolo di esempio, senza uscire con ciò dall’ambito della presente invenzione, come definita dalle rivendicazioni che seguono.

I profili sono indicati come associati a un rispettivo operatore di rete mobile. Tuttavia, la definizione di un operatore di rete mobile differente comprende anche il caso in cui i profili differenti rappresentino differenti linee o sottoscrizioni di uno stesso operatore, per es. Telecom Italia, come una linea business e una linea personale.

Claims

RIVENDICAZIONI 1. Procedimento per effettuare una gestione di un modulo SIM a sottoscrizione multipla (108a), detto modulo SIM a sottoscrizione multipla (108a) comprendendo almeno una memoria (1084a) atta a memorizzare almeno un primo (P1) e un secondo (P2) profilo associati a un primo e a un secondo operatore di rete mobile rispettivi, detta memoria (1084) comprendendo una porzione volatile (1084R), detta operazione di memorizzare comprendendo di installare o di aggiornare (1004) dei profili (P1, P2) scaricando uno o più profili scaricati (Pd) da un host remoto (30a), detta gestione comprendendo di selezionare uno o più profili abilitati (Ps) comprendenti un’applicazione da eseguire e di allocare una partizione della porzione volatile (1084R) della memoria a detti uno o più profili abilitati (Ps), caratterizzato dal fatto che detto procedimento comprende inoltre le operazioni di: dividere (2005) l’area della memoria volatile (1084R) in una partizione (OSP) per il sistema operativo, una partizione (SPP) per ciascuno dell’uno o più profili abilitati e una partizione per un profilo scaricato (DPP), detta partizione per il profilo abilitato (SPP) e detta partizione per un profilo scaricato (DPP) avendo la stessa dimensione, allocare (2010) la partizione per il profilo abilitato (SPP) al profilo abilitato (Ps), mantenendo non accessibile la partizione per un profilo scaricato (DPP), durante un’operazione di scaricamento di un profilo (1004), accedere (2015) soltanto alla partizione per un profilo scaricato (DPP) allocando detta partizione per un profilo scaricato (DPP) al profilo scaricato (Pd), durante un’operazione di cambiamento di un profilo (1006) scambiare (2020) il profilo di scaricamento (Pd) dalla partizione per un profilo scaricato (DPP) a una delle partizioni per il profilo abilitato (SPP).
2. Procedimento secondo la rivendicazione 1, caratterizzato dal fatto che detta operazione di cambiamento di un profilo (1006) è effettuata dopo un reset di un modulo SIM (108a), in particolare dopo un ciclo di spegnimento e riaccensione.
3. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che detto allocare (2010) la partizione per il profilo abilitato (SPP) al profilo abilitato (Ps) è effettuato quando il modulo SIM (108a) è acceso.
4. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che detto modulo SIM a sottoscrizione multipla (108a) è una scheda eUICC.
5. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che detta memoria volatile (1084R) è una memoria RAM.
6. Procedimento secondo una qualsiasi delle rivendicazioni precedenti, caratterizzato dal fatto che detta gestione di un modulo SIM a sottoscrizione multipla (108a) comprende di selezionare un profilo abilitato (Ps) comprendente un’applicazione da eseguire e di allocare una partizione della memoria volatile (1084R) della memoria a detto profilo abilitato (Ps), e detto procedimento comprende inoltre le operazioni di: dividere (2005) l’area della memoria volatile (1084R) in una partizione per il sistema operativo (OSP), una partizione per il profilo abilitato (SPP) e una partizione per un profilo scaricato (DPP), detta partizione per il profilo abilitato (SPP) e detta partizione per un profilo scaricato (DPP) avendo la stessa dimensione, allocare (2010) la partizione per il profilo abilitato (SPP) al profilo abilitato (Ps), mantenendo non accessibile la partizione per un profilo scaricato (DPP), durante un’operazione di scaricamento di un profilo (1004), accedere (2015) soltanto alla partizione per un profilo scaricato (DPP) allocando detta partizione per un profilo scaricato (DPP) al profilo scaricato (Pd), durante un’operazione di cambiamento di un profilo (1006) scambiare (2020) il profilo di scaricamento (Pd) dalla partizione per un profilo scaricato (DPP) alla partizione per il profilo abilitato (SPP).
7. Modulo SIM a sottoscrizione multipla (108a) comprendente almeno un processore (1082a) e almeno una memoria (1084a) atta a memorizzare almeno un primo (P1) e un secondo (P2) profilo associati a un primo e a un secondo operatore di rete mobile rispettivi, in modo tale che un rispettivo contenuto (APP, AUTH, OTA, FS) possa essere associato a ciascun profilo (P1, P2), detta memoria (1084a) comprendendo una porzione volatile (1084R), in cui detto modulo SIM a sottoscrizione multipla (108a) è configurato per implementare il procedimento secondo una qualsiasi delle precedenti rivendicazioni da 1 a 6.
8. Modulo secondo la rivendicazione 7, caratterizzato dal fatto che detto modulo SIM a sottoscrizione multipla (108a) è una scheda eUICC.
9. Prodotto informatico che può essere caricato nella memoria di almeno un processore e che comprende porzioni di codice software per implementare il procedimento secondo una qualsiasi delle Rivendicazioni da 1 a 6.