WO2004072849A1

WO2004072849A1 - Method for creating a program code

Info

Publication number: WO2004072849A1
Application number: PCT/EP2004/001453
Authority: WO
Inventors: Bernd Müller; Gary Jones; Stefan Angermeier; Rainer Simmet; Peter Niebler; Gerhard Stix; Anton Sontheim; Heiko Oester; Martin RÖSNER; Jens Rudolph
Original assignee: Giesecke & Devrient Gmbh
Priority date: 2003-02-17
Filing date: 2004-02-16
Publication date: 2004-08-26
Also published as: DE10306717A1; EP1597670A1; WO2004072849B1

Abstract

The invention relates to a method and a software tool for creating a program code, in particular for a chip card that controls a mobile terminal. According to said method: a) in a design step, a graphic design is created on a graphical user interface of a computer system by dragging icons (drag & drop) on a working surface and by linking the icons using lines; b) in a build step, the source code is created for the design and c) in a compiling step an intermediate code is created. The method can be carried out in the terminal. Alternatively, the method is carried out outside the terminal and the created intermediate code is uploaded to the terminal or to a chip card that is provided in said terminal.

Description

Procedure for creating program code

The invention relates to a method for creating program code, in particular for a chip card, for communication with a mobile terminal.

In this text, a mobile end device is understood to mean a cell phone, a personal digital assistant (PDA), a combined device consisting of a cell phone and a PDA or an electronic organizer or a similar device that is suitable for organization or communication or similar activities and that is also suitable to be carried by the user on the body, in clothing or in small hand luggage.

In this text, a chip card is understood to mean a data carrier with an electronic circuit and a card body. The card body can have any format such as, for example, credit card format or SIM card format. The chip card can be a pure memory card or a microprocessor card with a CPU and one or more memories. In connection with the invention, the chip card is preferably a microprocessor card.

Program code, in particular for a chip card, for controlling a mobile terminal can be created in a programming language used, for example by direct programming, by entering the source code character by character and then compiling it. This requires programming knowledge in the programming language used. In object-oriented programming, it is known to integrate a preprogrammed source code module into the program sequence for a self-contained functional unit that is to be executed in a program sequence, so that the source code of the functional unit no longer needs to be programmed character by character. As a result, more complex program sequences can be created even with less programming knowledge.

The object of the invention is to create a method and a software tool for carrying out the method, with which program code for controlling a mobile terminal can be created in a simple and intuitive manner and without extensive programming knowledge.

The object is achieved by a method according to independent method claim 1, by a software tool according to independent software tool claim 26 and by a data carrier or computer or a mobile terminal with a software tool or program code implemented therein, that was created with the software tool or according to the procedure.

Advantageous developments of the invention are set out in the dependent claims.

In the method, the graphic design of the program code to be created is created in the design step. To do this, icons are positioned on the graphic work surface and connected with each other by lines. Each icon corresponds to a functional element that one corresponding source code and, in compiled form, corresponds to a corresponding intermediate code. The arrangement of the icons determines which functions are to be carried out later by the program code. The program flow is determined by drawing the lines between the icons, ie the sequence in which the functions behind the icons run when the program code is subsequently executed.

The method has the advantage that no programming knowledge in a specific programming language is required to create program code, regardless of the programming language in which the source code or intermediate code is created. It is sufficient to be familiar with the operation of graphical user interfaces by means of input devices such as a mouse, trackball, keyboard, touch screen and the like, depending on which input device the graphical user interface is operated with. The fact that the program sequence is defined by simply drawing graphical lines makes the process particularly simple and intuitive.

The source code, which corresponds to a functional element, can be integrated directly into the runtime source code, but is preferably provided in that a function call to the source code of the functional element is incorporated into the runtime source code. The function call is preferably directed to an entry of the associated function element in a library source code file.

Functional elements and connections can also be configured using parameters. Regarding the compiled intermediate code for the functional elements, according to a first embodiment of the method according to the invention, the intermediate codes of the functional elements are carried along with the intermediate sequence code, ie compiled into the intermediate sequence code file. In this case, the compiled functional elements preferably form a separate library section, which, however, lies within the sequence intermediate code file. This embodiment has the advantage that only the intermediate codes of those functional elements that are absolutely necessary have to be carried. As a result, the memory requirement of the program code created is small.

In the event that it is provided that a larger number of program codes are created using the method according to the invention and stored in the same mobile device or in the same chip card, the following second embodiment of the method according to the invention is preferred. According to the second embodiment, only function calls to the functional elements are carried in the intermediate code for the functional elements used in a program code. The intermediate codes of the functional elements themselves are kept in a corresponding library intermediate code file, separate from the sequence intermediate code file, and are not used during the execution of the actual method. The library intermediate code file does not need to be available, in particular during the creation of the program code. It is sufficient if the library is available for the subsequent execution of the program code. The library intermediate code file only needs to be set up once on the mobile device or the chip card on which the program code is to run later. The library intermediate code file used in the second embodiment preferably contains others

Functional elements that are available for the implementation of the method, but which are not used in the currently created program code. The library intermediate code file further preferably contains an inventory of intermediate codes that is independent of the implementation of the method.

According to a third embodiment of the invention, it is possible to choose within the method whether the intermediate code for the functional elements according to the first embodiment is integrated directly into the intermediate flow code or, according to the second embodiment, only one in the intermediate flow code Function call is to be integrated, whereas the intermediate codes of the function elements remain in the library.

The method can be carried out on a personal computer or server or on a mobile terminal or on any data carrier with at least one memory and a microprocessor (computer system in the broadest sense).

A compiler that is only available for the method or a compiler that is also available for other programs can be used to compile source code in the compilation step. The source code or the intermediate code, possibly including the parameters, can preferably be stored in a project file on the computer or other device or data carrier mentioned above. This means that the creation of program code can be interrupted and later continued again using the project file.

In addition, graphic design data are preferably stored in the project file, which allow a reconstruction of the graphic design created in design step a) by calling up the project file.

The project file can preferably be saved in XML format, since this file format is particularly suitable for data exchange.

Optionally, a created program code, in particular the source code or intermediate code contained in the project file, can be declared as a further function element and preferably a new graphic icon can be generated for the function element declared in this way. The new graphic icon, which belongs to the declared further functional element, can be arranged in the design step in subsequent program creation as described above in order to create further program code, in which the program code of the declared functional element is (again) used as a modular program element. The project file can also be transferred to another device, i.e. Computer, chip card, mobile device or other storage device or

Memory processor device, stored as the device on which it was created. According to a preferred embodiment, at least one of the functional elements is a proactive command, in particular for mobile radio applications. Proactive commands are used to control the functions (e.g. for display issues, etc.) of mobile devices such as cell phones or personal digital assistants (PDAs). For example, the proactive command is a proactive SIM command according to the GSM specification 3GPP TS 11.14.

According to one embodiment of the method, the method is carried out at least partially outside the chip card and the mobile terminal for which the program code is created. In this case, the source code or the intermediate code is further loaded onto the chip card and / or onto the mobile terminal device in a loading step.

If, according to the second or third embodiment described above, only function calls are contained in the intermediate code with regard to the functional elements, a library intermediate code file is additionally loaded onto the chip card or the mobile terminal. If the chip card or the mobile device has a suitable compiler, the library can also be loaded in source code form, as a library source code file and then compiled on the chip card or the device. In this case, the sequence code, ie the program code created, can also be loaded in source code form onto the chip card or the terminal and only be compiled there. The library is preferably loaded only once, independently of the program codes or together with a program code. For example, the library can be loaded when a program code is loaded onto the card or the end device for the first time. Each time a program code is loaded, it can optionally be checked whether a library already exists and, if no library exists, the library is also loaded.

Charging can be carried out contact-based via a reader or contactless, or partly contact-based, partly contact-free. The program code is particularly preferably created on a computer, loaded from there onto a server, and made available on the server, for example via the Internet. From the Internet browser, the program code can be sent to a predetermined mobile phone via SMS. Alternatively, a cell phone can request that the program code be sent to the cell phone via SMS. In the mobile phone or other mobile terminal, the program code is loaded onto the chip card and / or the terminal and interpreted by an interpreter implemented there into an executable code. The functionalities of the end device, such as the display, loudspeaker, etc., are controlled by the interpretable code.

The program code loaded onto the mobile terminal (chip card and / or terminal directly) or the program code created there is preferably used to create a menu entry in the menu of the terminal, which is integrated into the originally existing menu entries and is designed in the same appearance.

Preferably, a loading parameter can be defined during the implementation of the method, by means of which it is predetermined in which area the chip card and / or the mobile terminal is loaded with the source code or the intermediate code in the loading step.

The chip card preferably has the memory areas RAM, EEPROM, flash memory and ROM, and the loading parameter determines in which memory area the source code or the intermediate code is loaded in the loading step. For example, the library, if it is loaded separately, is stored in the flash memory and the program code, if it is loaded without a library, is loaded into the EEPROM.

The invention is explained in more detail below on the basis of exemplary embodiments and with reference to the drawing, in which:

1 shows an example of a graphical user interface according to the invention for use by the method or software tool according to the invention;

Fig. 2 shows an example of a work surface according to the invention, which is shown on a graphical user interface, and on the one

A plurality of icons and the connections connecting the icons to one another are shown graphically;

3 shows a schematic representation of a plurality of program codes created with the software tool according to the invention, which can access a common library; 4 shows a schematic representation of the method according to the invention, with steps a), b) and c), using the example of Java as the programming language;

5 shows a schematic detailed illustration of the sequence source code generated in build step b) from FIG. 4, according to a preferred embodiment of the invention;

6 shows a schematic representation of a library source code file according to the invention;

7 shows a schematic illustration of a sequence intermediate code according to a first embodiment of the invention;

8 shows a schematic illustration of an intermediate sequence code according to a second embodiment of the invention, according to a first variant, with a specific library;

Fig. 9 is a schematic representation of an intermediate flow code according to the second embodiment of the invention, according to a second

Variant, with a process-independent library;

Fig. 10 is a schematic representation of several intermediate flow codes according to the second embodiment of the invention, according to the second variant, with a process-independent common

Library; 1 shows an example of a graphical user interface according to the invention for use by the method or software tool according to the invention. The graphical user interface is divided into windows in a manner customary for computers. In a two-line header 101, commands are displayed with which functions of the software tool can be carried out. For example, by activating "File" in the top line, a pop-up menu can be opened (not shown), in which a submenu "New" enables the opening of a new project or a new work space and a submenu "Open" allows you to open a saved project file. In the lower line of the header 101 (toolbar) there are circuit symbols with which functions can also be activated, for example "Open file" by activating the "Open hanging folder" symbol. A tree-like menu structure can be displayed in a project window 102, which corresponds to the structure of the currently open project file and which also in this form with the respective ones

Text is displayed on the mobile device. The project file shown in FIG. 1 with the name Mobile_Banking contains six different program codes, namely account balance_views, transfer, connections, accounts, service and contact. The program code Account Balance_View is contained in a project sub-file called Account Balance, which is hierarchically subordinate to the Mobile_Banking project file. Each of the six program codes was created using the method according to the invention with the software tool according to the invention. The project file is saved in XML format. According to the hierarchical structure of the program codes, the menu structure in the project window 102 contains a higher-level menu entry Mobile_Banking, six subordinate ones Submenu entries of the second level, namely account balance, transfer, connections, accounts, service and contact, and a submenu entry of the third level, namely account balance_display. By activating one of the submenu entries, the associated work area with the associated icons and connections is shown in the work window 103. In Fig. 1, the submenu entry Account Balance_Display is activated in the project window 102 and consequently the graphic design for the program code Account Balance_Display is displayed on the work surface 103.

There is a between the project window 102 and the work window 103

Command bar 104 arranged, which contains a plurality of icons to be used for the work surface (command symbols). The icons represent proactive SIM commands according to the GSM specification 3GPP TS 11.14, e.g. DISPLAY TEXT at the top, PLAY TONE etc. at the fourth, and a START symbol and a STOP symbol at the two lowest positions, which mark the beginning or end of a respective program code. The icons (command symbols) can be dragged and dropped onto the work surface, i.e. by activating a tick mark (cursor) on the icon, dragging the tick mark together with the icon into the work surface 103, and deactivating the tick mark on the work surface, whereupon the icon is placed on the work surface 103.

FIG. 2 shows the work surface from FIG. 1 separately. A plurality of icons and the connections connecting the icons to one another are shown graphically on the work surface. The icons have been arranged on the work surface by pulling them from the command bar 104 or have been dragged from the header 101 onto the work surface (see above). The icons are connected by connecting lines. Each connecting line is drawn by activating a cursor (marker) over a first icon, dragging it to the second icon and deactivating it there again. A connecting line drawn in this way from the first icon to the second icon means at program level that first a first command corresponding to the first icon and then a second command corresponding to the second icon are executed. With the program code from Fig. 2, after the start (START), text is first shown on the display (DISPLAY TEXT), then an input is accepted (GET INPUT), then a short message (SMS) is sent (SEND SMS), and finally a text is displayed again (DISPLAY TEXT), after which the program code has ended (STOP).

In FIG. 1 it can be seen that the icon (command symbol) GET INPUT is currently activated on the work surface 103. Correspondingly, a plurality of parameter fields are displayed in a parameter area 105, into which parameters for the configuration of the functional element for the displayed icon, in this case the functional element GET INPUT, can be entered. For example, you can enter the PIN in the "Question" field when asked "Please enter PIN". The minimum and maximum response size (response size) can be entered in the two parameter fields below. 0 or 255 are currently entered.

The connections between the icons can also be configured using parameters. It is specified, for example, which response code of the mobile terminal to the first command refers to the further process affects, or in which path the process is continued. Another parameter can be the format in which the first command passes data to the second command. The functional elements can also be configured using parameters. In order to configure the respective functional element or the respective connection using parameters, for example in the design step a) an input mask is shown in or next to the graphical work surface or otherwise on the graphical user interface, into which the parameters are entered. In the subsequent build step, the parameters entered are integrated into the source code.

A proactive command, for which an icon is shown on the work surface, is the DISPLAY TEXT command in accordance with the GSM specification 3GPP TS 11.14. The DISPLAY TEXT command, executed on a SIM card of a mobile phone, has the effect that a specific text is shown on the display of the mobile phone. The DISPLAY TEXT command is configured for this by the parameter of the specific text that is to be displayed. With PLAY TONE, played on the SIM card of a combined PDA mobile phone, a sound is emitted through the loudspeaker of the PD A mobile phone. Suitable parameters can, for example, indicate pitch and duration. Further proactive commands can be found in the GSM specification 3GPP TS 11.14.

According to a variant, connecting lines that begin and end on the same icon, that is, form a loop, can be used, for example, to incorrectly input the user on the mobile Repeat end devices and to correct incorrect statements (not shown here).

According to a further developed variant of the invention, a created program code is declared as a new functional element and a new icon is generated for the declared functional element. According to the invention, the program code has been generated from a graphic design with several icons for several functional elements, for example from a graphic design such as that shown in FIG. According to the example from Fig. 1, for example, the source code or the intermediate code in the project file with the name Mobile_Banking is declared as a new functional element with the same name "MobileJBanking" and an associated icon is generated. The different program codes in the project are generated in an analogous manner - Subfiles account balance_view, transfer, connections, accounts, service and contact as

Functional elements with the names Kontostand_ anzeigen, transfer, connections, accounts, service or contact are declared and an associated icon is created for each of the declared functional elements. If subsequently a program code is to be created which carries out the function of the project sub-file, for example transfer, then the icons from which "transfer" is composed do not need to be individually arranged graphically and connected to one another, but rather the prefabricated, newly declared functional element "transfer""are used and the associated" transfer "icon is arranged graphically. The same applies to the remaining project sub-files and the higher-level project file" Mobile_Banking ". 4 shows a schematic illustration of the method according to the invention, with steps a), b) and c). Java is used as an example as the programming language. However, the method can also be carried out with another, preferably object-oriented, programming language. The process is preferably carried out with the in Fig. 1 and Fig. 2 illustrated software tool _¥.

In the design step a), three icons 402 are successively dragged onto the work surface. A proactive command is represented by each icon 402. In the case of FIG. 4, these are the proactive commands DISPLAY TEXT, PLAY TONE and SEND SHORT MESSAGE (cf. also FIG. 6). The icons 402 are connected to one another by connecting lines 401. This determines that later, when the program code is run on the end device and / or the associated SIM card, the DISPLAY TEXT command, then PLAY TONE and then SEND SHORT MESSAGE should be carried out.

In build step b), which is started, for example, by activating the "Build" command in the header 101 from FIG. 1, an execution source code main.java is created from the connecting lines 401 on the work surface, as in Fig. 4 is indicated by the arrows. The more detailed structure of the main.java file is explained below (see Fig. 5).

In compilation step c), the runtime source code main.java is compiled into the runtime intermediate code file main.cap by means of a compiler (cf. also FIGS. 7 to 10). The file main.cap is of the CAP format, ie of the Card Application Format, and is therefore suitable for to be interpreted by a Java Card interpreter like a Java Card Virtual Machine. The file main.cap is usually created more precisely by first creating a class file main.class by a compiler in the narrower sense, and then using a converter to convert the main.cap sequence file from the main.class file is created. In the example from FIG. 4, the intermediate code is thus a converted Java byte code of the CAP format, whereby Java byte code is understood to be a code of the CLASS format.

FIG. 5 shows a schematic detailed representation of the main.java run source code generated in build step b) from FIG. 4, according to a preferred embodiment of the invention. The runtime source code main.java contains source codes 1 of connecting lines and function calls 2 on function elements that correspond to icons. The function calls 2 preferably also contain parameters for configuring the function elements in the main.java execution source code. The function calls 2 are directed to entries of the source codes of the function elements in a library source code file library.java, as shown in FIG. 6. The library source code file library.java from FIG. 6 contains as entries the source codes of all functional elements that are available to the method or software tool.

Fig. 7 shows a schematic representation of a sequence intermediate code file main.cap according to a first embodiment of the invention. The intermediate codes for the connections 1, 401 and also for the functional elements 2, 402 are stored in the sequence intermediate code file main.cap. Internally, the sequence intermediate code file is main.cap in one Flow section 701 and a library section 702 divided. The execution section 701 contains the compiled execution source codes 1 and source code function calls 2. The library section 702 contains the compiled source codes 2 of the functional elements, but only for the functional elements whose icons 402 are contained in the design. For icons 402 that occur several times in the design, the associated intermediate code need only be provided once in the library section 702. 8 shows a schematic representation of an intermediate sequence code according to a second embodiment of the invention, according to a first variant, with a specific library. In comparison to the run intermediate code file main.cap from FIG. 7, the run intermediate code file main.cap from FIG. 8 contains only one run section with compiled run source codes 1 and source code function calls 2. The intermediate codes of Function elements for which an icon 402 is included in the draft are stored in a separate library intermediate code file library.cap. The library intermediate code file library.cap can thus be saved, copied or loaded separately from the sequence intermediate code file main.cap. In particular, for example, when program code is loaded from a computer on which the program code has been created onto a chip card for which the library intermediate code file library.cap a different storage location is selected than for the sequence intermediate code file main .cap. For example, library.cap can be written in the flash memory and main.cap in the EEPROM of the chip card.

FIG. 9 shows a schematic illustration of a sequence intermediate code according to the second embodiment of the invention, according to a second Variant, with a process-independent library. In comparison to the variant shown in FIG. 8, the library intermediate code file library.cap contains the intermediate codes of all functional elements available to the method or software tool, including those of the functional elements that are not currently being used. As a result, the library intermediate code file library.cap can be used universally regardless of the program code created according to the invention. The library intermediate code file library.cap can thus also be used as a common library for several program codes generated according to the method, as shown in FIG. 10.

10 shows a schematic representation of a plurality of sequence intermediate codes mainl.cap, main2.cap, main3.cap according to the second embodiment of the invention, according to the second variant, with a process-independent shared library library.cap. This variant is also illustrated in FIG. 3. Several expiry intermediate codes access one and the same separate library intermediate code file library.cap. For this purpose, the library intermediate code file library.cap contains a process-independent inventory of intermediate codes of functional elements. The inventory can preferably be expanded and reduced, which is preferably done independently of the creation of the main.cap program code. Since the common, universal library intermediate code file library.cap only has to be loaded once, it can be written, for example, into a memory which is difficult to rewrite but has other advantages, for example, it is cheap or fast or permanent. The program codes main.cap or maini.cap, i = 1, 2,3, ... are preferably divided into one comparatively easily rewritable memory written, for example in the EEPROM or in the flash memory.

According to one embodiment, the method is carried out directly on the mobile terminal on which the program code is to run later. For this purpose, for example, the display of the terminal device is used in particular to display the graphical user interface. This is particularly possible with the high-quality displays of the newer generations of mobile phones and PDAs and combined devices. To operate the display, the infrastructure used by the end device is used, i.e. Keyboard, touch screen, possibly with stylus, cell phone keys etc.

According to a further embodiment, the method is carried out on a computer and the intermediate code main.cap, possibly together with the library library.cap, is loaded onto the mobile terminal, preferably onto a chip card installed there, alternatively also or partly onto the terminal itself the chip card, partly on the end device. The interpreter provided on the chip card or in the terminal, for example a Java Card Virtual Machine, finally interprets the program code as an executable code by means of which the functionalities of the mobile terminal can be controlled. The chip card can in particular be a mobile phone card of the SIM generation and in this case is preferably a Java card which complies with the GSM specification 3GPP TS 11.14. The proactive commands do not necessarily have to be SIM commands, but can also be USIM commands or commands according to another mobile radio standard or other communication standard.

The program code which is provided after the compilation step c) in order to be executed or to be loaded onto the chip card and / or onto the mobile terminal and then to be executed is preferably a Java applet. ,

The applet is preferably loaded by storing the applet on a server that is accessible via the Internet. An internet user can, for example against payment, arrange for the applet to be sent to his or her mobile device (e.g. cell phone) via SMS. Alternatively, he can initiate the download of the applet directly from his mobile device.

The library that may be required can be downloaded in the same way as the applet. If a common, universal library is used as the library, it only needs to be downloaded once, even if several applets are loaded one after the other. As a result, the consumer who purchases the applets can save expensive connection costs for the mobile (contactless) connection between the server and his mobile terminal device, which makes downloading the applets more attractive for consumers. The applet may contain the information on which memory area of the chip card of the end device it is loaded, the information already being specified when the applet was created.

Claims

Patent claims

1. A method for creating program code, in particular for a chip card, for controlling a mobile terminal, wherein a) a graphic design is created in a design step on a graphical user interface of a computer system by one or more graphical icons being displayed on a graphical user interface graphic work surface and, if more than one icon has been arranged, the icons are connected by graphic lines, so that a

Structure of icons interconnected by lines is formed, with each icon schematically representing an associated functional element and each graphical line graphically representing a connection at program level between the functional elements connected by the line, b) in a build step from the graphic design, a source code (main.java, library.java) of the program code is created by providing the source code of the associated functional element for each graphic icon contained in the structure and for each graphic line contained in the structure on the work surface of the

Source code (1) of the connection is provided, with the provided source codes (1) of the connections forming an execution source code (main.java) by which the execution of the program code is determined, c) an intermediate code in a compilation step ( main.class, library.class, main.cap, library.cap) is created, which can be read by the interpreter implemented on the chip card and / or the mobile device into the chip card and / or the mobile device executable code is interpretable, whereby the runtime source code is compiled into a runtime intermediate code file (main.class, main.cap).

2. The method according to claim 1, characterized in that at least one functional element and / or at least one connection is configured by parameters.

3. The method according to claim 1 or 2, characterized in that when the source code of the respective functional element is provided, a function call (2) is integrated into the source code of the functional element in the sequence source code (main.java), the function call (2) preferably is directed to an entry of the functional element in a library source code file (library.java).

4. The method according to any one of claims 1 to 3, characterized in that in the compilation step c), when creating the intermediate code, the intermediate codes of the functional elements for which an icon has been inserted into the structure in the design step a) can be integrated into the sequence intermediate code file (main.class, main.cap), in particular by compiling the associated source codes.

5. The method according to any one of claims 1 to 3, characterized in that in the compilation step c), when creating the intermediate code, for the functional elements for which an icon has been inserted into the structure in the design step a) Function call on the

Intermediate code of the functional element is integrated into the sequence intermediate code file.

6. The method according to claim 5, characterized in that the intermediate codes of the functional elements are provided in a library intermediate code file (library.class, library.cap) separate from the sequence intermediate code file.

7. The method according to claim 6, characterized in that the library intermediate code file (library.class, library.cap) contains an inventory of intermediate codes of functional elements, which is independent of the implementation of the method.

8. The method according to any one of claims 1 to 7, characterized in that during the implementation of the method is selected in which way for the functional elements, for which an icon has been inserted in the structure in the design step a), creates the associated intermediate code is, in particular whether, according to claim 4, the intermediate codes of the functional elements are also integrated into the intermediate flow code file (main.class, main.cap) or - according to one of claims 5 to 7, a function call to the intermediate code of the functional element is included in the sequence - Intermediate code file is integrated.

9. The method according to any one of claims 1 to 8, characterized in that all information about the respective project including menus used, work surfaces with icons and parameters and project options are stored in a project file, in particular in XML format.

10. The method according to claim 9, characterized in that additional graphic design data are stored in the project file, which allow a reconstruction of the graphic design created in the design step a) by calling the project file.

11. The method according to any one of claims 1 to 10, characterized in that further d) in an interpretation step by the interpreter implemented in the chip card and / or in the mobile terminal of the intermediate code in readable for the chip card and / or the mobile terminal executable code is translated.

12. The method according to any one of claims 1 to 11, characterized in that at least one of the functional elements is a proactive command, in particular for mobile radio applications.

13. The method according to any one of claims 1 to 12, characterized in that steps a) to c) are carried out partially or completely on the chip card and / or on the mobile terminal for mobile communication.

14. The method according to claim 13, characterized in that the graphical user interface is shown on a display of the mobile terminal and / or that the build step b) and / or

Compilation step c) carried out in an integrated circuit is formed in the chip card or in the mobile terminal or partly in the chip card and partly in the mobile terminal.

15. The method according to any one of claims 1 to 14, characterized in that the method is carried out at least partially outside of the chip card and the mobile device and that the source code or the intermediate code is further loaded onto the chip card and / or onto the mobile device in a loading step becomes.

16. The method according to claim 15, characterized in that in particular the library source code file (library.java) according to claim 3 or the library intermediate code file (library.class, library.cap) according to one of claims 6 to 8 the chip card or is loaded onto the mobile terminal or partly onto the chip card and partly onto the mobile terminal.

17. The method according to claim 16, characterized in that the library source code file (library.java) or the library intermediate code file (library.class, library.cap) is only loaded if at the destination of the store on the Chip card or the mobile device does not yet have a corresponding file.

18. The method according to any one of claims 15 to 17, characterized in that the charging in the loading step is carried out via a contact-based reader.

19. The method according to any one of claims 15 to 17, characterized in that the charging in the charging step is carried out at least partially without contact.

20. The method according to any one of claims 15 to 19, characterized in that the loading in the loading step is carried out at least partially via a server.

21. The method according to claim 20, characterized in that the loading is carried out by the source code or the intermediate code being provided on the server and subsequently being transmitted contactlessly to the chip card or the mobile terminal.

22. The method according to claim 21, characterized in that the contactless transmission to the chip card or to the mobile terminal is initiated either by the chip card or the mobile terminal or by the server.

23. The method according to any one of claims 15 to 22, characterized in that during the implementation of the method, a loading parameter is determined by which it is predetermined in which area of the chip card and / or the mobile terminal the source code or the intermediate code in the Loading step is loaded.

24. The method according to claim 23, characterized in that the

Chip card has a plurality of different memory areas, which preferably have one or more of the memory areas RAM, EEPROM, Flash memory and ROM, and that the loading parameter determines in which memory area the source code or the intermediate code is loaded in the loading step.

25. The method according to claim 24, characterized in that the

Chip card has an EEPROM and / or a flash memory and at least the sequence intermediate code is loaded into the EEPROM or flash memory during loading in the loading step.

26. The method according to any one of claims 1 to 25, characterized in that the program code created is declared as a new functional element that can be used according to the method according to one of claims 1 to 25.

27. The method of claim 26, wherein for the declared new

Functional element is created an icon that can be used according to the method according to any one of claims 1 to 26. ,

28. Software tool for performing a method for creating program code according to one of claims 1 to 27, comprising: a) a graphic control device for controlling the graphic user interface, so that a graphic design of the program code can be created by one or more graphic Icons are arranged on a graphical work surface shown on the graphical user interface and, if more than one

Icon has been arranged, the icons are connected by graphic lines, so that a structure of by lines interconnected icons are formed, with each icon schematically representing an associated functional element and graphically representing a connection at program level between the functional elements connected by the line, b) a build control device with which in a build Step from the graphic design a source code (main.java, library.java) of the program code can be created by providing the source code of the associated functional element for each graphic icon contained in the structure and for each graphic line contained in the structure on the work surface of the Source code of the connection is provided, whereby with the provided source codes of the connections an execution source code (main.java) is formed, by which the execution of the program code is determined, c) a compiler with which in a compilation step

Intermediate code (main.class, library.class, main.cap, library.cap) can be generated, which can be interpreted by an interpreter implemented on the chip card and / or the mobile terminal in executable code that can be read by the chip card and / or the mobile terminal , whereby the run source code is compiled into a run intermediate code file (main.class, main.cap).

29. Software tool according to claim 28, characterized in that it further comprises a library interface which is set up to provide source codes or intermediate codes of functional elements for the method, which are in a separate library source code file (library.java) or library intermediate code file (library.class, library.cap) are saved.

30. Software tool according to claim 29, characterized in that it further comprises a library selection device with which according to claim 8 can be selected in which way the associated intermediate code is created for the source codes of the functional elements.

31. Software tool according to one of claims 28 to 30, characterized in that it further has a loading selection device with which, according to one of claims 23 to 25, it can be selected in which area of the chip card and / or the mobile terminal the source code or the intermediate code is loaded in the loading step according to any one of claims 15 to 22.

32. Software tool according to one of claims 28 to 31, characterized in that all information about the respective project including menus used, work surfaces with icons and parameters and project options can be stored in a project file, in particular in XML format.

33. Software tool according to claim 32, characterized in that additional graphic design data can be stored in the project file, which allow a reconstruction of the graphic design created in the design step a) by calling the project file.

34. Data carrier with an integrated circuit and an at least partially implemented in the integrated circuit software tool according to one of claims 28 to 33.

35. Computer with an integrated circuit and an at least partially implemented in the integrated circuit software tool according to one of claims 28 to 33.

36. Mobile terminal with an integrated circuit and an at least partially implemented in the integrated circuit

Software tool according to one of claims 28 to 33.

37. Data carrier with an at least partially implemented program code, in particular source code (main.java, library.java) or intermediate code (main.class, library.class, main.cap, library.cap), according to a method according to one of the claims 1 to 27 has been created.

38. A data carrier according to claim 37, which is configured as a chip card, preferably with a microprocessor, in particular with a plurality of different memory areas, which preferably have at least one of the memory areas RAM, EEPROM, flash memory and ROM.

39. A data carrier according to claim 37 or 38, which is designed as a Java Card for a mobile terminal such as a mobile phone or a Personal Digital Assistant (PDA) or a combined device comprising a mobile phone and Personal Digital Assistant (PDA).