FR3091102A1 - METHOD FOR CUSTOMIZING AN ELECTRONIC ENTITY, AND ASSOCIATED ELECTRONIC ENTITY - Google Patents

Abstract

The invention essentially relates to a method for personalizing an electronic entity, implemented by said electronic entity, said method comprising the following steps: - reception (S210) of one or more data and storage (S220) of the data or data in at least one shared file, - determination (S230) of at least one shared file associated with said at least one shared file, - for said at least one file in sharing, determination (S240) of at least one shared data item among the data stored in the associated shared file, then storage (S250) of a sharing link, comprising an identifier corresponding to said at least one shared file, in association with an address corresponding to said at least one shared datum. Figure for the abstract: Fig. 2.

Description

Description

Title of the invention: PERSONALIZATION PROCESS

OF AN ELECTRONIC ENTITY, AND ASSOCIATED ELECTRONIC ENTITY Technical area

The present invention relates to the field of personalization of an electronic entity, such as a smart card, and more particularly relates to a method of personalization of an electronic entity.

Prior art

In known manner, a smart card comprises several life phases. The first phase of the smart card life is a personalization phase, during which the file structure of the card is created in a memory of the smart card, then the personalization data of the card is stored in the files as well. created.

The manufacture of the smart card includes the personalization phase. After manufacture, there comes a phase of using the smart card, then a terminal phase, in which the smart card is no longer usable.

[0004] The creation of the file structure and the storage of personalization data are typically implemented by means of computer commands coded in "Native" computer language.

During the customization phase, these computer commands use, in order to create the files but also in order to define total or partial sharing links between a shared file and a shared file, the identifiers and the sizes of the files.

More specifically, in order to create a sharing link between two files, it is necessary to know the size of the shared file, and it is necessary that this shared file exists.

[0007] In addition, to load a data item into a partially shared file, it is necessary to know the data structure of the shared file.

However, the personalization data being received after the creation of the files, it is not possible to know in advance the size of certain files, called variable size files. Also, when creating the files, it is considered for each file of variable size that the size of the file is equal to a maximum size, equal to the sum of the maximum sizes of the data that the file could include.

The sharing links are thus created according to the maximum sizes, then the data are loaded into the files.

However, setting the size of each variable size file to a maximum size has the disadvantage of unnecessarily allocating memory size.

Indeed, in general, the size of the data loaded into a file during the personalization phase is less than the maximum size that was used for the creation of the file structure.

There is therefore a need for a solution for customizing smart cards without unnecessarily allocating memory size.

Statement of the invention

To this end, the present invention relates to a method of personalizing an electronic entity, implemented by said electronic entity, said method comprising the following steps:

- reception of one or more data and storage of the data in at least one shared file,

- determination of at least one shared file associated with said at least one shared file,

- for said at least one shared file, determination of at least one shared data item among the data or data stored in the associated shared file, then

- storage of a sharing link, comprising an identifier corresponding to said at least one shared file, in association with an address corresponding to said at least one shared datum.

In a particular embodiment, the sharing link is stored in said at least one shared file.

In a particular embodiment, said at least one shared file and / or said at least one shared data item are determined by means of a sharing indicator received by the electronic entity.

In a particular embodiment, the determination of said at least one shared file and / or of said at least one shared datum results from the absence of at least one datum at a given storage location of said at least one file to share.

In a particular embodiment, the method further comprises a step of storing a sharing declaration, comprising the identifier corresponding to said at least one shared file in association with an identifier corresponding to said at least one datum shared, the step of determining said at least one shared file and / or the step of determining said at least one shared datum being implemented by means of the sharing declaration.

In a particular embodiment, said at least one shared data item is determined as a function of the size and / or of the data structure of said at least one shared file and / or of the associated shared file.

In a particular embodiment, the method further comprises storing an indicator prohibiting the sharing of at least one data item among the stored data or data from the shared file, said sharing prohibition indicator being used to prohibit the sharing of at least one data stored in said associated shared file.

In a particular embodiment, said at least one shared file and said at least one associated shared file are files of variable size.

The invention further relates to an electronic entity, capable of implementing a method as described above.

In a particular embodiment, the different steps of the process described above are determined by instructions from computer programs.

Consequently, the invention also relates to a computer program on an information medium (or recording medium), this program being capable of being implemented by an electronic entity or more generally in a computer , this program comprising instructions adapted to the implementation of the steps of a method as defined above.

This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a particularly compiled form, or in n ' any other desirable form.

The invention also relates to an information medium (or recording medium) readable by an electronic entity or more generally by a computer, and comprising instructions of a computer program as mentioned above.

The information medium can be any entity or device capable of storing the program. For example, the support may include a storage means, such as a rewritable non-volatile memory (of the “EEPROM” or “Flash NAND” type for example), or such as a “ROM”, for example a “CD ROM Or a microelectronic circuit "ROM", or else a magnetic recording means, for example a floppy disc or a hard disk.

On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from a network of the Internet type.

Alternatively, the information medium can be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

Brief description of the drawings

Other characteristics and advantages of the present invention will emerge from the description made below, with reference to the accompanying drawings which illustrate an embodiment thereof devoid of any limiting nature. In the figures:

[Fig.l]

Figure 1 shows, schematically, a system comprising an electronic entity according to an exemplary embodiment of the invention;

[Fig.2]

FIG. 2 represents, in the form of a flowchart, the main steps of a personalization process in accordance with an exemplary embodiment of the invention;

[Fig.3]

FIG. 3 represents, in the form of a flowchart, the main steps of a personalization process in accordance with an exemplary embodiment of the invention;

[Fig.4]

FIG. 4 represents, in the form of a flowchart, the main steps of a personalization method in accordance with an exemplary embodiment of the invention;

[Fig.5]

FIG. 5 represents an example of a fully shared file and of an associated shared file, which can be created during the implementation of one of the methods of FIGS. 2 to 4;

[Fig.6]

FIG. 6 represents an example of a partial sharing file and of an associated shared file, which can be created during the implementation of one of the methods of FIGS. 2 to 4;

[Fig.7]

FIG. 7 represents an example of a sharing declaration, which can be stored during the implementation of a storage step of the method of FIG. 3;

[Fig.8]

FIG. 8 represents an example of a centralized table, which can be used during the implementation of the method of FIG. 4;

[Fig.9]

FIG. 9 represents an example of file structure, which can be created during the implementation of the method of FIG. 4.

Description of the embodiments

Figure 1 shows, schematically, an electronic entity 100 according to an exemplary embodiment of the invention, capable of implementing a personalization method according to an exemplary embodiment, for example the method described with reference to FIG. 2, the method described with reference to FIG. 3, or the method described with reference to FIG. 4.

The electronic entity 100 has the conventional architecture of a computer, and may in particular include a processor 102, a read only memory 104 (of the "ROM" type), a rewritable non-volatile memory 106 (of the "EEPROM" type). or "Flash NAND" for example), a volatile rewritable memory 108 (of the "RAM" type), and a communication interface 110.

In this example, the read-only memory 104 constitutes an information (or recording) medium in accordance with a particular embodiment of the invention. In the read-only memory 104 is stored a computer program PI allowing the electronic entity 110 to implement a personalization method in accordance with an exemplary embodiment of the invention. Alternatively, the PI computer program is stored in the rewritable non-volatile memory 106.

The rewritable non-volatile memory 106 may include a centralized table TC, intended to store one or more sharing links (also called pointers), described in detail below.

The electronic entity 100 is typically a secure element, for example intended to be incorporated in a terminal such as a mobile phone.

The secure element 100 can comply with the standard "ISO 7816". This secure element 100 can thus be of the “UICC” type (“Universal Integrated Circuit Card” in English terminology). Alternatively, the secure element can be an embedded subscriber identity module, also called an "embedded Universal Integrated Circuit Card" (eUICC) module.

Alternatively, the electronic entity can be a secure element incorporated in a smart card, for example a bank card (or payment card) of ID-1 format specified in the ISO / IEC 7810 standard, having the dimensions 85.6 millimeters by 53.98 millimeters by 0.76 millimeters.

Alternatively, the electronic entity is incorporated into an identity document, for example an electronic passport.

The electronic entity is able to communicate, via the communication interface 110, with an external personalization device 120, such as a card reader.

Figures 2, 3 and 4 show methods of personalizing an electronic entity such as the electronic entity of Figure 1, in accordance with exemplary embodiments of the invention.

Each of these personalization methods makes it possible to create a structure of computer files in a memory of the electronic entity 100, typically in the rewritable non-volatile memory 106.

The programming language used for the implementation of each of these methods is typically "Native" or "Java". Thus, each of these methods can be implemented by means of computer commands coded in “Native” computer language or in “Java”.

In addition, each of these personalization methods is typically implemented during a personalization phase and / or a phase of use of the electronic entity.

Each computer file of the file structure created by one of the personalization methods of Figures 2 to 4 typically includes a header and content. The file header includes metadata characterizing the file, such as for example an identifier of the file, information relating to the size of the file, an indicator of the type of file, for example relating to the structure of the data contained in the file, conditions of access to the data contained in the file, and / or an address pointing to the beginning of the data contained in the file. The content of the file may include one or more content data.

In addition, the file structure created by one of the personalization methods of Figures 1 to 4 typically includes at least one shared file and at least one shared file. The shared file and the shared file are for example of variable size.

A shared file is a file intended to store in its content (or contain) one or more shared data, that is to say one or more content data that can be used by the shared file and one or more files shared, associated with the shared file. Other terms could be used to name such a file, such as "pointed file", "master file", or "source file".

Each shared file can for example be transparent, linear or even cyclic. A shared file of transparent type contains a single continuous sequence of unitary data, and is for example defined by the ISO 7816 standard. A shared file of linear type is a file which contains groups of data (each group of data being named record) , ordered sequentially without looping, and is for example defined in standard ISO 7816. Each group of data can have an identical or different size from the other groups of data. In addition, a cyclic shared file is a file which contains groups of data (or record), sequentially ordered with looping, all the groups of data being of identical size. This type of file is for example defined in the ISO 7816 standard.

A shared file is a file capable of using one or more shared data, stored in one or more shared files, associated with the shared file. Other terms could be used to name such a file, such as "image file", "mirror file", or even "link file".

A shared file is typically associated with a shared file by means of a sharing declaration described in more detail below, or by inheritance. Next, a shared file can be associated with a shared file by means of a sharing link, which includes an association of an identifier corresponding to the shared file and one or more addresses corresponding to the shared data or data of the shared file.

A shared file can be a total shared file. The total shared file does not contain content data, and is able to use all of the content data of a shared file associated with the shared file. We then say that the file in total sharing points to all of the content data of the associated shared file.

As a variant, the total shared file contains one or more content data but does not use them, and is capable of using all the content data of a shared file associated with the shared file. This ability can for example be based on at least one indicator for total sharing, typically stored in the file for total sharing.

FIG. 5 represents an example of a file with total sharing EF1 under the directory DF3, this file with total sharing EF1 under DF3 being associated with a shared file EF1 under the directory DF1. Each EFl file under DF3 and EFl under DF1 includes an SFI 1 identifier (SFI being the acronym for "Short File Identifier").

The total sharing file EFl under DF3 does not contain content data, while the shared file EFl under DF1 contains three content data Red, Rec2a and Rec3. The file in total sharing EF1 under DF3 being associated with the shared file EF1 under DF1, this file in total sharing EFl under DF3 is able to use the three content data Red, Rec2a and Rec3 of the shared file EFl under DF1.

In addition, a shared file can be a partial shared file. The partially shared file contains at least one piece of content data, and is capable of using at least one piece of content data from a shared file associated with the shared file, this piece of data from the shared file not corresponding to the content data of the shared file.

Typically, a partial sharing file and a shared file associated with the partial sharing file have the same content data structure. Thus, they can include the same number of memory locations, a memory location of the shared file being able to contain the same type of data as the data contained in the corresponding memory location (i.e. at the same place in the file data structure) of the shared file.

A partially shared file is then able to use data from the associated shared file when the memory location of the shared file containing the data corresponds to an empty memory location of the partially shared file.

Alternatively, the partial sharing file contains one or more content data, but does not use at least one of these content data and is able to use at least one content data from a shared file associated with the shared file, each of these shared file content data corresponding to unused content data of the shared file.

This ability can for example be based on at least one indicator, identifying the memory locations for which the shared file must use the corresponding shared data of the associated shared file. According to another example, this ability can be based on the identification of particular content data in the memory locations of the shared file (for example content data all at FF or 00).

FIG. 6 represents an example of a file in partial sharing EF1 under DF2, this file in partial sharing EF1 in the directory DF2 being associated with a shared file EF1 in the directory DF1. The shared file EF1 under DF1 comprises a first memory location EM1 containing a first content data Red, a second memory location EM2 containing a second content data Rec2a and a third memory location EM3 containing a third content data Rec3.

The partial sharing file EFl under DF2 comprises a first memory location EM4, corresponding to the first memory location EM1 of the shared file EFl under DF1 and not containing content data, a second memory location EM5, corresponding to the second memory location EM2 of the shared file EF1 under DF1 and containing a fourth content datum Rec2b, and a third memory location EM6, corresponding to the third memory location EM3 of the shared file EFl under DF1 and not containing any content datum.

The partial sharing file EFl under DF2 being associated with the shared file EF1 under DF1, and the first and third memory locations EM4 and EM6 of the shared file being empty, the partial sharing file EFl under DF2 is able to use the first data item of content Red and the third item of data content Rec3 of the shared file EFl under DF1.

Each computer file of the file structure created by one of the personalization methods of FIGS. 2 to 4 can be of fixed size or of variable size. A file is of fixed size when the size of the content data that this file is intended to store is known before the data is loaded into this file. In addition, a file is of variable size when the size of the content data that this file is intended to store is known only at the end of the loading of the data in this file (because the size of one or more data n is not known before loading and / or the number of data is not known before loading).

The structure of computer files, the computer files of this structure, the data stored in these files, and the sharing links that can be created during the implementation of one of the methods of FIGS. 2 to 4 allow in particular to customize the electronic entity 100.

FIG. 2 represents a method of personalizing an electronic entity such as the electronic entity of FIG. 1, in accordance with an exemplary embodiment of the invention.

This personalization process is implemented by an electronic entity. In the following description of FIG. 2, it is considered that the personalization process is implemented by the electronic entity 100 of FIG. 1.

In a step S210, the electronic entity 100 receives one or more content data, these data being typically sent by the external personalization device 120 and being intended to be stored in one or more shared files of a set of electronic entity 100 shared files.

The electronic entity 100 then stores, in a step S220, the data or the data in the shared file or files.

In a step S230, the electronic entity 100 determines one or more shared files, each shared file being associated with one or more shared files from the set of shared files.

For each shared file, the electronic entity 100 determines one or more shared data among the data or data stored in the associated shared file or files (step S240).

After the implementation of step S240, the electronic entity 100 stores, for each shared file, a sharing link comprising an identifier corresponding to the shared file, in association with one or more addresses corresponding to the or the shared data (step S250).

The steps S210, S230 and S240 can be implemented in any order, before the implementation of the step S250. Step S220 follows step S210, so that it is interposed between step S210 and the following step S230, S240 or S250.

The sharing links being created after the reception of the content data, the size of the files is known when the links are created, which makes it possible to calculate the address of these shared data and not to unnecessarily allocate the memory size.

In addition, the storage of sharing links allows the electronic entity 100 to easily find the shared data, without having to calculate the address of this shared data each time that it is desired to access it.

FIG. 3 represents a method of personalizing an electronic entity such as the electronic entity of FIG. 1, in accordance with an exemplary embodiment of the invention.

This personalization process is implemented by an electronic entity. In the following description of FIG. 3, it is considered that the personalization process is implemented by the electronic entity 100 of FIG. 1.

In addition, in the following description of FIG. 3, it is considered that each shared file is associated with a shared file. However, the method of FIG. 3 is applied when a shared file is associated with several shared files.

The file structure to be created (for example in the rewritable non-volatile memory 106) can be known in advance. This file structure is for example described by a standard, typically by a standard associated with an application used by the electronic entity 100. In the case where the electronic entity is an electronic passport, the file structure is standardized by the Organization of International Civil Aviation (IC AO).

Similarly, the data structure of certain files is known, for example from the issuer of the electronic entity 100, or from the card or electronic document incorporating the electronic entity 100. It can thus be determined that one or more files are of fixed size, for example because this is described by a standard, or by the architecture and / or the design of an application used by the electronic entity 100.

In the case where the file structure comprises one or more shared files of fixed size and one or more shared files of fixed size, the personalization method can comprise a step S302 of creating the file or files of shared size fixed and fixed size shared file (s). Each fixed-size sharing file created in this step S302 can be total sharing or partial sharing.

This creation of files can typically be carried out following the reception of a dedicated command.

In the case where the electronic entity 100 is a secure element of the “UICC” type, files of the “Master File”, “Dedicated File” and / or “Elementary file” type, described by the ISO 7816 standard, can be created in step S302.

Step S302 can then include, for each shared file created, the creation of a share link associating the shared file and the associated shared file.

More specifically, the sharing link is created by storing in association an identifier corresponding to the shared file and one or more addresses corresponding to the shared data or data of the associated shared file.

Indeed, the size of the shared file being known, and therefore the size of the data contained in said shared file being known, it is possible to determine the address of each shared data item of the shared file. The address of a shared datum is typically determined by adding, to the address of the shared file storing the shared datum, the size of the possible datum (s) stored in the memory locations preceding that of said shared datum, in the shared file .

The share link is stored in the shared file, for example in the header of the file or in its content. As a variant, the sharing link is stored in the centralized table TC.

The personalization method can further comprise a storage step S304, in which for at least one file of variable size sharing, typically for each file of variable size sharing, a sharing declaration is stored, this declaration comprising an identifier corresponding to the shared file in association with one or more identifiers corresponding to one or more shared data.

Each identifier corresponding to a shared data item is for example the identifier of the associated shared file storing the shared data item, and / or the identifier of the shared data item. Thus, a sharing declaration typically includes the identifier of the shared file and the identifier of the associated shared file. Alternatively, the sharing declaration may include the identifier of the shared file, the identifier of the associated shared file, and the identifier of the shared data or the identifiers of the shared data.

Each sharing declaration can be stored in the sharing file concerned, for example in the header of the file or in its content. As a variant, the sharing declaration can be stored in a centralized table, for example the centralized table TC, or in the volatile rewritable memory 108.

FIG. 7 represents an example of sharing declarations, in which all the sharing declarations are stored consecutively, typically in a table 700 in the volatile rewritable memory 108.

Each DPl-DPn sharing declaration includes in this example an IFl-IFn identifier of the shared file, an IFPl-IFPn identifier of the associated shared file, and an ITl-ITn identifier of the type of associated shared file.

In addition, the table 700 stores the total length LT of the table 700, for example before the first DPI sharing declaration.

In a step S310, typically implemented after the step S304 of sharing declaration storage, the electronic entity 100 receives one or more content data, these content data being typically sent by the external device 120 of personalization and being typically intended to be stored in one or more shared files of the electronic entity 100, each of these files can be a file of fixed size or variable size.

One or more content data received in step S310 may also be intended to be stored in one or more shared files of the electronic entity 100, of fixed or variable size.

In addition, the electronic entity 100 can receive one or more sharing indicators and / or one or more sharing prohibition indicators, typically sent by the external device 120.

The electronic entity 100 then stores, in a step S320, the content data or data in the shared file or files and possibly the shared file or files.

Step S320 can include a sub-step S322 for creating shared and shared files from the file structure. Typically, the content data to be stored in the same file can be received continuously, the first data comprising an identifier naming the file intended for storing the data, and the last data comprising an indicator indicating the end of the reception of the data of this file. Files in the file structure can then be created as data is received and stored.

The sharing indicator (s) and / or the sharing prohibition indicator (s) possibly received in step S310 can also be stored in the sharing file or, preferably, in the shared file, for example in the header of the file. As a variant, the indicator or indicators of each shared file are stored in a centralized table, for example the centralized table TC.

Next, in a step S330, the electronic entity determines each shared file associated with a shared file. This step S330 of determination is typically implemented by consulting the sharing declaration or declarations stored in step S304, and / or by means of one or more sharing indicators received by the electronic entity.

The sharing indicator can associate a shared file with a shared file, and / or can associate the shared file with one or more shared data of the shared file. The sharing indicators can thus typically be considered as supplements to the sharing declaration or declarations stored in step S304.

The determination of a shared file can also result from the absence of at least one piece of data at a given storage location for this shared file.

For each shared file determined in step S330, the electronic entity 100 determines one or more shared data, among the stored data or data of the associated shared file (step S340).

One or more shared data can be determined using the T sharing indicator (s) and / or the sharing prohibition indicator (s).

Each sharing indicator can indeed indicate what is the shared data of a shared file. In addition, each sharing prohibition flag can prohibit the sharing of one or more data from a shared file.

One or more shared data can be determined according to the size and / or the data structure of the shared file and / or the associated shared file. The shared file associated with the shared file is then typically identified by consulting the sharing declaration or the sharing indicator.

For example, it is first determined whether the shared file is empty, that is to say if the content of the shared file does not contain any data received in step S310 of reception.

If the shared file is empty, the file is fully shared, and all the data stored in the content of the shared file in step S320 is shared data (unless a sharing prohibition indicator indicates the opposite).

If the shared file is not empty, ie if at least one data item received in step S310 of reception is stored in the content of the shared file (and in the absence of a sharing indicator indicating do not use this or these data), the file is partially shared.

Step S340 may include a sub-step (not shown), typically implemented for each partially shared file, in which, for each content item stored in the associated shared file, the electronic entity 100 determines whether content data is stored in the storage location of the shared file corresponding to the storage location of said stored data.

The storage location of the stored data designates here the logical storage location or the physical storage location of the stored data.

In the absence of data in the corresponding storage location of the shared file, the stored data is shared data (unless a sharing prohibition indicator indicates otherwise).

On the contrary, if a data item is stored in the corresponding storage location of the shared file, the stored data item is not a shared item of data (unless a sharing indicator indicates otherwise).

In the example of FIG. 6, the implementation of this substep typically makes it possible to determine that the first data item of content Red and the third item of data item of content Rec3 are shared data, and that the second item of data item of content Rec2a is not shared data.

As a variant, step S340 may include a sub-step in which the electronic entity 100 determines whether there is, in the shared file, a storage location corresponding to the storage location of the stored data.

Alternatively, step S340 may include a sub-step in which the electronic entity 100 compares the size of the content of the shared file with the size of the content of the shared file. In the case where the size of the content of the shared file is different from the size of the content of the shared file, the electronic entity can deduce which data from the shared file is shared (typically because a standard specifies which data should be shared) . In addition, in the case where the size of the content of the shared file is zero, the shared file is fully shared and all the data in the file is shared.

Step S340 can be implemented before or after step S330. Furthermore, step S304 is implemented before steps S330 and S340, and can be implemented before or after step S302, before or after step S310, as well as before or after step S320 .

Once the shared data or data have been determined, a sharing link associating the shared file and the associated shared file is created by the electronic entity 100, in a step S350. The sharing declaration or declarations possibly stored in step S304 can then be deleted.

The sharing link is created by storing in association an identifier corresponding to the shared file and one or more addresses corresponding to the shared data or data of the associated shared file, this association being called sharing link.

In fact, the data having been received and then stored in the shared file and possibly the shared file, the size of the shared file is known, as well as the size of each data item stored in the shared file. It is thus possible to determine each address corresponding to one or more shared data of the shared file.

The identifier corresponding to the shared file is typically the identifier of the shared file, and / or the identifier of a sub-part of the shared file such as data from the shared file, and / or a file type of the shared file.

In the case of total sharing, the address corresponding to the shared data or data can be the address of the shared file.

In addition, each address corresponding to a shared datum can be the address of the shared datum, this address possibly being relative to the address of the shared file in which the shared datum is stored. Thus, in the case of partial sharing and when the shared file includes several shared data, the address corresponding to the shared data can include the address of the shared file and, for each shared data, the relative address of the shared data, it that is to say the address jump allowing to find the address of the shared data from the address of the shared file.

The sharing link is stored in the shared file, for example in the header of the file or in its content. As a variant, the sharing link is stored in the centralized table TC.

Since the sharing links are created after the reception of the content data, the size of the files is known when the links are created, which makes it possible not to allocate memory size unnecessarily.

FIG. 4 represents a method of personalizing an electronic entity such as the electronic entity of FIG. 1, in accordance with an exemplary embodiment of the invention.

This personalization process is implemented by an electronic entity. In the following description of FIG. 4, it is considered that the personalization process is implemented by the electronic entity 100 of FIG. 1.

Furthermore, in the following description of FIG. 4, it is considered that each shared file is associated with a shared file. However, the method of FIG. 4 is applied when a shared file is associated with several shared files.

The method of FIG. 4 can comprise a step S402 of creating at least one shared file and at least one shared file, typically following the reception of an “Install” type command, sent by the external personalization device 120. A file tree structure is thus typically created in step S402.

[0136] For example, a file structure by inheritance is created in this step S402, a child file being created from a parent file.

In a step S410, the electronic entity 100 receives one or more content data, this content data being typically sent by the external personalization device 120 and being typically intended to be stored in one or more shared files of the electronic entity 100.

One or more content data received in step S410 may also be intended to be stored in one or more shared files of the electronic entity 100.

The electronic entity 100 then stores, in a step S420, the content data or data in the shared file or files and possibly the shared file or files.

In a step S430, the electronic entity 100 determines each shared file associated with a shared file.

For each shared file, the electronic entity 100 determines one or more shared data among the stored data or data of the associated shared file (step S440).

Steps S430 and S440 are typically implemented concomitantly, for example during the first use of the shared file. As a variant, step S430 and implemented before or after step S440.

The electronic entity 100 determines a possible absence of data at a given storage location of the shared file. This absence is typically determined using the metadata present in the header of the shared file, or of a directory associated with the shared file. This absence can be deduced from an absence of referencing of the shared file in the directory associated with the shared file, or from the fact that the size of at least one datum of the shared file, indicated in the header of the shared file. , is zero or equal to a specific value.

In the absence of at least one piece of data, the file is a shared file. Otherwise, the file is not a shared file.

For each datum absent from the shared file, a datum corresponding to the absent datum can then be sought, typically by going up in the file structure. Thus, a datum corresponding to the absent datum can be sought in the parent file of the shared file.

If a data item corresponding to the missing data item is found in the parent file of the shared file, the parent file of the shared file is the shared file associated with the shared file, and the data item corresponding to the missing data item is a data item shared.

In the case where no data corresponding to the absent data is found in the parent file of the shared file, a data corresponding to the absent data is sought in the grandfather file of the shared file, and so on after.

In the case where the shared file is empty, that is to say if the content of the file does not contain any data received in step S410 of reception, the file is a total shared file, and in the case where at least one data item received in step S410 of reception is stored in the content of the file, the file is in partial sharing.

After determining the data or data shared in step S440, a sharing link associating the shared file and the associated shared file is created by the electronic entity 100, in a step S450.

More specifically, the sharing link is created by storing in association an identifier corresponding to the shared file and one or more addresses corresponding to the shared data or data of the associated shared file, this association being called sharing link.

The identifier corresponding to the shared file is typically the identifier of the shared file, and / or the identifier of a sub-part of the shared file such as data from the shared file, or even a type file sharing file.

In the case of total sharing, the address corresponding to the shared data or data can be the address of the shared file.

In addition, each address corresponding to a shared datum can be the address of the shared datum, this address possibly being relative to the address of the shared file in which the shared datum is stored. Thus, in the case of partial sharing and when the shared file includes several shared data, the address corresponding to the shared data can include the address of the shared file and, for each shared data, the relative address of the shared data, it that is to say the address jump allowing to find the address of the shared data from the address of the shared file.

The share link is stored in the shared file, for example in the header of the file or in its content. As a variant, the sharing link is stored in the centralized table TC.

The storage of the sharing links allows the electronic entity 100 to easily find the shared data, without having to calculate the address of this shared data each time that one wants to access it.

FIG. 8 schematically represents an example of a centralized table TC storing sharing links, during the implementation of the method of FIG. 4.

Each LPl-LPn sharing link in this example includes an ILl-ILn identifier of the file being shared and an address @ l- @ n corresponding to the shared data or data of the associated shared file. In addition, the centralized table TC stores the total length LT of the table TC, for example before the first sharing link LP1.

FIG. 9 schematically represents an example of file structure created during the implementation of the method of FIG. 4.

In the example of FIG. 9, a first directory ME, a second directory DDE1, a third directory DDE2, a fourth directory ADE1, a fifth directory ADE2, a sixth directory ADE3 and a seventh directory ADE4 are created at l step S402 of file creation, so that the second directory DDE1 and the third directory DDE2 inherit from the first directory ME, the fourth directory ADE1 and the fifth directory ADE2 inherit from the second directory DDE1, and the sixth directory ADE3 and seventh directory ADE4 inherit from the third DDE2 directory. In addition, an ELI file is created in each DDE1, DDE2, ADE1, ADE2, ADE3 and ADE4 directory. As a variant, an ELI file is created only under the second directory DDE1, sixth directory ADE3 and seventh directory ADE4.

The second DDE1 directory and third DDE2 directory may correspond to directories which may contain several applications, and are typically directories containing payment applications conforming to the EMV standard (for “Europay Mastercard Visa”).

In addition, the fourth ADE1 directory, fifth ADE2 directory, sixth ADE3 directory and seventh ADE4 directory can be directories associated with an application, typically a payment application conforming to the EMV standard.

Then, in steps S410 and S420, the electronic entity 100 receives and stores in the ELI file in the second directory DDE1 a first datum "Log Entry 1" and a second datum "Log Format 1", receives and stores in the file EF1 under the sixth directory ADF3 a third datum “Log Entry 2” and a fourth datum “Log Format 2” and receives and stores in the file EF1 under the seventh directory ADF4 a fifth datum “Log Entry 3” and a sixth datum "Log Format 3".

Next, in steps S430 and S440, the electronic entity 100 determines that the files EF1 in the fourth and fifth directories ADF1 and ADF2 are files in total sharing and that the file EF1 in the second directory DDF1 is the shared file associated with each of these shared files.

In fact, the electronic entity determines that the files EF1 under the fourth and fifth files ADF1 and ADF2 are empty or do not exist, and, for each of these files, searches for the data corresponding to the missing data by going up in file structure. The file EF1 in the second DDF1 directory storing the data corresponding to the missing data (ie the first data "Log Entry 1" and the second data "Log Format 1"), this file EF1 in the second directory DDF1 is the shared file associated with file EF1 under the fourth shared ADF1 directory and file EF1 under the fifth shared ADF2 directory.

The file EF1 in the sixth ADF3 directory storing the third data "Log Entry 2" and the fourth data "Log Format 2", and the file EF1 in the seventh directory ADF4 storing the fifth data "Log Entry 3" and the sixth data "Log Format 3", these EF1 files are not shared files.

The absence of file EF1 under the fourth and fifth directories ADF1 and ADF2 is for example determined because these files are not referenced in the metadata of ADF1 and ADF2 (or alternatively in the metadata of DDF1 and / or MF).

When EF1 files are created in the fourth and fifth directories ADF1 and ADF2, the absence of content data in these files can be determined because the metadata of the header of these files indicates that the size of the data contained is nothing.

For example, the file EF1 under the fourth directory ADF1 includes an index (for example in the metadata of the header of said file EFl under ADF1) referencing the groups of data which it contains (for example, Groupel- offsetl I group3-offset3 or Groupel-offsetl I group2-FFFF I group3-offset3). It can then be deduced from the absence of a reference at group 2 level in the header of the file EF1, or from the presence of this group but with an offset to a specific value, that this group of data is shared.

Claims (1)

Claims [Claim 1] Method for personalizing an electronic entity (100), implemented by said electronic entity (100), said method comprising the following steps: - reception (S210, S310, S410) of one or more data and storage (S220, S320, S420) of the data or data in at least one shared file, - determination (S230, S330, S430) of at least one shared file associated with said at least one shared file, - for said at least one shared file, determination (S240, S340, S440) of at least one shared item of data or items stored in the associated shared file, then - storage (S250, S350, S450) of a sharing link, comprising an identifier corresponding to said at least one shared file, in association with an address corresponding to said at least one shared datum. [Claim 2] The method of claim 1, wherein the share link is stored in said at least one shared file. [Claim 3] The method of claim 1 or 2, wherein said at least one shared file and / or said at least one shared data are determined by means of a sharing indicator received by the electronic entity. [Claim 4] Method according to any one of Claims 1 to 3, in which the determination of said at least one shared file and / or of said at least one shared data item results from the absence of at least one data item at a given storage location. said at least one shared file. [Claim 5] A method according to any of claims 1 to 4, further comprising a step (S304) of storing a sharing declaration, comprising the identifier corresponding to said at least one file in sharing in association with an identifier corresponding to said at at least one shared datum, the step of determining (S230, S330, S430) of said at least one shared file and / or the determining step (S240, S340, S440) of said at least one shared datum being implemented by means of the declaration of sharing. [Claim 6] A method according to any of claims 1 to 5, wherein [Claim 7] [Claim 8] [Claim 9] [Claim 10] [Claim 11] said at least one shared data item is determined according to the size and / or the data structure of said at least one shared file and / or the associated shared file. The method according to any one of claims 1 to 6, further comprising the storage of an indicator prohibiting the sharing of at least one data item among the stored data or data of the shared file, said sharing prohibition indicator being used to prohibit the sharing of at least one data stored in said associated shared file. The method according to any one of claims 1 to 7, wherein said at least one shared file and said at least one associated shared file are files of variable size. Electronic entity (100) capable of implementing a method according to any one of claims 1 to 8. Computer program (PI) comprising instructions for the execution of the process steps according to any one of Claims 1 to 8 when said program is executed by a computer. Recording medium (104, 106) readable by a computer on which a computer program is recorded comprising instructions for the execution of the steps of the method according to any one of claims 1 to 8.