WO2006037609A2 - Verfahren zum laden einer applikation in einen datenträger - Google Patents

Verfahren zum laden einer applikation in einen datenträger Download PDF

Info

Publication number
WO2006037609A2
WO2006037609A2 PCT/EP2005/010678 EP2005010678W WO2006037609A2 WO 2006037609 A2 WO2006037609 A2 WO 2006037609A2 EP 2005010678 W EP2005010678 W EP 2005010678W WO 2006037609 A2 WO2006037609 A2 WO 2006037609A2
Authority
WO
WIPO (PCT)
Prior art keywords
library
data carrier
application
loaded
functions
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/EP2005/010678
Other languages
English (en)
French (fr)
Other versions
WO2006037609A3 (de
Inventor
Michael Baldischweiler
Rudolf Schubert
Robert Hockauf
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke+Devrient GmbH
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 WO2006037609A2 publication Critical patent/WO2006037609A2/de
Publication of WO2006037609A3 publication Critical patent/WO2006037609A3/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading

Definitions

  • the invention relates to a method for loading an application into a data carrier with an operating system implemented therein and a library assigned to the operating system.
  • a data carrier in the sense of the invention is a computer system in which the resources, i. Memory resources and / or computing capacity (computing power) are limited, e.g. a chip card (smart card, microprocessor chip card).
  • the data carrier has a body in which a CPU (a Mikro ⁇ processor) is arranged, and may have any standardized or non-standardized shape, such as the shape of a flat chip card without standard or according to a standard such. ISO 7810 (e.g., ID-I, ID-00, ID-000) or a volumetric token.
  • the data carrier can furthermore have one or more arbitrary interfaces for contactless and / or contact-based communication with a reading device or data processing system (for example personal computer, workstation, server).
  • An operating system for operating the data carrier is implemented in the data carrier. Furthermore, one or more applications can be implemented in the data carrier. Functions of the data carrier are realized by the applications, so that the data carrier has, for example, the function of a subscriber card for a mobile radio system (eg SIM card, USIM card), a payment transaction card, a card in the area of health care or another card ,
  • a subscriber card for a mobile radio system eg SIM card, USIM card
  • a payment transaction card eg.g., a card in the area of health care or another card
  • the operating system is assigned a library (equivalent to a library file) with a plurality of library functions that can be used by applications implemented in the data carrier, so that the applications do not themselves have to contain the program code which corresponds to the library functions.
  • a library equivalent to a library file
  • library functions that can be used by applications implemented in the data carrier, so that the applications do not themselves have to contain the program code which corresponds to the library functions.
  • the applications for example, in J AVA cards contain it the applications (applets) to be loaded next to the data elements usually also the associated code.
  • the library of a data carrier which satisfies a predetermined standard contains all the library functions defined in the standard. This ensures that any application that is implemented in the data carrier, or that is later loaded into the data carrier, has all the library functions that it needs.
  • the library occupies a large amount of memory in the data carrier. This memory is missing, for example, if additional applications are to be loaded into the data carrier. In this case, the amount of available memory is relatively limited, especially for data carriers.
  • the invention is based on the object to provide a method for loading an application into a data carrier, in which the available memory of the data carrier is handled sparingly.
  • the inventive method according to the independent claim 1 is based on a data carrier, with an operating system implemented therein and a library assigned to the operating system in which library functions can be stored. Applications can be loaded into the data carrier.
  • the invention specifies a method for loading an application into the data carrier. According to the invention, the application is loaded into the data carrier and at most those library functions which are required by the application are loaded into the library. Since only the required library functions are loaded into the data carrier, no memory is given away by superfluous library functions.
  • a method for loading an application into a data carrier is created in which the available memory of the data carrier is used sparingly.
  • the required library functions can be loaded into the data carrier either before or after the application.
  • the application and the library functions can be loaded closely adjacent to one another in terms of time.
  • the library is then preferably checked as to whether it contains library functions which are required by the application. Subsequently, only the library functions required by the application will be loaded into the library, which according to the check are not yet contained in the library.
  • the review of the library can optionally be omitted.
  • an empty library is provided in the volume.
  • the library is checked after removing an application from the disk, after which no longer required library functions are removed from the library.
  • library functions to be loaded into the library are provided with a signature.
  • the signature of the library function is checked before or during loading of the library function and the library function is only loaded into the library if this is permissible according to the signature. In this way library functions with malicious contents such as viruses, Trojans, worms or the like can be held.
  • FIG. 1 shows schematically a smart card with an operating system, a library associated with the operating system and an application memory with a plurality of applications stored therein.
  • Fig. 1 shows a smart card 10 as an example of a data carrier.
  • an operating system 20 is implemented, as well as a Be ⁇ operating system associated library 21 with a plurality of Libraryfunkti ⁇ onen a, b, c, ....
  • the smart card 10 includes an application memory 30 having a plurality of applications stored therein I, II, ....
  • the library 21 When loading a new application into the application memory 30, the library 21 is checked for its library of library functions. Only library functions which are not yet available, but which are required by the new application, are loaded into the library 21.
  • the smart card 10 a memory area is provided in which the information is stored, which library functions a, b, c are already contained in the library 21.
  • the memory area is in a first embodiment of the smart card 10 at least readable and optionally also overwritable.
  • the memory area may be a file in the MF of the smart card 10 which, after an authentication of the instance that wants to load the application, can be read out for it. Outside of the Smart Card 10, it is checked which library functions are still to be loaded into the library 21. The memory area is updated from the outside by a write access after a successful addition of the library. However, it is more expensive but safer to permit the updating of the memory area only by the smart card 10 itself.
  • the smart card 10 treats the addition of the library 21 and the entry of the changes in the storage area as an ato-mare transaction. That is, it ensures that either either steps are successfully performed or none of the steps become effective, as known by so-called "roll-back" or "roll-forward mechanisms".
  • the memory area is an internal memory area of the smart card 10.
  • the smart card 10 checks whether the library 21 for loading the application is to be supplemented. You could evaluate for this purpose the smart card 10 already present, to be loaded application. However, the smart card 10 preferably receives as a separate data element a requirement profile of the application to be loaded, in which the required Libra ⁇ ryfunktionen and optionally their versions are listed.
  • the terminal which can be, for example, a computer with card reader and optional network connection.
  • the authorized entity to load the application onto the smart card 10 may be the owner of the computer or the operator of a server connected to the computer via the network.
  • the terminal sends the library functions to be supplemented to the smart card 10.
  • the smart card 10 supplements the library 21 with the library functions obtained and notes the additions in the memory area provided for this purpose.
  • the application to be loaded preferably comprises only data and no executable code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung schafft ein Verfahren zum Laden einer Applikation in einen Datenträger mit einem darin implementierten Betriebssystem und einer dem Betriebssystem zugeordneten Library, in der Libraryfunktionen ablegbar sind. Bei dem Verfahren wird eine Applikation in den Datenträger geladen. Höchstens diejenigen Libraryfunktionen werden in die Library geladen, die von der Applikation benötigt werden.

Description

Verfahren zum Laden einer Applikation in einen Datenträger
Die Erfindung betrifft ein Verfahren zum Laden einer Applikation in einen Datenträger mit einem darin implementierten Betriebssystem und einer dem Betriebssystem zugeordneten Library.
Ein Datenträger im Sinn der Erfindung ist ein Rechnersystem, bei dem die Ressourcen, d.h. Speicherressourcen und/ oder Rechenkapazität (Rechen¬ leistung) begrenzt sind, z.B. eine Chipkarte (Smart Card, Mikroprozessor- Chipkarte). Der Datenträger hat einen Körper, in dem eine CPU (ein Mikro¬ prozessor) angeordnet ist, und der jede beliebige standardisierte oder nicht standardisierte Gestalt haben kann, beispielsweise die Gestalt einer flachen Chipkarte ohne Norm oder nach einer Norm wie z.B. ISO 7810 (z.B. ID-I, ID- 00, ID-000) oder die eines volumigen Tokens. Der Datenträger kann weiter eine oder mehrere beliebige Schnittstellen für kontaktlose und/ oder kon¬ taktbehaftete Kommunikation mit einem Lesegerät oder Datenverarbei¬ tungssystem (z.B. Personal Computer, Workstation, Server) haben.
Im Datenträger ist ein Betriebssystem zum Betrieb des Datenträgers imple¬ mentiert. Weiter können in dem Datenträger ein oder mehrere Applikatio¬ nen implementiert sein. Durch die Applikationen sind Funktionen des Da¬ tenträgers verwirklicht, so dass der Datenträger beispielsweise die Funktion einer Teilnehmerkarte für ein Mobilfunksystem (z.B. SIM-Karte, USIM- Karte), einer Zahlungsverkehrkarte, einer Karte im Bereich des Gesund¬ heitswesens oder einer anderen Karte hat.
Dem Betriebssystem ist eine Library (gleichbedeutend Bibliotheksdatei) mit einer Mehrzahl von Libraryfunktionen zugeordnet, die durch im Datenträ¬ ger implementierte Applikationen genutzt werden können, so dass die Ap¬ plikationen den Programmcode, der den Libraryfunktionen entspricht, nicht selbst enthalten müssen. Beispielsweise in J AVA-Karten enthalten dagegen die zu ladenden Applikationen (Applets) neben den Datenelemente in der Regel auch den zugehörigen Code.
Herkömmlicherweise enthält die Library eines Datenträgers, der einem vor¬ bestimmten Standard genügt, sämtliche Libraryfunktionen, die in dem Stan¬ dard definiert sind. Damit ist sichergestellt, dass jede Applikation, die in dem Datenträger implementiert ist, oder die später noch in den Datenträger geladen wird, sämtliche Libraryfunktionen zur Verfügung hat, die sie benö¬ tigt. Allerdings nimmt die Library eine große Menge an Speicher im Daten¬ träger ein. Dieser Speicher fehlt beispielsweise, wenn zusätzliche Applikati¬ onen in den Datenträger geladen werden sollen. Dabei ist gerade bei Daten¬ trägern die Menge an verfügbarem Speicher relativ begrenzt.
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren zum Laden einer Applikation in einen Datenträger zu schaffen, bei dem mit dem verfügbaren Speicher des Datenträgers sparsam umgegangen wird.
Die Aufgabe wird durch ein Verfahren nach Anspruch 1 gelöst. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen ange¬ geben.
Das erfindungsgemäße Verfahren gemäß dem unabhängigen Anspruch 1 geht von einem Datenträger aus, mit einem darin implementierten Betriebs¬ system und einer dem Betriebssystem zugeordneten Library, in der Library¬ funktionen ablegbar sind. In den Datenträger können Applikationen geladen werden. Die Erfindung gibt ein Verfahren zum Laden einer Applikation in den Datenträger an. Gemäß der Erfindung wird die Applikation in den Da¬ tenträger geladen und werden höchstens diejenigen Libraryfunktionen in die Library geladen, die von der Applikation benötigt werden. Da nur die benötigten Libraryfunktionen in den Datenträger geladen wer¬ den, wird kein Speicher durch überflüssige Libraryfunktionen verschenkt.
Daher ist gemäß Anspruch 1 ein Verfahren zum Laden einer Applikation in einen Datenträger geschaffen, bei dem mit dem verfügbaren Speicher des Datenträgers sparsam umgegangen wird.
Die benötigten Library funktionen können wahlweise zeitlich vor oder nach der Applikation in den Datenträger geladen werden. Wahlweise kann ein relativ großer Zeitabstand zwischen dem Laden der Applikation und dem Laden der Libraryfunktionen liegen. Alternativ können die Applikation und die Libraryfunktionen zeitlich eng benachbart in den Datenträger geladen werden.
Vorzugsweise wird die Library daraufhin überprüft, ob in ihr Libraryfunkti¬ onen enthalten sind, die von der Applikation benötigt werden. Anschließend werden nur diejenigen von der Applikation benötigten Library funktionen in die Library geladen werden, die gemäß der Überprüfung noch nicht in der Library enthalten sind. Beim Laden einer ersten Applikation in den Daten¬ träger, der zu diesem Zeitpunkt noch keine Applikationen enthält, kann die Überprüfung der Library wahlweise entfallen.
Vorzugsweise wird, bevor eine erste Applikation in den Datenträger geladen wird, eine leere Library im Datenträger bereitgestellt.
Gemäß einer Weiterbildung der Erfindung wird nach einem Entfernen einer Applikation aus dem Datenträger die Library überprüft, woraufhin nicht mehr benötigte Libraryfunktionen aus der Library entfernt werden. Gemäß einer anderen Weiterbildung der Erfindung werden in die Library zu ladende Libraryfunktionen mit einer Signatur versehen. Dabei wird vor dem oder beim Laden der Libraryfunktion die Signatur der Libraryfunktion über¬ prüft und die Libraryfunktion nur dann in die Library geladen, falls dies gemäß der Signatur zulässig ist. Auf diese Weise können Libraryfunktionen mit bösartigen Inhalten wie Viren, Trojanern, Würmern oder dergleichen abgehalten werden.
Im folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigt:
Fig. 1 schematisch eine Smart Card mit einem Betriebssystem, einer dem Betriebssystem zugeordneten Library und einem Applikationsspei¬ cher mit einer Mehrzahl von darin abgespeicherten Applikationen.
Fig. 1 zeigt eine Smart Card 10 als ein Beispiel für einen Datenträger. In der Smart Card 10 ist ein Betriebssystem 20 implementiert, sowie eine dem Be¬ triebssystem zugeordnete Library 21 mit einer Mehrzahl von Libraryfunkti¬ onen a, b, c, ... . Weiter enthält die Smart Card 10 einen Applikationsspeicher 30 mit einer Mehrzahl von darin abgespeicherten Applikationen I, II, ... .
Beim Laden einer neuen Applikation in den Applikationsspeicher 30 wird die Library 21 auf ihren Bestand an Libraryfunktionen überprüft. Nur noch nicht vorhandene Library funktionen, die aber von der neuen Applikation benötigt werden, werden in die Library 21 geladen. In der Smart Card 10 ist ein Speicherbereich vorgesehen, in dem die Informa¬ tion gespeichert ist, welche Libraryfunktionen a, b, c bereits in der Library 21 enthalten sind.
Der Speicherbereich ist in einer ersten Ausgestaltung aus der Smart Card 10 zumindest auslesbar und optional auch überschreibbar. Insbesondere kann der Speicherbereich eine Datei im MF der Smart Card 10 sein, die nach einer Authentisierung der Instanz, die die Anwendung laden möchte, für diese auslesbar ist. Außerhalb der Smart Card 10 erfolgt die Überprüfung, welche Libraryfunktionen noch in die Library 21 zu laden sind. Der Speicherbereich wird nach einem erfolgreichen Ergänzen der Library von außen durch einen schreibenden Zugriff aktualisiert. Aufwendiger aber sicherer ist es, die Ak¬ tualisierung des Speicherbereiches nur durch die Smart Card 10 selbst zu gestatten. In diesem Fall behandelt die Smart Card 10 das Ergänzen der Lib¬ rary 21 und das Eintragen der Änderungen in den Speicherbereich als ato¬ mare Transaktion. Das heißt sie sichert ab, dass immer entweder beide Schritte erfolgreich durchgeführt werden oder keiner der Schritte wirksam wird, wie es durch so genannte „Roll-Back" oder „Roll-Forward- Mechanismen" bekannt ist.
Der Speicherbereich ist in einer zweiten Ausgestaltung ein interner Spei¬ cherbereich der Smart Card 10. Die Smart Card 10 überprüft anhand der In¬ formationen in dem Speicherbereich, ob die Library 21 für das Laden der Anwendung zu ergänzen ist. Sie könnte zu diesem Zweck die der Smart Card 10 bereits vorliegende, zu ladende Anwendung auswerten. Bevorzugt erhält die Smart Card 10 jedoch als separates Datenelement ein Anforde¬ rungsprofil der zu ladenden Anwendung, in welchem die benötigten Libra¬ ryfunktionen und gegebenenfalls deren Versionen aufgeführt sind. Nachdem die Smart Card 10 intern überprüft hat, welche Libraryfunktionen zu ergänzen sind, sendet es diese Information als Antwort an das Terminal, das beispielsweise ein Computer mit Kartenleser und optionaler Netzwerk- anbindung sein kann. Die zum Laden der Anwendung auf die Smart Card 10 berechtigte Instanz kann der Inhaber des Computer oder der Betreiber eines mit dem Computer über das Netzwerk verbundenen Servers sein. Das Ter¬ minal sendet die zu ergänzenden Library funktionen an die Smart Card 10. Die Smart Card 10 ergänzt die Library 21 mit den erhaltenen Libraryfunkti¬ onen ergänzt und notiert die Ergänzungen in dem dafür vorgesehenen Spei¬ cherbereich.
Die zu ladende Anwendung umfasst vorzugsweise nur Daten und keinen ausführbaren Code.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Laden einer Applikation (I; II) in einen Datenträger (10) mit einem darin implementierten Betriebssystem (20) und einer dem Be¬ triebssystem (20) zugeordneten Library (21), in der Libraryfunktionen (a;b;c) ablegbar sind, wobei eine Applikation (I;II) in den Datenträger (10) geladen wird und - höchstens diejenigen Libraryfunktionen (a;b;c) in die Library (21) geladen werden, die von der Applikation (I;II) benötigt werden.
2. Verfahren nach Anspruch 1, wobei die Library (21) daraufhin überprüft wird, ob in ihr Libraryfunktionen (a;b;c) enthalten sind, die von der Applika¬ tion (I;II) benötigt werden, und anschließend nur diejenigen von der Appli¬ kation (I;II) benötigten Libraryfunktionen (a;b;c) in die Library (21) geladen werden, die gemäß der Überprüfung noch nicht in der Library (21) enthalten sind.
3. Verfahren nach Anspruch 1 oder 2, wobei, bevor eine erste Applikation (I;II) in den Datenträger (10) geladen wird, eine leere Library (21) im Daten¬ träger (10) bereitgestellt wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, wobei nach einem Entfernen einer Applikation (I;II) aus dem Datenträger (10) die Library (21) überprüft wird und nicht mehr benötigte Libraryfunktionen (a;b;c) aus der Library (21) entfernt werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, wobei in die Library (21) zu ladende Libraryfunktionen (a;b;c) mit einer Signatur versehen werden, und wobei vor dem oder beim Laden der Libraryfunktion (a;b;c) die Signatur der Libraryfunktion (a;b;c) überprüft wird und die Libraryfunktion (a;b;c) nur in die Library (21) geladen wird, falls dies gemäß der Signatur zulässig ist.
6. Datenträger (19) mit einem darin implementierten Verfahren nach einem der Ansprüche 1 bis 5.
PCT/EP2005/010678 2004-10-04 2005-10-04 Verfahren zum laden einer applikation in einen datenträger Ceased WO2006037609A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200410048262 DE102004048262A1 (de) 2004-10-04 2004-10-04 Verfahren zum Laden einer Applikation in einen Datenträger
DE102004048262.4 2004-10-04

Publications (2)

Publication Number Publication Date
WO2006037609A2 true WO2006037609A2 (de) 2006-04-13
WO2006037609A3 WO2006037609A3 (de) 2006-11-02

Family

ID=35572975

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/010678 Ceased WO2006037609A2 (de) 2004-10-04 2005-10-04 Verfahren zum laden einer applikation in einen datenträger

Country Status (2)

Country Link
DE (1) DE102004048262A1 (de)
WO (1) WO2006037609A2 (de)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6546551B1 (en) * 1999-09-28 2003-04-08 International Business Machines Corporation Method for accurately extracting library-based object-oriented applications
WO2002023331A2 (en) * 2000-09-14 2002-03-21 Sun Microsystems, Inc. Remote incremental program binary compatibility verification using api definitions
US20040015943A1 (en) * 2002-07-17 2004-01-22 Ying-Chou Chen Embedded computer system equipped with an upgradeable software library

Also Published As

Publication number Publication date
DE102004048262A1 (de) 2006-04-06
WO2006037609A3 (de) 2006-11-02

Similar Documents

Publication Publication Date Title
DE69813208T2 (de) Chipkarte mit datenumsetzer
DE69100175T2 (de) Integrierte Schaltung für eine Mikroprozessor-Karte mit mehreren Programmen in programmierbarem Speicher.
DE69402955T2 (de) Datenauswechselsystem mit tragbaren Datenverarbeitungseinheiten
DE10313318A1 (de) Kontrollierte Ausführung eines für eine virtuelle Maschine vorgesehenen Programms auf einem tragbaren Datenträger
DE69904446T2 (de) Speicherkarte
WO1997002543A1 (de) Verarbeitung langer nachrichten in einer prozessorkarte
DE60224937T2 (de) Verfahren und anordnung zum verknüpfen von verwandelten appletdateien
EP2795934B1 (de) Verfahren zur kommunikation mit einer applikation auf einem portablen datenträger sowie ein solcher portabler datenträger
DE102006016994A1 (de) Erfassen des Betriebsmittelverbrauchs
WO2005055052A2 (de) Java smart card chip mit für globale variablen reserviertem speicherbereich
WO2007128551A2 (de) Personalisierung von portablen datenträgern
DE102009009049B4 (de) Leseranwendungsvorrichtung
WO2001041087A1 (de) Verfahren zur initialisierung und/oder personalisierung von chipkarten sowie eine entsprechende einrichtung
DE102004048262A1 (de) Verfahren zum Laden einer Applikation in einen Datenträger
DE102007027935A1 (de) Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers
DE102004005676A1 (de) Datenträger mit plattformunabhängigem Anwendungs-Programmcode
DE102005045149A1 (de) Verfahren zur Initialisierung und/oder Personalisierung eines tragbaren Datenträgers
DE69904038T2 (de) Verfahren zum durchführen einer gesicherten transaktion mittels einer chipkarte über ein telekommunikationsnetzwerk
EP1610218B1 (de) Tragbarer Datenträger, System mit einem solchen Datenträger und Verfahren zum Betreiben eines solchen Datenträgers
DE10328238B4 (de) Verfahren zum Laden von Chipkarten mit Initialisierungs- und/oder Personalisierungsdaten
DE102005007581A1 (de) Verfahren zur Personalisierung eines tragbaren Datenträgers
WO2006050912A1 (de) Verfahren zum abfragen der systemkonfiguration eines datenträgers
DE10224767A1 (de) Personalisiertes digitales Datenverarbeitungssystem
DE102008020343A1 (de) Portabler Datenträger
EP1899883B1 (de) Verfahren zum schutz vertraulicher daten

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

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

122 Ep: pct application non-entry in european phase