DE60015810T2 - Integriertes verfahren zur herstellung von chipkarten - Google Patents

Integriertes verfahren zur herstellung von chipkarten Download PDF

Info

Publication number
DE60015810T2
DE60015810T2 DE60015810T DE60015810T DE60015810T2 DE 60015810 T2 DE60015810 T2 DE 60015810T2 DE 60015810 T DE60015810 T DE 60015810T DE 60015810 T DE60015810 T DE 60015810T DE 60015810 T2 DE60015810 T2 DE 60015810T2
Authority
DE
Germany
Prior art keywords
card
application
script
smart card
data
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.)
Expired - Lifetime
Application number
DE60015810T
Other languages
English (en)
Other versions
DE60015810D1 (de
Inventor
E. Harry GRAHAM
B. Marc KEKICHEFF
Jay Ricky NABLO
W. William HAEUSER
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.)
Globalplatform Inc (ndgesd Staates Delaware)
Original Assignee
Visa International Service Association
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 Visa International Service Association filed Critical Visa International Service Association
Application granted granted Critical
Publication of DE60015810D1 publication Critical patent/DE60015810D1/de
Publication of DE60015810T2 publication Critical patent/DE60015810T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3574—Multiple applications on card

Description

  • Hintergrund der Erfindung
  • Die vorliegende Erfindung betrifft Chipkarten. Auch Chipkarten, integrierte Schaltkreiskarten, Speicherkarten oder Prozessorkarten genannt, ist die Chipkarte üblicherweise eine kreditkartengroße Kunststoffkarte, die einen oder mehrere integrierte Halbleiterschaltkreise umfasst. Eine Chipkarte kann eine Schnittstelle mit einem Verkaufsterminal, einem ATM, oder mit einem Kartenlesegerät, das in einem Computer, einem Telefon, einer Straßenverkaufsmaschine oder einer Vielzahl anderer Geräte eingebaut ist, bilden. Die Chipkarte kann mit verschiedenen Arten von Funktionen programmiert sein, wie eine Anwendung, die einen Geldwert speichert, eine Gutschrift- oder Belastungsanwendung, eine Kundenbindungsanwendung, Informationen über den Inhaber der Karte usw. Obwohl eine Kunststoffkarte zur Zeit das Medium der Wahl für Chipkarten ist, wird darüber nachgedacht, dass eine Chipkarte auch in eine kleinere Form integrierte werden könnte, z. B. kann man sie an einem Schlüsselanhänger befestigen oder sie könnte so klein wie ein Chipmodul sein. Eine Chipkarte kann auch Teil eines Taschencomputers, eines Telefons sein oder eine andere Form annehmen. Die nachfolgende Beschreibung bietet ein Beispiel für mögliche Elemente einer Chipkarte, auch wenn die vorliegende Erfindung auf eine breite Spannbreite von Arten von Chipkarten anwendbar ist.
  • Eine Chipkarte kann einen Mikroprozessor, einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher (ROM), einen nicht flüchtigen Speicher, ein Verschlüsselungsmodul (oder Recheneinheit) und eine Schnittstelle zum Kartenlesegerät (oder Terminal) umfassen. Andere Merkmale können vorhanden sein, wie z. B. ein optischer Speicher, ein Blitz-EEPROM, ein FRAM, eine Uhr, ein Zufallszahlengenerator, eine Unterbrechungssteuerung, eine Steuerlogik, eine Ladepumpe, Stromanschlüsse und Schnittstellenkontakte, damit die Karte mit der Außenwelt kommunizieren kann. Natürlich kann eine Chipkarte auf viele Arten integriert sein und muss nicht unbedingt einen Mikroprozessor oder andere Merkmale umfassen.
  • Der Mikroprozessor ist jede passende zentrale Recheneinheit zum Ausführen von Befehlen und zum Steuern der Vorrichtung. Das RAM dient als vorübergehender Speicher für berechnete Ergebnisse und als Stapelspeicher. Das ROM speichert das Betriebssystem, die feststehenden Daten, Standardroutinen, Abruftabellen und andere dauerhafte Informationen. Der nichtflüchtige Speicher (wie ein EPROM oder EEPROM) dient zum Speichern von Informationen, die nicht verloren gehen dürfen, wenn die Karte von einer Stromquelle entfernt wird, die aber auch veränderbar sein müssen, um Daten, die speziell für einzelne Karten gelten, aufzunehmen oder Änderungen während der Lebensdauer der Karte zu ermöglichen. Diese Informationen umfassen eine Kartenidentifikationsnummer, eine Personenidentifikationsnummer, Autorisierungsebenen, Kassenbestände, Kreditlinien und andere Informationen, die eventuell mit der Zeit verändert werden sollen. Ein Verschlüsselungsmodul ist ein optionales Hardwaremodul, das verwendet wird, um eine Vielzahl von Verschlüsselungsalgorithmen durchzuführen. Natürlich kann die Verschlüsselung auch von der Software durchgeführt werden. „Applied Cryptography" von Bruce Schneier, John Wiley & Sons, Inc., 1996, diskutiert passende Verschlüsselungsalgorithmen.
  • Die Schnittstelle zum Kartenlesegerät umfasst die Software und Hardware, die für eine Kommunikation mit der Außenwelt notwendig sind. Eine große Vielfalt von Schnittstellen ist möglich. Als Beispiel kann die Schnittstelle eine Kontaktschnittstelle, eine eng gekoppelte Schnittstelle, eine fern gekoppelte Schnittstelle, oder eine Vielfalt anderer Schnittstellen sein. Mit einer Kontaktschnittstelle werden Signale vom integrierten Schaltkreis zu einer Anzahl von Metallkontakten auf der Außenseite der Karte geschickt, die in physischen Kontakt mit ähnlichen Kontakten eines Kartenlesegeräts gelangen. Eine Chipkarte kann einen herkömmlichen Magnetstreifen umfassen, um eine Kompatibilität mit herkömmlichen Kartenlesegeräten und – anwendungen zu bieten, und kann zur Kompatibilität auch eine Kopie der Magnetstreifeninformation im integrierten Schaltkreis selbst vorsehen.
  • Verschiedene mechanische und elektrische Eigenschaften einer Chipkarte und Aspekte ihrer Zusammenwirkung mit einem Kartenlesegerät sind in Smart Card Handbook, W. Rankl und W. Effing, John Wiley & Sons, Ltd., 1997 beschrieben und werden von den nachfolgenden Spezifikationen definiert: Visa Integrated Circuit Card Specification, Visa International Service Association, 1996; EMV Integrated Circuit Card Specification for Payment Systems, EMV Integrated Circuit Card Terminal Specification for Payment Systems, EMV Integrated Circuit Card Application Specification for Payment Systems, Visa International, Mastercard, Europay, 1996; und International Standard; Identification Cards – Integrated Circuit (s) Cards with Contacts, Parts 1 – 6, International Organization for Standardization, 1987 – 1995.
  • Beim Aufbau solch einer Chipkarte werden üblicherweise mehrere Schritte an verschiedenen physikalischen Stellen durchgeführt. Einer dieser Schritte ist die Installation der Anwendungssoftware. Anwendungen, die für eine Chipkarte gedacht sind, werden üblicherweise von einem Chipkartenhersteller oder einem Dritten nach Anweisung eines Kartenausstellers entwickelt. Der Kartenaussteller ist häufig eine Bank oder andere Finanzinstitution, kann aber auch ein Telekommunikationsunternehmen sein, ein Händler, der ein Kundentreueprogramm durchführt, oder sogar ein Agent, der für einen Aussteller arbeitet. Die Anwendungen, die normalerweise in Assembler-Code für einen speziel len Chip geschrieben werden, werden an den Chiphersteller übergeben, der solche Chips herstellt. Der Chiphersteller brennt die Anwendersoftware in die Chips auf einem Siliziumwafer. Der Wafer wird dann zerschnitten und die Chips werden zurück an den Chipkartenhersteller gesandt. Der Chipkartenhersteller integriert die Chips dann in die Kunststoffkarten.
  • Sobald die Chips in den Kunststoffkarten integriert sind, führt der Kartenhersteller einen Initialisierungsvorgang durch. Während der Initialisierung werden Daten und Datenstrukturen, die für einen ganzen Stapel von Karten gleich sind, auf den Karten installiert. Daten, die für einen ganzen Stapel von Karten gleich sind, können z. B. Druckgraphiken für Bank- oder Netzwerklogos, Informationen wie eine Bankidentifizierungsnummer (BIN), oder die von der Anwendung verwendete Währung, wie US-Dollar oder deutsche Mark, sein.
  • Nach der Initialisierung tritt normalerweise ein Personalisierungsvorgang ein. Der Personalisierungsvorgang kann vom Kartenhersteller durchgeführt werden, wird aber häufig von einem spezialisierten Personalisierungsbüro durchgeführt. Während der Personalisierung werden die Daten, welche die Karte als die Einzige identifizieren, auf die Karte geladen. Zum Beispiel können die Personalisierungsdaten einen Maximalwert für eine Karte mit gespeichertem Geldwert, eine persönliche Identifikationsnummer (PIN), eine Kontonummer des Kartenhalters, das Ablaufdatum der Karte oder Verschlüsselungen umfassen.
  • Das Personalisierungsbüro ist üblicherweise eine dritte Partei, die vom Chipkartenaussteller unter Vertrag genommen ist, um ihre Chipkarten zu personalisieren. Das Personalisierungsbüro liegt häufig in einem Ort, der nicht der Ort des Chipkartenausstellers oder der Ort des Kartenherstellers ist. Für jeden Kartenstapel müssen die Kartenhalterinformationsdaten üblicherweise vom Aussteller vorbearbeitet sein (sortiert, for matiert und in einer Personalisierungsdatei abgelegt). Üblicherweise benötigt jedes Personalisierungsbüro ein besonderes Dateiformat. Der Aussteller muss seine Kartenhalterinformationsdaten für jedes Personalisierungsbüro, mit dem der Aussteller zusammenarbeitet, abändern. Anderenfalls muss das Personalisierungsbüro seine Dateiformate für die verschiedenen Aussteller, mit denen es zusammenarbeitet, abändern. In jedem Fall muss die Personalisierungsdatendatei üblicherweise für fast alle Änderungen, die an den Spezifikationen für einen Stapel von Karten vorgenommen werden, neu konzipiert werden. Während der Personalisierung werden üblicherweise Personalisierungsgeräte, die mit einer Sicherheitsvorrichtung gekoppelt sind, verwendet. Die Personalisierungsgeräte enthalten Software, die mit der Chipkartensoftware zusammenarbeitet, um die Personalisierungsdaten zu laden. Die Sicherheitsvorrichtung wird verwendet, um Chiffrierschlüssel oder andere empfindliche Informationen zu speichern, die im Personalisierungsvorgang benötigt werden könnten. Nach der Personalisierung werden die Karten an die Kartenhalter verteilt.
  • Eine Technik für die Chipkartenpersonalisierung ist in der US-Patentanmeldung Nr. 08/755,459 (US-Patent Nr. 5,889,941) mit dem Titel „System and Apparatus for Smart Card Personalization", übertragen an UbiQ Incorporated, beschrieben. Diese Anwendung lehrt ein Chipkarten-Personalisierungssystem, welches eine Datenbank erhält, die Kartenanwendungsdaten, Kartenbetriebssystemdaten, Ausstellervorgaben zur Eingabe von Kartenhalterdaten und Personalisierungsgerätedaten umfasst, um dynamisch Konfigurationen aufzubauen, um ausgestellte (personalisierte) Chipkarten herzustellen.
  • Herkömmlicherweise ist die Vorrichtung, die mit der Chipkartenherstellung verbunden ist, vorprogrammiert. Jedes Stück Software wird individuell für einen bestimmten Satz von Spezifikationen für einen Stapel von Karten angefertigt, wie für die Kombination der Chipkartenanwendung und dem Chip selbst. Dementsprechend muss für tatsächlich jede Änderung an den Spezifikationen für einen Stapel von Chipkarten die Software für jedes Gerät, das im Chipkarten-Herstellungsvorgang verwendet wird, umgeschrieben werden. Dieses individuelle Umschreiben von Software für wirklich jedes Gerät, das in der Chipkartenherstellung verwendet wird, kann sehr zeitaufwändig, arbeitsintensiv und teuer sein.
  • Zusätzlich sind die herkömmlichen Verfahren zum Herstellen von Chipkarten nicht praktisch für die Herstellung von Chipkarten mit Mehrfachanwendungen. Eine Chipkarte mit Mehrfachanwendungen kann in vielen Formen und von einer Vielzahl von Herstellern auftreten. In einem Beispiel kann die Chipkarte das Betriebssystem Multi-application Operating System (MULTOS), vertrieben von Maosco Ltd. verwenden. In einem anderen Beispiel kann die Chipkarte mit Mehrfachanwendungen die „Open Platform" Architektur verwenden, die genauer in den US-Patentanmeldungen Nr. 09/046,993 und 09/046,994 beschrieben ist, die beide an Visa International Service Association übertragen wurden. Im Allgemeinen werden diese Arten von Chipkarten hier als Chipkarten mit Mehrfachanwendungen bezeichnet.
  • Eine (herkömmliche) Chipkarte mit einer einzelnen Anwendung wird ausgeliefert, wobei ihre Softwareanwendung bereits dauerhaft in den Chip auf der Karte eingebrannt wurde. Es ist im Allgemeinen nicht möglich, der Karte weitere Anwendungen hinzuzufügen. Außerdem laufen Anwendungen, die für eine Karte, hergestellt von einem ersten Hersteller (z. B. Gemplus), geschrieben wurden, nicht notwendigerweise auf einer Karte, die von einem zweiten Hersteller (z. B. Schlumberger) hergestellt wurde. Bei einer Open-Platform-Chipkarte sind die Anwendungen so konzipiert, dass sie einer Karte nach der Ausstellung hinzugefügt werden können, und Anwendungen sollten so ausgelegt sein, dass sie auf jeder Open-Platform-Karte laufen können, ungeachtet des Kartenherstellers. Diese Open-Platform-Chipkarten können das Laden einer Anwendung und/oder von Objekten von einem Anwendungsserver auf eine Karte über eine Kartenannahmevorrichtung ermöglichen. Dieses Laden kann vor oder nach der Ausstellung der Karte in einer sicheren und vertraulichen Weise durchgeführt werden. Zusätzlich erleichtert die Open-Platform-Chipkarte Mehrfach-Eigentümer und Steuerung verschiedener Anwendungen der Chipkarte.
  • In einem Ausführungsbeispiel der Open-Platform-Karte enthält die Karte nach der Herstellung die Software-Infrastruktur, die nötig ist, um das Laden, Initialisieren, Personalisieren und Laufen der Anwendungen zu unterstützen. Diese Infrastruktur kann das Betriebssystem der Karte, ein Kartenausführungsprogramm (das Hauptsteuerprogramm für den Chip), eine Kartendomain (die Softwareanwendung, die den Aussteller repräsentiert), und eine Anzahl von Sicherheitsdomains (wobei jede einen Anwendungsprovider darstellt) umfassen. In einem bestimmten Ausführungsbeispiel, das zur Verwendung mit Anwendungen, die in JAVA geschrieben wurden, passend ist, umfasst die Infrastruktur einen JAVA-Übersetzer (die „virtuelle JAVA Maschine"). Die virtuelle Maschine JavaCardTM (JCVM) arbeitet gut in diesem Ausführungsbeispiel.
  • Eine Open-Platform-Chipkarte kann auch vertrauliche Informationen für eine Anwendung in einer Chipkarte bereitstellen. In einer Chipkarte mit Mehrfachanwendung wird eine privilegierte Anwendung, bezeichnet als eine Sicherheitsdomain, verwendet als ein vertraulicher Vertreter eines Anwendungsproviders. Die Sicherheitsdomain umfasst Verschlüsselungszeichen, die vor dem Chipkartenaussteller geheim gehalten werden, um somit eine Trennung der Verschlüsselungssicherheit zwischen dem Aussteller und dem Anwendungsprovider zu ermöglichen. Wenn eine neue Anwendung auf eine Chipkarte geladen wird, verwendet die neu geladene Anwendung ihren verbundenen Sicherheitsdomain- Verschlüsselungsservice. Eine privilegierte Anwendung, die den Aussteller repräsentiert, bezeichnet als Kartendomain, genehmigt Befehle (wie Befehle zur Initialisierung und Personalisierung) durch Aufrufen des Sicherheitsdomain-Verschlüsselungsservices. Auf diese Weise kann ein Laden einer Anwendung auf eine Open-Platform-Chipkarte nach der Ausstellung erreicht werden.
  • Wie oben erwähnt, sind die herkömmlichen Verfahren zur Herstellung von Chipkarten nicht praktisch für die Herstellung von Chipkarten mit Mehrfachanwendungen. Wenige Beteiligte sind bei der Herstellung einer Chipkarte für Einfachanwendung beteiligt: ein Aussteller, ein oder zwei Kartenhersteller, und ein oder zwei Personalisierungsbüros. Echte Chipkarten mit Mehrfachanwendungen benötigen neue und mehr Beteiligte, einschließlich einem oder mehreren Anwendungsprovidern, die Anwendungen entwickeln/betreiben und mit dem Hauptaussteller vertraglich verbunden sind, um ihre Anwendungen auf die Karten des Ausstellers zu laden. Jeder dieser Anwendungsprovider kann mit seinen eigenen (und verschiedenen) Personalisierungsbüros vertraglich verbunden sein. Solche Chipkarten mit Mehrfachanwendungen können auf einen Mehrschritt-Lade- und Personalisierungsvorgang stoßen, an vielerlei Orten (einen für jede der unterschiedlichen Anwendungen), bevor sie tatsächlich ausgestellt werden können. Oder eine solche Chipkarte mit Mehrfachanwendung könnte ausgestellt werden, während nur ein Teil der Anwendungen geladen und personalisiert ist, und können eine weitere Personalisierung erfordern.
  • Herkömmliche Verfahren zur Ausstellung und Verteilung von Karten erfordern, dass die Hardware, die zum Initialisieren und Personalisieren von Chipkarten verwendet wird, für jede neue Kombination eines Chips mit einem bestimmten Satz von Anwendungen neu programmiert wird. Zusätzlich gibt es typischerweise keine Vorkehrungen zum Laden eines Anwendungscodes auf die Karte, der nicht der Code ist, der bei der Herstellung auf die Siliziumkarte gebrannt wurde.
  • Die Herstellung von Karten mit Mehrfachanwendungen kann extrem kompliziert sein und wird nicht oft versucht. Für jede unterschiedliche Kombination von Mehrfachanwendungen, die auf die Chipkarte geladen und personalisiert werden sollen, müssen die Geräte, die während des Herstellvorgangs der Chipkarte verwendet werden, für jede unterschiedliche Kombination von Anwendungen neu programmiert werden. In ähnlicher Weise müsste für jede unterschiedliche Kombination von Mehrfachanwendungen die Personalisierungsdatendatei neu konzipiert werden für jede Kombination. Für jede unterschiedliche Beziehung zwischen dem Aussteller und dem Mehrfachanwendungsprovider müssten die Personalisierungsdaten neu konzipiert werden und in verschiedene Dateien für jede unterschiedliche Beziehung verteilt werden. Auch wenn es praktisch wäre, Karten mit Mehrfachanwendungen mittels des herkömmlichen Kartenherstellungsverfahrens herzustellen, könnte dementsprechend nur eine vorbestimmte Anzahl von Chips und Anwendungen hergestellt werden, ohne wesentliche Kosten pro Karte hervorzurufen.
  • Es wäre wünschenswert, den Herstellungsvorgang für Chipkarten zu automatisieren, so dass große Stapel von Chipkarten hergestellt werden könnten, während es möglich ist, jede Karte für jeden Aussteller, Anwendungsprovider und Kartenhalter anzupassen. Eine Massenproduktion von Chipkarten mit Mehrfachanwendungen zu vernünftigen Preisen wäre ebenfalls wünschenswert. Es wäre ferner wünschenswert, einzigartige Variationen in der Kombination von Anwendungen, die auf eine einzelne Karte geladen werden, zuzulassen und außerdem zu ermöglichen, einzigartige Variationen auf einzelne Karten nach der Ausstellung zu laden. Es wäre außerdem wünschenswert, eine Reproduktion einer verlorenen oder gestohlenen Karte an anderen Orten als denen des Kartenausstellers oder Personalisierungsagenten zu ermög lichen, wie in einer Bankfiliale, ohne einen wesentlichen Zeitverlust.
  • Es kann auch schwierig sein, Anwendungen auf eine Karte nach der Ausstellung zu laden, wenn andere Anwendungen bereits geladen wurden. Wenn nicht genug Speicherplatz für eine neue Anwendung vorhanden ist, wenn eine neue Anwendung einen Konflikt mit einer existierenden Anwendung hervorrufen würde, oder wenn die Betriebssystemversion, die von der Anwendung benötigt wird, nicht die ist, die gerade auf der Karte ist, ist es möglicherweise nicht ratsam, eine neue Anwendung zu laden. Als letztes kann eine neue Anwendung eventuell nicht funktionieren, auch wenn ein Laden nach der Ausstellung erfolgreich war. Deshalb wäre es ferner wünschenswert, Anwendungen erfolgreich auf ausgestellte Chipkarten laden zu können, mit der Zusicherung, dass das Laden erfolgreich sein wird und die Anwendung wie gewünscht funktionieren wird.
  • Zusammenfassung der Erfindung
  • Um das Vorstehende zu erreichen und gemäß dem Zweck der vorliegenden Erfindung, sind ein System und ein Verfahren offenbart, die eine automatisierte Massenherstellung von Chipkartendaten und eine Massenproduktion von Chipkarten ermöglichen. Diese Chipkarten können herkömmliche Chipkarten mit Einfachanwendung oder Chipkarten mit Mehrfachanwendungen sein, die mehr als eine Anwendung umfassen und die Fähigkeit aufweisen, mehr als eine Anwendung zu laden. Zusätzlich ermöglicht ein Ausführungsbeispiel der vorliegenden Erfindung eine Massenproduktion von Chipkarten, die für jeden einzelnen Kartenaussteller, Anwendungsprovider und Kartenhalter individuell angepasst werden können.
  • Der automatisierte Vorgang gemäß einem Ausführungsbeispiel der vorliegenden Erfindung verwendet eine Skriptsprache, die die Kombination aller Herstellungsaspekte einer Karte in einem einheitlichen Skript ermöglicht. Dieses Skript wird unter Verwendung der Skriptsprache und deren besonderen Syntaxregeln automatisch erzeugt und kann einfach verändert und individuell angepasst werden. Das Skript wird in einem Kartenherstellungssystem verwendet, das eine kundenbezogene Chipkarte automatisch herstellen kann. In einem Ausführungsbeispiel der vorliegenden Erfindung kann ein Kunde zu einem einzelnen Ort (z. B. eine Bankfiliale) gehen und eine kundenbezogene Chipkarte erhalten, die während eines einzigen Besuchs bei der Bank für ihn hergestellt wurde. Andere Ausführungsbeispiele der vorliegenden Erfindung erlauben auch, dass eine Karte mit neuen oder überarbeiteten Anwendungen nach der Ausstellung aktualisiert wird.
  • Gemäß einem Aspekt der Erfindung, ist ein Verfahren zum Aufbau eines Chipkarten-Skripts zur Verwendung bei der Herstellung einer Chipkarte vorgesehen, wobei das Verfahren umfasst:
    Empfangen von Anwendungsprofildaten, die typisch für zumindest eine Softwareanwendung, die für die Chipkarte vorgesehen ist, sind, wobei die Anwendungsprofildaten die Anforderungen der zumindest einen Softwareanwendung beschreiben; Empfangen eines Kartenprofils, welches die Ressourcen der Chipkarte beschreibt; und
    Schreiben des Chipkarten-Skripts, wobei das Verfahren dadurch gekennzeichnet ist, dass das Chipkarten-Skript unter Verwendung der Anwendungsprofildaten und des Kartenprofils geschrieben wird.
  • Somit wird ein Skript in einem Ausführungsbeispiel der Erfindung zur Verwendung mit einem Kartenherstellungs-Gerät erzeugt, so dass das Kartenherstellungs-Gerät nicht für jede Änderung in den speziellen Kartenanforderungen neu programmiert werden muss. Das Kartenherstellungs-Gerät folgt den Anweisun gen des Skripts, um eine Chipkarte herzustellen, welche die speziellen Kartenanforderungen erfüllt. Das Skript selbst kann einfach verändert werden, um eine Anpassung einer Chipkarte an die Kundenwünsche zu erlauben.
  • In einem weiteren Aspekt der Erfindung ist ein System zum Aufbau eines Chipkarten-Erzeugungsskripts zur Verwendung bei der Herstellung einer Chipkarte vorgesehen, wobei das System umfasst:
    einen Computer;
    eine erste Computerdatei mit Anwendungsprofildaten, wobei die Anwendungsprofildaten für eine Softwareanwendung, die für die Chipkarte vorgesehen ist, typisch sind, wobei die Anwendungsprofildaten die Anforderungen der Softwareanwendung beschreiben;
    eine zweite Computerdatei mit Kartenprofildaten, wobei die Kartenprofildaten die Ressourcen der Chipkarte beschreiben; und
    eine Software zum Durchführen der Schreibfunktion eines Chipkarten-Erzeugungsskripts unter Verwendung der ersten und der zweiten Computerdatei.
  • Gemäß einem weiteren Aspekt der Erfindung ist eine Chipkarten-Skriptdatenstruktur, integriert in ein Computer-lesbares Medium, vorgesehen, wobei die Chipkarten-Skriptdatenstruktur umfasst:
    einen physikalischen Abschnitt mit physikalischen Attributen der Chipkarte;
    einen Initialisierungsabschnitt mit allgemeinen Kartendaten, die auf die Chipkarte geschrieben werden sollen;
    einen Personalisierungsabschnitt mit einzigartigen Daten, die auf die Chipkarte geschrieben werden sollen; und
    eine Datentabelle mit Werten oder Verweisen für Daten, die von einer Anwendung der Chipkarte verwendet werden, wobei die Skriptdatenstruktur geeignet ist für die Herstellung einer Chipkarte mit der Anwendung.
  • Um den komplizierten Vorgang der Erzeugung von Chipkarten zu automatisieren, werden die Chipkarten unter Verwendung verschiedener Profile beschrieben, z. B. ein Kartenprofil, Anwendungsprofile und ein Ausstellerprofil. Das Kartenprofil z. B. beschreibt die Ressourcen, die auf der Karte verfügbar sind und dokumentiert die Softwareinfrastruktur der Karte, die verfügbaren Ressourcen (einschließlich aller Speicherarten), jede Anwendung, die bereits auf der Karte vorhanden ist, den Lebensdauerstatus dieser Anwendungen und die physikalischen Attribute der Karte. Um bei der Bestimmung, welche Anwendungen gemeinsam auf der Karte vorhanden sein können, zu helfen, werden die Anwendungsanforderungen in einem Anwendungsprofil dokumentiert. Ein Anwendungsprofil identifiziert den Quellcode der Anwendung und umfasst die Ressourcenanforderungen einer Anwendung, wie Speicher, Betriebssystemversion, Sicherheit und physikalische Anforderungen der Karte.
  • Für eine vorgegebene, herzustellende Chipkarte werden die ausgewählten Anwendungsprofile der Anwendungen, die auf der Karte installiert werden sollen, verglichen, um ihre Kompatibilität sicherzustellen. Diese Profile werden auch auf Kompatibilität mit allen Kartenprofilen überprüft, um ein passendes Kartenprofil zu finden. Ein Kartenerzeugungsskript kann dann auf der Grundlage der ausgewählten Anwendungsprofile und des Kartenprofils erstellt werden. In einem Ausführungsbeispiel ist das Kartenerzeugungsskript eine Beschreibung in natürlicher Sprache der Funktionen und Daten, die erforderlich sind, um eine Chipkarte mit Mehrfachanwendungen oder eine herkömmliche Chipkarte (mit Einfachanwendung) zu erzeugen. Dieses Kartenerzeugungsskript kann die Initialisierung und Personalisierung für beide Arten von Karten umfassen, und es kann ferner das Laden des Anwendungscodes für die Karten mit Mehrfachanwendungen beinhalten.
  • In einem Ausführungsbeispiel ist das Skript Verkäuferunabhängig und ist ein standardisiertes Verfahren zur Beschreibung der Erzeugung nahezu jeder Chipkarte. Ein Skript ist maschinenlesbar, wodurch den Verkäufern, die ihre eigenen Parser schreiben, ermöglicht wird, das Skript zu verwenden, um die Steuerungen ihrer eigenen Personalisierungs-Geräte anzusteuern. Der Initialisierungsbereich des Skripts kann verwendet werden, um die Geräte zur Durchführung der Initialisierung anzusteuern.
  • Alternativ kann das gesamte Skript verwendet werden, um eine Desktopeinheit anzusteuern, die einmalige Karten in einer Bankfiliale herstellt. Skripts für eine Reihe von Anwendungen können erzeugt und archiviert werden, um die Erzeugung einer einzelnen kundenbezogenen Karte oder die Erzeugung von Millionen Karten zu ermöglichen. In einem weiteren Ausführungsbeispiel steuert das Skript einen Fernserver, der mit einer lokalen Kartenleseschnittstelle kommuniziert, in welche die Chipkarte physikalisch eingeführt wird, wodurch eine Fern-Personalisierung und/oder Initialisierung online ermöglicht wird, wie in einem Vorgang nach der Ausstellung, wenn sich die Karte in den Händen des Kartenhalters befindet.
  • Somit ermöglichen die Ausführungsbeispiele der vorliegenden Erfindung eine Automatisierung dessen, was heute ein komplizierter manueller Vorgang ist. Das Laden der Anwendungen auf die Karten geschieht automatisch, unter Verwendung der Techniken der vorliegenden Erfindung; der vormals manuelle Vorgang der Programmierung der Initialisierungs- und Personalisierungshardware für jede Kombination von Karte und Anwendung kann gemäß den Ausführungsbeispielen der Erfindung ebenfalls automatisiert werden. Auf diese Weise erlauben die Ausfüh rungsbeispiele der Erfindung eine schnelle Entwicklung und einen schnellen Einsatz der Chipkarten.
  • In einem weiteren Ausführungsbeispiel der Erfindung wird ein aktualisiertes Kartenprofil auch vom Skriptschreiber hergestellt. Das aktualisierte Kartenprofil beschreibt die Ressourcen der Karte, sobald eine oder mehrere Anwendungen geladen wurde(n) und die Karte ausgestellt wurde. Somit wird das ursprüngliche Kartenprofil (das eine Leerkarte beschreibt) aktualisiert, um ein bestimmtes Kartenprodukt zu beschreiben. Das aktualisierte Kartenprofil kann verwendet werden, wenn es erwünscht ist, nach der Ausstellung der Karte Anwendungen zu laden. Durch Vergleich des aktualisierten Datenprofils mit den erwünschten Anwendungsprofilen, die nach der Ausstellung geladen werden sollen, kann ein neues Kartenskript erzeugt werden, das die Anwendungen erfolgreich laden wird und die Sicherheit gewährleistet, dass die neuen Anwendungen wie gewünscht funktionieren werden.
  • Kurze Beschreibung der Zeichnungen
  • 1 zeigt ein Flussdiagramm, das ein Verfahren des Standes der Technik zur Herstellung einer herkömmlichen Chipkarte zeigt.
  • 2 zeigt ein Flussdiagramm, das ein Verfahren zur Herstellung einer Chipkarte mit Mehrfachanwendungen unter Verwendung eines herkömmlichen Verfahrens zur Herstellung von Chipkarten zeigt.
  • 3 zeigt ein Blockdiagramm eines Systems zur Herstellung einer Chipkarte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 4 zeigt ein Flussdiagramm einer höheren Ebene, das ein Verfahren zum Aufbau eines Kartenerzeugungsskripts beschreibt.
  • 5 zeigt eine Darstellung eines Beispiels von Abschnitten innerhalb eines Skripts gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.
  • 6A–6C zeigen detaillierte Flussdiagramme, die ein Verfahren zum Aufbau eines Skripts für eine herkömmliche Chipkarte zeigen.
  • 7A–7C zeigen detaillierte Flussdiagramme, die ein Verfahren zum Aufbau eines Skripts für eine Chipkarte mit Mehrfachanwendungen beschreiben.
  • 8 zeigt ein Flussdiagramm, das ein Verfahren zur Herstellung einer herkömmlichen Chipkarte beschreibt.
  • 9 zeigt ein Flussdiagramm, das ein Verfahren zur Herstellung einer Chipkarte mit Mehrfachanwendungen beschreibt.
  • 10 zeigt ein Beispiel einer Skriptsequenztabelle.
  • 11 zeigt ein Beispiel einer Konfliktbestimmungstabelle.
  • 12 zeigt ein Flussdiagramm, das ein Verfahren zur Herstellung eines aktualisierten Kartenprofils gemäß einem Ausführungsbeispiel beschreibt.
  • 13 zeigt ein Blockdiagramm eines Systems zur Installation einer Anwendung nach der Ausstellung.
  • 14 ist ein Flussdiagramm, das ein Verfahren zum Laden einer Anwendung nach der Ausstellung beschreibt.
  • 15 und 16 erläutern ein Computersystem 900, das für die Implementierung der Ausführungsbeispiele der vorliegenden Erfindung geeignet ist.
  • Genaue Beschreibung der Erfindung
  • Die vorliegende Erfindung ist sowohl auf herkömmliche Chipkarten mit Einfachanwendung als auch auf Chipkarten mit Mehrfachanwendungen anwendbar. 1 und 2 zeigen frühere Verfahren zur Herstellung einer Chipkarte mit Einfachanwendung und einer Chipkarte mit Mehrfachanwendungen. 1 zeigt ein Beispiel, bei dem der Anwendungscode in das ROM des Chips „eingebrannt" wird. 2 zeigt ein Beispiel, bei dem der Anwendungscode in den nicht-flüchtigen Speicher des Chips geladen wird.
  • Chipkartenherstellung nach dem Stand der Technik
  • 1 ist ein Flussdiagramm eines Verfahrens des Standes der Technik zur Herstellung einer Chipkarte. Ein Aussteller sendet Chipkarten-Anwendungsspezifikationen an einen Kartenhersteller (Schritt 30); der Kartenhersteller schreibt dann den Anwendungscode, typischerweise in Assembler (Schritt 32). Der Anwendungscode wird dann an einen Chiphersteller gesandt, der den in Assembler geschriebenen Code in die Speicherbereiche auf einem Chip brennt (Schritt 34). Der Chiphersteller schickt dann den maskierten Chip zurück an den Kartenhersteller, der den Chip mit der Anwendung darauf empfängt (Schritt 36). Der Kartenhersteller integriert dann den Chip auf oder in der Kunststoffkarte (Schritt 38).
  • Das Initialisierungs-Gerät wird dann programmiert, um die spezielle Anwendung, die auf der Karte installiert wurde, zu ini tialisieren (Schritt 40). Die Initialisierungsdaten werden dann auf den Chip geschrieben, typischerweise vom Kartenhersteller (Schritt 42). Das Personalisierungs-Gerät wird dann programmiert, um die spezielle Anwendung, die auf der Karte installiert und initialisiert wurde, zu personalisieren (Schritt 44). Es ist üblich, die Karte zu einem Personalisierungsbüro zu schicken, um die Karte zu personalisieren. Das Personalisierungsbüro schreibt die Personalisierungsinformation, wie kundenspezifische Daten, die vom Kartenaussteller in vorverarbeiteten Personalisierungsdatendateien zur Verfügung gestellt werden, auf die Karte (Schritt 46). Abgeleitete oder einzigartige Schlüssel (pro Karte) können ebenfalls während der Personalisierung auf die initialisierte Karte aufgebracht werden. Abgeleitete oder einzigartige Kartenschlüssel werden üblicherweise für Anwendungs- und Sicherheitszwecke verwendet. Schließlich, nachdem der Chip installiert und die Karte initialisiert und personalisiert wurde, wird sie an den Aussteller geliefert und die Chipkarte wird für einen Kunden ausgegeben (Schritt 48).
  • 2 ist ein Flussdiagramm eines Beispiels, wie eine Chipkarte mit Mehrfachanwendungen unter Verwendung eines Verfahrens des Standes der Technik hergestellt werden kann. Der bereits komplizierte Vorgang der Herstellung einer herkömmlichen Chipkarte oder Chipkarte mit Einfachanwendung wird seit der Einführung von Karten mit Mehrfachanwendungen, die verschiedene Anwendungen enthalten können, die zu verschiedenen Zeiten während der Nutzdauer der Karte geladen werden, noch schwieriger. Diese Anwendungen könnten von verschiedenen Anwendungsprovidern geschrieben und „besessen" und unterstützt werden.
  • Herkömmliche Verfahren der Herstellung und Ausstellung von Chipkarten sind nicht praktikabel für Karten mit Mehrfachanwendungen. Herkömmliche Verfahren erfordern, dass die Hardware, die zum Initialisieren und Personalisieren der Karten verwendet wird, für jede neue Kombination von Chip und Anwendungen neu programmiert wird; außerdem gibt es keine Vorkehrungen für ein Laden von Anwendungen auf die Karte nach der Herstellung. Die Herstellung von Karten mit Mehrfachanwendungen ist sehr kompliziert und wird nicht oft versucht.
  • In dem in 2 gezeigten Verfahren sendet ein Aussteller Kartenspezifikationen an einen Kartenhersteller (Schritt 50). Der Kartenhersteller schreibt dann eine Karteninfrastruktur basierend auf den Kartenspezifikationen (Schritt 52). Ein Chiphersteller brennt dann die Infrastruktur auf einen Chip (Schritt 54). Der Kartenhersteller verbindet dann den Chip mit einer Karte, wodurch eine Karte mit der erforderlichen Infrastruktur, um die verschiedenen Kartenanwendungen zu unterstützen, zur Verfügung gestellt wird (Schritt 56). Der Kartenhersteller programmiert dann das Initialisierungs-Gerät, um verschiedene Anwendungen auf die Karte zu laden (Schritt 58).
  • Der Kartenhersteller nutzt dann das Initialisierungs-Gerät, um Anwendungen auf die Karte zu laden (Schritt 60). Der Kartenhersteller programmiert die Geräte außerdem dazu, diese Anwendungen zu initialisieren (Schritt 62). Durch Verwendung dieses Geräts initialisiert der Kartenhersteller die Anwendungen auf der Karte (Schritt 64). Der Kartenhersteller (oder wahrscheinlicher ein Kartenpersonalisierungsbüro) programmiert das Personalisierungs-Gerät, um diese Anwendungen zu personalisieren (Schritt 66). Der Aussteller bereitet die Personalisierungsdatendateien, welche die kundenspezifischen Daten enthalten, vor. Ein Personalisierungsbüro (oder ein Kartenhersteller) schreibt dann diese Personalisierungsdaten auf die Karte (Schritt 68). Die Karte kann dann ausgestellt werden (Schritt 70).
  • Somit erfordert das herkömmliche Verfahren viele Schritte an vielen Orten und macht den Kartenaussteller (oder Anwendungs provider) abhängig von dem Kartenhersteller und dem Personalisierungsbüro. Zusätzlich ist der Personalisierungsschritt des herkömmlichen Verfahrens extrem teuer und zeitaufwändig. Da nahezu die gesamte Ausrüstung, die bei der Initialisierung und Personalisierung involviert ist, vorprogrammiert ist, muss jedes Mal, wenn eine Änderung in den Spezifikationen oder eine Änderung des Herstellers der Karte auftritt, die Software für die verschiedenen Teile der Herstellungsgeräte neu geschrieben werden. Diese Einschränkungen machen es schwierig, Chipkarten auszustellen, und noch schwieriger, Karten mit Mehrfachanwendungen auszustellen und zu aktualisieren. Dementsprechend ist derzeit eine Massenproduktion von Chipkarten, die für jeden Aussteller oder Anwendungsprovider angepasst werden müssen, nicht praktikabel. Wie vorher erläutert, ist es noch schwieriger, eine Massenproduktion für kundenbezogene Chipkarten mit Mehrfachanwendungen für einen Aussteller, einen Anwendungsprovider oder für einen Kunden zu versuchen. Um die Sache weiter zu verkomplizieren, können Karten mit Mehrfachanwendungen im Allgemeinen nach der Ausstellung nicht aktualisiert werden. Derzeitige Verfahren unterstützen nicht ohne weiteres die Herstellung und Ausstellung dieser Kartenarten, wie beschrieben wurde.
  • Chipkarten-Erzeugungssystem
  • 3 ist ein Blockdiagramm eines Systems 200 zur Herstellung einer Chipkarte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Anwendungsprofile 201 bis 203 werden in ein Skriptgerüst 208 eingegeben. Das Skriptgerüst 208 bestimmt, ob es Konflikte zwischen den Anwendungsprofilen 201 bis 203 gibt. Ein Kartenprofil 206, ein Ausstellerprofil 207, eine Benutzereingabe 209, eine Skriptsequenztabelle 220 und eine Konfliktbestimmungstabelle 222 sind ebenfalls in das Skriptgerüst 208 eingegeben. Der Datenverbund, der im Skriptgerüst 208 abgeleitet wird, wird dann in ein Kartenerzeugungsskript 210 aufge nommen. Weitere Einzelheiten des Skriptgerüsts 208 werden später in Verbindung mit 4 bis 7 erläutert. Als Option wird in einem weiteren Ausführungsbeispiel ein aktualisiertes Kartenprofil 230 erzeugt, wie genauer in 12 erläutert.
  • Ein Anwendungsprofil wird vorzugsweise vom Entwickler der Anwendung erstellt und kann jedes beliebige Format und jede Sprache haben. Im speziellen hier beschriebenen Ausführungsbeispiel verwendet ein Anwendungsprofil die Skriptsprachen-Syntaxregeln, wie sie im Anhang gezeigt sind. Für Anwendungen, die in Assembler (oder einer anderen passenden Sprache) vom Chip- oder Kartenhersteller geschrieben wurden (native Anwendungen), kann der Hersteller das Anwendungsprofil erzeugen. Jedes Anwendungsprofil 201 bis 203 umfasst eine Vielzahl von Elementen, die eine Anwendung definieren: Anwendungsname, Beschreibung der Anwendung, Bezugnahme auf den Anwendungscode oder den tatsächlichen Code, Hardwareanforderungen der Karte (wie Speicheranforderungen und Verarbeitungsanforderungen), Softwareversionsanforderungen, Anforderungen hinsichtlich Kartendomain und Sicherheitsdomain (für Open Platform entsprechende Anwendungen), Sicherheitsanforderungen, Datenwörterbuch, Datenmappinginformation, physikalische Eigenschaften, Anforderungen an die Lebensdauer der Anwendung und Standarddatenwerte. Beispiele für Elemente, die die Speicheranforderungen einer Anwendung definieren, umfassen eine Identifikation der Größe des elektrisch löschbaren, programmierbaren Nur-Lese-Speichers (EEPROM) und des Direktzugriffsspeichers (RAM). Beispiele für Elemente, die die Anforderungen an die Anwendungsverarbeitung definieren, umfassen eine Identifikation der CPU und Chipkernanforderungen und alle Chiffrieranforderungen.
  • Beispiele für Elemente, die die Versionsanforderungen einer Anwendungssoftware definieren, umfassen eine Identifikation der Version jeder Software, die von der Anwendung auf der Karte benötigt wird, wie die erforderliche Version der virtuellen Maschine JavaCardTM (JCVM). Domainanforderungen der Anwendung können für Open-Platform-Chipkarten als Teil der Anwendungsprofile 201 bis 203 festgelegt werden. Domainanforderungen umfassen Kartendomainanforderungen und Sicherheitsdomainanforderungen. Kartendomainanforderungen der Anwendung umfassen eine Identifikation der bestimmten benötigten Kartendomain und Version. Sicherheitsdomainanforderungen der Anwendung umfassen eine Identifikation der bestimmten benötigten Sicherheitsdomain und Version.
  • Beispiele für Sicherheitsanforderungen der Anwendung umfassen Initialisierungs- und Personalisierungsschlüssel, Daten, die einen Chiffrieralgorithmus identifizieren, eine Charakterisierung des Chiffrierschlüssels, Schlüsselversionen usw. Die Sicherheitsanforderungen können von einem Anwendungslebensdauerzustand zum anderen variieren. Die Anwendungsprofile 201 bis 203 können Anforderungen für jeden Lebensdauerzustand oder nur einen Teil davon umfassen. Jedes Profil 201 bis 203 kann außerdem ein Datenwörterbuch umfassen, das alle Kartendatenelemente, die für jede Anwendung relevant sind, auflistet und beschreibt.
  • Jedes Anwendungsprofil kann auch eine Datenmappinginformation bzw. Datenzuordnungsinformation umfassen. Diese Information stellt entweder die Datenelemente, die von einer Anwendung benötigt werden (eventuell durch Verwendung eines Standardwerts) zur Verfügung, liefert dem Anwender schnelle Informationen, so dass ein Datenelement interaktiv von einem Anwender eingeben werden kann, oder gibt eine Referenz an, wo das Datenelement gefunden werden kann. Die Datenmappinginformation verbindet Datenelemente, die von einer Anwendung benötigt werden, mit einer bestimmten Stelle auf der Chipkarte, z. B. können manche Datenelemente einer Datei auf der Karte oder einem Datenobjekt zugeordnet werden. In einem Ausführungsbeispiel der Erfindung hat jede Anwendung ihre eigene Datenelementtabelle, die be schreibt, wie die für die Anwendung einzigartigen Daten erhalten werden können. Beispiele für diese Daten umfassen Kontonummer, Name des Kartenhalters, Anzahl der Male, wie oft eine persönliche Identifikationsnummer (PIN) falsch eingegeben werden darf, bevor das Konto gesperrt wird, die Währung, mit der die Chipkarte arbeitet usw. Für Karten mit einer Dateistruktur kann die Datenelementtabelle eine Bezugnahme enthalten, die anzeigt, wo jedes Datenelement in einer Datei zu finden ist. Die Tabelle kann auch Standardwerte, Benutzer-Befehlsaufforderungen und/oder den Namen eines Datenobjekts, das einen Wert für ein Datenelement liefert, zur Verfügung stellen.
  • Die Anwendungsprofile 201 bis 203 können auch Elemente umfassen, welche die physikalischen Eigenschaften jeder Karte, die eine Anwendung eventuell benötigt, definieren. Beispiele für die physikalischen Eigenschaften sind die Graphiken, Hologramme, Prägungen und Magnetstreifen der Chipkarte. Zusätzlich hat jede Anwendung eine Lebensdauer, die mit dem Laden einer Anwendung beginnt und mit Blockierung oder Ablauf endet. Jeder Anwendungslebensdauerzustand kann seine eigenen Anforderungen bezüglich der Handhabung und Verwaltung durch die Chipkarten-Herstellungssysteme aufweisen. Das Anwendungsprofil informiert über die Lebensdauerzustände für jede Anwendung und zeigt an, in welchem Zustand sich die Anwendung bei Kartenerzeugung befindet.
  • Es gibt im Allgemeinen nur ein Kartenprofil 206 pro Kartenmaske. Beispiele für Informationen, die in dem Kartenprofil 206 enthalten sein können, umfassen: eine Identifizierungseinrichtung für das Modell der zentralen Recheneinheit (CPU), eine Identifizierungseinrichtung für den Chiffrierprozessor (falls vorhanden), die Größe oder Menge des verfügbaren Speichers, Softwareversionsnummern, Sicherheitsanforderungen für die Karte und Sicherheitsdomains (falls vorhanden), Identifikation der Anwendung (falls vorhanden), die bereits auf der Karte geladen ist (z. B, im ROM), physikalische Eigenschaften der Karte, und Anwendungslebensdauerinformationen für Anwendungen, die vom Kartenhersteller im Speicher vorinstalliert sind (Lebensdauerzustände, aktueller Zustand). Die Identifizierungseinrichtung für das Modell der CPU dient zum Identifizieren des Herstellers und Modells des Chipkarten-Chips. Die Identifizierungseinrichtung für den Chiffrierprozessor identifiziert den Chiffrier-Coprozessor, der auf der Chipkarte für Chiffrierfunktionen benutzt wird. Die Identifikation des verfügbaren Speichers identifiziert den Typ des verfügbaren Speichers, wie RAM oder EEPROM.
  • Beispiele für die Softwareversionsnummern umfassen Versionsnummern für verschiedene Bestandteile der Karte, wie das Betriebssystem, ein Organisationsprogramm der Karte (falls vorhanden) und die JCVM (falls vorhanden). Beispiele für Informationen, welche die Sicherheitsanforderungen identifizieren, umfassen Daten, welche die Kartendomain und Sicherheitsdomain identifizieren, und Informationen über die Chiffrierschlüssel, die sie umfassen (z. B. Schlüsseleigenschaften, Version, Chiffrieralgorithmus usw.). Die Identifikation der Anwendung liefert den Namen und die Versionsnummer jeder Anwendung, die bereits in der Karte vorhanden ist. Beispiele für physikalische Eigenschaften umfassen Graphiken, Prägungen und Magnetstreifeninformationen. Anwendungslebensdauer-Zustandsinformationen für Anwendungen, die bereits entweder in das ROM oder EEPROM der Karte geladen wurden, können sich vom „geladenen" Zustand zum „initialisierten", „personalisierten", „blockierten" oder „gelöschten" Zustand verändern.
  • Das Ausstellerprofil 207 ist üblicherweise eine Computerdatei, die allgemeine Kartendaten umfasst, d. h. Daten, die für einen Satz von herzustellenden Karten gleich sind. Allgemeine Daten umfassen: die Identifizierung des Ausstellers (z. B. BIN), An zahl der zu erzeugenden Sicherheitsdomains, Niveau der Sicherheitsanforderungen, das während Initialisierung und Personalisierung angewandt werden soll, usw.
  • Das Skriptgerüst 208 erzeugt dann ein Kartenerzeugungsskript 210, das die Informationen von den Anwendungsprofilen 201 bis 203, dem Kartenprofil 206, dem Ausstellerprofil 207 und der Benutzereingabe 209 (falls benötigt) verwendet. Das Skriptgerüst 208 kann in jedem passenden Softwaretool integriert sein. Die Benutzereingabe kann zwei Arten von Daten umfassen: allgemeine Kartendaten und einzigartige Kartendaten. Die allgemeinen Kartendaten sind Daten, die für jede Karte im Personalisierungsstapel gleich sind. Die einzigartigen Kartendaten sind für jede Karte anders. Der Benutzer kann tatsächliche Daten, eine Bezugnahme auf ein anderes Datenelement, eine Bezugnahme auf eine Stelle auf der Chipkarte, oder eine Bezugnahme auf ein Feld in der Ausstellerpersonalisierungsdatei, einer Datenbank oder anderen Quelle eingeben.
  • Das Kartenerzeugungsskript 210 beschreibt Vorgänge und Daten, die erforderlich sind, um eine Chipkarte aus einem Kunststoffrohling und/oder einem nicht initialisierten Chip zu erzeugen. Das Kartenerzeugungsskript 210 ist in Abschnitte unterteilt, um physikalische und logische Attribute der Chipkarte zu beschreiben. Es kann auch eine kombinierte Datenelementtabelle enthalten, die erforderliche Datenelemente von jeder Anwendung Feldern in der Ausstellerpersonalisierungsdatei, einer Datenbank, anderen Quellen zuordnet und/oder Standardwerte liefert. Die Datenelemente können auch anderen Quellen, wie Stellen auf der Chipkarte, zugeordnet werden oder der Benutzer kann aufgefordert werden, Informationen einzugeben.
  • Im Allgemeinen kann das Kartenerzeugungsskript 210 auch Standarddatenwerte umfassen oder Bezugnahmen auf Kartenhalterdaten 214 (d. h. Verweise auf die Stelle der Kartenhalterdaten) in nerhalb der Kartenhalterinformationsdateien aufweisen, die vom Kartenaussteller oder Anwendungsprovider zur Verfügung gestellt werden. Beispiele für Kartenhalterdaten umfassen den Namen des Kartenhalters und die persönliche Identifikationsnummer (PIN) des Kartenhalters. Weitere Einzelheiten zur Funktion des Skriptgerüsts 208 sind in 6 und 7 beschrieben. Ein Beispiel eines Kartenerzeugungsskripts 210 ist in 5 und 10 gezeigt.
  • Das Kartenerzeugungsskript 210 wird dann in einem Kartenherstellungssystem 216 verwendet. Das Kartenherstellungssystem 216 kombiniert das Kartenerzeugungsskript 210 mit einer zu bearbeitenden Karte 212 und Kartenhalterdaten 214. Weitere Einzelheiten der Chipkartenherstellung werden in Verbindung mit 8 und 9 erläutert. Das Kartenherstellungssystem 216 führt dann zu einer Chipkarte 218, die fertig zum Ausstellen ist.
  • Aufbau eines Kartenerzeugungsskripts
  • 4 ist ein Flussdiagramm einer höheren Ebene zum Aufbau eines Kartenerzeugungsskripts 210 zur Verwendung bei der Herstellung einer Chipkarte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Eine Liste der verfügbaren Anwendungen wird zu Beginn ausgewählt (Schritt 300). Für jede ausgewählte Anwendung wird ein Anwendungsprofil einschließlich der oben erwähnten Informationen erstellt. Diese Profile werden dann ausgewählt, um die Anwendungen darzustellen, die auf der Chipkarte installiert werden sollen. Zum Beispiel können die Anwendungsprofile 201 bis 203 der 3 zuerst ausgewählt werden. Die Kompatibilität zwischen den ausgewählten Anwendungen wird dann überprüft (Schritt 302). Wenn irgendwelche der Anwendungen mit den anderen nicht kompatibel sind, dann kann eine neue Anwendung gewählt werden, eine neue Version der inkompatiblen Anwendung kann gewählt werden oder eine inkompatible Anwendung kann weggelassen werden.
  • Ein Kartenprofil wird ebenfalls ausgewählt (Schritt 304). Für die Zwecke dieser Offenbarung wird ein Ausführungsbeispiel, bei dem die Anwendungen zuerst ausgewählt werden, gezeigt. Die Fachleute auf dem Gebiet werden beim Lesen dieser Offenbarung feststellen, dass Ausführungsbeispiele der Erfindung implementiert werden können, indem ein Kartenprofil ausgewählt wird, bevor die Anwendungsprofile ausgewählt werden. Die Kompatibilität zwischen den ausgewählten Anwendungen und der vom Kartenprofil beschriebenen Chipkarte wird dann überprüft (Schritt 306). Wenn eine Anwendung und das Kartenprofil nicht kompatibel sind, kann eine neue Anwendung oder eine neue Version der Anwendung ausgewählt werden. Alternativ kann die inkompatible Anwendung weggelassen werden, ein neues Kartenprofil kann gewählt werden oder das Kartenprofil kann verändert werden. Die Kompatibilität zwischen den ausgewählten Anwendungen und der Chipkarte wird überprüft, indem die Anforderungen jeder Anwendung erneut geprüft werden. Beispiele für Konflikte umfassen: die Kapazität des EEPROM oder RAM kann für bestimmte Anwendungen unzureichend sein, die CPU kann für eine Anwendung nicht ausreichend sein, eine für die Personalisierung erforderliche Sicherheitsdomain ist nicht vorhanden, usw.
  • Die Ausstellerprofildaten werden beim Vorgang des Aufbaus eines Kartenerzeugungsskriptes 210 ebenfalls verwendet (Schritt 308). Ein Ausstellerprofil umfasst allgemeine Kartendaten (Daten, die für einen Satz von herzustellenden Karten gleich sind), wie den Namen und die Adresse des Ausstellers. Vorzugsweise werden die Kartenhalterdaten 214 während der Erzeugung einer Karte in das Kartenerzeugungssystem 216 eingegeben. Die Kartenhalterdaten können Daten umfassen, die nur für den Kartenhalter gelten, wie der Name des Kartenhalters, die Kreditlinie, bevorzugte Sitze im Flugzeug, usw. Es wird jedoch in Erwägung gezogen, dass Kartenhalterdaten 214 während des Aufbaus des Kartenerzeugungsskriptes ausgewählt werden können und ein Teil des Skripts werden. In einem weiteren Ausführungsbeispiel sind Bezugnahmen auf Kartenhalterdaten in diesem Schritt vorgesehen, während die tatsächlichen Daten während der Verwendung des Kartenherstellungssystems 216 abgerufen werden.
  • Ein Kartenerzeugungsskript wird dann unter Verwendung der in Schritt 300 bis 310 ausgewählten Informationen erstellt (Schritt 312). Im Allgemeinen kann jede beliebige Anzahl von Anwendungsprofilen mit einem Kartenprofil und einer Benutzereingabe kombiniert werden, um ein Kartenerzeugungsskript zu erstellen. Das Skript wird dann für jedes Kartenprodukt, das erzeugt werden soll, ausgestellt. Einzelheiten des Inhalts der Abschnitte des Kartenerzeugungsskripts werden später unter Bezugnahme auf 5 und 10 beschrieben. Weitere Einzelheiten des Aufbaus des Kartenerzeugungsskripts werden später unter Bezugnahme auf 6 und 7 beschrieben. Eine Chipkarte kann dann unter Verwendung des vervollständigten Skripts erzeugt werden, wie in Verbindung mit 8 und 9 erläutert werden wird.
  • 5 ist eine Darstellung eines beispielhaften Blockdiagramms eines Kartenerzeugungsskriptes gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Im Allgemeinen kann ein Skript in jeder passenden Kartenerzeugungssprache und -syntax geschrieben werden. Ein Beispielskript, das einen bestimmten Satz von Syntaxregeln verwendet, ist im Anhang gezeigt. Das Skript selbst beschreibt die Funktionen und Daten, die erforderlich sind, um aus unspezifischem weißen Kunststoff eine Chipkarte zu erzeugen. Es liefert Funktionen und Daten zum Laden, Installieren und Registrieren der gewünschten Anwendungen; es ist auch in der Lage, Anwendungen mit Standarddatenwerten, die von einem Anwender geliefert werden, zu initialisieren, und eine Karte mit Daten speziell für den Kartenhalter und die Anwendung zu personalisieren. In einem Ausführungsbeispiel der Erfindung ist das Skript in Abschnitte unterteilt, welche die physikalischen und logischen Attribute der Chipkarte beschreiben, und enthält eine Datenelementtabelle, welche den für jede Anwendung erforderlichen Datenelementen Stellen in der Kartendateistruktur zuordnet. Der Anhang zeigt eine mögliche Implementierung eines einfachen Kartenerzeugungsskripts, das bestimmte Syntaxregeln verwendet. Natürlich kann ein Skript implementiert werden, das irgendeinen passenden Satz von Syntaxregeln verwendet.
  • Das gezeigte Skript umfasst verschiedene Abschnitte, einschließlich Abschnitte für: Identität 800, physikalische Attribute 802, Dateistruktur 804, Ladefunktionen 806, Initialisierungsfunktionen 808, Personalisierungsfunktionen 810, Datenelementtabelle 812 und Sicherheitsfunktionen 814. Der Identitätsabschnitt 800 kann den Namen, die Anwendungsidentifizierungen und Lebensdauerbeschreibungen aller Anwendungen auf der Karte, einschließlich der Sicherheitsdomains, umfassen. Eine Maskenidentifikationsnummer, eine Kartenarchitekturidentifizierung (herkömmlich oder Mehrfachanwendung), der Lebensdauerzustand jeder Anwendung bei Beendigung der Kartenerzeugung usw. können ebenfalls beinhaltet sein.
  • Physikalische Attribute 802 können Stelleninformationen beinhalten und Daten für: Strichcode, Prägung, Magnetstreifen, Textaufdruck (Vorder- und Rückseite), Hologramm und Graphiken. Eine Angabe des I/O-Typs der Karte, z. B. kontaktherstellend oder kontaktlos, kann ebenfalls beinhaltet sein. Die Dateistruktur 804 kann Dateistrukturen aller Anwendungen und deren Dateninhalten aufweisen. Es kann eine Dateistruktur für jede Anwendung oder eine kombinierte Dateistruktur, die alle Anwendungen vertritt, vorhanden sein.
  • Die Ladefunktionen 806 können die Funktionen zum Laden, Installieren und Registrieren umfassen, die von den Anwendungen und Sicherheitsdomains benötigt werden. Die Initialisierungs funktionen 808 können Funktionen zum Schreiben allgemeiner Kartendaten auf die Karte und zum Erzeugen der Dateistruktur (wenn noch nicht durchgeführt) beinhalten. Die Personalisierungsfunktionen 810 umfassen Funktionen zum Schreiben von einzigartigen Kartendaten auf die Chipkarte. Die Inhalte der Datenelementtabelle 812 umfassen Beschreibung und Werte (oder Bezugnahmen) aller Karten- und Anwendungsdatenelemente. Die Sicherheitsfunktionen 814 umfassen Chiffrierung, Dechiffrierung und Chiffrierschlüssel-Ableitungsfunktionen für die Karte und die Anwendungen, sowie Chiffrierschlüssel, wenn gewünscht. In einem Ausführungsbeispiel erzeugt das Personalisierungs-Gerät abgeleitete Schlüssel zum Laden auf die Karte unter Verwendung der einzigartigen Kartendaten wie Kontonummer, Benutzerdaten, usw.
  • 6A bis 6C sind ein Flussdiagramm zum Aufbau eines Kartenerzeugungsskripts 210 für eine herkömmliche Chipkarte oder eine Chipkarte mit Mehrfachanwendungen gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Dieser Vorgang kann auf jedem passenden Computer und in jeder passenden Computersprache implementiert werden. In einem Ausführungsbeispiel wird dieser Vorgang in der Programmiersprache C++ implementiert. Im Allgemeinen mischt der Vorgang die Abfolge der Anwendungsprofile mit dem Kartenprofil und bewertet sie dann auf Kompatibilität. Zusätzlich verwendet der Vorgang die Anwendungsprofile und das Kartenprofil, um alle erforderlichen Datenelemente in einer kombinierten Datenelementtabelle zu sammeln.
  • Die Anwendungsprofile werden zu Beginn ausgewählt (Schritt 500) und dann bewertet, um ihre Kompatibilität miteinander zu überprüfen. In einem Ausführungsbeispiel liest der Vorgang eine „Konfliktbestimmungstabelle", welche die Überprüfungen beschreibt, die durchgeführt werden sollen (sowohl für die Anwendungen als auch die Karte). 11 ist ein Ausführungsbeispiel einer einfachen Konfliktbestimmungstabelle 222, die ver schiedene Überprüfungen aufführt, die durchgeführt werden sollen. Als Beispiel umfasst die Tabelle 222 eine Versionsüberprüfung für das Betriebssystem, die JCVM, EMV usw. und Speicherüberprüfungen, um sicherzustellen, dass die Karte genug Speicher für eine Anwendung hat. Natürlich sind kompliziertere Tabellen möglich und die durchzuführenden Überprüfungen können auch auf andere Weise beschrieben oder aufgeführt werden. 6A bis 6C zeigen ein Beispiel solcher Überprüfungen. Es wird dann festgestellt, ob ein physikalischer Konflikt zwischen den ausgewählten Anwendungsprofilen besteht (Schritt 502). Ein Beispiel eines physikalischen Konflikts wäre ein Anwendungsprofil, das ein Drucken auf eine Kartenoberfläche erfordert, was in Konflikt steht mit der Anforderung eines zweiten Anwendungsprofils, einen Magnetstreifen anzuordnen. Andere Konflikte könnten aus anderen physikalischen Anforderungen entstehen (z. B. Prägung, Graphiken, Kontakte, Drucken usw.). Wenn ein physikalischer Konflikt besteht, dann wird ein anderes Anwendungsprofil oder eine neue Version einer Anwendung ausgewählt, oder eine physikalische Anforderung kann verändert werden (Schritt 500). Es ist auch eine Option, eine Anwendung, die einen physikalischen Konflikt mit anderen Anwendungen aufweist, wegzulassen. Die Fachleute auf dem Gebiet werden erkennen, dass der Vorgang der vorliegenden Erfindung auch verwendet werden kann, um Karten mit Einfachanwendung zu erzeugen. In dem Fall, wenn Karten mit Einfachanwendung hergestellt werden, sind bestimmte Vergleichs- und Konfliktüberprüfungsschritte nicht notwendig.
  • Wenn kein physikalischer Konflikt zwischen den Anwendungen besteht (Schritt 502), dann wird festgestellt, ob ein Dateistrukturkonflikt vorhanden ist (Schritt 504). Ein Dateistrukturkonflikt könnte vorhanden sein, wenn Dateistrukturen der ausgewählten Anwendungen irgendwie inkompatibel zueinander sind. Beispiele für inkompatible Dateistrukturen umfassen zwei Dateien mit der gleichen Identifizierung oder dem gleichen Na men, eine inkompatible Dateihierarchie oder andere. Es ist auch möglich, dass ein Konflikt innerhalb der verschiedenen Anwendungsdatenelementtabellen vorhanden ist. Zum Beispiel kann ein Konflikt innerhalb der Dateistruktur vorhanden sein, dass zwei Anwendungen versuchen, das gleiche Verzeichnis oder die gleiche Datei zu nutzen. Wenn ein solcher Konflikt festgestellt wird, dann wird entweder ein neues Anwendungsprofil oder eine neue Version eines Anwendungsprofils ausgewählt (Schritt 500).
  • Wenn keine Dateistrukturkonflikte vorhanden sind (Schritt 504), kann der Vorgang dann weitergehen und feststellen, ob die Softwareversionsanforderungen zwischen den ausgewählten Anwendungen und der Karte kompatibel sind (Schritt 508). Beispiele für inkompatible Softwareanforderungen sind: Inkompatibilität zwischen Anwendungen aus verschiedenen Gründen, inkompatible Version des Betriebssystems der Karte und ein ATR-Konflikt (siehe Schritt 512).
  • Wenn die Softwareanforderungen nicht kompatibel sind (Schritt 508), dann wird ein neues Anwendungsprofil oder eine neue Version eines Anwendungsprofils ausgewählt, oder andere Veränderungen können vorgenommen werden (Schritt 500). Als Teil der Bestimmung der Kompatibilität von Softwareanforderungen kann der Vorgang feststellen, ob ein Konflikt zwischen den Anwendungen während ATR „Attention to Reset" (Schritt 512) auftritt. Ein ATR ist üblicherweise die erste Antwort einer Chipkarte, wenn sie in ein Lesegerät eingeführt wird. Wenn zwei ausgewählte Anwendungen gegensätzliche Antwortanforderungen während ATR aufweisen, dann besteht ein Konflikt. Wenn ein Konflikt während ATR auftritt (Schritt 512), dann wird ein anderes Anwendungsprofil oder eine andere Version eines Profils ausgewählt, oder die kollidierende Anwendung wird weggelassen (Schritt 500).
  • Wenn kein ATR-Konflikt auftritt (Schritt 512), dann wird eine kombinierte Dateistruktur erzeugt (Schritt 516). Die Dateistrukturen für alle Anwendungen werden kombiniert und eine einzige kombinierte Dateistruktur wird für die Chipkarte erstellt. Ein Beispiel einer kombinierten Dateistruktur hat eine Gesamtdateihierarchie beginnend mit der ISO 7816-6-Hauptdatei als Ursprung und beschreibt Hierarchien der Verzeichnisdateien und Grunddateien.
  • Die Fachleute auf dem Gebiet werden erkennen, dass der Ablauf und die Typen der hier aufgeführten Vergleiche verändert werden können, indem der Ablauf verändert wird oder durch Anpassen der Vergleiche, um Konflikte zu vermeiden. In einem besonderen Ausführungsbeispiel wird die „Konfliktbestimmungstabelle" verändert. Die hier aufgeführten Schritte sind einfach als Beispiel dargestellt und zusätzliche oder andere Vergleiche können durchgeführt werden, falls dies erforderlich ist, um Anwendungskonflikte zu vermeiden.
  • Der Vorgang fährt fort mit dem Auswählen eines Kartenprofils (Schritt 518). Wie vorher diskutiert, kann ein Kartenprofil 206 eine Identifizierungseinrichtung für das CPU-Modell, eine Identifizierungseinrichtung für den Chiffrierprozessor (falls vorhanden), verfügbares RAM und EEPROM, Identifikation von Anwendungen (falls vorhanden), die bereits geladen sind, physikalische Eigenschaften der Karte, Anwendungslebensdauerinformationen für Anwendungen, die vorab vom Kartenhersteller im ROM oder EEPROM installiert wurden, und jede andere Information, die nötig erscheint, um ein Kartenprofil zu definieren.
  • Nachdem ein Kartenprofil ausgewählt wurde (Schritt 518) und die Konfliktbestimmungstabelle gelesen wurde, wird festgestellt, ob der Speicher, der auf der zu bearbeitenden Karte verfügbar ist, für die ausgewählten Anwendungen ausreichend ist (Schritt 520). Wenn die Karte nicht genügend Speicherplatz hat, dann wird ein anderes Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 518).
  • Wenn die Chipkarte genug Speicherplatz hat (Schritt 520), dann wird festgestellt, ob die zu bearbeitende Chipkarte physikalisch kompatibel zu den ausgewählten Anwendungen ist (Schritt 522). Zum Beispiel wird festgestellt, ob die Chipkarte die physikalischen Anforderungen für die Anwendungen unterstützen kann, z. B. ob der Aufdruck auf der Chipkarte mit den Anwendungen kompatibel ist, und ob ein Magnetstreifen für die Anwendungen verfügbar ist.
  • Wenn die Chipkarte physikalisch nicht mit den Anwendungen kompatibel ist (Schritt 522), dann wird ein neues Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 518). Wenn jedoch die Karte physikalisch mit den Anwendungen kompatibel ist (Schritt 522), dann wird bestimmt, ob der Kartenprozessor mit den ausgewählten Anwendungen kompatibel ist (Schritt 524). Der zu überprüfende „Kartenprozessor" kann einen Hauptprozessor und/oder einen Koprozessor umfassen. Wenn der Kartenprozessor für die ausgewählten Anwendungen nicht geeignet ist, dann wird ein neues Kartenprofil oder eine neue Version eines Kartenprofils ausgewählt (Schritt 518). Wenn jedoch der Kartenprozessor mit den ausgewählten Anwendungen kompatibel ist (Schritt 524), dann wird festgestellt, ob der Eingabe/Ausgabe-Typ (I/O-Typ), der auf der Chipkarte verwendet wird, mit den ausgewählten Anwendungen kompatibel ist (Schritt 528). Beispiele des I/O-Typs umfassen kontaktherstellende oder kontaktfreie Karten. Wenn der I/O-Typ nicht mit den ausgewählten Anwendungen kompatibel ist (Schritt 528), dann wird ein neues Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 518). Ein Beispiel eines inkompatiblen I/O-Typs ist eine kontaktlose Anwendung, aber eine nur kontaktherstellende Karte.
  • Wenn der I/O-Typ kompatibel ist, geht der Vorgang dann weiter, um festzustellen, ob Softwareanforderungen der ausgewählten Anwendungen mit der Softwareinfrastruktur der Karte kompatibel sind (Schritt 529). Ein Beispiel für inkompatible Softwareanforderungen ist, wenn die Version des Kartenbetriebssystems eine andere als die erforderliche ist. Wiederum ist der Ablauf der Vergleiche und die Liste der zu überprüfenden Punkte nur zur Erläuterung gedacht und kann verändert werden, während die Ziele der vorliegenden Erfindung dennoch erreicht werden.
  • Als nächstes wird das Skript durch Schreiben verschiedener Abschnitte erstellt, wie nun beschrieben wird. In einem Ausführungsbeispiel werden der Ablauf und die Regeln für jeden der Skriptabschnitte von einer „Skriptsequenztabelle" verwaltet. 10 zeigt ein Ausführungsbeispiel einer einfachen Skriptsequenztabelle 220, welche die Reihenfolge aufführt, in welcher die Skriptabschnitte erscheinen sollen. Natürlich sind kompliziertere Tabellen möglich und ein Skript kann auf viele verschiedene Weisen geschrieben oder geordnet sein. Ein Ausstellerprofil 207 wird dann ausgewählt (Schritt 530). Das Ausstellerprofil umfasst Standarddaten des Ausstellers, wie spezielle Ausstellerdaten, die mit Identifikation und Sicherheit zusammenhängen. Zusätzlich können bestimmte Anwendungsstandardinformationen, wie die Währung und die Größe des Transaktionsprotokolls auf der Karte, ebenfalls im Ausstellerprofil enthalten sein. Diese Informationen und Daten können auch als „statische" Daten bezeichnet werden, und sie können entweder im Initialisierungsabschnitt 808 oder im Personalisierungsabschnitt 810 gespeichert werden, abhängig von der Art der Information und der Anwendung.
  • Das Kartenerzeugungsskript 210 wird gebildet, indem zuerst der „Identitätsabschnitt" 800 (5) des Skripts geschrieben wird (Schritt 530). Der Identitätsabschnitt 800 wird geschrieben, indem Anwendungsidentitätsinformationen aus allen ausge wählten Anwendungsprofilen und Kartenprofilen entnommen werden, und durch Kombinieren der Informationen zu einem Identitätsabschnitt des Kartenerzeugungsskriptes 210. Der dadurch entstehende Identitätsabschnitt 800 des Skripts kann den Namen, die Anwendungsidentifizierungen und die Lebensdauer jeder Anwendung auf der Chipkarte umfassen. Anwendungsidentifizierungen werden von ISO 7816-5 definiert und werden verwendet, um eine Anwendung auf einer Chipkarte als Einzige zu adressieren oder auszuwählen.
  • Die physikalischen Attribute der Chipkarte werden dann im „physikalischen" Abschnitt 802 (5) des Skripts beschrieben (Schritt 532). Beim Beschreiben der physikalischen Attribute der Chipkarte werden die erforderlichen physikalischen Attribute der verschiedenen Anwendungen und des Kartenprofils zu diesem physikalischen Abschnitt des Skripts kombiniert. Beispiele der physikalischen Attribute umfassen Lage und Inhalt der Anforderungen an Prägung, Text, Graphiken, Magnetstreifen oder Strichcode.
  • Die in Schritt 516 erzeugte kombinierte Kartendateistruktur wird dann (Schritt 534) in einem Dateistrukturabschnitt 804 (5) des Skripts beschrieben. Die Struktur wird durch Auflisten aller Dateien, der Dateihierarchie, der Dateitypen (kreisförmig, linear, mit feststehender/variabler Länge) usw. beschrieben. Obwohl in dem einen Ausführungsbeispiel Ladefunktionen nicht in den Abschnitt 806 für eine Karte mit Einfachanwendung geladen werden, wird in Erwägung gezogen, das Ladefunktionen geladen werden können, falls erforderlich.
  • Die Initialisierung der Anwendungen wird dann (Schritt 542) in einem Initialisierungsabschnitt 808 (5) des Skripts beschrieben. Die Beschreibung kann Datenelemente, alle erforderlichen Chiffrierschlüssel und andere allgemeine Kartendaten umfassen. Viele der Initialisierungsdaten können im Ausstel lerprofil enthalten sein. Die verbleibenden Initialisierungsdaten können aus den Datenelementtabellen jedes Anwendungsprofils abgeleitet werden. Ebenso können bestimmte Standarddatenwerte über eine interaktive Benutzereingabe zur Verfügung gestellt werden.
  • Die Personalisierung von Anwendungen wird auch in einem Personalisierungsabschnitt 810 (5) des Skripts beschrieben (Schritt 544). Die Personalisierungsdaten umfassen Sicherheits- und Datenelemente und andere Daten, die für eine einzelne Karte einzigartig sind. Die Datenelementtabelle für jede Anwendung umfasst Verweise (Hinweise auf eine Stelle) auf die Kartenhalterdaten für jede Anwendung. Diese Daten sind vorzugsweise in der Ausstellerpersonalisierungsdatei, einer Datenbank oder einer anderen Quelle enthalten.
  • Eine kombinierte Datenelementtabelle wird dann mit Standarddaten und Datenverweisen erstellt (Schritt 546). Die Datenelementtabelle wird dann in Abschnitt 812 des Skripts gespeichert. In diesem Schritt werden die Datenelementtabellen für alle Anwendungen kombiniert, um eine einzige Datenelementtabelle für die Karte herzustellen, welche sowohl die tatsächlichen allgemeinen Kartendaten und die Stelle der Daten für die einzigartigen Kartendaten enthält. Außerdem werden die individuellen Datenelemente der kombinierten Datenelementtabelle der kombinierten Dateistruktur zugeordnet. Falls erforderlich, können zu diesem Zeitpunkt Sicherheitsfunktionen 814 zum Skript hinzugefügt werden oder Chiffrierschlüssel, falls erwünscht.
  • 7A bis 7C zeigen ein Flussdiagramm zum Aufbau eines Kartenerzeugungsskripts für eine Open-Platform-Chipkarte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Dieser Vorgang kann auf jedem passenden Computer und in jeder passenden Computersprache integriert sein. In dem einen Ausführungs beispiel wird dieser Vorgang in der Programmiersprache C++ implementiert. Im Allgemeinen führt der Vorgang eine Abfolge von Anwendungsprofilen mit dem Kartenprofil zusammen und überprüft sie auf Kompatibilität. Zusätzlich verwendet der Vorgang die Anwendungsprofile und das Kartenprofil, um alle erforderlichen Datenelemente in einer kombinierten Datenelementtabelle zu sammeln.
  • Die Anwendungsprofile werden zu Beginn ausgewählt (Schritt 600) und dann überprüft, um ihre Kompatibilität zueinander zu verifizieren. In dem einen Ausführungsbeispiel liest der Vorgang eine „Konfliktbestimmungstabelle", welche die durchzuführenden Überprüfungen beschreibt (sowohl für die Anwendungen als auch die Karte). Natürlich können die durchzuführenden Überprüfungen auch in anderer Weise beschrieben oder aufgeführt werden. 7A bis 7C zeigen ein Beispiel solcher Überprüfungen. Es wird dann festgestellt, ob ein physikalischer Konflikt besteht (Schritt 602). Ein Beispiel für einen physikalischen Konflikt wäre ein Anwendungsprofil, das einen Aufdruck auf die Kartenoberfläche erfordert, was der Anforderung eines zweiten Anwendungsprofils, einen Magnetstreifen anzuordnen, entgegensteht. Andere Konflikte könnten aus anderen physikalischen Anforderungen entstehen (z. B. Prägung, Graphiken, Kontakte, Druck usw). Wenn ein physikalischer Konflikt besteht, dann wird ein anderes Anwendungsprofil oder eine neue Version einer Anwendung ausgewählt, oder eine physikalische Anforderung kann verändert werden (Schritt 600). Es ist auch eine Option, eine Anwendung, die einen physikalischen Konflikt mit den anderen Anwendungen aufweist, wegzulassen. In dem Fall, dass Karten mit Einfachanwendungen hergestellt werden, sind bestimmte Vergleiche und Konfliktüberprüfungen eventuell nicht erforderlich. Außerdem werden Fachleute auf dem Gebiet erkennen, dass der Ablauf der hier angeführten Vergleiche verändert werden kann, indem der Ablauf verändert wird oder durch Anpassen der Vergleiche, um Konflikte zu vermeiden. In einem Ausführungs beispiel kann die Konfliktbestimmungstabelle verändert werden. Die hier angeführten Schritte stellen nur ein Beispiel dar.
  • Wenn kein physikalischer Konflikt zwischen den Anwendungen besteht (Schritt 602), dann wird festgestellt, ob ein Dateistrukturkonflikt vorhanden ist (Schritt 604). Ein Dateistrukturkonflikt kann vorhanden sein, wenn Dateistrukturen der ausgewählten Anwendungen irgendwie nicht miteinander kompatibel sind. Potenzielle inkompatible Dateistrukturen wurden oben angegeben. Wenn ein Dateistrukturkonflikt vorhanden ist, dann kann das kollidierende Profil weggelassen werden oder ein neues Anwendungsprofil bzw. eine neue Version eines Anwendungsprofils kann ausgewählt werden (Schritt 600).
  • Wenn keine Dateistrukturkonflikte vorhanden sind (Schritt 604), kann der Vorgang dann weitergehen, um zu bestimmen, ob die Softwareanforderungen aller ausgewählten Anwendungen kompatibel sind (Schritt 606). Wenn die Softwareanforderungen nicht kompatibel sind, dann kann die kollidierende Anwendung weggelassen werden oder ein anderes Anwendungsprofil bzw. eine neue Version eines Anwendungsprofils kann ausgewählt werden (Schritt 600). Beispiele für inkompatible Softwareanforderungen umfassen: inkompatible Version der virtuellen Maschine JavaCardTM (JCVM), ATR-Konflikte usw.
  • Zum Beispiel bestimmt der Vorgang, ob ein Konflikt zwischen Anwendungen während Attention to Reset (ATR) auftritt (Schritt 612). Ein ATR ist die erste Antwort einer Chipkarte beim Einführen in ein Lesegerät. Wenn zwei ausgewählte Anwendungen entgegenstehende Antwortanforderungen während ATR aufweisen, dann besteht ein Konflikt. Wenn ein Konflikt während ATR besteht (Schritt 612), dann kann eine kollidierende Anwendung weggelassen werden oder ein anderes Anwendungsprofil oder eine andere Version eines Profils kann ausgewählt werden (Schritt 600).
  • Wenn kein ATR-Konflikt vorhanden ist (Schritt 612), dann werden die Gesamtanforderungen an das EEPROM berechnet (Schritt 614). Beim Berechnen der Gesamtanforderungen an das EEPROM werden alle Speicheranforderungen (an das EEPROM) für alle Anwendungen aufaddiert. Dann wird eine kombinierte Dateistruktur erzeugt (Schritt 616), in welcher die Dateistrukturen für alle Anwendungen kombiniert werden und eine einzelne Dateistruktur für die Chipkarte wird erstellt. Eine kombinierte Dateistruktur ist oben in Schritt 516 beschrieben.
  • Als Nächstes wird ein Kartenprofil ausgewählt (Schritt 618). Wie vorher diskutiert, kann ein Kartenprofil 206 eine Identifizierungseinrichtung für das CPU-Modell, eine Identifizierungseinrichtung für den Chiffrierprozessor (falls vorhanden), verfügbares RAM und EEPROM, Kartenorganisationsprogramm und JCVM-Versionsnummern, Sicherheitsanforderungen (Karten- und Sicherheitsdomains), Identifikation von Anwendungen (falls vorhanden), die bereits geladen sind, physikalische Eigenschaften der Karte, Anwendungslebensdauerinformationen für Anwendungen, die vorab vom Kartenhersteller im ROM oder EEPROM installiert wurden, und jede andere Information, die nötig erscheint, um ein Kartenprofil zu definieren, umfassen.
  • Nachdem ein Kartenprofil ausgewählt wurde (Schritt 618) und die Konfliktbestimmungstabelle gelesen wurde, wird festgestellt, ob der auf der zu bearbeitenden Karte verfügbare Speicherplatz für die ausgewählten Anwendungen ausreichend ist (Schritt 620). Wenn die Karte nicht genügend Speicherplatz hat (Schritt 620), dann wird ein anderes Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 618).
  • Wenn die Chipkarte genug Speicherplatz hat (Schritt 620), dann wird festgestellt, ob die Chipkarte physikalisch kompatibel zu den ausgewählten Anwendungen ist (Schritt 622). Zum Beispiel wird bestimmt, ob die Chipkarte die physikalischen Anforderungen für die Anwendungen unterstützen kann, z. B. ob ein Aufdruck auf die Chipkarte mit den Anwendungen kompatibel ist, und ob ein Magnetstreifen für die Anwendungen verfügbar ist.
  • Wenn die Chipkarte nicht mit den Anwendungen physikalisch kompatibel ist (Schritt 622), wird ein neues Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 618). Wenn jedoch die Karte physikalisch kompatibel zu den Anwendungen ist (Schritt 622), dann wird bestimmt, ob der Kartenprozessor mit den ausgewählten Anwendungen kompatibel ist (Schritt 624). Der zu überprüfende „Kartenprozessor" kann einen Hauptprozessor und/oder einen Koprozessor umfassen. Wenn der Kartenprozessor für die ausgewählten Anwendungen nicht geeignet ist, dann wird ein neues Kartenprofil oder eine neue Version eines Kartenprofils ausgewählt (Schritt 618). Wenn jedoch der Kartenprozessor mit den ausgewählten Anwendungen kompatibel ist (Schritt 624), dann wird festgestellt, ob die Softwareinfrastruktur mit den ausgewählten Anwendungen kompatibel ist (Schritt 626). Wenn die Softwareinfrastruktur der Karte nicht mit den Anwendungen kompatibel ist, dann wird ein neues Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 618). Die Feststellung, ob die Softwareinfrastruktur kompatibel ist, umfasst die Feststellung, ob die virtuelle Maschine JavaCardTM (JCVM) mit den Anwendungen kompatibel ist.
  • Wenn die Softwareinfrastruktur der Karte mit den Anwendungen kompatibel ist (Schritt 626), dann wird bestimmt, ob die Domainanforderungen kompatibel sind (Schritt 627). Die Überprüfung der Kompatibilität zwischen Domainanforderungen umfasst die Feststellung, ob eine Kartendomain und Sicherheitsdomains in der Open-Platform-Chipkarte kompatibel sind. Wenn die Domainanforderungen nicht kompatibel sind (Schritt 610), dann kann eine kollidierende Anwendung weggelassen werden oder ein anderes Anwendungsprofil oder eine neue Version eines Anwendungsprofils kann ausgewählt werden (Schritt 600). Die Feststellung, ob die Kartendomain und die Sicherheitsdomains mit einer Sicherheitsdomain kompatibel sind umfasst die Verifizierung, dass eine bestimmte Sicherheitsdomain, die von einer ausgewählten Anwendung gefordert wird, bereits auf die Karte geladen wurde oder ausgewählt wurde, um geladen zu werden.
  • Wenn Domainanforderungen kompatibel sind (Schritt 610), dann wird festgestellt, ob der Eingabe/Ausgabe-Typ (I/O-Typ), der auf der Chipkarte verwendet wird, mit den ausgewählten Anwendungen kompatibel ist (Schritt 628). Beispiele des I/O-Typs umfassen kontaktherstellende oder kontaktlose Karten. Wenn der I/O-Typ nicht kompatibel mit der ausgewählten Anwendung ist (Schritt 628), dann wird ein neues Kartenprofil oder eine neue Version des Kartenprofils ausgewählt (Schritt 618). Ein Beispiel für einen inkompatiblen I/O-Typ ist eine kontaktlose Anwendung, aber eine nur kontaktherstellende Karte.
  • Als nächstes wird das Skript durch Schreiben verschiedener Abschnitte erstellt, wie nun beschrieben wird. In einem Ausführungsbeispiel werden der Ablauf und die Regeln für jeden der Skriptabschnitte von einer „Skriptsequenztabelle" verwaltet. 10 zeigt ein Ausführungsbeispiel einer einfachen Skriptsequenztabelle 220, welche die Reihenfolge aufführt, in welcher die Skriptabschnitte erscheinen sollen. Natürlich sind kompliziertere Tabellen möglich und ein Skript kann auf viele verschiedene Weisen geschrieben oder geordnet sein. Ein Ausstellerprofil 207 wird dann ausgewählt (Schritt 640). Das Ausstellerprofil umfasst Standarddaten des Ausstellers, wie spezielle Ausstellerdaten, die mit Identifikation und Sicherheit zusammenhängen. Zusätzlich können bestimmte Anwendungsstandardinformationen, wie die Währung und die Größe des Transaktionsprotokolls auf der Karte, ebenfalls im Ausstellerprofil enthalten sein. Diese Informationen und Daten können auch als „statische" Daten bezeichnet werden, und sie können entweder im Initialisierungsabschnitt 808 oder im Personalisierungsabschnitt 810 gespeichert werden, abhängig von der Art der Information und der Anwendung.
  • Ein Kartenerzeugungsskript 210 wird gebildet, indem zuerst der „Identitätsabschnitt" 800 des Skripts geschrieben wird (Schritt 630). Der Identitätsabschnitt wird geschrieben, indem Anwendungsidentitätsinformationen aus allen ausgewählten Anwendungsprofilen und Kartenprofilen entnommen werden, und durch Kombinieren der Informationen zu einem Identitätsabschnitt des Kartenerzeugungsskriptes 210. Wie bereits erwähnt, kann der dadurch entstehende Identitätsabschnitt des Skripts den Namen, die Anwendungsidentifizierungen und die Lebensdauer aller Anwendungen auf der Chipkarte umfassen.
  • Die physikalischen Attribute der Chipkarte werden dann in einem „physikalischen" Abschnitt 802 des Skripts beschrieben (Schritt 632). Beim Beschreiben der physikalischen Attribute der Chipkarte werden die erforderlichen physikalischen Attribute der verschiedenen Anwendungen und Kartenprofile zu diesem physikalischen Abschnitt des Skripts kombiniert, welcher physikalische Attribute beschreibt. Beispiele der physikalischen Attribute umfassen Lage und Inhalt der Anforderungen an Prägung, Text, Graphiken und Magnetstreifen.
  • Die in Schritt 616 erzeugte kombinierte Kartendateistruktur wird dann (Schritt 634) in einem Dateistrukturabschnitt 804 des Skripts beschrieben. Die Struktur wird durch Auflisten aller Dateien, der Dateihierarchie, der Dateitypen (kreisförmig, linear, mit feststehender/variabler Länge) usw. beschrieben.
  • Ein Karteninitialisierungsvorgang und die Installation von Domains wird als nächstes beschrieben (Schritt 636). Für Open-Platform-Chipkarten registriert ein Vorgang die Kartendomain mit dem Kartenorganisationsprogramm und installiert alle Si cherheitsdomains und Anwendungen, die bereits auf die Karte geladen sind. Dieser Vorgang und die Informationen werden vorzugsweise im Initialisierungsabschnitt 808 gespeichert.
  • Das Laden, Installieren und Registrieren von Befehlen der bestimmten Anwendungen wird zusammen mit einer Beschreibung der Schlüssel und Sicherheitsdomains, die erforderlich sind, beschrieben (Schritt 638). Zum Beispiel müssen Open-Platform-Chipkarten-Anwendungen, die in JAVA geschrieben sind, in den Speicher geladen werden, ein Installationsvorgang muss ablaufen und mit einer Sicherheitsdomain registriert werden, damit die Anwendung in der Lage ist, zu einem späteren Zeitpunkt ihre Anwendungsschlüssel zu laden (Schritt 642). Vorzugsweise werden diese Befehle im Ladeabschnitt 806 gespeichert.
  • Die Initialisierung der Anwendungen wird dann in einem Initialisierungsabschnitt 808 des Skripts beschrieben (Schritt 642). Die Beschreibung kann Datenelemente, alle erforderlichen Chiffrierschlüssel und andere allgemeine Kartendaten umfassen. Viele der Initialisierungsdaten können im Ausstellerprofil enthalten sein. Die verbleibenden Initialisierungsdaten können aus den Datenelementtabellen für jedes Anwendungsprofil abgeleitet werden. Ebenso können bestimmte Standarddatenwerte über eine interaktive Benutzereingabe zur Verfügung gestellt werden.
  • Die Personalisierung von Anwendungen wird dann in einem Personalisierungsabschnitt 810 des Skripts beschrieben (Schritt 644). Die Personalisierungsdaten umfassen Sicherheits- und Datenelemente und andere Daten, die für eine einzelne Karte einzigartig sind. Die Datenelementtabelle für jede Anwendung umfasst Verweise (Hinweise auf eine Stelle) auf die Kartenhalterdaten für jede Anwendung. Diese Daten sind in der Ausstellerpersonalisierungsdatei, einer Datenbank oder einer anderen Quelle enthalten.
  • Eine kombinierte Datenelementtabelle wird mit Standarddaten und Datenverweisen erstellt (Schritt 646). In diesem Schritt werden alle Datenelementtabellen für alle Anwendungen kombiniert, um eine einzige Datenelementtabelle für die Karte herzustellen, welche sowohl die tatsächlichen allgemeinen Kartendaten und die Stelle der Daten für die einzigartigen Kartendaten enthält. Außerdem werden die individuellen Datenelemente der kombinierten Datenelementtabelle der kombinierten Dateistruktur zugeordnet. Zu diesem Zeitpunkt können erforderliche Sicherheitsfunktionen 814 zum Skript hinzugefügt werden oder Chiffrierschlüssel, falls erwünscht.
  • 8 ist ein Flussdiagramm zum Herstellen einer herkömmlichen Chipkarte gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Ein Aussteller sendet zuerst Spezifikationen an einen Kartenhersteller (Schritt 900). Als Nächstes schreibt der Kartenhersteller den Anwendungscode in einer Computersprache, wie z. B. Assembler (Schritt 902). Ein Chiphersteller brennt den Code dann in einen Chip (Schritt 904). Der Kartenhersteller empfängt den Chip mit der Anwendung darauf (Schritt 906) und integriert den Chip auf der Karte, wodurch eine nicht-personalisierte Karte, die bearbeitet werden soll, bereitgestellt wird (Schritt 908).
  • Zu irgendeinem Zeitpunkt liefert der Aussteller eine Personalisierungsdatei mit Kartenhalterdaten an den Kartenhersteller. Die Kartenhalterdaten umfassen eine Anwendungsabfolge-Identifizierungseinrichtung, welche die Anwendungen, die personalisiert werden sollen, identifiziert (d. h. welches Kartenprodukt hergestellt werden soll). Diese Anwendungsabfolge-Identifizierungseinrichtung wird verwendet, um das passende Kartenerzeugungsskript aus vielen auszuwählen. Das Kartenerzeugungsskript wird dann auf die nicht-personalisierte Karte angewandt (Schritt 910). In einem Ausführungsbeispiel empfängt das Personalisierungs-Gerät (Kartenherstellungs-Hardware und – Software) das Kartenerzeugungsskript, die Anwendungsquelldateien, Kartenhalterdaten und Chiffrierschlüssel (von jedem passenden Hardware-Sicherheitsmodul). Das Personalisierungs-Gerät verwendet das Skript, um eine Chipkarte, die bereit ist, um auf einen Kartenhalter ausgestellt zu werden, zu personalisieren. Ein Fachmann auf dem Gebiet kann einfach ein Parserprogramm schreiben, um ein Skript zu verarbeiten und das Personalisierungs-Gerät zu steuern.
  • Insbesondere befiehlt das Skript dem Personalisierungs-Gerät, die Dateistruktur auf der Karte zu erzeugen (Schritt 911), die Initialisierungsdaten auf die Karte zu schreiben (Schritt 912), und die Personalisierungsdaten auf die Karte zu schreiben (Schritt 914). Personalisierungsdaten umfassen Kartenhalterdaten 214, die für den Kartenhalter speziell sind, wie den Namen des Kartenhalters, die Kreditlinie, bevorzugter Sitz im Flugzeug usw. Chiffrierschlüssel können ebenfalls während der Initialisierungs- und Personalisierungsschritte auf die Karte geladen werden. Danach kann die Chipkarte an einen Kunden ausgestellt werden (Schritt 918).
  • 9 ist ein Flussdiagramm zur Herstellung einer Open-Platform-Chipkarte (einer Karte mit Mehrfachanwendungen) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Ein Aussteller sendet eine Open-Platform-Kartenspezifikation an einen Kartenhersteller (Schritt 1000). Der Kartenhersteller schreibt dann die Karteninfrastruktur für die Open-Platform-Karte (Schritt 1002). Ein Chiphersteller brennt dann die Infrastruktur auf den Chip (Schritt 1004). Der Kartenhersteller integriert dann den Chip auf der Karte, wodurch eine Open-Platform-Karte mit Infrastruktur erzeugt wird (Schritt 1006).
  • Zu irgendeinem Zeitpunkt liefert der Aussteller eine Personalisierungsdatei mit Kartenhalterdaten an den Kartenhersteller.
  • Die Kartenhalterdaten umfassen eine Anwendungsabfolge-Identifizierungseinrichtung, welche die Anwendungen, die auf die Karte gebracht werden sollen, identifiziert (d. h. welches Kartenprodukt hergestellt werden soll). Diese Anwendungsabfolge-Identifizierungseinrichtung wird verwendet, um das passende Kartenerzeugungsskript aus vielen auszuwählen. Das Kartenerzeugungsskript wird dann auf die Open-Platform-Karte angewandt (Schritt 1007). In einem Ausführungsbeispiel empfängt das Personalisierungs-Gerät (Kartenherstellungs-Hardware und – Software) das Kartenerzeugungsskript, die Anwendungsquelldateien, Kartenhalterdaten und Chiffrierschlüssel (von jedem passenden Hardware-Sicherheitsmodul). Das Personalisierungs-Gerät verwendet das Skript, um eine Chipkarte, die bereit ist, um auf einen Kartenhalter ausgestellt zu werden, zu personalisieren. Ein Fachmann auf dem Gebiet kann einfach ein Parserprogramm schreiben, um ein Skript zu verarbeiten und das Personalisierungs-Gerät zu steuern.
  • Wenn das Skript angewendet wird, wird der Anwendungscode auf die Karte geladen (Schritt 1008), die Dateistruktur wird auf der Karte erzeugt (Schritt 1009), die Initialisierungsdaten werden auf die Karte geschrieben (Schritt 1010), und ebenfalls die Personalisierungsdaten (Schritt 1012). Personalisierungsdaten umfassen Kartenhalterdaten 214, die für den Kartenhalter speziell sind, wie den Namen des Kartenhalters, die Kreditlinie, bevorzugter Sitz im Flugzeug usw. Chiffrierschlüssel können ebenfalls während der Initialisierungs- und Personalisierungsschritte auf die Karte geladen werden. Die Open-Platform-Karte kann dann ausgestellt werden (Schritt 1018).
  • Laden einer Anwendung nach der Ausstellung
  • Bei einem weiteren Ausführungsbeispiel der Erfindung ist das aktualisierte Kartenprofil 230 der 3 nützlich, um Anwendungen auf eine Chipkarte nach der Ausstellung zu laden. Das aktualisierte Kartenprofil 230 ist ein „Schnappschuss" eines Stapels von Karten, wie ausgestellt; es ist ein Profil eines bestimmten Kartenprodukts, wie eine ATM-Karte, eine Geldautomatenkarte, eine Karte mit gespeichertem Geldwert, eine Kundenkarte usw. Das aktualisierte Kartenprofil 230 reflektiert die Anwendungen, die auf einer Karte geladen sind und die Ressourcen, die auf dieser Karte übrig sind. Wenn neue Anwendungen nach der Ausstellung geladen werden sollen, kann das aktualisierte Kartenprofil 230 verwendet werden, um Konflikte zwischen der existierenden ausgestellten Karte und diesen neuen Anwendungen zu überprüfen. In einem Ausführungsbeispiel kann das aktualisierte Kartenprofil zurück in das System 200 der 3 geliefert werden, zusammen mit Profilen der neuen Anwendungen, die nach der Ausstellung geladen werden sollen. Das System erzeugt dann ein weiteres Kartenerzeugungsskript, das zum Laden der neuen Anwendungen auf die existierenden Karten geeignet ist. Da das aktualisierte Kartenprofil mit den neuen, zu ladenden Anwendungen verglichen werden kann, erhält der Anwender die Sicherheit, dass das neu erzeugte Skript Anwendungen laden wird, die problemlos auf der Karte funktionieren werden.
  • 12 ist ein Flussdiagramm, das ein Verfahren zur Herstellung eines aktualisierten Kartenprofils gemäß einem Ausführungsbeispiel beschreibt. Wie in 3 gezeigt, ist das aktualisierte Kartenprofil 230 eine optionale Ausgabe des Skriptgerüsts 208. Der Anwender des Systems 200 kann wählen, ein Profil 230 zu erzeugen, wenn ein aktualisiertes Profil in der Zukunft nützlich wäre, z. B. wenn Anwendungen auf Karten nach der Ausstellung geladen werden sollen.
  • Das Kartenprofil 206 wird in das System 200 eingegeben (Schritt 1202) und stellt Ressourcen einer leeren Karte, wie bereits beschrieben wurde, dar. Ein Skript 210 wird dann für ein bestimmtes Kartenprodukt erzeugt (Schritt 1204), wie im Detail in irgendeinem der Ausführungsbeispiele der 3 bis 11 beschrieben wurde. Ein Kartenprodukt kann jede passende Karte sein, die fertig ist, um an einen Kunden oder eine andere Rechtspersönlichkeit ausgestellt zu werden. Als Beispiel kann ein Kartenprodukt jede passende Karte sein mit einer bestimmten Anwendung oder einem Satz von Anwendungen, wie eine ATM-Karte, eine Karte mit gespeichertem Geldwert, eine Kundenkarte usw. Als Nächstes werden in Schritt 1206–1212 die Informationen identifiziert, die beim Aufbau des aktualisierten Kartenprofils 230 verwendet werden. Fachleute auf dem Gebiet werden verstehen, dass die Schritte 1206–1212 vor Schritt 1204, in Verbindung mit diesem oder danach auftreten können.
  • Die Anwendungen, die unter Verwendung des erzeugten Skripts 210 auf die Karte geladen werden sollen, werden identifiziert (Schritt 1206), einschließlich Anwendungsname, Versionsnummer und andere identifizierende Eigenschaften jeder Anwendung. Die für den Aufbau des Skripts 210 verwendeten Anwendungsprofile können verwendet werden, um diese identifizierenden Informationen abzurufen. Der Lebensdauerzustand jeder Anwendung (Schritt 1208) wird dann identifiziert. Vorzugsweise ist der Zustand jeder Anwendung der Zustand, in welchem sie auf der Karte existieren wird, wenn diese ausgestellt wird. Der auf der Karte verfügbare Speicher, nachdem die Anwendungen geladen wurden, wird dann bestimmt (Schritt 1210). Der verfügbare Speicher kann sich auf jede Art von Speicher auf der Karte beziehen, der übrig bleibt, nachdem ein bestimmter Satz von Anwendungen geladen wurde. In einem Ausführungsbeispiel wird der EEPROM-Speicher, der auf der Karte verfügbar ist, nachdem eine Anzahl von Anwendungen geladen wurde, berechnet. Das Kartenprofil 206 und die Anwendungsprofile, die zum Aufbau des Skripts 210 verwendet werden, können verwendet werden, um den verfügbaren Speicher zu berechnen.
  • Schließlich werden die in Schritt 1206–1210 abgerufenen Informationen verwendet, um ein aktualisiertes Kartenprofil 230 zu erzeugen (Schritt 1212). Das aktualisierte Kartenprofil 230 hat vorzugsweise das gleiche Format wie das ursprüngliche Kartenprofil 206, auch wenn es nun mit den Informationen aus den Schritten 1206–1210 aktualisiert wurde. Jede andere Information auf dem aktualisierten Kartenprofil 230 kann ebenfalls aktualisiert werden, wenn dies sinnvoll erscheint. Wenn z. B. die Ausstellungsprozedur zu einer Veränderung der physikalischen Eigenschaften einer Karte führt, kann das aktualisierte Kartenprofil diese Änderung auch widerspiegeln, wodurch angezeigt wird, dass ein bestimmter Stapel von Karten nun eine andere physikalische Eigenschaft aufweist. Das aktualisierte Kartenprofil 230 wird dann für eine künftige Verwendung gespeichert.
  • Bei einem alternativen Ausführungsbeispiel wird ein aktualisiertes Kartenprofil nicht vom Skriptgerüst 208 des Systems 200 erzeugt, sondern kann manuell erstellt werden. In dieser Situation kann ein Anwender eine Datei für das aktualisierte Kartenprofil manuell erzeugen, das alle Profilinformationen für ein existierendes Kartenprodukt enthält. Solch ein alternatives Ausführungsbeispiel kann sinnvoll sein in einer Situation, wenn ein Kartenprodukt bereits existiert, aber noch nicht unter Verwendung eines Kartenerzeugungsskripts hergestellt wurde.
  • Sobald ein Stapel Karten ausgestellt wurde, kann eine Entscheidung getroffen werden, eine neue Anwendung (oder Anwendungen) zu den Karten hinzuzufügen. In dieser Situation kann ein Ausführungsbeispiel der vorliegenden Erfindung verwendet werden für den Aufbau eines neuen Kartenerzeugungsskripts unter Verwendung des aktualisierten Kartenprofils 230. Abhängig von der Art der Karte kann irgend eines der Ausführungsbeispiele der 6A bis 6C oder 7A bis 7C verwendet werden, um ein neues Skript zu erstellen. Vorzugsweise werden die Flussdiagramme leicht abgeändert, um für den Aufbau eines neuen Skripts für eine bereits ausgestellte Karte zu passen (statt für eine noch auszustellende Karte). Das Folgende stellt ein Beispiel dar, wie das Flussdiagramm der 6A bis 6C abgeändert werden kann, um ein Skript 210' für das Laden einer Chipkarte nach ihrer Ausstellung zu erstellen.
  • Zuerst wird ein existierendes Kartenprodukt als das Objekt eines Ladens nach der Ausstellung ausgewählt. Schritt 518 (Kartenprofil auswählen) wird vorzugsweise zu Beginn des Vorgangs durchgeführt und wird verwendet, um das aktualisierte Kartenprofil 230, das mit dem existierenden Kartenprodukt übereinstimmt, auszuwählen. In Schritt 500 werden die Profile für die vorher geladenen Anwendungen ausgewählt, sowie die Profile für alle neuen Anwendungen, die auf die Karte geladen werden sollen. Auf diese Weise können die neuen Anwendungen mit den ursprünglichen Anwendungen, die bereits auf der Karte existieren, verglichen werden.
  • Im Hinblick auf Schritt 516 ist es eventuell nicht nötig, eine neue Dateistruktur für die Karte zu erzeugen. Vorzugsweise wird die existierende Dateistruktur erweitert, um alle neuen Anwendungen aufzunehmen, z. B. können neue Dateien hinzugefügt werden, um die neuen Anwendungen zu unterstützen.
  • Schritt 532 kann leer sein, da es eventuell nicht möglich ist, die physikalischen Attribute einer Karte zu verändern, nachdem sie ausgestellt wurde. Wenn eine Karte ausgestellt wurde, hat sie bereits eine Prägung erhalten, Graphiken wurden darauf gedruckt und Informationen wurden auf den Magnetstreifen gespeichert. Es wird jedoch in Erwägung gezogen, dass bestimmte physikalische Attribute nach der Ausstellung verändert werden können. Zum Beispiel können die Daten auf dem Magnetstreifen verändert werden.
  • Im Hinblick auf Schritt 534 muss die Dateistruktur nicht neu beschrieben werden, aber jede Erweiterung der Dateistruktur, um neue Anwendungen aufzunehmen, wird in dem Skript notiert. Schritte 542–546 werden abgeändert, damit sie sich auf die neuen Anwendungen beziehen, die auf die Chipkarte geladen werden sollen, anstelle der Anwendungen, die früher geladen wurden. Zum Beispiel wird die Initialisierung für die neuen Anwendungen beschrieben, zusammen mit allen erforderlichen Personalisierungsinformationen. Schließlich wird eine neue kombinierte Datenelementtabelle erzeugt, welche die Informationen, die für jede neue Anwendung relevant sind, enthält. Das neu erstellte Skript 210' kann nun verwendet werden, um ein Laden einer Chipkarte nach der Ausstellung durchzuführen.
  • 13 ist ein Blockdiagramm eines Systems 1300 zum Installieren einer Anwendung nach der Ausstellung. Ein neu erstelltes Kartenerzeugungsskript (CCS) 210' ist gezeigt, das verwendet wird, um neue Anwendungen auf ein existierendes Kartenprodukt zu laden. Ein Server 1310 hat ein verbundenes Hardware-Sicherheitsmodul (HSM) 1312, akzeptiert den neuen Anwendungscode 1314 und kommuniziert über das Internet 1320 (oder ein anderes Netzwerk) mit einer Chipkarte 212'. Der Server 1310 steht auch in Verbindung mit einer Kartenhalter-Datenbank 1316, welche die Personalisierungsdaten über jeden Kartenhalter, die für bestimmte Anwendungen relevant sind, enthält. Zum Beispiel kann die Datenbank 1316 Vielfliegerzahlen für eine Rabattanwendung, die auf die Karten geladen werden soll, enthalten.
  • Der Server 1310 ist jedes passende Computersystem zum Lesen des Skripts 210' und zum Übertragen der Anweisungen und des Codes 1314 über ein Netzwerk an eine Chipkarte. Vorzugsweise steuert der Server 1310 die Interaktion mit der entfernten Chipkarte 212' und das Terminal am anderen Ende muss kein intelligentes Terminal sein.
  • Das Hardware-Sicherheitsmodul (HSM) 1312 wird verwendet, um die Chiffrierverarbeitung zu erleichtern. Das HSM 1312 speichert üblicherweise geheime Schlüssel und Chiffrieralgorithmen, führt Chiffrierfunktionen an geheimen Daten durch und erzeugt Verbindungsschlüssel und Signaturen. Wie im Stand der Technik bekannt, ist das HSM 1312 im Allgemeinen eine Vorrichtung, die gegen unberechtigten Zugriff geschützt ist, welche ein bestimmtes Niveau von physikalischen Sicherheitsmaßnahmen nutzt, um empfindliche Informationen im Inneren zu schützen. Das HSM 1312 kann jedes in der Industrie verwendete Sicherheitsmodul sein, wie ein RACAL HSM Modell RG7000, oder die Sicherheitsbox, die an automatischen Geldausgabegeräten befestigt ist. In alternativen Ausführungsbeispielen kann das HSM 1312 auf einer Chipkarte innerhalb eines Kartenlesegeräts integriert sein, auf eine Reihe von Chipkarten, kann auf jedem passenden sicheren Computer implementiert sein, oder kann in der Software enthalten sein.
  • Der Anwendungscode 1314 ist jeder beliebige passende Code zum Laden auf eine Chipkarte und kann eine Anwendung oder mehrere darstellen. In einem Ausführungsbeispiel werden die Anwendungen in der Programmiersprache JAVA geschrieben, obwohl Assembler, Visual Basic, C oder andere Sprachen ebenfalls verwendet werden können, um Anwendungen zu schreiben.
  • Das Internet 1320 ist jedes passende Netzwerk, über welches eine Kommunikation zwischen dem Server 1310 und einem Fernterminal mit einer Chipkarte stattfindet. Obwohl in einem Ausführungsbeispiel das Internet verwendet wird, kann das Netzwerk auch ein Telefonnetz, ein GSM-Netz oder andere sein.
  • Wie in 13 gezeigt, kann das Laden nach der Ausstellung zu Hause über einen Computer 1330 geschehen, an einem Verkaufsstand 1332 oder in einer Bankfiliale über ein Terminal 1334. Zu Hause wird ein Kartenlesegerät am Computer 1330 befestigt und die Chipkarte 212' wird in das Lesegerät eingeführt. Der Verkaufsstand 1332 kann in einem Laden oder an einem anderen Ort vorhanden sein, oder kann die Form eines ATM aufweisen. Ein im Verkaufsstand 1332 eingebautes Kartenlesegerät akzeptiert die Chipkarte 212' für ein Laden nach der Ausstellung. Ein Terminal 1334 in einer Bankfiliale kann ebenfalls verwendet werden, um eine Chipkarte 212' für ein Laden nach der Ausstellung zu akzeptieren. Ein tragbares Terminal kann ebenfalls verwendet werden, um eine Chipkarte für ein Laden nach der Ausstellung zu akzeptieren.
  • Das genannte Kartenlesegerät kann jedes passende Terminal sein, wie es im Stand der Technik bekannt ist, um von einer Chipkarte zu lesen oder auf diese zu schreiben, oder dergleichen. Als Beispiel können Terminals hergestellt von Verifone, Hypercom, NCR oder anderen verwendet werden. Ein Terminal, auch bezeichnet als Schnittstellengerät (IFD), Chip akzeptierendes Gerät (CAD), Chipkartenleser (CCR), Chipkartenadapter und Kartenlesegerät, kann jede beliebige passende Schnittstelle sein, die funktioniert, um Informationen und Befehle zwischen einer Chipkarte und einem Nutzer und/oder einem Computer zu übertragen. Ein Terminal kann ein nicht-intelligentes Gerät sein, das einfach nur Strom an eine Karte liefert und die Übertragung der Informationen erleichtert, oder es kann so kompliziert wie ein Verkaufsterminal sein, das einen Prozessor, Anwendungssoftware und die Fähigkeit zur Kommunikation über ein Netzwerk umfasst.
  • Ein Terminal kann jede beliebige physische Form annehmen und kann eine unabhängige einzelne Einheit, in einen Computer integriert, an der Tastatur eines Computers angebracht, eine PCMCIA-Karte sein oder kann sogar in eine Einheit von der Größe einer Diskette eingebaut sein, welche von einem Plattenlaufwerk eines Computers gelesen werden kann, usw. Außerdem kann ein Terminal auch in einer tragbaren Vorrichtung, wie einem Laptop-Computer, einem Mobiltelefon oder irgendeiner Art von Taschencomputer (PDA) integriert sein.
  • 14 ist ein Flussdiagramm, welches ein Verfahren zum Laden einer Anwendung nach der Ausstellung beschreibt. Zuerst (Schritt 1402) wird eine Verbindung zwischen dem Server 1310 und einer Chipkarte 212' eingerichtet, welche in ein Lesegerät eingeführt wurde, das z. B. mit dem Computer 1330, dem Verkaufsstand 1332, dem Terminal 1334 oder jedem anderen passenden Terminal verbunden ist. Techniken zur Kommunikation über ein Netzwerk mit einer Chipkarte sind im Stand der Technik bekannt. Als nächstes wird das Skript 210' in den Server 1310 eingegeben (Schritt 1404). Der Status der Karte wird überprüft (Schritt 1406), um festzustellen, ob der Zustand der Karte derjenige ist, den das Skript erwartet. Die Lebensdauer der Karte kann überprüft werden, zusammen mit einer Identifikation der auf der Karte vorhandenen Anwendungen und des Lebensdauerstatus jeder Anwendung. Das Skript kann erwarten, dass sich die Karte in einem bestimmten Zustand befindet, bevor das Laden nach der Ausstellung vorgenommen werden kann. Wenn der Status nicht so wie erwartet ist, endet der Vorgang.
  • Wenn jedoch der Status in Ordnung ist, dann wird das Skript 210' unter der Steuerung des Servers 1310 über das Netzwerk 1320 auf der Karte 212' angewandt (Schritt 1408). In diesem Ausführungsbeispiel empfängt der Server 1310 das Skript 210', die Anwendungs-Quelldateien 1314, die Kartenhalterdaten von der Datenbank 1316 und Chiffrierschlüssel vom HSM 1312. Der Server verwendet das Skript, um Anwendungen auf die Chipkarte zu laden. Ein Fachmann auf dem Gebiet kann einfach ein Parser- Programm schreiben, um ein Skript abzuarbeiten und den Server zu steuern.
  • Wenn das Skript 210' angewandt wurde, wird der Anwendungscode 1314 auf die Karte 212' geladen (Schritt 1410) und die Dateistruktur auf der Karte wird auf der Karte erweitert (Schritt 1412), um neue Anwendungen aufzunehmen. Außerdem werden alle Anwendungsinitialisierungsdaten (Schritt 1414) sowie alle Personanlisierungsdaten (Schritt 1416), die von einer bestimmten Anwendung benötigt werden, auf die Karte geschrieben. Personalisierungsdaten können Daten von der Datenbank 1316 umfassen, die speziell für den Kartenhalter und für eine bestimmte Anwendung nützlich sind, wie z. B. die Identifizierungsnummer des Kartenhalters, die Kreditlinie, bevorzugter Sitzplatz im Flugzeug usw. Chiffrierschlüssel können ebenfalls während der Initialisierungs- und Personalisierungsschritte auf die Karte geladen werden. Die Karte 212' ist dann fertig, um an den Kunden ausgegeben zu werden, wobei neue Anwendungen geladen wurden und einsatzfähig sind.
  • In einem weiteren Ausführungsbeispiel der Erfindung wird ein Personalisierungsvorgang mit mehreren Schritten verwendet. In diesem Szenario kann ein erster Aussteller ein Kartenerzeugungsskript erstellen, welches verwendet wird, um einen Stapel von Karten für einen bestimmten Zweck zu initialisieren und zu personalisieren. Als Teil dieses Vorgangs erstellt der erste Aussteller ein aktualisiertes Kartenprofil, das zu diesen Karten gehört. Der Stapel von Karten wird dann an einen zweiten Aussteller geliefert, der die Karten weiter personalisieren möchte (und/oder weitere Anwendungen hinzufügen möchte). Der zweite Aussteller verwendet das aktualisierte Kartenprofil (welches den aktuellen Status und die aktuellen Ressourcen des Stapels von Karten kennzeichnet), das er vom ersten Aussteller erhalten hat, um ein zweites Skript zu erzeugen, das die Karte weiter personalisieren wird oder weitere Anwendungen hinzufü gen wird. Dieses Ausführungsbeispiel ist nützlich, wenn die Aussteller die Arbeit aufteilen möchten, wenn die Aussteller weit voneinander entfernt sind, wenn bestimmte Personalisierungsdaten und/oder Anwendungen nur dem zweiten Aussteller zugänglich sind, oder wenn der zweite Aussteller Daten oder Schlüssel hat, die gegenüber dem ersten Aussteller geheim gehalten werden sollen.
  • Ausführungsbeispiel des Computersystems
  • 15 und 16 zeigen ein Computersystem 1500, das geeignet ist, die Ausführungsbeispiele der vorliegenden Erfindung zu implementieren. 15 zeigt eine mögliche physische Form des Computersystems. Natürlich kann das Computersystem viele physische Formen aufweisen, von einem integrierten Schaltkreis, einer Leiterplatte und einem kleinen Handgerät bis hin zu einem riesigen Supercomputer. Das Computersystem 1500 umfasst einen Monitor 1502, eine Anzeige 1504, ein Gehäuse 1506, ein Plattenlaufwerk 1508, eine Tastatur 1510 und eine Maus 1512. Die Platte 1514 ist ein computer-lesbares Medium, das verwendet wird, um Daten vom und zum Computersystem 1500 zu übertragen.
  • 16 ist ein Beispiel eines Blockdiagramms für das Computersystem 1500. Eine große Vielzahl von Untersystemen ist mit dem Systembus 1520 verbunden. Ein Prozessor bzw. Prozessoren 1522 (auch als zentrale Recheneinheiten oder CPU bezeichnet) sind mit Speichervorrichtungen, einschließlich des Speichers 1524, verbunden. Der Speicher 1524 umfasst einen Direktzugriffsspeicher (RAM) und einen Nurlesespeicher (ROM). Wie im Stand der Technik gut bekannt ist, dient das ROM zum Übertragen von Daten und Anweisungen in einer Richtung an die CPU und das RAM wird üblicherweise verwendet, um Daten und Anweisungen in zwei Richtungen zu übertragen. Beide dieser Arten von Speichern können jedes passende computer-lesbare Medium, wie vor her beschrieben, umfassen. Eine Festplatte 1626 ist ebenfalls in beiden Richtungen mit der CPU 1522 verbunden; sie bietet zusätzliche Datenspeicherplatzkapazität und kann ebenfalls jedes oben beschriebene computer-lesbare Medium umfassen. Die Festplatte 1526 kann verwendet werden, um Programme, Daten und dergleichen zu speichern und ist typischerweise ein Nebenspeichermedium, das langsamer als der Hauptspeicher ist. Es ist klar, dass die Informationen auf der Festplatte 1526 in geeigneten Fällen in üblicher Weise als virtueller Speicher im Speicher 1524 integriert sein kann. Die auswechselbare Platte 1514 kann jede Form eines oben beschriebenen computer-lesbaren Mediums annehmen.
  • Die CPU 1522 ist auch mit einer Vielzahl von Eingabe-/Ausgabegeräten verbunden, wie der Anzeige 1504, der Tastatur 1510, der Maus 1512 und Lautsprechern 1530. Im Allgemeinen kann ein Eingabe-/Ausgabegerät ein beliebiges der folgenden sein: Videoanzeigen, Rollkugeln, Mäuse, Tastaturen, Mikrophone, Touch-Screen-Anzeigen, Wandler-Kartenlesegeräte, Magnetband- oder Papierbandlesegeräte, Zeichentabletts, Lichtstifte, Stimmen- oder Handschrifterkennungsgeräte, biometrische Lesegeräte oder andere Computer. Die CPU 1522 kann optional mit einem weiteren Computer oder einem Telekommunikationsnetzwerk, das eine Netzwerkschnittstelle 1540 verwendet, verbunden sein. Bei einer solchen Netzwerkschnittstelle wird in Erwägung gezogen, dass die CPU Informationen vom Netzwerk empfangen könnte oder Informationen an das Netzwerk ausgeben könnte, im Laufe der Durchführung der oben beschriebenen Verfahrensschritte. Weiterhin können die Ausführungsbeispiele der Verfahren der vorliegenden Erfindung nur auf der CPU 1522 ausgeführt werden oder über ein Netzwerk, wie das Internet, in Verbindung mit einer Fern-CPU, welche einen Bereich der Verarbeitung übernimmt.
  • Zusätzlich betreffen Ausführungsbeispiele der vorliegenden Erfindung Computerspeicherprodukte mit einem computer-lesbaren Medium, die einen Computercode beinhalten, um verschiedene computereigene Operationen durchzuführen. Die Medien und der Computercode können speziell für die Zwecke der vorliegenden Erfindung konstruiert und aufgebaut sein, oder sie können von der Art sein, wie sie für Fachleute im Bereich der Computersoftware gut bekannt und verfügbar sind. Beispiele für computerlesbare Medien umfassen (sind aber nicht beschränkt darauf): magnetische Medien wie Festplatten, Disketten und Magnetbänder; optische Medien wie CD-ROMs und holographische Geräte; magneto-optische Medien wie optische Disketten; und Hardwaregeräte, die speziell dazu ausgelegt sind, Programmcodes zu speichern und auszuführen, wie anwendungsspezifische Schaltkreise (ASIC), programmierbare Logikeinrichtungen (PLD) und ROM- und RAM-Vorrichtungen. Beispiele des Computercodes umfassen Maschinencodes, wie die von einem Compiler erzeugten Codes, und Dateien mit einem Code mit höherem Niveau, die von einem Computer mit Hilfe eines Interpreters ausgeführt werden.
  • Obwohl die vorstehende Erfindung ziemlich genau zum Zwecke der Klarheit und Verständlichkeit beschrieben wurde, ist es offensichtlich, dass bestimmte Änderungen und Modifikationen innerhalb des Umfangs der beigefügten Ansprüche durchgeführt werden können. Zum Beispiel ist die Erfindung auf eine große Vielfalt von herkömmlichen Chipkarten, Chipkarten mit Mehrfachanwendungen und Chipkarten ähnlich den Open-Platform-Chipkarten anwendbar. Das Skriptgerüst kann eine Vielzahl von Informationen zusätzlich zu den Anwendungsprofilen, Karten- und Ausstellerprofilen und der Benutzereingabe nutzen. Das Skript kann viele Formate aufweisen und unter Verwendung unterschiedlicher Sprachen geschrieben werden. Ebenso können eine Anzahl von Personalisierungsgeräten oder anderer Kartenherstellungshardware verwendet werden, um das Skript zu interpretieren und eine Chipkarte aufzubauen. Zusätzlich ist es möglich, zuerst ein Kartenprofil auszuwählen (das ursprüngliche oder das aktualisierte) und dann die Anwendungen auszuwählen, die mit diesem Kartenprofil kompatibel sind, anstatt zuerst die Anwendungen auszuwählen und dann ein Kartenprofil zu finden, das dazu passt. Deshalb sollten die beschriebenen Ausführungsbeispiele als erläuternd und nicht als einschränkend betrachtet werden, und die Erfindung sollte nicht durch die hier dargelegten Einzelheiten begrenzt sein, sondern durch die nachfolgenden Ansprüche und den vollen Umfang ihrer Äquivalente definiert sein.
  • ANHANG
    Figure 00610001
  • Figure 00620001
  • Figure 00630001
  • Figure 00640001

Claims (28)

  1. Verfahren zum Aufbau eines Chipkarten-Skript (210) zur Verwendung beim Herstellen einer Chipkarte, wobei das Verfahren umfasst: Empfangen von Anwendungsprofildaten (201, 202, 203), die typisch für zumindest eine Softwareanwendung, die für die Chipkarte vorgesehen ist, sind, wobei die Anwendungsprofildaten die Anforderungen der zumindest einen Softwareanwendung beschreiben; Empfangen eines Kartenprofils (206), welches die Ressourcen der Chipkarte beschreibt; und Schreiben des Chipkarten-Skripts (210), wobei das Verfahren dadurch gekennzeichnet ist, dass das Chipkarten-Skript unter Verwendung der Anwendungsprofildaten und des Kartenprofils geschrieben wird.
  2. Verfahren nach Anspruch 1, ferner umfassend: Empfangen von Ausstellerdaten (207), gemeinsam für eine Vielzahl von Chipkarten, wobei der Schritt des Schreibens des Skripts auch die Ausstellerdaten verwendet.
  3. Verfahren nach Anspruch 1 oder 2, ferner umfassend: Empfangen von Verweisen auf Kartenhalterdaten (214), wobei der Schritt des Schreibens des Skripts auch die Verweise auf die Kartenhalterdaten verwendet, wobei im Gebrauch das Skript angepasst ist, um die Chipkarte zu personalisieren.
  4. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend: Vergleichen des Kartenprofils (206) mit den Anwendungsprofildaten (201, 202, 203); Bestimmen, ob die vom Kartenprofil dargestellte Chipkarte die Softwareanwendung unterstützen kann (Schritt 306); und wenn bestimmt wird, dass die Chipkarte die Softwareanwendung nicht unterstützen kann, Auswählen eines anderen Kartenprofils, das die Ressourcen einer anderen Chipkarte beschreibt.
  5. Verfahren zum Aufbau eines Chipkarten-Skripts nach Ansprüchen 1 bis 4, wobei der Schritt des Schreibens des Skripts ein Schreiben eines physikalischen Abschnitts (802) der Chipkarte einschließlich physikalischer Attribute der Chipkarte umfasst.
  6. Verfahren zum Aufbau eines Chipkarten-Skripts nach einem der vorhergehenden Ansprüche, wobei der Schritt des Schreibens des Skriptes ein Schreiben eines Initialisierungsabschnitts (808) des Chipkarten-Skripts einschließlich Daten, die zu einer Vielzahl von Chipkarten gehören, umfasst.
  7. Verfahren nach Anspruch 6, wobei der Schritt des Schreibens des Skripts ein Schreiben eines Personalisierungsabschnitts (810) des Chipkarten-Skripts einschließlich einmaliger Kartendaten der Chipkarte umfasst, wobei das Skript angepasst ist, um Chipkarten sowohl zu initialisieren als auch zu personalisieren.
  8. Verfahren zum Aufbau eines Chipkarten-Skripts nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner umfasst: Bestimmen einer Speichergröße, die auf der Chipkarte verfügbar sein soll, nach dem Laden von der zumindest einen Softwareanwendung auf die Chipkarte; und Erstellen eines aktualisierten Kartenprofils (230) durch Verändern des Kartenprofils (206), um eine Identifikation der zumindest einen geladenen Softwareanwendung und einen Hinweis auf die Speichergröße der Chipkarte zu enthalten.
  9. Verfahren nach Anspruch 8, wobei das aktualisierte Kartenprofil ein Profil einer ausgestellten Chipkarte ist und die geladenen Softwareanwendungen und den auf der ausgestellten Chipkarte verfügbaren Speicher wiederspiegelt.
  10. Verfahren zum Aufbau einer Chipkarte nach Anspruch 9, wobei die Chipkarte eine ausgestellte Karte ist und das Chipkarten-Skript (210') geeignet ist, für ein Laden der ausgestellten Chipkarte nach der Ausstellung verwendet zu werden, und wobei das aktualisierte Kartenprofil bestehende Anwendungssoftware, die früher auf die ausgestellte Chipkarte geladen wurde, identifiziert; wobei das Verfahren ferner die Schritte umfasst: Vergleichen des aktualisierten Kartenprofils mit dem Anwendungsprofil und Schreiben des Skripts unter Verwendung der Anwendungsprofildaten und des aktualisierten Kartenprofils, wobei im Gebrauch das Skript angepasst ist, um die zumindest eine Softwareanwendung auf die ausgestellte Chipkarte zu laden.
  11. Verfahren nach Anspruch 10, ferner umfassend: Empfangen von Kartenhalterdaten, die mit der zumindest einen Softwareanwendung in Zusammenhang stehen, wobei der Schritt des Schreibens des Skripts ferner die Verwendung der Kartenhalterdaten umfasst, wobei im Gebrauch das Skript angepasst ist, die Softwareanwendung zu personalisieren.
  12. Verfahren nach Anspruch 10 oder 11, ferner umfassend: Bestimmen, ob die von dem aktualisierten Kartenprofil dargestellte Chipkarte die Softwareanwendung unterstützen kann; und wenn bestimmt wird, dass die Chipkarte die Softwareanwendung nicht unterstützen kann, Auswählen eines anderen Anwendungsprofils, das die Anforderungen einer anderen Softwareanwendung beschreibt.
  13. Verfahren nach einem der Ansprüche 8 bis 12, wobei der Schritt des Empfangens der Anwendungsprofildaten das Empfangen einer Vielzahl von Anwendungsprofilen (201, 202, 203) umfasst, wobei jedes der Anwendungsprofile typisch für eine entsprechende Softwareanwendung ist, die für die Chipkarte vorgesehen ist (Schritt 500), und die Anforderungen der Softwareanwendung beschreibt; und eine entsprechende Datenelementtabelle umfasst, welche Datenelemente, die von den entsprechenden Softwareanwendungen gefordert sind, Stellen in der Chipkarte zuordnet, und wobei der Schritt des Schreibens des Skripts die Anwendungsprofile verwendet, wobei im Gebrauch das Skript angepasst ist, um eine Chipkarte für Mehrfachanwendungen herzustellen; wobei das Verfahren ferner umfasst: Erzeugen einer erweiterten Dateistruktur aus Dateistrukturen der Softwareanwendungen; Beschreiben der erweiterten Dateistruktur in dem Skript; Erzeugen einer kombinierten Datenelementtabelle aus Datentabellen der Softwareanwendungen; und Schreiben der kombinierten Datentabelle in das Skript, wobei das Skript (210') verwendet werden kann, um die Softwareanwendungen auf die ausgestellte Chipkarte zu laden.
  14. Verfahren nach einem der Ansprüche 1 bis 12, wobei der Schritt des Empfangens der Anwendungsprofildaten das Empfangen einer Vielzahl von Anwendungsprofilen (201, 202, 203) umfasst, wobei jedes typisch für eine entsprechende Softwareanwendung ist, die für die Chipkarte vorgesehen ist (Schritt 500), wobei die Anwendungsprofile die Anforderungen der Softwareanwendung beschreiben; und wobei der Schritt des Schreibens des Skripts die Anwendungsprofile verwendet, wobei im Gebrauch das Skript angepasst ist, um eine Chipkarte für Mehrfachanwendungen herzustellen.
  15. Verfahren nach Anspruch 13 oder 14, ferner umfassend: Vergleichen der Anwendungsprofile (201, 202, 203); Bestimmen, ob eine der Softwareanwendungen zu einer anderen der Softwareanwendungen inkompatibel ist (Schritt 302; Schritte 502–512); und wenn bestimmt wird, dass eine der Softwareanwendungen mit einer anderen inkompatibel ist, Auswählen eines anderen Anwendungsprofils (Schritt 500).
  16. Verfahren nach einem der Ansprüche 13 bis 15, wobei der Schritt des Schreibens des Skripts ferner umfasst: Schreiben eines Identitätsabschnitts (800) des Chipkarten-Skripts einschließlich einer Vielzahl von Anwendungsnamen, welche die Softwareanwendungen, die auf die Chipkarte geladen werden sollen, identifizierten, wobei das Skript verwendet werden kann, um eine Chipkarte für Mehrfachanwendungen herzustellen.
  17. Verfahren nach einem der Ansprüche 13 bis 16, wobei jedes der Anwendungsprofile eine entsprechende Datenelementtabelle umfasst, welche Datenelemente, die von den entsprechenden Softwareanwendungen gefordert werden, Stellen in der Chipkarte zuordnet, ferner umfassend: Erzeugen einer kombinierten Dateistruktur (Schritt 516) aus Dateistrukturen der entsprechenden Softwareanwendungen; Beschreiben der kombinierten Dateistruktur in dem Skript; Erzeugen einer kombinierten Datenelementtabelle (812) aus Datentabellen der entsprechenden Softwareanwendungen; und Schreiben der kombinierten Datenelementtabelle in das Skript.
  18. Verfahren zum Aufbau eines Chipkarten-Skripts nach einem der Ansprüche 13 bis 17, ferner umfassend: Bestimmen, ob die Ressourcen der Chipkarte ausreichend sind für die Softwareanwendungen (Schritt 520); und wenn bestimmt wird, dass die Ressourcen der Chipkarte nicht ausreichend sind für die Softwareanwendungen, Auswählen eines anderen Kartenprofils, welches die Ressourcen einer anderen Chipkarte beschreibt (Schritt 518).
  19. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Chipkarten-Skript für jeden Typ von Personalisierungs-Geräte auswählbar ist und angeordnet ist, um von dem Personalisierungs-Geräten interpretiert zu werden.
  20. System zum Aufbau eines Chipkarten-Erzeugungsskripts zur Verwendung bei der Herstellung einer Chipkarte, wobei das System umfasst: einen Computer; eine erste Computerdatei mit Anwendungsprofildaten, wobei die Anwendungsprofildaten für eine Softwareanwendung, die für die Chipkarte vorgesehen ist, typisch sind, wobei die Anwendungsprofildaten die Anforderungen der Softwareanwendung beschreiben; eine zweite Computerdatei mit Kartenprofildaten, wobei die Kartenprofildaten die Ressourcen der Chipkarte beschreiben; und eine Software zum Durchführen der Schreibfunktion eines Chipkarten-Erzeugungsskripts unter Verwendung der ersten und der zweiten Computerdatei.
  21. System nach Anspruch 20, ferner umfassend eine dritte Computerdatei mit Ausstellerdaten, wobei die Ausstellerdaten zu einer Vielzahl von Chipkarten gemeinsam gehören, wobei die Software auch die dritte Computerdatei verwendet.
  22. System nach Anspruch 20 oder 21, ferner umfassend eine vierte Computerdatei mit Verweisen auf Kartenhalterdaten, wobei die Software auch die vierte Computerdatei verwendet und das Skript im Gebrauch angepasst ist, um die Chipkarte zu personalisieren.
  23. System nach einem der Ansprüche 20 bis 22, ferner umfassend eine Vielzahl von Computerdateien, jede mit Anwendungsprofildaten, die für eine entsprechende Softwareanwendung, die für die Chipkarte vorgesehen ist, typisch sind, wobei die Anwendungsprofildatendateien die Anforderungen der Softwareanwendungen beschreiben, wobei die Software auch die Vielzahl von Computerdateien verwendet und das Skript, im Gebrauch, angepasst ist, um eine Chipkarte für Mehrfachanwendung herzustellen.
  24. System zum Aufbau eines Chipkarten-Skripts nach Ansprüchen 20 bis 23, wobei die Chipkarte eine ausgestellte Chipkarte ist und das Chipkarten-Skript geeignet ist zur Verwendung nach der Ausstellung der ausgestellten Chipkarte, wobei die Kartenprofildaten aktualisierte Kartenprofildaten umfassen, wobei die aktualisierten Kartenprofildaten bestehende Anwendungssoftware, die früher auf die ausgestellte Chipkarte geladen wurde, identifizieren; wobei das System ferner umfasst: eine Software zum Vergleichen der ersten Computerdatei mit der zweiten Computerdatei; wobei die Software zum Ausführen der Schreibfunktion des Chipkarten-Skripts die Anwendungsprofildaten und das aktualisierte Kartenprofil verwendet, wobei im Gebrauch das Skript angepasst ist, um die zumindest eine Softwareanwendung auf die ausgestellte Chipkarte zu laden.
  25. System nach einem der Ansprüche 20 bis 24, wobei das Chipkarten-Erzeugungsskript für jeden Typ von Personalisierungs-Gerät auswählbar ist und angeordnet ist, um von dem Personalisierungs-Gerät interpretiert zu werden.
  26. Chipkarten-Skriptdatenstruktur, integriert in ein Computer lesbares Medium, wobei die Skriptdatenstruktur umfasst: einen physikalischen Abschnitt (802) mit physikalischen Attributen der Chipkarte; einen Initialisierungsabschnitt (808) mit allgemeinen Kartendaten, die auf die Chipkarte geschrieben werden sollen; einen Personalisierungsabschnitt (810) mit einzigartigen Daten, die auf die Chipkarte geschrieben werden sollen; und eine Datentabelle (812) mit Werten oder Verweisen für Daten, die von einer Anwendung der Chipkarte verwendet werden, wobei die Skriptdatenstruktur geeignet ist für die Herstellung einer Chipkarte mit der Anwendung.
  27. Chipkarten-Skriptdatenstruktur nach Anspruch 26, ferner umfassend: einen Identitätsabschnitt (800) mit einer Vielzahl von Anwendungsnamen, welche die Anwendungen, die auf die Chipkarte geladen werden sollen, identifizieren; und einen Funktionsabschnitt (806) mit Funktionen zum Laden der Anwendungen auf die Chipkarte, wobei die Skriptdatenstruktur angepasst ist, um eine Chipkarte mit Mehrfachanwendungen herzustellen.
  28. Chipkarten-Skriptdatenstruktur nach Anspruch 26 oder 27, wobei die Chipkarten-Erzeugungsskript-Datenstruktur für jeden Typ von Personalisierungs-Gerät auswählbar ist und an geordnet ist, um von dem Personalisierungs-Geräten interpretiert zu werden.
DE60015810T 2000-04-11 2000-04-11 Integriertes verfahren zur herstellung von chipkarten Expired - Lifetime DE60015810T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2000/009718 WO2001078020A1 (en) 2000-04-11 2000-04-11 Integrated production of smart cards

Publications (2)

Publication Number Publication Date
DE60015810D1 DE60015810D1 (de) 2004-12-16
DE60015810T2 true DE60015810T2 (de) 2005-10-27

Family

ID=21741264

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60015810T Expired - Lifetime DE60015810T2 (de) 2000-04-11 2000-04-11 Integriertes verfahren zur herstellung von chipkarten

Country Status (6)

Country Link
EP (1) EP1272983B1 (de)
AT (1) ATE282231T1 (de)
AU (1) AU2000240814A1 (de)
CA (1) CA2405477A1 (de)
DE (1) DE60015810T2 (de)
WO (1) WO2001078020A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005052888A1 (de) * 2005-11-07 2007-05-16 Giesecke & Devrient Gmbh Verfahren zur Personalisierung von tragbaren Datenträgern
DE102006021382B4 (de) * 2006-05-08 2015-08-20 Giesecke & Devrient Gmbh Personalisierung von portablen Datenträgern

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020162021A1 (en) 2001-04-30 2002-10-31 Audebert Yves Louis Gabriel Method and system for establishing a remote connection to a personal security device
US7320126B2 (en) * 2001-11-06 2008-01-15 Sandisk Corporation Implementation of in system programming to update firmware on memory cards
FR2836258A1 (fr) * 2002-02-21 2003-08-22 Frederic Lambret Systeme de gestion d'information personnalisees, accessibles sur un site internet
US8010405B1 (en) 2002-07-26 2011-08-30 Visa Usa Inc. Multi-application smart card device software solution for smart cardholder reward selection and redemption
US8626577B2 (en) 2002-09-13 2014-01-07 Visa U.S.A Network centric loyalty system
US9852437B2 (en) 2002-09-13 2017-12-26 Visa U.S.A. Inc. Opt-in/opt-out in loyalty system
US8015060B2 (en) 2002-09-13 2011-09-06 Visa Usa, Inc. Method and system for managing limited use coupon and coupon prioritization
US7827077B2 (en) 2003-05-02 2010-11-02 Visa U.S.A. Inc. Method and apparatus for management of electronic receipts on portable devices
US8554610B1 (en) 2003-08-29 2013-10-08 Visa U.S.A. Inc. Method and system for providing reward status
US7051923B2 (en) 2003-09-12 2006-05-30 Visa U.S.A., Inc. Method and system for providing interactive cardholder rewards image replacement
US8407083B2 (en) 2003-09-30 2013-03-26 Visa U.S.A., Inc. Method and system for managing reward reversal after posting
US8005763B2 (en) 2003-09-30 2011-08-23 Visa U.S.A. Inc. Method and system for providing a distributed adaptive rules based dynamic pricing system
US7653602B2 (en) 2003-11-06 2010-01-26 Visa U.S.A. Inc. Centralized electronic commerce card transactions
EP1703476A1 (de) * 2005-03-18 2006-09-20 Hewlett-Packard Development Company, L.P. Stufenweise Personalisierung von Mehrfachanwendungschipkarten
EP1936574A1 (de) * 2006-12-01 2008-06-25 Cassis International PTE Ltd. CAP-Datei zur Personalisierung von Java-Anwendungen
CN102025710B (zh) 2009-09-11 2015-11-25 中国银联股份有限公司 多应用智能卡及智能卡多应用管理系统和方法
US7992781B2 (en) 2009-12-16 2011-08-09 Visa International Service Association Merchant alerts incorporating receipt data
US8429048B2 (en) 2009-12-28 2013-04-23 Visa International Service Association System and method for processing payment transaction receipts
DE102010006987A1 (de) * 2010-02-05 2011-08-11 Giesecke & Devrient GmbH, 81677 Komplettierung portabler Datenträger
GB2550207A (en) 2016-05-13 2017-11-15 Visa Europe Ltd Extended data storage
CN108718238B (zh) * 2018-05-11 2023-04-18 北京握奇智能科技有限公司 一种通用个人化的方法和系统
EP3633573A1 (de) * 2018-10-05 2020-04-08 Giesecke+Devrient Mobile Security GmbH Verfahren und system zur identitätsbasierten sofortausgabe von karten
FR3097672A1 (fr) * 2019-06-21 2020-12-25 Aava Mobile Sas Système d’applications de service pour terminaux de paiement
IT201900017561A1 (it) * 2019-09-30 2021-03-30 St Microelectronics Srl "Procedimento per introdurre dati di personalizzazione in memorie non volatile di una pluralità di circuiti integrati, in particolare in carte a circuito integrato, corrispondente sistema e prodotto informatico"
CN111160896A (zh) * 2019-12-25 2020-05-15 大唐微电子技术有限公司 一种智能卡定制方法、设备和系统、存储介质
DE102022200754A1 (de) 2022-01-24 2023-07-27 Continental Automotive Technologies GmbH Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2623332B2 (ja) * 1988-02-03 1997-06-25 日立マクセル株式会社 Ｉｃカード及びその動作プログラム書込み方法
FR2695235B1 (fr) * 1992-08-31 1994-10-21 Solaic Sa Procédé de fabrication d'une carte intelligente comportant un micro-circuit à mémoire inscriptible.
FR2725540B1 (fr) * 1994-10-07 1997-01-03 Serpeinesm Sa Procede de personnalisation en serie de cartes
US5889941A (en) 1996-04-15 1999-03-30 Ubiq Inc. System and apparatus for smart card personalization
US5923884A (en) * 1996-08-30 1999-07-13 Gemplus S.C.A. System and method for loading applications onto a smart card
US6317832B1 (en) * 1997-02-21 2001-11-13 Mondex International Limited Secure multiple application card system and process

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005052888A1 (de) * 2005-11-07 2007-05-16 Giesecke & Devrient Gmbh Verfahren zur Personalisierung von tragbaren Datenträgern
DE102006021382B4 (de) * 2006-05-08 2015-08-20 Giesecke & Devrient Gmbh Personalisierung von portablen Datenträgern

Also Published As

Publication number Publication date
CA2405477A1 (en) 2001-10-18
WO2001078020A1 (en) 2001-10-18
ATE282231T1 (de) 2004-11-15
DE60015810D1 (de) 2004-12-16
EP1272983A1 (de) 2003-01-08
EP1272983B1 (de) 2004-11-10
AU2000240814A1 (en) 2001-10-23

Similar Documents

Publication Publication Date Title
DE60015810T2 (de) Integriertes verfahren zur herstellung von chipkarten
DE69823649T2 (de) Multi-anwendungs ic-kartensystem
US6402028B1 (en) Integrated production of smart cards
DE69826318T2 (de) Kartenaktivierung an der verteilungsstelle
DE69916260T2 (de) Verfahren und Geräte für dynamische Smartkarten-Synchronisierung und Personalisierung
DE69813208T2 (de) Chipkarte mit datenumsetzer
DE69912749T2 (de) System und verfahren zum sperren und freigeben einer chipkartenanwendung
DE69534441T2 (de) System und Verfahren zum Verkaufen von elektronischen Wertkarten
DE69720181T2 (de) System und verfahren zum laden von mehrfachen anwendungen in eine chipkarte
DE69824437T2 (de) Personalisieren von chipkarten
DE2760485C2 (de)
DE69925810T2 (de) Verfahren und vorrichtung für eine reisebezogene multifunktionelle chipkarte
US6317832B1 (en) Secure multiple application card system and process
DE60316498T2 (de) Chipkarte, tragbares Endgerät und Zugriffsteuerungsverfahren
WO2003049056A2 (en) Smartcard system
DE69932412T2 (de) Chipkartenkonfiguration
DE19718115A1 (de) Chipkarte und Verfahren zur Verwendung der Chipkarte
EP0968485A2 (de) Chipkarte und verfahren zur verwendung der chipkarte
US20070094149A1 (en) Smartcard-based value transfer
EP0961241A2 (de) Persönliches Überweisungsystem mittels Chipkarten mit mehrfachiger Speicher
KR20040089974A (ko) 스마트 카드 저장 정보 자동 삭제 방법 및 시스템
DE102007027935A1 (de) Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers
DE19853730C2 (de) Verfahren und Vorrichtung zum Identifizieren und Behandeln von kritischen Chipkartenkommandos
KR101124262B1 (ko) 혼용카드용 애플리케이션 또는 서비스 코드 제작 및 중계방법
EP1605415A1 (de) Dateienverwaltungssystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: GLOBALPLATFORM, INC. (N.D.GES.D. STAATES DELAWARE)

8328 Change in the person/name/address of the agent

Representative=s name: HOEFER & PARTNER, 81543 MUENCHEN