IT201800004293A1 - Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico - Google Patents

Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico Download PDF

Info

Publication number
IT201800004293A1
IT201800004293A1 IT102018000004293A IT201800004293A IT201800004293A1 IT 201800004293 A1 IT201800004293 A1 IT 201800004293A1 IT 102018000004293 A IT102018000004293 A IT 102018000004293A IT 201800004293 A IT201800004293 A IT 201800004293A IT 201800004293 A1 IT201800004293 A1 IT 201800004293A1
Authority
IT
Italy
Prior art keywords
operating system
component
components
card
version
Prior art date
Application number
IT102018000004293A
Other languages
English (en)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed filed Critical
Priority to IT102018000004293A priority Critical patent/IT201800004293A1/it
Priority to EP19164859.1A priority patent/EP3550427A1/en
Priority to US16/375,695 priority patent/US11106472B2/en
Priority to CN201910271286.XA priority patent/CN110362350B/zh
Publication of IT201800004293A1 publication Critical patent/IT201800004293A1/it

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/4408—Boot device selection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4416—Network booting; Remote initial program loading [RIPL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates

Description

DESCRIZIONE dell’invenzione industriale intitolata:
“Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico”
TESTO DELLA DESCRIZIONE
Campo tecnico
Le forme di realizzazione della presente descrizione si riferiscono a soluzioni per un procedimento di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato utilizzante un caricatore di avvio o boot loader primario per caricare un sistema operativo selezionato.
Le forme di realizzazione della presente descrizione si riferiscono in particolare alla eUICC (Carta a Circuito Integrato Universale incorporata o embedded).
Sfondo
Le Carte a Circuito Integrato Universale (UICC, Universal Integrated Circuit Card), a cui viene sovente fatto riferimento come a carta di Modulo di Identità di Abbonato (SIM, Subscriber Identity Module), sono ampiamente utilizzate per permettere a dispositivi mobili di accedere a servizi forniti dagli Operatori di Rete Mobile (MNO, Mobile Network Operato).
In questo contesto, Figura 1 mostra una possibile architettura di una “apparecchiatura utente” 10, quale un dispositivo mobile, ad es. uno smartphone o un tablet, o un modulo di comunicazione mobile solitamente da utilizzare in sistemi embedded.
Generalmente, il dispositivo 10 comprende uno o più processori 102 connessi ad 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.
Ad esempio, l’interfaccia di comunicazione mobile 106 può comprendere un GSM (Sistema Globale per Comunicazioni Mobili, Global Mobile Communication System), ricetrasmettitore CDMA (Accesso Multiplo a Divisione di Codice, Code Division Multiple Access), W-CDMA (Accesso Multiplo a Divisione di Codice a Banda Larga, Wideband Code Division Multiple Access), UMTS (Sistema Universale di Telecomunicazioni Mobili, Universal Mobile Telecommunications System,), HSPA (Accesso al Pacchetto ad Alta Velocità, High-Speed Packet Access) e/o un ricetrasmettitore LTE (Evoluzione di Lungo Termine, Long Term Evolution).
Un dispositivo mobile comprende sovente anche un’interfaccia utente 110, quale uno schermo tattile. Al contrario, un modulo di comunicazione da utilizzare ad es., in sistemi embedded, quali sistemi di allarme, contatori del gas o altri tipi di sistemi di controllo e/o monitoraggio remoti, sovente non comprende un’interfaccia utente 110, ma un’interfaccia di comunicazione 112 al fine di scambiare dati con un ulteriore unità di elaborazione di un sistema embedded. Ad esempio, in questo caso, l’interfaccia 112 può essere un’interfaccia di comunicazione digitale, quale un’interfaccia di comunicazione UART (Ricevitore-Trasmettitore Asincrono Universale), SPI (Interfaccia Periferica Seriale), e/o USB (Bus Seriale Universale). Generalmente, l’unità di elaborazione 102 può anche essere direttamente il processore principale di un sistema embedded. In questo caso l’interfaccia 112 si può utilizzare per scambiare dati con uno o più sensori e/o attuatori. Ad esempio, in questo caso, l’interfaccia 112 si può implementare per mezzo di una o più interfacce analogiche e/o porte digitali di ingresso/uscita dell’unità di elaborazione 102.
Nella memoria 104 si può memorizzare ad es. un sistema operativo OS che è eseguito dal processore 102 e che gestisce le funzioni generali del dispositivo 10, quali la gestione dell’interfaccia utente 110 e/o dell’interfaccia di comunicazione 112 e la costituzione di una connessione con la stazione base BS tramite l’interfaccia 106. La memoria 104 può anche contenere applicazioni che sono eseguite dal sistema operativo OS. Ad esempio, nel caso di un dispositivo mobile, la memoria 104 comprende sovente un’applicazione di navigazione web o web browser WB.
Per stabilire una connessione con la stazione base BS, il dispositivo 10 è accoppiato ad un’unità di elaborazione 108 configurata per gestire l’identificazione di identità dell’utente. Ad esempio, solitamente un dispositivo mobile comprende un’possessore di carta per ricevere una carta comprendente un Modulo di Identità di Abbonato (SIM), che è solitamente chiamato carta SIM. Generalmente un corrispondente modulo SIM si può anche installare direttamente all’interno del dispositivo 10. Nell’esempio di Figura 1 si utilizza una Carta a Circuito Integrato Universale (UICC) 108, che è una carta intelligente o smart card sovente utilizzata in reti GSM ed UMTS. L’UICC assicura l’integrità e sicurezza di tutti i tipi di dati personali e contiene tipicamente alcune centinaia di kilobyte. Inoltre una UICC si può direttamente integrare nel dispositivo 10 ed è in questo caso sovente chiamata UICC embedded (eUICC).
Ad esempio, in una rete GSM, l’UICC 108 contiene un’applicazione SIM e in una rete UMTS un’applicazione USIM. Un’UICC può contenere svariate applicazioni, rendendo possibile per la stessa smart card fornire accesso ad entrambe le reti GSM e UMTS, e può anche fornire la memorizzazione di una rubrica telefonica ed altre applicazioni.
Di conseguenza, il riferimento ad un modulo SIM nel seguito della presente descrizione intende comprendere moduli per la suddetta rete e si applica anche al caso in cui un tale modulo SIM sia fornito su una carta SIM.
Come mostrato in Figura 2, un modulo SIM 108 comprende sovente uno o più processori 1082 ed una o più memorie 1084 per eseguire applicazioni memorizzate nella memoria 1084 del modulo 108. Ad esempio, il modulo SIM 108 può comprendere in aggiunta all’applicazione del Modulo di Identità di Abbonato (segno di riferimento SIM in Figura 2) almeno un’ulteriore applicazione APP. Ad esempio, questa applicazione APP può essere configurata per comunicare (direttamente, o indirettamente tramite il processore 102 e eventualmente il sistema operativo OS) con l’interfaccia di comunicazione mobile 106 al fine di inviare dati a e/o ricevere dati da un host remoto 30. Per questo scopo, l’host 30 può essere connesso tramite una rete 20, quale una Rete di Area Locale (LAN) o una Rete ad Estensione Geografica (WAN), quale internet,alla stazione base BS. Di conseguenza, la connessione tra l’host 30 e l’UICC 108 si può stabilire per mezzo della rete 20, la stazione base BS e l’interfaccia di comunicazione 108. Generalmente, la comunicazione si può avviare tramite l’host 30 o l’UICC 108. Ad esempio, l’applicazione APP può essere un’applicazione web server, che riceve richieste dal web browser WB di un dispositivo mobile 10 ed ottiene rispettivi contenuti 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 all’UICC 108 e l’UICC 108 può inviare una risposta di autenticazione all’host 30. La memoria o una pluralità di memorie 1084 si possono utilizzare anche per memorizzare immagini di dati comprendenti il profilo o i profili attinenti a diversi MNO e sistemi operativi relativi all’immagine. Per immagine si intende qui una rappresentazione strutturata di informazioni binarie, che sono anche criptate, che sono anche configurate per decriptare dati incapsulati, gestire diritti e controllare l’integrità di dati decriptati caricati.
Di conseguenza, una carta UICC in breve comprende solitamente un microprocessore ed una memoria, comprendente tipicamente una porzione volatile e non volatile. Tale memoria è configurata per memorizzare dati quali un sistema operativo, applet ed un profilo MNO che un dispositivo mobile può utilizzare per registrarsi ed interagire con un MNO. Le UICC possono essere introdotte in modo rimovibile in una fessura o slot di un dispositivo, cioè un dispositivo mobile, o esse possono anche essere embedded direttamente nei dispositivi, in questo caso esse sono chiamate eUICC. Le carte eUICC sono utili poiché per loro natura sono progettate per ricevere remotamente profili MNO.
Tali profili tuttavia devono essere personalizzati con dati specifici della carta, quali le chiavi di autenticazione. L’UICC Embedded è un’evoluzione delle UICC attuali che consente la possibilità di scaricare profili multipli sulla carta che rappresentano diversi operatori di telecomunicazione. Il caso di utilizzo principale, come menzionato, è di “saldare” un’eUICC in un dispositivo specifico; poiché l’eUICC non è rimovibile, se il proprietario del dispositivo vuole cambiare operatore di telecomunicazioni (ad es., da Vodafone a TelecomItalia), l’eUICC dovrebbe essere in grado di aggiornare le credenziali di telecomunicazione. Tali credenziali di telecomunicazione sono comprese in un profilo che rappresenta completamente un operatore nel contenimento di tutte le informazioni. Un punto mancante nelle carte eUICC è la possibilià (vero per le SIM tradizionali) per il MNO di personalizzare il sistema operativo.
Una carta eUICC può avere memorizzato nella propria memoria non volatile un sistema operativo ed il profilo di un primo MNO. Un profilo di un secondo MNO si può caricare in tale memoria tramite un’operazione di carico, risultando in una configurazione in cui il primo profilo è attivo ed il secondo profilo è disattivato. Successivamente con un’operazione di cancellazione sul primo profilo ed un’operazione di attivazione, la carta è configurata in modo da avere solo il secondo profilo, attivato per l’operazione. Il profilo ed il sistema operativo sono scaricati attraverso una rete quale la rete 20, da un host remoto quale l’host remoto 30, comprendente ad esempio uno o più server. Tali server possono corrispondere a server remoti MNO, definiti qualche volta come Creatore di Profilo, dove i profili sono progettati e scaricati attraverso la rete mobile nella carta.
Di conseguenza, nelle carte UICC embedded il profilo può cambiare, ma il sistema operativo non può.
Tuttavia sono anche note carte a circuito integrato che utilizzano un Boot Loader Primario.
Un Boot Loader Primario (PBL, Primary Boot Loader) è solitamente memorizzato in una porzione della memoria non volatile o in una memoria se si fornisce una pluralità di memorie non volatili.
Il PBL è configurato, quando attivato, per caricare un’immagine, ad es. contenente un profilo di un MNO, e/o lanciare (o effettuare il bootstrapping) di un sistema operativo relativo a tale immagine quando il MNO accede alla carta di per altre operazioni di gestione dell’immagine come la cancellazione.
A tal proposito, in figura 3A è schematicamente mostrata la memoria non volatile 1084 in un’area in cui è memorizzato un boot loader primario 11, che si utilizza per caricare in modo sicuro il software successivo, ad esempio dal server remoto MNO, in un’altra area della memoria 1084, rappresentata da un primo profilo P1 e sistema operativo OSD1 come un singolo primo pacchetto di dati 12a. Quindi, per cambiare il primo profilo P1 e sistema operativo OSD1 si esegue un’operazione di cancellazione DA per ottenere la configurazione della memoria 1084 di figura 3B, in cui non vi è pacchetto 12a poiché era stato cancellato, successivamente un’operazione di caricamento LA attraverso il boot loader primario 11, caricamento di un secondo pacchetto di dati 12b comprendente un secondo profilo P2 ed un corrispondente secondo sistema operativo OSD2.
La limitazione di “un profilo alla volta” è abbastanza forte nelle soluzioni di carte UICC utilizzanti il PBL, tuttavia vi sono vari scenari applicativi in cui la presenza di vari profili assieme può essere utile, quali:
- apparecchi telefonici a SIM multiple (ad es. doppia SIM);
- scaricamento di un profilo tramite OTA (è necessario un profilo aggiuntivo per offrire la connettività) – necessario per le soluzioni M2M; - backup di connettività, in modo che in caso di perdita di connettività di un primo MNO, sia possibile effettuare il back up su un altro MNO; - semplificazione del roaming, in modo che, ad esempio, a seconda del paese sia attivato uno specifico profilo).
Una soluzione al problema nel contesto del PBL utilizzante carte UICC verrebbe rappresentata dal fatto di avere una diversa immagine per ciascun MNO con un rispettivo boot loader primario. Tuttavia, poiché la dimensione del sistema operativo è tipicamente circa 600-700 kb per carte di fascia alta, mentre la dimensione del profilo è circa 150 kb. Di conseguenza, per ospitare due profili in una carta utilizzante un boot loader primario si avrebbe la necessità di carte con una memoria molto grande.
Sintesi
Sulla base della descrizione precedente, è sentita l’esigenza di soluzioni che superano uno o più degli svantaggi precedentemente sottolineati.
Secondo una o più forme di realizzazione, tale scopo è conseguito attraverso procedimenti aventi le caratteristiche specificatamente esposte nelle rivendicazioni che seguono. Le forme di realizzazione riguardano inoltre un sistema correlato per la personalizzazione di profili in carte a circuito integrato così come un corrispondente prodotto informatico correlato, caricabile nella memoria di almeno un computer e comprendente porzioni di codice software per eseguire le fasi del procedimento quando il prodotto è eseguito su un computer.
Come qui utilizzato, il riferimento ad un tale prodotto informatico intende essere equivalente al riferimento ad un mezzo leggibile su computer contenente istruzioni per controllare un sistema di computer per coordinare le prestazioni del procedimento. Il riferimento “ad almeno un computer” è evidentemente inteso per evidenziare l’eventualità che la presente descrizione venga implementata in una maniera distribuita/modulare.
Le rivendicazioni sono parte integrante dell’insegnamento tecnico della descrizione qui fornita.
Come menzionato in precedenza, la presente descrizione fornisce soluzioni riguardanti un procedimento di gestione di un sistema operativo in carte a circuito integrato, comprendente l’utilizzo di un boot loader primario per caricare un sistema operativo selezionato, comprendente suddividere un sistema operativo in una pluralità di componenti del sistema operativo,
associare uno o più di detti componenti in detta pluralità di componenti del sistema operativo ad un descrittore indicando una versione del componente del sistema operativo,
scaricare detti uno o più componenti in una memoria non volatile della carta a circuito integrato,
detta operazione di scaricamento comprendendo una verifica se vi è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato,
memorizzare il componente nella carta se la versione è diversa,
scartare il componente dall’operazione di scaricamento se la versione è la stessa.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere associare ciascun componente di detta pluralità di componenti del sistema operativo ad un descrittore indicante una versione del componente del sistema operativo,
scaricare ciascun componente di detti uno o più componenti nella memoria non volatile della carta a circuito integrato.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere
associare un componente determinato di detta pluralità di componenti del sistema operativo ad un descrittore indicante una versione del componente del sistema operativo,
scaricare detto componente di detti uno o più componenti nella memoria non volatile della carta a circuito integrato.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere che detta operazione di verifica comprenda confrontare la versione degli uno o più componenti che sono scaricati con la versione di corrispondenti componenti già memorizzati nella memoria della carta in una tabella di versioni anche residente nella memoria, in particolare nel boot loader primario.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere che detti uno o più componenti comprendano uno o più fra componenti di Kernel, Carta Java, protocollo SMS, Autenticazione, USIM, Piattaforma Globale.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere che quando è eseguito un cambio o switch del profilo comprende eseguire un’operazione di collegamento dinamico sui componenti memorizzati nella memoria dopo la fase di verifica se vi è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere
isolare gli uno o più componenti
definendo gli uno o più componenti come una libreria, comprendente un’interfaccia con i procedimenti esposti.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere
memorizzare nella carta ciascuno degli uno o più componenti
- un descrittore di importazione indicante
- quale modulo è importato e quale versione;
- quali API sono invocate
- un descrittore di esportazione indicante:
- quale API è esportata
- qual’è la versione del componente.
In forme di realizzazione diverse, il procedimento qui descritto può comprendere che è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato, e
un server di scaricamento reperisce le corrispondenti informazioni, in particolare da una tabella di versioni ed esegue detta verifica in corrispondenza del server.
La presente descrizione fornisce anche soluzioni riguardanti un sistema di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato, in particolare una carta eUICC, comprendente una carta a circuito integrato configurata per funzionare in un dispositivo mobile ed un server remoto configurato per scambiare dati con il dispositivo e la carta configurata per implementare il procedimento secondo qualsiasi delle precedenti forme di realizzazione.
La presente descrizione fornisce anche soluzioni riguardanti una carta a circuito integrato, in particolare una carta UICC o eUICC, configurata per funzionare nel sistema precedente.
La presente descrizione fornisce anche soluzioni riguardanti un prodotto informatico che si può caricare nella memoria di almeno un processore e comprende porzioni di codice software per implementare il procedimento secondo qualsiasi delle precedenti forme di realizzazione.
Breve descrizione delle figure
Le forme di realizzazione della presente descrizione verranno ora descritte facendo riferimento ai disegni annessi, che sono forniti puramente a titolo di esempio non limitativo ed in cui:
- Figure 1 a 3 sono già state descritte in precedenza; - Figura 4 mostra un diagramma di flusso che illustra una forma di realizzazione del procedimento qui descritto;
- Figura 5 mostra un diagramma di flusso che illustra ulteriori operazioni del procedimento qui descritto;
- Figura 6 mostra uno schema a blocchi di moduli software di una carta che implementa il procedimento qui descritto.
Descrizione Dettagliata
Nella seguente descrizione, numerosi dettagli specifici sono dati per fornire una comprensione approfondita di forme di realizzazione. Le forme di realizzazione si possono mettere in pratica senza uno o vari dettagli specifici, o con altri procedimenti, componenti, materiali, ecc. In altri casi, strutture materiali, o operazioni ben noti non sono mostrati o descritti nel dettaglio per evitare di rendere poco chiari gli aspetti delle forme di realizzazione.
Il riferimento per tutta questa descrizione ad “una forma di realizzazione”significa che una particolare caratteristica, struttura, o peculiarità descritta in abbinamento alla forma di realizzazione è compresa in almeno una forma di realizzazione. Di conseguenza, gli aspetti della frase “in una forma di realizzazione” in vari posti per tutta questa descrizione non fanno necessariamente tutti riferimento alla stessa forma di realizzazione. Inoltre, le particolari caratteristiche, strutture, o peculiarità si possono combinare in qualsiasi maniera appropriata in una o più forme di realizzazione.
Le intestazioni qui fornite sono solo per comodità e non interpretano l’ambito o significato delle forme di realizzazione.
Parti, elementi o componenti di Figure che sono già stati descritti con riferimento a Figure 1 a 3 sono indicati tramite gli stessi riferimenti precedentemente utilizzati in tali Figure; la descrizione di tali elementi precedentemente descritti non verrà ripetuta nel seguito al fine di non sovraccaricare la presente descrizione dettagliata.
La soluzione qui descritta si basa sostanzialmente sull’osservazione secondo cui anche se gli MNO richiedono sistemi operativi diversi, le differenze sono rappresentate da una personalizzazione dello stesso sistema operativo. Di conseguenza, considerando due sistemi operativi tramite due diversi MNO, essi sono molto simili, ad es. 95% di memoria contiene immagini con le stesse informazioni binarie, mentre solo il rimanente 5% è diverso.
In particolare, considerando il sistema operativo come comprendente una pluralità di componenti, solo alcuni componenti fra tali componenti sono assoggettati alla personalizzazione, mentre gli altri componenti rimangono gli stessi.
Quindi in breve, il procedimento qui descritto di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato, in particolare di gestione di sistemi operativi multipli in una carta a circuito integrato, utilizzando un boot loader primario, fornisce la suddivisione di ciascun sistema operativo in una pluralità di componenti del sistema operativo, quali Kernel, Carta Java, protocollo SMS, Autenticazione, USIM, Piattaforma Globale, quali, a titolo di esempio non limitativo, il componente della JCOP (Java Card OpenPlatform).
Successivamente ciascun componente del sistema operativo è associato ad un descrittore indicante una versione del sottomodulo del sistema operativo. Queste operazioni sono eseguite presso lo sviluppatore del sistema operativo, o eventualmente presso il fornitore del sistema operativo, cioè in modo remoto rispetto alla carta, e in ogni caso prima di scaricare il sistema operativo nella memoria di tale carta.
Quando un dato sistema operativo è scaricato nella carta, la carta è configurata attraverso la sua unità di elaborazione per memorizzare in una tabella disponibile nella tabella di memorie di carte la versione di ciascun componente del dato sistema operativo.
Quando è necessario scaricare un ulteriore sistema operativo nella carta, la versione dei componenti dell’ulteriore sistema operativo è confrontata con la versione dei componenti del dato sistema operativo.
Se la versione è la stessa, il componente del dato sistema operativo ed ulteriore sistema operativo sono considerati come binari uguali e lo scaricamento del corrispondente componente è scartato. Se la versione è diversa il componente dell’ulteriore sistema operativo è memorizzato nella memoria della carta. Quando la carta, dopo lo scaricamento, esegue il cambio di profilo comprendente il cambio del sistema operativo, l’ulteriore sistema operativo utilizza i moduli con la stessa versione del primo profilo precedentemente memorizzata ed esegue un collegamento dinamico per eseguire i moduli appena memorizzati aventi una versione diversa.
In figura 4 è mostrato un diagramma di flusso che rappresenta il procedimento di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato qui descritto. Con il riferimento numerico 300 è indicata una procedura di scaricamento di un primo sistema operativo OSD1 nella carta 108, che comprende un’operazione 310 di suddivisione del primo sistema operativo OSD1 in una pluralità di componenti C1…Cn. Tale suddivisione 310 è eseguita in corrispondenza del server MNO, ad es. un host 30, quando è progettato il sistema operativo OSD1. I componenti C1…Cn, che possono comprendere uno o più fra Kernel, Carta Java, protocollo SMS, Autenticazione, USIM, Piattaforma Globale, sono identificati nel sistema operativo OSD1. Questo è un elenco di esempio di componenti del sistema operativo, tuttavia si possono identificare altri componenti o si può eseguire un’altra suddivisione, ad esempio aggregare due dei suddetti componenti in un singolo componente.
Successivamente, è eseguita un’operazione 320 per associare ciascun componente del sistema operativo C1…Cn ad un rispettivo descrittore v11…v1n, che indica la versione del componente del sistema operativo. Inoltre questa operazione è eseguita preferibilmente quando si progetta il primo sistema operativo OSD1, scrivendo il descrittore di versione in un campo dello script di programmazione del componente. In generale per un i-esimo OSDi di sistema operativo e per un j-esimo componente Cj, il corrispondente descrittore di versione è indicato come vij, dove si trova l’indice del sistema operativo diverso OSDi che si può scaricare nella carta 108, mentre j è l’indice dei componenti Cj in cui esso si può suddividere con l’operazione 310, cioè j va da 1 a n.
In questo modo si ottengono i componenti C1…Cn comprendenti un rispettivo descrittore di versione v11…v1n.
Con 330 si indica un’operazione 330 di scaricamento nella carta 108 il primo sistema operativo OSD1. Il primo sistema operativo OSD1 è scaricato all’interno di un’immagine da caricare con il boot loader primario 11, residente nella memoria 1084. Quando una tale operazione 330 è eseguita, la carta 108 è configurata attraverso la sua unità di elaborazione 1082 per memorizzare in una tabella di versioni VT la versione v11...V1n dei componenti C1...Cn, come meglio specificato facendo riferimento alla Tabella 1 nel seguito. La tabella di versioni VT risiede nell’area di memoria del boot loader primario nella memoria non volatile 1084.
Successivamente, si esegue un’operazione 340 di memorizzazione dei componenti C1...Cn del primo sistema operativo nell’area di memoria dedicata nella memoria non volatile 1084.
Quando è necessario scaricare un secondo, ulteriore, sistema operativo OSD2, è eseguita una procedura 400 di scaricamento, che comprende l’applicazione delle operazioni 310 e 320 descritte sopra, ottenendo di conseguenza i componenti C1…Cn e corrispondenti versioni v21…V2n. Naturalmente la procedura 400 si può eseguire dopo l’operazione 340 dopo una quantità di tempo indeterminata, che può essere di una settimana, mesi o anche anno, ad es. solo quando è necessario caricare un’immagine di dati, comprendente il profilo e sistema operativo, di un altro MNO.
Successivamente, quando si esegue un’operazione 430 di scaricamento del secondo sistema operativo OSD2 nella carta 108, tale operazione di scaricamento comprende una fase 433 di confronto delle versioni v21…V2n dei componenti C1…Cn che sono scaricati con la versione di corrispondenti componenti già memorizzati nella carta 108, in questo caso v11…v1n, che sono memorizzati nella tabella di versioni VT (si veda Tabella 1 nel seguito).
Se la fase 433 indica che un componente che è scaricato ha una versione v2j che è diversa dalla versione v1j del corrispondente componente già memorizzato, allora sono eseguite una fase 437 e fase 439.
La fase 437 prevede la scrittura nella colonna della tabella VT corrispondente al sistema OSD2, che è inizializzato con le versioni v21…V2n, che sono uguali alle versioni v11…v1n, il numero della nuova versione o istanza del componente che si è scoperto avente una versione diversa alla fase 433.
La fase 439 prevede la memorizzazione di componenti aventi una versione diversa dalle versioni dei componenti già memorizzati nella carta.
Se alla fase 433 si scopre che versione del componente che è scaricato è la stessa del corrispondente componente del primo sistema operativo OSD1 memorizzato nella tabella VT, il componente è scartato, cioè non memorizzato nella memoria 1084. Tutti gli altri componenti che dipendono dal modulo scartato sono collegati con la corrispondente versione già memorizzata nella memoria 1084 della carta 108.
Si sottolinea che la procedura di scaricamento, comprendente le operazioni 330, 340, 430 non cambia l’interazione tra la carta 108 ed il server remoto del MNO 30, tale procedura di scaricamento essendo eseguita nella carta. La carta può inserire nel buffer i componenti in arrivo dei sistemi operativi, ad es. per eseguire successivamente il confronto 433, utilizzando ad esempio una porzione della memoria non volatile, o in forme di realizzazione diverse, della memoria volatile, a seconda ad esempio della dimensione della memoria disponibile, o anche, alternativamente, i componenti si possono scartare al volo, ad es. senza memorizzazione.
Dopo lo scaricamento di tutti i componenti del secondo sistema operativo OSD2, e di conseguenza la memorizzazione dei soli aventi una versione diversa nella memoria 1084 vi saranno memorizzati tutti i componenti di OSD1 ed alcuni componenti (solitamente uno o due) di OSD2. Dopo la procedura 400 si attende che venga richiesta una procedura di cambio di profilo 500.
Come meglio descritto nel dettaglio nel seguito facendo riferimento alle figure 5 e 6, può avere luogo un cambio di profilo. Se si esegue un cambio di profilo può essere ad esempio necessario caricare il secondo sistema operativo OSD2. In questo caso, al posto del componente Cj o dei componenti scartati si utilizza il corrispondente componente del primo sistema operativo OSD1 che è già memorizzato.
Qui di seguito nella tabella 1 è rappresentata una possibile forma di realizzazione della tabella VT. Nella prima colonna, che è anche la colonna indice della tabella VT, è contenuto un campo corrispondente al j-esimo componente Cj. Nelle colonne seguenti sono inserite le versioni vij dei componenti per ciascun i-esimo sistema operativo OSDi.
Tabella 1
Nell’esempio mostrato, dopo lo scaricamento con la procedura 100 del primo sistema operativo OSD1, quando si scarica il secondo sistema operativo OSD2 nell’operazione di confronto si scopre alla fase 433 che i componente della Carta Java, Piattaforma Globale, USIM e ISIM, ipotizzando che essi siano valutati nelle sequenze come C1...C4, abbiano la stessa versione v21...V24, quindi sono scartati i corrispondenti moduli del secondo sistema operativo, cioè non memorizzati nella memoria 1084. Si scopre che il componente di Autenticazione, cioè C5, alla fase 233 ha un diverso descrittore di versione, v.1.3.0 invece di v.1.2.1, quindi il corrispondente componente C5 è memorizzato per il secondo sistema operativo nella memoria 1084.
La procedura 200 si può naturalmente replicare quando si scarica una terza immagine contenente un terzo profilo e terzo sistema operativo OSD3, come mostrato in Tabella 2, dove si aggiunge una colonna indicante le stesse istanze del componente Cj. Come mostrato, nell’esempio rappresentato in Tabella 2 si possono avere 1, 2 o 3 istanze dello stesso modulo di OS. La procedura 400 si può naturalmente replicare anche per scaricare ulteriori sistemi operativi.
Tabella 2
Quando si memorizza una pluralità di sistemi operativi, è possibile naturalmente che vi siano istanze multiple dello stesso componente, nell’esempio il componente di Autenticazione ha tre diverse istanze, mentre il componente ISIM ne ha due.
Quando si esegue un’operazione di cancellazione si devono preservare tutti i componenti del sistema operativo che sono referenziati da almeno un profilo MNO – cancellare ad es. il secondo profilo corrispondente a OSD2 risulterebbe nel rimuovere solo un’istanza, cioè v.1.3.0 del componente di Autenticazione.
In figura 5 si indica anche una procedura 500 che è eseguita quando è eseguito un cambio di profilo.
In una fase 510 si valuta se è richiesto un cambio di profilo, cioè caricando ad esempio il secondo sistema operativo OSD2 attraverso il boot loader primario 11 al posto del primo sistema operativo OSD1.
In caso affermativo, basandosi sui contenuti della tabella VT per il secondo sistema operativo OSD2, in una fase 520 sono caricati nella memoria volatile i componenti del primo sistema operativo OSD1 che hanno lo stesso descrittore di versione vij. Tali componenti erano stati memorizzati mentre si eseguiva l’operazione di scaricamento 330 del primo sistema operativo OSD1. Inoltre nella fase 520 sono caricati il componente o componenti del secondo sistema operativo OSD2 memorizzati nella fase 440, poiché essi hanno un diverso descrittore di versione vij: nell’esempio di Tabella 1 ciò corrisponde al solo componente di Autenticazione, ad es. v25.
Successivamente si esegue un’operazione di collegamento dinamico 330 sul componente avente il componente o i componenti del secondo sistema operativo OSD2 con un diverso descrittore di versione vij. Ciò è eseguito in modo che quando si esegue il secondo sistema operativo OSD2, quando si esegue un eseguibile al tempo di esecuzione, è eseguito un collegamento dinamico, in generale copiando il contenuto delle librerie dalla memoria permanente nella RAM, e riempiendo le tabelle di salto e riposizionando il puntatore. Il collegamento dinamico a titolo di esempio corrisponde al caricamento e collegamento delle librerie, che come si vedrà corrispondono ai componenti, necessari per l’eseguibile.
In particolare per supportare l’operazione di collegamento dinamico 530 la fase di suddivisione 310 esegue una sottofase di isolamento dei componenti C1…C2 che a sua volta comprende la definizione di ciascuno dei componenti C1…Cn come una libreria. In particolare, in una maniera di per sé nota, ciascun componente Cj come una libreria comprende un’interfaccia con i procedimenti esposti, ad es. un elenco che dichiara le funzioni del componente/libreria agli altri componenti/libreria. Inoltre ciò può corrispondere all’intestazione .h nel linguaggio C. Le librerie dipendono le une sulle altre per la dipendenza.
Successivamente, per supportare l’operazione di collegamento dinamico 530 è anche previsto che nella memoria 1084 della carta 108 sia memorizzata un’ulteriore tabella che per ciascun componente Cj memorizza:
- un descrittore di importazione indicante
quale modulo Cj è importato e quale versione Vij; quali API sono invocate;
- un descrittore di esportazione indicante:
o quale API è esportata
o qual’è la versione del componente.
Tale ulteriore tabella contenente per ciascun componente di ciascun sistema operativo OSDi il descrittore di importazione IC e il descrittore di esportazione EC si può memorizzare nella memoria 1084, preferibilmente nell’area del PBL.
A tal proposito in figura 6 è schematicamente rappresentato un componente C1 di un’API della Carta Java, del dato sistema operativo ad es. OSD1, che durante l’esecuzione deve collegarsi al componente C4, utilizzando una funzione F, nell’esempio getstate().
In figura 6 sono mostrate due istanze del componente GlobalPlatform, una prima istanza C4(v14) ed una seconda C4(v24). Si sottolinea che questo esempio è diverso da quello mostrato in Tabella 1 poiché l’istanza di versione v14 è la versione 1.3.0 e l’istanza di versione v24 è la versione 1.4.0 ad avere due istanze per questo componente.
La seconda istanza C4(v24) è associata ad un descrittore di esportazione EC memorizzato nell’ulteriore tabella descritta sopra nella memoria 1084 indicante quale API è esportata, in questo caso la funzione getstate() e qual’è la versione del componente, in questo caso v24.
Il componente C1 della Carta Java è associato in tale ulteriore tabella ad un descrittore di importazione IC indicante quale componente è importato e quale versione e quali API sono invocate.
nell’esempio si indica un primo componente che è importato con la versione, USIM v 1.2, e l’API invocata, [API: getBuffer], ed un secondo componente che è importato con la versione, che è l’istanza mostrata di Globalplatform, C4(v24), ad es. GlobalPlatform v1.3, e l’API invocata [API: getState].
Di conseguenza quando l’API della Carta Java invoca getState di GlobalPlatform essa è reindirizzata verso l’istanza di componente Globalplatform, C4(v24), attraverso un proxy PX associato al componente Globalplatform, C4(v24). Il proxy PX è un procedimento, in particolare una struttura o struct, che si utilizza nel linguaggio C per richiamare la funzione F. L’API della Carta Java API richiama il procedimento, richiama la funzione F ed il proxy esegue un’indirezione.
Durante l’esecuzione, qualsiasi invocazione funzionale è eseguita via un procedimento di indirezione. Il procedimento di indirezione dipende dal linguaggio del programma.
Nelle smart card si utilizza tipicamente il linguaggio “C”, dove l’indirezione comprende invocare il procedimento attraverso una struct.
Durante il collegamento dinamico, l’utilizzo dei descrittori di importazione e di esportazione è utilizzato per mettere, nel componente di importazione di un primo componente, nell’esempio C1, il collegamento al componente di esportazione di un secondo componente, nell’esempio C4.
Nei sistemi di carta dove il sistema operativo è scaricato via etere, come nei sistemi OFL (Open Firmware Loader), la carta esegue un’autenticazione dell’immagine contenente il sistema operativo che è scaricato, verificando una firma crittografica rappresentata da una chiave pubblica.
Secondo un ulteriore aspetto della soluzione qui descritta, non solo il sistema operativo, ma ciascun componente del sistema operativo C1..Cn del sistema operativo è firmato in modo crittografico con una crittografia asimmetrica utilizzante una chiave pubblica che identifica l’emettitore o fornitore del sistema operativo.
La carta è successivamente configurata per: verificare la firma crittografica di ciascun componente del sistema operativo C1..Cn che è scaricato, eseguire il collegamento dinamico solo su componenti verificati come aventi una firma crittografica calcolata dallo stesso emettitore, ad es. il fornitore del sistema operativo.
Di conseguenza, in generale il procedimento di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato utilizzante un boot loader primario per caricare un sistema operativo selezionato, comprende
suddividere 310 un sistema operativo, quale OSD1, OSD2 in una pluralità di componenti del sistema operativo, C1..Cn,
associare 320 uno o più di detti componenti in detta pluralità di componenti del sistema operativo C1…Cn ad un descrittore indicante una versione, ad es. v11…v1n del componente del sistema operativo,
scaricare 330, 430 detti uno o più componenti in una memoria non volatile, ad es. memoria 1084 della carta a circuito integrato 108,
detta operazione di scaricamento comprendendo la verifica se vi è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato. La verifica è eseguita tramite l’operazione di confronto 233 con la tabella di versioni VT.
In caso negativo, se la versione è diversa, si prevede di memorizzare 239 il componente nella carta,
o altrimenti scartare il componente dall’operazione di scaricamento se si scopre che la versione è la stessa.
Come menzionato, gli altri componenti che dipendono dal modulo scartato sono collegati con la corrispondente versione già memorizzata nella memoria 1084 della carta 108, mentre un componente memorizzato dopo la verifica è dinamicamente collegato agli altri componenti quando si attiva il cambio di profilo).
Si sottolinea che nelle forme di realizzazione diverse gli uno o più componenti che sono scaricati possono essere un singolo componente. Ciò può succedere per motivi di manutenzione, cioè è necessario scaricare un componente per sostituire un componente malfunzionante o corrotto. In quel caso il componente sostitutivo si può associare ad un diverso descrittore di versione.
Naturalmente si può eseguire un’operazione di manutenzione scaricando un intero nuovo sistema operativo con il solo componente sostitutivo associato ad un diverso descrittore di versione. Tutti i componenti con lo stesso descrittore, come descritto sopra, verranno semplicemente scartati dall’operazione di scaricamento.
Per lo scaricamento, il meccanismo ipotizza che non vi sia alcun cambiamento nel protocollo di scaricamento sull’UICC. La soluzione descritta ottimizzare l’utilizzo della memoria della carta.
In forme di realizzazione diverse è tuttavia possibile ottimizzare anche il protocollo di scaricamento.
In tale forma di realizzazione il server MNO, ad esempio coincidente con l’host 30 ospita un Creatore Personale, reperisce l’elenco di componenti sulla carta UICC 108. Ciò si può effettuare avendo accesso alla tabella di versioni VT.
Successivamente il server scarica solo i componenti che necessitano essere scaricati, cioè che non sono presenti sull’UICC.
Di conseguenza il procedimento in questa forma di realizzazione prevede che vi sia memorizzato nella carta 108 un componente del sistema operativo associato ad una stessa versione del componente che è scaricato, il server di scaricamento reperisce le corrispondenti informazioni, in particolare dalla tabella di versioni VT, ed esegue detta verifica in corrispondenza del server. La verifica comprendendo l’esecuzione di operazioni corrispondenti alla fase 233, che sono eseguite nel server invece di essere eseguite nella carta, anche lo scarto del componente dallo scaricamento ha luogo nel server, mentre la memorizzazione 239 è eseguita dal server nella carta connessa in modo remoto.
La soluzione descritta ha di conseguenza vari vantaggi rispetto alle soluzioni della tecnica anteriore.
Il procedimento qui descritto consente di gestire sistemi operativi multipli, o anche di sostituire singoli componenti del sistema operativo in carte utilizzanti un boot loader primario per caricare l’immagine di dati degli MNO comprendenti il sistema operativo.
Il procedimento qui descritto consente di gestire sistemi operativi multipli con un utilizzo di memoria di chip significativamente inferiore rispetto alle soluzioni note.
Il procedimento qui descritto può anche ridurre la quantità di dati trasmessi dal server remoto, per memorizzare un sistema operativo.
Naturalmente, senza pregiudizio per il principio dell’invenzione, i dettagli di costruzione e le forme di realizzazione possono variare ampiamente rispetto a ciò che è stato descritto e qui illustrato puramente a titolo di esempio, senza così discostarsi dall’ambito della presente invenzione, come definito dalle successive rivendicazioni.

Claims (13)

  1. RIVENDICAZIONI 1. Procedimento di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato comprendente l’utilizzo di un boot loader primario per caricare un sistema operativo selezionato, suddividere un sistema operativo in una pluralità di componenti del sistema operativo, associare uno o più di detti componenti in detta pluralità di componenti del sistema operativo ad un descrittore indicante una versione del componente del sistema operativo, scaricare detti uno o più componenti in una memoria non volatile della carta a circuito integrato, detta operazione di scaricamento comprendendo una verifica se vi è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato, memorizzare il componente nella carta se la versione è diversa, scartare il componente dall’operazione di scaricamento se la versione è la stessa.
  2. 2. Procedimento secondo la rivendicazione 1, comprendente associare ciascun componente di detta pluralità di componenti del sistema operativo ad un descrittore indicante una versione del componente del sistema operativo, scaricare ciascun componente di detti uno o più componenti nella memoria non volatile della carta a circuito integrato.
  3. 3. Procedimento secondo la rivendicazione 1, comprendente associare un componente determinato di detta pluralità di componenti del sistema operativo ad un descrittore indicante una versione del componente del sistema operativo, scaricare detto componente di detti uno o più componenti nella memoria non volatile della carta a circuito integrato.
  4. 4. Procedimento secondo la rivendicazione 1, dove detta operazione di verifica comprende confrontare la versione degli uno o più componenti che sono scaricati con la versione di corrispondenti componenti già memorizzati nella memoria della carta in una tabella di versioni anche residente nella memoria, in particolare nel boot loader primario.
  5. 5. Procedimento secondo la rivendicazione 1 dove detti uno o più componenti comprendono uno o più fra componenti di Kernel, Carta Java, protocollo SMS, Autenticazione, USIM, di Piattaforma Globale.
  6. 6. Procedimento secondo la rivendicazione 1 dove quando si esegue un cambio di profilo (300) comprende eseguire un’operazione di collegamento dinamico (330) sui componenti memorizzati nella memoria dopo la fase di verifica se vi è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato.
  7. 7. Procedimento secondo la rivendicazione 6 comprendente isolare gli uno o più componenti definendo gli uno o più componenti come una libreria, comprendente un’interfaccia con i procedimenti esposti.
  8. 8. Procedimento secondo la rivendicazione 7 comprendente memorizzare nella carta ciascuno degli uno o più componenti - un descrittore di importazione indicante - quale modulo è importato e quale versione; - quali API sono invocate - un descrittore di esportazione indicante: - quale API è esportata - qual’è la versione del componente.
  9. 9. Procedimento secondo la rivendicazione 1, in cui detta verifica se vi è memorizzato nella carta un componente del sistema operativo associato ad una stessa versione del componente che è scaricato, comprende che un server di scaricamento reperisca le corrispondenti informazioni, in particolare da una tabella di versioni ed esegua detta verifica in corrispondenza del server.
  10. 10. Procedimento secondo la rivendicazione 1, in cui ciascun componente di sistema operativo del sistema operativo è firmato in modo crittografico con una crittografia asimmetrica utilizzando una chiave pubblica che identifica un emettitore del sistema operativo, la carta essendo successivamente configurata per: verificare la firma crittografica di ciascun componente del sistema operativo che è scaricato, eseguire il collegamento dinamico solo su componenti verificati come aventi una firma crittografica calcolata dallo stesso fornitore del sistema operativo.
  11. 11. Sistema di gestione della memorizzazione di un sistema operativo in una carta a circuito integrato, in particolare una carta eUICC, comprendente una carta a circuito integrato configurata per funzionare in un dispositivo mobile ed un server remoto configurato per scambiare dati con il dispositivo e la carta configurata per implementare il procedimento secondo qualsiasi delle rivendicazioni precedenti 1 a 10.
  12. 12. Carta a circuito integrato configurata per funzionare nel sistema secondo la rivendicazione 11.
  13. 13. Prodotto informatico che si può caricare nella memoria di almeno un processore e comprende porzioni di codice software per implementare il procedimento secondo qualsiasi delle Rivendicazioni 1 a 10.
IT102018000004293A 2018-04-06 2018-04-06 Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico IT201800004293A1 (it)

Priority Applications (4)

Application Number Priority Date Filing Date Title
IT102018000004293A IT201800004293A1 (it) 2018-04-06 2018-04-06 Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico
EP19164859.1A EP3550427A1 (en) 2018-04-06 2019-03-25 Method for managing multiple operating systems in integrated circuit cards, corresponding system and computer program product
US16/375,695 US11106472B2 (en) 2018-04-06 2019-04-04 Method for managing multiple operating systems in integrated circuit cards, corresponding system and computer program product
CN201910271286.XA CN110362350B (zh) 2018-04-06 2019-04-04 管理集成电路卡中的多个操作系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
IT102018000004293A IT201800004293A1 (it) 2018-04-06 2018-04-06 Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico

Publications (1)

Publication Number Publication Date
IT201800004293A1 true IT201800004293A1 (it) 2019-10-06

Family

ID=62530514

Family Applications (1)

Application Number Title Priority Date Filing Date
IT102018000004293A IT201800004293A1 (it) 2018-04-06 2018-04-06 Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico

Country Status (4)

Country Link
US (1) US11106472B2 (it)
EP (1) EP3550427A1 (it)
CN (1) CN110362350B (it)
IT (1) IT201800004293A1 (it)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110401687B (zh) * 2018-04-25 2021-10-22 华为技术有限公司 一种配置文件传输方法及相关设备和存储介质
EP3672300A1 (en) * 2018-12-21 2020-06-24 Telefonica, S.A. Portable secure elements for subscription manager roles

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100180271A1 (en) * 2003-09-03 2010-07-15 The Directv Group, Inc. Automatic software update detection and flexible installer for set-top boxes
EP2448216A1 (en) * 2010-10-28 2012-05-02 Apple Inc. Methods and apparatus for delivering electronic identification components over a wireless network
US20130019236A1 (en) * 2011-07-12 2013-01-17 Masaki Nakagawa Communication device, update method, and computer-readable storage medium

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4865972B2 (ja) * 1999-07-15 2012-02-01 トムソン ライセンシング 集積回路カードを使用してリモートサーバからのコンテンツのダウンロードを容易にするための方法および装置
KR100400542B1 (ko) * 2001-02-28 2003-10-08 엘지전자 주식회사 디지털 방송 수신장치의 광고를 이용한 시스템 소프트웨어업그레이드 장치 및 방법
US9639347B2 (en) 2009-12-21 2017-05-02 International Business Machines Corporation Updating a firmware package
US8837449B2 (en) * 2010-10-29 2014-09-16 Cellco Partnership Universal integrated circuit card updates in a hybrid network
JP5910297B2 (ja) * 2012-01-17 2016-04-27 ソニー株式会社 情報処理装置、ｉｃチップ、情報処理方法、プログラム、及び情報処理システム
US9432067B2 (en) * 2014-05-30 2016-08-30 Apple Inc. Supporting SIM toolkit applications in embedded UICCs
CN104899091B (zh) * 2015-07-02 2018-11-27 中国地质大学（武汉） 一种智能嵌入式设备多操作系统切换方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100180271A1 (en) * 2003-09-03 2010-07-15 The Directv Group, Inc. Automatic software update detection and flexible installer for set-top boxes
EP2448216A1 (en) * 2010-10-28 2012-05-02 Apple Inc. Methods and apparatus for delivering electronic identification components over a wireless network
US20130019236A1 (en) * 2011-07-12 2013-01-17 Masaki Nakagawa Communication device, update method, and computer-readable storage medium

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHIH-CHIEH HAN ET AL: "A Dynamic Operating System for Sensor Nodes", USENIX, 24 May 2005 (2005-05-24), pages 163 - 176, XP061012324, DOI: 10.1145/1067170.1067188 *

Also Published As

Publication number Publication date
US20190310860A1 (en) 2019-10-10
US11106472B2 (en) 2021-08-31
CN110362350A (zh) 2019-10-22
EP3550427A1 (en) 2019-10-09
CN110362350B (zh) 2023-09-22

Similar Documents

Publication Publication Date Title
CN103970563B (zh) 动态加载安卓类的方法
ITUB20151246A1 (it) Procedimento per gestire una pluralita' di profili in modulo sim, e corrispondente modulo sim e prodotto informatico
CN109144478B (zh) 组件框架系统以及组件框架系统的使用方法
US9390259B2 (en) Method for activating an operating system in a security module
KR102083751B1 (ko) 보안 요소에서의 객체들을 관리하기 위한 방법
CN103455349A (zh) 应用程序访问智能卡的方法和装置
US10430177B2 (en) Method for updating a package
IT201800004293A1 (it) Procedimento di gestione di sistemi operativi multipli in carte a circuito integrato, corrispondente sistema e prodotto informatico
JP5511874B2 (ja) セキュリティサービスに実装するシステムおよび方法
CN109040169A (zh) 管理配置文件的通信装置和方法
US10531296B2 (en) Method for loading a subscription into an embedded security element of a mobile terminal
CN110321739B (zh) 集成电路卡的个性化方法、对应的系统和计算机程序产品
US20170262385A1 (en) Method and apparatus for data storage service
CN109857374B (zh) 移动应用的开发方法及装置
CN109933407B (zh) 区块链dapp虚拟机、数据处理方法和计算设备
US20080320490A1 (en) Method, apparatus and computer program product for providing sub-process resource management
KR20170089887A (ko) 보안 엘리먼트를 공장 상태로 복원하는 방법
CN112214213A (zh) Linux内核的开发和管理方法、装置、计算机设备和存储介质
JP2021069050A (ja) ｅＵＩＣＣおよびｅＵＩＣＣの発行方法
CN108804236B (zh) 一种aidl文件的共享方法及系统
KR20160134419A (ko) 복수의 가입자 식별 정보를 포함하는 스마트 카드를 이용한 가입자 식별 정보 변경 방법, 단말 및 컴퓨터 프로그램
WO2019157891A1 (zh) 应用安装方法、应用安装包的生成方法
IT201900017561A1 (it) "Procedimento per introdurre dati di personalizzazione in memorie non volatile di una pluralità di circuiti integrati, in particolare in carte a circuito integrato, corrispondente sistema e prodotto informatico"
CN110737911A (zh) 数据处理方法、装置和计算机可读存储介质
EP3682323B1 (en) Method for amending the firmware of a resource constrained device