DE102010054783B4 - Method for storing a file in a portable storage device - Google Patents

Abstract

Method for storing a file (10) in a portable data carrier (1), the file (10) having a file descriptor (11) and a file content (12), comprising the method steps:- receiving (17) a file content (12) of the file (10) in the data carrier (1) during operation of the data carrier (1); and- checking (18) an attribute (13) of the file (10) whose file content (12) was received by the data carrier (1); characterized in that the file content (12) is stored in a volatile memory area (3) of the data carrier (1) for use during this operation of the data carrier (1) if the file (10) has a specific attribute (13);- wherein the file (10) is an elementary file of a file system (8) of a SIM card and the specific attribute (13) is the "High Update Activity" attribute;- wherein the data carrier (1) is a subscriber identification module for a mobile radio network (6), the structure and operation of which is defined in the specification ETSI 3GPP TS 11.11/51.011 or the ETSI 3GPP TS 31.102.

Description

The invention relates to a method for storing a file in a portable data carrier, a computer product and a portable data carrier.

A portable data carrier is preferably a data carrier with corresponding security functions, such as smart cards, chip cards, tokens, mass storage cards, multimedia cards and/or electronic identity documents, such as an electronic ID card, a passport with machine-readable identification data of a person stored on a chip. For example, a chip card is understood under the term portable data carrier, whereby the area of application of the chip card is very diverse, for example as a credit or debit payment card, health card, access authorization card, company ID, identification card, electronic vehicle registration document or driver's license. In particular, a subscriber identification card, or SIM card for short, for identifying a subscriber in a mobile network is understood under the term portable data carrier.

Alternatively, the data carrier can also be a security element integrated into a mobile device. The security element is designed in particular as a hardware component and arranged as a permanently integrated part in the mobile device, whereby it cannot be removed from the mobile device in this form, for example as an M2M module, co-processor or as a trustworthy processor part, such as a trusted base. Alternatively, the security element can be connected to the mobile device as a removable module with security functionality, for example in the form of a chip card, in particular a Subscriber Identification Module, or SIM card for short, mass storage card, USB token, mass storage card, Secure MicroSD card, as a mobile network token, e.g. a UMTS surf stick. Alternatively, the security element is designed as a software component in the form of a Trusted Platform Module as a trustworthy part of the operating system kernel of the mobile device or as a security software algorithm.

According to the 5th edition of the “Handbook of Chip Cards” by the authors Wolfgang Rankl and Wolfgang Effing, hereinafter referred to as Rankl/Effing, published in 2008 by Carl Hanser Verlag, page 502 ff in point 13.7 “File Management”, the file system of a data storage device includes directory files such as the Master File, MF for short, or Dedicated Files (DF) and individual files, referred to as Elementary Files, EF for short.

According to Rankl/Effing, the file system is stored in a rewritable, non-volatile memory area, for example the EEPROM or FLASH memory of the portable data storage device, so that the file system is available even after the data storage device has been deactivated. The management and organization of the files in the file system is handled by the operating system of the data storage device.

In an object-oriented file system structure, the files have a file descriptor, also known as the file header, which contains all information about the file itself. The files also have the file content, also known as the file body, which contains the file's payload data. The file descriptor in turn contains the file's attribute, which identifies special properties of the file. The file descriptor can have a fixed or variable length.

Parts of the file system of today's portable data storage devices can be updated subsequently, i.e. after the data storage device has been issued to a user, for maintenance purposes, innovations, extensions and/or error correction. One part of the file system includes, for example, an application with a directory file DF and associated files EF. One part of the file system is, for example, an application for maintaining any functionality. The changes or updates to the file system affect the file contents of a single or multiple files in the file system, or only certain parts of a file's file contents are replaced by current parts of the file contents.

With today's data storage devices, the number of write/read accesses in the non-volatile memory is limited and depends heavily on the technology used to manufacture the non-volatile memory, the manufacturing process itself and the environment in which the semiconductor chip is operated. This number decreases as performance increases and the area of the memory areas in the data storage device decreases. A semiconductor chip manufacturer usually guarantees a minimum number of write cycles. Typically, a manufacturer of EEPROM memory guarantees between 100,000 and 500,000 write cycles, and up to 100,000 write cycles are guaranteed for FLASH memory. If the guaranteed minimum number of write cycles on a sector/block or in the same byte in a memory area is reached, no guarantee is given for the functionality of the chip. In most cases, the The data storage device is no longer functional and must be replaced.

The problem is exacerbated when the data carrier is a permanently integrated component in an end device, for example a machine-to-machine (M2M) module or a trusted processor area. On the one hand, such data carriers are intended to have longer operating times, and on the other hand, the data carrier cannot be easily replaced. In most cases, the entire end device has to be replaced.

To avoid such problems, a "wear leveling" process is used to operate non-volatile memory areas. This process uses an unused or previously little-used sector of the non-volatile memory area to write the updated file content, instead of immediately writing updated data content to a sector after a deletion process. This effectively increases the number of read/write accesses.

Alternatively, data storage device manufacturers often advise that writing to the non-volatile memory can be avoided using software routines, such as program code loops, complex register evaluations, etc., so that the non-volatile memory area needs to be written to less frequently in order to achieve the longest possible lifespan of the data storage device. The disadvantage of this is that a programmer of software for the data storage device has to limit himself in the design of his software code, in particular the performance of the data storage device can be massively weakened by such bypass software routines due to higher computing effort, program runtimes and can be massively weakened.

EN 10 2004 013 132 B4 describes a data storage device that has a data structure in which several files are stored. The file header represents the content of the respective file and context information represents the content of the respective further file, which has a file body that has a factual reference to the content of an open file.

EN 199 60 114 A1 describes a method for storing data in a file of a data storage system which comprises a working memory which is directly associated with a microprocessor and in which data required by the microprocessor when executing data processing programs is stored, as well as a mass storage device which is provided for storing further data, wherein the data is stored in at least two different fragments of the file which are associated with separate areas of the data storage system, and wherein an allocation list is formed in which the allocation of the file fragments to different areas of the data storage system is stored. It is provided that the data is stored at least in part in file fragments of the mass storage device and that the entries in the allocation list are stored in the working memory.

DE 694 27 070 T2 describes a file management system for managing data of a plurality of files divided in a non-volatile memory in a so-called IC card, using an IC chip having a non-volatile memory and a control unit such as a CPU for controlling the non-volatile memory and the like.

DE 697 25 677 T2 describes methods and apparatus for storing geographic information on physical storage media, and in particular methods and apparatus for providing geographic data on a physical storage medium for use in a computer-based navigation system.

Wikipedia, the free encyclopedia. Last edited: 09.07.2010. URL: https://de.wikipedia.org/w/index.php?title=Festplattencache&oldid=76495915 [accessed on 18.07.2023] describes a hard disk cache.

Information technology - AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS). T13/1699-D, revision 6a, American National Standards Institute, Inc. Status: September 6, 2008. Archived from the original (PDF) on August 6, 2020. Retrieved December 14, 2020. URL: https://web.archive.org/web/20200806025823/http://www.t13.org/Docu ments/ UploadedDocuments/docs2008/D1699r6a-ATA8-ACS.pdf [accessed on 18.07.2023] describes an ATA/ATAPI command set (ATA8-ACS).

The invention is therefore based on the object of noticeably increasing the service life of portable data storage devices and, in particular, significantly reducing write access to a non-volatile memory area. The aim is to prevent complex workarounds so that a programmer can use all the possibilities and features of the data storage device. The method should be easy to implement and efficient.

The object of the invention is achieved by the measures described in the independent patent claims. Advantageous Embodiments are described in the respective dependent claims.

The object is achieved in particular by a method for storing a file in a portable data carrier. The file has a file descriptor and a file content. In a first method step, a file content of the file is received during operation of the data carrier. In a second method step, an attribute of the file whose file content was received is checked by the data carrier. The file content is stored in a volatile memory area for use during operation of the data carrier if the file has a specific attribute. The file is an elementary file of a file system of a SIM card and the specific attribute is the "high update activity" attribute, the data carrier being a subscriber identification module for a mobile radio network, the structure and operation of which is defined in the specification ETSI 3GPP TS 11.11/51.011 or the ETSI 3GPP TS 31.102.

Saving in the volatile memory area means in particular that the file contents are not transported to the non-volatile memory area and saved there. Until the end of the session, the file contents are stored exclusively in the volatile memory area. If this file content is necessarily required during the session, it is not loaded from the non-volatile memory as usual, but loaded directly from the volatile memory area, for example the RAM.

The creation of new files is also included in this procedure. For example, if the CREATE FILE command is received on the data carrier and the file has the specific attribute, the file is created exclusively in the volatile memory area and discarded again after the session ends.

An attribute of the file of a portable data storage device is described in particular in Rankl/Effing under point 12.9 "Attributes of files" from page 474. They are used to identify special properties of the file. The attribute is stored in the file descriptor. In an object-oriented structure, this file descriptor has a pointer to the original file content of the file. The file descriptor and the original file content are stored in a non-volatile memory area of the data storage device. A specific attribute in the sense of the application is an attribute that indicates a specific property of the file or the file content. This property of the file indicates to the method according to the invention that the file content can be discarded after the session of the data storage device has ended and is therefore only stored in the volatile memory area of the data storage device.

The term operation of the data carrier is synonymous with the term session of the data carrier. The data carrier has been made operational by means of a terminal device, whereby it is supplied in particular with a power supply and possibly other supplying electrical signals, such as reset, clock, etc. from the terminal device. If the data carrier is operational in a session and receives file contents, these are preferably only available in this session. If the supply signals are deactivated by the data carrier, the operation of the data carrier ends and the session is thus ended.

According to the invention, the file is thus in particular an elementary file of a SIM card file system.

According to the invention, the specific attribute is the "high update activity" attribute. This attribute identifies files that are updated very frequently, whereby the lifespan of the data storage device decreases rapidly when these files are used frequently. Therefore, data storage device manufacturers always warn against this and advise programmers not to use such files at all, although using the data storage device during a session is certainly advantageous. The problem is that these files are always overwritten in the same sector of the non-volatile memory, so that specific memory cells are loaded excessively often, which drastically shortens the operability of the data storage device. The method according to the invention makes it possible to use files with this attribute without disadvantages, since it can be assumed that the update of the files has no relevance after the session has ended and can be discarded.

According to one embodiment and in particular, the file content is an updated file content and the file is already stored with an original file content in a non-volatile storage area of the data carrier. A known update command on data carriers is UPDATE BINARY/RECORD, with which an original file content can be updated on a data carrier.

In the sense of the description, the term updated file content is understood to mean the replacement of an original file content already stored in the non-volatile memory area. Alternatively, the term is also understood to mean that a reloadable file content in addition to already existing file content, which can also be discarded when the data storage device session is terminated. The term updated file content therefore also includes file content that can be reloaded.

In contrast to the prior art, in which every update of file contents is stored as a backup in the non-volatile memory, the method according to the invention first checks an attribute and, depending on the attribute, determines whether storage in the non-volatile memory area is necessary. This saves a lot of time that would be needed to access the non-volatile memory. Since volatile memories, such as RAM cells, can be written to much more frequently, the lifespan of the data carrier is drastically extended.

According to one embodiment and in an advantageous manner, the updated file content is stored exclusively in the volatile storage area of the data carrier, so that the updated file content is discarded without being saved when the data carrier is deactivated. If it is determined from the attribute that an update of the file content is not necessary, the updated file content is not stored in the non-volatile storage area.

The invention makes use of the fact that a large number of updates to file contents do not have to be stored permanently and are only necessary for one session of the data carrier. Therefore, these updates are only stored in the volatile memory area.

According to one embodiment, when the data carrier is restarted, i.e. when a new session begins, the original file content of the file is loaded from the non-volatile memory area of the data carrier.

According to the invention, the data carrier is a subscriber identification module for a mobile network. The structure and operation of such data carriers is described in detail in the specification ETSI 3GPP TS 11.11/51.011 or the ETSI 3GPP TS 31.102. This GSM/USIM specification also defines the files, which in turn are updated if necessary.

According to one embodiment, the name of the file is also checked when checking the attribute. If file contents are updated to remove incorrect file contents or to display information for a user, it is sensible not to discard this update without saving it. A list of the respective file names can be found in the figure description.

In an advantageous embodiment, an update counter is provided in the data carrier, which is incremented when the file content is received if the updated file content is only stored in the volatile memory area of the data carrier. The counter reading of the update counter is stored in the non-volatile memory area so that it is also available after the session has ended. The counter reading is stored, for example, in the file descriptor of the file whose updated file content was received and is queried when the attribute is checked. Alternatively, the version of the file is transmitted with each updated file content so that access to the non-volatile memory area can be completely prevented.

In an advantageous embodiment, the count of the update counter is compared with a preset value. The updated file content is stored in the non-volatile memory area regardless of the attribute of the file if the count exceeds the preset value. The original file content is overwritten by the updated file content. A preset value can be any value. For example, this can advantageously ensure that every xth update can be stored in the non-volatile memory area, so that the other nine updates received in the meantime are discarded.

In an advantageous embodiment, the updated file content is always initially saved in the non-volatile memory area, regardless of the attribute, when the original file content is updated for the first time. Most updates in the field are only relevant the first time, so it makes sense to store this first update of the original file content in the non-volatile memory area. All subsequent updates are discarded, as they are only relevant for the current session.

In one embodiment, the updated file content is received by means of an over-the-air service from a remote mobile radio instance in a mobile radio network or through a communication connection with a terminal in the data carrier. In this application, a mobile radio network is understood to be a technical infrastructure on which the transmission of signals for mobile radio takes place. This essentially includes the mobile switching network in which the transmission and switching of the signals between fixed facilities and platforms of the mobile radio network takes place, as well as the access network (also known as the air interface) in which the transmission of signals between a mobile radio antenna and a mobile device takes place. Examples of this include the "Global System for Mobile Communications", or GSM for short, as a representative of the so-called second generation, or the General Packet Radio Service, or GPRS for short, and the Universal Mobile Telecommunications System, or UMTS for short, as representatives of the so-called third generation of mobile radio networks. In the third generation, the mobile switching network is expanded to include the ability to transmit data in packets, but the radio network itself remains unchanged.

Alternatively, the updated file content is received via a communication connection with a terminal device in the data carrier. This is done either via a contact interface or a contactless interface. The operating system of the data carrier is designed in such a way that the update of the file content is received via the contactless interface of the data carrier, for example in accordance with one of the ISO/IEC 14443, 15693, 18092 or contact-based in accordance with ISO/IEC 7816 or USB standard.

The basic idea of the invention further comprises a computer program product which is loaded directly into the volatile or non-volatile memory of the data carrier and comprises software code sections with which the preceding embodiments of the method according to the invention are carried out when the product runs on the data carrier.

The basic idea of the invention further comprises a portable data carrier with an integrated semiconductor circuit. The circuit comprises a communication interface for receiving an updated file content of a file, a volatile memory area for storing the updated file content and a non-volatile memory area for storing an original file content and a file descriptor of the file. The data carrier further comprises a checking unit which stores an attribute of the file and the updated file content only in the volatile memory area for use during operation of the data carrier if the file has a certain attribute. The integrated semiconductor circuit of the data carrier further comprises an update counter, wherein the update counter is incremented when the updated file content (12a) is received and a comparison unit, wherein the comparison unit compares the count of the update counter with a preset value. The original file content in the non-volatile memory area is overwritten by the updated file content if the comparison of the comparison unit shows that the counter reading is equal to or greater than the preset value.

The invention and further embodiments and advantages of the invention are explained in more detail below with the aid of figures, whereby the figures merely describe embodiments of the invention. Identical components in the figures are provided with the same reference numerals. The figures are not to be regarded as being to scale; individual elements of the figures may be shown exaggeratedly large or exaggeratedly simplified.

• 1 Das Empfangen eines aktualisierten Dateiinhalts über ein Mobilfunknetz gemäß dem Stand der Technik
• 2 Ein Blockschaltbild über Funktionseinheiten eines im tragbaren Datenträger eingebrachten Halbleiterschaltkreis gemäß dem Stand der Technik
• 3 Ein Dateisystem mit Dateien in einer SIM-Karte gemäß dem Stand der Technik
• 4 Eine objektorientierte Struktur einer Datei bestehend aus Dateideskriptor und Dateiinhalt gemäß dem Stand der Technik
• 5 Ein Ablaufdiagramm eines erstes Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zum Speichern einer Datei in einem Datenträger
• 6 Ein alternatives erfindungsgemäßes Ausführungsbeispiel des in 5 gezeigten Ablaufdiagramms
• 7 Ein alternatives erfindungsgemäßes Ausführungsbeispiel des in 5 und 6 gezeigten Ablaufdiagramms

They show:

• 1 Receiving an updated file content via a mobile network according to the state of the art
• 2 A block diagram of functional units of a semiconductor circuit incorporated in the portable data carrier according to the prior art
• 3 A file system with files in a SIM card according to the state of the art
• 4 An object-oriented structure of a file consisting of file descriptor and file content according to the state of the art
• 5 A flow chart of a first embodiment of a method according to the invention for storing a file in a data carrier
• 6 An alternative embodiment of the invention of the 5 shown flow chart
• 7 An alternative embodiment of the invention of the 5 and 6 shown flow chart

1 shows a system consisting of a mobile terminal 5 with an internal terminal circuit 5a. The mobile terminal 5 also contains a portable data carrier 1 in the form of a SIM card. The data carrier 1 could also be designed in one of the ways described above and integrated into the terminal 5. The terminal 5 is in 1 a mobile radio terminal and by means of a mobile radio connection 6 with a remote mobile radio instance 7 in a communication connection. Part of the mobile radio instance 7 is an update server 7a. On the SIM card 1 there is a file system (not shown), whose files 10 have a file content 12 that can be updated via the update server 7a. The file system 8 and the files 10 contained therein are updated in the SIM 1 by an update command 15, initiated by the remote mobile radio instance 7 using OTA. Alternatively, the terminal device 5 required to operate the SIM 1 can carry out the pending update.

The 1 The terminal 5 shown is, for example, a smart phone, a PDA or an alternative mobile terminal 5. It is primarily suitable for a mobile radio connection 6 with a mobile radio instance 7. The terminal 5 receives the updated file content 12a as part of the file system 8 on the SIM 1 via a mobile radio antenna (not shown). This update is transmitted from the terminal 5 to the SIM 1. In the SIM 1, the original file content 12b is replaced by the updated file content 12a in the non-volatile memory area 4b. The update takes place at irregular intervals and for a wide variety of purposes, in particular for remote maintenance, troubleshooting, information communication and the like.

In 2 an example block diagram of a semiconductor circuit 2 incorporated in the data carrier 1 is shown. The semiconductor circuit comprises a central processing unit CPU, at least one I/O interface, via which a contact-based and/or contactless communication connection to the terminal device 5 is enabled. The data carrier 1 is made operational via this I/O interface by transmitting the necessary signals, in particular the power supply, the clock, the reset signal and possibly other data channels. The transmission takes place, for example, via an electrical line or an electromagnetic field.

The semiconductor circuit 2 also has a volatile memory area 3, in particular a random access memory, or RAM for short. This memory is characterized by fast access times compared to other memory technologies and the loss of memory content when the power supply fails. A non-volatile memory area 4 is also provided in the circuit 2. This memory area 4 has a non-volatile memory 4a that can be rewritable once and a non-volatile memory 4b that can be rewritable multiple times. The memory 4a is, for example, a read-only memory that is written to during a production and/or personalization phase with files that are stored in an unchangeable manner in the area 4a. The memory 4b, on the other hand, can be rewritable multiple times. The memory area 4b in today's data storage devices is primarily designed using EEPROM or FLASH technology.

The 2 The data carrier 1 shown now receives the data in 1 mentioned updated file content 12a in the form of APDU and transmits this updated file content 12b to the CPU. The CPU in turn has, to a certain extent, access rights to the volatile memory area 3 and the non-volatile memory areas 4a and 4b. According to the state of the art and the GSM and ETSI specifications mentioned in the introduction, after receiving the updated file content 12a, the updated file content 12a is stored in the non-volatile, rewritable memory area 4b.

In 3 an exemplary file system 8 according to the prior art is shown. The file system has a master file, MF, and two dedicated files DF1, DF2 as directory files 9. Hierarchically subordinate, each DF has two elementary files EF1, EF2 or EF3, EF4, which are referred to below as files 10. In 3 shown in dashed lines, a directory file DF1 can contain another directory file DF3, which in turn contains elementary files EF5, EF6. If updated file contents 12a for the files EF1, EF2 are received as part of an update command 15, the original file contents 12b are replaced by the updated file contents 12a as part of the update 15, so to speak, the file contents 12b are overwritten with the file contents 12a. Since this file content 12 is always in the same sector of the rewritable storage area 4b, this sector may be written to more often than other sectors that are only read, whereby the maximum number of write accesses is reached at some point. These sectors of the storage area 4b therefore reduce the lifespan of the data carrier 1 and in particular lead to it becoming inoperable. This can lead to massive costs, especially in the case of permanently installed data carriers 1 in the terminal device 5, since replacing the data carrier 1 is complex.

In 4 an object-oriented structure of a file 10 is now shown. A file descriptor 11 is shown. The descriptor 11, also referred to as the file header, contains the administratively relevant information of the actual file content 12. The file descriptor 11 has an attribute 13 on one side, which characterizes the properties of the file 10. As attribute 13 there is in particular the WORM attribute, a marking that the corresponding file 10 may only be written once, but may be read multiple times. Another attribute 13 is the EDC attribute, a marking that the file content 12 of this file 10 is particularly sensitive and is equipped with an error detection code, EDC for short, in order to immediately recognize the flipping of individual memory bits in the non-volatile memory. Also as attribute 13 is the atomic Write access is provided, an indication that this file 10 may only be written completely or not at all. Further attributes can be assigned for interface management, the boot process of the data carrier, file encryption and much more.

An attribute 13 that is very important for this application is the attribute for frequent writing, or high update activity. This is an identifier for a file 10 that is updated very frequently and causes a correspondingly high number of write/read accesses to the non-volatile memory area 4b.

The actual file content 12 of the file 10 is in turn contained in the file body. The file descriptor 11 always has a pointer to the address of the memory area 4b in which the file content 12 belonging to the descriptor 11 is stored. When updating the file content 12, the original file content 12b does not have to be completely replaced with the updated file content 12a, but in particular only parts of the file content 12b can be updated. An update command 15 can therefore include an updated file content 12a for only a fraction of an original file content 12b.

For the purposes of the application, the term updated file content is understood to mean, on the one hand, the replacement of an original file content already stored in the non-volatile memory area, but also retrofittable file content is conceivable.

In 5 a program sequence of a method according to the invention is shown. Here, the data carrier 1 is put into operation, which is shown with the start of a session. The term “start-up” refers to the supply of the data carrier 1 with clock, reset, voltage and possibly other signals. During the session, the reception 17 of an updated file content 12a takes place. The reception is in 1 explained in a hint and is not an explicit part of the invention. Once the reception 17 is complete, the check 18 is carried out according to the invention for the attribute 13 of the file 10 that relates to the updated file content 12a. This attribute 13 was either received during the reception 17 or alternatively by reading the file descriptor 11 belonging to the updated file content 12a in the non-volatile memory area 4b. According to the invention, the attribute "High Update Activity" is used as the specific attribute 13.

If the attribute 13 “High Update Activity” is not detected during the check 18, the updated file content 12a is written to the non-volatile memory area 4b. In particular, the associated original file content 12b is overwritten.

If, however, the attribute 13 "High Update Activity" is detected during the check 18, the updated file content is only saved in the volatile memory area 3, in particular the RAM for this session. The file content 12a can be used for this session and is available for all necessary operations in the data carrier 1. The specification ETSI TS 102 241 describes card-internal processes for SIM/USIM cards 1, for example the "FILE UPDATE EVENT" process, which continue to function if the updated file content 12a is only saved in the volatile memory area 3. The updated file content 12a is still completely transparent for applications, such as Java Card Applets, on the data carrier 1 and can continue to be used without problems. This means in particular that an application is still triggered when an updated file content 12a has been received for a file 10 of the application and it is irrelevant whether the updated file content 12a is stored in the volatile memory 3 or in the non-volatile memory 4b.

If the data storage device is deactivated, for example by ending the session, the RAM memory area 3 loses its contents and the updated file content 12a is discarded. When the data storage device is switched on again, the original file content 12b is loaded from the non-volatile memory area 4b if required.

Saving in RAM 3 means that the files are no longer stored in the non-volatile memory area 4b and are stored exclusively in RAM 3 until the end of the session.

According to the specification mentioned, all files 10 should be stored in the non-volatile memory area 4b. By applying the method according to the invention, specially marked files 10 are simply not updated, since these files 10 do not have any counter readings or other continuous file contents 12 that would impair the interaction between the mobile network 6, terminal device 5 and data storage device 1. In the present case, updating of the files is therefore radically dispensed with, since this update is only important for this current session and is otherwise irrelevant. In order not to unnecessarily overload the RAM 3, attributes 13 of files 10 should be selected that are not too large due to the limited size of the RAM 3, in particular have few bytes.

According to 6 is an alternative embodiment to the one in 5 shown process flow diagram. The process sequences differ only in that after checking 18 the specific attribute 13, a further check 20 of the file descriptor 11, in particular the name of the file 10 to be updated, takes place. If this check 20 shows that the update of the file 10 must take place in the non-volatile memory area 4b, regardless of the attribute 13, this update of the file content 12 is written to the non-volatile memory 4b.

If this check 20 shows that the update of the file 10 does not have to take place in the non-volatile memory area 4b, this update of the file content 12 is only stored in the volatile memory 3.

• - EF Loci
• - EF Kc
• - EF KcGPRS
• - EF LociGPRS

The following lists examples of names of EF files 10 that have the attribute 13 “High Update Activity” and can be easily discarded after the session of disk 1 has ended:

• - EF Locations
• - EF Kc
• - EF KcGPRS
• - EF LociGPRS

This list is not exhaustive. As already mentioned, other attributes or other markings can be used to apply the method according to the invention

In 7 is one of the 5 and 6 alternative embodiment is shown. In contrast to the 5 After reception 17, an update counter provided in the data carrier 1 will be incremented 21. The counter reading of this update counter will then be compared 22 with a preset value X. If the counter reading is equal to or greater than the value X, the updated file content 12a will be saved in the non-volatile memory area 4b, regardless of the attribute check 18 or the further check 20.

This design makes it possible to store every x-th update of a file 10.

This update counter can alternatively be incremented if it is determined that the updated file content 12a is only stored in RAM 3.

Alternatively and not shown, an update counter reading is also received at the time when the updated file content 12a is received. The comparison 22 is carried out on the basis of the counter reading provided and a decision is made as to whether the file content is to be stored in the volatile memory area 3 or in the non-volatile memory area 4.

It is also conceivable that the file descriptor 11 has an identification of the file version 16 and the current version is communicated upon receipt 17. Based on the version 16 of the file 10, a decision is made as to whether the file content is stored in the volatile memory area 3 or in the non-volatile memory area 4.

In particular, and not further shown here, the update in the non-volatile memory area 4b takes place in any case when the first update of the file 10 has been received, since these are necessary for the correct operation of the data carrier 1, the terminal 5 and the remote mobile radio instance 7.

In a further embodiment not shown in the figures, the received updated file content 12a is stored in the non-volatile memory area 4b if the file content 12a differs greatly from the original file content 12b. Using the EF Loci as an example, an indicator of this strong difference would be if a different MCC (Mobile Country Code) or a different MNC (Mobile Network Code) is located in the LAI field (Location Area Identity) of the updated EF Loci instead of the original EF Loci.

List of reference symbols

1

Portable data storage device; SIM

2

Integrated circuit

3

Volatile memory area, RAM

4

Non-volatile memory area

4a

Non-volatile write-once memory ROM

4b

Non-volatile rewritable memory, EEPROM, FLASH

5

End device

5a

Internal terminal circuit

6

Mobile connection, OTA

7

Mobile phone instance,

7a

Update server

8

File system

9

Master File (MF), Dedicated File (DF) directory

10

File, Elementary File (EF)

11

File descriptor

12

File content

12a

Updated file content

12b

Original file content

13

Attribute of the file

14

Part of the file content

15

Update command

16

File version

17

Receive an update of an EF

18

Checking the EF attribute

19

Saving the EF depending on the attribute of the EF

20

Saving the EF depending on the EF

21

Incrementing the update counter

22

Comparing the update counter value with the preset value

Claims (11)

Method for storing a file (10) in a portable data carrier (1), the file (10) having a file descriptor (11) and a file content (12), comprising the method steps: - receiving (17) a file content (12) of the file (10) during operation of the data carrier (1) in the data carrier (1); and - checking (18) an attribute (13) of the file (10) whose file content (12) was received by the data carrier (1); characterized in that the file content (12) is stored in a volatile memory area (3) of the data carrier (1) for use during this operation of the data carrier (1) if the file (10) has a specific attribute (13); - wherein the file (10) is an elementary file of a file system (8) of a SIM card and the specific attribute (13) is the "High Update Activity"attribute; - wherein the data carrier (1) is a subscriber identification module for a mobile radio network (6), the structure and operation of which is defined in the specification ETSI 3GPP TS 11.11/51.011 or ETSI 3GPP TS 31.102. Procedure according to Claim 1 , wherein the file content (12) is an updated file content (12a) and the file (10) with an original file content (12b) is stored in a non-volatile memory area (4b) of the data carrier (1). Procedure according to Claim 2 , wherein the updated file content (12a) is stored exclusively in the volatile memory area (3) of the data carrier (1), so that the updated file content (12a) is discarded without being secured when the data carrier (1) is deactivated. Procedure according to Claim 2 or 3 , wherein when the data carrier (1) is put into operation again, the original file content (12b) of the file (10) is loaded from the non-volatile memory area (4b) of the data carrier (1). Method according to one of the preceding claims, wherein when checking (18) the attribute (13) the name of the file (10) is also checked. Method according to one of the preceding claims, wherein an update counter is provided in the data carrier (1), which is incremented (21) upon receipt (17) of the file content (12) if the updated file content (12a) is only stored in the volatile memory area (3) of the data carrier (1). Procedure according to Claim 6 , wherein the count of the update counter is compared with a preset value and wherein the updated file content (12a) is stored in the non-volatile memory area (4b) regardless of the attribute (13) of the file (10) when the count exceeds the preset value, wherein the original file content (12b) is overwritten by the updated file content (12a). Method according to one of the preceding claims, wherein the updated file content (12a) is stored in the non-volatile memory area (4b) independently of the attribute (13) when the original file content (12b) is updated for the first time. Method according to one of the preceding claims, wherein the updated file content (12a) is received by means of an over-the-air service (6) from a remote mobile radio instance (7) or through a communication connection with a terminal (5) in the data carrier (1). Computer program product which is loaded directly into a volatile or non-volatile memory (3, 4b) of a data carrier (1) and comprises software code sections with which the method steps according to one of the preceding methods claims 1 until 9 be executed when the product on the data carrier (1) expires. Portable data carrier (1) comprising an integrated semiconductor circuit (2) with: - a communication interface (I/O) for receiving (17) an updated file content (12a) of a file (10); - a volatile memory area (3) for storing (19) the updated file content (12a); and - a non-volatile memory area (4b) for storing (19) an original file content (12b) and a file descriptor (11) of the file (10); - characterized in that the data carrier further comprises a checking unit which checks an attribute (13) of the file (10) and the updated file content (12a) is only stored in the volatile memory area (3) for use during operation of the data carrier (1) if the file (10) has a certain attribute (13); - wherein the integrated semiconductor circuit (2) of the data carrier (1) further comprises: - an update counter, wherein the update counter is incremented (21) when the updated file content (12a) is received; - a comparison unit, wherein the comparison unit compares the count of the update counter with a preset value; characterized in that the original file content (12b) in the non-volatile memory area (4b) is overwritten by the updated file content (12a) if the comparison of the comparison unit shows that the counter reading is equal to or greater than the preset value.

Images