-
Die
Erfindung betrifft einen mit einem Mikroprozessor ausgestatteten
Datenträger,
in dem plattformunabhängiger
Programmcode für
mindestens eine Anwendung und zumindest ein Teil eines Interpreters
zum Interpretieren von plattformunabhängigem Programmcode implementiert
sind. Insbesondere betrifft die Erfindung einen Multiapplikations-Datenträger, in
dem Programmcodes von mehreren Anwendungen implementiert sind.
-
Ein
Datenträger
im Sinne der Erfindung ist ein Mikroprozessorsystem mit begrenzten
Systemressourcen, wie z.B. eine Chipkarte bzw. Smart Card (Mikroprozessor-Chipkarten)
oder ein Token, bei dem die Ressourcen, d.h. Speicherressourcen und/oder
die Rechenkapazität
(Rechenleistung) begrenzt sind. Der Datenträger hat einen Körper, in
dem ein Mikroprozessor angeordnet ist, und der jede beliebige standardisierte
oder nicht standardisierte Gestalt haben kann, beispielsweise die
Gestalt einer Chipkarte nach einer Norm wie z.B. ISO 7810 (z.B. ID-1,
ID-00, ID-000) oder die eines volumigen Tokens. Der Datenträger kann
weiter eine oder mehrere beliebige Schnittstellen für kontaktlose
und/oder kontaktbehaftete Kommunikation mit einem Lesegerät oder Datenverarbeitungssystem
(z.B. Personal Computer, Workstation, Server) haben.
-
Der
Mikroprozessor weist typischerweise eine CPU (central processing
unit) und einen oder mehrere Speicher auf. Üblicherweise sind nichtflüchtige und
flüchtige
Speicher vorgesehen.
-
In
funktioneller Hinsicht hat der Datenträger einen Systemspeicher, d.h.
einen oder mehrere (i.d.R. nicht-flüchtige) Speicherbereiche, in
denen das Be triebssystem des Datenträgers implementiert ist, einen
Anwendungsspeicher, d.h. einen oder mehrere (i.d.R. nicht-flüchtige)
Speicherbereiche, in denen Programmcodes von Anwendungen implementiert
sind, die auf dem Datenträger
unter Verwendung der CPU und des Betriebssystems oder auf einem externen
System ausgeführt
werden können,
und einen Arbeitsspeicher, in dem z.B. die CPU arbeitet, um z.B.
Anwendungen auszuführen.
Der Arbeitsspeicher kann flüchtig
oder nicht-flüchtig
sein, kann z.B. als gesonderter Speicher, z.B. RAM-Speicher (vgl. weiter
unten), vorgesehen sein oder in Form eines oder mehrerer spezifischer
Register innerhalb der CPU vorgesehen sein.
-
Ein
typischer herkömmlicher
Mikroprozessor auf einem Datenträger
hat als nicht-flüchtige
Speicher einen ROM (ROM = Read Only Memory) und einen EEPROM (EEPROM
= Electrically Erasable Programable Read Only Memory) und als flüchtigen Speicher
einen RAM (Random Access Memory). Im ROM ist in der Regel zumindest
der größte Teil
des Betriebssystems abgespeichert. Im EEPROM sind hauptsächlich Programmcodes
z.B. von Anwendungsprogrammen abgespeichert, sowie bei Bedarf Patches,
mit denen Fehler im ROM korrigiert werden. Der RAM (und/oder ein
oder mehrere Register der CPU) dient typischerweise als Arbeitsspeicher.
Teile von ROM und EEPROM können
wahlweise durch Flash-Speicher ersetzt sein. Insbesondere kann als Anwendungsspeicher
ein Flash-Speicher vorgesehen sein.
-
Programmcodes,
die von dem Mikroprozessor ausgeführt werden sollen, müssen dem
Mikroprozessor in einem Datenformat bereit gestellt werden, das
die CPU des Mikroprozessors ausführen
kann. Das Datenformat ist dabei grundsätzlich für jeden unterschiedlichen Typ
von CPU unterschiedlich.
-
Bei
nativen Programmiersprachen wie z.B. C, Basic, Assembler etc. wird
ein erstellter Programmcode durch Compilierung in maschinenlesbaren
Nativcode übersetzt,
der durch die jeweilige CPU ausführbar
ist. Der Compiler ist dabei für
die jeweilige CPU ausgelegt.
-
Beim
Konzept der plattformunabhängigen Programmierung,
wie es mit hohen Programmiersprachen wie zum Beispiel JavaTM von Sun Microsystems verfolgt wird, wird
durch die Compilierung eines erstellten Programmcodes mit einem
Compiler ein plattformunabhängiger
Zwischencode erzeugt. Der Compiler und der von ihm erzeugte Zwischencode sind
universell und unabhängig
von der CPU (d.h. von der "Plattform"), auf der der Programmcode
später
ausgeführt
werden soll. Der Zwischencode wird nachfolgend durch einen Interpreter
interpretiert und in ausführbaren
Code für
die verwendete CPU umgesetzt. Der plattformunabhängige Zwischencode ist für jede CPU
verwendbar, die durch den Interpreter unterstützt wird. Bei der Programmiersprache
Java z.B. ist der Zwischencode der JavaTM Bytecode (*.class-Dateien) oder für Java CardsTM (Chipkarte) auch der Java CardTM Bytecode (*.cap-Dateien). Der Interpreter
bei JavaTM ist für den JavaTM Bytecode (*.class)
die JavaTM Virtual Machine und für den Java CardTM Bytecode (*.cap) die Java CardTM Virtual Machine.
-
Plattformunabhängige Programmcodes (Zwischencodes)
haben den Vorteil, dass der Programmcode für jede Anwendung nur einmal,
unabhängig
von der später
verwendeten CPU, erstellt werden muss, und nachfolgend auf jeder
CPU lauffähig
ist. Die Anpassung an die CPU braucht nur ein Mal, nämlich bei
der Erstellung des Interpreters, zu erfolgen. Zudem bieten platt formunabhängige Programmierumgebungen
wie z.B. JavaTM eine Vielzahl von Sicherheitssystemen
wie z.B. Firewalls, mit denen sich unterschiedliche Anwendungen
gegeneinander abgrenzen lassen, und die bei nativen Programmierumgebungen
nicht vorgesehen sind.
-
Im
Vergleich zu ausgedehnten Computersystemen haben Datenträger mit
Mikroprozessoren zur Speicherung von Programmcodes nur begrenzten
Speicherplatz zur Verfügung.
Daher ist es wichtig, mit dem vorhandenen Speicherplatz sparsam
umzugehen. Andererseits besteht, insbesondere bei Multiapplikations
Smart Cards, zunehmend Bedarf, eine Mehrzahl von Anwendungen auf
einem einzigen Datenträger
unterzubringen. Beispiele für
Multiapplikations Smart Cards sind (U)SIM-Karten für Mobiltelefone,
Bürgerkarten
für die
Kommunikation zwischen Bürgern
und Behörden,
Gesundheitskarten für
Krankenversicherungs- und Krankenbehandlungsdienste, elektronische
Geldbörsen
mit weiteren Funktionalitäten
und Smart Cards mit Kombinationen der genannten und/oder weiterer
Funktionalitäten.
-
Bei
einem bekannten Mechanismus zum Ressourcen sparenden Implementieren
von Programmcode werden solche Programmcodesequenzen, die im Programmablauf
bereits verwendet worden sind, an einer späteren Stelle im Programmablauf
durch eine Referenz auf die weiter vorne im Programmablauf verwendete
identische Programmcodesequenz ersetzt. Hierdurch braucht die Programmcodesequenz
nur ein einziges Mal vollständig vorgesehen
zu werden. Jedes Mal, wenn die Programmcodesequenz nochmals in der
gleichen Form benötigt
wird, wird statt der vollständigen
Programmcodesequenz eine Referenz auf die erste Programmcodesequenz
im Programmablauf vorgesehen.
-
Aufgabe
der Erfindung ist es, einen Datenträger zu schaffen, in dem plattformunabhängiger Programmcode
für mindestens
eine Anwendung und zumindest ein Teil eines Interpreters zum Interpretieren von
plattformunabhängigem
Programmcode implementiert sind, wobei der plattformunabhängige Programmcode
für die
mindestens eine Anwendung möglichst
Ressourcen sparend in dem Datenträger implementiert ist, und
wobei zugleich die Plattformunabhängigkeit des Programmcodes
bei der Ausführung
der Anwendung beibehalten ist. Zudem sollen Verfahren zum Betreiben
eines solchen Datenträgers angegeben
werden.
-
Die
Aufgabe wird gelöst
durch einen Datenträger
nach dem unabhängigen
Anspruch 1 und durch ein Verfahren nach einem der unabhängigen Verfahrensansprüche. Vorteilhafte
Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angeführt.
-
Bei
dem erfindungsgemäßen Datenträger gemäß dem unabhängigen Anspruch
1 ist der plattformunabhängige
Programmcode der Anwendung oder Anwendungen komprimiert in dem Datenträger implementiert
(abgespeichert). Dadurch lassen sich in dem Datenträger größere Anwendungen
oder eine größere Anzahl
von Anwendungen unterbringen als bei einer unkomprimierten Speicherung
des Programmcodes. Der Datenträger
ist somit besonders Speicherressourcen sparend ausgebildet. Da andererseits
der Programmcode plattformunabhängig
ist, bleiben trotz der Komprimierung die Vorteile der plattformunabhängigen Programmierungsumgebung, beispielsweise
Sicherheitssysteme, wie z.B. Firewalls, die die plattformunabhängige Programmierung bietet,
nutzbar.
-
Daher
ist gemäß Anspruch
1 ein Datenträger geschaffen,
bei dem plattformunabhängiger
Programmcode für
mindestens eine Anwendung möglichst
Ressourcen sparend implementiert ist, wobei zugleich die Plattformunabhängigkeit
des Programmcodes bei der Ausführung
der Anwendung beibehalten ist.
-
Der
Programmcode hat vorzugsweise ein Datenformat, z.B. eines Zwischencodes,
das durch den Interpreter, der ebenfalls zumindest teilweise in dem
Datenträger
implementiert ist, interpretierbar ist.
-
Gemäß einer
bevorzugten Ausführungsform der
Erfindung hat der Programmcode in seiner zumindest teilweise komprimierten
Form ein durch den Interpreter interpretierbares Datenformat. Bei
dieser Ausführungsform
kann zur Ausführung
der Anwendung oder zumindest eines Teils der Anwendung, der Programmcode
der Anwendung bzw. des entsprechenden Teils der Anwendung ohne vorherige
Dekomprimierung dem Interpreter zur Interpretation bereitgestellt
wird. Der Interpreter kann den Programmcode, sobald er in den Arbeitsspeicher
geladen ist, ohne vorherige Dekomprimierung interpretieren. Nachfolgend
kann der interpretierte Code ausgeführt werden, so dass die Anwendung
ausgeführt
wird. Diese Ausführungsform
hat den zusätzlichen
Vorteil, dass Anwendungen sehr schnell ausgeführt werden können, obgleich
der zugehörige
Programmcode komprimiert und dadurch Speicher sparend abgespeichert
ist.
-
Alternativ
oder zusätzlich
hat der Programmcode in seiner nicht komprimierten Form ein durch den
Interpreter interpretierbares Datenformat.
-
Die
Compilierung des Quelltextes, um den Programmcode zu erzeugen, kann
beispielsweise bereits vorab auf einem leistungsfähigeren
Datenverarbeitungssystem erfolgt sein, z.B. einem Personal Computer
oder einer Workstation, bevor der Programmcode auf den Datenträger geladen
wird. Alternativ ist auch ein Datenträger mit einem darin implementierten
Compiler und eine Compilierung des Quelltextes auf dem Datenträger denkbar.
-
Der
Interpreter kann (nur) teilweise in dem Datenträger implementiert sein, um
Ressourcen des Datenträgers
zu sparen, oder vollständig
in dem Datenträger
implementiert sein, damit der Datenträger möglichst autonom betreibbar
ist.
-
Die
komprimierte Speicherung des Programmcodes der Anwendung oder Anwendungen hat
den weiteren Vorteil einer erhöhten
Sicherheit, dadurch, dass der Klartext des Programmcodes durch die
Komprimierung verfälscht
ist. Daher lässt sich
der Inhalt des komprimiert abgespeicherten Programmcodes durch einen
unbefugten Nutzer nur mit großem
Aufwand missbräuchlich
ausspähen.
Die komprimierte Implementierung des Programmcodes (Zwischencodes)
der Anwendung erhöht
somit zusätzlich
die Sicherheit des Datenträgers.
-
Falls
der komprimierte Programmcode nicht direkt, ohne vorherige Dekomprimierung
interpretierbar ist, wird zur Ausführung der Anwendung oder zumindest
eines Teils der Anwendung, der Programmcode zu zumindest dem entsprechenden
Teil der Anwendung dekomprimiert und dem Interpreter zur Interpretation
bereitgestellt. In diesem Fall wird der dekom primierte Programmcode
interpretiert und schließlich
ausgeführt.
Weitere in dem Datenträger ggf.
implementierte Programmcodes für
Anwendungen oder Anwendungsteile, die gerade nicht benötigt werden,
können
komprimiert abgespeichert bleiben. Soll beispielsweise eine von
mehreren Anwendungen zur Ausführung
aufgerufen werden, wird nur der Programmcode der gewünschten
Anwendung aus dem für
Anwendungen reservierten Anwendungsspeicher, z.B. einem Teilbereich
des EEPROM oder einem Flash-Speicher,
in den Arbeitsspeicher geladen, dekomprimiert und dem Interpreter
zugeführt. Die
Programmcodes der übrigen
Anwendungen verbleiben komprimiert im Anwendungsspeicher. Soll, als
weiteres Beispiel, bei einer größeren Anwendung nur
ein Teil der Anwendung ausgeführt
werden, so wird auf ähnliche
Weise nur der entsprechende Teil des zugehörigen Programmcodes in den
Arbeitsspeicher geladen, dekomprimiert und dem Interpreter zugeführt. Nicht
benötigte
Programmcodeteile der übrigen
Anwendungsteile verbleiben komprimiert im Anwendungsspeicher.
-
Gemäß bevorzugten
Ausführungsformen
der Erfindung ist das Datenformat des nicht durch den Interpreter
interpretierbaren Programmcodes das Datenformat eines JavaTM Bytecode oder Java CardTM Bytecode,
d.h. der interpretierbare Programmcode liegt als Klassendatei im
class-Format (*.class) gemäß der JavaTM Spezifikation bzw. im cap-Format (*.cap)
gemäß der Java
CardTM Spezifikation vor (Spezifikationen
derzeit einsehbar z.B. unter http://java.sun.com/products/javacard).
Bei diesen Ausführungsformen
ist durch den Interpreter zumindest ein Teil einer JavaTM Virtual
Machine bzw. einer Java CardTM Virtual Machine
gebildet.
-
Der
Datenträger
kann insbesondere eine Java CardTM sein.
Die Anwendung oder Anwendungen können
insbesondere JavaTM Applikationen oder JavaTM Applets sein.
-
Bei
einer weiteren Ausführungsform
der Erfindung enthält
der Datenträger
eine Komprimiereinrichtung zum Komprimieren von Programmcode. Bei dieser
Ausführungsform
kann plattformunabhängiger Programmcode
(Zwischencode) ohne weitere Maßnahmen
in den Datenträger
geladen werden. Der Datenträger
empfängt
den plattformunabhängigen
Programmcode (Zwischencode), komprimiert ihn und speichert ihn in
seinem für
Anwendungen vorgesehenen Anwendungsspeicher ab, z.B. im EEPROM oder Flash-Speicher.
Der komprimiert abgespeicherte Programmcode kann später wie
weiter oben beschrieben geladen und an den Interpreter bereitgestellt
werden, um die zugehörige
Anwendung auszuführen.
-
Bei
einer alternativen Ausführungsform
wird der Programmcode, der in dem Datenträger implementiert werden soll,
außerhalb
des Datenträgers komprimiert.
Der komprimierte Programmcode wird in den Datenträger eingespeist
und dort in einem Speicher implementiert, z.B. in einem ROM-Speicher oder in
einem EEPROM oder Flash-Speicher. Diese Ausführungsform hat den zusätzlichen
Vorteil, dass die begrenzte Rechenkapazität des Datenträgers geschont
wird.
-
Gemäß einer
weiteren Ausführungsform
der Erfindung sind bei dem erfindungsgemäßen Datenträger nur solche Teilabschnitte
des Programmcodes in komprimierter Form implementiert, die keinen
Befehlscode für
eine bedingte Verzweigung aufweisen. Diese Ausführungsform ist insbesondere
im Zu sammenhang mit derjenigen Ausführungsform bevorzugt, bei der
der komprimierte Programmcode erst dekomprimiert werden muss, bevor
er durch den Interpreter interpretiert werden kann. Hierbei ist
ein Befehlscode für
eine bedingte Verzweigung dadurch ausgezeichnet, dass auf den Befehlscode
der bedingten Verzweigung in Abhängigkeit
von einer Bedingung mindestens zwei unterschiedliche nachfolgende
Befehle folgen können.
Mit anderen Worten hat die Anwendung zwei (oder mehr) Zweige, von
denen in Abhängigkeit
von der Bedingung alternativ nur ein Zweig der beiden (oder mehreren)
Zweige ausgeführt
wird. Anwendungs-Befehlscode, der eine oder mehrere Verzweigungen
enthält,
ist vorzugsweise in unkomprimierter Form in dem Datenspeicher implementiert
(abgespeichert). Auf diese Weise kann an einer bedingten Verzweigung
im Programmablauf, die in mehrere Zweige mündet, vorgesehen werden, dass,
wenn gemäß der Bedingung
ein vorbestimmter Zweig des Programmablaufs ausgeführt werden
soll, nur der Programmcode zu diesem vorbestimmten Zweig geladen
und dekomprimiert wird. Programmcodes, die den übrigen Zweigen entsprechen,
die nicht ausgeführt
werden und daher nicht benötigt werden,
verbleiben komprimiert im Anwendungsspeicher.
-
Im
Zusammenhang mit derjenigen Ausführungsform,
bei der der komprimierte Programmcode erst dekomprimiert werden
muss, bevor er durch den Interpreter interpretiert werden kann,
ist es weiter bevorzugt, dass der Programmcode zu einer Anwendung
bzw. einem Teil davon nur während
der Ausführung
der Anwendung bzw. des Teils der Anwendung in dekomprimierter Form
bereitgehalten wird. Solange die Anwendung nicht aufgerufen wird,
ruht der komprimierte Programmcode in komprimierter Form im Anwendungsspeicher.
Wird andererseits eine aufgerufene, geladene, de komprimierte, interpretierte und
schließlich
zur Ausführung
gelangte Anwendung (bzw. ein solcher Anwendungsteil) wieder beendet, so
wird die dekomprimierte Form des zugehörigen Programmcodes vorzugsweise
wieder gelöscht.
Dies kann beispielsweise dadurch bewirkt werden, dass der Bereich
im Arbeitsspeicher, der für
die Anwendung bereitgestellt worden ist, wieder freigegeben wird.
-
Zusätzlich kann
Speicherplatz gespart werden, indem eine vorbestimmte Codesequenz
innerhalb des Programmcodes, die innerhalb des Programmcodes an
einer ersten Stelle und an mindestens einer weiteren Stelle zur
Ausführung
vorgesehen ist, an der weiteren Stelle durch eine Referenz auf die
Codesequenz an der ersten Stelle ersetzt wird. Die Referenz kann
insbesondere in einem direkten Verlinken der identischen Codesequenzen
auf ein und denselben Speicherabschnitt bestehen.
-
Im
Folgenden werden bevorzugte Verfahren zum Komprimieren von Programmcode
angegeben.
-
Gemäß einer
besonders bevorzugten Ausführungsform
der Erfindung ist die Komprimierung derart durchgeführt, dass
solche Bestandteile des Programmcodes entfernt werden, die keine
Information enthalten.
-
Beispielsweise
werden bei JavaTM bzw. Java CardTM Bytecode gemäß der JavaTM Spezifikation
Indizes in 2 Byte Werten abgespeichert, obwohl in den meisten Fällen der
Index kleiner als 255 ist, wo dass also 1 Byte ausreichen würde, um
den Index anzugeben. In diesem Fall wird beispielsweise bei der Komprimierung
das überflüssige Byte
des Index entfernt, so dass ein Index nur noch ein Byte lang ist.
-
Wahlweise
ist bei Bedarf der Interpreter auf den komprimierten Programmcode
angepasst, so dass er den komprimierten Bytecode interpretieren kann.
Alternativ wird die Komprimierung derart durchgeführt, dass
der Interpreter unverändert
bleiben kann.
-
Gemäß einer
weiteren Ausführungsform
der Erfindung wird, wenn eine vorbestimmte Codesequenz, z.B. Bytefolge,
innerhalb des Programmcodes an einer ersten Stelle und an mindestens
einer weiteren Stelle zur Ausführung
vorgesehen ist, die Codesequenz an der weiteren Stelle durch eine
Referenz auf die Codesequenz an der ersten Stelle ersetzt. Vorzugsweise
ist die Codesequenz ursprünglich
an allen Stellen im Programmcode vollständig ausformuliert vorhanden
und wird dann an allen Stellen bis auf die erste Stelle durch eine
Referenz auf die Codesequenz an der ersten Stelle ersetzt. Insbesondere
wird beispielsweise die Codesequenz beim Linken des Programmcodes
durch die Referenz ersetzt. Genauer wird beim Linken des Programmcodes
die an der ersten Stelle vorgesehene Codesequenz auf herkömmliche
Weise in dem Datenträger implementiert,
wobei die Codesequenz auf einen vorbestimmten Speicherabschnitt
verlinkt wird. An der weiteren Stelle wird erkannt, dass die identische Codesequenz
bereits an der ersten Stelle vorgesehen war und bereits auf den
vorbestimmten Speicherabschnitt verlinkt worden ist. Folglich wird
die Codesequenz nicht nochmals in dem Datenträger implementiert und dabei
insbesondere nicht nochmals auf einen freien, weiteren Speicherabschnitt
verlinkt. Statt dessen wird an der zweiten Stelle die Codesequenz
auf ein und denselben vorbestimmten Spei cherbereich verlinkt, auf
den die Codesequenz an der ersten Stelle verlinkt worden ist. So
lässt sich weiterer
Speicherplatz sparen.
-
Die
zuletzt genannte Ausführungsform,
bei der identische Codesequenzen auf denselben Speicherabschnitt
verlinkt werden, ist insbesondere für Tabellen vorteilhaft. Ein
vorbestimmter Eintrag in einer Tabelle wird beispielsweise von unterschiedlichen
Stellen im Programmcode aus referenziert. Gemäß der Ausführungsform der Erfindung werden
in diesem Fall alle diese unterschiedlichen Stellen auf ein und
denselben Eintrag in einer oder mehreren zusammengehörenden Tabellen
verlinkt. Bei einer Java Card ist beispielsweise der Konstantenpool
als Tabelle vorgesehen. Der Konstantenpool wird von unterschiedlichen
Stellen im Programmcode aus referenziert. Dennoch wird jeder Eintrag
des Konstantenpools nur ein einziges Mal im Konstantenpool implementiert.
Bei jeder weiteren Stelle, die eine Referenz auf einen Eintrag des
Konstantenpools enthält,
wird die weitere Stelle auf den bereits implementierten Eintrag
Konstantenpools verlinkt.
-
Im
folgenden wird die Erfindung anhand von Ausführungsbeispielen und unter
Bezugnahme auf die Zeichnung näher
erläutert,
in der zeigen:
-
1 ein
Flussdiagramm zur Veranschaulichung des Implementierens von Programmcodes
in einen Datenträger
sowie des Extrahierens von Programmcodes zur Ausführung einer
Anwendung, gemäß einer
ersten Ausführungsform
der Erfindung;
-
2 ein
analoges Flussdiagramm wie das in 1 gezeigte
für eine
zweite Ausführungsform der
Erfindung, bei der zusätzlich
in dem Datenträger eine
Komprimiereinrichtung implementiert ist;
-
3 ein
analoges Flussdiagramm wie das in 1 gezeigte
für eine
dritte Ausführungsform
der Erfindung, bei der zusätzlich
in dem Datenträger
eine Dekomprimiereinrichtung implementiert ist;
-
4 ein
analoges Flussdiagramm wie das in 1 gezeigte
für eine
vierte Ausführungsform
der Erfindung, bei der der Datenträger zusätzlich eine Komprimiereinrichtung
und eine Dekomprimiereinrichtung aufweist.
-
1 bis 4 zeigen
Flussdiagramme zur Veranschaulichung des Implementierens von Programmcodes
in einen Datenträger
sowie des Extrahierens von Programmcodes zur Ausführung einer Anwendung,
gemäß Ausführungsformen
der Erfindung. Der Datenträger
ist eine Java CardTM Multiapplikationskarte
(Smart Card, Chipkarte), in der eine Mehrzahl von Anwendungen in
Form von Applets implementiert sind. Der Quelltext eines in den
Datenträger
zu ladenden Applets wird zunächst
auf einem externen Computer, außerhalb
der Multiapplikationskarte, zu einem JavaTM Bytecode
compiliert und zusammen mit Export-Dateien zu einer cap-Datei konvertiert
(nicht gezeigt), so dass ein Programmcode im Datenformat eines Java
CardTM Bytecodes (Zwischencodes) erzeugt
wird. Der als cap-Datei vorliegende Programmcode hat ein durch eine
in der Multiapplikationskarte implementierte Java Card Virtual MachineTM interpretierbares Datenformat. Die Flussdiagramme
sind analog anzuwenden auf Datenträger, in denen nur eine einzel ne
Anwendung implementiert ist und/oder in denen andere Anwendungen als
Applets implementiert sind und/oder bei denen eine andere plattformunabhängige Programmierumgebung
als JavaTM verwendet ist.
-
Bei
einer ersten Ausführungsform,
die in 1 dargestellt ist, soll zuerst, wie in den Schritten 1 bis 3 dargestellt
ist, eine Anwendung in Form eines JavaTM Applets
in den Anwendungsspeicher einer Java CardTM Multiapplikationskarte
(Datenträger, Smart
Card, Chipkarte) geladen werden. Als Anwendungsspeicher wird bei
dieser Ausführungsform
der ROM verwendet. Alternativ kann das Applet auch im EEPROM oder
in einem Flash-Speicher implementiert (abgespeichert) werden. Der
Programmcode wird, vgl. Schritt 1, einer Komprimiereinrichtung
bereitgestellt, die den Programmcode, vgl. Schritt 2, komprimiert.
Die Komprimiereinrichtung komprimiert den Programmcode derart, dass
der komprimierte Programmcode immer noch ein Datenformat hat, das durch
die Java Card Virtual MachineTM der Multiapplikationskarte
interpretierbar ist. Der komprimierte Programmcode des Applets wird über Kontakte
(je nach Ausführungsform
kontaktlos oder kontaktbehaftet) der Multiapplikationskarte in die
Multiapplikationskarte eingegeben und nachfolgend, vgl. Schritt 3,
in den Anwendungsspeicher (hier ROM; alternativ EEPRROM oder Flash)
der Java CardTM Multiapplikationskarte geladen.
In dem Anwendungsspeicher sind bereits mehrere weitere Anwendungen
in Form von Applets abgespeichert. Mit Beendigung von Schritt 3 ist
die Multiapplikationskarte fertig zum Gebrauch.
-
Nun
soll, gemäß den Schritten 4 und 5 von 1,
ein in der Multiapplikationskarte implementiertes Applet ausgeführt werden.
Der zu dem gewünschten
Applet gehörige
komprimierte Programmcode, d.h. die komprimierte cap-Datei, wird,
vgl. Schritt 4, aus dem Anwendungsspeicher (EEPROM) in
den Arbeitsspeicher der Multiapplikationskarte geladen. Gemäß Schritt 5 wird
der geladene Programmcode ohne vorherige Dekomprimierung an die Java
Card Virtual MachineTM (Interpreter) bereitgestellt,
die schließlich
den Programmcode interpretiert und den interpretierten Code an die
CPU der Multiapplikationskarte liefert, woraufhin das Applet ausgeführt wird.
-
2 zeigt
ein analoges Flussdiagramm wie das in 1 gezeigte
für eine
zweite Ausführungsform
der Erfindung. Bei der zweiten Ausführungsform ist, anders als
bei der ersten Ausführungsform
aus 1, in der Java CardTM Multiapplikationskarte
eine Komprimiereinrichtung implementiert. Bei der Ausführungsform
aus 2 wird zunächst
in Schritt 1 Programmcode, der als cap-Datei vorliegt,
bereitgestellt und über
Kontakte (je nach Ausführungsform kontaktlos
oder kontaktbehaftet) der Multiapplikationskarte in die Multiapplikationskarte
eingegeben. Von den Kontakten aus wird der Programmcode, vgl. Schritt 2,
an eine in der Multiapplikationskarte implementierte Komprimiereinrichtung
bereitgestellt, die den Programmcode innerhalb der Multiapplikationskarte
komprimiert. Die Komprimiereinrichtung kann in die CPU der Multiapplikationskarte
integriert sein. Alternativ kann zum Komprimieren von Programmcodes
ein gesonderter Prozessor vorgesehen sein. Der komprimierte Programmcode
wird wie bei der Ausführungsform
aus 1 in dem Anwendungsspeicher der Multiapplikationskarte
abgespeichert. Das Ausführen
eines Applet erfolgt analog wie bei der Smart Card aus 1 (vgl.
Schritte 4 und 5 in 2).
-
3 zeigt
ein analoges Flussdiagramm wie das in 1 gezeigte
für eine
dritte Ausführungsform der
Erfindung, bei der zusätzlich
in dem Datenträ ger eine
Dekomprimiereinrichtung implementiert ist. Das Implementieren von
Applets in den Datenträger
(Java CardTM Multiapplikationskarte) erfolgt
wie bei der Ausführungsform
aus 1 (vgl. Schritte 1 bis 3 in 3).
Beim Ausführen
eines Applet wird, vgl. Schritt 4, zunächst der zugehörige Programmcode
aus dem Anwendungsspeicher (hier ROM) in den Arbeitsspeicher geladen.
Im nachfolgenden Schritt 5 wird der geladene Programmcode
dekomprimiert und danach, Schritt 6, an die Java CardTM Virtual Machine bereitgestellt. Diese
interpretiert den dekomprimierten Programmcode. Wie an Hand der 1 bis 3 beschrieben
wird schließlich
das Applet ausgeführt.
-
4 zeigt
ein analoges Flussdiagramm wie das in 1 gezeigte
für eine
vierte Ausführungsform
der Erfindung, bei der der Datenträger zusätzlich eine Komprimiereinrichtung
und eine Dekomprimiereinrichtung aufweist. Als Anwendungsspeicher wird
bei der vierten Ausführungsform
ein Flash-Speicher
verwendet. Das Komprimieren und Laden von Applets in die Java CardTM (Datenträger) gemäß den Schritten 1 bis 3 erfolgt
wie bei der zweiten Ausführungsform
(2). Das Ausführen
von Applets erfolgt wie bei der dritten Ausführungsform (3).