DE102017010430B4 - Method of conserving flash memory by sequentially occupying one-time code modules - Google Patents

Abstract

A method of preserving a non-volatile memory device via sequential population of single-use code modules therein, the method comprising:a) installing a proprietary boot loader (001) in a portion of the non-volatile memory device; b) executing the proprietary boot loader (001) to thereby step (002) loading a CrDe module (003) and an OS (004) onto the non-volatile memory unit leaving space (005); c) executing the CrDe module (003) to thereby in step (006) load a dedicated file set (007) within the free space (005);d) resetting the card in which the OS (004) is running, thereby in step (008) a master device patch module (010) on the same portion of the non-volatile memory unit , previously occupied by the CrDe module (003), to regenerate and thus preserve that portion of the non-volatile memory device;e) executing the master device gspatch module (010), thereby to read in step (011) contents of the non-volatile memory unit obtained in the previous step d) as an image in manufacturing file format to serve in a master reproduction application of choice.

Description

field of invention

The present invention relates generally to protocols for accessing, addressing, and allocating blocks of non-volatile memory, and more particularly to improvements therein directed to increasing the availability of free space and endurance in the blocks of non-volatile memory.

In particular, the present invention is a method aimed at achieving the above-mentioned aims for flash memory contained in embedded systems, in particular smart cards, by sequentially occupying one-time code modules therein.

Background of the Invention

CN 102 760 075 A discloses a method in a smart card that ensures data is stored securely and reliably.

Non-volatile memory systems, particularly flash memory systems, have gained immense popularity due to their low power consumption, small size, low cost, low heat generation, and high stability. Today, flash memory-based systems are most commonly either in a removable form factor, including memory cards or flash drives, that can be operably incorporated into host system(s) such as personal computers, cameras, etc., or alternatively in an embedded form factor integrated within systems, containing smart cards, SIMs that have their own processing environments but are incorporated as such in larger host systems including ATMs, smartphones, presence terminals, etc.

When data is written to non-volatile storage, the host typically assigns unique logical addresses to sectors, clusters, or other data units within a contiguous virtual address space of the storage system, regardless of the deployment form factor. A controller generally within the storage system translates logical addresses received from the host into physical addresses within the storage array where the data is actually stored and then keeps track of these address translations for later interrogation. Predefined cycle times and unidirectional write history characteristics in flash memory systems are considered limiting for repeated iterations of the write process described above. Therefore, the art needs a way that is simple and inexpensive, but helps extend the lifespan of embedded flash memory and therefore the useful life of systems that integrate the flash memory.

The life cycle of systems that integrate this flash memory is defined by the programmed application(s) and their frequency of operation, which is caused by the user responsible for the system. In the immediate scope of the present invention, the life cycle of smart cards is considered to encompass many states, including: a) registration with a smart card management system, b) personalization for issue to a person, c) commissioning for use, d) execution of the on the smart card programmed operation, e) adding subsequent applications to be run on the smart card, f) blocking or deleting the smart card from the management system, and g) restoring it to use, to name a few.

Most transitions between the above-mentioned states in the smart card lifecycle invariably involve one or more write operations to the onboard non-volatile memory, which advances the write count and hence the approach to the lifetime of the memory unit. Storage space limitations and available flash memory density limitations are major obstacles to expanding the capacity of flash memory systems. It would therefore be desirable to minimize the residency of data on flash memory blocks, thereby freeing up a large portion of it to receive more data via subsequent erase/write operations, and consequently the uneven wear of the memory blocks by reducing the dependency on specific memory addresses for to reduce repeated erase-write cycles.

Among the lifecycle states mentioned above, personalization refers to the electronic on-chip loading of application code, user data, and cryptographic keys and is an initial manufacturing process whereby generic off-the-shelf smart cards are converted into customized cards used in one or more programmed applications can become.

Personalization protocols used today require the loading of many functional modules or applets into predetermined areas within the flash memory of common off-the-shelf cards. There are certain Modules that have a single use case and become redundant after the point of personalization of the target card. Loading such data at specific addresses provided for this blocks the flash memory to the same extent and therefore increases the occupancy of the flash memory unit. It would be desirable, therefore, for such data residency to be optimized to allow a large proportion of flash memory areas to remain free, in addition to recovering those that have been used, thereby increasing the availability of onboard flash memory and, in addition, the useful life of systems using such Integrate flash memory to improve.

A few attempts to solve the above considerations are mentioned in the prior art. For example revealed US7272086 (granted to Samsung Electronics Co Ltd) a method of logically rewriting data in a write-once information storage medium incapable of physical rewriting so that data is easily updated and/or read out, and a data recording and/or a playback device therefor. Here, a command to overwrite new data in a first area of the write-once information storage medium in which data has already been recorded is issued. Then the first area is regarded as a defective area and the new data is recorded in a second area. Thereafter, updated error management information including information about the location of the first and second areas is recorded in the write-once information storage medium. However, this method relies on the determination of defective areas and an additional error management system, which thus continues to overwrite these memory areas.

Another example, the US20140229025 (assigned to Rain Bird Corp.) discloses a code replacement for irrigation controls, providing a bootloader that writes the copy of the second set of code received via a removably plugged-in connector over a first set of code, except for the bootloader, which does not will be overwritten. However, this system is not able to meet flash memory management requirements, particularly wear and tear fatigue and file redundancy, beyond the use case outlined in the cited document, which otherwise, according to the proposed solution, has an advantage in achieving upgrades or additional functionalities for an existing set of code that is present in a storage location.

The prior art, to the extent presented above, does not present a single effective solution that addresses all of the aforementioned considerations, thereby preserving an acute need for invention for the present inventors, who, as a result of their focused research, came up with novel solutions to ultimately meet the needs of the art attend. The following disclosures provide a better understanding of the objects, advantages, features, characteristics and relationships of the present invention.

Objects of the present invention

The present invention is identified as addressing at least all of the major deficiencies discussed in the previous section by effectively addressing the issues identified below. In this

It is a primary object to provide a method for optimizing the usability of flash memory, or otherwise avoiding wasting it, in embedded systems, particularly smart cards.

it is a further object, besides the object(s) mentioned above, that the method thus provided specifically addresses the problem of redundant data residing within flash memory in embedded systems.

it is a further object, besides the object(s) mentioned above, that the method thus provided can be implemented without requiring modifications, if any only minimal modifications, to existing embedded systems, in particular smart cards.

it is a further object, besides the above mentioned object(s), that the method thus provided is inexpensive to implement and does not require any special expertise or knowledge on the part of the user who is responsible for the embedded system, in particular for one using the method equipped smart card is responsible.

it is a further object, besides the above mentioned object(s), that the method thus provided can be used to introduce an initialization tool for the effective personalization of embedded systems, in particular smart cards, while optimizing flash memory usage.

These and other objects and their attainment will become apparent to the reader with the following detailed disclosures and appended independent disclosures dependent claims 1 and 11. Other components, features and the way of their implementation are outlined in the dependent claims.

Summary of the present invention

In accordance with the present invention as presently contemplated, there is hereby provided a method for preserving flash memory by sequential allocation by single use code modules. In implementing the method during the smart card manufacturing process, single-use code modules identified as mutually exclusive are loaded sequentially according to the logic for executing them for personalization, thereby wasting flash memory space that would otherwise result from loading each of the single-use code modules into separate areas within the flash memory is avoided. This method introduces a custom bootloader and card personalization tool based on it to effectively personalize smart cards while optimizing flash memory usage.

character list

• 1 ein Blockdiagramm zur schematischen Veranschaulichung der Methodik zum Regenerieren von Flashspeicher, der durch Einmal-Codes belegt ist, im Wesentlichen gemäß der hierin dargelegten Offenbarungen.

The above and other aspects, features, and advantages of several embodiments of the present invention will become more apparent from the detailed description section provided hereinafter, taken in connection with the following drawings. Show in it:

• 1 12 is a block diagram schematically illustrating methodology for regenerating flash memory occupied by one-time codes, substantially in accordance with the disclosures set forth herein.

001

Proprietärer Bootloader

002

Schritt zum Herunterladen des Betriebssystems (OS, engl. Operating System)

003

Modul für die Funktionalität CreDe

004

Betriebssystem

005

Freiraum innerhalb des Flashspeichers der Smartcard

006

Schritt zum Herunterladen üblicher Personalisierungsdateien unter Verwendung von CreDe

007

Dateisystem, das dedizierte Dateien und/oder Elementardateien umfasst

008

Schritt zum Ermöglichen des Herunterladens eines Mastereinrichtungspatch

009

Befehl zum Herunterladen eines Mastereinrichtungspatch

010

Modul für Mastereinrichtungspatchfunktionalität

011

Schritt zur Herstellung von mehreren Karten

Wherever possible, the same numerals have been used throughout the above drawing(s) to designate the same or similar components or indexes, as follows:

001

Proprietary bootloader

002

Operating System (OS) download step

003

Module for functionality CreDe

004

operating system

005

Free space within the flash memory of the smart card

006

Step to download common personalization files using CreDe

007

File system that includes dedicated files and/or elementary files

008

Step to allow download of a master facility patch

009

Command to download a master facility patch

010

Module for master facility patching functionality

011

Step to make multiple cards

Reference to specific examples and implementations is for illustrative purposes only and is not intended to limit the scope of the invention or the claims. Although numbering has been introduced in the detailed description and claims to delineate reference to specific components from such references made in other sections of this specification, not all components are shown or numbered in each drawing to avoid obscuring the proposed invention.

The reader's attention is now drawn to the following detailed description, which describes a preferred embodiment of the present invention and other ways in which the principles of the invention may be practiced, without departing from the spirit of the invention as claimed herein.

Detailed description

In principle, the general purpose of the present invention is to assess inabilities and deficiencies inherent in known systems comprising the prior art and to develop new systems that incorporate all the available advantages of the known art and none of its disadvantages.

Before describing the invention in detail below, it may be beneficial to set forth definitions of certain words or phrases used throughout this specification: The terms "include" and "comprise" and their derivatives mean to include, but are not limited to; the term "or" is inclusive and means and/or; the terms "associated" and "associated with anything," and their derivatives, may include, include within, interconnected, with, include, to be included in, to connect to or to, to couple to, to be able to communicate with, to cooperate with, to interleave, to juxtapose, to be close to, to be attached to or with, to have, to have a property or the like; and the term "OS" refers to operating system or generally to any software program to be downloaded onto the smart card; “ASIC” refers to an application specific circuit; "FPGA" refers to a Field Programmable Gate Array; “CrDe” refers to create and delete functionalities; “MD” refers to a master institution; "CRC" refers to a cyclic redundancy check; "APDU" refers to an application protocol data unit.

Accordingly, an approach to reducing the overall occupancy of memory blocks within the flash memory device to make them free and available for further use during the lifecycle of the smart card in question is proposed, the enabling of which is discussed in terms of certain non-limiting embodiments, some of which are discussed below in terms of certain Examples are explained which generally illustrate the manner in which principles of the present invention can be used.

As mentioned in the previous part of this document, smart card personalization protocols used today require the loading of many functional single-use code modules or applets onto predetermined specific areas within the flash memory of the general off-the-shelf cards. The present inventors see this feature as a addressable niche since these single use code modules are required only once and are redundant after personalization. Therefore, its consumed flash memory represents a regenerable resource and the manner in which it is regenerated for manufacturing process flow forms the essence of the invention claimed herein.

To begin with, the present inventors propose an approach to sequentially overwrite single-use code modules, particularly CrDe and MD functionalities, which are known to be mutually exclusive, according to the logical sequence of their programmed execution during the personalization process. As such, CrDe is used to create and delete the files on the file system and the MD functionality is used to read the flash contents or image of the flash as a manufacturing file format, for example a .mot file. Both CrDe and MD are only required at the time of manufacture and not later during the life of the smart card.

Based on the approach mentioned in the previous paragraph and as in particular in 1 As illustrated, the inventive manufacturing process claimed herein is intended to begin with the selection of a generic off-the-shelf smart card (not shown). The smart card is customized by a proprietary bootloader (001) preinstalled in a portion of its flash memory. The proprietary bootloader (001) is programmed to load the CrDe module (003) and OS (004) onto the flash memory of the smart card via step (002), leaving space (005) empty.

With continuous reference to the accompanying 1 It can be seen that as a result of the execution of CrDe (003) a file system (007) comprising dedicated files and/or elementary files is loaded into the free space via step (006) (005) for personalization of the smart card. Thereafter, in step (008) erase and initialize commands of the OS (004) are executed to allow in step (009) the loading of the MD module (010) to the same memory location as the CrDe module (003), whereby an initial single card, or master card, is formed, thereby regenerating the flash memory originally occupied by CrDe (003).

Furthermore, with ongoing reference to the accompanying 1 to see that the execution of the MD module (010) results in reading the flash contents or the image of the flash as a manufacturing file, which also contains details including address, byte count and the CRC values, using it as a template Multiple cards can be made as needed. It will be understood from the course of these steps that once the download feature is enabled, the master card's functionality of the CrDe module (003) will be disabled.

1. a) Auslöschen einzelner oder mehrerer Sektoren des Flashspeichers auf der Smartcard. Das Befehlsformat dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, aus der der Flash ausgelöscht werden sollte; wohingegen die zwei wertniedrigsten Bytes die Anzahl von Seiten angeben, die ausgelöscht werden muss; die Werte von N und X können je nach Verwendungsfall bestimmt werden.
2. b) Initialisieren/Schreiben spezifischer Inhalte auf den Flashspeicher. Das APDU-Format dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, ab der der Flash beschrieben werden muss, während der Rest der wertniedrigeren Bytes die auf den Flash zu schreibenden eigentlichen Datenbytes darstellen;
3. c) Verifizieren des Inhalts des beschriebenen Flash durch Validieren eines zuvor gelieferten CRC gegenüber eines intern durch die Karte berechneten. Das APDU-Befehlsformat für diesen Befehl weist N zusätzliche Datenbytes auf, unter denen die höchstwertigen X-Bytes der Daten die Adresse angeben, von denen aus die CRC-Berechnung erfolgen sollte. Die nächsten vier hochwertigen Bytes stellen dann die Anzahl von Bytes dar, auf denen die CRC-Berechnung erfolgen sollte. Die restlichen (N-X) Bytes der Daten stellen den erwarteten Wert der CRC dar, der durch das externe Werkzeug berechnet wird. Derselbe Wert wird mit dem berechneten Wert der CRC verglichen. Auf Basis dieses Vergleichs wird die positive oder negative Antwort des Verifikationsbefehls gegeben; und
4. d) Übergabe der Ausführungssteuerung vom Bootloader an das OS. Aufgrund dieses Befehls wird die erste Seite des Flash aktualisiert.

In accordance with a first aspect of the present invention, the proprietary bootloader (001) is a computer-implemented routine programmed to have a set of instructions directed, when executed, to achieve the following functions:

1. a) Erasing one or more sectors of the flash memory on the smart card. The command format of this command has N additional bytes of data, among which most significant X bytes indicate the address from which the flash should be erased; whereas the two least significant bytes indicate the number of pages to be wiped got to; the values of N and X can be determined depending on the use case.
2. b) Initializing/writing specific content to the flash memory. The APDU format of this command has N additional data bytes, among which most significant X bytes indicate the address from which to write to the flash, while the rest of the less significant bytes represent the actual data bytes to be written to the flash;
3. c) verifying the content of the written flash by validating a previously supplied CRC against one calculated internally by the card. The APDU command format for this command has N additional bytes of data, among which the most significant X bytes of data indicate the address from which the CRC calculation should be done. The next four high-order bytes then represent the number of bytes on which the CRC calculation should be done. The remaining (NX) bytes of data represent the expected value of the CRC calculated by the external tool. The same value is compared with the calculated value of the CRC. Based on this comparison, the positive or negative answer of the verification command is given; and
4. d) Transfer of execution control from the bootloader to the OS. Because of this command, the first page of the flash is updated.

1. a) Erstellen von für die Personalisierung der Smartcards notwendigen Dateien;
2. b) Löschung von für die Personalisierung der Smartcards notwendigen Dateien;
3. c) Auslöschen einzelner oder mehrerer Sektoren des Flashspeichers auf der Smartcard. Das APDU-Format dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, aus der der Flash gelöscht werden sollte; wohingegen die wertniedrigsten verbliebenen (N-X)-Bytes die Anzahl von Seiten angeben, die ausgelöscht werden müssen;
4. d) Initialisieren/Schreiben spezifischer Inhalte auf den Flashspeicher. Das APDU-Format dieses Befehls weist N zusätzliche Datenbytes auf, unter denen höchstwertige X-Bytes die Adresse angeben, ab der der Flash beschrieben werden muss, während der Rest der wertniedrigeren Bytes die auf den Flash zu schreibenden eigentlichen Datenbytes darstellen;
5. e) Verifizieren des Inhalts des beschriebenen Flash durch Validieren eines gelieferten CRC gegenüber einem intern durch die Karte berechneten. Das APDU-Befehlsformat für diesen Befehl weist N zusätzliche Datenbytes auf, unter denen die höchstwertigen X-Bytes der Daten die Adresse angeben, von denen aus die CRC-Berechnung erfolgen sollte. Die restlichen Bytes der Daten stellen den erwarteten Wert der CRC dar, der durch das externe Werkzeug berechnet wird. Derselbe Wert wird mit dem berechneten Wert der CRC verglichen. Basierend auf diesem Vergleich wird die positive oder negative Antwort des Verifikationsbefehls gegeben;
6. f) Schutz der Herunterladefunktionalität des OS. Eine erfolgreiche Authentifizierung unter Verwendung dieses Befehls ist auf die Ermöglichung der Befehle bei Punkt c) bis e) in diesem Absatz gerichtet; und
7. g) Auslesen der Flashinhalte von der Karte. Dies ist ein optionaler Befehl, der der MD-Funktionalität als steckbares Modul dient.

According to a second aspect of the present invention, the OS (004) is a computer-implemented routine programmed to include, among other things, a set of manufacturing-specific instructions directed, when executed, to achieve the following, including:

1. a) Creation of files necessary for the personalization of the smart cards;
2. b) Deletion of files necessary for the personalization of the smart cards;
3. c) Erasing one or more sectors of the flash memory on the smart card. The APDU format of this command has N additional bytes of data, among which most significant X bytes indicate the address from which the flash should be erased; whereas the least significant remaining (NX) bytes indicate the number of pages to be erased;
4. d) Initializing/writing specific content to the flash memory. The APDU format of this command has N additional data bytes, among which most significant X bytes indicate the address from which to write to the flash, while the rest of the less significant bytes represent the actual data bytes to be written to the flash;
5. e) verifying the content of the written flash by validating a supplied CRC against one calculated internally by the card. The APDU command format for this command has N additional bytes of data, among which the most significant X bytes of data indicate the address from which the CRC calculation should be done. The remaining bytes of data represent the expected value of the CRC calculated by the external tool. The same value is compared with the calculated value of the CRC. Based on this comparison, the positive or negative answer of the verification command is given;
6. f) Protection of the downloading functionality of the OS. Successful authentication using this command is aimed at enabling the commands at point c) to e) in this paragraph; and
7. g) Reading the flash content from the card. This is an optional command that serves the MD functionality as a pluggable module.

According to another aspect of the present invention, the proprietary bootloader (001) and the CrDe module (003) are grouped under a phone book file (such as an .ADN format) to provide flexibility in file size allocation, protection against accidental deletion of the proprietary bootloader (001) and/or the CrDe module (003) after personalization and also a choice to regenerate the CrDe module (003) space with regard to the phone book file, since the latter's definition was changed at the time of the Manufacturing can be left blank to allow. The phone book file is mandatory updated to complete the smart card personalization process mentioned in the previous paragraph. This also applies to the multiple cards that are prepared using the manufacturing file, as well as the single card used to generate the artwork to be used in the manufacturing of multiple cards.

According to a further aspect of the present invention, step (002) is preceded by a selection of a smart card with a pre-installed proprietary bootloader (001) which consumes very little flash memory on the card. Executing the proprietary bootloader (001) in step (002) results in the loading of the CrDe module (003) and OS (004) to the flash memory of the smart card right after the proprietary bootloader (001). After that, the card is reset, to activate the OS (004).

Step (002) makes the CrDe module (003) available to the OS (004). In this process, the flash area occupied by the CrDe module (003) can be regenerated with respect to the phone book file, thereby providing the alternative embodiments wherein the definition of the flash area to be regenerated is greater than, equal to, or less than the combination of proprietary bootloader (001) and CrDe module (003). Once personalization is done in this way, then the same card can be used as the final manufacturing card, or it can be used to create a template manufacturing file for the manufacture of generate multiple maps as needed. It should be understood that the phone book file can be created at any time during personalization if its file size is less than or equal to the proprietary bootloader (001) plus the CrDe module (003), otherwise the phone book file removal will not be included in the deletion of the CrDe module (003).

According to another aspect of the present invention, the step (008) is performed as an instruction by the OS (004) to download the MD module (010) to the flash memory area separated from the area occupied by the CrDe module (003). has been regenerated, thus allowing the creation of the template making file. This function is protected by requiring a certain number of bytes (say A, 8 bytes in particular) of the authentication value, if this is not the case the proprietary bootloader (001) plus the CrDe module (003) are set up, to be erased from the card, permanently disabling this feature. It should also be noted that step (008) is designed for a single execution and cannot be executed again if the card is reset during step (009), thereby permanently disabling the MD module (010) download.

According to another aspect of the present invention, step (009) is performed by the OS (004) in the form of erase sector and initialize commands to move the MD module (010) to the flash memory area allocated by the CrDe module (003) has been regenerated, making the MD module (010) available as a pluggable part of the OS (004) itself. And once the MD module (010) is downloaded, the personalized card can be used to read the flash contents into a manufacturing file, which in turn is to be used to make multiple cards according to the user's needs.

From the foregoing, it should be understood that there are effectively two flash areas to be regenerated, identified by populations of the CrDe module (003) and the MD module (010). In alternative embodiments, it can be envisaged that the CrDe module (003) and the OS (004) can be configured to occupy either discrete or contiguous locations within the flash memory unit of the smart card.

As can be easily understood, the method proposed herein is made possible by a consortium of tools/computer-implemented routines programmed to perform steps (002), (006), (009) and (011). Conventional downloaders, personalization tools and reading flash tools can be used for the purposes mentioned.

Although 1 illustrates a number of operations in a particular order, operations that are not order dependent can be reordered, and other operations can be combined or taken out. While some rearrangements or other groupings are specifically mentioned, others will be apparent to those skilled in the art and thus do not constitute an exhaustive list of alternatives. In addition, it should be recognized that the phases can be implemented in hardware, firmware, software, or any combination thereof.

1. a) Regenerierung von Flashspeicher, der entweder von CrDe- oder MD-Einmalcode-Modulen oder von beiden oder von keinem davon belegt ist;
2. b) Kontrolle über unbeabsichtigte Löschung des Bootloaders; und
3. c) Darstellung von Protokollen für die Herstellung von einzelnen und mehreren Karten, wodurch eine größere Flexibilität beim Herstellungsverfahrens erlaubt wird.

The present invention has been put into practice in an exemplary configuration using a hardware module and has been identified as having the following advantages over the prior art:

1. a) regeneration of flash memory occupied by either CrDe or MD one-time code modules, or both, or neither;
2. b) control over accidental bootloader deletion; and
3. c) Presentation of protocols for the manufacture of single and multiple cards, allowing greater flexibility in the manufacturing process.

In interpreting this document, to simplify the description, various functions and operations, or executable routines therefor, may be described as being performed or caused by software code. However, those skilled in the art will recognize that such terms mean that functions resulting from the execution of the code/instructions or routines by a pro processor such as a microprocessor. It should be understood that the functions and operations, or executable routines for implementing these embodiments, may be implemented as part of an operating system or a specific application, component, program, object, module, or sequence of instructions.

Furthermore, the embodiments presented herein or further variants thereof can be implemented using hard-wired circuitry such as ASIC or FPGA without software instructions or in combination with software instructions. Thus, the techniques disclosed herein are not limited to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system.

While some embodiments disclosed herein may be implemented in fully functional computers and computer systems, various embodiments may be distributed as a computing product in a variety of forms and may be applied independently of the particular type of machine or the particular computer-readable media used for actual distribution .

Claims (13)

A method of preserving a non-volatile memory device via sequential occupation by single-use code modules therein, the method comprising: a) installing a proprietary boot loader (001) in a portion of the non-volatile memory unit; b) executing the proprietary bootloader (001) to thereby load a CrDe module (003) and an OS (004) onto the non-volatile memory unit in step (002), leaving space (005) therein; c) executing the CrDe module (003) to thereby load a dedicated file set (007) within the free space (005) in step (006); d) resetting the card wherein the OS (004) is running to thereby in step (008) assign a master device patch module (010) on the same portion of the non-volatile memory unit previously occupied by the CrDe module (003). overwrite to regenerate and thus preserve that portion of the non-volatile memory device; e) executing the master device patch module (010) to thereby read in step (011) contents of the non-volatile memory unit obtained in the previous step d) as an image in manufacturing file format to serve in a master replication application of choice. Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 , wherein the non-volatile memory unit is in particular a flash memory on a smart card. Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 and 2 , wherein step (006) results in personalization of the smart card. Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 , where the proprietary bootloader (001) and CrDe module (003) are grouped under one phonebook file, thereby allowing flexibility in file size allocation in addition to protecting against accidental deletion of the proprietary bootloader (001) and CrDe module (003) to allow after personalization in step (006). Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 4 wherein the phone book and manufacturing files are updated in each instance of completing steps (006) and (011), respectively. Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 and 2 , wherein the template replication application is directed to mass production of smart cards at the option of step (011). Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 wherein the non-volatile storage unit is alternatively selected from rewritable read-only memory, magnetic memory, optical disks and their equivalents. Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 , wherein the portion of the non-volatile memory unit that can be preserved is alternatively greater than, equal to, or less than the memory size of the combination of the proprietary bootloader (001) and the CrDe module (003). Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 or 8th wherein the portion of the non-volatile memory unit that can be preserved is alternatively selected from those identified by the occupancy of the CrDe module (003) and the MD module (010). Method for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 1 and 5 wherein the phone book is not updated during the personalization in step (006) if a portion of the non-volatile memory unit to be preserved is identified by occupancy by both the CrDe module (003) and the MD module (010). System for preserving a non-volatile memory unit, which is in particular a flash memory on a smart card, via sequential occupation by single-use code modules therein by the method according to claim 1 is implemented, the system comprising: a) a proprietary bootloader (001), which is a computer-executable routine, the execution of which is programmed within the non-volatile memory device to result in step (002), wherein one or more loading single-use code modules, in particular a CrDe module (003) and OS (004), to predetermined locations within the non-volatile memory unit, wherein space (005) is left; b) a file set (007) that is necessary for the personalization of the smart cards; c) a master device patch module (010) which is a computer executable routine, the execution of which is programmed within the non-volatile memory unit to result in step (011) contents of the non-volatile memory unit being selected in the preceding step d) as a image obtained for use in a master reproduction application of choice; and d) a toolset further comprising conventionally implemented computer-executable routines including downloaders, personalization tools and read flash tools for commissioning and transferring control corresponding to steps (002), (006), (009) and ( 011). System for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 6 wherein the proprietary boot loader (001) includes an instruction set arranged to perform: a) erasing one or more sectors of the non-volatile memory unit; b) writing specific information content to predetermined sections of the non-volatile memory unit; c) verifying the success of the previous step b) by validating a predetermined cyclic redundancy check value against that calculated internally for the non-volatile memory unit; and d) upon successful completion of step c), transfer of control from the proprietary bootloader (001) to the OS (004). System for preserving a non-volatile memory unit via sequential occupation by single-use code modules therein according to claim 6 wherein the OS (004) includes an instruction set arranged to perform: a) creating, in particular the file set (007), and deleting content within the free space (005) necessary for the personalization of the smart card; b) erasing one or more sectors of the non-volatile memory unit; c) writing specific information content to predetermined sections of the non-volatile memory unit; d) verifying the success of the previous step b) by validating a predetermined cyclic redundancy check value against that calculated internally for the non-volatile memory unit; e) protecting the downloading functionality of the OS (004) by authenticating the previous steps b) to d); and f) upon successful completion of step e), transfer of control from the OS (004) to the master device patch module (010).

Images