DE10306717A1

DE10306717A1 - Verfahren zum Erstellen von Programmcode

Info

Publication number: DE10306717A1
Application number: DE2003106717
Authority: DE
Inventors: Gerhard Stix
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2003-02-17
Filing date: 2003-02-17
Publication date: 2004-09-16
Also published as: WO2004072849A1; EP1597670A1; WO2004072849B1

Abstract

Die Erfindung betrifft ein Verfahren und ein Software-Tool zum Erstellen von Programmcode, insbesondere für eine Chipkarte, zum Ansteuern eines mobilen Endgeräts, wobei a) in einem Entwurfsschritt auf einer graphischen Benutzeroberfläche eines Computersystems durch Ziehen von Icons (nach Art des "Drag & Drop") auf eine Arbeitsfläche und Verbinden der Icons mit Linien ein graphischer Entwurf erstellt wird, b) in einem Build-Schritt der Quellcode zu dem Entwurf erstellt wird und c) in einem Compilierungs-Schritt ein Zwischencode erstellt wird. Das Verfahren kann auf dem Endgerät durchgeführt werden. Alternativ wird das Verfahren außerhalb des Endgeräts durchgeführt, und der fertige Zwischencode wird auf das Endgerät bzw. eine dort vorgesehene Chipkarte geladen.

Description

Die Erfindung betrifft ein Verfahren zum Erstellen von Programmcode, insbesondere für eine Chipkarte, zur Kommunikation mit einem mobilen Endgerät.
Unter einem mobilen Endgerät wird in diesem Text ein Mobiltelefon, ein Personal Digital Assistant (PDA), ein kombiniertes Gerät aus einem Mobiltelefon und einem PDA oder ein elektronischer Organizer verstanden oder ein ähnliches Gerät, das für Organisation oder Kommunikation oder ähnliche Tätigkeiten geeignet ist und das zugleich dazu geeignet ist, vom Benutzer am Körper, in der Kleidung oder in kleinem Handgepäck mitgeführt zu werden.
Unter einer Chipkarte wird in diesem Text ein Datenträger mit einem elektronischen Schaltkreis und einem Kartenkörper verstanden. Der Kartenkörper kann ein beliebiges Format wie beispielsweise Scheckkartenformat oder SIM-Kartenformat haben. Die Chipkarte kann eine reine Speicherkarte sein oder eine Mikroprozessorkarte mit einer CPU und einem oder mehreren Speichern sein. Im Zusammenhang mit der Erfindung ist die Chipkarte vorzugsweise eine Mikroprozessorkarte.
Programmcode, insbesondere für eine Chipkarte, zum Ansteuern eines mobilen Endgeräts kann in einer verwendeten Programmiersprache beispielsweise durch unmittelbare Programmierung erstellt werden, indem Zeichen für Zeichen der Quellcode eingegeben wird und anschließend compiliert wird. Dazu sind Programmierkenntnisse in der verwendeten Programmiersprache erforderlich.
In der objektorientierten Programmierung ist es bekannt, für eine in sich abgeschlossene Funktionseinheit, die in einem Programmablauf ausgeführt werden soll, ein vorprogrammiertes Quellcode-Modul in den Programmablauf einzubinden, so dass der Quellcode der Funktionseinheit nicht mehr Zeichen für Zeichen programmiert zu werden braucht. Hierdurch lassen sich auch mit geringeren Programmierkenntnissen komplexere Programmabläufe erstellen.
Aufgabe der Erfindung ist es, ein Verfahren und ein Software-Tool zum Durchführen des Verfahrens zu erstellen, mit dem sich auf einfache und intuitive Weise und ohne weitreichende Programmierkenntnisse Programmcode zum Ansteuern eines mobilen Endgeräts erstellen lässt.
Die Aufgabe wird gelöst durch ein Verfahren nach dem unabhängigen Verfahrensanspruch 1, durch ein Software-Tool nach dem unabhängigen Software-Tool-Anspruch 26 sowie durch einen Datenträger oder Computer oder ein mobiles Endgerät mit einem darin implementierten Software-Tool oder einem darin implementierten Programmcode, der mit dem Software-Tool oder nach dem Verfahren erstellt worden ist.
Vorteilhafte Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen angeführt.
Bei dem Verfahren wird in dem Entwurfsschritt der graphische Entwurf des zu erstellenden Programmcodes erstellt. Dazu werden Icons auf der graphischen Arbeitsfläche positioniert und durch Linien miteinander verbunden. Jedes Icon entspricht einem Funktionselement, das einem entsprechenden Quellcode und, in compilierter Form, einem entsprechenden Zwischencode entspricht. Durch das Anordnen der Icons wird festgelegt, welche Funktionen durch den Programmcode später ausgeführt werden soll. Durch das Ziehen der Linien zwischen den Icons wird der Programmablauf festgelegt, d.h. in welcher Reihenfolge die hinter den Icons stehenden Funktionen bei einer nachfolgenden Ausführung des Programmcodes ablaufen.
Das Verfahren hat den Vorteil, dass zum Erstellen von Programmcode keine Programmierkenntnisse in einer spezifischen Programmiersprache erforderlich sind, unabhängig davon, in welcher Programmiersprache der Quellcode oder Zwischencode erstellt wird. Es genügt, mit der Bedienung von graphischen Benutzeroberflächen mittels Eingabegeräten wie Maus, Trackball, Tastatur, Touch-Screen und dergleichen vertraut zu sein, je nachdem über welches Eingabegerät die graphische Benutzeroberfläche bedient wird. Dadurch, dass der Programmablauf durch ein einfaches Ziehen von graphischen Linien definiert wird, ist das Verfahren besonders einfach und intuitiv.
Der Quellcode, der einem Funktionselement entspricht, kann direkt in den Ablauf-Quellcode eingebunden werden, wird aber vorzugsweise dadurch bereitgestellt, dass ein Funktionsaufruf auf den Quellcode des Funktionselements in den Ablauf-Quellcode eingebunden wird. Der Funktionsaufruf ist vorzugsweise auf einen Eintrag des zugehörigen Funktionselements in einer Library-Quellcode-Datei gerichtet.
Funktionselemente und Verbindungen können zudem durch Parameter konfiguriert werden.
Betreffend den compilierten Zwischencode für die Funktionselemente werden gemäß einer ersten Ausführungsform des erfindungsgemäßen Verfahrens die Zwischencodes der Funktionselemente mit dem Ablauf-Zwischencode mitgeführt, d.h. in die Ablauf-Zwischencode-Datei compiliert.
Dabei ist vorzugsweise durch die compilierten Funktionselemente ein eigener Library-Abschnitt gebildet, der aber innerhalb der Ablauf-Zwischencode-Datei liegt. Diese Ausführungsform hat den Vorteil, dass nur die Zwischencodes derjenigen Funktionselemente mitgeführt werden müssen, die unbedingt erforderlich sind. Dadurch ist der Speicherbedarf des erstellten Programmcodes gering.
In dem Fall, dass vorgesehen ist, dass eine größere Anzahl von Programmcodes nach dem erfindungsgemäßen Verfahren erstellt und in dem selben mobilen Gerät oder in der selben Chipkarte abgespeichert wird, ist die folgende zweite Ausführungsform des erfindungsgemäßen Verfahrens bevorzugt. Gemäß der zweiten Ausführungsform werden für die in einem Programmcode verwendeten Funktionselemente im Zwischencode nur Funktionsaufrufe auf die Funktionselemente mitgeführt. Die Zwischencodes der Funktionselemente selbst werden in einer entsprechenden, von der Ablauf-Zwischencode-Datei gesonderten, Library-Zwischencode-Datei bereit gehalten und werden während der Durchführung des eigentlichen Verfahrens nicht verwendet. Die Library-Zwischencode-Datei braucht insbesondere während der Erstellung des Programmcodes nicht zur Verfügung zu stehen. Es genügt, wenn die Library bei der nachfolgenden Ausführung des Programmcodes zur Verfügung steht.
Die Library-Zwischencode-Datei braucht nur ein einziges Mal auf dem mobilen Gerät oder der Chipkarte, auf der der Programmcode später laufen soll, eingerichtet zu werden. Die bei der zweiten Ausführungsform verwendete Library-Zwischencode-Datei enthält vorzugsweise weitere Funktionselemente, die für die Durchführung des Verfahrens zur Verfügung stehen, die aber in dem aktuell erstellten Programmcode nicht verwendet werden. Weiter vorzugsweise enthält die Library-Zwischencode-Datei einen von der Durchführung des Verfahrens unabhängigen Bestand an Zwischencodes.
Gemäß einer dritten Ausführungsform der Erfindung ist vorgesehen, dass innerhalb des Verfahrens gewählt werden kann, ob der Zwischencode für die Funktionselemente gemäß der ersten Ausführungsform direkt in den Ablauf-Zwischencode eingebunden wird, oder ob, gemäß der zweiten Ausführungsform, im Ablauf-Zwischencode nur ein Funktionsaufruf eingebunden werden soll, wohingegen die Zwischencodes der Funktionselemente in der Library verbleiben.
Das Verfahren kann auf einem Personal Computer oder Server oder auf einem mobilen Endgerät durchgeführt werden oder auf einem beliebigen Datenträger mit zumindest einem Speicher und einem Mikroprozessor (Computersystem im weitesten Sinn).
Zum Compilieren von Quellcode in dem Compilierungs-Schritt kann ein Compiler verwendet werden, der nur dem Verfahren zur Verfügung steht oder ein Compiler, der auch weiteren Programmen zur Verfügung steht.
Der Quellcode oder der Zwischencode, gegebenenfalls einschließlich der Parameter, lässt sich vorzugsweise in einer Projekt-Datei auf dem Computer oder sonstigen oben genannten Gerät bzw. Datenträger abspeichern. Dadurch kann die Erstellung von Programmcode unterbrochen und später, unter Verwendung der Projekt-Datei, wieder fortgesetzt werden.
Vorzugsweise sind in der Projekt-Datei zusätzlich graphische Entwurfsdaten abgespeichert werden, die eine Rekonstruktion des in dem Entwurfsschritt a) erstellten graphischen Entwurfs durch Aufruf der Projekt-Datei erlauben.
Vorzugsweise ist die Projekt-Datei im XML-Format abspeicherbar, da sich dieses Dateiformat besonders gut für den Datenaustausch eignet.
Die Projekt-Datei kann auch auf ein anderes Gerät, d.h. Computer, Chipkarte, mobiles Endgerät oder sonstige Speicher-Einrichtung oder Speicher-Prozessor-Einrichtung, gespeichert werden als das Gerät, auf dem sie erstellt worden ist.
Gemäß einer bevorzugten Ausführungsform ist mindestens eines der Funktionselemente ein proaktiver Befehl, insbesondere für Mobilfunkanwendungen. Durch proaktive Befehle werden die Funktionen (z.B. für Displayausgabe etc.) von mobilen Endgeräten wie beispielsweise Mobiltelefonen oder Personal Digital Assistants (PDAs) angesteuert. Beispielsweise ist der proaktive Befehl ein proaktiver SIM-Befehl gemäß der GSM-Spezifikation 3GPP TS 11.14.
Gemäß einer Ausführungsform des Verfahrens wird das Verfahren zumindest teilweise außerhalb der Chipkarte und des mobilen Endgeräts durchgeführt, für die/das der Programmcode erstellt wird. In diesem Fall wird weiter in einem Ladeschritt der Quellcode oder der Zwischencode auf die Chipkarte und/oder auf das mobile Endgerät geladen.
Falls gemäß der oben beschriebenen zweiten oder dritten Ausführungsform im Zwischencode bezüglich der Funktionselemente nur Funktionsaufrufe enthalten sind, wird zusätzlich eine Library-Zwischencode-Datei auf die Chipkarte oder das mobile Endgerät geladen. Falls die Chipkarte oder das mobile Endgerät über einen geeigneten Compiler verfügt, kann die Library auch in Quellcodeform, als Library-Quellcode-Datei geladen werden und nachfolgend auf der Chipkarte bzw. dem Endgerät compiliert werden. In diesem Fall kann auch der Ablauf-Code, d.h. der erstellte Programmcode, in Quellcodeform auf die Chipkarte bzw. das Endgerät geladen werden und erst dort compiliert werden. Die Library wird vorzugsweise nur einmalig unabhängig von den Programmcodes oder zusammen mit einem Programmcode geladen. Beispielsweise kann die Library mitgeladen werden, wenn erstmalig ein Programmcode auf die Karte bzw. das Endgerät geladen wird. Optional kann bei jedem Laden eines Programmcodes überprüft werden, ob schon eine Library vorhanden ist und, falls noch keine Library vorhanden ist, die Library mitgeladen werden.
Das Laden kann kontaktbehaftet über eine Lesegerät oder kontaktlos durchgeführt werden oder teils kontaktbehaftet, teils kontaktlos. Besonders bevorzugt wird der Programmcode auf einem Computer erstellt, von dort auf einen Server geladen, und auf dem Server zur Verfügung gestellt, beispielsweise über das Internet. Vom Internet-Browser aus kann veranlasst werden, dass der Programmcode per SMS an ein vorbestimmtes Mobiltelefon gesandt wird. Alternativ kann durch ein Mobiltelefon angefordert werden, dass der Programmcode per SMS an das Mobiltelefon gesandt wird. Im Mobiltelefon bzw. sonstigen mobilen Endgerät wird der Programmcode auf die Chipkarte und/oder das Endgerät geladen und von einem dort implementierten Interpreter zu einem ausführbaren Code interpretiert. Durch den interpretierbaren Code werden die Funktionalitäten des Endgeräts, wie Display, Lautsprecher etc., angesteuert.
Vorzugsweise wird durch den auf das mobile Endgerät (Chipkarte und/oder Endgerät direkt) geladenen Programmcode oder dort erstellten Programmcode ein Menüeintrag im Menü des Endgeräts erstellt, der sich in die ursprünglich vorhandenen Menüeinträge einfügt, und der im gleichen Erscheinungsbild gestaltet ist.
Vorzugsweise ist bei während der Durchführung des Verfahrens ein Lade-Parameter festlegbar wird, durch den vorbestimmt wird, in welchen Bereich der Chipkarte und/oder des mobilen Endgeräts der Quellcode oder der Zwischencode in dem Ladeschritt geladen wird.
Die Chipkarte weist vorzugsweise die Speicherbereiche RAM, EEPROM, Flash-Speicher und ROM auf, und durch den wird Lade-Parameter vorbestimmt wird, in welchen Speicherbereich der Quellcode oder der Zwischencode in dem Ladeschritt geladen wird. So kann z.B. die Library, wenn sie separat geladen wird, in den Flash-Speicher gespeichert werden und der Programmcode, wenn er ohne Library geladen wird, in den EEPROM geladen werden.
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
1 ein Beispiel für eine erfindungsgemäße graphische Benutzeroberfläche für die Verwendung durch das erfindungsgemäße Verfahren bzw. Software-Tool;
2 ein Beispiel für eine erfindungsgemäße Arbeitsfläche, die auf einer graphischen Benutzeroberfläche dargestellt ist, und auf der eine Mehrzahl von Icons und die Icons untereinander verbindenden Verbindungen graphisch dargestellt sind;
3 eine schematische Darstellung einer Mehrzahl von mit dem erfindungsgemäßen Software-Tool erstellten Programmcodes, die auf eine gemeinsame Library zugreifen können;
4 eine schematische Darstellung des erfindungsgemäßen Verfahrens, mit den Schritten a), b) und c), am Beispiel von Java als Programmiersprache;
5 eine schematische Detaildarstellung des in dem Build-Schritt b) aus 4 erzeugten Ablauf-Quellcodes, gemäß einer bevorzugten Ausführungsform der Erfindung;
6 eine schematische Darstellung einer erfindungsgemäßen Library-Quellcode-Datei;
7 eine schematische Darstellung eines Ablauf-Zwischencodes gemäß einer ersten Ausführungsform der Erfindung;
8 eine schematische Darstellung eines Ablauf-Zwischencodes gemäß einer zweiten Ausführungsform der Erfindung, gemäß einer ersten Variante, mit einer spezifischen Library;
9 eine schematische Darstellung eines Ablauf-Zwischencodes gemäß der zweiten Ausführungsform der Erfindung, gemäß einer zweiten Variante, mit einer verfahrensunabhängigen Library;
10 eine schematische Darstellung mehrerer Ablauf-Zwischencodes gemäß der zweiten Ausführungsform der Erfindung, gemäß der zweiten Variante, mit einer verfahrensunabhängigen gemeinsamen Library;
1 zeigt ein Beispiel für eine erfindungsgemäße graphische Benutzeroberfläche für die Verwendung durch das erfindungsgemäße Verfahren bzw. Software-Tool. Die graphische Benutzeroberfläche ist in einer für Computer üblichen Art in Fenster aufgeteilt. In einer zweizeiligen Kopfleiste 101 sind Befehle angezeigt, mit denen sich Funktionen des Software-Tools ausführen lassen. Beispielsweise lässt sich durch ein Aktivieren von "File" in der oberen Zeile ein Pop-up-Menü öffnen (nicht gezeigt), in dem ein Untermenü "New" das Eröffnen eines neuen Projektes bzw. einer neuen Arbeitsfläche ermöglicht und ein Untermenü "Open" das Öffnen einer abgespeicherten Projekt-Datei ermöglicht. In der unteren Zeile der Kopfleiste 101 (Toolleiste) sind Schaltsymbole enthalten, mit denen sich ebenfalls Funktionen aktivieren lassen, z.B. "Datei öffnen" durch Aktivieren des Symbols "geöffneter Hängeordner". In einem Projektfenster 102 ist eine baumartige Menüstruktur anzeigbar, die dem Aufbau der gerade geöffneten Projekt-Datei entspricht und die auch in dieser Form mit den jeweiligen Texten auf dem mobilen Endgerät angezeigt wird. Die in 1 dargestellte Projekt-Datei mit dem Namen Mobile_Banking enthält sechs unterschiedliche Programmcodes, nämlich Kontostand anzeigen, Überweisung, Verbindungen, Konten, Service und Kontakt. Der Programmcode Kontostand anzeigen ist hierbei in einer Projekt-Unterdatei mit dem Namen Kontostand enthalten, die der Projekt-Datei Mobile_Banking hierarchisch untergeordnet ist. Jeder der sechs Programmcodes ist nach dem erfindungsgemäßen Verfahren, mit dem erfindungsgemäßen Software-Tool erstellt worden. Die Projekt-Datei wird im XML-Format gespeichert. Entsprechend der hierarchischen Struktur der Programmcodes enthält die Menüstruktur im Projektfenster 102 einen übergeordneten Menüeintrag Mobile_Banking, sechs untergeordnete Untermenüeinträge der zweiten Ebene, nämlich Kontostand, Überweisung, Verbindungen, Konten, Service und Kontakt, und einen Untermenüeintrag der dritten Ebene, nämlich Kontostand anzeigen. Durch Aktivieren eines der Untermenüeinträge wird im Arbeitsfenster 103 die zugehörige Arbeitsfläche mit den zugehörigen Icons und Verbindungen dargestellt. In 1 ist im Projektfenster 102 der Untermenüeintrag Kontostand anzeigen aktiviert und folglich auf der Arbeitsfläche 103 der graphische Entwurf zum Programmcode Kontostand anzeigen angezeigt.
Zwischen dem Projektfenster 102 und dem Arbeitsfenster 103 ist eine Befehlsleiste 104 angeordnet, die eine Mehrzahl von zu verwendenden Icons für die Arbeitsfläche (Befehlssymbole) enthält. Durch die Icons sind proaktive SIM-Befehle gemäß der GSM-Spezifikation 3GPP TS 11.14 dargestellt, z.B. an oberster Stelle DISPLAY TEXT, an vierter Stelle PLAY TONE etc., und an den beiden untersten Positionen ein START Symbol und ein STOP Symbol, durch die Anfang bzw. Ende eines jeweiligen Programmcodes markiert werden. Die Icons (Befehlssymbole) können per "Drag and Drop" auf die Arbeitsfläche gezogen werden können, d.h. indem eine Laufmarke (Cursor) auf dem Icon aktiviert wird, die Laufmarke mitsamt dem Icon in die Arbeitsfläche 103 gezogen wird, und die Laufmarke auf der Arbeitsfläche wieder deaktiviert wird, woraufhin das Icon auf der Arbeitsfläche 103 abgelegt wird.
2 zeigt die Arbeitsfläche aus 1 gesondert dargestellt. Auf der Arbeitsfläche sind eine Mehrzahl von Icons und die Icons untereinander verbindenden Verbindungen graphisch dargestellt. Die Icons sind auf der Arbeitsfläche angeordnet worden, indem sie aus der Befehlsleiste 104 oder aus der Kopfleiste 101 auf die Arbeitsfläche gezogen worden sind (vgl.
oben). Die Icons sind durch Verbindungslinien miteinander verbunden. Jede Verbindungslinie wird dadurch gezogen, dass ein Cursor (Laufmarke) über einem ersten Icon aktiviert wird, zum zweiten Icon gezogen wird und dort wieder deaktiviert wird. Eine auf diese Weise vom ersten Icon zum zweiten Icon gezogene Verbindungslinie bedeutet auf Programmebene, dass zuerst ein dem ersten Icon entsprechender erster Befehl und anschließend ein dem zweiten Icon entsprechender zweiter Befehl ausgeführt wird. Bei dem Programmcode aus 2 wird somit nach dem Start (START) zuerst ein Text auf dem Display angezeigt (DISPLAY TEXT), danach eine Eingabe entgegengenommen (GET INPUT), anschließend eine Short Message (SMS) versandt (SEND SMS), und schließlich wieder ein Text angezeigt (DISPLAY TEXT), wonach der Programmcode zu Ende ist (STOP).
In 1 ist zu sehen, dass auf der Arbeitsfläche 103 gerade das Icon (Befehlssymbol) GET INPUT aktiviert ist. Entsprechend wird in einer Parameterfläche 105 eine Mehrzahl von Parameterfeldern angezeigt, in die Parameter zur Konfiguration des Funktionselements zu dem angezeigten Icon, hier also des Funktionselements GET INPUT, eingebbar sind. Beispielsweise lässt sich in dem Feld zu "Question" auf die Aufforderung "Bitte PIN eingeben" die PIN eingeben. In den beiden Parameterfeldern darunter lassen sich die minimale und maximale Antwortgröße (Responsegröße) eingeben. Aktuell sind 0 bzw. 255 eingegeben.
Die Verbindungen zwischen den Icons können ebenfalls durch Parameter konfiguriert werden. Dabei wird beispielsweise angegeben, welcher Antwortcode des mobilen Endgerätes auf den ersten Befehl sich auf den weiteren Ablauf auswirkt, bzw. in welchem Pfad der Ablauf fortgesetzt wird. Ein weiterer Parameter kann das Format sein, in dem der erste Befehl an den zweiten Befehl Daten weitergibt. Die Funktionselemente können ebenfalls durch Parameter konfiguriert werden. Um das jeweilige Funktionselement bzw. die jeweiligen Verbindung durch Parameter zu konfigurieren, wird beispielsweise in dem Entwurfsschritt a) in oder neben der graphischen Arbeitsfläche oder anderweitig auf der graphischen Benutzeroberfläche eine Eingabemaske dargestellt, in die die Parameter eingegeben werden. Im anschließenden Build-Schritt werden die eingegebenen Parameter in den Quellcode eingebunden.
Ein proaktiver Befehl, für den auf der Arbeitsfläche ein Icon dargestellt ist, ist der Befehl DISPLAY TEXT gemäß der GSM-Spezifikation 3GPP TS 11.14. Der Befehl DISPLAY TEXT hat, ausgeführt auf einer SIM-Karte eines Mobiltelefons, die Wirkung, dass auf dem Display des Mobiltelefons ein spezifischer Text angezeigt wird. Dazu ist der Befehl DISPLAY TEXT durch den Parameter des spezifischen Texts, der angezeigt werden soll, konfiguriert. Durch PLAY TONE, abgespielt auf der SIM-Karte eines kombinierten PDA-Mobiltelefons, wird durch den Lautsprecher des PDA-Mobiltelefons ein Ton ausgegeben. Durch geeignete Parameter können beispielsweise Tonhöhe und Tondauer angegeben sein. Weitere proaktive Befehle lassen sich der GSM-Spezifikation 3GPP TS 11.14 entnehmen.
Gemäß einer Variante können Verbindungslinien, die an ein und demselben Icon beginnen und enden, die also eine Schleife bilden, dafür benutzt werden, um beispielsweise eine falsche Eingabe des Benutzers am mobilen Endgeräts zu wiederholen und um falsche Ausführungen zu korrigieren (hier nicht dargestellt).
4 zeigt eine schematische Darstellung des erfindungsgemäßen Verfahrens, mit den Schritten a), b) und c). Als Programmiersprache wird exemplarisch Java verwendet. Jedoch kann das Verfahren auch mit einer anderen, vorzugsweise objektorientierten, Programmiersprache durchgeführt werden. Das Verfahren wird vorzugsweise mit dem in 1 und 2 dargestellten Software-Tool durchgeführt.
In dem Entwurfsschritt a) werden nacheinander drei Icons 402 auf die Arbeitsfläche gezogen. Durch jedes Icon 402 ist ein proaktiver Befehl dargestellt. Im Fall aus 4 sind dies die proaktiven Befehle DISPLAY TEXT, PLAY TONE und SEND SHORT MESSAGE (vgl. auch 6). Die Icons 402 werden durch Verbindungslinien 401 miteinander verbunden. Dadurch wird festgelegt, dass später, beim ablaufen Lassen des Programmcodes auf dem Endgerät und/oder der zugehörigen SIM-Karte zuerst der Befehl DISPLAY TEXT, dann PLAY TONE und anschließend SEND SHORT MESSAGE durchgeführt werden soll.
In dem Build-Schritt b), der beispielsweise dadurch gestartet wird, dass in der Kopfzeile 101 aus 1 der Befehl "Build" aktiviert wird, wird aus den Verbindungslinien 401 auf der Arbeitsfläche ein Ablauf-Quellcode main.java erstellt, wie in 4 durch die Pfeile angedeutet ist. Der genauere Aufbau der Datei main.java wird weiter unten erklärt (vgl. 5).
Im Compilierungs-Schritt c) wird mittels eines Compilers (im weiteren Sinn) der Ablauf-Quellcode main.java zur Ablauf-Zwischencode-Datei main.cap compiliert (vgl. auch 7 bis 10). Die Datei main.cap ist vom CAP-Format, d.h. vom Card Application Format, und ist somit dazu geeignet, von einem Java Card Interpreter wie einer Java Card Virtual Machine interpretiert zu werden. Die Datei main.cap wird üblicherweise genauer dadurch erstellt, dass zunächst durch einen Compiler im engeren Sinn eine Klassen-Datei main.class erstellt wird und anschließend aus der Klassen-Datei main.class mittels eines Converters die Ablauf-Zwischencode-Datei main.cap erstellt wird. Der Zwischencode ist somit bei dem Beispiel aus 4 ein konvertierter Java Bytecode vom CAP-Format, wobei unter Java Bytecode ein Code vom CLASS-Format verstanden wird.
5 zeigt eine schematische Detaildarstellung des in dem Build-Schritt b) aus 4 erzeugten Ablauf-Quellcodes main.java, gemäß einer bevorzugten Ausführungsform der Erfindung. Der Ablauf-Quellcode main.java enthält Quellcodes 1 von Verbindungslinien und Funktionsaufrufe 2 auf Funktionselemente, die Icons entsprechen. Mit den Funktionsaufrufen 2 sind vorzugsweise auch Parameter zur Konfiguration der Funktionselemente im Ablauf-Quellcode main.java enthalten. Die Funktionsaufrufe 2 sind auf Einträge der Quellcodes der Funktionselemente in einer Library-Quellcode-Datei library.java gerichtet, wie sie in 6 dargestellt ist. Die Library-Quellcode-Datei library.java aus 6 enthält als Einträge die Quellcodes aller Funktionselemente, die dem Verfahren bzw. Software-Tool zur Verfügung stehen.
7 zeigt eine schematische Darstellung einer Ablauf-Zwischencode-Datei main.cap gemäß einer ersten Ausführungsform der Erfindung. In der Ablauf-Zwischencode-Datei main.cap sind die Zwischencodes sowohl zu den Verbindungen 1, 401 als auch zu den Funktionselementen 2, 402 abgelegt. Intern ist die Ablauf-Zwischencode-Datei main.cap in einen Ablauf-Abschnitt 701 und einen Library-Abschnitt 702 aufgeteilt. Der Ablauf-Abschnitt 701 enthält die compilierten Ablauf-Quellcodes 1 und Quellcode-Funktionsaufrufe 2. Der Library-Abschnitt 702 enthält die compilierten Quellcodes 2 der Funktionselemente, allerdings nur zu den Funktionselementen, deren Icons 402 in dem Entwurf enthalten sind. Für Icons 402, die in dem Entwurf mehrmals auftreten, braucht der zugehörige Zwischencode in dem Library-Abschnitt 702 nur ein mal vorgesehen zu sein.
8 zeigt eine schematische Darstellung eines Ablauf-Zwischencodes gemäß einer zweiten Ausführungsform der Erfindung, gemäß einer ersten Variante, mit einer spezifischen Library. Im Vergleich zu der Ablauf-Zwischencode-Datei main.cap aus 7 enthält die Ablauf-Zwischencode-Datei main.cap aus 8 nur einen Ablauf-Abschnitt mit compilierten Ablauf-Quellcodes 1 und Quellcode-Funktionsaufrufen 2. Die Zwischencodes der Funktionselemente, für die im Entwurf ein Icon 402 enthalten ist, sind in einer gesonderten Library-Zwischencode-Datei library.cap abgelegt. Die Library-Zwischencode-Datei library.cap lässt sich somit gesondert von der Ablauf-Zwischencode-Datei main.cap speichern, kopieren oder laden. Insbesondere kann beispielsweise, wenn Programmcode von einem Computer, auf dem der Programmcode erstellt worden ist, auf eine Chipkarte geladen wird, für die die Library-Zwischencode-Datei library.cap ein anderer Speicherort gewählt werden als für die Ablauf-Zwischencode-Datei main.cap. Beispielsweise kann library.cap in den Flash-Speicher und main.cap in den EEPROM der Chipkarte geschrieben werden.
9 zeigt eine schematische Darstellung eines Ablauf-Zwischencodes gemäß der zweiten Ausführungsform der Erfindung, gemäß einer zweiten Variante, mit einer verfahrensunabhängigen Library. Im Vergleich zu der in 8 gezeigten Variante sind in der Library-Zwischencode-Datei library.cap die Zwischencodes aller dem Verfahren bzw. Software-Tool zur Verfügung stehenden Funktionselemente enthalten, auch die derjenigen Funktionselemente, die gerade nicht verwendet werden. Dadurch ist die Library-Zwischencode-Datei library.cap unabhängig vom erfindungsgemäß erstellten Programmcode universell einsetzbar. Die Library-Zwischencode-Datei library.cap kann somit auch als gemeinsame Library für mehrere nach dem Verfahren erzeugte Programmcodes verwendet werden, wie in 10 dargestellt ist.
10 zeigt eine schematische Darstellung mehrerer Ablauf-Zwischencodes main1.cap, main2.cap, main3.cap gemäß der zweiten Ausführungsform der Erfindung, gemäß der zweiten Variante, mit einer verfahrensunabhängigen gemeinsamen Library library.cap. Diese Variante ist auch in 3 verdeutlicht. Mehrere Ablauf-Zwischencodes greifen auf ein und die selbe gesonderte Library-Zwischencode-Datei library.cap zu. Dazu enthält die Library-Zwischencode-Datei library.cap einen verfahrensunabhängigen Bestand an Zwischencodes von Funktionselementen. Vorzugsweise kann der Bestand erweitert und verringert werden, was vorzugsweise unabhängig vom Erstellen der Programmcodes main.cap geschieht. Da die gemeinsame, universale Library-Zwischencode-Datei library.cap nur einmal geladen werden muss, kann sie beispielsweise in einen Speicher geschrieben werden, der zwar schwierig wiederzubeschreiben ist, dafür aber andere Vorteile hat, indem er z.B. billig oder schnell oder dauerhaft ist. Die Programmcodes main.cap bzw. maini.cap, i=1,2,3,... werden vorzugsweise in einen vergleichsweise einfach wiederbeschreibbaren Speicher geschrieben, z.B. in den EEPROM oder in den Flash-Speicher.
Das Verfahren wird gemäß einer Ausführungsform direkt auf dem mobilen Endgerät ausgeführt, auf dem der Programmcode später laufen soll. Dazu wird beispielsweise insbesondere das Display des Endgeräts zur Darstellung der graphischen Benutzeroberfläche verwendet. Mit den qualitativ hochwertigen Displays der neueren Generationen von Mobiltelefonen und PDAs und kombinierten Endgeräten ist dies besonders gut möglich. Zur Bedienung des Displays wird dabei die Infrastruktur benutzt, die das Endgerät zur Verfügung stellt, d.h. Tastatur, Touch-Screen, ggf. mit Eingabestift, Mobiltelefontasten etc..
Gemäß einer weiteren Ausführungsform wird das Verfahren auf einem Computer durchgeführt und der Zwischencode main.cap, ggf. zusammen mit der Library library.cap, auf das mobile Endgerät geladen, vorzugsweise auf eine dort eingebaute Chipkarte, alternativ auch auf das Endgerät selbst oder teils auf die Chipkarte, teils auf das Endgerät. Der auf der Chipkarte oder in dem Endgerät vorgesehene Interpreter, z.B. eine Java Card Virtual Machine, interpretiert den Programmcode schließlich zu einem ausführbaren Code, durch den die Funktionalitäten des mobilen Endgeräts ansteuerbar sind. Die Chipkarte kann dabei insbesondere eine Mobiltelefonkarte der SIM-Generation sein und ist in diesem Fall vorzugsweise eine Java Card, die der GSM-Spezifikation 3GPP TS 11.14 genügt.
Die proaktiven Befehle müssen nicht unbedingt SIM-Befehle sein, sondern können auch USIM-Befehle oder Befehle gemäß einem anderen Mobilfunkstandard oder sonstigen Kommunikationsstandard sein.
Der Programmcode, der nach dem Compilierungs-Schritt c) bereitgestellt wird, um ausgeführt zu werden oder um auf die Chipkarte oder/und auf das mobile Endgerät geladen zu werden und anschließend ausgeführt zu werden, ist vorzugsweise ein Java Applet.
Das Laden des Applet wird vorzugsweise dadurch durchgeführt, dass das Applet auf einem Server abgelegt wird, der über das Internet zugänglich ist. Ein Internet-Nutzer kann, beispielsweise gegen Bezahlung, aus dem Internet heraus veranlassen, dass ihm das Applet per SMS auf sein mobiles Endgerät (z.B. Handy) gesandt wird. Alternativ kann er das Herunterladen des Applets auch direkt von seinem mobilen Endgerät aus initiieren.
Die ggf. erforderliche Library kann auf dem gleichen Weg wie das Applet heruntergeladen werden. Falls als Library eine gemeinsame, universale Library verwendet wird, braucht diese nur ein einziges mal heruntergeladen werden, auch wenn nacheinander mehrere Applets geladen werden. Dadurch kann der Konsument, der die Applets bezieht, teure Verbindungskosten für die mobile (kontaktlose) Verbindung zwischen dem Server und seinem mobilen Endgerät sparen, was das Herunterladen der Applets für Konsumenten attraktiver macht.
Das Applet enthält ggf. die Information, auf welchen Speicherbereich der Chipkarte des Endgeräts es geladen wird, wobei die Information bereits bei der Erstellung des Applet vorgegeben wurde.

Claims

Verfahren zum Erstellen von Programmcode, insbesondere für eine Chipkarte, zum Ansteuern eines mobilen Endgeräts, wobei a) in einem Entwurfsschritt auf einer graphischen Benutzeroberfläche eines Computersystems ein graphischer Entwurf erstellt wird, indem ein oder mehrere graphische Icons auf einer auf der graphischen Benutzeroberfläche dargestellten graphischen Arbeitsfläche angeordnet werden und, falls mehr als ein Icon angeordnet worden ist, die Icons durch graphische Linien miteinander verbunden werden, so dass eine Struktur von durch Linien miteinander verbundenen Icons gebildet wird, wobei durch jedes Icon ein zugehöriges Funktionselement schematisch graphisch dargestellt ist und durch jede graphische Linie eine Verbindung auf Programmebene zwischen den durch die Linie verbundenen Funktionselementen graphisch dargestellt ist, b) in einem Build-Schritt aus dem graphischen Entwurf ein Quellcode (main.java, library.java) des Programmcodes erstellt wird, indem zu jedem in der Struktur enthaltenen graphischen Icon der Quellcode des zugehörigen Funktionselements bereitgestellt wird und zu jeder in der Struktur enthaltenen graphischen Linie auf der Arbeitsfläche der Quellcode (1) der Verbindung bereitgestellt wird, wobei mit den bereitgestellten Quellcodes (1) der Verbindungen ein Ablauf-Quellcode (main.java) gebildet wird, durch den der Ablauf des Programmcodes festgelegt ist, c) in einem Compilierungs-Schritt ein Zwischencode (main.class, library.class, main.cap, library.cap) erstellt wird, der durch einen auf der Chipkarte und/oder dem mobilen Endgerät implementierten Interpreter in für die Chipkarte und/oder das mobilen Endgerät lesbaren ausführbaren Code interpretierbar ist, wobei der Ablauf-Quellcode in eine Ablauf-Zwischencode-Datei (main.class, main.cap) compiliert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mindestens ein Funktionselement und/oder mindestens eine Verbindung durch Parameter konfiguriert wird.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass beim Bereitstellen des Quellcodes des jeweiligen Funktionselements ein Funktionsaufruf (2) auf den Quellcode des Funktionselements in den Ablauf-Quellcode (main.java) eingebunden wird, wobei der Funktionsaufruf (2) vorzugsweise auf einen Eintrag des Funktionselements in einer Library-Quellcode-Datei (library.java) gerichtet ist.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in dem Compilierungs-Schritt c), beim Erstellen des Zwischencodes, die Zwischencodes der Funktionselemente, für die in dem Entwurfsschritt a) ein Icon in die Struktur eingefügt worden ist, mit in die Ablauf-Zwischencode-Datei (main.class, main.cap) eingebunden werden, insbesondere durch Compilierung der zugehörigen Quellcodes.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass in dem Compilierungs-Schritt c), beim Erstellen des Zwischencodes, für die Funktionselemente, für die in dem Entwurfsschritt a) ein Icon in die Struktur eingefügt worden ist, jeweils ein Funktionsaufruf auf den Zwischencode des Funktionselements in die Ablauf-Zwischencode-Datei eingebunden wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Zwischencodes der Funktionselemente in einer von der Ablauf-Zwischencode-Datei gesonderten Library-Zwischencode-Datei (library.class, library.cap) bereitgestellt werden.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass die Library-Zwischencode-Datei (library.class, library.cap) einen Bestand an Zwischencodes von Funktionselementen enthält, der von der Durchführung des Verfahrens unabhängig ist.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass während der Durchführung des Verfahrens ausgewählt wird, auf welche Weise für die Funktionselemente, für die in dem Entwurfsschritt a) ein Icon in die Struktur eingefügt worden ist, der zugehörige Zwischencode erstellt wird, insbesondere ob – gemäß Anspruch 4 die Zwischencodes der Funktionselemente mit in die Ablauf-Zwischencode-Datei (main.class, main.cap) eingebunden werden oder – gemäß einem der Ansprüche 5 bis 7 jeweils ein Funktionsaufruf auf den Zwischencode des Funktionselements in die Ablauf-Zwischencode-Datei eingebunden wird.
Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass alle Informationen über das jeweilige Projekt einschließlich verwendeter Menüs, Arbeitsflächen mit Icons und Parameter sowie Projektoptionen in einer Projekt-Datei abgespeichert werden, insbesondere im XML-Format.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass in der Projekt-Datei zusätzlich graphische Entwurfsdaten abgespeichert werden, die eine Rekonstruktion des in dem Entwurfsschritt a) erstellten graphischen Entwurfs durch Aufruf der Projekt-Datei erlauben.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass weiter d) in einem Interpretations-Schritt durch den in der Chipkarte und/ oder in dein mobilen Endgerät implementierten Interpreter der Zwischencode in für die Chipkarte und/oder das mobile Endgerät lesbaren ausführbaren Code übersetzt wird.
Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass mindestens eines der Funktionselemente ein proaktiver Befehl, insbesondere für Mobilfunkanwendungen, ist.
Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass die Schritte a) bis c) teilweise oder vollständig auf der Chipkarte und/oder auf dem mobilen Endgerät zur mobilen Kommunikation ausgeführt werden.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die graphische Benutzeroberfläche auf einem Display des mobilen Endgerätes angezeigt wird und/oder dass der Build-Schritt b) und/oder der Compilierungs-Schritt c) in einem integrierten Schaltkreis durchgeführt wird, der in der Chipkarte oder in dem mobilen Endgerät oder teils in der Chipkarte und teils in dem mobilen Endgerät ausgebildet ist.
Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass das Verfahren zumindest teilweise außerhalb der Chipkarte und des mobilen Endgeräts durchgeführt wird und dass weiter in einem Ladeschritt der Quellcode oder der Zwischencode auf die Chipkarte und/oder auf das mobile Endgerät geladen wird.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass insbesondere die Library-Quellcode-Datei (library.java) gemäß Anspruch 3 oder die Library-Zwischencode-Datei (library.class, library.cap) gemäß einem der Ansprüche 6 bis 8 auf die Chipkarte oder auf das mobile Endgerät oder teils auf die Chipkarte und teils auf das mobile Endgerät geladen wird.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die Library-Quellcode-Datei (library.java) oder die Library-Zwischencode-Datei (library.class, library.cap) nur dann geladen wird, falls am Zielort der Ladens auf der Chipkarte bzw. dem mobilen Endgerät noch keine entsprechende Datei vorhanden ist.
Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass das Laden in dem Ladeschritt über ein kontaktbehaftet arbeitendes Lesegerät durchgeführt wird.
Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass das Laden in dem Ladeschritt zumindest teilweise kontaktlos durchgeführt wird.
Verfahren nach einem der Ansprüche 15 bis 19, dadurch gekennzeichnet, dass das Laden in dem Ladeschritt zumindest teilweise über einen Server durchgeführt wird.
Verfahren nach Anspruch 20, dadurch gekennzeichnet, dass das Laden dadurch durchgeführt wird, dass der Quellcode oder der Zwischencode auf dem Server bereitgestellt wird und anschließend kontaktlos an die Chipkarte oder das mobile Endgerät übermittelt wird.
Verfahren nach Anspruch 21, dadurch gekennzeichnet, dass das kontaktlose Übermitteln an die Chipkarte oder an das mobile Endgerät entweder durch die Chipkarte oder das mobile Endgerät oder durch den Server veranlasst wird.
Verfahren nach einem der Ansprüche 15 bis 22, dadurch gekennzeichnet, dass während der Durchführung des Verfahrens ein Lade-Parameter festgelegt wird, durch den vorbestimmt wird, in welchen Bereich der Chipkarte und/oder des mobilen Endgeräts der Quellcode oder der Zwischencode in dem Ladeschritt geladen wird.
Verfahren nach Anspruch 23, dadurch gekennzeichnet, dass die Chipkarte eine Mehrzahl von unterschiedlichen Speicherbereichen aufweist, die vorzugsweise einen oder mehrere der Speicherbereiche RAM, EEPROM, Flash-Speicher und ROM aufweisen, und dass durch den Lade-Parameter vorbestimmt wird, in welchen Speicherbereich der Quellcode oder der Zwischencode in dem Ladeschritt geladen wird.
Verfahren nach Anspruch 24, dadurch gekennzeichnet, dass die Chipkarte einen EEPROM und/oder einen Flash-Speicher aufweist und beim Laden in dem Ladeschritt zumindest der Ablauf-Zwischencode in den EEPROM oder Flash-Speicher geladen wird.
Software-Tool zum Durchführen eines Verfahrens zum Erstellen von Programmcode nach einem der Ansprüche 1 bis 25, mit: a) einer Graphik-Steuereinrichtung zum Ansteuern der graphischen Benutzeroberfläche, so dass ein graphischer Entwurf des Programmcodes erstellbar ist, indem ein oder mehrere graphische Icons auf einer auf der graphischen Benutzeroberfläche dargestellten graphischen Arbeitsfläche angeordnet werden und, falls mehr als ein Icon angeordnet worden ist, die Icons durch graphische Linien miteinander verbunden werden, so dass eine Struktur von durch Linien miteinander verbundenen Icons gebildet wird, wobei durch jedes Icon ein zugehöriges Funktionselement schematisch graphisch dargestellt ist und durch jede graphische Linie eine Verbindung auf Programmebene zwischen den durch die Linie verbundenen Funktionselementen graphisch dargestellt ist, b) einer Build-Steuereinrichtung, mit der in einem Build-Schritt aus dem graphischen Entwurf ein Quellcode (main.java, library.java) des Programmcodes erstellbar ist, indem zu jedem in der Struktur enthaltenen graphischen Icon der Quellcode des zugehörigen Funktionselements bereitgestellt wird und zu jeder in der Struktur enthaltenen graphischen Linie auf der Arbeitsfläche der Quellcode der Verbindung bereitgestellt wird, wobei mit den bereitgestellten Quellcodes der Verbindungen ein Ablauf-Quellcode (main.java) gebildet wird, durch den der Ablauf des Programmcodes festgelegt ist, c) einem Compiler, mit dem in einem Compilierungs-Schritt ein Zwischencode (main.class, library.class, main.cap, library.cap) erstellbar ist, der durch einen auf der Chipkarte und/oder dem mobilen Endgerät implementierten Interpreter in für die Chipkarte und/oder das mobilen Endgerät lesbaren ausführbaren Code interpretierbar ist, wobei der Ablauf-Quellcode in eine Ablauf-Zwischencode-Datei (main.class, main.cap) compiliert wird.
Software-Tool nach Anspruch 26, dadurch gekennzeichnet, dass es weiter eine Library-Schnittstelle aufweist, die dazu eingerichtet ist, für das Verfahren Quellcodes oder Zwischencodes von Funktionselementen bereitzustellen, die in einer gesonderten Library-Quellcode-Datei (library.java) bzw. Library-Zwischencode-Datei (library.class, library.cap) abgespeichert sind.
Software-Tool nach Anspruch 27, dadurch gekennzeichnet, dass es weiter eine Library-Auswahleinrichtung aufweist, mit der gemäß Anspruch 8 auswählbar ist, auf welche Weise für die Quellcodes der Funktionselemente der zugehörige Zwischencode erstellt wird.
Software-Tool nach einem der Ansprüche 26 bis 28, dadurch gekennzeichnet, dass es weiter eine Lade-Auswahleinrichtung aufweist, mit der gemäß einem der Ansprüche 23 bis 25 auswählbar ist, in welchen Bereich der Chipkarte und/oder des mobilen Endgeräts der Quellcode oder der Zwischencode in dem Ladeschritt gemäß einem der Ansprüche 15 bis 22 geladen wird.
Software-Tool nach einem der Ansprüche 26 bis 29, dadurch gekennzeichnet, dass alle Informationen über das jeweilige Projekt einschließlich verwendeter Menüs, Arbeitsflächen mit Icons und Parameter sowie Projektoptionen in einer Projekt-Datei abspeicherbar sind, insbesondere im XML-Format.
Software-Tool nach Anspruch 30, dadurch gekennzeichnet, dass in der Projekt-Datei zusätzlich graphische Entwurfsdaten abspeicherbar sind, die eine Rekonstruktion des in dem Entwurfsschritt a) erstellten graphischen Entwurfs durch Aufruf der Projekt-Datei erlauben.
Datenträger mit einem integrierten Schaltkreis und einem zumindest teilweise in dem integrierten Schaltkreis implementierten Software-Tool nach einem der Ansprüche 26 bis 31.
Computer mit einem integrierten Schaltkreis und einem zumindest teilweise in dem integrierten Schaltkreis implementierten Software-Tool nach einem der Ansprüche 26 bis 31.
Mobiles Endgerät mit einem integrierten Schaltkreis und einem zumindest teilweise in dem integrierten Schaltkreis implementierten Software-Tool nach einem der Ansprüche 26 bis 31.
Datenträger mit einem zumindest teilweise darin implementierten Programmcode, insbesondere Quellcode (main.java, library.java) oder Zwischencode (main.class, library.class, main.cap, library.cap), der nach einem Verfahren gemäß einem der Ansprüche 1 bis 25 erstellt worden ist.
Datenträger nach Anspruch 35, der als Chipkarte, vorzugsweise mit einem Mikroprozessor, ausgestaltet ist, insbesondere mit einer Mehrzahl von unterschiedlichen Speicherbereichen, die vorzugsweise mindestens einen der Speicherbereiche RAM, EEPROM, Flash-Speicher und ROM aufweisen.
Datenträger nach Anspruch 35 oder 36, der als eine Java Card für ein mobiles Endgerät wie eine Mobiltelefon oder ein Personal Digital Assistant (PDA) oder ein kombiniertes Gerät aus Mobiltelefon und Personal Digital Assistant (PDA) ausgestaltet ist.