-
TECHNISCHES GEBIET
-
Die
vorliegende Erfindung bezieht sich im allgemeinen auf die Verwendung
von Karten mit integrierter Schaltung ("Smartcards") für
kommerzielle Transaktionen, und genauer auf Techniken zum dynamischen
Synchronisieren und Personalisieren einer Smartcard-Information
im Rahmen eines verteilten Transaktionssystems.
-
STAND DER TECHNIK UND
TECHNISCHE PROBLEME
-
Jüngste Fortschritte
im Internet-Handel, bei der elektronischen Datenverarbeitung und
bei der Halbleitervorrichtungs-Technologie haben zu einem gestiegenen
Interesse an einer Smartcard-Technologie geführt. Allgemein gesagt sind
Smartcards Karten von der Größe einer
Geldbörse
(oder kleiner), welche einen Mikroprozessor oder Mikrocontroller enthalten,
um Daten innerhalb der Karten zu speichern und zu verwalten. Komplexer
als Magnetstreifen- und Speicherwertkarten sind Smartcards durch komplizierte
Speicherverwaltungs- und Sicherheitsmerkmale gekennzeichnet. Multifunktionskarten
sind beispielsweise oft so aufgebaut, dass sie einen Kredit, eine
Belastung, einen gespeicherten Wert, eine Loyalität und eine
Anzahl weiterer Anwendungen alle innerhalb einer einzigen Karte
unterstützen.
Eine typische Multifunktions-Smartcard
enthält
einen innerhalb der Plastikkarte eingebundenen Mikrocontroller, welcher
elektrisch mit einem Array von externen Kontakten verbunden ist,
welche auf dem Äußeren der Karte
bereitgestellt sind. Der Smartcard-Mikrocontroller enthält im allgemeinen
einen elektrisch löschbaren
und programmierbaren Festwertspeicher (EEPROM) zum Speichern von
Benutzerdaten, einen Arbeitsspeicher (RAM) zur Arbeitsspeicherung
und einen Festwertspeicher (ROM) zum Speichern des Kartenbetriebssystems.
Relativ einfache Mikrocontroller sind geeignet um diese Funktion
zu steuern. Somit ist es bei Smartcards nicht unüblich, 8-Bit, 5 MHZ Mikrocontroller
zu verwenden, mit ungefähr
8K an EEPROM-Speicher (beispielsweise die Motorola 6805 oder Intel
8051 Mikrocontroller).
-
Eine
Anzahl an Standards wurde entwickelt, um unterschiedliche Aspekte
von Karten mit integrierter Schaltung zu verwenden, beispielsweise: ISO
7816-1, Part 1: Physical characteristics (1987); ISO 7816-2, Part 2: Dimensions
and locations of the contacts (1988); ISO 7816-3 Part 3: Electronic
signals and transmission protocols (1989, Amd. 1 1992, Amd. 2 1994);
ISO 7816-4, Part 4: Inter-industry commands for interchange (1995);
ISO 7816-5, Part 5: Numbering system and registration procedure
for application identifiers (1994, Amd. 1 1995); ISO/IEC DIS 7816-6,
Inter-industry data elements (1995); ISO/IEC WD 7816-7, Part 7:
Enhanced inter-industry commands (1995; und ISO/IEC WD 7816-8, Part
8: Inter-industry security architecture (1995). Ferner kann eine
allgemeine Information bezüglich
Magnetstreifenkarten und Chipkarten in einer Anzahl an Standardtexten
gefunden werden, beispielsweise Zoreda & Oton, SMART CARDS (1994), und Rankl & Effing, SMART
CARD HANDBOOK (1997).
-
Es
ist bei jeder von einem Konsumenten gehaltener Smartcard wünschenswert,
eine im wesentlichen genaue Historie an Transaktionsinformation und
Anwendungen aufrecht zu erhalten, welche mit der Smartcard in Verbindung
stehen. Derzeit bekannte Systeme sind typischerweise bezüglich dessen ungeeignet,
als dass sie keine effiziente und zuverlässige Verfahren zum Sicherstellen
einer Synchronisation zwischen Information, welcher auf der Smartcard
gespeichert ist, und entsprechender Information, welche in einer
von mehreren externen Datenbasen gespeicherten ist, bereitstellen.
Daraus folgend versagen vorliegende Systeme dahingehend, sicherzustellen,
dass verlorene oder gestohlene Karten wiederverwendet oder mit aktualisierter
Information wiederverwendet werden können.
-
Darüber hinaus
sind vorliegende Systeme dahingehend ungeeignet, als dass die Systeme
es einer Gesellschaft, wie beispielsweise ein Smartcard-Kooperationspartner
(beispielsweise Hertz, Hilton, und dergleichen), nicht ermöglichen,
dynamisch die Smartcard-Anwendungsstruktur
selber dynamisch hinzuzufügen
oder anderweitig zu modifizieren. Das heißt, dass es im Rahmen von Multifunktionskarten
oft nicht machbar ist, die Dateistruktur der Karte zu ändern oder
zu erweitern, ohne sich mit dem zeitintensiven und teuren Prozess
einer Neuausgabe der Karte zu befassen.
-
Ferner
sind bekannte Verfahren zum Ausgeben und Neuausgeben von Smartcards
in einer Mehrfachanwendung, Mehrfach-Gesellschaftsumgebung typischerweise
ungeeignet. Darüber
hinaus enthält
eine Smartcard oft eine Anzahl unterschiedlicher Anwendungen, welche
mit einem weiten Bereich von Organisationen einer Gesellschaft in
Verbindung stehen. Aus Sicherheitsgründen sind das Schreiben, Aktualisieren
und Lesen dieser Dateien vorteilhafterweise auf bestimmte Parteien
beschränkt,
und zwar gemäß eines
Satzes an Zugriffsbedingungsregeln. Diese Zugriffsbedingungen sind geeigneterweise
unter Verwendung von kryptologischen Schlüsseln implementiert, welche
nur den geeigneten Parteien bekannt sind, wie zum Beispiel der Gesellschaft.
Somit wird eine Kartenausgebende Partei, wie beispielsweise American
Express, typischerweise keinen Zugriff auf die Schlüssel haben, welche
notwendig sind, um ihre Funktion durchzuführen. Bekannte Systeme versuchten
dieses Problem zu lösen,
indem sie Schlüsseldaten
in einem zentralen Aufbewahrungsort ansammelten, welcher im Ausgabeprozess
verwendet wird. Dieses Verfahren ist in vielerlei Hinsicht unzufriedenstellend.
Vor allem würde
eine Sicherheitslücke
im zentralen Aufbewahrungsort von einer Schlüsselinformation fatale Konsequenzen
haben.
-
Beispiele
aus dem Stand der Technik enthalten die WO 97/39424, welche ein
System und eine Vorrichtung zur Smartcard-Personalisierung beschreibt.
Sie enthält
ein Smartcard-Personalisierungssystem, welche eine Datenbasis aufrecht
erhält,
welche Formatvorlagen von Kartenausgeberdaten, Kartenanwendungen,
Spezifikationen von Befehlen und Personalisierungs-Ausstattung von
Kartenbetriebssystemen aufrecht erhält. Das System ist derart angepasst,
dass es eine zentralisierte Schnittstelle von Eingaben und Ausgaben
an einen Kartenausgabeprozess bereitstellt, welcher dynamisch Änderungen
im Ausgabeprozess einstellt, um es einem Kartenausgeber zu ermöglichen,
die Formate, Kartenanwendungen, Kartenbetriebssysteme und/oder Personalisierungs-Ausstattung
bei einem Kartenausgabeprozess einfach zu ändern.
-
Ein
weiteres Beispiel einer Anwendung aus dem Stand der Technik ist
die
EP 0 836 160 , welche ein
Verfahren und System zum Beschränken
einer Zuwiderverwendung von gefälschten
Kreditkarten, Zugriffsmarken, elektronischen Konten oder dergleichen
beschreibt. Das System ist derart angepasst, dass es eine Zurückweisung
einer zweiten und darauffolgender Kopien von einer informationsgleichen Karte
oder von einer Mar ke, welche in ein Client/Server-System eingebracht
wird, ermöglicht,
indem nur jene Karten verarbeitet werden, welche darauf gespeicherte
Transaktionshistorien haben.
-
Es
gibt immer noch Probleme, welche mit diesen bekannten Anwendungen
in Verbindung stehen, und daher werden Techniken benötigt, um
diese und weitere Beschränkungen
aus dem Stand der Technik zu beheben. Genauer gesagt, werden Systeme
benötigt,
welche eine sichere und effiziente Personalisierung und dynamische
Synchronisation von Multifunktions-Smartcards bereitzustellen.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die
vorliegende Erfindung behebt die Beschränkungen aus dem Stand der Technik,
indem sie Verfahren und eine Vorrichtung zum Personalisieren und
Synchronisieren von Smartcard-Daten im Rahmen eines verteilten Transaktionssystems
bereitstellt.
-
Gemäß eines
Aspektes der vorliegenden Erfindung enthält ein dynamisches Smartcard-Synchronisationssystem
Zugriffspunkte, welche so konfiguriert sind, dass sie eine Transaktion
in Verbindung mit einer Smartcard, einer Gesellschaftsdaten-Sammeleinheit
und einem Kartenobjekt-Datenbasis-Aktualisierungssystem einleiten.
Ein beispielhaftes dynamisches Synchronisationssystem (DSS) enthält vorzugsweise
unterschiedliche Smartcard-Zugriffspunkte, einen Sicherheitssupport-Clientserver, ein
Kartenobjekt-Datenbasis-Aktualisierungssystem (CODUS), eine oder
mehrere Gesellschaftsdaten-Synchronisationsschnittstellen
(EDSI), ein Aktualisierungs-Logiksystem,
eine oder mehrere Gesellschaftsdaten-Sammeleinheiten (EDCUs) und
einen oder mehrere Smartcard-Zugriffspunkte, welche so aufgebaut
sind, dass sie kompatibel Smartcards akzeptieren und mit ihnen eine
Schnittstelle aufbauen. Bei einer beispielhaften Ausführungsform
enthält
ein DSS ein Personalisierungssystem und ein Konto-Wartungssystem, welche
so aufgebaut sind, dass sie mit CODUS kommunizieren.
-
Gemäß eines
weiteren Aspektes der vorliegenden Erfindung wird eine Personalisierung
von Multifunktions-Smartcards unter Verwendung eines Sicherheitsservers
ermöglicht,
welcher so aufgebaut ist, dass er eine kryptographische Schlüsselinformation
aus mehreren Gesellschafts schlüsselsystemen während der
Endphase des Smartcard-Ausgabeprozesses erzeugt und/oder abfragt.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
Der
Gegenstand der Erfindung wird im folgenden in Verbindung mit den
begleitenden Zeichnungsfiguren beschrieben, bei denen gleiche Bezugsziffern
gleiche Elemente kennzeichnen, und:
-
1 eine schematische Übersicht
eines beispielhaften dynamischen Synchronistionssystems gemäß unterschiedlicher
Aspekte der vorliegenden Erfindung ist;
-
2 eine schematische Übersicht
eines beispielhaften Sicherheitssupport-Clientservers ist;
-
3 eine schematische Übersicht
einer beispielhaften Gesellschaftsdaten-Synchronisationsschnittstelle
ist;
-
4 eine schematische Übersicht
eines beispielhaften Aktualisierungs-Logiksystems ist;
-
5 eine schematische Übersicht
einer beispielhaften Gesellschaftsdaten-Sammeleinheit ist;
-
6 eine schematische Übersicht
eines beispielhaften Kartenobjekt-Datenbasis-Aktualisierungssystems
(CODUS) ist;
-
7 ein Ablaufdiagramm ist,
welches ein beispielhaftes Verfahren zum Synchronisieren einer anhängigen Transaktionsinformation
darstellt;
-
8 ein Ablaufdiagramm ist,
welches ein beispielhaftes Verfahren zum Synchronisieren von einer
Aktualisierungs-Transaktionsinformation
darstellt;
-
9 eine schematische Übersicht
eines beispielhaften Personalisierungssystems ist;
-
10 ein Ablaufdiagramm ist,
welches ein beispielhaftes Verfahren einer Smartcard-Personalisierung
darstellt; und
-
11 eine beispielhafte Transaktions-Datenstruktur
ist, welche zur Verwendung im Rahmen einer Reise geeignet ist.
-
GENAUE BESCHREIBUNG BEVORZUGTER
BEISPIELHAFTER AUSFÜHRUNGSFORMEN
-
Ein
System gemäß unterschiedlicher
Aspekte der vorliegenden Erfindung enthält Verfahren und eine Vorrichtung
zum Personalisieren und dynamischen Synchronisieren von Smartcards
und damit in Verbindung stehender Datenbasen im Rahmen eines verteilten
Transaktionssystems. Genauer gesagt, enthält nun unter Bezugnahme auf 1 ein beispielhaftes dynamisches
Synchronisationssystem (DSS) vorzugsweise einen Sicherheitssupport-Clientserver 104,
ein Kartenobjekt-Datenbasis-Aktualisierungssystem 106 (CODUS),
eine oder mehrere Gesellschaftsdaten-Synchronisationsschnittstellen 108 (EDSI),
ein Aktualisierungs-Logiksystem 110, eine
oder mehrere Gesellschaftsdaten-Sammeleinheiten 112 (EDCUs)
und einen oder mehrere Smartcard-Zugriffspunkte 102, welche
so aufgebaut sind, dass sie kompatibel Smartcards 120 akzeptieren
und mit ihnen eine Schnittstelle aufbauen. Bei einer beispielhaften
Ausführungsform
enthält
ein DSS ebenfalls geeigneterweise ein Personalisierungssystem 140 und
ein Konto-Wartungssystem 142, welches so aufgebaut ist,
dass es mit dem CODUS 106 kommuniziert.
-
Genauer
gesagt, ist bei einer bevorzugten Ausführungsform der Sicherheitssupport-Clientserver 104 über ein
geeignetes Netzwerk durch Gesellschafts-Netzwerke 114 mit
EDSIs 108 verbunden. EDSIs 108 sind mit einem
Aktualisierungs-Logiksystem 110 verbunden, welches selber
mit Gesellschaftsdaten-Sammeleinheiten 112 verbunden ist. Die
Gesellschaftsdaten-Sammeleinheiten 112 sind mit CODUS 106 und
einem Sicherheitssupport-Clientserver 104 verbunden. Im
allgemeinen, wie unten im weiteren Detail beschrieben, steht jede
Gesellschaft (beispielsweise ein Luftfahrtgesellschafts-Partner,
Hotel-Partner, eine Reiseagentur, usw.) vorzugsweise mit einer entsprechenden
EDSI 108, einem Gesellschafts-Netzwerk 114 und
einer EDCU 112 in Verbindung. Dass heißt, dass eine EDCU 112(a) einem
EDSI 108(a) und einem Gesellschafts-Netzwerk 114(a) entspricht,
eine EDCU 112(b) einem EDSI 108(b) und einem Gesellschafts-Netzwerk 114(b) entspricht,
usw. Das DSS kann eine beliebige Anzahl an solchen Funktionsblöcken gemäß der Anzahl
an dargestellten Gesellschaften enthalten.
-
Ein
Personalisierungssystem 140 wirkt vorzugsweise als die
Ausgabequelle von Smartcards 120. Dass heißt, dass
ein Personalisierungssystem 140 Smartcards zur Verwendung
von dem Konsumenten erzeugt und ausgibt, und zwar durch Bereitstellen
einer vorbestimmten Dateistruktur, welche mit Initialisierungsdaten
bestückt
ist (beispielsweise Kontonummern, Seriennummern, Vorgabepräferenzen
und dergleichen). Angesichts dessen baut das CODUS 106 eine
Schnittstelle mit einem Personalisierungssystem 140 auf,
um eine Neuausgabe der Karte durch Bereit stellen von aktualisierten
Daten neu auszugeben, falls eine Karte zerstört, verloren oder gestohlen
ist. Das Personalisierungssystem 140 ist unten detailliert
in Verbindung mit 9 beschrieben.
-
Ein
Konto-Wartungssystem 142 ist aus Gründen eines Konsumentenservice
bereitgestellt, und seine Kapazität wirkt im Falle einer Eingabe
von Karteninhaber-Beschwerden, Fragen und einer weiteren Konsumenteneingabe.
Das CODUS 106 kommuniziert geeigneterweise mit dem Konto-Wartungssystem 140,
um Konsumentenservice-Repräsentanten
und/oder automatisierte Systeme beim Adressieren von Karteninhaber-Ausgaben
zu unterstützen.
-
Smartcard-Zugriffspunkte
-
Smartcard-Zugriffspunkte 102 ermöglichen es
dem Karteninhaber einen Zugriff auf das verteilte Transaktionssystem über eine
Vielzahl von Mitteln zu erlangen. Solche Zugriffspunkte können beispielsweise
ein Standardtelefon, unterschiedliche PCS Drahtlossysteme, Münzfernsprecher,
Palmtop-Computer, Notebook-Computer, Internet-Arbeitsstationen, Geldautomaten (ATMs),
Kassenterminals (POS), Einzelkioske, Netzwerkcomputer (NCs), Personal
Data Assistants (PDAs) oder jegliche andere geeignet konfigurierte
Kommunikationsvorrichtungen sein.
-
Zugriffspunkte 102 können tragbar
sein (wie im Falle von PDAs und Mobiltelefonen) oder zentral lokalisiert
sein, wie beispielsweise beim Fluggesellschaft-Kartenverkauf und
im Flugsteig-Bereichen, bei Mietfahrzeug-Umgebungen, Hotellobbys,
Reiseagenturen und Supermärkten.
Zusätzlich
können
Unternehmen selber zum Einrichten eines Zugriffspunktes 102 Sorge
tragen, um Businessreisen ihrer Arbeitnehmer zu rationalisieren.
Bei einer bevorzugten Ausführungsform
sind unterschiedliche Zugriffspunkte 102 derart aufgebaut,
dass sie mit kontaktbasierten Smartcards 120 gemäß den relevanten
Abschnitten des ISO-7816 Standards eine Schnittstelle bilden.
-
Sicherheitssupport-Clientserver
-
Sicherheitssupport-Clientserver 104 stellen, wann
immer geeignet, jegliche Funktionalität bereit, welche vom einzelnen
Zugriffspunkt 102, welcher während einer Transaktion verwendet
wird, vermisst wird. Der Server 104 handhabt ebenfalls
geeigneterweise eine Führung
von Meldungen von Zugriffspunkten 102 an die geeignete
EDSI 108 und/oder EDCU 112.
-
Bezugnehmend
nun auf 1 und 2 enthält ein beispielhafter Sicherheitssupport-Clientserver 104 eine
Sicherheitsmaschine (Security Engine) 202, eine Zusatzanwendung-Unterstützung 204 und
einen Router 206. Die Sicherheitsmaschine 202 enthält geeignete
Hardware und/oder Software, um eine Sicherheitsmeldung zwischen
Server 104, EDCUs 112 und Gesellschafts-Netzwerken 114 bereitzustellen. Genauer
gesagt verwendet die Sicherheitsmaschine 202 eine Authentifikation,
Datenverschlüsselung
und digitale Signaturtechniken in Verbindung mit eingehenden und
ausgehenden Meldungspaketen. Eine Vielzahl von herkömmlichen
Sicherheitsalgorithmen ist im Rahmen der vorliegenden Erfindung
geeignet, welche beispielsweise DES-Verschlüsselung, RSA-Authentifikation
und eine Vielzahl weiterer symmetrischer oder unsymmetrischer kryptographischer Techniken
enthalten.
-
Die
Zusatzanwendung-Unterstützung 204 enthält vorzugsweise
geeignete Hardware- und/oder Software-Bauteile, welche sich auf
eine spezifische Funktionalität
eines Zugriffspunkts 102 beziehen. Genauer gesagt, bestimmt
der Server 104 geeigneterweise die Beschaffenheit des Zugriffspunktes 102, welcher
während
einer Transaktion verwendet wird. Wenn der Zugriffspunkt 102 nicht
die geeignete Software zum Bewirken der angefragten Transaktion
enthält,
versorgt der Server 104 die Funktionalität (dass heißt Softwaremodule),
welche die Transaktion mit jeweiligen EDSIs 108 und/oder
EDCUs 112 vollendet. Die Zusatzfunktionalität enthält unter
anderem Softwaremodule zum korrekten Formatieren von Meldungspaketen
(wie unten weiter detailliert beschrieben), welche über die
unterschiedlichen Netzwerke, welche das DSS enthalten, gesendet
werden. Wenn beispielsweise eine Transaktion über einen Zugriffspunkt 102 stattfindet,
welcher nur einen autonomen Smartcard-Leser enthält, dann werden beinahe alle
Funktionen über
den Server 104 versorgt, weil der Smartcard-Leser selber
nur in der Lage ist, Meldungen zu und von der Smartcard 120 auf
eine "verschleuderte" Weise („dump" manner) zu übertragen. Wenn
jedoch ein geeignet konfigurierter PC für den Zugriffspunkt 102 enthalten
ist, wird die notwendigste Funktionalität durch unterschiedliche Softwaremodule
versorgt, welche im PC innewohnen. In einem solchen Fall braucht
der Server 104 nur die unterschiedlichen Meldungspakete
zu und von dem Zugriffspunkt 102 zu über tragen, ohne zusätzliche
Software zuzuführen.
Eine zusätzliche
Funktionalität
kann über
jegliches geeignetes verfahren zugeführt werden, beispielsweise
durch die Verwendung von tragbarem Softwarecode (portable software
code)(beispielsweise Java, ActiveX, und dergleichen) oder über verteilte Software,
welche in Zugriffspunkten 102, Karten 120 und/oder
im Server 104 innewohnt.
-
Der
Router 206 handhabt geeigneterweise ein Führen von
Meldungen an die geeigneten EDCUs 112, Gesellschafts-Netzwerke 114 und
Zugriffspunkte 102. Dass heißt, dass der Router 206 dazu
konfiguriert ist, die geeigneten Funktionsblöcke innerhalb der DSS zu identifizieren,
an welche ein vorliegendes Meldungspaket gesendet werden sollte.
Die Identifikation der geeigneten Funktionsblöcke kann auf eine Vielzahl
von Arten stattfinden. Bei einer bevorzugten Ausführungsform
wird die Identifikation durch die Verwendung einer Suchtabelle durchgeführt, welche eine
Liste an geeigneten Zielen enthält,
welche informationsverschlüsselt
sind, und durch Anfragen extrahiert werden, welche von Zugriffspunkten 102 empfangen
werden.
-
Bei
einer alternativen Ausführungsform
der vorliegenden Erfindung wird ein Sicherheitssupport-Clientserver 104 nicht
verwendet, und die Funktionalität
an Zugriffspunkten 102 wird geeigneterweise spezifiziert,
um den Bedarf des Servers 104 zu umgehen. Alternativ können die
Funktionen des Servers 104 durch die DSS-Komponenten auf
jegliche vorteilhafte Weise zugewiesen und verteilt werden.
-
Es
wird dem Fachmann klar sein, dass der Ausdruck "Transaktion" sich im allgemeinen auf jegliche Meldung
bezieht, welche über
das System kommuniziert wird, um ein bestimmtes Ziel zu bewirken, beispielsweise
eine Lastschrift/Kostenautorisierung, ein Präferenzwechsel, Reservierungsanfragen,
Ticketanfragen und dergleichen. 11 zeigt
beispielsweise eine beispielhafte Transaktions-Datenstruktur, welche
im Rahmen einer Durchführung
einer Online-Transaktion mit einem Reisepartner verwendbar ist,
wobei der Feldname 1102, Datentyp 1104 ("C" als Bezugszeichen), die maximale Bitelänge 1106 und
eine Beschreibung 1108 in Tabellenform aufgelistet sind.
In diesem Beispiel enthalten die Transaktionsmeldungen geeigneterweise
abgegrenzte Datenpakete, obwohl weitere Datenstrukturen verwendet
werden können.
-
Kartenobjekt-Datenbasis-Aktualisierunssystem
(CODUS)
-
CODUS 106 speichert
geeigneterweise sicher Information bezüglich des Zustandes der unterschiedlich
ausgegebenen Smartcards 120. Bezugnehmend nun auf 1 und 6 enthält CODUS 106 in einer
bevorzugten Ausführungsform
eine Sicherheitsmaschine 602, ein Datenverwaltungsmodul 604, eine
Kartenobjekt-Datenbasis 116, ein Kartenobjekt-Administrationsmodul 606 und
eine Prüfdatei 608.
-
Die
Sicherheitsmaschine 602 stellt eine geeignete Sicherheit
unter anderem für
die innerhalb der Kartenobjekt-Datenbasis 116 gespeicherte
Information bereit. Angesichts dessen kann die Sicherheitsmaschine 602 unterschiedliche
Authentifizierungs-, Datenverschlüsselungs- und digitale Signaturtechniken
in Verbindung mit eingehenden und ausgehenden Meldungspaketen verwenden.
Geeignete Algorithmen im Rahmen der vorliegenden Erfindung enthalten
beispielsweise eine DES-Verschlüsselung,
RSA-Authentifikation und eine Vielzahl weiterer symmetrischer und
unsymmetrischer kryptographischer Techniken.
-
Das
Datenverwaltungsmodul 604 wirkt geeigneterweise als eine
Datenschnittstelle zwischen CODUS 106 und einer Konto-Verwaltung 142,
als auch zwischen CODUS 106 und den unterschiedlichen EDCUs 112.
Genauer gesagt, wandelt das Modul 604 zwischen dem in diesen
Systemen verwendetem Datenformat um, und übersetzt. Beispielsweise können Daten,
welche innerhalb der Objekt-Datenbasis 106 gespeichert
sind, nicht in einem Format gespeichert werden, welches einfach
durch EDCUs 112 oder der Konto-Verwaltung 142 verwendet
werden kann. Demgemäß enthält das Datenverwaltungsmodul 604 geeignete
Routinen zum Bewirken einer Umwandlung und Formatierung von sowohl eingehenden
als auch ausgehenden Daten.
-
Das
Kartenobjekt-Administrationsmodul 606 stellt vorzugsweise
eine geeignete Datenbasis-Software bereit, um innerhalb der Objekt-Datenbasis 106 gespeicherte
Daten zu editieren, aktualisieren, löschen, synchronisieren und
deren Nichtmißbrauch sicherzustellen.
Eine Vielzahl von Datenbasis-Einheiten sind für diese Aufgabe geeignet, beispielsweise
enthalten sie unterschiedliche konventionelle Datenbasis-Verwaltungssysteme
der vierten Generation (4GL RDBMS).
-
Die
Prüfdatei 608 verfolgt
geeigneterweise Änderungen
auf die Objekt-Datenbasis 116, wodurch sie unterstützt, die
Integrität
von Kartendaten, welche innerhalb des CODUS 106 gespeichert
sind, sicherzustellen. Genauer gesagt, wenn Änderungen auf die Objekt-Datenbasis 116 stattfinden,
und zwar resultierend aus Präferenzen-Aktualisierungen,
Transaktionen, Änderungen
in der Applikationsstruktur und dergleichen, verfolgt die Prüfdatei 608 geeigneterweise eine
Information bezüglich
dieser Änderungen,
beispielsweise Zeit, Datum und Beschaffenheit, und den Inhalt der Änderung.
-
Die
Kartenobjekt-Datenbasis 116, welche eine einzige Datenbasis
oder einen Satz an verteilten Datenbasen enthalten kann, wird verwendet,
um den bekannten Zustand der unterschiedlichen Smartcards 120 zu
speichern. Im allgemeinen ist der Zustand einer Smartcard durch
einen geeigneten Satz an Karten-Freistempel gekennzeichnet. Bei
einer bevorzugten Ausführungsform,
bei welcher eine Datenstruktur gemäß ISO-7816 verwendet wird,
speichert die Kartenobjekt-Datenbasis 116 eine Information bezüglich der
einzelnen Anwendungen, welche auf den unterschiedlichen Smartcards 120 vorliegen (dass
heißt,
die gesamte Dateistruktur), als auch die einzelnen Felder, Verzeichnisse
und Daten, welche diese Anwendungen enthalten. Eine Dateistruktur
für eine
Kartenobjekt-Datenbasis 116 wird derart gewählt, dass
sie einen geeigneten Satz an Datenfeldern für eine vorliegende Smartcard 120 enthält.
-
Gesellschaftsdaten-Synchronisationsschnittstelle
-
Bei
einer bevorzugten Ausführungsform
verfolgen die unterschiedlichen EDSIs 108 Änderungen bei
Smartcard-Daten und/oder Applikationen bezüglich einzelner Gesellschaften.
Mit Bezug auf 1 und 3 enthält die EDSI 108 einen
Kommunikationsserver 302, eine Sicherheitsmaschine 304 und
eine Konsumenten-Datenbasis 306.
-
Der
Kommunikationsserver 302 unterstützt geeigneterweise eine Kommunikation
mit Gesellschafts-Netzwerken 114 und einem Aktualisierungs-Logiksystem 110.
Bezüglich
dessen ist der Server 302 so aufgebaut, dass er zwischen
unterschiedlichen Formaten, Medien und Kommunikationsprotokollen übersetzt,
und zwar wie notwendig, wenn die bestimmte Wahl von verwendeten
Komponenten gegeben ist.
-
Die
Sicherheitsmaschine 304 stellt geeignete Sicherheitsmessungen
mit Bezug auf den Zugriff und die Speicherung von Information mit
der Konsumenten-Datenbasis 306 bereit. Die Sicherheitsmaschine 304 kann
unterschiedliche Authentifikation, Datenverschlüsselung und digitale Signaturtechniken
in Verbindung mit eingehenden und ausgehenden Meldungspaketen verwenden.
Geeignete Algorithmen im Rahmen der vorliegen den Erfindung enthalten
beispielsweise eine DES-Verschlüsselung, eine
RSA-Authentifizierung und eine Vielzahl von weiteren symmetrischen
und unsymmetrischen kryptographischen Techniken.
-
Die
Konsumenten-Datenbasis 306 stellt geeigneterweise ein Mittel
zum Speichern einer Smartcard-Information bereit, welche sich auf
einzelne Partner oder Gesellschaften bezieht. Dass heißt, dass
eine bestimmte Gesellschaft (Hosting, beispielsweise Gesellschafts-Netzwerk 114(a))
Smartcard-Information bezüglich
nur auf diese Gesellschaft erstellen kann oder andere zur Erstellung
einsetzt. Beispielsweise kann eine Hotelkette eine Loyalität, Präferenz und
weitere Daten, welche sich speziell auf diese Hotelkette beziehen,
speichern, während
einer Synchronisation (wie im folgenden ferner detailliert beschrieben)
würde jegliche Änderungen auf
die Datenbasis 306 über
das System und umgekehrt verbreitet werden, Änderungen andernorts im System
würden
an die Datenbasis 306 kommuniziert werden. Diese Kommunikation
wird vorzugsweise in Verbindung mit dem Kommunikationsserver 302 sicher
durchgeführt
(unter Verwendung der Sicherheitsmaschine 304).
-
Bei
einer alternativen Ausführungsform
würde die
durch die EDSIs 108 bereitgestellte Funktionalität in die
entsprechende EDCU 112 eingeordnet. Dass heißt, während eine
nicht dargestellte Ausführungsform
eine oder mehrere physikalisch separate EDSIs 108 verwendet,
kann es vorteilhaft sein, ferner die DSS zu rationalisieren, indem
diese Funktionalität
in den entsprechenden EDCU 112 Funktionsblock einbezogen
wird.
-
Aktualisierungs-Logiksystem
-
Bei
einer bevorzugten Ausführungsform
formatiert das Aktualisierungs-Logiksystem 110 Kartendaten,
welche von den EDCUs 112 und EDSIs 108 empfangen
werden, und an diese übertragen
werden, und leitet diese sicher weiter. Bezugnehmend nun auf 4 enthält bei einer bevorzugten Ausführungsform
das Aktualisierungs-Logiksystem 110 eine Logikmaschine 402,
ein Datenverwaltungsmodul 404, eine Sicherheitsmaschine 406,
einen Gesellschafts-Aktualisierungs-Administrator 408 und
ein Gesellschafts-Aktualisierungs-Prüfmodul 410.
-
Die
Logikmaschine 402 wirkt geeigneterweise zum Leiten und
Verteilen von Informationsänderungen über das
System. Somit ist die Logikma schine 402 in der Lage zu
bestimmen, welches Modul (dass heißt, welche EDCUs 112 und
EDSIs 108) es benötigen
die Änderung
widerzuspiegeln.
-
Das
Datenverwaltungsmodul 404 wirkt geeigneterweise als eine
Datenschnittstelle zwischen EDSIs 108 und EDCUs 112.
Genauer gesagt ist das Modul 404 in der Lage zwischen einem
in diesen Systemen verwendeten Datenformat umzuwandeln und zu übersetzen.
Demgemäß enthält das Datenverwaltungsmodul 404 geeignete
Routinen zum Bewirken von einer Umwandlung und Formatierung von sowohl
eingehenden als auch ausgehenden Daten.
-
Die
Sicherheitsmaschine 406 wird verwendet, um geeignete Sicherheitsmessungen
mit Bezug auf Daten bereitzustellen, welche durch das Aktualisierungs-Logiksystem 110 fließen. Die
Sicherheitsmaschine 406 kann unterschiedliche Authentifizierungs-,
Datenverschlüsselungs-
und digitale Signaturtechniken in Verbindung mit eingehenden und ausgehenden
Meldungspaketen verwenden. Geeignete Algorithmen im Rahmen der vorliegenden
Erfindung enthalten beispielsweise eine DES-Verschlüsselung, RSA-Authentifizierung
und eine Vielzahl weiterer symmetrischer und unsymmetrischer kryptographischer
Techniken.
-
Ein
Gesellschafts-Aktualisierungs-Administrator 408 enthält geeigneterweise
eine Overhead-Software, welche notwendig ist, um einen Datentransfer
zwischen EDSIs 108 und EDCUs 112 aufrecht zu erhalten.
-
Das
Gesellschafts-Aktualisierungs-Prüfmodul 410 verfolgt
geeigneterweise eine Aktualisierungsinformation, welche durch das
Aktualisierungs-Logiksystem 110 fließt. Genauer gesagt, wenn eine
Information über
das Aktualisierungs-Logiksystem 110 kommuniziert wird (als
Ergebnis von Präferenzen-Aktualisierungen,
Transaktionen, Applikationsstrukturänderungen und dergleichen),
verfolgt das Prüfmodul 410 geeignete
Freistempel dieser Information, beispielsweise Zeit, Datum und Beschaffenheit
und Inhalt der Kommunikation.
-
Gesellschaftsdaten-Sammeleinheit
-
Die
EDCUs 112 speichern und koordinieren vorzugsweise den Transfer
von Synchronisationsdaten entsprechend einer bestimmten Gesellschaft.
Mit Bezug auf 5 enthält in einer
bevorzugten Ausführungsform
die Gesellschaftsdaten-Sammeleinheit 112 eine Sicherheitsmaschine 508,
eine Konsumenten-Aktualisierungs-Transaktionsdatenbasis 504, eine
Konsumenten-Loyalität-Transaktionsdatenbasis 510,
eine konsumentenanhängige Transaktionsdatenbasis 514,
eine Aktualisierungs-Datenbasis 502, eine EDCU Prüfdatei 506,
eine EDCU Administrationsdatei 512 und ein EDCU Datenverwaltungsmodul 516.
-
Die
Sicherheitsmaschine 508 wird verwendet, um geeignete Sicherheitsmessungen
mit Bezug auf Daten bereitzustellen, welche durch die EDCU 112 fließen. In
Richtung zu diesem Ende hin, kann die Sicherheitsmaschine 406 unterschiedliche
Authentifizierungs-, Datenverschlüsselungs- und digitale Signaturtechniken
in Verbindung mit eingehenden und ausgehenden Meldungspaketen verwenden. Geeignete
Algorithmen im Rahmen der vorliegenden Erfindung enthalten beispielsweise
eine DES-Verschlüsselung,
RSA-Authentifizierung und eine Vielzahl weiterer symmetrischer und
unsymmetrischer herkömmlicher
kryptographischer Techniken.
-
Eine
Konsumenten-Aktualisierungs-Transaktionsdatenbasis 504 wird
verwendet, um Information zu speichern, welche auf einer Smartcard 120 aktualisiert
wurde, welche jedoch noch nicht an die unterschiedlichen Datenbasen
und Netzwerke verbreitet wurde, welche eine Aktualisierung benötigen. Beispielsweise
kann eine Smartcard 120 verwendet werden, um Karteninhaber-Präferenzen
im Rahmen einer Transaktion mit einer bestimmten Gesellschaft zu ändern. Diese
Information würde
kurz gesagt in der Datenbasis 504 (für die bestimmte Gesellschaft) gespeichert
werden, bis sie an CODUS 106 und die geeigneten EDCUs 112 und
EDSIs 108 ausgefächert werden
könnte.
Dieser Typ von Transaktion wird unten weiter detailliert beschrieben.
-
Die
Konsumenten-Loyalität-Transaktionsdatenbasis 510 wird
geeigneterweise verwendet, um eine Loyalitätsinformation (beispielsweise
Vielflieger, häufiger
Gast, usw.) in Verbindung mit einer bestimmten Gesellschaft oder
einem Partner zu speichern. Bei einer alternativen Ausführungsform
wird eine Loyalitäts-Transaktionsdatenbasis 510 nicht verwendet – statt
dessen ist die Funktionalität
der Datenbasis 510 in Datenbasen 502, 510 und 514 enthalten,
so dass eine Loyalitätstransaktion
gerade eine weitere Transaktionsmodalität wird, welche durch die EDCU 112 zu
verfolgen ist.
-
Die
konsumentenanhängige
Transaktionsdatenbasis 514 wird geeigneterweise verwendet,
um eine Information bezüglich
von Transaktionen zu speichern, welche ohne direkte Verwendung der Smartcard 120 stattfanden.
Genauer gesagt, können einige
Transaktionen, wie beispielsweise Änderungen in einer Präferenz und
dergleichen, durch einen Karteninhaber über einen Kanal eingeleitet
werden, welcher nicht die Verwendung der Karte einbezieht, beispielsweise über eine
verbale Anfrage über
ein Standardtelefon. In einem solchen Fall, und wie unten weiter
detailliert beschrieben, werden diese Daten geeigneterweise in der
anhängigen
Transaktionsdatenbasis 514 gespeichert. Die Transaktionsdaten verbleiben
in der Datenbasis 514, bis die entsprechende Smartcard 120 in
Verbindung mit einem Zugriffspunkt 102 verwendet wird,
woraufhin die Smartcard 120 selber (als auch das CODUS 106)
mit dieser neuen Information aktualisiert wird.
-
Die
Aktualisierungs-Datenbasis 502 wird geeigneterweise verwendet,
um weitere Typen an Transaktionen, dass heißt Transaktionen, welche nicht
wie Aktualisierung, Loyalität
oder Anhängigkeit klassifizierbar
sind, zu speichern. Beispielsweise kann die Aktualisierungs-Datenbasis 502 verwendet werden,
um Dateistruktur-Aktualisierungen zu speichern, wie im folgenden
detailliert beschrieben.
-
Die
Prüfdatei 506 wird
verwendet, um Änderungen
zum Aktualisieren der Datenbasis 504, anhängigen Datenbasis 514,
Datenbasis 502, und in einer dargestellten Ausführungsform,
Loyalitäts-Datenbasis 510,
zu verfolgen. Bei einer alternativen Ausführungsform, bei welcher keine
separate Loyalitäts-Datenbasis 510 verwendet
wird, verfolgt die Prüfdatei 506 Änderungen
bei Datenbasen 504, 514 und 502. Die
Prüfdatei 506 hilft
dabei die Integrität von
Daten in den jeweiligen Dateien sicherzustellen.
-
Die
Administrationsdatei 512 stellt eine geeignete Datenbasis-Software bereit,
welche notwendig ist, um Daten zu editieren, aktualisieren, löschen, synchronisieren
und deren Nichtmißbrauch
sicherzustellen, wobei sie innerhalb der unterschiedlichen Datenbasen
gespeichert sind, welche die EDCU 112 enthalten, dass heißt, Datenbasen 502, 504, 510 und 514.
-
Das
Datenverwaltungsmodul 516 stellt Datenverwaltungs-Fähigkeiten
bereit, um einen Datentransfer zwischen Smartcards 120 und
Datenbasen 504, 514, 502 und 510,
als auch zwischen diesen Datenbasen und den weiteren Systemen – dass heißt, dem
Aktualisierungs-Logiksystem 110 und CODUS 106,
zu erleichtern. Somit wirkt das Datenverwaltungsmodul 516 als
Schnittstelle, um einen nahtlosen Transfer von Daten zwischen den
unterschiedlichen Systemen sicherzustellen.
-
Netzwerk
-
Die
unterschiedlichen Komponenten, Datenbasen, Module und Vorrichtungen,
welche oben in Verbindung mit der bevorzugten Ausführungsform beschrieben
sind, werden über
ein geeignetes Datenkommunikationsnetzwerk verbunden. Ein solches Netzwerk
kann unterschiedliche physikalische Verbindungen enthalten, welche
eine Vielzahl an herkömmlichen
Datenprotokollen verwenden, beispielsweise das TCP/IP Protokoll.
Es wird deutlich sein, dass sich die einzelnen Verbindungen zwischen Komponenten
des vorliegenden Systems unterscheiden können. Beispielsweise kann ein
drahtlos PCS Netzwerk von einem Zugriffspunkt 102 verwendet werden,
um einen Support-Client-Server 104 zu sichern, während eine
Internet TCP/IP-Verbindung von dem CODUS 106 zu den unterschiedlichen
EDCUs 112 verwendet werden kann.
-
Der
Fachmann wird anerkennen, dass eine Vielzahl an Hardwaresystemen
zum Implementieren der vorliegenden Erfindung geeignet ist. Unterschiedliche
Modems, Router, CPU's,
Monitore, Backup-Systeme, Energieversorgungen und Peripheriegeräte können verwendet
werden, um die Vorzüge des
vorliegenden Systems zu realisieren. Bei einer Ausführungsform
wird beispielsweise ein Compaq Prolinea Computer, welcher in einer
OS/2 Umgebung betrieben wird, welche IBM MQ Server Software verwendet,
verwendet, um den Sicherheitssupport-Clientserver 104 zu
implementieren, wobei die unterschiedlichen Zugriffspunkte unabhängige Smartcard-Kioske
enthalten, eine EDCU 112 und ein CODUS 116 werden
dann auf einem Compaq Prolinea Computer implementiert, welcher in
einer Windows/NT Umgebung betrieben wird, auf welcher ein geeignetes
Datenbasis-Softwarepaket läuft.
-
Personalisierungssystem
-
Bezugnehmend
nun auf 9 enthält ein Personalisierungssystem 140 bei
einer bevorzugten Ausführungsform
geeigneterweise ein Karten-Verwaltungssystem 902,
ein Vermächtnis-Verwaltungssystem 904,
ein Erfassungs-Applikationsmodul 906, eine oder mehrere
Datenbasen 910, einen Aktivierungsblock 908, ein
gemeinsames Kartenpersonalisierungs-Dienstprogramm 912 (CCP), ein
Servicebüro 914,
einen gemeinsamen Karten-Sicherheitsserver 916, ein Schlüsselverwaltungssystem 918,
und ein oder mehrere Schlüsselsysteme 920.
Ein Schlüsselverwaltungssystem 918 enthält geeigneterweise ein
Datenbasismodul 922, ein CID Ersatzmodul 924, ein
Schlüsselsystem 926 und
ein Schlüsselsystem 928.
-
Das
CCP 912 kommuniziert geeigneterweise mit CODUS 106 (in 1 gezeigt), und das Vermächtnis-Verwaltungssystem 904 kommuniziert
geeigneterweise mit der Konto-Wartung 142, welche ebenfalls
so konfiguriert ist, dass sie mit CODUS 106 kommuniziert.
-
Das
Karten-Verwaltungssystem 902 empfängt geeigneterweise die Karten-Anforderung 901 und
leitet die Erfassung von Information von unterschiedlichen Quellen
ein. Im allgemeinen enthält
die Karten-Anforderung 901 unterschiedliche
Anforderungsinformation, welche dazu dient, eine gewünschte Gruppe
an Karteneigenschaften zu spezifizieren. Solche Eigenschaften können beispielsweise
enthalten: eine Liste an gewünschten
Anwendungen (Fluggesellschaft, Hotel, Mietfahrzeug, usw.); eine
Angabe, ob die Karten neu, eine erneuerte oder ein Ersatz ist; eine
Liste an vorgegebenen Präferenzen
des Karteninhabers, entsprechend der gewünschten Applikationen; eine
persönliche
Information bezüglich
des Karteninhabers (Name, Adresse, usw.) und benötigte Sicherheitslevel.
-
Das
Karten-Verwaltungssystem 902 analysiert geeigneterweise
die Karten-Anforderung und sendet, für Information, welche bereits
durch den Herausgeber gespeichert wurde, eine Anforderung an das
Vermächtnis-Karten-Verwaltungssystem 904. Für eine Information,
welche als Vermächtnisdaten nicht
erhältlich
ist, leitet das Karten-Verwaltungssystem 902 die
relevanten Komponenten der Karten-Anforderung 901 weiter, um
das Applikationsmodul 906 zu erfassen. Bei einer beispielhaften
Ausführungsform
wählt das
Karten-Verwaltungssystem 902 die optimalen
physikalischen Eigenschaften der Smartcard für eine bestimmte Karten-Anforderung 901 aus. Dass
heißt,
dass das Karten-Verwaltungssystem 902 geeigneterweise den
geeigneten Smartcard-Chiptyp bestimmt, welcher zu verwenden ist,
und zwar basierend auf einer Anzahl an Faktoren, beispielsweise Speicheranforderungen
und Berechnungskomplexität
der gewünschten
Sicherheitsfunktionen. Genauso kann das optimale Smartcard-Betriebssystem (SCOS)
gewählt
werden. Bei einer alternativen Ausführungsform werden der Smartcard-Chip,
das Betriebssystem und dergleichen in einer Karten-Anforderung 901 spezifiziert.
-
Das
Vermächtnis-Verwaltungssystem 904 wirkt
als ein geeigneter Aufbewahrungsort von Information bezüglich einer
vergangenen Beziehung des Karteninhabers – wenn jegliche besteht – mit der
Kartenausgabeorganisation. Beispielsweise kann ein Karteninhaber
einen langdauernden Kredit oder ein Lastschriftkonto mit der Ausgabeorganisation
haben (basierend auf einer standardisierten geprägten Magnetstreifenkarte),
und diese Information kann vorteilhafterweise in die ausgegebene
Karte einbezogen werden.
-
Ein
Erfassungs-Applikationsmodul 906 wird geeigneterweise konfiguriert,
um Information vom Karten-Verwaltungssystem 902 und Vermächtnis-Verwaltungssystem 904 zu
empfangen, und dann mit den unterschiedlichen Datenbasen 910 eine Schnittstelle
zu bilden, um eine gesamte verbleibende Applikationsinformation
zu erfassen, welche in der Karten-Anforderung 901 spezifiziert
ist. Vorzugsweise entsprechen Datenbasen 910 den einzelnen
Partner-Gesellschaften, und stehen mit diesen in Verbindung, welche
Smartcard-Anwendungen zur Verwendung in der Smartcard 120 anbieten
(beispielsweise Gesellschafts-Netzwerke 114 in 1). Somit würde beispielsweise
eine Karten-Anforderung 901, welche eine Anforderung für eine Hotel-Anwendung
enthielt, die Erfassungs-Anwendung 906 anstoßen, um
eine Datenkommunikation mit der geeigneten Hotel-Datenbasis 910 einzuleiten.
Die Hotel-Datenbasis 910 würde dann eine Information zurückführen, welche die
korrekte Dateistruktur, Zugriffsbedingungen (Sicherheit), Vorgabewerte
und weitere Daten rückführt, welche
notwendig sind, um die Smartcard 120 mit der angeforderten
Anwendung zu konfigurieren. Eine Kommunikation mit den unterschiedlichen
Datenbasen 910 kann über
jegliches geeignetes Mittel stattfinden, beispielsweise eine Datenkommunikation über das
Internet, PSTN und dergleichen, oder über weitere Kanäle, wie
beispielsweise einfache Telefonanforderungen.
-
Ein
Aktivierungsblock 908 wird geeigneterweise verwendet, um
ein Mittel für
den Karteninhaber bereitzustellen, um die Karte zu aktivieren, sobald
sie herausgegeben wurde. Beispielsweise ist es für Kreditkarten und dergleichen üblich, dass
sie unaktiviert an den Karteninhaber gesendet werden, welches erfordert,
dass der Karteninhaber ein automatisiertes System beim Herausgeber
anruft (oder anderweitig kontaktiert), um die Karte zu aktivieren.
Dies wird typischerweise über
eine Eingabe der Kartennummer und einer weiteren geeigneten ID unter
Ver wendung eines Tonwahl-Telefons erfüllt. In Anbetracht dessen wird
ein Aktivierungsblock 908 verwendet, um diese Funktion
für die
angeforderte Smartcard zu erleichtern, dass heißt, um zu spezifizieren ob
eine solche Aktivierung für
eine bestimmte Karte notwendig ist.
-
Die
CCP 912 wird verwendet, um ein korrekt formatiertes Karten – "Objekt" zu erzeugen – d. h., das
Betriebssystem, die Dateistruktur und alle weiteren erhältlichen
Kartendaten, welche an Karte 120 herunterzuladen sind – überträgt dann
diese Information an das Service-Büro 914 (zum Erzeugen
der Smartcard) und CODUS 106 (zum Aufzeichnen des wie ausgegebenen
Kartenzustands). Die CCP 912 wird vorzugsweise so konfiguriert,
um das Format des Kartenobjekts an das spezifische, zu verwendende
Karten-Ausgabesystem (unten beschrieben) zuzuschneiden. Somit kann
das Erfassungs-Anwendungssystem 906 eine Funktionalitätsanforderung mit
relativ hohem Level zuführen,
und die CCP kann das spezifische, bei der Implementierung zu verwendende "Objekt" erzeugen.
-
Das
Personalisierungs-Service-Büro 914 enthält geeignete
Hardware- und Softwarekomponenten,
um eine Erzeugung der Smartcards zur Ausgabe an die jeweiligen Karteninhaber
zu vollenden. In Anbetracht dessen enthält das Service-Büro 914 einen
geeigneten Smartcard-"Drucker", um den Informationstransfer
an den Smartcard-Chip handzuhaben, als auch jegliche herkömmliche
Prägung
oder einen Magnetstreifen-Schreiber, wenn notwendig. Geeignete Smartcard-Drucker
enthalten beispielsweise irgendeine aus den Serien 9000 und Serien 150i
Smartcard-Ausgabesysteme,
welche von Datacard Corporation of Minnetonka, MN hergestellt werden.
-
Ein
allgemeiner Karten-Sicherheitsserver 916 (CCSS) enthält geeigneterweise
Software- und Hardwarekomponenten, welche notwendig sind, um eine
kryptographische Schlüsselinformation
von unterschiedlichen Gesellschafts-Schlüsselsystemen 920 wieder
zu erlangen. Bei einer beispielhaften Ausführungsform wird auf diese Information
durch ein Service-Büro 914 zugegriffen,
um den Personalisierungsprozess zu vollenden. Genauer gesagt wird
es typischerweise der Fall sein, dass eine Smartcard 120 eine
Anzahl unterschiedlicher Anwendungen enthält, welche mit einem weiten
Bereich an Gesellschafts-Organisationen in Verbindung stehen. Der Fachmann
wird anerkennen, dass das Schreiben, Aktualisieren und Lesen dieser
Dateien vorzugsweise auf bestimmte Parteien beschränkt ist,
und zwar gemäß eines
Satzes an Zugriffsbedin gungsregeln. Diese Zugriffsbedingungen werden
geeigneterweise unter Verwendung kryptographischer Schlüssel implementiert,
welche den geeigneten Parteien bekannt sind. Somit wird das Service-Büro 914 – dessen
Aufgabe es ist, die Kartendateistruktur zu erzeugen und zu bestücken – nicht
ab initio Zugriff auf die Schlüssel haben,
welche zum Durchführen
dieser Funktion notwendig sind. Wie oben kurz erwähnt, streben
bekannte Systeme an, dieses Problem durch Ansammeln von Schlüsseldaten
in einem zentralen Aufbewahrungsort, welcher beim Ausgabeprozess
verwendet wird, zu lösen,
wodurch ein nicht akzeptierbares Sicherheitsrisiko erzeugt wird.
Verfahren gemäß der vorliegenden
Erfindung erlauben hingegen eine Kommunikation zwischen der Smartcard
und den einzelnen Schlüsselsystemen 920,
wenn die Karte ausgegeben wird, wodurch ermöglicht wird, dass eine Schlüsselinformation
sicher zur Smartcard heruntergeladen wird, und zwar ohne das Eingreifen
einer dritten Partei. Das CCSS 916 wird geeigneterweise
verwendet, um diesen Prozess zu erleichtern, indem Information von
der CCP 912 bezüglich
der Identität
der unterschiedlichen Applikationen empfangen wird, welche in den
unterschiedlichen Karten zu erzeugen sind, dann wird, wenn durch
das Service-Büro 914 abgefragt
(oder alternativ vor Ausgabe durch das Service-Büro 914), das geeignete
Schlüsselsystem 920 kontaktiert,
um einen Schlüssel
anzufordern, welcher an das Service-Büro 914 während der
Personalisierung zu übertragen
ist.
-
Schlüsselsysteme 920 enthalten
geeignete Datenbasis-Systeme, welche in der Lage sind, kryptographische
Schlüssel,
welche mit einer bestimmten Gesellschaft in Verbindung stehen, zu
speichern, erzeugen und sicher zu übertragen. Das Schlüsselverwaltungssystem 918 ist
in diesem Rahmen ein System, welches mit Schlüsselsystemen 920 vergleichbar
ist, welches aber von der Partei "besessen" wird, welche das Personalisierungssystem
implementiert. Die Schlüsselerzeugungsfunktion
kann zwischen CCSS und Schlüsselsystemen 920 verteilt
werden. Das heißt,
dass die Schlüssel
in Echtzeit am CCSS 916 (gemäß Algorithmen und einer Schlüsselinformation,
welche von den bestimmten Gesellschaften empfangen werden), erzeugt
werden, anstelle dass sie bei Schlüsselsystemen 920 erzeugt
werden.
-
Es
wird dem Fachmann klar sein, dass die in 9 dargestellten Funktionsblöcke unter
Verwendung einer Vielzahl an Hardware- und Softwarekomponenten implementiert
werden können,
und zwar beide serienmä ßig produziert
und/oder maßgeschneidert
entwickelt. Datenbasisintensive Funktionen, welche beispielsweise
durch das Karten-Verwaltungssystem 902 durchgeführt werden,
können unter
Verwendung eines geeigneten Datenbasis-Pakets implementiert werden,
beispielsweise Codebase, dBASE oder dergleichen.
-
Personalisierungsprozess
-
Ein
Personalisierungssystem, wie oben in Verbindung mit 9 beschrieben, wird geeigneterweise verwendet,
um effizient eine hohe Anzahl an Smartcards mit einem breiten Bereich
an Funktionalitätslevel
auszugeben. Diese Aufgabe enthält
ein Erlangen und Koordinieren in zeitgerechter Weise von genauen
Daten für
einzelne Karteninhaber über
die unterschiedlichen Partner-Gesellschaften hinweg, welche durch
das System unterstützt
werden. Angesichts dessen kann es vorkommen, dass bestimmte Partner-Gesellschaften
es wünschen
die Verbreitung proprietärer
Daten zu beschränken.
Diese Daten können
beispielsweise private Schlüssel
enthalten, welche in Verbindung mit Smartcard-Zugriffsbedingungen, als auch einer
Dateistruktur und persönlichen
Daten von Karteninhabern, verwendet werden.
-
Bezugnehmend
nun auf 9 und 10 wird nun ein beispielhafter
Smartcard-Personalisierungsprozess beschrieben. Zunächst empfängt das
System in Schritt 1002 eine Smartcard-Anforderung. Wie oben
erwähnt
wird das Karten-Verwaltungssystem 902 geeigneterweise verwendet,
um die Karten-Anforderung zu empfangen, und initiiert das Erfassen von
Information von unterschiedlichen Quellen. Die Karten-Anforderung 901 enthält geeigneterweise eine
Anforderungsinformation, welche dazu dient eine gewünschte Gruppe
an Karten-Eigenschaften zu spezifizieren. Solche Eigenschaften können beispielsweise
enthalten: eine Liste an gewünschten Anwendungen
(Luftfahrtgesellschaft, Hotel, Mietfahrzeug, usw.); eine Angabe
ob die Karte neu ist, eine erneuerte ist oder eine ersetzte Karte
ist; eine Liste an vorgegebenen Präferenzen des Karteninhabers, entsprechend
der gewünschten
Anwendungen; eine persönliche
Information bezüglich
des Karteninhabers (Name, Adresse, usw.); und erforderliche Sicherheitslevel.
-
Als
nächstes
wählt das
System in Schritt 1004 den Smartcard-Typ und die Konfiguration
aus, welche für
die vorliegende Karten-Anforderung 901 geeignet
sind. Dieser Schritt wird geeigneterweise durch das Karten-Verwaltungssystem 902 durchgeführt. Somit
untersucht das Karten-Verwaltungssystem 902 eine Anzahl
an Faktoren hinsichtlich von einer bei der Karten-Anforderung 901 empfangenen
Information (beispielsweise Speicheranforderungen, gewünschte Sicherheitsfunktionen
und dergleichen), und wählt
dann einen geeigneten Smartcard-Chip aus einer Sammlung an erhältlichen
Chips aus. Auf dieselbe Weise kann das optimale Smartcard-Betriebssystem
(SCOS) ebenfalls ausgewählt
werden.
-
In
Schritt 1006 wird die Karteninhaber-Information erlangt.
Dieser Schritt wird geeigneterweise durch das Erfassungs-Applikationsmodul 906 durchgeführt, welches
in Verbindung mit Datenbasen 910 und dem Vermächtnis-Verwaltungssystem 904 arbeitet.
Genauer gesagt, wird die spezifische Information des Karteninhabers
vorzugsweise in zwei Gruppen klassifiziert: eine dem Personalisierungssystem
bekannte Information und eine dem Personalisierungssystem unbekannte
Information. Eine bekannte Information enthält im allgemeinen Daten, welche
durch eine vergangene Beziehung mit der Organisation erlangt wurde,
welche das Personalisierungssystem betreibt. In einem solchen Fall
sind bestimmte Daten, wie zum Beispiel der Name des Karteninhabers,
bevorzugte Rechnungsadresse, Titel, Firma, usw, höchstwahrscheinlich
bereits bekannt, sowie das auch bei bestimmten Applikationsdaten
der Fall sein wird. Eine solche Information wird geeigneterweise
in einer oder mehreren Datenbasen, welche das Vermächtnis-Verwaltungssystem 904 enthalten,
gespeichert, und kann daraus abgefragt werden. Als Teil von Schritt 1006 bestimmt
das System (im speziellen Modul 908) vorzugsweise, ob die
Karte eine Aktivierung erfordern sollte. Dass heißt, wie
oben kurz erwähnt,
dass es üblich
ist auf einer Karte einen Sticker oder dergleichen anzulegen, welcher
den Karteninhaber darauf hinweist, dass eine Aktivierung der Karte
vor der Verwendung benötigt
wird. Eine Aktivierung enthält
typischerweise die Verwendung eines automatisierten Telefonsystems.
Die Wahl, ob eine bestimmte Karte eine Aktivierung benötigt, kann
auf einer Anzahl von Faktoren basieren, beispielsweise demographische
Faktoren, Kriminalitätsraten
oder Postbetrugs-Statistiken,
welche mit der Postleitzahl des Karteninhabers in Verbindung stehen.
-
Für Daten,
welche im Vermächtnis-Verwaltungssystem 904 nicht
enthalten sind, kommuniziert das Erfassungs-Applikationsmodul 906 geeigneterweise
mit Datenbasen 910, um die Information abzufragen, welche
benötigt
wird um die Karten-Anforderung 901 zu erfüllen. Diese
Information wird typischerweise eine Dateistruktur-Information enthalten, beispielsweise
die DF und EF Hierarchie, Datentypen und -längen und Zugriffsbedingungs-Spezifikationen
für die
bestimmte Applikation, welche durch das Unternehmen gesponsort wird.
Beispielsweise in dem Fall, bei welchem die Karten-Anforderung 901 eine
Anforderung für
eine Luftfahrtgesellschaft-Anwendung enthält, würde das Erfassungs-Applikationsmodul 906 die
der Gesellschaft entsprechende Datenbasis kontaktieren, welche die
Luftfahrtgesellschaft-Anwendung betreibt, und dann die gesamte notwendige
Dateistruktur-Information herunterladen. Dieser Prozess würde wiederum
für jede
neue oder modifizierte Anwendung fortgesetzt, welche in die Smartcard
einzubeziehen ist.
-
In
Schritt 1008 wird ein vollständiger Karteninhaber-Datensatz
erzeugt, und zwar geeigneterweise unter Verwendung der CCP 912.
Der Kartensatz oder das "Karten-Objekt" wird letztendlich
durch das Service-Büro 914 verwendet,
um die physikalische Smartcard zu erzeugen. Die Form des Karten-Objekts
kann variieren. Bei einer Ausführungsform
enthält
das Karten-Objekt ein als Binary Large Object ("BLOB")
bezeichnetes Objekt. Das Karten-Objekt wird vorzugsweise auf die
ausgewählte
Smartcard-Konfiguration (beispielsweise Chiptyp und Betriebssystem,
wie in Schritt 1004 spezifiziert), den Inhalt der Karteninhaber-Informationsdaten
(erfasst in Schritt 1006) und den beabsichtigten Smartcard-"Drucker" (d. h. die Vorrichtung,
welche verwendet wird, um die abgeschlossene Karte innerhalb des Service-Büros 914 zu
erzeugen), zurechtgeschnitten. Dies ermöglicht es dem System, um in
den nachfolgenden Schritten Dateistrukturen, Datentypen und dergleichen
zu spezifizieren, ohne sich selber damit zu beschäftigen,
wie diese Struktur auf die Smartcard verschlüsselt werden wird oder wie
auf die Daten zugegriffen werden wird. Hoch bis Schritt 1008 braucht das
System nur ein Modell mit relativ hohem Level der beabsichtigten
Smartcard-Datenstruktur
zu entwickeln; die Besonderheiten sind mit Ausnahme der CCP 912 für alle unsichtbar.
-
Bei
einer alternativen Ausführungsform
können
unterschiedliche Details des Smartcard-Datenobjekts an einem vorherigen
Punkt im System bestimmt werden. Dass heißt, dass die Funktionalität der CCP 912 unter
unterschiedlichen Komponenten des Systems hinweg verteilt werden
kann.
-
Sobald
der Karteninhaber-Datensatz oder das Karten-Objekt in Schritt 1008 erzeugt
ist, werden diese Daten dann an CODUS 106 gesendet (Schritt 1010).
Dies stellt sicher, dass das DSS (insbesondere CODUS 106)
eine Aufzeichnung des Smartcard-Zustands zum Zeitpunkt der Personalisierung hat.
Diese Information ist dann dem Karten-Verwaltungssystem 142 unmittelbar
zugänglich.
-
Das
Karten-Objekt wird dann an das Service-Büro 914 und (wenn erforderlich)
an das CCSS 916 (Schritt 1012) gesendet. In Schritt 1014 werden die
notwendigen Schlüssel
erlangt, um es dem Service-Büro 914 zu
ermöglichen,
die abgeschlossene Smartcard zu erzeugen. Wie oben erwähnt, wird Schritt 1014 geeigneterweise
durch CCSS 916 durchgeführt,
und zwar gleichzeitig oder seriell mit dem Ausgabeprozess. Bei einer
Ausführungsform fragt
das Service-Büro 914 das
CCS 916 nach den geeigneten kryptographischen Schlüsseln ab,
sobald jede einzelne Karte unter Verwendung eines Ausgabesystems,
welches sich geeigneterweise am Service-Büro 914 befindet, erzeugt
ist. Diese Schlüssel wurden
entweder früher
von den Schlüsselsystemen 920 und 918 (d.
h. nach Schritt 1012) abgefragt oder wurden in Echtzeit
in Ansprechen auf die Anforderung vom Service-Büro 914 abgefragt.
Alternativ können
die Schlüssel
durch das CCSS 916 abgefragt werden und an das CCP 912 übertragen
werden, und zwar vor Übertragung
des Karten-Objekts an das Service-Büro 914. In beiden
Fällen
wird der Schlüssel
oder werden die Schlüssel
dann zur Einbeziehung in das in Schritt 1008 erzeugte Karten-Objekt abgefragt.
-
In
Schritt 1016 wird die tatsächliche Karte ausgegeben. Das
Service-Büro 914 lädt geeigneterweise
das Karten-Objekt in die korrekte Smartcard-Hardware herunter, und
zwar unter Verwendung der korrekten kryptographischen Schlüssel. Die
initialisierte Smartcard kann dann gebündelt und gemäß den herkömmlichen
Verfahren an den geeigneten Karteninhaber verteilt werden.
-
Synchronisationsprozess
-
Ein
dynamisches Synchronisationssystem, wie oben in unterschiedlichen
Ausführungsformen beschrieben,
wird verwendet, um den "Zustand" der Smartcard des
Konsumenten zu verfolgen. Der Zustand der Smartcard wird geeigneterweise
durch die Struktur von Anwendungen charakterisiert, welche in der
Smartcard verwendet werden, und die unterschied lichen Datenstücke werden
dann innerhalb dieser Anwendungen gespeichert.
-
Die
Art und Weise, auf welche Applikationen und Daten innerhalb einer
Smartcard verwaltet werden, kann variieren. Beispielsweise können Datendateien
und Verzeichnisse in einer "Baum"-Struktur in der
Smartcard 120 gespeichert werden. Dass heißt, dass
die Smartcard-Dateistruktur
geeigneterweise der bekannten MS-DOS (Microsoft Disk Operating System)
Dateistruktur gleicht, bei welcher Dateien innerhalb einer Hierarchie
an Verzeichnissen logisch organisiert werden. Im speziellen werden
drei Typen an Dateien in der ISO 7816-4 bestimmt: zugehörige Dateien
(DF), Elementardateien (EF) und eine Master-Datei (MF). Die Master-Datei
ist analog zum MS-DOS "Stamm"-Verzeichnis und
enthält
alle weiteren Dateien und Verzeichnisse. Zugehörige Dateien sind tatsächlich Verzeichnisse
oder "Ordner" zum Halten weiterer
DFs oder EFs. Somit kann die MF eine beliebige Anzahl an DFs enthalten,
und diese DFs können
weitere DFs enthalten oder nicht enthalten. Elementare Dateien werden
verwendet um Benutzerdaten zu speichern und können innerhalb einer zugehörigen Datei
oder innerhalb der Master-Datei vorliegen. DFs mit höherem Level
(d. h. DFs, welche bestimmte Anwendungen unterbringen), werden oft als
anwenderzugehörige
Dateien (ADFs) bezeichnet. Der Umfang der vorliegenden Erfindung
ist jedoch nicht auf diesen Typ von Multifunktionskarte beschränkt. Weitere
Implementierungen, beispielsweise Multos oder Java-basierende Karten
sind ebenfalls innerhalb des Rahmens der vorliegenden Erfindung
geeignet.
-
Eine
Anzahl an Synchronisationsausgaben kann im Rahmen der Multifunktions-Smartcard
aufkommen, tatsächlich
treten drei Paradigma-Fälle
mit einer gewissen Häufigkeit
wieder auf und beziehen sich auf: 1) aktualisierte Transaktionen,
2) anhängige Transaktionen
und 3) Änderungen
der Dateistruktur. Jeder dieser Fälle wird nun wiederum mit Bezug
auf die vorliegende Erfindung beschrieben.
-
Beispiel 1: Aktualisierungs-Transaktionen
-
Es
ist für
einen Karteninhaber recht gewöhnlich,
eine lokale Änderung
der Smartcard 120 durchzuführen, welche nicht unmittelbar
in allen Datenbasen widergespiegelt wird, welche vorteilhafterweise Gebrauch
von dieser Information machen können. Beispielsweise
angenommen, dass bei einer Initialisierung (d. h., wenn die Karte
ursprünglich über ein Personalisierungssystem 140 ausgegeben
wurde) die Smartcard 120 des Karteninhabers so konfiguriert
war, dass sie eine allgemeine Präferenz
zum Rauchen widerspiegelt (beispielsweise enthält eine Datei ein Boolsches
Feld, welches auf Raucher/Nichtraucher verschlüsselt ist), der Karteninhaber
jedoch nun wünscht
diese allgemeine Präferenz-Datei zu ändern, um
eine Nichtraucherpräferenz
widerzuspiegeln.
-
In
diesem fall, bezugnehmend nun auf 1, 7 mit Bezug auf eine bevorzugte
Ausführungsform
der vorliegenden Erfindung, führt
der Karteninhaber geeigneterweise die Karte 120 in einem
herkömmlich
lokalisierten Zugriffspunkt 102 ein, worauf eine Authentifizierung
der Karte und/oder des Karten-Lesers stattfindet (Schritt 802).
Bei einer bevorzugten Ausführungsform
findet die Authentifizierung gemäß relevanter
Sektionen des ISO 7816 Standards statt.
-
Als
nächstes
verwendet der Karteninhaber eine geeignete Benutzerschnittstelle
(welche durch den Zugriffspunkt 102 zugeführt wird,
welcher in Verbindung mit Server 104 arbeitet), um eine
Transaktion durchzuführen – d. h.,
um eine Änderung
der Präferenz-Datei
anzufordern (Schritt 804). Diese Änderung würde typischerweise unmittelbar
bei der Smartcard 120 widergespiegelt werden. Dass heißt, dass
der Zugriffspunkt 102 und/oder Server 104 die Funktionalität enthalten
würde,
welche notwendig ist, um auf die geeigneten Dateien innerhalb der
Smartcard 120 zuzugreifen und sie zu aktualisieren.
-
Der
Kommunikations-Router 206 in Server 104 leitet
dann die Transaktion an die geeignete Partei, d. h. an einen EDSI 108 oder
einen EDCU 112, und zwar jeweils entsprechend von Zweigen 807 und 812,
weiter. Dass heißt,
dass in Abhängigkeit
von der Systemkonfiguration, die zu ändernde Datei mit einer bestimmten
Gesellschaft in Verbindung gebracht werden kann oder alternativ
mit der Organisation in Verbindung gebracht werden kann, welche
das DSS betreibt. Diese zwei Fälle
werden wiederum beschrieben.
-
Zweig 807 in 8 folgend werden die Änderungsdaten
an die geeignete EDSI 108 gesendet und darin gespeichert
(Schritt 808). Das Aktualisierungs-Logiksystem 110 überträgt dann
diese Änderungsanfrage
an die geeignete EDCU 112 – d. h. die EDCU 112,
welche der bestimmten EDSI entspricht (Schritt 810). Diese
Information wird geeigneterweise in der entsprechenden Aktualisierungs-Datenbasis 504 gespeichert.
Diese Information wird ebenfalls an weitere EDSIs verteilt. Bei
dem augen blicklichen Beispiel würde
das Aktualisierungs-Logiksystem 110 jene Systeme identifizieren,
welche von der Kenntnis des Raucherzustands des Karteninhabers einen
Vorteil ziehen würden.
Solche Systeme können
beispielsweise unterschiedliche Hotels, Mietfahrzeug-Agenturen und
dergleichen enthalten.
-
Wenn
alternativ Zweig 805 in 8 gefolgt wird,
können
die Daten zuerst bei der geeigneten EDCU gespeichert werden (Schritt 812)
und dann an weitere EDCUs 112 und EDSIs 108 verteilt
werden, wie oben beschrieben.
-
Die Änderung
der Kartendaten wird dann an CODUS 106 übertragen. Genauer gesagt werden
die unterschiedlichen Felder und Dateien, welche mit der Smartcard 120 in
Verbindung stehen, aktualisiert, um die in der Aktualisierungs-Datenbasis 504 gespeicherte Änderung
widerzuspiegeln. Somit entspricht die Information innerhalb des
CODUS 106 der Information, welche innerhalb der Smartcard 120 und
den unterschiedlichen EDCUs 112 und EDSIs 108 enthalten
ist. Nach dieser Übertragung
werden die entsprechenden Änderungsdaten
in der Aktualisierungs-Datenbasis 504 gelöscht (Schritt 818).
-
Beispiel 2: Anhängige Transaktion
-
Der
Karteninhaber kann eine Änderung
vornehmen oder eine Transaktion durchführen, und zwar über einen
Kanal, welcher nicht direkt die Smartcard 120 einbezieht,
wodurch eine Ungereimtheit zwischen den Daten in der Smartcard 120 und den
Daten in unterschiedlichen Datenbasen über das DSS hinweg erzeugt
wird. Ein solcher Fall kann beispielsweise auftreten, wenn der Karteninhaber
ein Hotel anruft, um eine Reservierung vorzunehmen (anstelle dass
die Transaktion unter Verwendung der Smartcard 120 online
durchgeführt
wird), und mündlich
anfordert, seine Präferenzen
von Raucher auf Nichtraucher zu ändern.
-
Bezugnehmend
nun auf 1 und 7 kontaktiert der Karteninhaber
zunächst
in diesem Fall, mit Bezug auf eine bevorzugte Ausführungsform
der vorliegenden Erfindung, eine Gesellschaft über ein Mittel, welches die
Smartcard 120 nicht enthält – d. h., eine Transaktion,
bei welcher "die
Smartcard nicht vorliegt" (Schritt 702).
Unter Verwendung einer geeigneten Schnittstelle (mündlich,
Tastatur, usw.) wird eine Änderung
oder Transaktion ausgewählt
(Schritt 704). Diese Änderung
wird dann lokal innerhalb eines bestimmten Gesellschafts-Netzwerks 114 gespeichert
und/oder innerhalb eines EDSI 108 gespeichert (Schritt 706).
-
Als
nächstes
leitet das Aktualisierungs-Logiksystem 110 in Schritt 708 diese
Information an die entsprechende EDCU 112, wo sie in der
anhängigen Datenbasis 514 verbleibt.
An diesem Punkt ist sich die Smartcard 120 selber der Änderung
nicht bewußt. Daraus
folgend würde,
wenn der Karteninhaber eine Transaktion mit der Smartcard einleitet,
die entsprechende Gesellschaft wahrscheinlich zunächst bei
der Datenstruktur in der Smartcard 120 nach Präferenzen
nachsehen, und, wie bereits angegeben, würde höchstwahrscheinlich zur falschen
Entscheidung gelangen (beispielsweise könnte ein Raucher-Zimmer zugewiesen
werden, ungeachtet der ausdrücklichen Präferenz des
Karteninhabers).
-
Um
dieser Situation Abhilfe zu schaffen, stellt die vorliegende Erfindung
in Schritten 710, 720 ein Verfahren bereit, bei
welchem die Smartcard bei ihrer nächsten Verwendung aktualisiert
wird. Dass heißt, nachdem
die Smartcard bei einem Zugriffspunkt 102 eingesetzt wird,
und geeigneterweise authentifiziert wird (Schritt 710),
fragt das System die anhängige Datenbasis 514 an,
zu bestimmen, ob irgendwelche Änderungen
vorgenommen wurden. Wenn dies der Fall ist, wird die geeignete Information
an die Smartcard 120 heruntergeladen (Schritt 712).
-
Nachdem
die obige Informationsübertragung zufriedenstellend
vollendet ist, werden die Änderungsdaten
an CODUS 106 übertragen,
wo sie innerhalb der Kartenobjekt-Datenbasis 116 gespeichert werden.
Schließlich
wird die jeweilige Information innerhalb der anhängigen Datenbasis 514 gelöscht (Schritt 716).
-
Beispiel 3: Dateistruktur/Anwendungsänderung
-
Zusätzlich zu
den oben detailliert angegebenen Modifikationen bezüglich der
Daten können Änderungen
der Struktur von in der Smartcard 120 gespeicherten Daten
ebenfalls im bestimmten Rahmen wünschenswert
sein. Dass heißt,
dass es während der
Lebensdauer von einer Smartcard wahrscheinlich sein kann, dass der
Karten-Ausgeber, eine Partner-Gesellschaft
oder der Karteninhaber selber es wünschen kann, die Funktionalität der Karte
zu erweitern, indem er die Folge an Anwendungen erweitert, welche
innerhalb der Karte untergebracht ist. Beispielsweise kann ein Karteninhaber,
welcher eine Smartcard für
ein Mietfahrzeug und für
Fluggesellschaft-Reservierungen verwendet, es ebenfalls wün schen,
die Karte zu verwenden, um Hotelreservierungen zu erlangen und diese
zu bezahlen. In einem solchen Fall kann der geeignete Hotel-Partner die Anforderung
des Karteninhabers verarbeiten und zusätzlich für eine Hotel-Anwendung arrangieren,
welche der Smartcard-Dateistruktur
hinzugefügt
wird. Bei einem weiteren Beispiel kann der Smartcard-Ausgeber selber
den Zusatz einer neuen Anwendung autorisieren, und zwar beispielsweise
eine Kredit- und/oder Lastschrift-Anwendung. Im Gegensatz dazu kann es ebenfalls
in einigen Fällen
geeignet sein, Anwendungen von der Karte zu entfernen.
-
Bei
einer bevorzugten Ausführungsform
können
die Typen an Dateistruktur-Änderungen,
wie oben beschrieben, auf eine Weise analog dem in 7 dargelegten Verlauf gehandhabt werden,
und zwar in einem gewissen Ausmaß davon abhängig, welche Partei die Dateistruktur-Änderung erzeugt. Dass heißt, dass,
wie in Schritt 712 die geeignete Information der Dateistruktur-Änderung
in der EDCU 112 gespeichert werden kann (beispielsweise
in Datenbasis 502), und dann an die Smartcard 120 übertragen
werden kann, wenn die Karte in Verbindung mit einer Online-Transaktion
verwendet wird (Schritte 710 und 712). Nachdem
die Dateistruktur auf der Smartcard 120 erweitert ist oder
anderweitig modifiziert ist, wird CODUS 106 (im speziellen
Datenbasis 116) ähnlich
modifiziert, um die Änderung
widerzuspiegeln. Die Änderungsinformation
wird dann aus der Datenbasis 502 gelöscht (Schritt 716).
-
Obwohl
die Erfindung hier in Verbindung mit den anhängigen Zeichnungen beschrieben
wurde, wird der Fachmann anerkennen, dass der Umfang der Erfindung
nicht darauf beschränkt
ist. Modifikationen in der Auswahl, dem Entwurf und der Anordnung
der unterschiedlichen Komponenten und Schritte, wie hier diskutiert,
können
gemacht werden, ohne vom Umfang der Erfindung abzuweichen, wie in den
anhängigen
Ansprüchen
angegeben.