WO2007006457A1 - Verwaltung von applikationen in einem tragbaren datenträger - Google Patents

Verwaltung von applikationen in einem tragbaren datenträger Download PDF

Info

Publication number
WO2007006457A1
WO2007006457A1 PCT/EP2006/006498 EP2006006498W WO2007006457A1 WO 2007006457 A1 WO2007006457 A1 WO 2007006457A1 EP 2006006498 W EP2006006498 W EP 2006006498W WO 2007006457 A1 WO2007006457 A1 WO 2007006457A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
data
data carrier
applications
management
Prior art date
Application number
PCT/EP2006/006498
Other languages
English (en)
French (fr)
Inventor
Stephan Spitz
Gisela Meister
Original Assignee
Giesecke & Devrient Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Publication of WO2007006457A1 publication Critical patent/WO2007006457A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files

Definitions

  • the invention generally relates to the technical field of portable data carriers, which are designed to carry out more than one application - also called fertil fertilizer or application program.
  • a multi-application data carrier can be designed in different designs, for example as a smart card or as a smart module or as a comparable resource-limited system.
  • the GlobalPlatform Card Specification published by GlobalPlatform, Inc., Foster City, California, USA, Version 2.1.1, March 2003, discloses a multi-application volume architecture using a centralized management module called Card Manager is provided.
  • the Card Manager carries out a variety of tasks, which are particularly administrative and security-related nature.
  • the card uses Manager, a centralized management file called a registry that contains a variety of management information.
  • the Card Manager manages data elements in the registry, which are described in section 6.6.2 of the document "GlobalPlatform Card Specification". Among other things, these data elements each comprise an application identifier AID (Application Identifier) for each application installed on the data carrier.
  • AID Application Identifier
  • Card Manager can not provide information about which applications build on each other or are required to run other applications. This limitation affects application management, especially for complex application structures. There is therefore a need for improved possibilities for application management.
  • a file system according to this standard has a file designated as EFDIR or DIR (Directory) for short, in which for each installed application the unique application identifier AID of this application and a path to the application are contained.
  • EFDIR EFDIR
  • DIR Directory
  • the DIR file also can not provide information about dependencies between the applications.
  • the invention accordingly has the object to provide an improved technique for application management on a portable multi-application data carrier.
  • the administration of application structures with dependencies between the applications should be simplified by the invention.
  • this object is achieved in whole or in part by a method having the features of claim 1, a portable multi-application data carrier according to claim 10 and a computer program product according to claim 11.
  • the dependent claims define optional features in some embodiments of the invention.
  • the invention is based on the basic idea of recording in central, ie not just application-local, administrative data, from which other applications the operation of a first application is dependent. This creates an uncomplicated option for application management. For example, it can be checked - whether from outside or inside the data carrier - if there are any dependencies between applications. As a further example, possibly missing - ie required, but not present on the disk - applications can be reloaded in a simple manner.
  • an "application” is understood to be an individually selectable application program on the data carrier.
  • An executable load file (Executable Load File) and an executable module (Executable Module) according to the GlobalPla f / orm specification, which contain only program code for an application, but are not even selectable, are preferably not considered as applications within the meaning of the present document become.
  • the entry of the information according to the invention takes place in connection with the loading and / or the installation of an application.
  • a management module can be used here.
  • the management module can also be used to determine information about missing applications and output, for example, in response to an external request.
  • the portable data carrier and / or the computer program product have in preferred developments features that correspond to the above-mentioned and / or the features mentioned in the method claims.
  • the computer program product according to the invention may be a physical medium, e.g. a semiconductor memory or a floppy disk or a CD-ROM.
  • the computer program product may also be a non-body medium, e.g. a signal transmitted over a computer network.
  • the computer program product may be used in the manufacture and / or initialization and / or personalization of the data carrier or during the use of the data carrier by the end user.
  • Fig. 1 shows as a sole drawing figure a block diagram of a data carrier according to an embodiment of the invention.
  • the multi-application data carrier 10 shown in FIG. 1 has a one-chip microcontroller in which, in a manner known per se, a processor 12, a memory 14 and an interface circuit 16 are integrated.
  • the memory 14 is divided into a plurality of memory fields configured in different technologies - eg RAM, ROM and EEPROM.
  • the interface circuit 16 is used for contact-bound or contactless communication with an external terminal (not shown in FIG. 1).
  • an operating system 18 which is multiap attacks and, for example, an advanced version of the known operating systems STARCOS® or SECCOS® can be.
  • the operating system 18 includes hardware-proximate drivers, a run-time environment, and application programming interfaces (APIs) in multiple sequential layers.
  • Each application 2Ox represents an executable application program that can be individually selected by the external terminal. Some of the applications 2Ox may already have been written into the ROM or EEPROM during the production of the data carrier 10, while other applications 2Ox may only be written during initialization or personalization or have been reloaded during use of the disk 10 in this.
  • the data carrier 10 also contains a management module 22, which performs a plurality of tasks and, among other things, serves for application administration.
  • the management module 22 is shown as being separate from the operating system 18 in FIG. 1, but it is understood that the management module 22 may also be integrated into the operating system 18 in alternative embodiments.
  • the management module 22 accesses management data 24 stored in the EEPROM of the data carrier 10.
  • the management data 24 are stored centrally. In the present exemplary embodiments, this is understood to mean that the administration data 24 are contained in one or more files and are available to all applications 2Ox-possibly via the intermediary of the management module 22. A distributed in the individual applications 2Ox storage of the management data 24 is therefore not provided in the embodiments described here. This does not exclude that in the applications 20x, additional data useful for managing the volume 10 may be stored locally.
  • the administrative data 24 may be small or large in scale;
  • an application directory 26 contained in the administration data 24 is mainly of interest.
  • AID Application Identifier
  • the entry in the application directory 26 shown in FIG. 1 indicates that the application 2OA with the application identifier 123 for operation requires the application 2OB with the application identifier 345 and a further application, not shown in FIG. 1, with the application identifier 567 ,
  • the application directory 26 is illustrated in the form of a table, but it goes without saying that any data structures can be used to implement the application directory 26.
  • each application 2Ox transmits the information about the other applications 2Ox required by it to the management module 22, which in turn applies one or more corresponding entries in the administration data 24-in particular the application directory 26.
  • This process which is illustrated in FIG. 1 by a dashed arrow 28, can take place in particular in connection with the loading of the application 2Ox into the data carrier 10 or in connection with the installation of the application 2Ox.
  • the on-circuit of the management module 22 is required because in the present embodiment, only the management module 22 has access to the management data 24. In alternative embodiments, on the other hand, it may be provided that the applications 2Ox directly access the administration data 24. access and enter the required information in the application directory 26.
  • the management module 22 can check with little effort whether an application 2Ox is executable, or whether additional applications 20x are needed and have to be reloaded into the data carrier 10. Such a check and / or a required reloading process can / can be initiated internally. Alternatively or additionally, however, an external query of the application configuration of the data carrier 10 may also be provided. 1 shows by way of example a request 30 in the form of a command APDU (Application Protocol Data Unit) with a status request command, such as the GET STATUS command.
  • APDU Application Protocol Data Unit
  • the management module 22 In response to receiving the status request command, the management module 22 checks if additional applications 20Ox are required to resolve all dependencies of one or more applications 20x already on the volume 10. In the example shown in FIG. 1, the application with the application identifier 567, which is required by the application 2OA, is still missing. The management module 22 reports this information in a suitable response 32, namely a response APDU, to the external terminal, which in turn - possibly in coordination with a background computer - can cause the reloading of the still missing application (AID 567).
  • the data carrier 10 is designed according to the GlobalPlatform Card Specification already mentioned above.
  • the management module 22 can then be configured in particular as a card manager, and the management data 24 can be formed as a registry or contained in the registry.
  • the application directory 26 is preferably formed in such embodiments by corresponding entries in the registry.
  • the data carrier 10 may include a file system in accordance with ISO / IEC 7816-4.
  • the application directory 26 may be formed by the file EFDIR.
  • the individual applications 20x can describe the file EFDIR directly or via an operating system service in order to enter the required information.
  • a management module 22 is not present in all configurations. in particular, it may be provided as part of the operating system 18 to provide functionality for detecting missing applications 20x and for internal and / or external query.
  • the described approaches are generally applicable to software components of a portable data carrier.
  • parts of applications parts of the operating system, such as system programs, drivers, in particular for I / O interfaces and libraries can be seen as software components.

Landscapes

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

Abstract

Ein Verfahren zur Verwaltung von Applikationen (2Ox) in einem tragbaren Multiapplikations-Datenträger (10), wobei in dem Datenträger (10) Verwaltungsdaten (24), die die Applikationen (2Ox) betreffen, zentral gespeichert werden, weist den Schritt auf, in den Verwaltungsdaten (24) zu vermerken, von welchen anderen Applikationen (20B) der Betrieb einer ersten Applikation (20A) abhängig ist. Ein Multiapplikations-Datenträger (10) und ein Computerprogrammprodukt weisen entsprechende Merkmale auf. Die Erfindung schafft eine verbesserte Technik zur Applikationsverwaltung auf dem Multiapplikations-Datenträger (10).

Description

Verwaltung von Applikationen in einem tragbaren Datenträger
Die Erfindung betrifft allgemein das technische Gebiet der tragbaren Datenträger, die zum Ausführen von mehr als einer Applikation - auch Anwen- düng oder Anwendungsprogramm genannt - eingerichtet sind. Ein solcher Multiapplikations-Datenträger kann in unterschiedlichen Bauformen beispielsweise als Chipkarte (Smart Card) oder als Chipmodul (Smart Tokeή) oder als vergleichbares ressourcenbeschränktes System ausgestaltet sein.
Im Zuge der technischen Entwicklung wächst die Leistungsfähigkeit von tragbaren Datenträgern - sowohl im Hinblick auf die Rechenleistung als auch im Hinblick auf den zur Verfügung stehenden Speicherplatz - immer weiter an. Da auch stets neue Anwendungsgebiete für tragbare Datenträger erschlossen werden, gewinnen Datenträger mit Multiapplikations-Funktio- nalität zunehmend an Bedeutung.
Bei Multiapplikations-Datenträgern können mehrere Applikationen gleichzeitig installiert sein und in der Regel auch während des Betriebs des Datenträgers beim Endbenutzer nachgeladen werden. Dadurch verkompliziert sich die Applikationsverwaltung, weil im Laufe der Zeit eine unüberschaubare Vielfalt unterschiedlicher Kombinationen von Applikationen und Applikationsversionen auf den im Besitz der Endbenutzer befindlichen Datenträgern entsteht.
Aus dem Dokument "GlobalPlatfonn Card Specification" , herausgegeben von GlobalPlatform, Inc., Foster City, Kalifornien, USA, Version 2.1.1, März 2003, ist eine Architektur für Multiapplikations-Datenträger bekannt, bei der ein als Card Manager bezeichnetes, zentrales Verwaltungsmodul vorgesehen ist. Der Card Manager führt eine Vielzahl von Aufgaben aus, die insbesondere verwaltungs- und sicherheitstechnischer Natur sind. Hierbei nutzt der Card Manager eine als Registry bezeichnete, zentrale Verwaltungsdatei, die eine Vielzahl von Verwaltungsinformationen enthält.
Eine Aufgabe des Card Manager ist die Applikationsverwaltung, die unter anderem das Laden von Programmdateien auf den Datenträger, die Installation von Applikationen und das Löschen von Applikationen und Programmdateien umfaßt. Der Card Manager verwaltet hierbei Datenelemente in der Registry, die in Abschnitt 6.6.2 des Dokuments "GlobalPlatform Card Specifi- cation" beschrieben sind. Unter anderem umfassen diese Datenelemente je einen Applikationsbezeichner AID (Application Identifier) für jede auf dem Datenträger installierte Applikation.
Der Card Manager kann jedoch keine Informationen darüber liefern, welche Applikationen aufeinander aufbauen beziehungsweise erforderlich sind, um andere Applikationen ausführen zu können. Diese Einschränkung beeinträchtigt die Applikationsverwaltung insbesondere bei komplexen Applikationsstrukturen. Es besteht daher ein Bedürfnis nach verbesserten Möglichkeiten zur Applikationsverwaltung.
Bei tragbaren Datenträgern ist die Verwendung von Dateisystemen gemäß der Norm ISO/ IEC 7816-4, herausgegeben von der International Standardi- sation Organisation, Genf, Schweiz, weit verbreitet. Ein Dateisystem gemäß dieser Norm weist eine als EFDIR oder kurz DIR (Directory) bezeichnete Datei auf, in der für jede installierte Applikation der eindeutige Applikations- bezeichner AID dieser Applikation und eine Pfadangabe zu der Applikation enthalten sind. Auch die DIR-Datei kann jedoch keine Informationen über Abhängigkeiten zwischen den Applikationen liefern. Die Erfindung hat demgemäß die Aufgabe, eine verbesserte Technik zur Applikationsverwaltung auf einem tragbaren Multiapplikations-Datenträger bereitzustellen. Insbesondere soll durch die Erfindung die Verwaltung von Applikationsstrukturen mit Abhängigkeiten zwischen den Applikationen vereinfacht werden.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren mit den Merkmalen von Anspruch 1, einen tragbaren Multiapplikations-Datenträger gemäß Anspruch 10 und ein Computer programmpro- dukt gemäß Anspruch 11. Die abhängigen Ansprüche definieren optionale Merkmale in manchen Ausführungsformen der Erfindung.
Die Erfindung geht von der Grundidee aus, in zentralen - also nicht nur applikationslokalen - Verwaltungsdaten zu vermerken, von welchen ande- ren Applikationen der Betrieb einer ersten Applikation abhängig ist. Dadurch wird eine unkomplizierte Möglichkeit zur Applikationsverwaltung geschaffen. Zum Beispiel kann - von außen oder innerhalb des Datenträgers - geprüft werden, ob Abhängigkeiten zwischen Applikationen vorliegen. Als weiteres Beispiel können gegebenenfalls fehlende - also erforderliche, aber nicht auf dem Datenträger vorhandene - Applikationen auf einfache Weise nachgeladen werden.
In bevorzugten Ausgestaltungen wird unter einer "Applikation" ein individuell anwählbares Anwendungsprogramm auf dem Datenträger verstanden. Eine ausführbare Ladedatei (Executable Load File) und ein ausführbares Modul (Executable Module) gemäß der GlobalPla f/orm-Spezifikation, die lediglich Programmcode für eine Applikation enthalten, aber selbst nicht anwählbar sind, sollen vorzugsweise nicht als Applikationen im Sinne des vorliegenden Dokuments angesehen werden. Vorzugsweise erfolgt das Eintragen der erfindungsgemäßen Informationen im Zusammenhang mit dem Laden und/ oder der Installation einer Applikation. Hierbei kann in manchen Ausgestaltungen ein Verwaltungsmodul ein- gesetzt werden. Das Verwaltungsmodul kann optional auch dazu dienen, Informationen über fehlende Applikationen zu ermitteln und z.B. in Reaktion auf eine externe Anfrage auszugeben.
Der tragbare Datenträger und/ oder das Computerprogrammprodukt weisen in bevorzugten Weiterbildungen Merkmale auf, die den oben erwähnten und/ oder den in den Verfahrensansprüchen genannten Merkmalen entsprechen. Das erfindungsgemäße Computerprogrammprodukt kann ein körperliches Medium sein, z.B. ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nicht-kör- perliches Medium sein, z.B. ein über ein Computernetzwerk übermitteltes Signal. Insbesondere kann das Computerprogrammprodukt bei der Herstellung und/ oder Initialisierung und/ oder Personalisierung des Datenträgers oder während des Einsatzes des Datenträgers beim Endbenutzer verwendet werden.
Weitere Merkmale, Aufgaben und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen.
Fig. 1 zeigt als einzige Zeichnungsfigur ein Blockdiagramm eines Datenträgers nach einem Ausführungsbeispiel der Erfindung.
Der in Fig. 1 dargestellte Multiapplikations-Datenträger 10 weist einen Ein- Chip-Mikrocontroller auf, in dem in an sich bekannter Weise ein Prozessor 12, ein Speicher 14 und eine Schnittstellenschaltung 16 integriert sind. Der Speicher 14 ist in mehrere in unterschiedlichen Technologien ausgestaltete Speicherfelder - z.B. RAM, ROM und EEPROM - gegliedert. Die Schnittstellenschaltung 16 dient zur kontaktgebundenen oder kontaktlosen Kom- munikation mit einem externen - in Fig. 1 nicht gezeigten - Terminal.
Im Speicher 16 - und zwar teils im ROM und teils im EEPROM - befindet sich ein Betriebssystem 18, das multiapplikationsfähig ist und beispielsweise eine weiterentwickelte Version eines der an sich bekannten Betriebssysteme STARCOS® oder SECCOS® sein kann. Das Betriebssystem 18 weist in mehreren aufeinander aufbauenden Schichten hardwarenahe Treiber, eine Laufzeitumgebung und Anwendungsprogrammierschnittstellen (APIs) auf.
Im Speicher 14 des Datenträgers 10 befinden sich mehrere Applikationen 2OA, 2OB, 2OC, die im folgenden zusammenfassend mit 2Ox bezeichnet werden. Jede Applikation 2Ox stellt ein lauffähiges und durch das externe Terminal individuell selektierbares Anwendungsprogramm dar. Manche der Applikationen 2Ox können schon bei der Herstellung des Datenträgers 10 in das ROM oder EEPROM eingeschrieben worden sein, während andere App- likationen 2Ox erst bei der Initialisierung oder Personalisierung oder während der Benutzung des Datenträgers 10 in diesen nachgeladen worden sind.
Der Datenträger 10 enthält ferner ein Verwaltungsmodul 22, das eine Vielzahl von Aufgaben übernimmt und unter anderem zur Applikationsverwal- tung dient. Das Verwaltungsmodul 22 ist in Fig. 1 als vom Betriebssystem 18 getrennte Einheit gezeigt, aber es versteht sich, dass das Verwaltungsmodul 22 in Ausführungsalternativen auch in das Betriebssystem 18 integriert sein kann. Das Verwaltungsmodul 22 greift auf Verwaltungsdaten 24 zu, die im EEPROM des Datenträgers 10 gespeichert sind. Die Verwaltungsdaten 24 sind zentral gespeichert. Hierunter wird in den vorliegenden Ausführungsbeispielen verstanden, dass die Verwaltungsdaten 24 in einer oder mehreren Datei/ en enthalten sind und allen Applikationen 2Ox - gegebenenfalls unter Vermittlung des Verwaltungsmoduls 22 - zur Verfügung stehen. Eine bei den einzelnen Applikationen 2Ox verteilte Speicherung der Verwaltungsdaten 24 ist also in den hier beschriebenen Ausführungsbeispielen nicht vorgesehen. Dies schließt nicht aus, dass in den Applikationen 2Ox zusätzliche Daten, die zur Verwaltung des Datenträgers 10 nützlich sind, lokal gespeichert sein können.
In unterschiedlichen Ausgestaltungen können die Verwaltungsdaten 24 geringen oder großen Umfang aufweisen; für das hier beschriebene Ausfüh- rungsbeispiel ist hauptsächlich ein in den Verwaltungsdaten 24 enthaltenes Applikationsverzeichnis 26 von Interesse. In dem Applikationsverzeichnis 26 sind für jede im Datenträger 10 installierte Applikation 20x ein eindeutiger Applikationsbezeichner (AID = Application Identifier) der Applikation 2Ox sowie ferner Applikationsbezeichner derjenigen anderen Applikationen 20x vermerkt, die die erstgenannte Applikation 2Ox benötigt, um lauffähig zu sein. So gibt beispielsweise der in Fig. 1 dargestellte Eintrag im Applikationsverzeichnis 26 an, dass die Applikation 2OA mit dem Applikationsbezeichner 123 zum Betrieb die Applikation 2OB mit dem Applikationsbezeichner 345 sowie eine weitere, in Fig. 1 nicht gezeigte Applikation mit dem Applika- tionsbezeichner 567 benötigt.
In Fig. 1 ist das Applikationsverzeichnis 26 in Form einer Tabelle veranschaulicht, aber es versteht sich, dass zur Implementierung des Applikationsverzeichnisses 26 beliebige Datenstrukturen verwendet werden können. So kann das Applikationsverzeichnis 26 beispielsweise als Datei mit einer Vielzahl von TLV-Objekten (TLV = Tag, Length, Value = Kennzeichen, Länge, Wert) ausgestaltet sein, die je einen Applikationsbezeichner einer vorhandenen Applikation 2Ox und gegebenenfalls einen oder mehrere Applikations- bezeichner der jeweils benötigten Applikationen 20x angeben.
Im vorliegend beschriebenen Ausführungsbeispiel übermittelt jede Applikation 2Ox die Informationen über die von ihr benötigten anderen Applikationen 2Ox an das Verwaltungsmodul 22, das seinerseits einen oder mehrere entsprechende Einträge in den Verwaltungsdaten 24 - insbesondere dem Applikationsverzeichnis 26 - anlegt. Dieser Vorgang, der in Fig. 1 durch einen gestrichelten Pfeil 28 veranschaulicht ist, kann insbesondere im Zusammenhang mit dem Laden der Applikation 2Ox in den Datenträger 10 oder im Zusammenhang mit der Installation der Applikation 2Ox erfolgen. Die Ein- Schaltung des Verwaltungsmoduls 22 ist erforderlich, weil im vorliegenden Ausführungsbeispiel nur das Verwaltungsmodul 22 Zugriff auf die Verwaltungsdaten 24 hat. In Ausführungsalternativen kann dagegen vorgesehen sein, dass die Applikationen 2Ox unmittelbar auf die Verwaltungsdaten 24 . zugreifen und die erforderlichen Informationen in das Applikationsverzeich- nis 26 eintragen.
Aufgrund der im Applikationsverzeichnis 26 enthaltenen Daten kann das Verwaltungsmodul 22 mit geringem Aufwand prüfen, ob eine Applikation 2Ox lauffähig ist, oder ob zusätzliche Applikationen 20x benötigt werden und in den Datenträger 10 nachgeladen werden müssen. Eine solche Prüfung und/ oder ein erforderlicher Nachladevorgang kann/ können intern angestoßen werden. Alternativ oder zusätzlich kann jedoch auch eine externe Abfrage der Applikationskonfiguration des Datenträgers 10 vorgesehen sein. Fig. 1 zeigt hierzu beispielhaft eine Anfrage 30 in Form einer Kommando- APDU (APDU = Application Protocol Data Unit) mit einem Statusabfragebefehl wie z.B. dem Befehl GET STATUS.
In Reaktion auf den Erhalt des Statusabfragebefehls überprüft das Verwal- tungsmodul 22, ob zusätzliche Applikationen 2Ox erforderlich sind, um alle Abhängigkeiten einer oder mehrerer bereits auf dem Datenträger 10 befindlichen Applikation/ en 20x aufzulösen. In dem in Fig. 1 gezeigten Beispiel fehlt noch die Applikation mit dem Applikationsbezeichner 567, die von der Applikation 2OA benötigt wird. Das Verwaltungsmodul 22 meldet diese Informa- tion in einer geeigneten Antwort 32, nämlich einer Antwort- APDU, an das externe Terminal, das dann seinerseits - gegebenenfalls in Abstimmung mit einem Hintergrundrechner - das Nachladen der noch fehlenden Applikation (AID 567) veranlassen kann.
In manchen Ausgestaltungen ist der Datenträger 10 gemäß der eingangs bereits erwähnten GlobalPlatform Card Specification ausgestaltet. Das Verwaltungsmodul 22 kann dann insbesondere als Card Manager ausgebildet sein, und die Verwaltungsdaten 24 können als Registry ausgebildet oder in der Registry enthalten sein. Das Applikationsverzeichnis 26 wird in solchen Ausführungsformen vorzugsweise durch entsprechende Einträge in der Registry gebildet.
Alternativ oder zusätzlich zu den Merkmalen der GlobalPlatform Card Specification kann der Datenträger 10 in manchen Ausgestaltungen ein Dateisystem gemäß der Norm ISO/ IEC 7816-4 aufweisen. In diesem Fall kann das Applikationsverzeichnis 26 durch die Datei EFDIR gebildet sein. Die einzelnen Applikationen 20x können die Datei EFDIR unmittelbar oder über einen Betriebssystemdienst beschreiben, um die erforderlichen Informationen einzutragen. Ein Verwaltungsmodul 22 ist nicht in allen Ausgestaltungen vorhan- den, es kann aber insbesondere als Teil des Betriebssystems 18 vorgesehen sein, um eine Funktionalität zur Ermittlung von fehlenden Applikationen 20x und zur internen und/ oder externen Abfrage bereitzustellen.
Die beschriebenen Lösungsansätze sind allgemein anwendbar für Softwarekomponenten eines tragbaren Datenträgers. Als Softwarekomponenten können neben Applikationen auch Teile von Applikationen, Teile des Betriebssystems, wie beispielsweise Systemprogramme, Treiber, insbesondere für I/O-Schnittstellen und Bibliotheken gesehen werden.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur Verwaltung von Softwarekomponenten (20x) in einem tragbaren Multiapplikations-Datenträger (10), wobei in dem Datenträger (10) Verwaltungsdaten (24), die die
Softwarekomponenten (2Ox) betreffen, zentral gespeichert werden, dadurch gekennzeichnet, dass in den Verwaltungsdaten (24) vermerkt wird, von welchen anderen Softwarekomponenten (20B) der Betrieb einer ersten Softwarekomponente (20A) abhängig ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass im Zusammenhang mit dem Laden und/ oder der Installation der ersten Softwarekomponente (20A) in den/ dem Datenträger (10) Bezeichner aller anderen Softwarekomponenten (20B), von denen der Betrieb der ersten Softwarekomponente (20A) abhängig ist, in die Verwaltungsdaten (24) eingetragen werden.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass ferner ein Bezeichner der ersten Softwarekomponente (20A) in die
Verwaltungsdaten (24) eingetragen wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Verwaltungsdaten (24) mindestens ein Applika- tionsverzeichnis (26) aufweisen.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Verwaltungsdaten (24) eine Registry gemäß der GlobalPlatform Card Specification sind oder umfassen.
6. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Verwaltungsdaten (24) eine EFöiR-Datei gemäß der Norm ISO/ IEC 7816-4 sind oder umfassen.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Softwarekomponenten (2Ox) über ein Verwaltungsmodul (22) auf die Verwaltungsdaten (24) zugreifen.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekenn- zeichnet, dass aus den Verwaltungsdaten (24) Informationen über fehlende und zum Betrieb der ersten Softwarekomponente (20A) erforderliche Softwarekomponenten ermittelt werden.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Informationen über die fehlenden und zum Betrieb der ersten
Softwarekomponente (20A) erforderlichen Softwarekomponenten in Reaktion auf eine bei dem Datenträger (10) eingehende Anfrage (30) vom Datenträger (10) in einer Antwort (32) ausgegeben werden.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß Softwarekomponenten Applikationen sind.
11. Tragbarer Multiapplikations-Datenträger (10), insbesondere Chip- karte oder Chipmodul, der dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
12. Computerprogrammprodukt mit einer Vielzahl von Programmbefehlen, die dazu eingerichtet sind, einen Prozessor (12) eines tragbaren Multiapplikations-Datenträgers (10) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 10 zu veranlassen.
PCT/EP2006/006498 2005-07-12 2006-07-04 Verwaltung von applikationen in einem tragbaren datenträger WO2007006457A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005032542.4 2005-07-12
DE200510032542 DE102005032542A1 (de) 2005-07-12 2005-07-12 Verwaltung von Applikationen in einem tragbaren Datenträger

Publications (1)

Publication Number Publication Date
WO2007006457A1 true WO2007006457A1 (de) 2007-01-18

Family

ID=37074808

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/006498 WO2007006457A1 (de) 2005-07-12 2006-07-04 Verwaltung von applikationen in einem tragbaren datenträger

Country Status (2)

Country Link
DE (1) DE102005032542A1 (de)
WO (1) WO2007006457A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3217281A2 (de) 2016-03-10 2017-09-13 Giesecke+Devrient Mobile Security GmbH Verfahren zur verwaltung der kartensoftware einer smartcard
CN109978096A (zh) * 2019-03-29 2019-07-05 西安精雕软件科技有限公司 一种电极自动化生产与仓储管理系统

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0543588A2 (de) * 1991-11-21 1993-05-26 International Business Machines Corporation Erstellung und Verarbeitung von Rechnerprogrammen
EP0802480A1 (de) * 1996-04-19 1997-10-22 Sun Microsystems, Inc. Installierung von mehreren Softwarepaketen mit Paketabhängigkeiten
US6185734B1 (en) * 1998-07-21 2001-02-06 Hewlett-Packard Company Hierarchical registry structure for managing multiple versions of software components
WO2001082082A1 (en) * 2000-04-24 2001-11-01 Microsoft Corporation Method and apparatus for providing volume snapshot dependencies in a computer system
US6442754B1 (en) * 1999-03-29 2002-08-27 International Business Machines Corporation System, method, and program for checking dependencies of installed software components during installation or uninstallation of software
US20020147903A1 (en) * 2001-04-10 2002-10-10 Discreet Logic Inc. Initialising modules
US20040064830A1 (en) * 2002-09-30 2004-04-01 Irving Richard H. Runtime services for network software platform

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0270571B1 (de) * 1986-05-16 1992-06-24 AT&T Corp. Anlage für einen tragbaren datenträger mit mehreren anwendungsdatenbeständen
FR2683357A1 (fr) * 1991-10-30 1993-05-07 Philips Composants Microcircuit pour carte a puce a memoire programmable protegee.
US6385645B1 (en) * 1995-08-04 2002-05-07 Belle Gate Investments B.V. Data exchange system comprising portable data processing units
JP2002149411A (ja) * 2000-11-09 2002-05-24 Nec Microcomputer Technology Ltd 多機能スマートカード及びその管理方法
US20040164142A1 (en) * 2002-12-11 2004-08-26 Wolfgang Flugge Methods and systems for user media interoperability with data integrity

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0543588A2 (de) * 1991-11-21 1993-05-26 International Business Machines Corporation Erstellung und Verarbeitung von Rechnerprogrammen
EP0802480A1 (de) * 1996-04-19 1997-10-22 Sun Microsystems, Inc. Installierung von mehreren Softwarepaketen mit Paketabhängigkeiten
US6185734B1 (en) * 1998-07-21 2001-02-06 Hewlett-Packard Company Hierarchical registry structure for managing multiple versions of software components
US6442754B1 (en) * 1999-03-29 2002-08-27 International Business Machines Corporation System, method, and program for checking dependencies of installed software components during installation or uninstallation of software
WO2001082082A1 (en) * 2000-04-24 2001-11-01 Microsoft Corporation Method and apparatus for providing volume snapshot dependencies in a computer system
US20020147903A1 (en) * 2001-04-10 2002-10-10 Discreet Logic Inc. Initialising modules
US20040064830A1 (en) * 2002-09-30 2004-04-01 Irving Richard H. Runtime services for network software platform

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GLOBALPLATFORM INC.: "GlobalPlatform Card Specification 2.1.1", 25 March 2003 (2003-03-25), pages 1 - 237, XP002403627, Retrieved from the Internet <URL:http://www.globalplatform.org/specificationview.asp?id=archived> [retrieved on 20061018] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3217281A2 (de) 2016-03-10 2017-09-13 Giesecke+Devrient Mobile Security GmbH Verfahren zur verwaltung der kartensoftware einer smartcard
CN109978096A (zh) * 2019-03-29 2019-07-05 西安精雕软件科技有限公司 一种电极自动化生产与仓储管理系统

Also Published As

Publication number Publication date
DE102005032542A1 (de) 2007-01-18

Similar Documents

Publication Publication Date Title
DE102004022480A1 (de) Datenintegrationssystem mit programmatischen Quell- und Zielschnittstellen
DE10003268B4 (de) Verfahren und Vorrichtung zum Feststellen der Laufwerksbuchstaben-Bezeichnung eines CD-Rom-Laufwerks während der anfänglichen Systemvorbereitung eines Computersystems
DE60224937T2 (de) Verfahren und anordnung zum verknüpfen von verwandelten appletdateien
WO2007006457A1 (de) Verwaltung von applikationen in einem tragbaren datenträger
EP1695207A2 (de) Java smart card chip mit für globale variablen reserviertem speicherbereich
DE102004022478A1 (de) Datenintegrationssystem mit programmatischen Quell- und Zielschnittstellen
DE69737608T2 (de) Verfahren zum laden eines anwendungsprogramms auf eine chipkarte
EP1623394A1 (de) Speicherverwaltung bei einem tragbaren datentrager
DE19928939A1 (de) Datenträger sowie Verfahren zur Datenübertragung und zur Speicherverwaltung
DE10040241A1 (de) Speicheranordnung für einen Datenträger und Verfahren zur Speicherverwaltung
DE10324384B3 (de) Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
DE102004040296B3 (de) Schreiben von Daten in einen nichtflüchtigen Speicher eines tragbaren Datenträgers
EP1516245B1 (de) Vorrichtung und verfahren zum verarbeiten einer sequenz von sprungbefehlen
EP2012280A2 (de) Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers
EP1044409B1 (de) Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems
DE102004054068A1 (de) Verfahren zum Abfragen der Systemkonfiguration eines Datenträgers
DE102008020343A1 (de) Portabler Datenträger
WO2005022405A1 (de) Organisation eines dateibaums bei einem tragbaren datenträger
WO2004104916A2 (de) Laden eines ausführbaren programms in einen tragbaren datenträger
DE102004052876A1 (de) Kennzeichnen von Remote-Objekten als exportiert
EP1922618A1 (de) Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger
EP1600855A2 (de) Erzeugen und Verwenden von Speicherbelegungsinformationen bei einem tragbaren Datenträger
DE102008026785A1 (de) Verwalten von Instanzen einer virtuellen Maschine in einem tragbaren Datenträger
EP1691322A1 (de) Transaktionssystem und Verfahren zur Durchführung von Transaktionen
DE10351764A1 (de) Steuern der Speicherbereinigung bei einem tragbaren Datenträger

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06762389

Country of ref document: EP

Kind code of ref document: A1