DE19945862A1 - Dynamische Speicherverwaltung von Datenobjekten in Javacard Applets - Google Patents

Abstract

Verfahren und Vorrichtung zur dynamischen Speicherverwaltung von Datenobjekten (10, 12) in SmartCards (8), insbesondere in JavaCards sind Gegenstand der Erfindung. Es wird vorgeschlagen, ein Objekt und Methoden für individuelle Speicherobjekte (10, 12) auf der SmartCard zu implementieren, die Speicherplatz vollständig zur Laufzeit eines Cardprogramms, insbesondere eines Java-Applets verwalten können. Zu dieser Speicherplatz-Verwaltung gehören die klassischen Funktionen wie schreiben, lesen, ändern, Speicherplatz allokieren, deallokieren und - als zusätzliches, optionales Merkmal - die Defragmentierung von Speicherbereichen. In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung werden die durch die oben erwähnte dynamische Speicherverwaltung erzeugten Speicher- oder Datenobjekte (10, 12) nicht mehr zur logischen Detailstrukturierung der Daten benutzt, sondern nur noch für eine logische Grobstrukturierung aller Datenobjekte eines Applets oder mehrerer eingesetzt. Innerhalb der Datenobjekte werden die Daten (14, 16, 18, 21, 22) mit einem logischen Verzeichnissystem administriert.

Description

1. HINTERGRUND DER ERFINDUNG 1.1 GEBIET DER ERFINDUNG

Die Erfindung betrifft die Programmierung und Betriebsweise von Anwendungen zum Gebrauch in elektronischen Computergeräten mit begrenzter Rechenleistung, die nur in geringem Maße moderne Programmierkonzepte auf hoher Ebene unterstützen. Insbesondere betrifft die Erfindung Verfahren und Vorrichtung zur dynamischen Speicherverwaltung von Datenobjekten in SmartCards, insbesondere in JavaCards.

1.2 BESCHREIBUNG DES STANDES DER TECHNIK UND SEINER NACHTEILE

Die eingangs erwähnten Geräte sind vor allem solche Geräte des allgemeinen Gebrauchs, die nur eine - verglichen mit einem Desktop-Computer - geringe Rechenleistung besitzen und deren Programmierung von keinen hochentwickelten Programmierkonzepten unterstützt wird. Exemplarisch dafür sollen für den Zweck der Offenbarung der vorliegenden Erfindung SmartCards genannt sein, also Karten, auf denen ein kleiner Speicherchip mit einem eigenen Mikroprozessor angebracht ist. Auf dem Chip können Daten gespeichert werden, die im Zusammenhang mit einer Host-Anwendung - beispielsweise das Bargeld-Ausgabeprogramm in einem Geldautomat - die verschiedensten Geschäftsprozesse ermöglichen. Die Akzeptanz dieser Chipkarten ist sehr groß, und ihre Anwendungsmöglichkeiten und Anwendungsbereiche wachsen schnell.

Es gibt zwei Sorten von SmartCards, zum einen die Dateisystem-orientierten SmartCards, die die Schnittstelle ISO 7816-4 als Protokoll zur Kommunikation mit Host-Anwendungen benutzen und auf denen bei der Initialisierung der Karte ein Verzeichnissystem eingerichtet wird, das den Speicherplatz für Daten der Host-Anwendung, die auf die SmartCard zugreift, genau strukturiert und vorgibt. Ein solches Verzeichnissystem verwaltet den gesamten, auf der SmartCard verfügbaren Speicherplatz.

Nachteil dieser sogenannten ISO-SmartCards ist jedoch, daß Assembler-Code zum Programmieren der Anwendungen benutzt werden muß, die auf diese Speicherplätze zugreifen. Dies ist höchst unkomfortabel für den Programmierer, und hochentwickelte Programmiertechniken sind für Anwendungen für solche Karten nicht anwendbar.

Zum anderen gibt es objektorientierte SmartCards, die dem Bedürfnis Rechnung tragen, auf der SmartCard selbst kleine Anwendungsprogramme zu speichern, die ausgeführt werden, wenn die Karte in einen SmartCard-Leser eingeführt wird. Diese autonom von der Host-Anwendung arbeitenden Programme können einzelne, kleine Geschäftsprozesse selbständig erfüllen, je nach Anwendungsbereich. Diese Anwendungen werden mit der Programmiersprache Java geschrieben, weswegen die Karten Java Cards genannt werden. Java Cards unterstützen die objektorientierte Programmierung, was die Schnittstelle zu modernen Programmiertechniken eröffnet. Durch diese modernen Techniken können letztendlich auf sehr effiziente Weise Anwendungen geschrieben werden, Anwendungs-Code wiederverwendet werden und standardisierte Schnittstellen ausgenutzt werden. Speziell bleiben für SmartCards allgemein jedoch die Speichermöglichkeiten und Rechenleistung begrenzt.

In dem Maß, wie die Nachfrage nach Java Card-Anwendungen gestiegen ist, hat sich auch das Bedürfnis verstärkt, auf einer Karte mehr als nur eine Anwendung unterzubringen.

Sogenannte "Multi-Application"-SmartCards liegen daher im Trend. So arbeiten verschiedene Dienstleister in zunehmendem Maße zusammen, um Kunden bestimmte Aufgaben abzunehmen, ihnen Anreize besonderer Art zu schaffen, oder besondere Serviceleistungen zu ermöglichen. Nur exemplarisch seien Fluggesellschaften genannt, die mit Mietwagen-Unternehmen und/oder Hotelketten zusammenarbeiten, um dem Kunden durch bestimmte Rabattsysteme und Vorreservierungsmöglichkeiten einen besonderen Service bieten zu können.

Dies bedeutet jedoch, daß möglichst auf einer SmartCard die logischen Verknüpfungen zwischen Anwendungsprogrammen aller beteiligten Unternehmen gespeichert sind, und nicht drei separate SmartCards notwendig sind, um diese Zusammenarbeit der drei Unternehmen zu ermöglichen. Ein dazu erforderlicher Datenaustausch von der einen Karte zur anderen wäre höchst unkomfortabel und für den Kunden nicht zumutbar. Soll nun im Zuge dieser zunehmenden Zusammenlegung von Unternehmensdienstleistungen eine vorhandene SmartCard eines Unternehmens in einer neuen Version herausgebracht werden, die die Dienstleistungen von zwei neuen Unternehmen im obigen Sinne mit unterstützt und mit diesen zusammenwirkt, so ist ein Upgrade der Karte erforderlich. Solche Upgrades oder auch erweiterte Speicherplatzanforderungen, die erst zur Laufzeit eines Java-Applets auftreten, sind jedoch bei Java-SmartCards vom Stand der Technik sehr unkomfortabel durchzuführen, da die JavaCards nur Programme speichern und die Größe der einzelnen Datenfelder, auf die die Anwendungsprogramme auf JavaCards - die sogenannten Java-Applets - zugreifen, statisch schon beim Laden des Applets auf eine Java Card allokiert werden. Eine solche statische Allokierung von Speicherplatz ist sehr unflexibel bei Änderungen oder Erweiterungen der Speicherplätze.

Außerdem wird der benutzte Speicherplatz der Datenobjekte unabhängig von der Grösse der in den Datenobjekten gespeicherten Daten statisch festgeschrieben. Das bedeutet, dass zum einen beim Speichern kleiner Datenmengen in einem grossen Datenobjekt viel Speicherplatz ungenutzt bleibt, wenn zur Laufzeit des Applets nur Daten geringen Umfangs auf den hierfür vorgesehenen Plätzen abgelegt werden. Zum anderen wird die logische Strukturierung der gespeicherten Daten nur über die zugeordneten Datenobjekte durchgeführt, was für die Programmierung von Applets nachteilig ist, da jedes einzelne Datenfeld für den Zugriff durch das Applet einen eindeutigen, separaten Namen haben muß. Dies ist in Fig. 1 anhand von personenbezogenen Datensätzen gezeigt. Die Figur zeigt in den separaten Kreisen Datenobjekte eines Java Card Applets, auf dem die Adressdaten von zwei Personen abgelegt werden können, nämlich Speicherplätze für den Namen einer Person, Name1, Name2, für die Telefonnummer Tel.1, Tel.2, oder die Adressdaten Str.1, Str.2, Adr.1, Adr.2. Die Grösse dieser Datenobjekte muss zum Zeitpunkt der Erstellung des Applets festgelegt werden. Der Speicherplatz wird unabhängig davon allokiert, ob alle Objekte zur Laufzeit benötigt werden oder nicht. Die Datenobjekte sind jeweils einzeln unabhängig voneinander separat definiert, was durch die einzelnen, nicht miteinander verbundenen Kreise auf der schematisch dargestellten SmartCard angedeutet ist.

Als weiterer Nachteil kann ein Java-Applet nicht auf Daten eines anderen Javä-Applets zugreifen, weil jedes Applet seine eigenen Daten schützt. Benötigen zwei Applets also zwei identische Datensätze, so müssen diese doppelt auf der Karte gespeichert werden. Speicherplatz wird also nicht effizient ausgenutzt.

Es stellt sich also die Aufgabe, JavaCards so programmieren zu können, daß der auf einer JavaCard verfügbare Speicherplatz für Daten dynamisch und effizient verwaltet wird, und daß Datensätze von mehreren Applets angesprochen werden können.

3. ZUSAMMENFASSUNG UND VORTEILE DER ERFINDUNG

Die genannten Aufgaben werden durch die in den unabhängigen Ansprüchen genannten Merkmale gelöst. Vorteilhafte Weiterbildungen des Erfindungsgegenstandes ergeben sich aus den jeweiligen Unteransprüchen.

Das grundlegende Konzept der vorliegenden Erfindung beruht auf der Idee, die Vorzüge yon Verzeichnissystem-orientierten SmartCards und von Java Cards zu kombinieren, um die oben gestellte Aufgabe zu erfüllen.

Dies wird erfindungsgemäß dadurch realisiert, daß der besondere Vorteil von Java Cards - nämlich die Fähigkeit, Objekte und zugehörige Methoden auf SmartCards zu implementieren - dazu ausgenutzt wird, den Vorteil der Verzeichnissystem-orientierten SmartCards zu erzeugen:

Es wird daher einem Aspekt der vorliegenden Erfindung für objektorientierte SmartCards folgend vorgeschlagen, ein Objekt und Methoden für individuelle Speicherobjekte auf der SmartCard zu implementieren, die Speicherplatz vollständig zur Laufzeit eines Cardprogramms, insbesondere eines Java-Applets verwalten können. Zu dieser Speicherplatz-Verwaltung gehören die klassischen Funktionen wie schreiben, lesen, ändern, Speicherplatz allokieren, deallokieren und - als zusätzliches, optionales Merkmal - die Defragmentierung von Speicherplatz.

Als weiteres zusätzliches Merkmal der vorliegenden Erfindung ist die Möglichkeit gegeben, ein und dasselbe Speicherverwaltungsobjekt für sämtliche auf der Java Card befindlichen Applets ansprechbar zu machen.

In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung werden die durch die oben erwähnte dynamische Speicherverwaltung erzeugten Speicher- oder Datenobjekte nicht mehr zur logischen Detailstrukturierung der Daten benutzt, sondern nur noch für eine logische Grobstrukturierung aller Datenobjekte eines Applets oder für den Zugriff durch mehrere eingesetzt.

Innerhalb der Datenobjekte werden die Daten mit einem logischen Verzeichnissystems administriert, das gemäß einer bevorzugten Ausprägung des erfinderischen Konzepts - angepaßt an objektorientierte SmartCards - in Form eines sogenannten Speicherverwaltungsobjekts mit zugehörigen Methoden als Code auf der Java Card residiert. Der Code zur Verwaltung des Verzeichnissystems ist je nach Anwendungerfordernissen dabei im Applet selbst codiert, kann aber auch im Kartenbetriebssystem oder an anderer Stelle gespeichert sein, und von einem oder mehreren Applets aufgerufen werden.

Durch Übertragung des erfinderischen Konzepts auf ISO-Filesystem-Karten wird mit Einsatz des so erzeugten, flexiblen Filesystems innerhalb von Datenobjekten daher auch das Problem der dynamischen Generierung der Layouts, d. h., der Gestaltung des kompletten Speichersystems bei diesen Karten durch die Hostanwendung oder "Off-Card"-Applikation gelöst.

Dies ist insbesondere bei dynamischen, objekt-orientierten Anwendungen, bei denen erst zur Laufzeit das Kartenlayout aus sogenannten High-Level-Objekten generiert wird, zwingend notwendig. Diese High-Level Objekte bilden einen universellen Bestandteil der Schnittstelle zwischen Host-Anwendungsprogramm und Karten-Anwendungsprogramm und stellen Platzhalter für Daten- und Befehlsaustauchvorgänge dar, die erst zur Laufzeit mit konkreten Implementierungen durch die entsprechenden Daten oder Befehle gefüllt werden und dann die - quasi spontan zur Laufzeit eines Applet aufkommenden - Speicherplatzanforderungen verursachen.

Die Vorteile der erfinderischen Konzepte können daher wie folgt zusammengefasst werden:

Es wird eine "automatische Speicherplatzverwaltung" innerhalb von Datenobjekten eines Applets durch das Verzeichnissystem ermöglicht. Hierdurch wird erreicht, dass Speicherplatz dynamisch an denjenigen Stellen zur Verfügung steht, an denen er zur Laufzeit des Applets benötigt wird; es wird daher weniger Speicherplatz vergeudet als bei herkömmlichen statischen Speicherplatzverwaltungsverfahren.

Zum Zeitpunkt der Appletprogrammierung müssen darüberhinaus nicht alle Datenstrukturen in Objektstrukturen abgelegt werden. Es können nachträglich welche hinzukommen, die sich nach der Dateneingabe quasi "selbst-installieren" können, soweit es nur die Grobeinteilung zuläßt. Weiter werden weniger Datenobjekte benötigt, wodurch weniger Aufwand bei der Objektadministration anfällt.

Schließlich wird ermöglicht, dass Anwendungen und Tools ihre Datenstrukturen, z. B. Kartenlayouts in den Datenobjekten erst nach der Initialisierung der Java Card zur Laufzeit einer Anwendung festlegen.

4. ZEICHNUNGEN

Ein Ausführungsbeispiel der Erfindung ist in den Zeichnungen dargestellt und wird in der genauen Beschreibung näher erläutert. In den Zeichnungen zeigt

Fig. 1 eine schematische Darstellung der Speicherung von Datenobjekten eines Java-Applets zum Speichern von Adressdaten und Karten-/Appletdaten gemäß dem Stand der Technik,

Fig. 2 eine schematische Darstellung der Speicherung von Daten in Verzeichnissystemen innerhalb von Datenobjekten eines Java-Applets nach der vorliegenden Erfindung,

Fig. 3 ein schematisches Blockdiagramm, das wesentliche Schritte beim erfindungsgemäßen Speicherverwaltungsverfahren zur Laufzeit eines JavaApplets zeigt.

5. GENAUE BESCHREIBUNG DES AUSFÜHRUNGSBEISPIELS

Mit Bezug zu Fig. 2 wird in einer beispielhaft ausgewählten Situation, in der es notwendig erscheint, ein Upgrade von SmartCards zu erzeugen, die durch die vorliegende Erfindung verbesserte, dynamische Speicherverwaltung beschrieben.

In dieser Situation soll eine bestimmte JavaCard-Serie, die von einer Fluggesellschaft herausgegeben wurde und die bereits an einen Kundenkreis verteilt ist, mit einer zusätzlichen Funktionalität ausgerüstet werden, was sich beispielhaber aus der neu beschlossenen Zusammenarbeit der Fluggesellschaft mit einer Hotelkette ergibt. Die neue Funktionalität macht es unter anderem notwendig, zwei neue Sätze von Personenstammdaten in dem vorhandenen Speicherplatz der Karte unterzubringen, sowie auf einen, vorher bereits vorhandenen Satz von Personenstammdaten, beispielsweise der des Inhabers der Karte, zurückzugreifen.

Erfindungsgemäß kann nun die Kartenserie einfach und flexibel auf den neuen Stand gebracht werden. Danach wird bei der Neukonzeption der Karte im vorhinein ein bestimmter, größerer Speicherbereich für Datenobjekte reserviert. Das neue, gemäß der vorliegenden Erfindung hergestellte Layout ergibt sich dann aus Fig. 2.

In dem in Fig. 2 gezeigten Beispiel ist eine schematisch umrissene SmartCard 8 und zwei Datenobjekte darauf dargestellt: Datenobjekt 10 ist ein Datenobjekt für personenbezogene Daten, und Datenobjekt 12 ist ein Datenobjekt für Daten zur Karten-/Appletverwaltung.

Diese Grobeinteilung des Speicherplatzes für Datenobjekte einerseits und Anwendungs-Code der Applets andererseits geschieht bei der Initialisierung der Karte.

Im vorhandenen Beispiel soll die neue, oben erwähnte Funktionalität für die SmartCard in der Praxis durch einen Dialog mit einem Host-Anwendungsprogramm an irgendeinem Terminal auf der Karte realisiert werden. Durch das Einschieben der Karte in den SmartCard-Leser des Terminals wird nun diese Host-Anwendung gestartet, die sämtliche, auf der SmartCard gespeicherten Daten sichert, zwischenspeichert und für ein neues Schreiben auf die Karte initialisiert.

Die Host-Anwendung führt nun die oben geschilderte Grobeinteilung für Datenobjekte und Anwendungs-Code durch, und schreibt in entsprechende Speicherbereiche die neu benötigten Applets, die die erweiterte Funktionalität mitbringen, sowie die alten, vorher auf der Karte vorhandenen Daten an neue Speicherplätze in einem passenden Datenobjekt.

Im vorliegenden Fall wird beispielsweise der vorher schon vorhandene Datensatz des Karteninhabers 14 in einem Verzeichnissystem in dem Datenobjekt 10 für personenbezogene Daten geschrieben. Des weiteren wird erfindungsgemäß das oben erwähnte "Speicherverwaltungsobjekt" auf der Karte gespeichert, zusammen mit den klassischen Speicherverwaltungs-Methoden, wie etwa Speicherplatz allokieren, Speicherplatz deallokieren, Speicherplatz defragmentieren, vom Speicherplatz lesen und den Speicherplatz beschreiben. Danach ist die SmartCard neu programmiert und kann vom Benutzer in ihrer erweiterten Funktionalität benutzt werden.

Der Benutzer zieht die Karte aus dem Lesegerät und verfügt nun über eine aktualisierte Karte. Deren Vorteile kann er beispielsweise dann kennenlernen, wenn er die Karte in ein Lesegerät der Fluggesellschaft einführt, die ihm durch die neue Zusammenarbeit mit der Hotelkette bestimmte Übernachtungsangebote und Hoteladressen zeigen soll. Eine Nutzung dieser Anwendung soll es nun erforderlich machen, daß der Benutzer selbst einen weiteren Satz von Personenstammdaten eingeben soll, um die neue Funktionalität der Karte komplett ausnutzen zu können.

Wie in Fig. 3 schematisch und aus Gründen verbesserter Klarheit nur auszugsweise dargestellt, steckt der Benutzer seine SmartCard in ein Terminal, das Applet startet, Schritt 110, und der Benutzer wird aufgefordert, Schritt 120, seinen neuen Satz von Personenstammdaten einzugeben. Sobald er dies beispielsweise über das Kartenterminal macht und Daten geliefert hat, Schritt 130, wird nach einer "Eingabe-korrekt ?"-Kon­ trolle 140 mit Korrekturmöglichkeit, Entscheidung 140- NEIN Zweig, nach Durchlaufen des JA-Zweigs, zur Speicherung der Daten nach dem erfinderischen, dynamischen Speicherverwaltungsverfahren das erfindungsgemäße Speichermanagerobjekt aufgerufen, Schritt 150.

Dieses bekommt die erforderlichen Parameter, wie etwa Anzahl der Zeichen des eingegebenen Namens, sowie die Zeichen selbst als Parameter mitgeliefert und erzeugt nun zur Laufzeit des Applets die neue Speicherstruktur 16 in Fig. 2 in demselben Verzeichnisbaum, der schon für die Speicherung der personenbezogenen Daten 14 des Karteninhabers selbst verwendet wurde, Schritt 160.

Das Speicherverwaltungsobjekt wird also in bevorzugter Weise für jeden Datensatz nur einmal aufgerufen. Alternativ kann es jedoch auch für jeden Namen beziehungsweise jedes Datenfeld separat aufgerufen werden. Es allokiert jeweils in beiden Möglichkeiten durch Aufruf der entsprechenden Allokierungsmethode und Übergabe der zugehörigen Parameter nur soviel Speicherplatz, wie es zur Speicherung der eingegebenen Daten notwendig ist.

Nach weiteren, vom Benutzer oder dem Applet durchgeführten Aktionen - siehe die Pünktchen in Fig. 3 - wird das Applet dann beendet - Schritt 170 und die SmartCard aus dem Terminalgerät gezogen. Speicherplatz wurde also zur Laufzeit des Applets allokiert, wodurch eine erhöhte Flexibilität bei der Handhabung und der Programmierung der SmartCards gezeigt ist.

Über den in Fig. 3 dargestellten Ablauf hinaus können jedoch zahlreiche weitere Abläufe sämtlich mit dem erfinderischen Speicherverwaltungskonzept realisiert werden.

Der Vorgang wird etwa nach der Eingabe des ersten Datensatzes z. B. für einen zweiten Personenstammdatensatz 18 in Fig. 2 wiederholt - was in Fig. 3 nicht mehr dargestellt ist. Danach wählt der Benutzer eine ihm zur Verfügung stehende Funktion aus, die die neu eingegebenen Daten auf dem Display der Host-Anwendung für eine Kontrolle sichtbar macht. Dabei stellt sich heraus, daß der Nachname falsch eingegeben worden ist, und die richtige Schreibweise zwei Buchstaben mehr erfordert. Der Benutzer möchte dieses also korrigieren und gibt den neuen Namen in korrekter Schreibweise ein. Die erneute Eingabe ruft wiederum das Speicherverwaltungsobjekt auf, was den Speicherplatz freigibt, der für den falsch geschriebenen Namen allokiert wurde, und schreibt den neu eingegebenen Namen zusammenhängend an eine andere Stelle im Speicher.

Gleichzeitig wird die freigegebene Stelle als freier Speicher markiert.

Nach einem beliebigen Zeitraum schließt sich nun ein drittes Unternehmen - ein Mietwagenunternehmen - dem Verbund der beiden ersten Unternehmen an. Die Karte des Kunden soll daher erneut mit erweiterter Funktionalität - und einem neuen, von diesem Unternehmen herausgegebenen Applet ausgestattet werden. Dabei soll durch das neu auf die Karte zu schreibende Applet auf die bereits auf der Karte vorhandenen Daten zurückgegriffen werden können, und es entstehen weitere Speicherplatzanforderungen zur Speicherung von weiteren, personenbezogenen Datensätzen.

In dieser Situation zeigt sich erneut der Vorteil des erfinderischen Speicherverwaltungsverfahrens, das es nun ermöglicht, daß das neue Applet mit seiner ID, wie oben beschrieben, in die Karte geladen wird, in dem zuständigen Applet-Verzeichnis des Datenobjekts 12 nach dem vorher bereits vorhanden Applet ID-Eintrag 21 als neuer Eintrag 22 aufgenommen wird, und das dann seinerseits aufgerufen werden kann. Zur Laufzeit des neuen Applets können die verlangten neuen, kundenindividuellen Personenstammdatensätze analog wie oben beschrieben eingegeben werden. Hierbei wird der Speicher wesentlich besser und effizienter ausgenutzt als bei SmartCards vom Stand der Technik, weil von Anfang an bekannt ist, in welchem Speicherbereich das Datenobjekt für Personenstammdaten liegt. Daß heißt, die Bitpositionen, die den Anfang beziehungsweise das Ende dieses Speicherbereiches markieren, können dem neu hinzugekommenen Applet bekanntgemacht werden. Das neu hinzugekommene Applet ruft wiederum das Speicherverwaltungsobjekt auf, um die bereits auf der Karte vorhandenen Datensätze lesen zu können, anzeigen zu können, sowie um neue Datensätze zu speichern.

Ein weiterer Vorteil des erfinderischen Verfahrens wird klar, wenn die Applet-Programmierung selbst betrachtet wird. Denn das zu programmierende Applet muß nur die Struktur eines Datensatzes kennen, nicht jedoch die Größe der Datenfelder der bereits benutzten Datensätze, um auf diese zugreifen zu können, und um weitere Datensätze derselben Struktur erzeugen zu können. Ein neuer Datensatz wird einfach als neues "Verzeichnis" mit den zugehörigen Datenfeldern als untergeordnete Struktur gespeichert. Daher wird die Applet-Programmierung einfacher.

Weiter kann der Gegenstand der vorliegenden Erfindung in Hardware, Software oder einer Kombination aus beiden realisiert werden. Eine beliebige Art von Computersystem oder Computergeräten ist dafür geeignet, das erfindungsgemäße Verfahren ganz oder in Teilen durchzuführen. Eine realisierbare Hardware-Software Kombination wäre ein normaler Computer mit einem Computerprogramm, das, wenn es geladen und ausgeführt wird, den Computer derart steuert, daß er das erfindungsgemäße Verfahren ganz oder in Teilen ausführt.

Ein solches Programm könnte auch hostseitig laufen und die Speicherverwaltung der SmartCard steuern. Die vorliegende Erfindung kann auch in ein Computerprogrammerzeugnis eingebettet sein, das sämtliche Merkmale enthält, die eine Implementierung der hierin beschriebenen Verfahren ermöglichen, und die, wenn sie in ein Computersystem geladen wird, dazu imstande ist, diese Verfahren auszuführen.

Computerprogrammeinrichtungen und Computerprogramme bedeuten im vorliegenden Kontext beliebige Ausdrücke in einer beliebigen Sprache oder Notation oder einem beliebigen Code eines Satzes von Anweisungen, die ein System mit einer Informationsverarbeitungsmöglichkeit dazu veranlassen sollen, von den folgenden Funktionen a) Umsetzung in eine andere Sprache oder Notation oder einen anderen Code, b) Reproduktion in eine unterschiedliche materielle Formeine bestimmte entweder direkt oder nacheinander oder beide durchzuführen.

Claims (10)

1. Verfahren zum Verwalten von Speicherplatz auf Computergeräten (8) mit begrenzter Unterstützung von Programmierkonzepten höherer Ebene in einem Datenobjekt (10, 12), gekennzeichnet durch den Schritt: Verwenden (150, 160) eines Speicherverwaltungsobjekts mit zugehörigen Speicherverwaltungsmethoden zur dynamischen Verwaltung von Speicherplatz zur Laufzeit eines Applets, wobei das Datenobjekt (10, 12) zur Aufnahme von Datensätzen (14, 16, 18, 21, 22) über mehr Speicherplatz verfügt, als zur Speicherung eines Datensatzes benötigt wird.

2. Verfahren nach Anspruch 1, wobei der Logikkreis, der das Speicherverwaltungsobjekt implementiert, auf dem Computergerät (8) residiert.

3. Verfahren nach dem vorstehenden Anspruch, bei dem eine Mehrzahl von Datensätzen (14, 16, 18, 21, 22) in verzeichnisförmiger Struktur innerhalb der Datenobjekte (10,12) verwaltet werden.

4. Verfahren nach Anspruch 2 oder 3, bei dem die Computergeräte objektorientierte SmartCards (8) sind.

5. Computergerät (8) mit begrenzter Unterstützung von Programmierkonzepten höherer Ebene, enthaltend Implementationen von Codeabschnitten, die dazu eingerichtet sind, zur Laufzeit eines auf dem Gerät (8) implementierten Programms ein Speicherverwaltungsobjekt mit zugehörigen Speicherverwaltungsmethoden zur dynamischen Verwaltung von Speicherplatz zu verwenden.

6. Gerät nach Anspruch 5, wobei der Logikkreis, der das Speicherverwaltungsobjekt implementiert, auf dem Computergerät (8) residiert.

7. Computergerät nach dem vorstehenden Anspruch, wobei das Gerät (8) eine objektorientierte SmartCard, insbesondere eine Java Card ist.

8. SmartCard nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, daß der Speicherraum auf der SmartCard (8) wenigstens ein Datenobjekt (10, 12) aufweist, das zur Aufnahme von Datensätzen (14, 16, 18, 21, 22) in verzeichnisförmiger Struktur über mehr Speicherplatz verfügt als zur Speicherung eines Datensatzes benötigt wird.

9. System, enthaltend eine Computereinrichtung zum Betreiben eines Hostanwendungsprogramms, das dazu eingerichtet ist, mit einem auf einem Computergerät (8) nach einem der Ansprüche 5 bis 8 gespeicherten Programm zusammenzuwirken, sowie eine Schnittstelle für einen Austausch von Daten oder Befehlen zwischen Computergerät (8) und Hostanwendungsprogramm.

10. Computerprogramm, enthaltend Programmcodebereiche zur Durchführung oder Vorbereitung der Durchführung der Schritte des Verfahrens gemäß einem der Ansprüche 1 bis 4, wenn das Programm in einen Computer geladen wird.