Patent Description:
Embodiments of the present disclosure relate in particular to eUICC (embedded Universal Integrated Circuit Card).

Universal Integrated Circuit Cards (UICCs), often referred as Subscriber Identity Module (SIM) card, are widely used to enable the mobile devices to access services provided by Mobile Network Operators (MNOs).

In this context, <FIG> shows a possible architecture of a "user equipment" <NUM>, such as a mobile device, e.g. a smartphone or a tablet, or a mobile communication module usually to be used in embedded systems.

Generally, the device <NUM> comprises one or more processors <NUM> connected to one or more memories <NUM>. The device <NUM> comprises moreover at least one mobile communication interface <NUM> for communication with a base station BS.

For example, the mobile communication interface <NUM> may comprise a GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access) transceiver, W-CDMA (Wideband Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access) and/or LTE (Long Term Evolution) transceiver.

A mobile device comprises often also a user interface <NUM>, such as a touchscreen. Conversely, a communication module to be used, e.g., in embedded systems, such as alarm systems, gas meters or other types of remote monitoring and/or control systems, often does not comprise a user interface <NUM>, but a communication interface <NUM> in order to exchange data with a further processing unit of an embedded system. For example, in this case, the interface <NUM> may be a digital communication interface, such as a UART (Universal Asynchronous Receiver-Transmitter), SPI (Serial Peripheral Interface) and/or USB (Universal Serial Bus) communication interface. Generally, the processing unit <NUM> may also be directly the main processor of an embedded system. In this case the interface <NUM> may be used to exchange data with one or more sensors and/or actuators. For example, in this case, the interface <NUM> may be implemented by means of one or more analog interfaces and/or digital input/output ports of the processing unit <NUM>.

In the memory <NUM> may be stored e.g. an operating system OS being executed by the processor <NUM> and which manages the general functions of the device <NUM>, such as the management of the user interface <NUM> and/or the communication interface <NUM> and the establishment of a connection to the base station BS via the interface <NUM>. The memory <NUM> may also contain applications being executed by the operating system OS. For example, in the case of a mobile device, the memory <NUM> often comprises a web browser application WB.

For establishing a connection with the base station BS, the device <NUM> is coupled to a processing unit <NUM> configured to manage the identity identification of the user. For example, usually a mobile device comprises a card holder for receiving a card comprising a Subscriber Identity Module (SIM), which is usually called SIM card. Generally a corresponding SIM module may also be installed directly within the device <NUM>. In the example of <FIG> it is used a Universal Integrated Circuit Card (UICC) <NUM>, which is a smart card often used in GSM and UMTS networks. The UICC ensures the integrity and security of all kinds of personal data and typically holds a few hundred kilobytes. Also a UICC may be integrated directly in the device <NUM> and is in this case often called embedded UICC (eUICC).

For example, in a GSM network, the UICC <NUM> contains a SIM application and in a UMTS network a USIM application. A UICC may contain several applications, making it possible for the same smart card to give access to both GSM and UMTS networks, and may also provide storage of a phone book and other applications.

Accordingly, the reference to a SIM module in the following of the present description is intended to include modules for the above network and applies also the case in which such a SIM module is provided on a SIM card.

As shown in <FIG>, a SIM module <NUM> often comprises one and more processors <NUM> and one or more memories <NUM> for executing applications stored in the memory <NUM> of the module <NUM>. For example, the SIM module <NUM> may comprise in addition to the Subscriber Identity Module application (reference sign SIM in <FIG>) at least one further application APP. For example, this application APP may be configured to communicate (directly, or indirectly via the processor <NUM> and possibly the operating system OS) with the mobile communication interface <NUM> in order to send data to and/or receive data from a remote host <NUM>. For this purpose, the host <NUM> may be connected via a network <NUM>, such as a Local Area Network (LAN) or a Wide Area Network (WAN), such as the internet, to the base station BS. Accordingly, connection between the host <NUM> and the UICC <NUM> may be established by means of the network <NUM>, the base station BS and the communication interface <NUM>. Generally, the communication may be initiated by the host <NUM> or the UICC <NUM>. For example, the application APP may be a web server application, which receives requests from the web browser WB of a mobile device <NUM> and obtains respective content from a remote host <NUM>, such as a web server. The application APP may also be an authentication application. In this case, the host <NUM> may send an authentication request to the UICC <NUM> and the UICC <NUM> may send an authentication response to the host <NUM>. The memory or a plurality of memories <NUM> is also used to store data images comprising the profile or the profiles pertaining different MNOs and operating systems related to the image. For image is here intended a structured representation of binary information, which is also encrypted, which is also configured to decrypt encapsulated data, manage rights and check the integrity of loaded decrypted data.

Thus, a UICC card in short usually comprises a microprocessor and a memory, typically including a non volatile and a volatile portion. Such memory is configured to store data such as an operating system, applets and an MNO profile that a mobile device utilizes to register and interact with an MNO. The UICC can be removably introduced in a slot of a device, i.e. a mobile device, or they can also be embedded directly into the devices, in this case they are called eUICC. eUICC cards are useful since for their nature are designed to remotely receive MNO profiles.

Such profiles however have to be personalized with data specific of the card, such as the authentication keys.

The Embedded UICC is an evolution of the actual UICCs that allows the possibility of downloading multiple profiles on the card representing different telecom operators. The main use case, as mentioned, is to "solder" an eUICC in a specific device; as the eUICC is not removable, if the device owner wants to change telecom operator (e.g. from Vodafone to TelecomItalia), the eUICC should be able to update the telecom credentials. Such telecom credentials are included in a profile that fully represents one operator in containing all the information. One missing point in the eUICC cards is the possibility (true for traditional SIMs) for the MNO to customize the operating system.

An eUICC card can have stored in its non volatile memory an operating system and the profile of a first MNO. A profile of a second MNO can be loaded in such memory by a load operation, resulting in a configuration in which the first profile is active and the second profile is disabled. Then with a delete operation on the first profile and an enable operation, the card is configured sot have the sole second profile, enabled for operation. The profile and the operating system are downloaded through a network such as the network <NUM>, from a remote host such as the remote host <NUM>, comprising for instance one or more or server. Such servers can correspond to MNO remote servers, sometimes defines as Profile Creator, where the profiles are designed and the downloaded through the mobile network in the card.

Thus, in embedded UICC cards the profile can change, but the operating system cannot.

However also are known integrated circuit cards which use a Primary Boot Loader.

A Primary Boot loader (PBL) is usually stored in a portion of the non volatile memory or in one memory if a plurality of non volatile memory is provided.

The PBL is configured, when activated, for loading an image, e.g. containing a profile of a MNO, and/or launching (or bootstrapping) an operating system related to such image when the MNO accesses the card of for other operations of management of the image such as deletion.

To this regard, in <FIG> is shown schematically the non volatile memory <NUM> in an area of which is stored a primary boot loader <NUM>, which is used for securely loading the subsequent software, for instance from the MNO remote server, in another area of the memory <NUM>, represented by a first profile P1 and operating system OSD1 as a single first data package 12a. Therefore, to change the first profile P1 and operating system OSD1 is performed a delete operation DA to obtain the configuration of the memory <NUM> of <FIG>, in which there is no package 12a as it was deleted, then a load operation LA through the primary boot loader <NUM>, loading a second data package 12b comprising a second profile P2 and a corresponding second operating system OSD2.

The limitation of "one profile per time" is quite strong in solutions of UICC cards using the PBL, however there are several applicative scenarios in which the presence of several profiles together may be useful, such as:.

A solution to the problem in the context of PBL using UICC cards would be represented by having different image for each MNO with a respective primary boot loader. However, since typically the operating system size is around <NUM>-<NUM> kb for high end cards, while profile size is around <NUM> kb. Thus, to accommodate two profiles in a card using a primary boot loader one would need cards with very large memory.

Documents <CIT>, <CIT>, <CIT>, <CIT> and Chih-Chieh Han et al: "A Dynamic Operating System for Sensor Nodes" also describe solutions which are pertinent to the technology background.

On the basis of the foregoing description, the need is felt for solutions which overcome one or more of the previously outlined drawbacks.

According to one or more embodiments, such an object is achieved through methods having the features specifically set forth in the claims that follow. Embodiments moreover concerns a related system for the personalization of profiles in integrated circuit cards as well as a corresponding related computer program product, loadable in the memory of at least one computer and including software code portions for performing the steps of the method when the product is run on a computer. As used herein, reference to such a computer program product is intended to be equivalent to reference to a computer-readable medium containing instructions for controlling a computer system to coordinate the performance of the method. Reference to "at least one computer" is evidently intended to highlight the possibility for the present disclosure to be implemented in a distributed/modular fashion.

The claims are an integral part of the technical teaching of the disclosure provided herein.

As mentioned in the foregoing, the present disclosure provides solutions regarding a method for managing the storage of an operating system in an integrated circuit cards including using a primary boot loader to load selected operating system, including.

In variant embodiments, the method here described may include associating each component of said plurality of operating system components to a descriptor indicating a version of the operating system component,
downloading each component of said one or more components to the non-volatile memory of the integrated circuit card.

In variant embodiments, the method here described may include.

In variant embodiments, the method here described may include that said verifying operation includes comparing the version of the one ore components being downloaded to the version of corresponding components already stored in the memory of the card in a version table also residing in the memory, in particular in the primary boot loader.

In variant embodiments, the method here described may include that said one or more components include one or more among Kernel, Java Card, SMS protocol, Authentication, USIM, Global Platform components.

The method here described includes that when a profile switch is performed includes performing a dynamic linking operation on the components stored in the memory after the step of verifying if there is stored in the card an operating system component associated to a same version of the component being downloaded.

In variant embodiments, the method here described may include
storing in the card each of the one or more component.

In variant embodiments, the method here described may include that it is stored in the card an operating system component associated to a same version of the component being downloaded, and
a downloading server retrieves the corresponding information, in particular from a version table and performs said verifying at the server.

The present disclosure provides also solutions regarding a system for managing the storage of an operating system in an integrated circuit cards, in particular a eUICC card, comprising a integrated circuit card configured to operate in a mobile device and a remote server configured to exchange data with the device and the card configured to implement the method of any of the previous embodiments.

The present disclosure provides also solutions regarding a integrated circuit card, in particular a UICC or eUICC card, configured to operate in the previous system.

The present disclosure provides also solutions regarding a computer-program product that can be loaded into the memory of at least one processor and comprises portions of software code for implementing the method of any of the previous embodiments.

Embodiments of the present disclosure will now be described with reference to the annexed drawings, which are provided purely by way of non-limiting example and in which:.

In the following description, numerous specific details are given to provide a thorough understanding of embodiments. The embodiments can be practiced without one or several specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the embodiments.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment.

Figures parts, elements or components which have already been described with reference to <FIG> are denoted by the same references previously used in such Figures; the description of such previously described elements will not be repeated in the following in order not to overburden the present detailed description.

The solution here described substantially is based on the observation that even if the MNOs require different operating systems, the differences are represented by a customization of same operating system. Thus, considering two operating system by two different MNOs, they are very similar, e.g. <NUM>% of memory contain images with the same binary information, while only the remaining <NUM>% is different.

In particular, considering the operating system as comprising a plural of components, only a few components among such components are subjected to the customization, while the other components remain the same.

Therefore in brief, the method here described for managing the storage of an operating system in an integrated circuit card, in particular managing multiple operating system in an integrated circuit card, using a primary boot loader, provides
subdividing each operating system in a plurality of operating system components, such as Kernel, Java Card, SMS protocol, Authentication, USIM, Global Platform, such as, by way of non limiting example, the component of the JCOP (Java Card OpenPlatform). Then each operating system component is associated to a descriptor indicating a version of the operating system sub-module. These operations are performed at the operating system developer, or possibly at the operating system provider, i.e. remotely with respect to the card, and in any case prior downloading the operating system in the memory of such card.

When a given operating system is downloaded in the card, the card is configured through its processing unit to store in a table available at the card memory table the version of each component of the given operating system.

When it is necessary to download a further operating system to the card, the version of the components of the further operating system is compared to the version of the components of the given operating system.

If the version is the same, the component of the given operating system and further operating system are considered as binary equal and the download of the corresponding component is discarded. If the version is different the component of the further operating system is stored in the memory of the card. When the card, after downloading, performs the profile switch including changing the operating system, the further operating system uses the modules with the same version of the first profile previously stored and performs a dynamic linking to execute the newly store modules having a different version.

In <FIG> it is shown a flow diagram representing the method for managing the storage of an operating system in an integrated circuit card here described. With the numerical reference <NUM> is indicated a procedure of downloading of a first operating system OSD1 in the card <NUM>, which includes an operation <NUM> of subdividing the first operating system OSD1 in a plurality of components C1. Such subdivision <NUM> is performed at the MNO server, e.g. a host <NUM>, when the operating system OSD1 is designed. Components C1. Cn, which can include one or more among Kernel, Java Card, SMS protocol, Authentication, USIM, Global Platform, are identified in the operating system OSD1. This is an example list of operating system components, however other components can be identified or other subdivision can be performed, for instance aggregating two of the above components in a single component.

Then, an operation <NUM> of associating each operating system component C1. Cn to a respective descriptor v11. v1n, which indicates the version of the operating system component is performed. Also this operation is performed preferably when designing the first operating system OSD1, writing the version descriptor in a field of the programming script of the component. In general for a i-th operating system OSDi and for a j-th component Cj, the corresponding version descriptor is indicated as vij, where is the index of the different operating system OSDi which can be downloaded in the card <NUM>, while j is the index of the components Cj in which it can subdivided with the operation <NUM>, i.e. j goes from <NUM> to n.

In this way components C1. Cn comprising a respective version descriptor v11. v1n are obtained.

With <NUM> is indicated an operation <NUM> of downloading in the card <NUM> the first operating system OSD1. The first operating system OSD1 is downloaded within an image to be loaded with the primary boot loader <NUM>, residing in the memory <NUM>. When such operation <NUM> is performed, the card <NUM> is configured through its processing unit <NUM> to store in a version table VT the version v11. v1n of the components C1. Cn, as better specified with respect to Table <NUM> below. The version table VT resides in the primary boot loader memory area in the non volatile memory <NUM>,.

Then, an operation <NUM> of storing the components C1. Cn of the first operating system in the dedicated area memory in the non volatile memory <NUM> is performed.

When it is necessary to download a second, further, operating system OSD2, a procedure <NUM> of downloading is performed, which includes applying the operations <NUM> and <NUM> described above, thus obtaining components C1. Cn and corresponding versions v21. Of course the procedure <NUM> can be executed after the operation <NUM> after an undetermined amount of time, that can be of week, months or also year, e.g. only when it is necessary to upload a data image, including profile and operating system, of another MNO.

Then, when an operation <NUM> of downloading the second operating system OSD2 in the card <NUM> is performed, such operation of downloading includes a step <NUM> of comparing the versions v21. V2n of the components C1. Cn being downloaded to the version of corresponding components already stored in the card <NUM>, in this case v11. v1n, which are stored in the version table VT (see Table <NUM> below).

If the step <NUM> indicates that a component being download has a version v2j which is different from the version v1j of the corresponding component already stored, then a step <NUM> and step <NUM> are performed.

The step <NUM> provides writing in the column of the table VT corresponding to system OSD2, which is initialized with versions v21. V2n, which are equal to versions v11. v1n, the number of the new version or instance of the component found having a different version at step <NUM>.

The step <NUM> provides storing the components having a version different from the versions of the components already stored in the card.

If at the step <NUM> is found that the version of the component being downloaded is the same of the corresponding component of the first operating system OSD1 stored in the table VT, the component is discarded, i.e. not stored in the memory <NUM>. All the other components depending on the discarded module are linked with the corresponding version already stored in the memory <NUM> of the card <NUM>.

It is underlined that the downloading procedure, including operations <NUM>, <NUM>, <NUM> does not change the interaction between the card <NUM> and the MNO remote server <NUM>, such downloading procedure being performed at the card. The card may buffer the incoming components of the operating systems, e.g. to perform then the comparison <NUM>, using for instance a portion of the non volatile memory, or in variant embodiments, of the volatile memory, depending for instance on the size of the memory available, or also, alternatively, the components can be discarded on the fly, e.g. without storing.

After the downloading of all the components of the second operating system OSD2, and the storing of the sole having a different versions thus in the memory <NUM> there will be stored all the components of OSD1 and some components (usually one or two) of OSD2. After the procedure <NUM> is waited that a profile switch procedure <NUM> is requested.

As better detailed in the following with reference to <FIG> and <FIG>, a profile switch may take place. If a profile switch is performed it may be for instance necessary to load the second operating system OSD2. In this case, in place of the component Cj or of the components discarded it is used the corresponding component of the first operating system OSD1 which is already stored.

Herebelow in table <NUM> is represented a possible embodiment of the table VT. In the first column, which is also the index column of the table VT, it is contained a field corresponding to the j-th component Cj. In the following columns are inserted the version vij of the components for each i-th operating system OSDi.

In the example shown, after downloading with the procedure <NUM> the first operating system OSD1, when it is downloaded the second operating system OSD2 in the comparison operation it is found at step <NUM> that the Java Card, GlobalPlatform, USIM and ISIM components, supposing that they are evaluated in sequences as C1. C4, have the same version v21. V24, therefore the corresponding modules of the second operating system are discarded, i.e. not stored in the memory <NUM>. The Authentication component, i.e. C5, at step <NUM> is found to have a different version descriptor, v. <NUM> instead of v. <NUM>, therefore the corresponding component C5 is stored for the second operating system in the memory <NUM>.

The procedure <NUM> can be of course replicated when a third image containing a third profile and third operating system OSD3 is downloaded, as shown in Table <NUM>, where it is added a column indicating the same instances of component Cj. As shown, in the example represented in Table <NUM> one can have <NUM>, <NUM> or <NUM> instances of the same OS module. The procedure <NUM> of course can be replicate also to download further operating systems.

When having stored a plurality of operating system, it is possible of course that there are multiple instances of same component, in the example the Authentication component has three different instances, while the ISIM component has two.

When performing a deletion operation it must be preserved all the operating system components that are referenced by at least one MNO profile - deleting e.g. the second profile corresponding to OSD2 would result in removing only one instance, i.e. v. <NUM> of the Authentication component.

In <FIG> it is also indicated a procedure <NUM> which is performed when it is performed a profile switch.

In a step <NUM> is evaluated if a profile switch is requested, i.e. loading for instance the second operating system OSD2 through the primary boot loader <NUM> in place of the first operating system OSD1.

In the affirmative, on the basis of the contents of the table VT for the second operating system OSD2, are loaded in a step <NUM> in the volatile memory the components of the first operating system OSD1 which have the same version descriptor vij. Such components were stored while performing the downloading operation <NUM> of the first operating system OSD1. Also in step <NUM> are loaded the component or components of the second operating system OSD2 stored in step <NUM>, since they have a different version descriptor vij: in the example of Table <NUM> this corresponds to the sole Authentication component, e.g. v25.

Then it is performed a dynamic linking operation <NUM> on the component having component or components of the second operating system OSD2 with a different version descriptor vij. This is performed so that when the second operating system OSD2 is executed, when an executable is executed at run time, a dynamic linking is performed, in general by copying the content of libraries from persistent storage to the RAM, and filling jump tables and relocating pointer. The dynamic linking by way of example corresponds to loading and linking the libraries, which as it will be shown correspond to the components, needed by the executable.

In particular to support the dynamic linking operation <NUM> the subdividing step <NUM> performing a sub step of isolation of the components C1. C2 which in its turn includes defining each of the components C1. Cn as a library. In particular, in a manner per se know, each component Cj as a library includes an interface with the methods exposed, e.g. a list declaring of the functions of the component/library to the other components/library. Also this can correspond to the header. h in C language. Libraries depend on the other for dependency.

Then, to support the dynamic linking operation <NUM> it is also provided that in the memory <NUM> of the card <NUM> is stored a further table which for each component Cj stores:.

Such further table containing for each component of each operating system OSDi the import descriptor IC and the export descriptor EC can be stored in the memory <NUM>, preferably in the area of the PBL.

To this regard in <FIG> is schematically represented an API of the Java Card, component C1 of given operating system e.g. OSD1, which during execution has to linked to the component C4, using a function F, in the example getstate().

In <FIG> are shown two instances of the component GlobalPlatform, a first instances C4(v14) and a second C4(v24). It is underlined that this example is different from the one shown in Table <NUM> since the instance of version v14 is version <NUM>. <NUM> and the instance of version v24 is version <NUM>. <NUM> to have two instances for this component.

The second instance C4(v24) is associated to an export descriptor EC stored in the further table described above in the memory <NUM> indicating which API is exported, in this case the function getstate() and which is the version of the component, in this case v24.

The Java Card component C1 is associated in such further table to an import descriptor IC indicating which component is imported and which version and which APIs are invoked.

In the example is indicated a first component which is imported with the version, USIM v <NUM>, and the API invoked, [APIs: getBuffer], and a second component which is imported with the version, which is the shown instance of Globalplatform, C4(v24), e.g. GlobalPlatform v1. <NUM>, and the API invoked [APIs: getState].

Thus when the Java Card API invokes getState of GlobalPlatform is redirected to the component instance of Globalplatform, C4(v24), through a proxy PX associated to the component Globalplatform, C4(v24). The proxy PX is a method, in particular a struct, which is used in C language to call the function F. The Java Card API calls the method, calls the function F and the proxy performs an indirection.

During the execution, any functional invocation is performed via an indirection method. The indirection method depends on the program language.

In smart cards typically "C" language is used, where the indirection includes invoking the method through a struct.

During the dynamic linking, the usage of the import and export descriptors is used to put, in the import component of a first component, in the example C1, the link to the export component of a second component, in the example C4.

In the card systems where the operating system is downloaded over the air, such as in the OFL (Open Firmware Loader) systems, the card performs an authentication of the image containing the operating system which is downloaded, by verifying a cryptographic signature represented by a public key.

According to a further aspect of the solution here described, not only the operating system, but each operating system component C1. Cn of the operating system is cryptographically signed with an asymmetrical cryptography using a public key identifying the operating system issuer or provider.

Thus, in general the method for managing the storage of an operating system in an integrated circuit cards using a primary boot loader to load a selected operating system, includes.

In the negative, if the version is different, it is provide storing <NUM> the component in the card,
or else discarding the component from the download operation if the version is found to be the same.

As mentioned, the other components depending on the discarded module are linked with the corresponding version already stored in the memory <NUM> of the card <NUM>, while a component stored after the verification is dynamically linked to the other components when the profile switch is enacted).

It is underlined that in variant embodiments the one or more components being downloaded can be a single component. This can happen for maintenance reason, i.e. it is necessary to download a component to substitute a malfunctioning or corrupted component. In that case the substitute component can be associated to a different version descriptor.

Of course, a maintenance operation can be performed downloading an entire new operating system with the sole substitute component associated to a different version descriptor. All the component with the same descriptor, as described above, will be simply discarded from the downloading operation.

For the download, the mechanism assumes that there is no change in downloading protocol over the UICC. The solution described optimizes usage of the memory of the card.

In variant embodiments it is possible however to optimize also the downloading protocol.

In such embodiment the MNO server, for instance coinciding with the host <NUM> hosting a Personal Creator, retrieves the list of components on the UICC card <NUM>. This can be done accessing the version table VT.

Then the server downloads only the components that need to be downloaded, i.e. are not present on the UICC.

Thus the method in this embodiment provides that there is stored in the card <NUM> an operating system component associated to a same version of the component being downloaded, the downloading server retrieves the corresponding information, in particular from the version table VT, and performs said verifying at the server. The verifying including performing operations corresponding to step <NUM>, which are performed at server instead of being performed at the card, also discarding the component from download takes place at the server. while the storing <NUM> is performed by the server at the remotely connected card.

The described solution thus has several advantages with respect to the prior art solutions.

The method here described allows to manage multiple operating system, or also substitute single components of the operating system in cards using a primary boot loader to load the data image of the MNOs including the operating system.

The method here described allows to manage multiple operating systems with a significantly lower chip memory usage with respect to the know solutions.

The method here described can also reduce the amount of data transmitted from the remote server, to store an operating system.

Claim 1:
A method for managing the storage of an operating system in an integrated circuit card including using a primary boot loader to load a selected operating system, comprising the operations of:
subdividing an operating system in a plurality of operating system components,
associating one or more of said components in said plurality of operating system components to a descriptor indicating a version of the operating system component,
then downloading a data image comprising a given mobile network operator profile, that a user equipment can utilize to register and interact with a mobile network operator, and said one or more operating system components to a non-volatile memory of the integrated circuit card in which at least a previous profile and other operating system components are stored,
said downloading operation including verifying if there is stored in said non-volatile memory of the card an operating system component among said other operating system components associated to a same version of the component being downloaded,
storing the component in the card if the version is different,
after said verifying,
discarding the component from the download operation if the version is the same,
when after downloading, a profile switch between the previous profile and said given profile is performed using as operating system said other operating system components associated to the same version and performing a dynamic linking to execute the components stored having a different version.