DE19954532A1 - Verfahren und System zur Speicherung von JAVA-Objekten in Vorrichtungen mit einer verringerten Unterstützung von höheren Programmierkonzepten - Google Patents

Abstract

Die auf einer SmartCard oder einer ähnlichen Vorrichtung zu speichernden Objekte sind Ausgaben des Hostanwendungscomputers in einer Form, die der Vorrichtung angepasst wurde, insbesondere in Form eines Byte-Arrays, das leicht auf einer derartigen SmartCard gespeichert werden kann. Diese Serialisierung umfasst das Konvertieren jedes einzelnen Objektes in eine Bytefolge, die das Objekt und seinen gegenwärtigen Status durch Speicherung aller Attribute, dessen Namen und aller weiterer Objekte, auf die sich das Objekt bezieht, das Gegenstand des Serialisierungsschrittes ist, repräsentiert. Mit der Gesamtheit dieser Informationen kann das Objekt in unveränderter Form nach einem Rücksetzen oder einer Unterbrechung, zu denen es während der Nutzung der SmartCard in einem jeweiligen SmartCard-Terminal kommen kann, wieder hergestellt werden. Die Wiederherstellungsprozedur wird auf analoge Weise durchgeführt: das Objekt, sowie alle weiteren Objekte auf die sich das Objekt bezieht, wird mit den aus der SmartCard ausgelesenen Daten instanziert und initialisiert. Das das Objekt repräsentierende Byte-Array kann sowohl auf gewöhnlichen dateisystemorientierten SmartCards als auch auf JavaCards gespeichert werden, ohne dass man die spezifischen weiteren Problemen konfrontiert wird (Fig. 1).

Description

1. HINTERGRUND DER ERFINDUNG 1.1 GEBIET DER ERFINDUNG

Die vorliegende Erfindung bezieht sich auf die Programmierung und den Betrieb von Anwendungen für den Einsatz mit Vorrichtungen mit einer verringerten Unterstützung von höheren Programmierkonzepten, insbesondere für den Einsatz von SmartCards, sie bezieht sich insbesondere auf Verbesserungen für die Programmierlese- und -schreiboperationen in derartigen Vorrichtungen.

1.2 BESCHREIBUNG UND NACHTEILE DES STANDES DER TECHNIK

Seit eine Chipkarte für öffentliche Telefone 1984 in Frankreich eingeführt wurde, ist das Chipkartengeschäft, die ökonomischen und technologischen Aspekte betreffend, rapide gewachsen. Bis zum Jahr 2000 wird ein jährliches Wachstum von 25% erwartet. Die Deutsche Geldkarte wurde über 40 Millionen mal herausgegeben. Frühere einfache Speicherchipplatten entwickelten sich zu modernen SmartCards mit ihrem eigenen Mikroprozessor, eigenem Betriebssystem und über 32 KBytes freiem Speicher für Anwendungen. Sehr zuverlässige Authentisierung, elektronische Unterschriften und Kryptografie sind Aufgaben bei denen SmartCards traditionellen Technologien wie Magnetstreifenkarten überlegen sind. Der integrierte Prozessor erlaubt es SmartCards unabhängig zu arbeiten und nicht durch die Umgebung beeinflussbar zu sein: empfindliche Daten, z. B. ein geheimer Schlüssel, müssen die Karte niemals verlassen. SmartCards sind in der Lage, kryptografische Algorithmen oder Passwortüberprüfungen lokal durchzuführen, bevor gespeicherte Daten freigegeben werden. Elektronische Geldtransaktionen können auf diese Weise ohne eine aufwendige Online-Verbindung zu Hostsystemen durchgeführt werden. Deshalb spielen SmartCards insbesondere im Electronic Business und Bankwesen eine besondere Rolle.

Ein anderes bedeutendes Gebiet von Anwendungen ist die Konsumelektronik: Mobiltelefone und Set-Top-Boxen wenden bereits SmartCard-Technologie an. Schließlich wird es in einigen Jahren eine neue Generation kleiner Elektronikgeräte geben, z. B. Computergeräte mit verringerten Ressourcen, die in Massenproduktion hergestellte Niedrigpreisgeräte für eine Vielzahl Einsatzfälle des täglichen Lebens darstellen, von denen jedes einen Prozessorchip und etwas Programmspeicher enthält.

Beiden Gerätetypen ist gemeinsam, dass sie durch den Besitz einer verringerten Unterstützung für höhere Programmierkonzepte gekennzeichnet sind.

Wenigstens ein großer Nachteil steht der Verbreitung derartiger Vorrichtungen und besonders der von SmartCards und ihrer Anwendungsentwicklung entgegen: die Softwareentwicklungsprobleme, die mit dem Speichern und Lesen auf/von derartigen Vorrichtungen einhergehen.

Das Speichern von Objekten, z. B. Programmierobjekten als ein Element von objektorientierten Programmier (OOP-)Techniken, ist eine wesentliche Aufgabe von objektorientierter Softwareentwicklung. Das Speichern eines Objektes umfasst sowohl das Speichern der Attribute, die das Objekt beschreiben, und das Speichern des Status in dem (OOP) Verfahren und Algorithmen enthalten sind, wenn das Objekt gespeichert wird, um in der Lage zu sein, die Verfahren und Algorithmen einfach und konsistent nach einem Rücksetzen oder einer Unterbrechung eines Programms fortzuführen, das beliebige Operationen an den Objekten ausgeführt hat.

Derartig hoch entwickelte Speicherverfahren können jedoch auf Computer-Vorrichtungen mit verringerten Ressourcen, d. h. beliebigen Vorrichtungen die einen Chip geringer Größe und sehr beschränkter Rechenleistung und Speicherkapazität besitzen, kaum genutzt werden. Weiterhin können sie auf den obigen Vorrichtungen mit einer verringerten Unterstützung höherer Programmierkonzepte nicht einfach ausgeführt werden.

Dateisystemorientierte SmartCards sind ein wichtiges Beispiel für derartige Vorrichtungen. Auf SmardCards wird jede Information unter Nutzung traditioneller Dateistrukturen bei dem beschränkten Speicherplatz und Dateizugriffseinschränkungen insbesondere für derartige Vorrichtungen gespeichert. Derartige Strukturen enthalten eine Sammlung einfacher Dateitypen und zugehöriger Dateiverzeichnisse um die Anwendungsdaten zu speichern, die zu einer Hostanwendung gehören, mit dem die SmartCard genutzt wird. Zwischen Hostcomputer und SmartCard werden Daten ausgetauscht, indem eine Vielzahl einfacher Befehlsfolgen, gewöhnlich als APDU abgekürzt, genutzt werden, welche die Daten als Abspann hinter den jeweiligen Anweisungen tragen und in die SmartCards über die meist vorhandenen zweipoligen Kontakte eingebracht werden.

Derartige dateisystemorientierte SmartCards sind die am meisten eingesetzten und die billigsten, im Vergleich mit den sogenannten JavaCards, wobei deren Entwicklung noch nicht abgeschlossen ist. Derartige JavaCards sind in der Lage, vollständige SmartCard-Anwendungen in Form von Applets zu speichern, und sie können diese auch autonom ausführen. In derartigen Karten können sowohl die einfachen Datentypen als auch komplette Programmierobjekte gespeichert werden. Eine derartige komfortable Speicherprozedur kann jedoch nur von der SmartCard-Anwendung selbst realisiert werden und kann nicht von der zum Austausch von Daten mit der jeweilige SmartCard-Anwendung nötigen Hostanwendung angestoßen werden. Wenn die Hostanwendung irgendein Objekt auf der JavaCard zu speichern hat, muss zum Datenaustausch die traditionelle Prozedur zur Übertragung von APDUs ausgeführt werden. Wenn jedoch Daten in APDUs übertragen werden hat der Anwendungsentwickler auf Datenformate Rücksicht zu nehmen, um alle Daten in adäquater Form auf der SmartCard anzuordnen. Diese Aufgabe erfordert eine Menge spezieller Erfahrung, die spezifisch für jede SmartCard- Dateisystemarchitektur ist.

Um das Datenmanagementproblem zu illustrieren mit dem der Anwendungsprogrammierer konfrontiert ist, wird als nächstes ein kleines und einfaches Beispiel gegeben.

Ein Anwendungsobjekt soll ein Bankkonto beschreiben. Die Klasse wird "BankKonto" genannt. Sie hat die Merkmale "Konto" und "KreditGrenze". Daneben umfasst diese Klasse die Programmiermethoden "Abheben()", "Einzahlen()" und "HoleAnzahlVonTransaktionen()". Der Anwendungsentwickler hat nun die einzelnen Attribute von dem Objekt auszulesen und diese auf der SmartCard spezifisch für das jeweilige Objekt jeweils getrennt zu speichern. Somit sind Konto, KreditGrenze sowie ein interner Zähler der HoleAnzahlVonTransktionen, der für das Zwischenspeichern der aktuellen Anzahl von SmartCard-Zugriffen notwendig ist, auf diese komplizierte Weise zu behandeln.

Wenn der Anwendungsentwickler die jeweiligen Daten getrennt und möglicherweise in einer Vielzahl verschiedener Weisen speichern muss, wobei jeder Weg für einen bestimmten SmartCard-Typ typisch ist, dann kann ein Anwendungsentwickler keinen großen Vorteil aus dem Softwareentwicklungskomfort ziehen, der zu objektorientierten Anwendungen, z. B. visuelle Programmiermethoden, gehört, da die SmartCards nur die oben betrachteten einfachen Datentypen unterstützen. Der Anwendungsentwickler hat die Objekte explizit in einfache Datentypen umzuwandeln, die von der SmartCard unterstützt werden, für die die Anwendung entworfen wurde. Derartige Aufgaben unterbrechen eine schnelle vorwärts gerichtete objektorientierte Softwareentwicklung und verkomplizieren visuelle Programmiertechniken.

Eine Alternative zur Nutzung von JavaCards für die Handhabung komplexer Objekte auf JavaCards ist nicht einfach zu realisieren, da die JavaCard-Technologie nicht zur Nutzung fertiggestellt, teuer und noch nicht ausreichend standardisiert ist. Somit ist der bedeutendste SmartCard- Sektor heute derjenige mit traditionellen dateisystemorientierten SmartCards.

1.3 AUFGABEN DER ERFINDUNG

Deshalb ist es eine Aufgabe der vorliegenden Erfindung, die Softwareentwicklung für Computergeräte mit verringerter Unterstützung von höheren Programmierkonzepten und insbesondere für SmartCard-Anwendungen durch Bereitstellung eines Zugriffs durch objektorientierte Programmierung auf SmartCards zu verbessern.

2. ZUSAMMENFASSUNG UND VORTEILE DER ERFINDUNG

Diese Aufgabe der Erfindung wird durch die Merkmale erzielt, die in den unabhängigen Ansprüchen festgehalten werden. Weitere vorteilhafte Anordnungen und Ausführungsformen der Erfindung werden in den jeweiligen Unterabschnitten dargelegt.

Die Objekte, die auf einer SmartCard oder einer ähnlichen Vorrichtung in dem oben genannten Sinn zu speichern sind, sind Ausgaben von dem Hostanwendungscomputer, die in einer seriellen Weise an die Vorrichtung angepasst sind, insbesondere in Form eines Byte-Arrays, das leicht auf einer derartigen SmartCard gespeichert werden kann. Die Serialisierung umfasst zur Umwandlung eines bestimmten Objektes in eine Folge aus Bytes, die das Objekt und dessen aktuellen Status durch Speichern aller Attribute darstellt, den Namen von diesem und allen weiteren Objekten, auf die sich das Objekt bezieht, das bei der Serialisierung betrachtet wird. Mit der Gesamtheit der Information kann das Objekt später prinzipiell sofort oder in Verbindung mit einem anderen Anschluss an eine Hostanwendung, die sich an einem anderen Ort befindet, einschließlich der Aktualisierungen, die vorher durchgeführt wurden, wieder hergestellt werden. Weiterhin können die Objekte in einer unveränderten Form nach einem Rücksetzen oder nach Unterbrechungen wieder hergestellt werden, zu denen es möglicherweise während der Nutzung der SmartCard in einem entsprechenden SmartCard-Terminal kommen kann. Die Wiederherstellungsprozedur wird auf analoge Weise ausgeführt: Das Objekt sowie alle weiteren Objekte auf die sich das Objekt bezieht wird instanziert und wird mit den Daten, die aus dieser SmartCard ausgelesen wird, initialisiert. Das Byte-Array, das das Objekt darstellt, kann sowohl in üblichen dateisystemsorientierten SmartCards als auch auf JavaCards gespeichert werden, ohne dass man mit irgendwelchen weiteren spezifischen Problemen konfrontiert wird.

Das Verfahren der vorliegenden Erfindung mit den Merkmalen von Anspruch 1 hat in Bezug zu dem Verfahren, das in der Diskussion zum Stand der Technik grob skizziert wurde, den Vorteil, dass Geschäftsobjekte wie JavaBeans in integraler Form, einschließlich der Attribute und der Verfahren des Objektes, hintereinander und in einem einzigen Schritt gespeichert werden können, anstatt eine Vielzahl einzelner Attribute zu speichern oder ein besonderes Dateiformat zu definieren. Dies vereinfacht das Entwickeln von Anwendungen außerordentlich: Die Anwendungsentwickler definieren ihre eigenen Objekte ohne deren binäre Darstellung berücksichtigen zu müssen.

In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens, das auf Java-Anwendungen angewandt wird, ist es vorteilhaft, diesen Serialisierungsschritt einfach durch Einsatz der "Objektserialisierung" zu realisieren, die Teil von Java 1.1 ist.

Es ist somit möglich, die Nutzung von JavaBean-Items zu erweitern, um die derartige Itemtechnologie auf bestimmte Verfahren zur Handhabung derartiger Objekte, wie dem Speichern und Lesen der Objekte, für Programmierungszwecke anzuwenden.

In einer weiteren bevorzugten Ausführungsform werden die Objekte in TLV-formatierter Form gepackt, d. h. Kennzeichen, Länge und Wert werden komprimiert bevor sie gespeichert werden. Dies erhöht den Nutzungsgrad des begrenzten Speicherplatzes auf derartigen SmartCards und ähnlichen Vorrichtungen.

So werden SmartCard-Anwendungsdaten transparenter, die Handhabung derartiger Daten wird einfacher und flexibler, da alle Datentypen der angelegten objektorientierten Programmiersprache bereitgestellt werden. Eine spezielle Kenntnis für SmartCard-Dateisystemstrukturen ist für den Anwendungsentwickler nicht erforderlich.

Indem eine objektorientierte Anwendungsentwicklung für dateisystemorientierte SmartCards nach dem Stand der Technik ermöglicht wird, können diese zur Entwicklung innovativer Softwarelösungen genutzt werden, die mit modernen objektorientierten Softwareentwicklungstechniken einschließlich visueller Programmiertechniken ausgeführt werden können. Somit schließt das Grundprinzip der vorliegenden Erfindung eine Lücke zwischen modernen Programmiertechniken und ihrer Anwendbarkeit auf Vorrichtungen mit einer verringerten Unterstützung höherer Programmierkonzepte, wie etwa SmartCards. Das Schließen dieser Lücke ist bedeutend, da neue JavaCards noch nicht völlig fertig entwickelt sind und diese viel teurer als dateisystemorientierte SmartCards sind.

Somit können mit der Hilfe von JavaBean-Technologie aus einfachen und flexiblen Softwareelementen SmartCard- Anwendungen in Java zusammengestellt werden, die die Anwendungsdaten enthalten und die ohne getrennte Programmierleistungen als eine Gesamteinheit auf jeder SmartCard gespeichert werden können. Derartige Elemente liefern für die Zusammenstellung komplexer Strukturen von SmartCard Informationen durch visuelle Programmiertechniken ohne besondere Kenntnis von SmartCards und ohne weitere Kenntnis auf diesem Gebiet. Die Nutzung der vorgeschlagenen Java-Serialisierung zur Durchführung der vorgeschlagenen Umwandlung bietet den Vorteil eines allgemein akzeptierten Quasistandards, der sich auf das Speicherformat der Objektzustände bezieht.

Weiterhin können Forderungen nach größerem Speicherplatz im Vergleich zu den Anforderungen von konventionellem, optimiertem Kartenlayout durch die oben betrachteten Vorteile und durch den deutlich erkennbaren Trend zu SmartCards mit stetig anwachsendem Speicherplatz ausgeglichen und ausgewogen werden.

Weiterhin erfordert das vorgeschlagene Verfahren keine JavaSmartCard-Technologie, sie kann jedoch JavaSmartCards zur Nutzung beinhalten.

Weiterhin kann eine feste Speicherung eines Objektstatus erzielt und genutzt werden, um komplexe eigene Klassen einer objektorientierten Anwendung in Verbindung mit SmartCards elegant zu nutzen.

Schließlich ist dieser Ansatz für visuelle Softwareentwicklung prädestiniert, bei der der Programmierer seine Anwendungsobjekte erzeugt und diese durch Ereignisse quasi intuitiv in einer grafischen Umgebung verbindet.

3. KURZBESCHREIBUNG DER ZEICHNUNGEN

Die vorliegende Erfindung wird beispielhaft illustriert und ist nicht durch die Form der Figuren der zugehörigen Zeichnungen begrenzt, wobei:

Fig. 1 eine schematische Skizze ist, die einen zusammenfassenden Überblick der erfindungsgemäßen Speicher- und Leseverfahren einschließlich der Objekte und der Darstellung ihrer Stati darstellt,

Fig. 2 eine schematische Darstellung eines Blockdiagramms ist, das die wesentlichen Schritte des Speicherverfahrens gemäß der Erfindung zeigt,

Fig. 3 eine schematische Darstellung eines Blockdiagramms ist, das die wesentlichen Schritte des Leseverfahrens gemäß der Erfindung zeigt.

4. BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM

Unter allgemeiner Bezugnahme auf die Figuren und mit besonderer Bezugnahme auf Fig. 1 wird als nächstes das Grundprinzip der vorliegenden Erfindung unten illustriert und zusammengefasst.

Das Prinzip wird an Hand einer Bankanwendung 6 illustriert, von der angenommen werden kann, dass sie mit einer Vielzahl unterschiedlicher SmartCards 7, 8 über eine Programmierschnittstelle 9 arbeitet, die eine zentrale Rolle bei der Implementierung des erfindungsgemäßen Verfahrens spielt. Die Anwendung umfasst wenigstens zwei beispielhafte Anwendungsobjekte, ein Anwendungsobjekt 10 hält die Daten, die den Kartenhalter beschreiben, und ein weiteres Objekt 12 beschreibt das Bankkonto des Kartenhalters. Dieses Beispiel wird absichtlich einfach gehalten, um den Blick auf den Kern der vorliegenden Erfindung zu richten.

Die Serialisierung von Objekten vor deren Speicherung und die jeweilige Deserialisierung nach deren Lesen findet in der Schnittstelle 9 statt und kann eine JavaBeanItem-Klasse umfassen, die dem Anwendungsingenieur zur Verfügung gestellt wird.

Die BeanItem-Klasse liefert die Funktionalität zum Speichern und Wiederherstellen, d. h. zum Lesen der anwendungsspezifischen Objekte auf beziehungsweise von den SmartCards. Aber jedes besondere Anwendungsobjekt kann durch den Anwendungsingenieur selbst definiert werden. Das Kontoobjekt 12 kann wie folgt beschrieben werden:

Wie man sehen kann besitzt es drei Datenitems, d. h. Konto, Kreditgrenze und Anzahl von Transaktionen, und drei Methoden, die mit den drei Items arbeiten, d. h. zum Abheben von Geld, zum Einzahlen von Geld und zum Auslesen der Anzahl von Transaktionen, die mit jedem Abheben oder Einzahlen erhöht wird.

Gemäß der Erfindung gibt es keine Notwendigkeit, irgendeine Zuordnung zwischen beliebigen Daten und dem Ort auf der SmartCard zu machen an dem sie gespeichert werden beziehungsweise von dem sie wiederhergestellt werden. Der Anwendungsingenieur muss nicht die bestimmten Attribute identifizieren und muss nicht spezielle Verfahren nutzen um den Zugriff auf SmartCard-Dateien zu realisieren. Der Status des Objektes "BankKonto" kann in integraler Form auf der SmartCard mit Hilfe der BeanItem-Methode "sichereAufCard()" gespeichert werden, die unten detaillierter beschrieben wird.

Die Serialisierung ist allgemein und gültig für alle Objekte und kann leicht vom BeanItem für beliebig andere SmartCards angewandt werden.

Als nächstes und unter zusätzlicher Bezugnahme auf Fig. 2 werden die grundlegenden Schritte zur Speicherung eines Objektes 'o' auf einer SmartCard mit Hilfe eines BeanItem- Objekts zusätzlich mit Hilfe eines Auszugs aus dem folgenden kommentierten Programmiercode beschrieben, der als Teil des Quellcodes der Hostanwendung 6 betrachtet werden kann:

Dementsprechend ist der Wiederherstellungsschritt des Objektes 'o' unabhängig von dem Objekt selbst, was durch den folgenden kommentierten Programmiercode illustriert wird, der unter Bezugnahme auf Fig. 3 gelesen werden sollte.

Jetzt, nach dem Speichern und der anschließenden Wiederherstellung wird derselbe Objektstatus wiederhergestellt, außer dem Status des internen Standes des Transaktionszählers, der von einem zugehörigen Zähler von sieben auf acht erhöht wurde.

Wie man aus dem Obigen sehen kann, kann das Lesen und Schreiben von Objekten ohne besondere Kenntnis des SmartCard-Dateisystems programmiert werden, wenn der Anwendungsingenieur mit den jeweiligen JAVA-BeanItem- Objekten loadFromCard() beziehungsweise saveToCard() ausgestattet ist.

In Verbindung mit der ebenfalls anhängigen Beschreibung die visuelle Programmierung von SmartCard-Anwendungen durch Nutzung von kartenunabhängigen Objekten betreffend, kann das Speichern und Wiederherstellen von Objekten von Java- Anwendungen auch kartenunabhängig durch Nutzung einer visuellen Entwicklungsumgebung realisiert werden: Dort wird eine Java-Schnittstelle bereitgestellt, die Verfahren zur Speicherung und Wiederherstellung von Objekten definiert. Die Anwendung kann derartige Methoden als einen Platzhalter nutzen, d. h. einen Dummy um seine eigenen SmartCard- Zugriffsprozeduren zu definieren, was wiederum ebenso vorteilhaft durch visuelle Programmiertechniken ausgeführt werden kann. Bei Nutzung des Prinzips, das in der anhängigen Beschreibung dargestellt wird, wird die aktuelle Implementierung der Schnittstelle zur Anwendungslaufzeit ausgeführt und ist spezifisch für jede der angewandten SmartCards. Somit ist die passende Implementierung von der aktuell genutzten SmartCard instantiell abhängig, um das betreffende Objekt zu serialisieren und in der SmartCard zu speichern oder von dieser wiederherzustellen.

In der obigen Spezifikation wurde die Erfindung in Bezug auf eine spezielle exemplarische Ausführungsform von ihr beschrieben. Es wird jedoch offensichtlich, dass unterschiedliche Modifikationen und Änderungen daran durchgeführt werden können, ohne von dem breiteren Sinn und Umfang der Erfindung abzuweichen, wie sie in den anhängigen Ansprüchen dargelegt werden. Die Spezifikation und Zeichnungen sind dementsprechend im illustrativen und nicht im restriktiven Sinn zu betrachten.

LISTE DER BEZUGSZEICHEN

6

Hostanwendung

7

,

8

SmartCards

9

Schnittstelle

10

,

12

Objekte

110-156

Vom erfindungsgemäßen Verfahren umfasste Schritte

Claims (11)

1. Verfahren zur Speicherung von Objekten (10, 12) in Vorrichtungen (7, 8) mit verringerten Ressourcen für die Unterstützung höherer Programmiersprachen, bei dem die Objekte sowohl einer Anwendung, die auf der Vorrichtung implementiert ist, als auch einer Hostanwendung (6) die auf einem Hostcomputer läuft, zugeordnet sind, wobei das Verfahren den folgenden Schritt umfasst:
Nutzung einer Schnittstelle (9) zwischen der Hostanwendung (6) und der Geräteanwendung, wobei die Schnittstelle den Objekten (10, 12) zugeordnet ist und Verfahren umfasst, die in der Lage sind, an den Attributen ausgeführt werden können, die den Objekten (10, 12) zugeordnet sind,
wobei das Verfahren durch den folgenden Schritt gekennzeichnet ist:
Nutzung einer erweiterten Form der Schnittstelle, die von einem hinzugefügten Serialisierungsitem herrührt, das die Serialisierung der Objekte (10, 12) in ein Format umfasst, das an solchen Vorrichtungen anwendbar ist.

2. Verfahren gemäß Anspruch 1, bei dem die Computergeräte mit verringerten Ressourcen (7, 8) SmartCards sind.

3. Verfahren gemäß Anspruch 1, bei dem die Serialisierung mit Java-Class-Technologie durch Bereitstellung eines serialisierenden BeanItems ausgeführt wird.

4. Verfahren gemäß einem der vorherigen Ansprüche, bei dem die Objekte (10, 12) vor dem Speichern der Objekte (10, 12) in einer TLV-formatierten Form gepackt und/oder komprimiert wurden.

5. Verfahren zur Wiederherstellung von Objekten (10, 12) von Vorrichtungen (7, 8) mit verminderten Ressourcen für höhere Programmierunterstützung, bei dem Objekte sowohl einer Anwendung, die in einer solchen Vorrichtung (7, 8) implementiert sind, als auch Hostanwendungen, die auf einem Hostcomputer laufen, zugeordnet sind, wobei das Verfahren den folgenden Schritt umfasst;
Nutzung einer Schnittstelle (9) zwischen der Hostanwendung (6) und der Geräteanwendung, wobei die Schnittstelle den Objekten (10,12) zugeordnet ist und Verfahren umfasst, die an den Attributen ausgeführt werden können, die den Objekten (10, 12) zugeordnet sind;
wobei das Verfahren durch den folgenden Schritt gekennzeichnet ist:
Nutzung einer erweiterten Form der Schnittstelle, die von einem hinzugefügten Deserialisierungs-Item kommt, das eine Deserialisierung der Objekte (10, 12) von einem Format umfasst, das an solchen Vorrichtungen (7, 8) anwendbar ist.

6. Verfahren gemäß Anspruch 5, bei dem die Vorrichtungen (7, 8) SmartCards sind.

7. Verfahren gemäß Anspruch 1, bei dem die Deserialisierung mit Java-Class-Technologie durch Bereitstellen eines De-serialisierenden BeanItem ausgeführt wird.

8. Verfahren gemäß einem der vorherigen Ansprüche, bei dem die Objekte nach der Widerherstellung von einer TLV- formatierten Form dekomprimiert und/oder ausgepackt werden.

9. Vorrichtung (7, 8) mit verringerten Ressourcen von höherer Programmierunterstützung, die die Objekte (10, 12) umfasst, die durch Nutzung des Verfahrens gemäß einem der vorherigen Ansprüche gespeichert wurden.

10. Vorrichtung (7, 8) gemäß dem vorherigen Anspruch, dadurch gekennzeichnet, dass diese Vorrichtung eine SmartCard ist.

11. Vorrichtung (7, 8) gemäß dem vorherigen Anspruch, dadurch gekennzeichnet, dass die Vorrichtung eine JAVA- kompatible SmartCard ist.