DE69835879T2

DE69835879T2 - Multifunktionschipkarte mit delegierungsmerkmal

Info

Publication number: DE69835879T2
Application number: DE69835879T
Authority: DE
Inventors: Barrington David Brighton EVERETT; James Stuart Bracknell MILLER; David Anthony Tunbridge Wells PEACHAM; Stephens Ian Broughton SIMMONS; Philip Timothy Radlett RICHARDS; Charles John VINER
Original assignee: Mondex International Ltd
Current assignee: Mondex International Ltd
Priority date: 1997-05-15
Filing date: 1998-05-14
Publication date: 2007-04-05
Anticipated expiration: 2018-05-15
Also published as: WO1998052159A3; JP2001527674A; AU7776898A; EP0985202A1; WO1998052159A2; EP0985202B1; DE69835879D1; JP4181641B2; US6220510B1

Description

HINTERGRUND DER ERFINDUNG
Chipkarten (Karten mit integrierter Schaltung) werden heute auf der Welt zunehmend für viele verschiedenen Zwecke verwendet. Eine Chipkarte (auch Smart-Karte genannt) hat gewöhnlich die Größe einer konventionellen Kreditkarte, die einen Computerchip enthält mit einem Mikroprozessor, einem Nur-Lese-Speicher (ROM), einem elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), einem RAM-Speicher (RAM), einem Eingabe/Ausgabemechanismus und anderen Schaltungsanordnungen zum Unterstützen des Betriebs des Mikroprozessors. Eine Chipkarte kann in ihrem Speicher eine einzelne Anwendung oder mehrere unabhängige Anwendungen enthalten. MULTOS^TM ist ein Mehranwendungsbetriebssystem, das, unter anderen Plattformen, auf Chipkarten ausgeführt wird und das Ausführen mehrerer Anwendungen auf der Karte selbst ermöglicht. Mit dem in der Chipkarte befindlichen Mehranwendungsbetriebssystem kann ein Kartenbenutzer viele in der Karte gespeicherten Programme (zum Beispiel Kredit/Debit-, E-Money/Elektronische-Geldbörse- und/oder Bonusanwendungen), unabhängig von der Art des Terminals (d.h. Geldautomat (ATM), Telefon und/oder POS) ausführen, in das die Karte zur Benutzung gesteckt wird.
In eine konventionelle Chipkarte mit einzelner Anwendung, wie z.B. eine Telefonkarte oder eine E-Cash-Karte, wird eine einzige Anwendung geladen, und die Chipkarte führt nur diese eine Anwendung aus, wenn sie in ein Terminal eingeführt wird. Beispielsweise könnte eine Telefonkarte nur zum Bezahlen eines Telefonanrufs verwendet werden und nicht als Kredit/Debitkarte. Wenn ein Kartenbenutzer es wünscht, dass ihm ausgestellte Einzel-Anwendungs-Chipkarten eine Reihe verschiedener Anwendungsfunktionen durchführen sollten, wie z.B. sowohl eine Geldbörsen- als auch eine Kredit/Debitfunktion, müsste der Kartenbenutzer mehrere tatsächliche Karten mit sich führen, was ziemlich umständlich und unpraktisch wäre. Wenn ein Anwendungsentwickler oder Kartenbenutzer es wünschen sollte, dass zwei verschiedene Anwendungen in Wechselwirkung stehen oder miteinander Daten austauschen sollten, wie z.B. eine mit einer Bonusanwendung für treue Flugkunden in Wechselwirkung stehende Geldbörsenanwendung, wäre der Kartenbenutzer gezwungen, während der Transaktion mehrere Karten abwechselnd in das kartenaufnehmende Terminal zu stecken bzw. abzuziehen, was die Transaktion schwierig, langwierig und unpraktisch machen würde.
Aus diesem Grund ist es vorteilhaft, mehrere Anwendungen in derselben Chipkarte zu speichern. Beispielsweise kann ein Kartenbenutzer sowohl eine Geldbörsenanwendung als auch eine Kredit/Debitanwendung auf derselben Karte haben, so dass der Benutzer die für einen Kauf zu benutzende Zahlungsart (mit elektronischem Geld oder mit Kreditkarte) auswählen könnte. Eine Chipkarte könnte mit mehreren Anwendungen versehen werden, wenn ausreichend Speicher vorhanden ist und sich in der Karte ein Betriebssystem befindet, das mehrere Anwendungen unterstützen kann.
Die größere Flexibilität und Leistung des Speicherns mehrerer Anwendungen auf einer einzelnen Karte bringen neue zu bewältigende technische Herausforderungen hervor betreffend die Unverfälschtheit und Sicherheit der Informationen (einschließlich Anwendungscode und assoziierte Daten), die zwischen der einzelnen Karte und dem Anwendungsanbieter ausgetauscht werden, sowie innerhalb des gesamten Systems bei der Kommunikation von Informationen zwischen Anwendungen.
Beispielsweise ermöglicht das Vorhandensein von mehreren Anwendungen auf derselben Karte den Datenaustausch zwischen zwei Anwendungen, während eine der Anwendungen ausgeführt wird. Wie oben angegeben, muss während der Ausführung einer Elektronische-Geldbörse-Anwendung eventuell auf ein Bonusprogramm für treue Flugkunden zugegriffen werden. Wenn Daten auf nichtsichere Weise zwischen Anwendungen übersendet werden, ist es für Dritte, die die Transaktion überwachen, vielleicht möglich, den Inhalt der übertragenen Daten oder sogar andere mit einer oder beiden der Anwendungen assoziierten persönlichen Daten zu ermitteln. Es wäre daher vorteilhaft, eine Anwendungsarchitektur und Speicherorganisation bereitzustellen, die Daten einer Anwendung vor der Entdeckung durch Dritte schützt, wenn sie mit anderen auf der Chipkarte vorhandenen Anwendungen ausgetauscht werden.
Dementsprechend ist es eine Aufgabe von erfindungsgemäßen Ausgestaltungen, eine Anwendungsarchitektur und Speicherorganisation bereitzustellen, die die Dateninteraktion zwischen Anwendungen mit höherer Sicherheit ermöglicht und den Zugriff auf mehrere Anwendungen während der Durchführung eines gewünschten Tasks oder einer gewünschten Funktion zulässt.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung sieht eine Application Abstract Machine (AAM) genannte Mehranwendungsarchitektur für eine Chipkarte und ein Verfahren zum Implementieren dieser Architektur vor. Die Verarbeitung mehrerer Anwendungen wird erreicht, indem für wenigstens eine Anwendung (die „erste Anwendung") ein Datenspeicherraum generiert wird, der wenigstens zwei Segmente aufweist, ein flüchtiges Speichersegment und ein nichtflüchtiges Speichersegment; Beginnen der Ausführung der Anweisungen der ersten Anwendung; Delegieren oder Wechseln der Ausführung von der ersten Anwendung an/auf die delegierte Anwendung und dadurch Speichern von Daten, die von der ersten Anwendung im mit der ersten Anwendung assoziierten logischen Datenspeicherraum erzeugt werden; Ausführen der Anweisungen der zweiten Anwendung; Abrufen der gespeicherten Daten und Abschließen der Ausführung der Anweisungen der ersten Anwendung mit diesen Daten.
Zusätzliche Delegierungsbefehle können von der zweiten Anwendung oder anderen nachfolgenden Anwendungen erteilt werden. Der delegierte Befehl wird von einer delegierten Anwendung auf die gleiche Weise wie ein von einem Terminal direkt erteilter Auswahlbefehl ausgelegt und daher führt jede Anwendung die Sicherheitsfunktionen auf der gleichen Ebene aus, als ob ein Terminal den Befehl erteilen würde.
Das flüchtige Speichersegment kann ferner in öffentliche („Public") und dynamische („Dynamic") Abschnitte getrennt werden. Daten können zwischen einer Mehrzahl von Anwendungen und/oder einem Terminal ausgetauscht werden, wenn sie in der öffentlichen Region des Datenspeichers gespeichert sind. Es ist möglich, die dynamische Speicherregion ausschließlich als temporären Arbeitsbereich für die spezifische Anwendung, die ausgeführt wird, zu verwenden.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Weitere Aufgaben, Merkmale und Vorteile der Erfindung gehen aus der folgenden, nur beispielhaft zu verstehenden, ausführlichen Beschreibung in Verbindung mit den Begleitfiguren hervor, die veranschaulichende Ausgestaltungen der Erfindung zeigen, wobei:
1 ein Blockdiagramm ist, das das Datenspeicherraumsegment und assoziierte Register für eine die AAM-Organisation verwendende Chipkartenanwendung illustriert;
2 ein Blockdiagramm ist, das den Codespeicher und die Datenspeicherräume für eine die AAM-Organisation verwendende Chipkartenanwendung illustriert;
3 ein Flussdiagramm ist, das die Schritte der Durchführung einer Anforderung für eine Delegierungsfunktion von einer Anwendung an eine andere illustriert;
4 ein Flussdiagramm ist, das die Schritte der Durchführung einer Rückdelegierungssteuerfunktion für eine Delegiertenanwendung an eine Delegatoranwendung illustriert;
5 ein Flussdiagramm ist, das die Schritte der Durchführung einer Delegator-ID-Anfrage-Anforderung einer Delegierungsfunktion illustriert;
6 ein Blockdiagramm des Chips einer Chipkarte ist, der erfindungsgemäß als Plattform verwendet werden kann; und
7A, 7B und 7C mehrere Delegierungsaufrufe zwischen drei Anwendungen illustrieren.
In den Figuren werden, wenn nicht anders angegeben, durchgehend die gleichen Bezugsnummern und -zeichen zum Bezeichnen gleicher Merkmale, Elemente, Komponenten oder Teile der illustrierten Ausgestaltungen verwendet. Darüber hinaus wird die gegenständliche Erfindung nun zwar in Bezug auf die Figuren ausführlich beschrieben, dies erfolgt aber in Verbindung mit den veranschaulichenden Ausgestaltungen. Es ist vorgesehen, dass an den beschriebenen Ausgestaltungen Änderungen und Modifikationen vorgenommen werden können, ohne vom wahren Umfang und Sinn der gegenständlichen Erfindung gemäß der Definition in den angehängten Ansprüchen abzuweichen.
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
Eine Ausgestaltung der vorliegenden Erfindung sieht ein Verfahren und eine Vorrichtung zum Verarbeiten einer Mehrzahl von Anwendungen mit in einer Chipkarte gespeicherten assoziierten Daten vor, auf die zugegriffen werden kann und die ausgeführt werden können. Eine in der Karte gespeicherte Anwendung kann von einem Terminal oder einem anderen Schnittstellengerät (IFD) oder einer anderen Anwendung ausgewählt werden. Jedem Anwendungsprogramm, das in der Chipkarte gespeichert ist, wird beim Ausführen ein vom Softwarecode des Programms (Anweisungen, die von einem auf der Chipkarte befindlichen Prozessor ausgeführt werden) organisierter Speicherraum und die assoziierten Daten alloziert, die die Anwendung speichert und während der Ausführung des Programms benutzt.
Zum Beispiel kann eine Mehranwendungskarte eine Geldbörsen-Anwendung oder eine E-Money-Anwendung und eine spezifische Treue-Anwendung wie eine Bonusanwendung für treue Flugkunden speichern. Jede Anwendung hat Softwarecode und assoziierte Daten zum Unterstützen der Ausführung dieses Softwarecodes. Jeder Anwendung wird beim Ausführen ein Speicherraum alloziert. In diesem Beispiel besteht eine Wechselwirkung zwischen den zwei in der Karte gespeicherten Anwendungen. Für jeden zum Tätigen eines Kaufs elektronisch ausgegebenen Dollar ist der Benutzer eventuell zu einer Vielflieger-Meile berechtigt, die von dem Vielflieger-Programm gespeichert und verarbeitet wird. Die Geldbörsen-Anwendung braucht sich des spezifischen in der Karte gespeicherten Treueprogramms nicht bewusst zu sein, sie kann stattdessen eine Anweisung zum Kommunizieren mit jedwedem in der Karte gespeicherten Treueprogramm enthalten. Das Treueprogramm erfordert Eingabedaten, die für den Betrag eines jeweiligen elektronischen Wertes repräsentativ sind, so dass es seine eigenen gespeicherten Daten von aktuellen Vielflieger-Meilen für den Benutzer der Karte aktualisieren kann.
Wenn zwei Anwendungen während derselben Transaktion miteinander kommunizieren müssen, wird eine Systemarchitektur zum Verarbeiten beider Anwendungen auf effiziente und sichere Weise benötigt. Ein Ansatz könnte ein Modell vom Windows-Typ sein, bei dem beide Anwendungen gleichzeitig laufen könnten. Gegenwärtig sind Chipkartenplattformen aber nicht leistungsstark genug zum effizienten gleichzeitigen Betreiben mehrerer Programme. Auch können übertragene Daten unerwünschtem Zugriff durch Dritte ausgesetzt sein. Zum Behandeln dieses Problems unterbrechen Ausgestaltungen gemäß der aktuellen Erfindung, die unten ausführlicher beschrieben werden, selektiv die Ausführung von Anwendungen auf sichere Weise. Dies lässt das Aufrechterhalten der Integrität der Daten der Anwendungen zu und erlaubt die beste Nutzung des verfügbaren Speicherplatzes in der Chipkarte.
Eine effiziente Architektur zum Verarbeiten mehrerer Anwendungen in einer Chipkarte ist als AAM-Architektur (AAM: Application Abstract Machine) bezeichnet und wird hierin beschrieben. Die AAM-Architektur gilt für jede beliebige Plattform, unabhängig von ihrer Hardware, und ermöglicht Entwicklern das Schreiben von Anwendungen zum Speichern in den Chipkarten, die über viele verschiedene Typen von Plattformen portabel sind (z.B. von verschiedenen Herstellern mit unterschiedlichen Prozessorkonfigurationen konstruierte Chipkarten), ohne dass Kenntnisse über die spezifische Hardware der Plattform benötigt werden.
Eine Application Abstract Machine (AAM), ein Begriff für die Speicherallozierung und Organisation für die von jeder Anwendung gespeicherten und benutzten Daten, wird für jede in der Chipkarte gespeicherte Anwendung erstellt, die vom Prozessor auf der Karte ausgeführt wird. Um Datenintegrität und -sicherheit zu gewährleisten, wenn Daten zwischen Anwendungen, die auf der Chipkarte ausgeführt werden, übertragen werden, darf jeweils nur eine Anwendung in der Chipkarte ausgeführt werden. Jede Anwendung hat einen Datenspeicherraum, der virtuell alloziert und auf die in den Chipkartenspeichern verfügbaren physikalischen Speicheradressen abgebildet wird. Daten werden dann zwischen zwei oder mehr Anwendungen innerhalb einer spezifischen Speicherstelle und auf eine Weise transferiert, die mit der Übertragung von Daten an ein externes Terminal oder eine externe Vorrichtung übereinstimmen, mit dem/der die Chipkarte in sicherer Wechselwirkung steht. Auf allgemeiner Ebene weist jeder für jede ausgeführte Anwendung generierte AAM-Raum zwei separate Adressbereiche auf, einen für den Programmcode selbst und einen für die Programmdaten, die von der Anwendung gespeichert und/oder verwendet werden. Der Programmdatenadressbereich ist effektiv in drei Segmente geteilt: ein statisches (Static-)Segment, ein dynamisches (Dynamic-)Segment und ein öffentliches (Public-)Segment, die in Verbindung mit 1 ausführlicher beschrieben werden. Wie oben angegeben, sind das statische, das dynamische und das öffentliche Segment logisch auf den physikalischen Speicher abgebildet; sie sind im Gegensatz zu physikalischen Speichersegmenten virtuelle Speichersegmente. Der AAM-Datenadressbereich wird vorzugsweise mit sieben verschiedenen Adressregistern und zwei Steuerregistern adressiert und verarbeitet.
1 zeigt ein veranschaulichendes Diagramm einer Allozierung von logischem Datenraum 101, die für eine in Verbindung mit der vorliegenden Erfindung verwendete Anwendung erstellt wurde. Der AAM-Datenteil 101 weist einen statischen Datenraum „Static" 103, einen öffentlichen Datenraum „Public" 105 und einen dynamischen Datenraum „Dynamic" 107 auf. Auch eine Reihe von Adressregistern sind abgebildet: das Static-Basisadressregister 109, das Static-Top-Adressregister 111, das Public-Basisadressregister 113, das Public-Top-Adressregister 115, das Dynamic-Basisadressregister 117, das Dynamic-Top-Adressregister 121 und das lokale Basisadressregister 119, das als lokaler Stackrahmenzeiger im dynamischen Datenraum dient, wenn die Anwendung ausgeführt wird. Die Adressregister können physikalische Speicheradressen enthalten, sie enthalten aber vorzugsweise Offsetadressen für die diversen Datenadressbereiche, um hardwareunabhängig zu sein. Ein Beispiel für den gesamten Adressbereich ist 64 Kilobyte, obwohl die Größe im Verhältnis zur anwendbaren Plattform und zur verfügbaren Speichergröße variiert. Die Register können auch in Betracht kommende Zeiger sein oder sie können auch jeder beliebige andere konventionelle Adressiermechanismus sein.
Im allozierten AAM-Datenraum 101 ist der statische Teil des Speichers nichtflüchtig (wie EEPROM) und wird nicht gelöscht, nachdem die Stromzufuhr zur Chipkarte unterbrochen wird, der dynamische Raum ist flüchtig (wie RAM) und wird eventuell gelöscht, nachdem die Stromzufuhr zur Karte unterbrochen wird, und der öffentliche Raum ist ebenfalls flüchtig (wie RAM). Eine Chipkarte kann Strom von einem Terminal erhalten, nachdem sie in das Terminal eingesetzt worden ist. Eine Chipkarte kann zwar eine Batterie zum weiteren Versorgen von Speicher und Schaltungsanordnung mit etwas Strom enthalten, flüchtiger Speicher wird aber meist gelöscht, nachdem die Chipkarte von ihrer Stromquelle entfernt worden ist.
Der definierte AAM-Datenraum hat in jedem Segment Bytes, die zusammenhängend sind, so dass Anwendungen Zeiger- und Offsetarithmetik durchführen können. Wenn beispielsweise die Segmentadressen „1515" und „1516" oder ein anderes Paar sequentieller Zahlen beide gültig und innerhalb desselben Segments vorhanden sind, dann adressieren sie benachbarte Bytes. Deshalb können in Registern gespeicherte Offsetwerte die Stelle einer gewünschten Speicheradresse bestimmen. Die Segmentadresse des ersten Bytes des statischen Segments ist null, so dass die Segmentadresse einer bestimmten Stelle innerhalb der statischen Region gleich ihrem Offset ist.
Zeiger zu anderen spezifischen Regionen des statischen Datenbereichs können in den statischen Daten gespeichert werden, weil die statische Region nichtflüchtig ist. Wenn zum Beispiel der Name des Kartenbenutzers im statischen Speicher einer Kredit-/Debitanwendung gespeichert ist, weiß die Anwendung, dass der Name des Kartenbenutzers immer an der 5. Speicherstelle über dem Anfangspunkt für den statischen Speicherteil gespeichert ist. Die Speicherstelle kann als SB [5] oder das 5. Byte über dem unteren Ende des statischen Bereichs notiert sein. Da der statische Speicher nichtflüchtig ist, wird er nicht nach jeder Transaktion gelöscht und die Anwendung kennt immer seine Stelle relativ zu den Adressregistern der statischen Segmente.
Andererseits ist die Segmentadresse einer beliebigen Stelle im dynamischen und im öffentlichen Segment nicht immer gleich einem spezifischen Offset vom Anfang des jeweiligens Segments, weil der Inhalt jener Segmente sich für jede Operation ändert. Die vierte Stelle im dynamischen Segment ist für jede von der Anwendung durchgeführte Operation verschieden. Die Adresse einer Speicherstelle des dynamischen oder öffentlichen Segments ist vorzugsweise nur für die Dauer der Operation eines Befehl-Antwort-Paares fest. Weil Segmentadressen in Dynamic oder Public nicht fest sind, können Anweisungen der MULTOS Executable Language (MEL)^TM (oder beliebige andere Programmanweisungen) Daten nicht ausschließlich mit Segmentadressen referenzieren. Stattdessen wird vorzugsweise eine mit Tag gekennzeichnete Adresse zum Identifizieren von Daten verwendet, die im Chipkartensystem aufgerufen, manipuliert, übertragen und/oder gespeichert werden sollen.
Eine mit Tag gekennzeichnete Adresse ist ein neunzehn Bit umfassender Wert, der aus einem Tag mit drei Bit (Adressregisternummer) und einem Offset mit sechzehn Bit besteht. Jedes der sieben Adressregister für den AAM-Datenraum enthält eine physikalische Segmentadresse. Zum Beispiel zeigen die Adressregister SB 109 und ST 111 auf die Grenzen des statischen Bereichs Static, die Adressregister PB 113 und PT 115 zeigen auf die Grenzen des öffentlichen Bereichs Public und die Adressregister DB 117 und DT 121 zeigen auf die Grenzen des dynamischen Bereichs Dynamic. Für jedes Segment zeigt das obere Register auf das Byte unmittelbar nach dem letzten gültigen Byte. Beispielsweise ist das letzte gültige Byte des statischen Bereichs ST[-1]. Register LB dient als Stackrahmenzeiger. Es zeigt auf eine Stelle im dynamischen Segment, um ein spezifisches Byte lokaler Daten für die Anwendung anzuzeigen, die aktuell ausgeführt wird.
In 1 enthält das allozierte statische Segment 103 die nichtflüchtigen Daten der Anwendung. Zu den statischen Daten zählen Daten, die mit jeder Anwendung für jede Transaktion assoziiert sind, wie der Name, die Kontonummer, der PIN-Wert und die Adresse des Kartenbenutzers. Statische Daten beinhalten auch variable Daten, die zur Verwendung in die Anwendung benutzenden zukünftigen Transaktionen gespeichert werden. Beispielsweise würden bei einer Geldbörsentransaktion die Daten des elektronischen Werts aus dem statischen Segment gelesen und später am Ende der Transaktion im statischen Segment gespeichert werden. Außerdem würden Transaktionsinformationsdaten oder verfügbare Kreditlimits im Fall einer Kredit-/Debitanwendung in den statischen Daten gespeichert werden.
Die statischen Daten werden unter Verwendung von Register SB (Static Base) und dem Register ST (Static Top) als Offsetregister adressiert. Diese Register enthalten den Offsetwert von einer physikalischen Adresse in einem Speicher auf der Chipkarte. Die einzelne Speicherstelle wird dann von diesen Ausgangspunkten wie SB[3] oder ST[-5] weiter versetzt. SB ist als null definiert und ST ist gleich der Größe der statischen Daten der Anwendung, die festgesetzt wird, wenn die Anwendung in die Chipkarte geladen wird. Das Mehranwendungsbetriebssystem stellt sicher, dass keine andere Anwendung die im statischen Segment einer jeweiligen Anwendung gespeicherten Daten lesen oder schreiben kann. Mithilfe von aktueller Technologie wird das statische Segment vorzugsweise auf einen EEPROM (elektrisch löschbarer programmierbarer Nur-Lese-Speicher) abgebildet, der nichtflüchtig ist.
Das dynamische Segment 107 enthält die flüchtigen oder temporären Daten der Anwendung. Zu den dynamischen Daten zählen Daten, die während der Ausführung einer Anwendung vorübergehend verwendet werden, wie z.B. in Rechnungen verwendete Zwischenwerte oder Arbeitsvariablen. Zum Beispiel kann eine Geldbörsenanwendung vorübergehend den Wert einer Transaktion speichern, um den Betrag des Werts in der Geldbörse zu verringern. Die temporären Daten werden weitgehend so verwendet, wie konventionelle Computerprogramme RAM zum Durchführen ihrer zugewiesenen Operationen verwenden. Das dynamische Segment ist vorzugsweise in zwei Teile geteilt, den Sitzungsdatenteil und den Stackdatenteil. Die Größe der Sitzungsdaten ist eine Konstante für jede Anwendung und wird ermittelt, wenn die Anwendung geladen wird. Der Stack enthält variable Daten, die für die jeweilige Transaktion, die durchgeführt wird, eindeutig sind. Der Stackdatenteil speichert Daten nach dem Last-in-First-out-Prinzip. Der Stack ist anfänglich leer, aber während der Ausführung der Anwendung dehnt er sich aus und schrumpft.
Die dynamischen Daten sind vom Register DB 117 bis zum Register DT 121 adressiert. Register LB 119 dient als lokaler Stackrahmenzeiger auf spezielle Speicherstellen im dynamischen Segment für Delegierungsbefehle oder Funktionsaufrufe. Register LB 119 wird zum Adressieren des obersten Rahmens verwendet, dem der Sitzungsdaten der aktuell ausgeführten Funktion. Register DT 121 dient als ein Adressenoffset für den Stackzeiger. Eine Dateneinheit von einem Byte am oberen Ende des Stacks ist als DT[-1] adressiert, das nächste Byte darunter ist mit DT[-2] adressiert und so weiter. Eine Push-Operation inkrementiert den relativen Wert von DT für jede Einheit auf im Stack und eine POP-Operation dekrementiert den relativen Wert von DT für jede Einheit im Stack. Beispielsweise befindet sich ein an DT[-5] befindliches Datenelement an DT[-6], nachdem eine zusätzliche Dateneinheit zum Stack hinzugefügt worden ist.
Wenn eine Anwendung ausgeführt wird, enthält das für diese Anwendung erstellte dynamische Segment auch die Sitzungsdaten der Anwendung, die beim Durchführen des/der zugewiesenen Task(s) oder Operation(en) verwendet werden. Das Mehranwendungsbetriebssystem stellt sicher, dass keine andere Anwendung die im dynamischen Segment einer jeweiligen Anwendung gespeicherten Daten lesen oder schreiben kann. Die Sitzungsdaten werden zu Beginn der Ausführung der Anwendung genullt. Stackdaten werden im Stack abgespeichert, wenn die Anwendung ein Task oder eine Operation an eine andere Anwendung delegiert.
Eine Delegierungsfunktion findet statt, wenn eine Anwendung eine andere Anwendung zum Verarbeiten eines Befehls auswählt, anstatt den Befehl selbst zu verarbeiten. Ein Beispiel für eine Delegierungsfunktion findet statt, wenn eine Delegatoranwendung einen Befehl erhält, den sie nicht erkennt oder für dessen Verarbeitung sie nicht programmiert ist. Die ausgewählte Anwendung sollte den Befehl nicht ablehnen und eine Fehlerantwort an das Schnittstellengerät (IFD) anlegen, sondern stattdessen den Befehl an den jeweiligen Empfänger oder die jeweilige delegierte Anwendung weiterleiten. Zum Durchführen einer Delegierung ruft der Delegator das Delegiertenprimitivum auf. Das Delegiertenprimitivum ist eine vom Mehranwendungsbetriebssystem erkannte Subroutine, die ausgeführt wird, wenn das Betriebssystem die Delegierungsanweisung interpretiert. Primitiva können als Teil des Betriebssystems selbst gespeichert werden, wobei sie beim Installieren des Betriebssystems als separate Routine geladen werden. Primitiva sind vorzugsweise in ausführbarer Sprache geschrieben, so dass sie schnell ausgeführt werden können, sie könnten aber auch in einer höheren Sprache geschrieben sein. Wenn ein Delegierungsbefehl ausgeführt wird, wird die Ausführung der delegierenden Anwendung angehalten und stattdessen die delegierte Anwendung ausgeführt. Die delegierte Anwendung generiert dann ihren eigenen Datenspeicherraum gemäß der AAM-Architektur. Die im öffentlichen Speicherraum der ersten Anwendung (im RAM gespeichert) gespeicherten Daten werden an den öffentlichen Speicherraum der zweiten Anwendung gesendet (der physikalisch der gleiche Speicher sein könnte, aber für jede Anwendung separat alloziert ist), so dass Daten zwischen den Anwendungen übertragen werden können. Der dynamische Speicherraum wird ebenfalls gemeinsam genutzt, obwohl Daten in einen Stack für den Delegator gespeichert werden und die anderen Teile initialisiert werden, bevor die delegierte Anwendung ausgeführt wird, weil die dynamischen Daten geheim sind.
In den meisten Fällen verarbeitet die delegierte Anwendung den Befehl genau so, als wäre der Befehl direkt von einem Schnittstellengerät gekommen. Wenn die delegierte Anwendung die Verarbeitung des Befehls abgeschlossen hat und eine Anwort in das allozierte öffentliche Speichersegment geschrieben hat, wird sie wie üblich beendet. Der Delegator nimmt dann die Ausführung an der Anweisungsadresse wieder auf, die der ausgeführten Anweisung folgt, die das Delegiertenprimitivum aufrief. Die bzw. auf die von der delegierten Anwendung generierte Antwort wird vom allozierten öffentlichen Speicherraum abgerufen oder zugegriffen. Die Delegatoranwendung kann wiederum einfach beendet werden, wodurch sie die Antwort zum Schnittstellengerät sendet, oder sie kann vor dem Beenden weiteres Verarbeiten durchführen.
Ein weiteres Beispiel einer Delegationsoperation tritt auf, wenn zwei Anwendungen Daten gemeinsam nutzen müssen. Wenn eine Anwendung A beim Verarbeiten eines Befehls B immer eine Dateneinheit N zurücksendet, dann kann eine andere Anwendung, die auch immer Dateneinheit N als Reaktion auf einen Befehl zurücksendet, die Funktion B an Anwendung A delegieren, um die Notwendigkeit für in der Chipkarte gespeicherte doppelte Codes zu verringern. Wenn beispielsweise eine PIN geprüft werden muss, bevor eine Anwendung ausgeführt wird, kann eine in der Karte gespeicherte Anwendung das „PIN-Funktion aufrufen" an eine PIN-Anwendung delegieren, die eine gespeicherte Universal-PIN für die Karte zurücksendet.
Vorzugsweise beginnt immer dann eine neue Sitzung, wenn das Schnittstellengerät (IFD), z.B. ein Terminal, eine Anwendung erfolgreich auswählt, selbst wenn die Anwendung schon vorher während der Transaktion ausgewählt wurde. Wenn ein Kartenbenutzer z.B. zu einem Terminal geht und zwanzig Dollar elektronisches Geld unter Verwendung einer Geldbörsenanwendung überweist, eine Kredit-/Debitanwendung mit dreißig Dollar belastet und dann wieder zehn Dollar unter Verwendung der Geldbörsenanwendung überweist, haben drei separate Sitzungen stattgefunden, obwohl während der gesamten Transaktion nur zwei Anwendungen benutzt wurden. Jedesmal, wenn eine Anwendung ein Task oder eine Funktion an eine andere Anwendung delegiert, behandelt die delegierte Anwendung die Delegierfunktion, als ob die Schnittstellengeräte die Anwendung zum Durchführen des Tasks oder der Funktion ausgewählt hätten. Das Durchführen einer Delegierungsfunktion wie unten beschrieben hat aber eine andere Wirkung auf Sitzungsdaten.
Die folgenden Beispiele helfen erläutern, wann die Sitzungsdaten initialisiert werden (d.h. gelöscht) und wann sie zur Verwendung in weiteren Operationen gespeichert werden. Wenn Anwendung A von einem Schnittstellengerät ausgewählt wird und vom Terminal Befehle X, Y und Z erhält, kann Anwendung A alle drei Befehle an Anwendung B delegieren. Beispielsweise können Delegierungen als Reaktion auf Delegierungsbefehle im Programmcode stattfinden. Bei beiden Anwendungen A und B werden die Sitzungs- und Stackdaten in ihren jeweiligen dynamischen Segmenten initialisiert (genullt), wenn sie Befehl X erhalten, aber der Stack wird nicht initialisiert, wenn sie die nachfolgenden Befehle Y und Z erhalten.
In einem zweiten Beispiel ist Anwendung A ausgewählt und erhält Befehle X, Y und Z vom Terminal. Anwendung A verarbeitet X selbst, delegiert aber Y und Z an Anwendung B. Die Sitzungs- und Stackdaten von Anwendung A werden initialisiert, wenn sie X erhält, aber nicht, wenn sie die nachfolgenden Befehle Y und Z erhält. Die Sitzungs- und Stackdaten von Anwendung B werden initialisiert, wenn sie Y erhält, aber nicht Z.
Ein Beispiel für die Verwendung von Sitzungsdaten ist das Unterstützen der Verwendung einer Sitzungs-PIN (PIN: persönliche Identifikationsnummer). Die Anwendung könnte einen Byte von Sitzungsdaten zum Unterstützen des PIN-Erhalt-Flag reservieren. Nach Erhalt des PIN-Prüfbefehls könnte die ausgewählte delegierte Anwendung das Flag wie folgt aktualisieren: wenn der PIN-Befehl erhalten wurde und die eingegebene PIN gleich der gespeicherten PIN ist, dann setzt sie die Sitzungsdaten DB[0] auf 1. Wenn nicht, prüft die Anwendung, ob das PIN-Flag bereits gesetzt ist, indem sie den Wert in DB[0] prüft. In beiden der obigen Fälle verarbeitet die Anwendung den Rest der Befehle in der Sitzung, weil die PIN verifiziert wurde. Wenn keiner der Fälle wahr ist, dann verarbeitet die Anwendung den Befehl nicht, weil die PIN nicht richtig ist. Die PIN-Prüffunktion könnte eine von der ausgewählten Anwendung an eine PIN-Prüfanwendung delegierte Funktion sein.
Das öffentliche Segment 105 wird für zwischen einem Schnittstellengerät und einer Anwendung übertragene Befehls- und Antwortdaten verwendet. Während eines Delegierungsbefehls enthält das öffentliche Segment die zwischen zwei Anwendungen übertragenen Daten, den Delegator (die die Delegierung einleitende Anwendung) und die delegierte Anwendung (die Anwendung, die die delegierte Funktion durchführt). Erforderlichenfalls kann eine Anwendung das öffentliche Segment auch als weiteren temporären Arbeitsspeicherbereich benutzen. Die öffentlichen Daten werden mit Offsets registriert, die im Register PB 113 als Startadresse bis Register PT 115 als Endadresse gespeichert werden. Register PB 113 und Register PT 115 sind für die Dauer eines vom Schnittstellengerät oder Delegator eingeleiteten Befehl-Antwort-Paares fest. Öffentliche Daten können in ein Terminal eingegebene oder von einem Terminal zugeführte Daten sein, wie ein Transaktionsbetrag, Verkäuferidentifikationsdaten, Terminalinformationen, Übertragungsformat oder sonstige Daten, die von einer auf der Chipkarte befindlichen Anwendung benötigt oder benutzt werden. Öffentliche Daten können auch Daten aufweisen, die an ein Schnittstellengerät oder eine andere Anwendung zu senden sind, wie z.B. ein elektronischer Dollarwert, Übertragungsformatdaten für Kartenbenutzerinformationen oder sonstige Daten, die vom Terminal oder einer anderen delegierten Anwendung benötigt oder verwendet werden.
Das Mehranwendungsbetriebssystem gewährleistet, dass die im öffentlichen Segment gespeicherten Daten nur der Anwendung bekannt bleiben, bis die Anwendung verlassen wird oder delegiert. Vorzugsweise werden die Daten im öffentlichen Segment dann anderen Entitäten wie folgt verfügbar gemacht: (1) wenn die Anwendung delegiert, wird das ganze öffentliche Segment für die delegierte Anwendung verfügbar; (2) wenn die Anwendung beendet wird und selbst von einer anderen delegiert wird, dann wird das ganze öffentliche Segment für den Delegator verfügbar; oder (3) wenn die Anwendung beendet wird und nicht selbst delegiert wird, dann wird ein Teil des öffentlichen Segments, der die E/A-Antwortparameter und -daten enthält, für das Schnittstellengerät verfügbar gemacht.
Eine Anwendung kann während der Ausführung der Anwendung geheime Daten in das öffentliche Speichersegment schreiben, die Anwendung muss aber sicherstellen, dass sie den geheimen Teil des öffentlichen Segments überschreibt, bevor sie delegiert oder beendet wird. Wenn die Anwendung abnormal endet (abstürzt), dann überschreibt das Betriebssystem auf der Chipkarte vorzugsweise automatisch alle Daten im öffentlichen Segment, so dass keine unerwünschten Entitäten Zugriff auf die geheimen Daten haben können. Wenn die MULTOS-Trägervorrichtung (MCD: MULTOS Carrier Device) rückgesetzt wird, überschreibt das Betriebssystem automatisch Daten im öffentlichen Segment, so dass keine geheimen Daten aufgedeckt werden. Ein Teil des öffentlichen Speichersegments wird auch als Kommunikationspuffer verwendet. Die E/A-Protokolldaten und -parameter werden vorzugsweise am oberen Ende des öffentlichen Speicherraums gespeichert. In einer weiteren bevorzugten Ausgestaltung sind die obersten siebzehn Bytes für das Kommunikationsprotokoll zwischen dem Schnittstellengerät und der Chipkartenanwendung reserviert. Es können aber auch zusätzliche oder weniger Bytes verwendet werden, je nach der/dem genutzten jeweiligen Anwendung und Betriebssystem.
Die zwischen den Speichersegmenten in 1 gezeigten Zwischenräume variieren je nach der/den spezifischen Anwendung und Befehlen, die verarbeitet werden. Zwischen den Speichersegmenten könnte es auch keinen Speicherraum geben, so dass die Speichersegmente zusammenhängend sind.
2 zeigt eine erweiterte Darstellung der AAM-implementierten Architektur. Datenspeicherraum 201 weist die drei Segmente Static, Public und Dynamic auf, wie bereits beschrieben. Codespeicherraum 203 enthält die Programmanweisungen für eine in der Chipkarte gespeicherte Anwendung. Die Anwendungsanweisungen werden vorzugsweise in einer ausführbaren Form gespeichert, die vom residenten Betriebssystem interpretiert werden kann, sie können aber auch in maschinenausführbarer Form gespeichert werden. Anweisung 205 ist an einer Stelle im Codespeicherraum 203 gespeichert. Zusätzliche Anweisungen sind an anderen Stellen von Speicherraum 203 gespeichert. Zwei zusätzliche Register 207 und 209 werden in der AAM-Architektur verwendet. Ein Codezeiger-(CP)-Register 207 zeigt die jeweilige als nächstes auszuführende Codeanweisung an. In der Figur zeigt das Register, z.B. durch ein Offset oder einen Zeiger, an, dass Anweisung 205 als nächstes ausgeführt werden wird. Bedingungssteuerregister (CCR: Condition Control Register) 209 enthält acht Bit, von denen vier zur Verwendung durch die individuelle Anwendung sind und vier in Abhängigkeit von den Ergebnissen der Ausführung einer Anweisung gesetzt oder gelöscht werden. Diese Bedingungscodes können von bedingten Anweisungen wie Verzweigung, Aufruf oder Sprung verwendet werden. Die Bedingungscodes können ein Übertragbit, ein Überlaufbit, ein negatives Bit und ein Nullbit aufweisen.
Alle Adress- und Steuerregister werden vor dem Ausführen der ausgewählten oder delegierten Anwendung auf definierte Werte gesetzt. Die Werte werden entweder dann gesetzt, wenn die Anwendung erst in die Karte geladen wird und die Größe des Codes und der nichtflüchtigen Daten festgestellt werden kann, oder in dem Moment, wenn die Anwendung die Steuerung an die Anwendung übergibt. Wenn die Anwendung geladen ist, ist SB auf null gesetzt und ST ist gleich der Zahl von Bytes in der Static-Datenbank der Anwendung. Die anderen Adressregister werden initialisiert, wenn die Anwendung die Steuerung erhält. Zu Beginn der Ausführung der Anwendung wird CP 207 genullt und alle acht Bits in CCR 209 werden gelöscht.
Zwischen dem Schnittstellengerät und einer Anwendung ist ein Kommunikationsschnittstellenmechanismus vorhanden, der die Verwendung des öffentlichen Datensegments als Kommunikationspuffer für Befehl-Antwort-Parameter beinhaltet. Ein Befehl-Antwort-Parameter bedeutet, dass einer Anwendung ein durchzuführender Befehl erteilt wird und sie eine Antwort an die den Befehl ausstellende Entität sendet. Anwendungen stehen mit einem Schnittstellengerät (IFD) in Wechselwirkung, indem sie über die IFD-Anwendungsschnittstelle Befehle erhalten, sie verarbeiten und Antworten zurücksenden. Wenn eine Anwendung die Ausführung eines Befehls abgeschlossen hat, legt die Anwendung die Antwort an PB[0] beginnend in das öffentliche Segment, das vom Schnittstellengerät gelesen werden kann, und setzt die richtigen Schnittstellenparameter im reservierten öffentlichen Raum relativ zu PT[0].
Eine Anwendung kann zwar direkt von einem Schnittstellengerät aufgerufen werden und eine Antwort direkt an ein Schnittstellengerät zurücksenden, sie kann aber auch, falls angebracht, eine Anforderung an eine andere Anwendung delegieren. Die anschließend aufgerufene Anwendung verarbeitet dann den Befehl im Auftrag der ersten Anwendung. Die Delegierung kann direkt als Reaktion auf einen erhaltenen Befehl erfolgen, wobei der Delegator als Steuerung zum Delegieren von Befehlen oder Unterbefehlen an andere zutreffende Anwendungen agiert. Alternativ kann der delegierte Befehl in einen Anwendungscode eingebettet sein, der die Steuerung des Prozessors delegiert, wenn die erste Anwendung während ihrer Ausführung mit einer weiteren Anwendung in Wechselwirkung stehen muss, wie z.B. Aktualisieren von Vielfliegermeilen oder Verifizierung einer PIN.
3 zeigt ein Ablaufdiagramm der Schritte, die ausgeführt werden, wenn eine Delegierungsanforderung ausgeführt wird. Schritt 301 setzt den delegator_application_ID (Delegator-ID) genannten Parameter, so dass er mit der selected_file.application_ID (ausgewählte ID) gleich ist. Die ausgewählte ID zeigt die aktuelle Anwendung an, die ausgewählt ist und die aktuell ausgeführt wird. Die Delegator-ID zeigt die Anwendung an, die eine Funktion an eine andere in der Chipkarte gespeicherte delegierte Anwendung delegiert. Schritt 303 fügt die Delegator-ID dann oben zum delegate_ID_stack (Delegierstack) hinzu (speichert sie). Die im Dynamic-Teil des allozierten Speichers referenzierten Daten werden gespeichert, so dass die aktuelle Anwendung ihre Ausführung abschließen kann, nachdem die delegierte Funktion abgeschlossen worden ist. Daten, die mit der delegierten Anwendung gemeinsam genutzt werden sollen, werden im Public-Teil des allozierten Speichers referenziert. Der delegierte Stack wird vorzugsweise außerhalb des AAM-Speicherraums einer Anwendung gespeichert und verfolgt, welche Anwendungen Funktionen delegiert haben. Jede Anwendung wird angehalten, wenn sie eine Funktion delegiert, damit der Delegierstack auf Last-In-First-Out-(LIFO-)Weise funktionieren kann, so dass, wenn eine Anzahl von Anwendungen auf Grund von Delegierungsanforderungen angehalten wurden, die richtige Anwendung in der richtigen Reihenfolge gestartet wird. Der Delegiertenstack behält so im Auge, welche Anwendung der letzte Delegator war, wenn mehrere geschichtete Delegierungsfunktionen durchgeführt werden. Der Delegierstack arbeitet zwar vorzugsweise nach dem LIFO-Verfahren, zutreffenderweise könnten aber auch andere Stacksysteme verwendet werden.
Schritt 305 setzt dann die ausgewählte ID auf den Wert delegate_request.delegate_application_id (Delegierungs-ID-Wert). Dieser Schritt wählt die Anwendung aus, die zum Durchführen der delegierten Funktion oder Funktionen aufgerufen werden wird. Die Identitäten der delegierten Anwendung können von der Delegatoranwendung spezifisch aufgerufen werden oder eine spezielle Funktion kann mit einer Anwendung in einer Lookup-Tabelle zusammengepasst werden. Zum Beispiel kann eine PIN-Abstimmungsoperation an verschiedene Anwendungen delegiert werden, je nachdem, welche Anwendungen auf der Karte vorhanden sind. Schritt 307 setzt dann den Anwendungsbefehlsparameter application_command auf den im Parameter delegate_request.application gespeicherten Wert. Dieser Schritt spezifiziert den an die Delegierungsanwendung zu delegierenden Befehl. Anwendungen haben meist die Fähigkeit, viele verschiedene Befehle zu verarbeiten. Alternativ könnte die gesamte Anwendung zum Durchführen von einer Funktion oder mehreren Funktionen ausgeführt werden. Die Delegatoranwendung kann wählen, welchen Befehl sie an eine andere Anwendung delegiert. Schritt 309 sendet dann den Anwendungsbefehl application_demand an das AAM-Betriebssystem zur Ausführung durch die Delegiertenanwendung. Die Delegatoranwendung wird dann angehalten (oder unterbrochen). Alle Daten, die zwischen Anwendungen übertragen werden müssen, werden über den öffentlichen Speicherraum transferiert.
4 ist ein Ablaufdiagramm der Schritte zum Durchführen eines Befehls zur „Rückdelegierungssteuerung" durch die Delegiertenanwendung. Dieser Befehl wird vom Betriebssystem ausgeführt, wenn eine delegierte Anwendung ihre delegierte Funktion abgeschlossen hat. Schritt 401 erhält Anwendungsantworten application_responses aus dem öffentlichen Speicherraum der delegierten AAM. Die Antwortdaten werden in das öffentliche Speichersegment der Delegierten-AAM geleitet. Schritt 403 setzt dann die Antwortstatusvariable delegate_response.status auf eine Erfolgsbedingung. Das bedeutet, dass eine Delegierungsoperation erfolgreich abgeschlossen wurde. Schritt 405 setzt den Parameter delegate_response.application_responses auf die Anwendungsantwortwerte (application_responses), die im öffentlichen Segment der Delegiertenanwendung gespeichert waren.
Schritt 407 setzt den Parameter delegate_response.delegate_application_id auf selected_file.application_id (die Delegiertenanwendungs-ID). Schritt 409 holt die oberste delegate_application_id (i.e. liest die zuletzt im Stack gespeicherten Daten) von delegate_id_stack. Diese Information zeigt die Identität der Delegatoranwendung für den Befehl an, der gerade delegiert und von der delegierten Anwendung abgeschlossen wurde. Schritt 411 setzt den Wert select_file.application_id auf den Wert delegator_application_id. Das wählt die Delegatoranwendung aus, die vom Delegierten-ID-Stack als die aktuelle Anwendung identifiziert wurde, die wieder abzulaufen beginnen wird. Die dynamischen Daten für die Delegatoranwendung werden für die Delegatoranwendung aus ihrer gespeicherten Stelle abgerufen, so dass die Anwendung mit allen Daten intakt dort weiter ausgeführt werden kann, wo sie aufhörte, aber auch die Antwortinformation von der delegierten Funktion haben wird. In Schritt 413 werden die Delegierungsantwortdaten delegate_response zur weiteren Verarbeitung an die aktuelle Anwendung gesendet. Die Antwortdaten werden durch den öffentlichen Datenraum geleitet, der dieselbe physikalische RAM-Speicherstelle sein könnte, weil alle Anwendungen den physikalischen flüchtigen Speicherraum gemeinsam nutzen.
5 zeigt ein Ablaufdiagramm der Schritte, die an Anfragen über eine Delegator-ID beteiligt sind, wenn eine delegierte Anwendung einen Delegierungsbefehl erhält. Die delegierte Anwendung muss eventuell die Identität des Delegators kennen, weil sie eventuell Operationen für verschiedene Delegatoranwendungen verschieden durchführt. Beispielsweise muss ein Treueprogramm einer Fluggesellschaft eventuell wissen, ob die Vielfliegerbonuszuteilung auf den tatsächlichen verarbeiteten Dollar-Beträgen oder einer Pauschalbetragszuteilung für eine andere Tätigkeit wie das Durchführen einer Rechnungsbezahlungsoperation basieren wird. Diese Information könnte als eine Variable an die delegierte Anwendung übertragen werden oder sie könnte mithilfe einer Anfrage ermittelt werden. Die Delegatoranfrageoperation könnte als ein Primitivum implementiert sein, wie bereits beschrieben.
Schritt 501 erhält die Aufforderung delegator_id_enq_request vom AAM-Betriebssystem. Die Aufforderung dient zum Feststellen der Identität des Delegators. Schritt 503 prüft, ob der Delegierten-ID-Stack delegate_id_stack leer ist. Wenn der Stack leer ist, dann haben keine Delegierungsoperationen stattgefunden und es wurden keine Anwendungen angehalten. Schritt 511 setzt daher den Zustandsparameter delegator_id_enq_response.status auf einen Fehleranzeiger. Schritt 513 setzt dann den Wert von delegator_is_enq_request.error_cause (Anforderung der Fehlerursache) auf einen Wert, der „keine Delegatoranwendung" andeutet. Es gibt keine Delegatoranwendung. Der Prozess fährt dann mit Schritt 509 fort.
Wenn der Delegierten-ID-Stack nicht leer ist, dann hat wenigstens eine Delegation stattgefunden. In diesem Fall setzt Schritt 505 den Zustandsparameter delegator_id_enq_response.status auf einen Wert, der „Erfolg" anzeigt. Schritt 507 setzt dann den Parameter delegator_id_enq_response.delegator_application_id auf den in delegate_id_stack.delegator_application_id gespeicherten Wert. Dies setzt die Anfrageantwort so, dass sie die oberste Delegatoranwendungskennung des Stacks anzeigt. Wie oben erläutert, zeigen die gespeicherten Daten am oberen Ende des Stacks die Delegatoranwendung an, die zuletzt eine Delegierungsfunktion aufgerufen hat. Schritt 509 sendet dann die Antwort auf die Delegator-ID-Anfrage delegator_id_enq_response an das AAM-Betriebssystem zurück, das die Information an die die Information anfordernde Anwendung oder IFD-Entität liefert.
6 zeigt ein Beispiel für ein Blockdiagramm einer gedruckten Schaltung, die sich auf einem Chipkartenchip befindet, der in Verbindung mit der Erfindung verwendet werden kann. Der IC-Chip befindet sich auf einem Chip auf der Karte. Der IC-Chip weist vorzugsweise eine Zentraleinheit 601, einen RAM 603, einen EEPROM 605, einen ROM 607, einen Timer 609, Steuerlogik 611, Ein-/Ausgabeports 613 und eine Sicherheitsschaltungsanordnung 615 auf, die durch einen konventionellen Datenbus 617 oder ein anderes konventionelles Mittel miteinander verbunden sind.
Steuerlogik 611 in der Smart-Karte stellt ausreichendes Sequentialisieren und Schalten zum Abwickeln von Lese-Schreib-Zugang zum Kartenspeicher durch die Eingabe-/Ausgabeports 612 bereit. CPU 601 in Verbindung mit Steuerlogik 611 kann viele verschiedene Funktionen durchführen, darunter die Durchführung von Rechnungen, Zugriff auf Speicherstellen, Modifizieren von Speicherinhalten und Verwalten von Eingabe-/Ausgabeports. Einige Chipkarten können auch einen Coprozessor zum Abwickeln komplexer Rechenvorgänge wie kryptografischen Algorithmen aufweisen. Eingabe-/Ausgabeports 613 werden für die Kommunikation zwischen der Karte und einem Schnittstellengerät (IFD) verwendet, das Informationen zu und von der Karte überträgt. Timer 609 (der einen Taktimpuls erzeugt und/oder anlegt) steuert die Steuerlogik 611, die CPU 601 und andere ein Taktsignal benötigende Komponenten durch die Sequenz von Schritten an, die Funktionen wie Speicherzugang, Speicherlesen und/oder -schreiben, Verarbeiten und Datenkommunikation ausrichten. Sicherheitsschaltungsanordnung 615 (die fakultativ ist) weist vorzugsweise Schmelzsicherungen auf, die die Eingabe-/Ausgabeleitungen mit internen Schaltungsanordnungen verbinden, wie es zum Testen während der Herstellung erforderlich ist, die aber nach Beendigung der Prüfungen zerstört werden, um späteren Zugang zu verhindern. Der statische Speicherraum wird vorzugsweise auf Speicherstellen im EEPROM 605 abgebildet, der nichtflüchtig ist. Der dynamische Speicherraum wird vorzugsweise auf RAM 603 abgebildet, der ein flüchtiger Speicher mit Schnellzugriff ist. Der öffentliche Speicherraum wird vorzugsweise ebenfalls auf RAM 603 abgebildet, der ein flüchtiger Speicher ist. Die dynamischen Daten und die öffentlichen Daten werden in verschiedenen Teilen von RAM 603 gespeichert, wobei RAM als ein bevorzugter nichtflüchtiger Speicher identifiziert ist und EEPROM als ein bevorzugter flüchtiger Speicher identifiziert ist. Andere Speichertypen könnten ebenfalls mit denselben charakteristischen Eigenschaften verwendet werden.
7A, 7B und 7C illustrieren ein Beispiel für eine Delegierungsfunktion, die durchgeführt wird, um mehrere Anwendungen in einer Chipkarte zu verarbeiten. 7A zeigt eine erste Anwendung, die ausgeführt wird, wie durch einen doppelt umzirkelten Kreis 701 bezeichnet wird. An einem Punkt während der Ausführung der ersten Anwendung wird eine Delegierungsfunktion 702 zum Delegieren einer Operation an die zweite Anwendung aufgerufen, die von Kreis 703 angezeigt wird. In 7A wird auch ein leerer Delegator-ID-Stack 705 gezeigt. Da der Stack leer ist, gibt es keine damit assoziierten Daten und er wird nur zu veranschaulichenden Zwecken gezeigt.
Das Mehranwendungsbetriebssystem erhält den Delegierungsbefehl und unterbricht die Ausführung der ersten Anwendung 701 und übergibt die Steuerung der integrierten Schaltung an Anwendung 703, wie in 7B gezeigt. Die Ausführung der zweiten Anwendung 703 ist mit einem doppelt umzirkelten Kreis dargestellt. Der Begriff „übergibt die Steuerung" bedeutet, dass der Mikroprozessor und andere Schaltungen auf der Karte die Anweisungen verarbeiten und Speicherraum für die Anwendung, die delegiert wird, allozieren werden. Wenn der Delegierungsbefehl verarbeitet ist, wird die Delegator-ID 707 dem Stack 705 am oberen Ende hinzugefügt. Der Delegator-ID-Stack wird auf LIFO-Weise betrieben. In 7B wird auch eine dritte auf der Karte befindliche Anwendung 709 gezeigt. An einem Punkt während der Ausführung der zweiten Anwendung wird eine Delegierungsfunktion 711 zum Delegieren der Operation an die dritte Anwendung aufgerufen.
Das Mehranwendungsbetriebssystem erhält den in 7B gezeigten Delegierungsbefehl 711, unterbricht die Ausführung der zweiten Anwendung 703 und übergibt die Steuerung der integrierten Schaltung an die dritte Anwendung 709, wie in 7C gezeigt. Wenn der Delegierungsbefehl verarbeitet ist, wird die Delegator-ID 713 der zweiten Anwendung dem oberen Ende des Delegator-ID-Stacks 705 hinzugefügt. Die Delegator-ID 707 der ersten Anwendung, deren Ausführung noch unterbrochen ist, wird in Übereinstimmung mit einer LIFO-Stackverwaltung im Stack nach unten geschoben. Wenn daher die dritte Anwendung ihre Ausführung beendet hat, wird die Delegator-ID am oberen Ende des Stacks vom Stack geholt und entfernt, um anzuzeigen, dass die Ausführung der zweiten Anwendung zuerst wiederaufzunehmen ist. Die Delegator-ID 707 von der ersten Anwendung ist dann zuoberst auf dem Stack, so dass, wenn die Ausführung der zweiten Anwendung beendet ist, die erste Anwendung ihre Ausführung wiederaufnimmt.
Zusätzliche Anwendungen können auf ähnliche Weise vom Delegator-ID-Stack verwaltet werden. Indem die Ausführung der Anwendungen unterbrochen wird, wenn ein Delegierungsbefehl verarbeitet wird, und die Delegationsreihenfolge im Auge behalten wird, können die Sicherheit und Integrität der Daten für jede einzelne Anwendung aufrecht erhalten werden, was wichtig ist, weil Chipkarten für Kartenbenutzer persönliche Daten für Anwendungen speichern, wie Kontonummern, Sozialversicherungsnummer, Adresse und andere Privatinformationen.

Claims

Chipkarte, die Folgendes umfasst: einen Mikroprozesor, einen mit dem genannten Mikroprozessor verbundenen flüchtigen Speicher; einen mit dem genannten Mikroprozessor verbundenen nichtflüchtigen Speicher und eine Mehrzahl von in dem genannten nichtflüchtigen Speicher gespeicherten Anwendungen, wobei der genannte Mikroprozessor beim Ausführen jeder genannten Anwendung für jede genannte laufende Anwendung einen assoziierten Datenspeicherraum alloziert, der wenigstens ein flüchtiges Speichersegment zum Referenzieren von temporären Daten und ein nichtflüchtiges Speichersegment zum Referenzieren statischer Daten umfasst; und wobei jedes genannte flüchtige Speichersegment in wenigstens zwei Regionen unterteilt ist, einschließlich einer öffentlichen Region und einer dynamischen Region, wobei jede genannte öffentliche Region zum Austauschen von Daten zwischen einer laufenden Anwendung und einer Schnittstelle und zum Austauschen von Daten zwischen Anwendungen verwendbar ist und wobei jede genannte dynamische Region nur von der spezifischen laufenden Anwendung gelesen oder beschrieben werden kann; und die ferner ein Mittel zum Delegieren der Leistung einer Funktion von einer ersten laufenden Anwendung an eine zweite laufende Anwendung umfasst, indem ein Delegierungsbefehl ausgeführt wird und Daten aus der öffentlichen Region der ersten Anwendung zur öffentlichen Region der zweiten Anwendung gesendet werden.
Chipkarte nach Anspruch 1, bei der die genannte dynamische Region zum Referenzieren von temporären Daten verwendet wird, die während der Ausführung einer Anwendung genutzt werden.
Chipkarte nach Anspruch 1, die ferner wenigstens ein mit dem genannten Mikroprozessor verbundenes Register umfasst, das zum Ermitteln der Ausgangsorte jedes der genannten Segmente verwendet wird.
Chipkarte nach Anspruch 3, die ferner wenigstens ein mit dem genannten Mikroprozessor verbundenes Register umfasst, das zum Ermitteln der obersten Orte jedes der genannten Segmente verwendet wird.
Chipkarte nach Anspruch 4, die ferner wenigstens ein mit dem genannten Mikroprozessor verbundenes Register umfasst, das als lokaler dynamischer Zeiger verwendet wird.
Chipkarte nach Anspruch 1, bei der jede genannte Anwendung eine Mehrzahl von Programmanweisungen umfasst und bei der wenigstens eine der genannten Programmanweisungen, wenn sie ausgeführt wird, Zugriff auf den von dem genannten flüchtigen Speichersegment referenzierten Speicher verursacht.
Chipkarte nach Anspruch 1, bei der das genannte flüchtige Speichersegment RAM referenziert und das genannte nichtflüchtige Speichersegment EEPROM referenziert.
Chipkarte nach Anspruch 1, die ferner Mittel aufweist zum Speichern eines mit der genannten ersten Anwendung assoziierten Kennzeichners in einem Datenstapel.
Chipkarte nach Anspruch 8, die ferner Mittel aufweist zum Abfragen des genannten mit der genannten ersten Anwendung assoziierten Kennzeichners.
Chipkarte nach Anspruch 1, die ferner Mittel aufweist zum Delegieren der Leistung einer Funktion von der genannten zweiten Anwendung an eine dritte in der genannten Chipkarte gespeicherten Anwendung.
Verfahren zum Verarbeiten einer Mehrzahl von in einem Speicher einer integrierten Schaltung gespeicherten-Anwendungen, das die folgenden Schritte umfasst: Auswählen einer ersten Anwendung zur Ausführung; Allozieren eines Datenraumes für die genannte erste Anwendung, der wenigstens zwei Speichersegmente aufweist, die ein erstes flüchtiges Speichersegment zum Referenzieren temporärer Daten und ein erstes nichtflüchtiges Speichersegment zum Referenzieren statischer Daten umfasst, wobei das genannte erste flüchtige Speichersegment eine öffentliche Region und eine dynamische Region aufweist, wobei die öffentliche Region zum Austauschen von Daten zwischen einer laufenden Anwendung und einer Schnittstelle und zum Austauschen von Daten zwischen Anwendungen benutzbar ist und die dynamische Region andere temporäre Daten referenziert, die nur von den Anwendungen gelesen oder geschrieben werden können; Ausführen der genannten ersten Anwendung; Unterbrechen der Ausführung der genannten ersten Anwendung durch Ausführen eines Delegierungsbefehls in der ersten Anwendung; Sichern von vom genannten ersten flüchtigen Speichersegment referenzierten Daten; Allozieren eines Datenraumes für eine zweite Anwendung, der wenigstens zwei Speichersegmente aufweist, die ein zweites flüchtiges Speichersegment zum Referenzieren temporärer Daten und ein zweites nichtflüchtiges Speichersegment zum Referenzieren statischer Daten umfasst, wobei das zweite flüchtige Speichersegment eine öffentliche Region und eine dynamische Region umfasst; Senden von Daten von der öffentlichen Region der ersten Anwendung zu der öffentlichen Region der zweiten Anwendung; Ausführen der genannten zweiten Anwendung; Nutzen der genannten gesicherten Daten vom genannten flüchtigen Speichersegment zum Ausführen der genannten ersten Anwendung und Vervollständigen der genannten Ausführung der genannten ersten Anwendung.
Verfahren nach Anspruch 11, bei dem die Identität der genannten ersten Anwendung während des genannten Delegierungsschrittes in einem Datenstapel gespeichert wird.
Verfahren nach Anspruch 12, bei dem auf die genannte Vervollständigung der genannten zweiten Anwendung folgend auf den genannten Datenstapel zugegriffen wird.
Verfahren nach Anspruch 13, das ferner den Schritt des Abfragens der Identität der genannten ersten Anwendung durch Zugriff auf den genannten Delegatorstapel aufweist.
Verfahren nach Anspruch 11, bei dem von der genannten dynamischen Region in dem genannten ersten flüchtigen Speicher referenzierte Daten während der Ausführung der genannten ersten Anwendung genutzt werden.
Verfahren nach Anspruch 11, bei dem die von der dynamischen Region der zweiten Anwendung referenzierten genannten Daten während der Ausführung der genannten zweiten Anwendung genutzt werden.
Verfahren nach Anspruch 11, das ferner den Schritt des Delegierens der Benutzung des genannten Mikroprozessors von der genannten zweiten Anwendung an die genannte dritte Anwendung, die in der genannten Chipkarte gespeichert wird, aufweist.
Verfahren nach Anspruch 17, bei dem ein dritter Datenraum für die genannte dritte Anwendung alloziert wird, der ein flüchtiges Speichersegment zum Referenzieren von temporären Daten und ein nichtflüchtiges Speichersegment zum Referenzieren von statischen Daten aufweist, wobei das genannte flüchtige Segment der genannten dritten Anwendung einen öffentlichen und einen dynamischen Teil aufweist.