EP1597670A1 - Verfahren zum erstellen von programmcode - Google Patents

Verfahren zum erstellen von programmcode

Info

Publication number
EP1597670A1
EP1597670A1 EP04711364A EP04711364A EP1597670A1 EP 1597670 A1 EP1597670 A1 EP 1597670A1 EP 04711364 A EP04711364 A EP 04711364A EP 04711364 A EP04711364 A EP 04711364A EP 1597670 A1 EP1597670 A1 EP 1597670A1
Authority
EP
European Patent Office
Prior art keywords
library
code
chip card
file
main
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP04711364A
Other languages
English (en)
French (fr)
Inventor
Bernd Müller
Gary Jones
Stefan Angermeier
Rainer Simmet
Peter Niebler
Gerhard Stix
Anton Sontheim
Heiko Oester
Martin RÖSNER
Jens Rudolph
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke+Devrient GmbH
Original Assignee
Giesecke+Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of EP1597670A1 publication Critical patent/EP1597670A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/34—Graphical or visual programming
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/38—Creation or generation of source code for implementing user interfaces

Definitions

  • the graphic design of the program code to be created is created in the design step.
  • 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.
  • 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.
  • a plurality of icons and the connections connecting the icons to one another are shown graphically;
  • 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.
  • 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).
  • program code 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.
  • library.cap can be written in the flash memory and main.cap in the EEPROM of the chip card.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Stored Programmes (AREA)

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 ausserhalb des Endgeräts durchgeführt, und der fertige Zwischencode wird auf das Endgerät bzw. eine dort vorgesehene Chipkarte geladen.

Description

Verfahren zum Erstellen von Programmcode
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-Kartenf ormat 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.
Wahlweise lässt sich ein erstellter Programmcode, insbesondere der in der Projekt-Datei enthaltene Quellcode oder Zwischencode, als ein weiteres Funktionselement deklarieren und vorzugsweise für das so deklarierte Funktionselement ein neues graphisches Icon erzeugen. Das neue graphische Icon, das zu dem deklarierten weiteren Funktionselement gehört, kann bei nachfolgenden Programmerstellungen wie oben beschrieben in dem Entwurfsschritt angeordnet werden, um weiteren Programmcode zu erstellen, bei dem der Programmcode des deklarierten Funktionselements als modulares Programmelement (wieder)verwendet wird. 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 Display aus gäbe 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 Lade-Parameter wird vorbestimmt, 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:
Fig. 1 ein Beispiel für eine erfindungsgemäße graphische Benutzeroberfläche für die Verwendung durch das erfindungsgemäße Verfahren bzw. Software-Tool;
Fig. 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;
Fig. 3 eine schematische Darstellung einer Mehrzahl von mit dem erfindungsgemäßen Software-Tool erstellten Programmcodes, die auf eine gemeinsame Library zugreifen können; Fig. 4 eine schematische Darstellung des erfindungsgemäßen Verfahrens, mit den Schritten a), b) und c), am Beispiel von Java als Programmiersprache;
Fig. 5 eine schematische Detaildarstellung des in dem Build-Schritt b) aus Fig. 4 erzeugten Ablauf -Quellcodes, gemäß einer bevorzugten Ausführungsform der Erfindung;
Fig. 6 eine schematische Darstellung einer erfindungsgemäßen Library- Quellcode-Datei;
Fig. 7 eine schematische Darstellung eines Ablauf-Zwischencodes gemäß einer ersten Ausführungsform der Erfindung;
Fig. 8 eine schematische Darstellung eines Ablauf-Zwischencodes gemäß einer zweiten Ausführungsform der Erfindung, gemäß einer ersten Variante, mit einer spezifischen Library;
Fig. 9 eine schematische Darstellung eines Ablauf-Zwischencodes gemäß der zweiten Ausführungsform der Erfindung, gemäß einer zweiten
Variante, mit einer verfahrensunabhängigen Library;
Fig. 10 eine schematische Darstellung mehrerer Ablauf -Zwischencodes gemäß der zweiten Ausführungsform der Erfindung, gemäß der zweiten Variante, mit einer verfahrensunabhängigen gemeinsamen
Library; Fig. 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 Fig. 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 Fig. 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 Lauf marke auf der Arbeitsfläche wieder deaktiviert wird, woraufhin das Icon auf der Arbeitsfläche 103 abgelegt wird.
Fig. 2 zeigt die Arbeitsfläche aus Fig. 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 Fig. 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 Fig. 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 PD A- 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).
Gemäß einer weitergebildeten Variante der Erfindung wird ein erstellter Programmcode als neues Funktionselement deklariert und für das deklarierte Funktionselement ein neues Icon erzeugt. Der Programmcode ist dabei erfindungsgemäß aus einem graphischen Entwurf mit mehreren Icons für mehrere Funktionselemente erzeugt worden, beispielsweise aus einem graphischen Entwurf wie dem in Fig.l dargestellten. Gemäß dem Beispiel aus Fig. 1 wird beispielsweise der Quellcode oder der Zwischencode in der Projekt-Datei mit dem Namen Mobile_Banking als neues Funktionselement mit dem gleichlautenden Namen „MobileJBanking" deklariert und ein zugehöriges Icon erzeugt. In analoger Weise werden die unterschiedlichen Programmcodes in den Projekt-Unterdateien Kontostand_anzeigen, Überweisung, Verbindungen, Konten, Service und Kontakt als
Funktionselemente mit den Namen Kontostand_anzeigen, Überweisung, Verbindungen, Konten, Service bzw. Kontakt deklariert und zu jedem der deklarierten Funktionselemente ein zugehöriges Icon erzeugt. Soll nachfolgend ein Programmcode erstellt werden, der die Funktion der Projekt-Unter datei z.B. Überweisung ausführt, so brauchen nicht die Icons, aus denen sich „Überweisung" zusammensetzt einzeln graphisch angeordnet und miteinander verbunden werden, sondern es kann das vorgefertigte neu deklarierte Funktionselement „Überweisung" verwendet werden und das zugehörige „Überweisung"-Icon graphisch angeordnet werden. Analoges gilt für die restlichen Projekt-Unterdateien und die übergeordnete Projekt-Datei „Mobile_Banking". Fig. 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 Fig. 1 und Fig. 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 Fig. 4 sind dies die proaktiven Befehle DISPLAY TEXT, PLAY TONE und SEND SHORT MESSAGE (vgl. auch Fig. 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 Fig. 1 der Befehl "Build" aktiviert wird, wird aus den Verbindungslinien 401 auf der Arbeitsfläche ein Ablauf-Quellcode main.java erstellt, wie in Fig. 4 durch die Pfeile angedeutet ist. Der genauere Aufbau der Datei main.java wird weiter unten erklärt (vgl. Fig. 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 Fig. 7 bis Fig. 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 Fig. 4 ein konvertierter Java Bytecode vom CAP-Format, wobei unter Java Bytecode ein Code vom CLASS-Format verstanden wird.
Fig. 5 zeigt eine schematische Detaildarstellung des in dem Build-Schritt b) aus Fig. 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 Fig. 6 dargestellt ist. Die Library- Quellcode-Datei library.java aus Fig. 6 enthält als Einträge die Quellcodes aller Funktionselemente, die dem Verfahren bzw. Software-Tool zur Verfügung stehen.
Fig. 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. Fig. 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 Fig. 7 enthält die Ablauf-Zwischencode- Datei main.cap aus Fig. 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.
Fig. 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 Fig. 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 Fig. 10 dargestellt ist.
Fig. 10 zeigt eine schematische Darstellung mehrerer Ablauf-Zwischencodes mainl.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 Fig. 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=l,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

P a t e n t a n s p r ü c h e
1. 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.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass mindestens ein Funktionselement und/ oder mindestens eine Verbindung durch Parameter konfiguriert wird.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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 dem mobilen Endgerät implementierten Interpreter der Zwischencode in für die Chipkarte und/ oder das mobile Endgerät lesbaren ausführbaren Code übersetzt wird.
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass mindestens eines der Funktionselemente ein proaktiver Befehl, insbesondere für Mobilfunkanwendungen, ist.
13. 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.
14. 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.
15. 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.
16. 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.
17. 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.
18. 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.
19. Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass das Laden in dem Ladeschritt zumindest teilweise kontaktlos durchgeführt wird.
20. 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.
21. 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.
22. 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.
23. 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.
24. 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.
25. 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.
26. Verfahren nach einem der Ansprüche 1 bis 25, dadurch gekennzeichnet, dass der erstellte Programmcode als neues Funktionselement deklariert wird, das gemäß dem Verfahren nach einem der Ansprüche 1 bis 25 verwendbar ist.
27. Verfahren nach Anspruch 26, wobei für das deklarierte neue
Funktionselement ein Icon erstellt wird, das gemäß dem Verfahren nach einem der Ansprüche 1 bis 26 verwendbar ist. .
28. Software-Tool zum Durchführen eines Verfahrens zum Erstellen von Programmcode nach einem der Ansprüche 1 bis 27, 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.
29. Software-Tool nach Anspruch 28, 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.
30. Software-Tool nach Anspruch 29, 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.
31. Software-Tool nach einem der Ansprüche 28 bis 30, 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.
32. Software-Tool nach einem der Ansprüche 28 bis 31, 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.
33. Software-Tool nach Anspruch 32, 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.
34. Datenträger mit einem integrierten Schaltkreis und einem zumindest teilweise in dem integrierten Schaltkreis implementierten Software-Tool nach einem der Ansprüche 28 bis 33.
35. Computer mit einem integrierten Schaltkreis und einem zumindest teilweise in dem integrierten Schaltkreis implementierten Software-Tool nach einem der Ansprüche 28 bis 33.
36. Mobiles Endgerät mit einem integrierten Schaltkreis und einem zumindest teilweise in dem integrierten Schaltkreis implementierten
Software-Tool nach einem der Ansprüche 28 bis 33.
37. 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 27 erstellt worden ist.
38. Datenträger nach Anspruch 37, 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.
39. Datenträger nach Anspruch 37 oder 38, 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.
EP04711364A 2003-02-17 2004-02-16 Verfahren zum erstellen von programmcode Ceased EP1597670A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE2003106717 DE10306717A1 (de) 2003-02-17 2003-02-17 Verfahren zum Erstellen von Programmcode
DE10306717 2003-02-17
PCT/EP2004/001453 WO2004072849A1 (de) 2003-02-17 2004-02-16 Verfahren zum erstellen von programmcode

Publications (1)

Publication Number Publication Date
EP1597670A1 true EP1597670A1 (de) 2005-11-23

Family

ID=32863828

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04711364A Ceased EP1597670A1 (de) 2003-02-17 2004-02-16 Verfahren zum erstellen von programmcode

Country Status (3)

Country Link
EP (1) EP1597670A1 (de)
DE (1) DE10306717A1 (de)
WO (1) WO2004072849A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8874093B2 (en) 2007-12-13 2014-10-28 Motorola Mobility Llc Scenarios creation system for a mobile device
US9678723B2 (en) * 2014-08-20 2017-06-13 Verizon Patent And Licensing Inc. Application programming interface (API) engine

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4860204A (en) * 1987-02-05 1989-08-22 Softron, Inc. Computer based workstation for development of graphic representation of computer programs
FR2801118B1 (fr) * 1999-11-17 2001-12-21 Bull Cp8 Procede de chargement d'applications dans un systeme embarque multi-application, systeme embarque correspondant, et procede d'execution d'une application du systeme embarque
DE10008632B4 (de) * 2000-02-24 2004-02-26 Gunter Gemmel Verfahren und System zum Erzeugen eines Computerprogramms

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004072849A1 *

Also Published As

Publication number Publication date
DE10306717A1 (de) 2004-09-16
WO2004072849A1 (de) 2004-08-26
WO2004072849B1 (de) 2004-09-30

Similar Documents

Publication Publication Date Title
DE60003457T2 (de) Verfahren und system zur konfiguration von komponenten, ausgebbar in einem netzwerk
DE68919503T2 (de) Methode und System zur Darstellung einer Benutzeroberfläche auf einem Computerbildschirm.
DE69503052T2 (de) Verbessertes objektorientiertes betriebssystem zum filtrieren von datenobjekten in einem fenster
DE69804107T2 (de) Eingebautes grafisches programmierungssystem
DE69326865T2 (de) Objektorientiertes Rechnersystem und Verfahren
DE10104043A1 (de) Die Schaffung der Möglichkeit, dass vorhandene Anwendungen andere Sprachen als ihre eingebauten Makrosprachen benutzen, ohne die vorhandene Anwendung zu ändern
DE10348784B4 (de) Vorrichtung und Verfahren zum Verwalten von Informationsdaten in einem Mobiltelefon
DE10140874A1 (de) Graphische Benutzeroberfläche
EP1005215B1 (de) Verfahren und Vorrichtung zum Editieren von Konfigurationsdaten für Telekommunikationssysteme
WO2004072849A1 (de) Verfahren zum erstellen von programmcode
DE10008632B4 (de) Verfahren und System zum Erzeugen eines Computerprogramms
DE4310615C2 (de) Entwurf elektrischer Vorrichtungen mit mehreren Entwurfswerkzeugen, die zumindest teilweise untereinander inkompatibel sind
DE69518238T2 (de) Objekt für die definition einer dialogeinheitschnittstelle
EP2220557B1 (de) Implementierung des user interfaces von mobiltelefonen auf basis von browser technologie
DE69811127T2 (de) Verfahren um objekte in den arbeitsbereich in eine rechneranwendung einzubringen
DE102005003680A1 (de) Verfahren zur Steuerung eines Geräts
DE102015221383A1 (de) Verfahren zum Betreiben eines Rechnersystems
EP1691275B1 (de) Verfahren und Vorrichtung zum rechnergestützten Erzeugen einer graphischen Benutzeroberfläche
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
DE10306810B4 (de) Verfahren und Anordnung zur Darstellung von Software-Assistenten auf mobilen Endgeräten
EP0740257B1 (de) Verfahren zum Konvertieren von betriebstechnischen Informationen in einer programmgesteuerten Kommunikationseinrichtung
DE10331799A1 (de) Verfahren zum Erstellen eines Programmcodes
DE102005018864A1 (de) Verfahren und System zum Erzeugen eines Quellcodes für ein Computerprogramm
WO2001080533A2 (de) Vorrichtung und verfahren zur präsentation eines mehrstufigen menüsystems
EP1420546A1 (de) Verfahren zum Erstellen eines Ablaufs einer zwischen mindestens zwei Instanzen ablaufenden Kommunikation und Protokolltester

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050919

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: RUDOLPH, JENS

Inventor name: ROESNER, MARTIN

Inventor name: OESTER, HEIKO

Inventor name: SONTHEIM, ANTON

Inventor name: STIX, GERHARD

Inventor name: NIEBLER, PETER

Inventor name: SIMMET, RAINER

Inventor name: ANGERMEIER, STEFAN

Inventor name: JONES, GARY

Inventor name: MUELLER, BERND

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20060404

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20070503