DESCRIPTION

Field of application The present invention relates to a method and system for controlling loss of reliability of a non-volatile memory (NVM) . More specifically, the invention relates to a method and system of the type cited above, wherein the non-volatile memory is included in a Integrated Circuit Card (ICC). Prior art

As known, Integrated Circuit Cards (ICCs) comprises at least a CPU, a Volatile memory and a non volatile memory (NVM).

The ICCs are used for a wide range of applications involving different devices. For example, when used for telecommunication applications, the ICCs are coupled to a GSM/UMTS handset device including a so called man to machine interface which allows a user to manage the ICC. The ICC may also be used in a so called Machine to Machine (M2M) application, wherein a system device is coupled to the ICCs and no man to machine interfaceis provided. Moreover, ICCs Machine to Machine (M2M) applications generally comply with different hardware and/or software requirements with respect to ICCs incorporated into handset devices, depending on the specific application they serve, for instance:

-an emergency ICC device reporting failures of a lift in a building has a stable voltage supply and the internal ICC is continuously powered on, for example for several years; moreover, the reliability requirement of the ICC should be very high since it is supposed not to be replaced even for several years.

-an ICC device installed inside a car device for phone calls may also be used to generate alerts in case of car stealing or of a car accident; in this case, the ICC is usually not continuously powered on and voltage supply is substantially not stable.

-a gas meter device storing an ICC may be used to send the gas meter measurement on a regular basis or upon a specific event; these information is automatically transmitted via an SMS or a data protocol.

All the applications referred above, i.e. man to machine applications such as a telecommunication application and M2M applications, suffer for the limitations that the loss of reliability of the non volatile memory of the ICC is not controlled at application layer. For clarity, here below are reported some examples of loss of reliability.

Reliability for data retention. The non volatile memory cannot guarantee that memory cells not updated for more than a predetermined time period, for instance for more than ten years, correctly store data. This problem is also known as reliability on data retention of the non volatile memory. For example, in a flash memory, the electric charges of memory cells are associated to respective bits and thus to corresponding data stored in the flash; however, if a cell is not updated for several time, restoring the corresponding electric charge, this last slowly dissipates and data thereto associated are lost. Reliability for limited writing cycles. The non volatile memory reliability also involves other factors, for example a limitation on the number of writing cycles supported by the memory; in fact, after a predetermined number of writing cycles on a same memory cell, it is not guaranteed that further operations on such cell, i.e. reading access or writing access, are executed correctly. Thus, data previously stored may be lost.

Other factors involving reliability of memory are the deterioration of the hardware or connection between ICC and the device thereto coupled, i.e. the handset or the system device.

As cited above, the current methods for controlling loss of reliability are not available or managed from the applications of the ICC. This is due to the fact that only the Operative System has the control on the hardware and thus on the non volatile memory, and the applications are coupled to respective portions of such non volatile memory only through the Operative System. This serves to guarantee portability of applications on different Operative Systems, in compliance with predetermined interfaces between the Core Operating System and the applications, such as Java Card and ETSI TS 102 241.

Thus, at application layer, it is not known a method to detect or interpret the status of the non volatile memory, due to the nature of the above mentioned interface, and thus it is not known how to control the reliability of the non volatile memory. That is to say, ICC OS merely provides application program with interfaces for accessing and updating data in memory, and ICC OS is responsible for managing the physical aspect of memory, for example, memory refreshing, memory page table.

For example, the application has no way to understand if the memory is losing reliability due to the limited data retention or to the limited writing cycles. Thus, how to control, from the application, the reliability of a non volatile memory associated or coupled to the application itself is a relevant technical problem in the field of ICC.

Moreover, the ICC Operative System cannot measure time because the ICC is not always powered on and thus it cannot determine whether a predetermined time period, for example five years, is elapsed to alert the application on a potential problem of data retention. On the other end, measuring the time on the base of a request to the handset device, for example requesting a current date or time with a so called "Provide local information proactive command" as specified in 3GPP TS 31.1 1 1 , is not safe because it depends on the reliability of date or time returned by the handset device. Neither receiving an SMS or data over other bearers on a regular basis, to detect the elapse of time, is secure; in fact, the ICC should rely on an external bearer; moreover, this solution involves undesired costs for transmitting the SMS to the ICC. Thus, it is not known how to manage the loss of reliability due to the data retention at application level and such problem of data retention is not easily detected at Operative System layer, since the Operative System cannot measure the elapsed time. Moreover, applications do not have any means to request specific actions to increase memory reliability, e.g., it doesn't exist any way for an application to request the refreshment of all memory areas to extend data retention in case a data retention problem is identified.

For what concerns deterioration of the hardware or connection between ICC and system device, in traditional machine to man systems, the handset may send through the corresponding machine to man interface a message associated to the reliability of the non volatile memory, allowing the user to substitute the ICC. However, if the ICC is connected to a system device with a M2M interface, no machine to man interface is available to alert a user to substitute the ICC. Thus, the known method cannot react to a loss of reliability of the memory when the ICC is used for a M2M application. In other words, the problem of the prior art lies in that although the NVM in ICC have constraints on a limited number of updates and a limited time for data retention, the application has no way to be aware of the status of NVM because no interfaces are provided by ICC OS.

The technical problem of the present invention is that of providing a method and a system for controlling possible loss of reliability of nonvolatile memories incorporated into an Integrated Circuit Card (ICC), especially due to the limited data retention of such memory, to the limited writing cycles of the memory and to possible deterioration of the hardware or connection with the device coupled to the ICC, and to improve the reliability of the non volatile memory in a plurality of scenarios in which the corresponding ICC is used, including man to machine application and Machine to Machine application, said method and system having such functional and structural features to overcome the drawback of the prior art solutions. Summary of invention

The solution idea at the base of the present invention is to control a loss of reliability of a non-volatile memory (NVM) included in an Integrated Circuit Card (ICC) at the level of the Operative System of the ICC and to implement an event- service communication model between the Operative System and the applications of the ICC which enables the Operative System to alert the applications when a loss of reliability is detected on a portion of the non volatile memory associated to the application and further enabling the application to react to such detected loss of reliability at application layer.

According to such idea of solution, the technical problem is solved by a method for controlling a non-volatile memory (NVM) included in an Integrated Circuit Card (ICC), characterized by: determining whether the NVM is reliable or not at the OS side and generating an event associated with the reliability of the NVM at the OS side to the application, if the NVM is determined to be unreliable. This improves the reliability of the NVM in ICC in the sense that the application can be aware of the status of NVM and it knows the operating environment.

The terms "reliable" in the following description shall be interpreted in the sense that a memory cell may be considered "more reliable" than another memory cell, below indicated as "not reliable" or "unreliable", since the former guarantees a longer and safer storage for the data, for example because it has been less stressed or more recently updated.

According to an aspect of the invention, a detection of the reliability is executed programming a predetermined memory portion of a non volatile memory of an ICC so that its memory reliability is reduced with respect to a reliability of the other memory cells of the non volatile memory and to implement a recovery procedure on the other memory cells when the predetermined memory portion is detected to be unreliable.

Advantageously, the detection of reliability at Operative System layer is not based on a time measure but on a comparison between the predetermined pattern and the data stored in the predetermined portion of memory. In an embodiment of the invention, the detection of reliability may be triggered by an application which may measure time on the base of the device to which it is connected. Accordingly, the schedule of request to the Operative System to check the reliability of the non volatile memory may be associated to an application environment wherein the ICC is used, both in a man to machine application environment or in a Machine to Machine application environment, but the detection of reliability is based on the way in which the predetermined memory portion or cell is programmed with the predetermined pattern, i.e. on the electric features of the programming operation and/ or on the hardware characteristics of the non volatile memory. Thus, the detection of reliability for data retention is implemented integrating the data available at application layer, i.e. the information available to the application and associated to the environment in which the application runs (for example a gas meter application), and data available at Operative System layer, i.e. the data stored in the memory cell associated to the predetermined pattern. According to this embodiment, determining the reliability of the NVM is performed by writing the prescribed pattern in a prescribed location of NVM with a weak update mechanism, retrieving a stored pattern from the prescribed location of the NVM, comparing the prescribed pattern with the stored pattern, and determining that the NVM is unreliable, if the prescribed pattern is different from the stored pattern. If the NVM is determined to be unreliable, the OS of ICC generates an event of warning on data retention and dispatches the event to the application. Then, the application may call service of refreshing the data of NVM provided by the OS. This allows the OS to determine when the NVM must be refreshed in order avoid a losing of stored information. If necessary, the application may call the service provided by the OS to refresh all or part of data store in NVM.

In another embodiment, examining the reliability of the NVM may be performed by detecting a write access for each cell or a set of cells in NVM, updating a counter value of a prescribed location of NVM, the prescribed location of NVM corresponding to the each cell or the set of cells in NVM, comparing the counter value of a prescribed location of NVM with a first predetermined value, and determining that the NVM is unreliable if the counter value of a prescribed location of NVM exceeds the first predetermined value.

If the NVM is determined to be unreliable, OS of ICC generates an event of warning on maximum data update and dispatches the event to the application. Then, the application may call service of extending write cycles number. More particularly, when the service extending write cycles number is called, the OS flags each cell or the set of cells as non- usable and move the data stored therein to different cells of NVM. In this way, the write access to the used up cells can be avoided.

The NVW may be detected to be unreliable because one or more memory cells have been written over the predetermined limit and also because data stored in one or more memory cells have not been updated for a long period. In this case, the OS generates both events, i.e. an event of warning on maximum data update and an event on data retention.

Further advantages and features of the method for controlling reliability of non volatile memory and the ICC according to the present invention will be apparent from the description given here below only for exemplificative purpose and without limiting the scope of protection of the present invention.

Brief description of the drawings Figure 1 schematically represents in a diagram the steps of the method for detecting reliability of non volatile memory, according to the present invention.

Figure 2 schematically represents the method for detecting the reliability of the non volatile memory, according to an embodiment of the present invention detecting the limit of writing cycles.

Figure 3 schematically represents a change of memory status when the service for extending write cycles number is invoked, according to the method of the present invention.

Detailed description With reference to figure 1, it is schematically represented an ICC according to the present invention, including logical components such as one or more application and an operation system (OS), and physical components such as a non volatile memory, for example a FLASH memory. The FLASH memory stores data for a long time even after power is not supplied.

According to the present invention, the ICC Operating System (OS) provides services to applications and applications request the ICC Operating System to take actions on or controlling the hardware, e.g. the non volatile memory through such services. More particularly, the ICC Operating System manages the FLASH memory and communicates to applications when it detects events on such memory. In other words, the ICC OS communicates with applications by a service and event protocol. According to the present invention, the control of a loss of reliability of the non volatile memory is executing integrating the capability of the Operative System to detect events of the hardware, i.e. on the non volatile memory, and the knowledge of the application on the environment in which is runs, thus implementing a reaction at application layer when a loss of reliability is detected at Operative System layer. In this respect, the ICC OS 40 alerts applications 42, 44, 46, 48 when a an event related to the non volatile memory is detected and provide services to the applications 42, 44, 46, 48 to execute recovery actions to extend reliability of memory, for example to react to a data retention or to an elevated number of updates on same cells.

Hereinafter, an embodiment of the method for enhancing data retention and number of updates will be explained in detail.

1. Events regarding the reliability of NVM

According to the present invention, in order to notify the applications that memory is losing reliability, the following events are provided:

Event warning on data retention. This event is generated by the operating system OS when it detects that memory retention is losing reliability. For example, some NOR memories, data is guaranteed to be retained for at least ten years, so a warning on data retention event should be generated after five years from the last update in a less recently written cell.

According to the present invention, a predetermined memory cell of the non volatile memory is updated with predetermined electronic parameters according to which a predetermined reduced data retention is obtained, such predetermined reduced data retention being less than the data retention guaranteed by all the other cells of the non volatile memory.

As an example of predetermined electronic parameters, a predetermined programming voltage for a reduced time may be applied to the predetermined memory cell of memory, resulting in data with a lower data retention. This operation is defined as weak update. According to another embodiment, the predetermined programming parameters provides to write the predetermined memory cell applying a reduced programming voltage to such predetermined cells for a same time period according to which the other memory cells are written. The predetermined electronic parameters include applying a reduced programming voltage for a reduced programming voltage to the predetermined memory cell. Accordingly, the following protocol is defined to generate the event which raises the application reaction:

-a known pattern is written in a specific memory cell with the weak update mechanism;

-the pattern is checked, for example on a predetermined time schedule;

-as soon as the pattern doesn't match the initial value, the warning on data retention event is generated from the ICC Operative System to the application. Figure 2 schematically represents a flash memory on which the weak update mechanism is applied. A portion of flash memory, i.e. some cells on flash memory, is updated with the weak update mechanism. For example, these cells are updated with a value of "A5A5A5A5".

Since data retention of the weak update is shorter than data retention of the other memory cells of the non volatile memory, when the ICC Operating System notifies an event to the application, the application may take a measure on the other cells of non volatile memory before such other memory cells have incurred in data loss.

Event warning on update cycles writing

This event is generated by the operating system when it detects that a memory cell has been written a number of times close to the maximum number of updates.

This event is generated by adding a counter information to each memory cell or to a sets of memory cells (e.g. memory pages) in NVM. When the highest of this counter reaches a specific value, then the event is generated. As an example, if the technology foresees 100,000 read/ write cycles, the event is generated if a counter has reached the value of 50,000 RW cycles.

The event generated to the application can indicate also information about the data that has been written too many times. For example, the information can include an address and the stored value of the address on which the data was overwritten.

Event ICC refused by handset

A possible scenario of the M2M involves the possibility of the M2M ICC to be inserted in devices that are never enhanced by an MMI; e.g. in a gas meter there's no user interface at all as the gas meter could also be screen less.

According to the method of the present invention, to manage this kind of loss of reliability, an event is generated at Operative System layer for the ICC applications, indicating that the former session has not been closed correctly. At a subsequent session, applications registered to this event react to the detect reliability, depending on the applicative environment; for example, in a gas meter application, an SMS to a specific remote server may be sent, in an automotive system could inform a failure collecting system to track the fail, etc. According to the method, a "Network Rejection" event, i.e. an event associated to a rejection of the ICC by the network due to an authentication data failure, as specified by the ETSI TS 102 223 standard, may be managed.

2. Services requested by the application

In order to let the applications reacting to the aforementioned events, the method of the present invention provide a step for calling services provided by the Operative System from the applications, to extend the non volatile memory reliability. According to an aspect of the present invention, the following mechanisms are implemented.

Service for data retention The service is called by an application and the OS executes a procedure to extend data retention, for example it rewrites (or refresh) all the data in the memory cells. Alternatively, the OS rewrites a portion of data in the memory cells required to be refreshed.

This service can be called by the application when an even occurs, for example:

-When an event associated to a warning on data retention is generated by the OS;

-when an event is generated by the application, for example when an SMS is received. Service for extending write cycles number

Once this service is invoked by an application, the OS executes a procedure to avoid updating predetermined memory cells which have been already stressed with a predetermined maximum number of writing cycles. For example, the OS flags the cell as not usable and moves the relevant data to a different memory cell logically replacing the previous cell.

This service is called by the application based on the application logic, including: -Event warning on update cycles writing generated by the OS.

-too much updates performed by the application in a specific memory field, which are counted by the application.

With reference to Figure 3, the NVM 10 includes some memory cells, one of which stores data 12, and the other 13, 14 are unused. The NVM also includes memory space 15 allocated for a counter of write access to the cell 12 of data. The method described above for detecting reliability on the basis of write access is also applicable to count other consuming operations on the memory; for example, a read operation causing a deterioration of cells of a corresponding memory may be monitored to control the reliability of such memory. If the application calls the service for extending write number cycles, the status of NVM 20 is changed, the OS reads the data 12 and move it to new location 13 in memory which is unused. Then, the OS marks the previous cell or sets of cells as unusable. Different memory managements for frequently updates and not frequently updates memories

According to an aspect of the present invention, since the method steps for controlling the loss of reliability of the non volatile memory involve an overhead of computation or memory, the memory is split in at least two different areas during card configuration:

-an area for "High update", for storing the data to be often updated (e.g. location information);

-an area for "Low update", for storing other data (e.g. the operating system) . This distinction is available in the SIM/ICC. In facts, all files specified for the telecom access applications (SIM application, specified in GSM 1 1.11 and USIM application, specified in 3GPP TS 31.102) indicate whereas they are to be considered as high or low frequency updateable. Moreover, to prevent the overheads of the High Update on both areas, the operating system may be designed to detect the event associated to the limitation on the number of writing cycles only over High Update area and to detect the event associated to data retention only over the Low Update area. In fact, the High Update area is updated and refreshed so frequently than a loss of data retention does not occur.

In a preferred embodiment, applications define data to be included in the High Update area and data to be included in Low Update area.

Some advantageously of the present invention are briefly summarized hereafter. The present invention improves the control of loss of reliability of the NVM in ICC because the application can be aware of the status of NVM and it knows the operating environment. Advantageously, the present invention allows the ICC OS to detect that a time in which a memory portion may be considered reliable is elapsed and to determine when the NVM must be refreshed in order to avoid the loose of data. Advantageously, a memory cell or section of cells in NVM where the counter value is stored are not be damaged for excessive writing cycles.

Advantageously, by dividing the area of NVM into High update area and Low update area, the detection of reliability on writing cycles update is applied only to High update area and the detection of reliability for data retention is applied only to Low update area, thus optimizing memory management, i.e. reducing the counters required for counting write access to the memory and refreshing only Low update area when warning for data retention occurs.