DE10331799A1 - Program code generating means, especially for use in personalizing a payment chip card, whereby object code is generated using a graphic user interface that permits selection of pre-coded code elements - Google Patents

Abstract

Method for creating a program code for personalizing a data carrier, especially a payment chip card, whereby in a generation step, an object structure of the program code is generated, which contains personalizing data and in a compilation step the object structure is converted to a program code file. The generation of the object code is achieved using a graphical user interface, whereby at least a pre-coded code element is selected. Independent claims are also included for the following : (1) the corresponding software tool for implementing the inventive method; (2) a data carrier with an implemented inventive method; (3) a data carrier with an implemented inventive software tool.

Description

The The invention relates to a method for creating a program code for personalizing a data carrier, in particular a chip card, for the electronic payments.

Under a smart card becomes a microprocessor card in the context of the invention understood with a programmable microprocessor.

typically, Such a microprocessor is programmed in two steps. In a first step is in a first memory area the ROM mask (ROM = Read Only Memory) programmed, which is essentially matches the operating system. In a second step, namely the personalization step, are in a second memory area programmed by the microprocessor personalization data. The ROM mask is for a variety programmed by microprocessors identically, being different for different basic use cases different ROM masks are available. Only in the following Personalization step, the individual microprocessors are individualized, for example a particular publisher or user.

One typical conventional Microprocessor has as the first memory area in which the ROM mask is stored is, the ROM, and as a second storage area in which the personalization data stored EEPROM (EEPROM = Electrically Erasable Programable Read Only Memory). additionally The personalization data can be used for the actual personalization data supplementary Have parts to the operating system (e.g., patches).

One typical alternative microprocessor has in place of the ROM and the EEPROM has a flash memory. The flash memory is organizational divided into a program flash and a data flash. In program flash the ROM mask is stored so that it corresponds functionally to the ROM. In the data flash are at least predominantly Personalization data stored so that the data flash so functional corresponds to the EEPROM.

By the ROM mask is defined in each case the basic profile of the microprocessor. Once the ROM mask is programmed, functionalities of the Microprocessors in detail and more information through the Personalization be set. Which functionalities for the personalization step for programming can stand in the individual case of the previously programmed ROM mask dependent because the basic profile has already been determined in advance by the ROM mask is. In this case, you can or should in the personalization step only with the ROM mask Compatible functionalities in be programmed into the microprocessor.

Examples for functionalities for data carriers for the electronic Payments are those of a credit card, debit card or electronic Wallet. The disk can also have multiple functionalities in a single microprocessor or in several housed in the disk Accommodate microprocessors. Each functionality is in the form of its own Implemented application in the microprocessor (or the microprocessors).

The additionally to the functionalities (Applications) programmed information, for example Information about include the publisher or the owner of the data carrier. editor may for example be a bank or savings bank. In addition, the Information parameters and other information about each functionality Include (application).

In addition to the payment transaction functions, the data carrier can further functionalities (applications) have, e.g. Customer Loyalty Programs. in the In connection with the invention, a data carrier for payment transactions with an additional one or multiple loyalty functionalities or with other additional functionalities always still as a disk for the Payment transactions understood.

The necessary personalization data in order to give the data carrier the desired functionality and possibly to program publisher-specific and other information are in the form of a program code. The program code is provided to a suitable personalization software tool which programs the personalization data into the corresponding memory area, eg EEPROM or data flash, of the microprocessor. The program code used for personalization of the volume is entered into the personalization software tool, and in the appropriate format, is often referred to as a production file for the volume (the smart card). As data format for the production file, the XML format is currently widely used (XML = extended markup language). You can also use another format for the production file.

program code for production files, especially for disk like smart cards, is conventionally created by immediate programming by the source code - in the used programming language - characters for signs is entered and then is compiled. There are programming skills in the used Programming language required.

To the Programming of microprocessors for data carriers such as smart cards are also extensive knowledge of the specifications required for each disk type (card type) are to be kept. For Chip cards for For example, the international payment system is the EMC specification to comply (EMV = Europay, Mastercard, Visa). This is the programming of microprocessors for disk like chip cards with difficulty and error prone.

The for the Production file required format, such as XML or other, must also have an associated Specification suffice, which must therefore be taken into account during programming.

task The invention is a method and a software tool for Carry out to create a process that is easy and intuitive Manner and without extensive programming knowledge and without far-reaching Knowledge of relevant specifications Program code for personalization a volume create, in particular a production file or a program code from which can win a production file.

The Task is solved by a method according to the independent method claim 1, by a software tool according to claim 16 and by a data carrier according to one of the independent ones device claims 17 and 18.

advantageous Embodiments of the invention are specified in the dependent claims.

at the method according to the invention according to the independent claim 1, the creation of the object structure in the build step a) through inputs in a graphical user interface (GUI = graphical user interface), where provided ready-made program code elements selected become. As a result, the program code elements do not need to be used every time to be reprogrammed by hand. The programming by hand must be done only once to the program code elements prefabricate. This prefabrication of the program code elements is not the subject of the invention. The created program code elements be provided so that over the graphical user interface (GUI) can always be accessed. To operate the graphic User interface (GUI) are not far-reaching programming skills and not far-reaching Knowledge of relevant specifications required. Because only inputs placed and prefabricated elements need to be selected is the operation is also simple and intuitive.

Therefore is according to claim 1 created a procedure that focuses on simple and intuitive Manner and without extensive programming knowledge and without far-reaching Knowledge of relevant specifications Program code for personalization a volume can create.

Of the Program code has a data format suitable for a personalization software tool of the disk is readable, or that is convertible into such a data format.

Therefore The invention provides the described simple and intuitive In particular, a production file for personalization of a disk or a program code that makes up such a production file win.

at The compiled program code, i. the file structure, converted into a data format in a subsequent conversion step, that for The software tool for personalizing the data carrier is readable is.

A specific desired functionality the disk, e.g. that it is a credit card, debit card or electronic wallet is preferably generated by the fact that in the GUI as a program code element a corresponding, especially for electronic payment specific application created becomes. The application can over the graphical user interface (GUI) using prefabricated program code blocks Preferably, properties of the application can be created edit by using the graphical user interface (GUI) one or more for the application specific information is entered. These Information can information about include the publisher and / or the owner of the data carrier as well as others Information that is given with reference to the embodiments or which are defined in the corresponding specifications. Before the or the first application is selected is preferably a ROM mask selected.

Further can be in the application or applications preferably (each) Insert one or more TLV objects. The TLV objects become also through inputs in the graphical user interface (GUI) inserted in the creation step a). The TLV objects can as complete prefabricated program code blocks or data elements taken over become. Preferably, however, it is possible to use the graphical user interface (GUI) Edit properties of TLV objects, i. leave the TLV objects to provide information.

For example can in an application a specific cardholder (cardholder) -TLV object added The intended purpose within the application is the owner the application or the data carrier to name by name. In this case it is more preferable in one for that provided field "VALUE" in the GUI as information You can specify who the owner of the data medium is. Further information that can be entered are for example use of the value as a test, fixed or default value, and special compilation rules for the TLV object, and - at one Variant of the invention - too dependencies of the TLV object to other TLV objects In an analogous way in a publisher TLV object information about the publisher and possibly enter further information.

The Compilation is preferably done according to predetermined compilation rules. Preferably, a selection of a ROM mask determines preselected compilation rules compatible with the ROM mask.

About the finished file structure, which if necessary still in one for the personalization software has been converted to a suitable format, optionally additionally checksum calculated.

in the The following is the invention with reference to embodiments and below Reference to the drawing closer explains in the show:

1 the main view of the graphical user interface GUI in the software tool according to an embodiment of the invention;

2 a partial view of the selection list or editor area of the graphical user interface GUI 1 with an open window for ROM mask selection;

3 a partial view of the window for the application and TLV object structure of the graphical user interface GUI 1 with an open window in which the TLV object tree is displayed after ROM mask selection and before selection of a first application;

4 the partial view 3 after a first application, namely application 1 , has been created;

5 the partial view 4 after two TLV objects, namely TLV object 1 and 2 , in the application 1 , have been inserted;

6 the partial view 5 , where the TLV object TLV object 1 is activated for editing information;

7 the TLV object tree with the compiled object structure of a card configuration (program code) for personalization, according to an embodiment of the invention;

8th Excerpt from a file structure tree of a compiled configuration according to an embodiment of the invention.

1 shows the main view of the graphical user interface GUI in the software tool according to an embodiment of the invention. The main view, possibly after an input window, is the first view presented to a user of the software tool. In this main view, the following graphical controls or views are provided:
for the object structure (with applications and TLV objects) ("TLV object tree") and
for the compiled file structure, which is designed here as a file and record structure ("file structure tree"), and
for logging and error output ("log window"),
for the ROM mask selection from the database ("ROM mask selection"),
for the TLV object selection from the database ("TLV object selection"),
for editing the TLV object properties ("TLV Object Editor") and
for editing the file structure properties, in this case the file / recorder properties ("File / Record Editor");
and at the in 1 also shown variant of the invention:
for editing the application properties ("application editor").

at other variants where applications are not editable, becomes the last-mentioned control element for editing the application properties ("Application Editor") not displayed.

The Controls can as a flat Controls or designed in the manner of tabs graphically be. In any case, the controls have the function of "shortcuts" to those specified therein Functions.

In the main view, the GUI has a window for the application and TLV object structure (in 1 left) and a selection list or editor area (in 1 right).

in the Window for the application and TLV object structure can be optionally either the object structure (creation step a)) of a created program code, stored in the so-called TLV object tree, or the compiled file structure (Compilation step b)), stored in the so-called file structure tree, represent. The selection of whether the TLV object tree (object structure) or the file structure tree (file structure) is displayed determined by whether it has already been compiled (file structure tree is displayed) or not yet (TLV object tree is displayed). Optionally, even without a previous compilation of a file structure one from an existing file in the file structure tree getting charged.

In the selection list or editor area can / can be optionally:
select a ROM mask from the database ("ROM mask selection" control),
select one or more TLV objects from the database ("TLV object selection" control),
Edit application properties ("Application Editor" control element), edit TLV object properties ("TLV object editor" control element) and
Edit file structure properties (ie properties of the compiled or file structure loaded from a file), in this case file / recorder properties ("File / Record Editor" control element).

As the appropriate selection or editor window in the selection list or editor area is opened, is described below. It usually can not each selection or editor window at any time during the Open procedure for selection or edition. Rather requires in usually every selection or editing process that has already been done certain other selection or editing operations have been performed are.

In the following, the sequential process of creating a program code, also called card configuration, for personalizing an EMV chip card according to a preferred embodiment of the invention will be described with reference to the figures of the drawing. The creation comprises, in this order, a creation step, a compilation step and, if necessary, a post-processing step. The creation step creates an object structure. This is compiled to a file structure in the compilation step. For the exemplary embodiment described, it is assumed that the structure of the file structure essentially complies with ISO / IEC 7816-4 for the construction of chip card file systems (cf., for example, Rankl, Effing, "Handbuch der Chipkarten", 4th edition, Carl Hanser Verlag Munich Vienna, 2002, chapter 5.6). The creation step may optionally be skipped by loading an object structure from a file. Alternatively, both the build and compile steps may be skipped if a compiled and saved file structure that has already been created in an earlier session is reloaded and, if necessary, edited in a postprocessing step.

First is according to the creation step a) an object structure of the program code (the card configuration) created.

I. Create the object structure (TLV object tree) (creation step a))

The Object structure is in a tree-like structure, the so-called TLV object tree, created.

1. ROM mask choose

The Selection of a ROM mask is basically the first step of a Configuration creation (program code creation). This is the one ROM mask selected, into the microprocessor, into which the configuration is then programmed should be, is already programmed. This will ensure that subsequently only to the ROM mask appropriate program code elements selected can be.

requirements for the Selection of a ROM mask are that of the TLV object tree, in the following the object structure (Creation step a)) is to be created, is empty, and so far neither a ROM mask nor any applications and TLV objects selected were. In a variant of the invention, the TLV object tree also filled be, by selecting a new mask, the previous object structure by replaced the new selection. The available ROM masks are stored in a database. Not all of this is stored Program codes of the ROM masks, but only placeholders for the ROM masks. If necessary are additional in the database Patches to ROM masks stored. For each ROM mask stored in the database, also stored in the database, compilation rules associated with the ROM mask.

By the respective ROM mask can be any operating system, e.g. generates a native operating system or a Java operating system be. Accordingly, according to the method of the invention generated program code a program code in basically any suitable Programming language such as C, C ++, Java etc.

The Database base for the software tool for creating the program code can be any be suitable database.

To select a ROM mask, the user opens in 1 selection list or editor area displayed by clicking on the "ROM mask selection" control element, the ROM mask selection in 2 is shown. In the in 2 The ROM mask selection shown are all ROM mask masks available for selection 1 , Mask 2 , ... mask x, ... mask n listed. In 2 the ROM mask Mask x is activated. Accordingly, in addition to the ROM mask selection (in 2 right next to it) opens a window with an info sheet belonging to the mask x, in which the properties of the mask form ROM are displayed (name, description, comment, ...). To select the desired ROM mask (here Mask x), the user selects them in the list and selects them with the "Select" control.

According to one Variant of the invention with this process in the TLV object tree all with the ROM mask associated, internal TLV objects created, i. all with the ROM mask compatible TLV objects. Which these are are stored in the database in this case.

in the TLV object tree are now all belonging to the selected ROM mask, internal TLV objects for the time being registered, i. entered as selectable below. These objects are initially used with their default values from the database.

at the preferred embodiment However, the invention is still accomplished by pressing the "select" control no such creation of TLV objects made, but also after pressing of the "Select" control still all TLV objects available. This is the flexibility of the procedure larger. at this preferred embodiment be all belonging to the ROM mask or needed or desired TLV objects in addition inserted manually.

If the user selects a ROM mask again despite the ROM mask selection already made, the user will be prompted Query the previously created TLV object tree deleted and created the new selection matching ROM mask with a new otherwise empty TLV object tree.

First if a ROM mask is selected was and their associated TLV objects created in the TLV object tree were created, the selection lists and editor areas are created and processing of applications and TLV objects.

2. Create a new application

After a ROM mask, here mask x, has been selected, the window for application and TLV object structure has the in 3 shown appearance. The corresponding TLV objects belonging to the mask x are created in the TLV object tree. In 3 these are the TLV objects TLV object 1 up to TLV object 4 ,

To the Creating a new (or further) application selects the User the control element "New Application" in the area of the TLV object tree.

Then, in the TLV object tree, under the mask-related TLV objects, a new (or under the last application already created another) application is created. In the 3 displayed GUI is created by creating the application "Application 1 "so changed that they are in 4 receives shown shape. The created application appears in a window below the selected mask, mask x, with the associated preselected TLV objects 1 ,

3. Properties edit the application

By manual insertion all needed TLV objects and specification of the corresponding data will be the properties the associated Application edited. The properties of an application will be described by the data in their TLV objects.

Of the Affected application are finally all necessary information assigned. This information will be provided later when creating the File structure used. Only if at least one ROM mask or an application is created in the object tree (i.e., in the object structure) is, is it possible to open the TLV object selection described below.

Now can In addition, further applications are created or existing ones Applications deleted again become.

Of the User can delete an already created application by: he marks the icon of the relevant application in the TLV object tree and subsequently the operating element "Application delete. "The result is that the application with all possibly already assigned TLV objects from the TLV object tree Will get removed. Was the application to be deleted the only one in the TLV object tree, with the deletion also the window "TLV object selection" by deactivation locked the control.

4. Insert from TLV objects in an application

In order to a TLV object into the TLV object tree, i. into the object structure, added At least one ROM mask or application must already be available be created in the TLV object tree (object structure). An inserted TLV object is inserted in an already created application.

To insert TLV objects, the user in the TLV object tree must press the icon of the application (eg, click) to which the TLV object (s) is to be added, in this case Application 1 , The "New TLV object" control element displays the TLV object selection list with all the TLV objects available to it for the specific ROM mask in the selection list or editor area. 5 shows the in 4 illustrated GUI after application 1 has been selected and after the "New TLV Object" control has been pressed. Im in 5 The right-hand part of the GUI therefore has the TLV object selection open in the selection list or editor area. Therein, several TLV objects are TLV object 3 , TLV object 4 , ... TLV object x, ... TLV object n listed. In the list of TLV objects, the user selects all desired TLV objects with the mouse (multiple selection possible) and adds them with the "Apply" control element to the TLV object tree under the intended application, here application 1 , one. With this transfer, all selected objects are added to the TLV object tree under the application taken. Im in 5 example shown are the two TLV objects TLV object 1 and 2 into the application application 1 been inserted. Therefore, the two TLV objects in the TLV object tree (object structure) are hierarchically subordinate to application 1 displayed. In a variant of the invention, it is possible to select all TLV objects that are necessary for a specific functionality with the aid of "wizards" and then to add them to a specific application. The user specifies which functionality he wants to insert (eg PIN). With this information, all objects belonging to the "PIN" function are automatically selected and inserted. Such wizards, which, as soon as a functionality is called, automatically select the objects required for this functionality and insert them into the TLV object tree, are optionally also provided in further method steps.

Now can Properties of the inserted TLV objects are edited, i. entered and / or changed.

5. Edit the properties of a selected one TLV object

Immediately after inserting the TLV objects, they are provided with TAG and name information in the TLV object tree under the respective application ( 5 ). In 5 and 6 these are the two TLV objects TLV object 1 and 2 that under application 1 stand. The user can edit the properties of the respective TLV object by clicking on the icon of the relevant TLV object with a mouse click; This mouse click opens the TLV object editor in the selection list and editor area, in which the user can edit the object information ( 6 ).

These editable information includes, for example:

in this connection means that TAG is fixed and stored in the database is. Value is empty by default and has to be edited or can be switched off the database become. Length automatically results from Value. For the compilation rules Default default values are created in the database. however can changed the compilation rules become. The possibly changed Compilation rules are not in the database, but together filed with the configuration. In a variant, dependencies can the created TLV object are edited; at first are in this Case no dependencies specified. Is for Information for the one edition possible but not prescribed, no edition made, so be the default values are taken from the database.

All in all are thus for all inserted TLV objects the relevant information either manually by the user entered or the default values taken from the database Service. By clicking on the relevant TLV object, the information becomes each displayed in the TLV object editor.

Of the User can delete a TLV object from the TLV object tree by: he selects the corresponding symbol with the mouse and with the operating element "delete TLV object" the object from the Tree structure removed. The deletion turns the object off removed from the TLV object tree.

In In one variant of the invention, it is possible to use several existing, in earlier Sessions created object (part) structures, the own encapsulated functionalities to create a new forest, edit it if necessary and then compile.

The Object structure is now done and ready, compiled to become.

II. Generate the file structure (File structure tree) (compiling step b))

7 shows the TLV object tree with the compiled object structure of a card configuration (program code) for personalization.

The TLV object tree was created as described above and contains two application applications 1 and application 2 , application 1 contains four TLV objects TLV object 1 , TLV object 2 , TLV object 3 , TLV object 4 , application 2 contains two TLV objects TLV object 1 , TLV object 2 , For each TLV object, tag and name are displayed.

By Generating or equivalently compiling the applications and TLV objects with all their specified properties in one File structure transferred in the file structure tree under the corresponding control element for Ad is coming. To compile, the user must use the "Generate file structure" control element to perform the compilation process start.

The results of the individual compilation steps can be traced in the log window (cf. 1 ).

III. Postprocessing of the compiled file structure (file system) (postprocessing step) (Optional)

in the Normally, the file structure is created by creating a TLV object tree and subsequent compilation. This will include the one contained in the TLV object tree Object structure based on the compilation rules in the corresponding File structure implemented. However, it may or may not be necessary in individual cases be desired edit the file structure created by compilation rework and, in particular, individual elements (files, Records) to edit.

8th shows the file structure tree of a compiled configuration according to an embodiment of the invention. In the file structure tree, a file structure created by compiling an object structure is shown. The object structure was created as described above.

In a variant of the invention, it is possible to create a new forest from several existing file (partial) structures created in previous sessions, which contain their own encapsulated functionalities 8th shown, create and edit if necessary.

The file structure that is in 8th can be seen in the file structure tree (left half of 8th ) has two directory files (Dedicated Files) DF 01 and DF 02. The directory file DF 01 contains two elementary files or equivalent elementary files EF 01 and EF 02. The directory file DF 02 also contains two elementary files EF 01 and EF 02. Element element EF 02 contained in DF 02 again has two records Rec 01 and Rec 02. In the right half of 8th the file / record editor is open. Because in 8th In the file structure tree the elementary file EF 02 of the directory file DF 02 is activated, in the file / record editor the properties belonging to the said EF 02 are displayed. These properties include the name (EF 02), the file identifier (5F), the file structure (linear fixed) the access conditions or equivalent access conditions (READ) and the file size or equivalent filesize (2 records a × byte). Preferably, the file structure also contains a master file MF (root directory) (not shown in FIG 8th ).

Depending on The type of configuration to create can be in addition to the above file structure elements (e.g., files, records), nor key definitions created and / or managed. These key definitions are hierarchically superior, inserted into the file structure.

to Postprocessing of the file structure are in the file / record editor made the desired changes. For example, existing files (elementary files (elementary files) or Dedicated Files), records or TLV objects edited or added to the existing file structure new files (Elementary Files or Dedicated Files), Records or TLV objects added or existing files or records or objects deleted.

1. Editing files, Records or TLV objects

The user marks with the mouse the file to be edited (EF or DF) or the record to be edited or the TLV object in the file structure tree (left side of 8th ). In the selection list and editor area (right side of 8th ) opens the file / record editor, in which the corresponding information is edited (ie entered or changed) can be. The editable (ie modifiable or enterable) details are filetype, filesize, filestructure, access conditions, etc .. The resulting file structure from the compilation is thereby adapted in content to the wishes of the user. The production file with which the microprocessor is to be personalized later is generated when called with these inputs or changes.

2. Insert from Files, Records or TLV objects

To the existing file structure Files (EF, DF), records or TLV objects added become. For this purpose, the user must use the file or record, under which he has a new file, a new record or a new TLV object create, with the mouse mark in the file structure tree. Then must he one of the controls "new Key definition "," New DF "," New EF "," New Record "or" New TLV Object "to open the desired Element (DF, EF or Rec, TLV object). After the "New / n" control element (key definition, DF, EF or Rec., TLV object) " has been made, the desired appears Element at the desired insertion in the file structure tree. The newly created element is initially empty and must or can be edited by the user in the file / record editor. Some information can be mandatory to enter, others may be optional or Need to be entered.

3. Delete files, records or TLV object

Out the existing file structure Key definitions Files (EF and / or DF), records and TLV objects are deleted. To do this, the user must move the element he wants to delete with the mouse in the Mark file structure tree. Then he has to click the "Delete" control element to select the desired element to delete. By pressing (e.g., clicking) the delete control the selected element is deleted from the file structure tree. These this element is a file, the hierarchically subordinate one Elements, e.g. Records, contains, so these hierarchically subordinate elements also become deleted.

According to one Variant of the invention, the file structure is already in one for the Personalization software appropriate data format before, so they directly as a production file for the personalization software can be used. At the preferred Variant of the invention is the file structure in an additional Generating step in a production file for the personalization software transformed. Preferably, the file structure is in the XML data format, especially in the EMC XML data format, transformed. In a variant of the invention can also be a different format for the Production file to be used.

IV. Generating the production file (Optional)

Of the User has a valid File structure generated, either only by loading from existing ones Files and / or only by compiling from the TLV object tree, or with a subsequent editing of the file structure. outgoing from the already performed Procedural steps is because the control element "Generate production file" activated, so that it is ready, pressed to become.

Thereby, the user in the file structure tree window the control element "production file generate "is pressed from the displayed file structure the production file in (EMC) - XML format generated. There is already a name for the current configuration (for example, by loading a project file with a specific name, see. below) this is for the production file is used, otherwise the "Save as ..." dialog opens - standard Windows dialog, in which the user must specify destination directory and file name. The file extension "* .xml" becomes automatic supplemented by the tool.

About these * .xml file is preferred for backing up the information contained another checksum calculated and stored in the production file. The XML format is the preferred EMC-specific format currently used in personalization of EMV smart card microprocessors.

in the specified target directory of the tool is a * .xml file, namely the Production file, with the currently configured configuration under the given name.

The object structure (not yet compiled form of the configuration, possibly additionally edited) and the file structure (compiled form of the configuration, possibly additionally edited) can also be saved, each in a project file.

V. Save the project files

1. Save the TLV object structure (not compiled form)

Of the User has selected at least one ROM mask and transferred it to the TLV object tree; In this case, further applications and TLV objects may be created and possibly edited.

Around To save a TLV object structure, the user must select the menu item "TLV object tree | Save" or "TLV object tree | Save as ... "selects Exists already a name for the current configuration, then it will be saved under this If there is no one yet, a name has to be given first. In this Case opens the "Save under ... "- standard Windows dialog, in which the user must specify destination directory and file name. The project file extension, e.g. "* .teo" (template editor objects), is automatically completed by the tool.

in the specified directory is the project file (not compiled Form in object format) with the specified name. The saved Information includes the current ROM mask selection and the compiled Object structure with all applications, their associated TLV objects as well as the currently valid Compilierungsregeln. In each case also all entered attributes become saved. Not part of saving in a project file is the compilation of the file system. The compilation may need to be postponed to load the project file again or for the first time.

The saved project file leaves by clicking on corresponding controls in the GUI reload and continue processing.

According to one Alternative embodiment is also an (intermediate) generating of File system and production file for storage in the same possible. in this connection are only file and record specific, but not the complete Object-specific information that is in the TLV object tree, stored in (EMC) XML format. A project (configuration) is therefore preferred not as a production file (* .xml format), but as a Object structure (e.g., * .teo file format) stored. The * xml file is preferably exclusively as a production file and not as a storage file.

2. Save the file structure (Filestructure) (compiled form)

Of the User has a valid File structure created (and in particular a compilation carried out) and possibly edited. The file structure tree is not empty.

Around To save a file structure, the user selects the menu item "File structure tree | Save "or" menu item "File structure tree | Save as ... ". There already exists a name for the current file structure, then it will be saved under this If there is no one yet, a name will be assigned on request. In this latter case opens the "Save under ... "- standard Windows dialog, in which the user must specify destination directory and file name. The project file extension, e.g. "* .xml" will be automatic supplemented by the tool.

in the specified directory is the project file (compiled form in file format) with the specified name. The stored information contain the current file structure. There are also all entered information (attributes). Not part saving in a project file is the creation of a production file. This must if necessary be recreated after loading the project file.

The saved project file leaves by clicking on corresponding controls in the GUI reload and continue processing.

In the stored filament structure are according to the described embodiment no information about the TLV object structure, which is the base of the file structure (filestructure) forms contain. A complete one conclusion from this compiled project file to the TLV object tree therefore not possible. The non-compiled project file described above serves this purpose (e.g. * .teo file). For this reason, in this embodiment after loading a compiled project file (e.g., * .xml file), editing not possible on TLV object level.

Preferably let yourself to each created configuration (program code for personalization) one Create a configuration description, preferably in the form of a *.PDF file.

VI. Generate the configuration description (* .pdf file) (optional)

It was either a TLV object structure (uncompiled form) or creates or loads a file structure (compiled form) TLV object or the file structure tree is not empty.

from User becomes a description of the created TLV object or file structure tree created and saved in a * .pdf file. This chooses the User the menu item "File | Create | * .pdf file "or the corresponding menu bar icon at. There already exists a name for the current configuration, then it will be saved under this If no one exists yet, a name will be given first. In this case opens the "Save as ... "- standard Windows dialog in which the user must enter destination directory and file name. By entering and subsequently confirming the destination directory and Filename becomes the * .pdf file with the description in the destination directory created under the file name. The file extension "* .pdf" becomes automatic supplemented by the tool.

These * .pdf file may e.g. serve the purpose in the previous steps defined file structure of a customer for whom the program code (configuration) is created, stored and, if necessary, as part of the contract, i. as part of the requirement definition, to print and sign allow. The pdf format is preferred because it is system independent and thus a once defined formatting always respected becomes

VII. Logging (optional)

Preferably a logging is carried out parallel to the method the over performed operations such as e.g. Compilierungsvorgänge and editing operations Book guided becomes.

1. Logging the compilation process from the TLV object structure to the file structure

When Prerequisite in the TLV object tree is a structure from ROM mask, possibly applications and possibly TLV objects created. The user bumps the logging process indirectly, by using the "Generate File Structure" control panel Invoke compilation process.

The Logging is not triggered explicitly by the user, but rather comes on automatically with a compilation process. All are logged implementation processes (e.g., "write TLV object TAG 4711 to file EF 02, record 03 ") from the object structure to the file structure (File structure). These conversions are reflected in the log window, preferably line by line, analogous to the compiling and linking operations in common Developer suites such as MS Visual Studio (TM Microsoft TM). Furthermore the log is also written to a * .log file.

in the Log windows are available - preferred line by line - all implementation processes and can if necessary, be completely viewed via scrollbar. The * .log file is in the current one Working directory of the tool and preferably bears the name of the current templates (the * .xml or * .teo project file), but with the extension *.log. If such a name has not yet been assigned, the user becomes before compiling (and thus creating the log). For example, the * .log file will work by the hour, by the day, or created weekly, preferably by the day, or alternatively or additionally after the occurrence of special events such as system crashes of the Systems on which the software tool to create the configuration (program codes) is running, and like.

2. Logging the manual edits within the file structure

requirement in that in the file structure tree, a structure of e.g. MF (masterfile), DF, EF and Records is created. The user initiates the logging process manual editing indirectly.

Logging is not initiated explicitly by the user, but is automatically included in the editing process. The insertion and deletion of files and records is also logged in, not overwriting or specifying file or recorder properties. This insertion and deletion is displayed line by line in the log window, analogous to the compiling and linking processes in common developer suites such as MS Visual Studio (TM Microsoft TM). In addition, the log is also in a * .log file written.

in the Log windows are available - preferably line by line - all insertion or deletions and can possibly be completely viewed via scrollbar. The * .log file is can be found in the current working directory of the tool and is named the current configuration (i.e., the * .xml or * .teo project file, for example), provided with the extension * .log. Was not such a name yet the user is compiled before (and thus the log creation) pointed out. The * .log file is preferably day by day created, but can also be created by the hour or by the week become. Alternatively or in addition The * .log file may crash after special events such as system crashes Systems on which the software tool for creating the configurations (Program codes) is running, be generated.

Claims (18)

Method for creating a program code for Personalizing a disk, in particular a chip card, for electronic payments, whereby a) in a creation step an object structure of the program code is created, the personalization data, especially for the electronic payments specific personalization data, to personalize the disk having, b) in a compilation step, the object structure is compiled to a file structure of the program code, the one Has data format for a software tool for personalizing the data carrier readable is, or that is convertible into such a data format, in which the creation of the object structure in the creation step a) Input is performed in a graphical user interface (GUI), wherein at least one provided prefabricated program code element selected becomes. The method of claim 1, wherein in the building step a ROM mask is selected, which causes subsequently only with the ROM mask Compatible program code elements in the graphical user interface (GUI) selectable are. The method of claim 1 or 2, wherein as a program code element at least one application is selected, in particular one for the electronic payment specific application, e.g. that of a credit card or a debit card or an electronic one Wallet. Method according to one of claims 1 to 3, wherein properties the program code element are edited by in the graphical Benut zeroberfläche (GUI) one or more for the program code element entered specific information and / or changed become. Method according to one of claims 1 to 4, wherein in the production step a) through inputs in a graphical user interface (GUI) within the program code element at least one TLV object is selected and thereby inserted into the program code element. A method according to claim 5, wherein properties of the TLV object can be edited by using the graphical user interface (GUI) one or more for the TLV object specific information is entered and / or changed. Method according to one of claims 1 to 6, wherein properties edited the file structure created in the compilation step are made in the graphical user interface (GUI) input to the file structure and / or changes the file structure are made. Method according to one of claims 1 to 7, wherein further c) in a conversion step, the file structure into a data format that is converted for a software tool for personalizing the data carrier readable is. The method of any one of claims 1 to 8, wherein the compiling step b) according to predetermined compilation rules carried out becomes. The method of claim 9, wherein the compilation rules by entering in the graphical user interface (GUI) selected and / or changed become. The method of claim 10 in conjunction with claim 2, wherein by selecting the ROM mask, only compilation rules compatible with the ROM mask can be selected. Method according to one of claims 1 to 11, wherein the application according to claim 3 and / or the compilation rules according to one of claims 9 to 11 and / or the TLV object according to claim 5 or 6 is provided in a database. The method of any one of claims 1 to 12, wherein further the file structure generated in the compilation step b) Input / s in the graphical user interface (GUI) is changed. Method according to one of claims 1 to 13, wherein the in the creation step a) created object structure in an object file is stored. The method of claim 14, wherein in the object file additionally those according to claim 10 modified compilation rules be stored. Software tool for performing the procedure after a the claims 1 to 15. disk with a method implemented therein according to one of claims 1 to 15th disk with a software tool implemented therein according to claim 16.