-
HINTERGRUND DER ERFINDUNG
-
Gebiet der Erfindung
-
Die
vorliegende Erfindung betrifft generell das Gebiet der Website-Konto-
und -E-Commerce-Verwaltung und insbesondere ein Verfahren, System
und computerlesbares Medium zur Verwaltung mehrerer Website-Konten
und zur Bereitstellung einer sicheren Methodologie bzw. Methode
für E-Commerce-Transaktionen
von einer Zentralwebsite-Stelle.
-
Diskussion des Hintergrunds
-
In
den letzten Jahren sind zahlreiche Internet- oder World Wide Web-Anwendungen
bzw. -Sites („WWW"- oder „Web"-Sites, beispielsweise Alta Vista, Yahoo!,
autobytel.dom, msn Hotmail, iwon, headhunter.net, Travelocity.com,
deja.com., Amazon.com. usw.) kreiert worden, die Benutzer auffordern,
persönliche
Konten bei ihnen zu einzurichten. Die persönlichen Konten umfassen typischerweise
einen Einlogg- bzw.
Anmeldenamen (login name) und ein Passwort und sind typischerweise
mit freiwilliger demographischer Information, Kredit/Debit-Karteninformation
und anderer Information verknüpft,
die, während
der Benutzer rechnergebunden bzw. online ist, durch Web-basierte
Formulare eingegeben werden kann.
-
Jedoch
aufgrund der zahlreichen persönlichen
Online-Konten und
-Passwörter,
die ein einzelner Benutzer typischerweise erzeugt, um auf die bevorzugten
Websites des Benutzers zuzugreifen, ist es für den Benutzer oft schwierig,
die zahlreichen Konten und Passwörter
auf Spur zu halten bzw. zu verfolgen und zu verwalten. Demgemäss umfassen typische Schwierigkeiten
und/oder Ausgaben, die solche Websites begleiten, beispielsweise:
(i) ein Benutzer muss bei jeder neuen Webanwendung bzw. Website,
bei welcher der Benutzer registriert werden will, die gleiche persönliche Information
neu eingeben, (ii) ein Benutzer muss, um durch die Überleitungseinrichtungen
bzw. Gateways der meisten Websites und Online-E-Mail-Konten zu kommen,
die gleichen wiederkehrenden Benutzernahmen und Passwörter neu
tippen, und (iii) ein Benutzer ist Reklamesystemen ausgesetzt, welche
den Onlinebestimmungen bzw. -zielen des Benutzers nachspüren, um
beim Benutzer gezielt Reklame abzusetzen.
-
Außerdem ermöglichen
viele der Websites den Online-Kauf von Produkten und/oder Diensten über eine
Kredit/Debit-Karte. Die Fähigkeit,
solche Produkte und/oder Dienste online zu kaufen, basiert auf existierender
Kredit/Debit-Karteninformation,
die in einem Online-Konto eines Benutzers gespeichert ist, oder
basiert auf Kredit/Debit-Karteninformation, die
eingegeben wird, während
er online ist. Jedoch umfassen typische Krankheiten und Nachteile,
die mit solchen Websites verbunden sind, die finanzielle Sicherheit
einer Kredit/Debit-Karteninformation eines Benutzers, während er
bei solchen Websites online ist, und die geheim zu haltenden Ausgaben
in Bezug auf den Online-Diebstahl
solcher vertraulicher Information und andere betrügerische
Akte. Das weit verbreitete Ausmaß solcher Befürchtungen
wird durch eine von Newsweek.MSNBC.com durch 5 P. M. EST, 25. Februar
2000 durchgeführte
Online-Untersuchung exemplifiziert, die fragte, welche Cyber-verbrecherische
Aktivitäten
Benutzer am meisten fürchten.
Die Resultate der Untersuchung umfassen einen Nasty-Computervirus
(nasty computer virus) (26%), einen Businessmeddler (business meddler)
(6%), einen E-Mail Spy (e-mail spy) (9%), einen Fremden, der sich
Kindern in einem Chatroom (chat room (virtueller Unterhaltungsraum))
nähert
(11%) und ein Stehlen von Kreditkartennummern durch Hacker (48%).
-
WO
99/01424 lehrt ein Kreditkartensystem, das einen begrenzten Gebrauch
von Kreditkartennummern und/oder Karten aufweist. Diese Nummern/Karten
können
nur für
eine einzelne Transaktion benutzt werden und werden bei einer einzelnen Benutzung
deaktiviert.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Demgemäss ist eine
Aufgabe der Erfindung, ein automatisiertes Verfahren zur Online-Verwaltung von
Kredit/Guthaben- bzw. Kredit/Debit-Karten-Transaktionen von einer
Zentralwebanwendungs- bzw. Zentralwebsite-Stelle bei gleichzeitiger Minimierung
der finanziellen Bloßstellung
eines Benutzers der Kredit/Debit-Karte bereitzustellen.
-
Diese
Aufgabe wird durch die wie in Anspruch 1 definierte Erfindung gelöst.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN
-
Ein
vollständigeres
Verständnis
der Erfindung und vieler der damit verbundenen Vorteile werden ohne
weiteres erhalten, da dieselbe besser verstanden wird durch Bezugnahme
auf die folgende detaillierte Beschreibung, wenn diese zusammen
mit den beigefügten
Zeichnungen betrachtet wird, in denen:
-
1 ein
Systemdiagramm zur Darstellung der Verwaltung und Sammlung von Formulardaten (Formdaten)
ist, die von mehreren Websites durch eine Zentralwebsite-Stelle
empfangen werden;
-
2 ein
Systemdiagramm zur Darstellung eines automatisierten Protokollierens
bzw. Einloggens bzw. Anmeldens von Benutzerinformation für mehrere
Websites von einer Zentralwebsite-Stelle aus ist;
-
3 ein
Systemdiagramm zur Darstellung einer automatisierten Registrierung
von Benutzerinformation bei mehreren Websites von einer Zentralwebsite-Stelle
aus ist;
-
4 ein
generelles Systemdiagramm zur Darstellung der Verwaltung von E-Commerce-Transaktionen
von einer Zentralwebsite-Stelle aus mit minimierter Online-Kredit/Debit-Kartenkonto-Aktivierungszeit
gemäß der vorliegenden
Erfindung ist;
-
5 ein
detailliertes Systemdiagramm zur Darstellung der Verwaltung von
E-Commerce-Transaktionen von einer Zentralwebsite-Stelle aus mit
minimierter Online-Kredit/Debit-Kartenkonto-Aktivierungszeit
gemäß der vorliegenden
Erfindung ist;
-
6 ein
detailliertes Systemdiagramm zur Darstellung der Verwaltung von
E-Commerce-Transaktionen in einem Kreditkartennetzwerk von einer Zentralwebsite-Stelle
aus mit minimierter Online-Kredit/Debit-Kartenkonto-Aktivierungszeit
gemäß einer anderen
Ausführungsform
der vorliegenden Erfindung ist;
-
7 ein
detailliertes Systemdiagramm zur Darstellung der Verwaltung von
E-Commerce-Transaktionen von einer Zentralwebsite-Stelle aus mit
minimierter finanzieller Bloßstellung
eines Online-Kredit/Debit-Kartenkontos;
-
8 ein
detailliertes Systemdiagramm zur Darstellung der Verwaltung von
Offline-Kredit/Debit-Kartentransaktionen mit minimierter finanzieller Bloßstellung
eines Kredit/Debit-Kartenkontos
ist;
-
9 ein
detailliertes Systemdiagramm zur Darstellung der Verwaltung von
Offline-Kredit/Debit-Kartentransaktionen mit minimierter finanzieller Bloßstellung
eines Kreditkartenkontos ist;
-
10 eine
generelles Systemdiagramm zur Darstellung eines untergeordneten
Kredit/Debit-Kartensystems ist;
-
11 ein
Blockdiagramm zur Darstellung eines zentralen Kontrollers des Systems
der 10 ist;
-
12 ein
Blockdiagramm zur Darstellung einer Benutzerschnittstelle des Systems
der 10 ist;
-
13 ein
Blockdiagramm zur Darstellung einer Ausgabebankschnittstelle des
Systems der 10 ist;
-
14 ein
Blockdiagramm zur Darstellung einer Akquirierungsbankschnittstelle
des Systems der 10 ist;
-
15 ein Flussdiagramm zur Darstellung des Betriebs
des zentralen Kontrollers der 10 ist;
-
16 ein Flussdiagramm zur Darstellung des Betriebs
der Ausgabebankschnittstelle der 10 ist;
-
17 ein Signaldiagramm zur Darstellung eines beim
System der 10 benutzten Signalformats ist;
-
18 ein Datenstrukturdiagramm zur Darstellung eines
beim System der 10 benutzten Datenstrukturformats
ist;
-
19 ein Flussdiagramm zur Darstellung der Verarbeitung
einer Online-Transaktion beim System der 10 ist;
-
20 ein Flussdiagramm zur Darstellung der Verarbeitung
einer Offline-Transaktion beim System der 10 ist;
-
21 bis 25 Flussdiagramme
sind, die verschiedene von einer Ausgabebank der 10 benutzte
Verschlüsselungstechniken
darstellen;
-
25 ein Systemblockdiagramm obersten Niveaus zur
Implementierung der Systeme und Prozesse der 1 bis 3 ist,
-
26 ein Systemblockdiagramm obersten Niveaus zur
Implementierung der Systeme und Prozesse der 4 bis 24 ist;
-
27 eine Darstellung ist, die einen Mehrzweck-
bzw. Universalcomputer darstellt, der entsprechend den Lehren der
vorliegenden Erfindung programmiert werden kann.
-
BESCHREIBUNG DER BEVORZUGTEN
AUSFÜHRUNGSFORMEN
-
Bezugnehmend
nun auf die Zeichnungen, in denen in den mehreren Darstellungen
durchgängig gleiche
Bezugszeichen identische oder korrespondierende Teile bezeichnen,
und insbesondere auf deren 1 bis 27,
sind dort verschiedene Ausführungsformen
der vorliegenden Erfindung dargestellt. Am Ende dieses Abschnitts
ist ein GLOSSAR bereitgestellt, das spezialisierte Ausdrücke und
ihre Definitionen im Kontext der vorliegenden Erfindung auflistet.
-
Zentrale Benutzerkontoverwaltung
-
Die
zentrale Benutzerkontoverwaltung ist über eine Zentralwebsite-Stelle
implementiert, worin ein Benutzer zuerst ein Mitglied der zentralen
Website durch beispielsweise (1) Ausfüllen eines Mitgliedschafts-
oder Registrierungsformulars und (2) Auswählen eines Benutzernamens und
Passworts für
die Zentralwebsite-Stelle wird. Die zentrale Webanwendung bzw. Website
schlägt
zur Verfügung
stehende Benutzernahmen vor, sollte sich erweisen, dass ein angeforderter
Benutzername schon genommen ist. Die en Schritte können bei
der Zentralwebsite-Stelle, wie es die Fachleute der relevanten Technik(en)
erkennen, über
eine Webbrowser-Schnittstelle oder über Telefon, Faksimile bzw.
Fax, E-Mail (e-Mail) usw. ausgeführt
werden. Das Registrierungsformular (Registrierungsform) enthält die Felder
für Formulare (Formen)
allgemeiner und zweckmäßiger Anwendungen
bzw. Sites auf dem Internet wie beispielsweise Alta Vista, Yahoo!,
autobytel.com, msn Hotmail, iwon, headhunter.net, Trevelocity.com,
deja.com, Amazon.com usw. Diese(s) Registrierungsform(ular) wird
vorteilhafter Weise eine „(Bildschirm-)Vorlage (template)" des Benutzers, wenn
der Benutzer sich mit anderen Websites verbinden will.
-
Die
von einem Benutzer bereitgestellte Registrierungsinformation wird
bei der Zentralwebsite-Stelle gehostet (= vom Hauptrechner verarbeitet), so
dass die zentrale Website auf die Daten des Benutzers zugreifen
und die Daten zur Herstellung von Verknüpfungen mit bzw. Verweisen
bzw. Links zu vom Benutzer bevorzugten Websites benutzen kann. Die
Links bei der Zentralwebsite-Stelle werden dann für den Benutzer
von jeder Einrichtung wie beispielsweise einem Computer, einem Cellulartelefon,
einem PDA (= personal data assistant (persönlicher Datenassistent)) usw.,
die eine Internetverbindung hat bzw. haben, zugreifbar. Die zentrale
Website benutzt dann die Information des Benutzers, um den Benutzer
bei den vom Benutzer bevorzugten Websites automatisch zu registrieren,
wobei sie dem Benutzer die Verzögerung
und den Nachteil wiederholten Tippens und Ausfüllens mehrfacher Formulare
für jede
bevorzugte Website ersparen. Der Benutzername und das Passwort,
die bei der Zentralwebsite-Stelle vorhanden sind, sind typischerweise
die letzten und nur die, an die sich der Benutzer immer erinnern muss,
um in Zukunft auf die bevorzugten Websites des Benutzers zuzugreifen.
Außerdem
kann ein Benutzer der zentralen Website zusätzliche Sites anfordern, die
zur Zentralwebsite-Stelle zu jeder Zeit hinzuzufügen sind.
-
Einmal
registriert, wird einem Benutzer von der zentralen Website eine
persönliche
Webseite bereitgestellt, und der Benutzer kann sich bei der persönlichen
Webseite des Benutzers einloggen bzw. anmelden, um beispielsweise
die Webseite zu personifizieren oder neue Websites hinzuzufügen. Bei
einer Ausführungsform
kann der Benutzer auf der persönlichen
Webseite des Benutzers eine oder mehrere Websites auswählen, die
der Benutzer verbinden bzw. zusammenbringen will, und dann einen
Button (Knopf) klicken, damit die zentrale Website den Benutzer
bei den ausgewählten
Websites registriert. Bei einer anderen Ausführungsform kann der Benutzer auf
einen in der persönlichen
Webseite des Benutzers vorgesehenen Link zu einer Website des Benutzers
klicken, die der Benutzer verbinden will, und die zentrale Website
registriert den Benutzer bei der jeweiligen Website.
-
Die
zentrale Website überträgt die Daten vom
Registrierungsformular des Benutzers zu den Websites, die der Benutzer
auswählt,
und erzeugt dynamisch Links zu den Websites in der persönlichen Webseite
des Benutzers. Die zentrale Website sendet dem Benutzer automatisch
Anmeldeinformation zu den ausgewählten
Websites und verbindet den Benutzer automatisch mit bei den ausgewählten Websites
gehaltenem Inhalt. Auf diese Weise kann der Benutzer direkt zu einer „Startseite" der ausgewählten Website
des Benutzers gehen ohne dass er irgendeine Anmeldeinformation eingeben
muss. Außerdem
erlaubt die zentrale Website auch einem Benutzer, Links für Sites
zu erzeugen, bei denen der Benutzer schon registriert ist. Dies
wird dadurch ausgeführt,
dass dem Benutzer erlaubt wird, existierende Benutzerinformation
für die
registrierten Websites bei der Zentralwebsite-Stelle einzugeben
und zu speichern, beispielsweise mittels eines Online-Formulars,
das Felder zum Speichern der existierenden Benutzerinformation aufweist, über E-Mail, über Faksimile bzw.
Fax, über
Telefon, über
drahtlose Kommunikation bzw. Funkkommunikation usw. Für jede vertrauliche
Benutzerinformation wie beispielsweise Benutzernamen, Passwörter, Kredit/Debit-Kartenkontonummern,
demographische Information usw., die bei der Zentralwebsite-Stelle
gespeichert ist, wird Verschlüsselung
benutzt. Die Arbeitsweise wird nun unter Bezugnahme auf die 1 bis 3 beschrieben.
-
1 ist
ein Systemdiagramm zur Darstellung eines Registrierungsformular-Verwaltungssystems
zur Verwaltung und Sammlung von Registrierungsformulardaten für jede von
mehreren Websites. Die gesammelten Formulardaten können dann
zur automatischen Registrierung eines Benutzers bei jeder von mehreren
Websites, für
welche die Formulardaten erhalten worden sind, benutzt werden, was später beschrieben
wird. Das System kann auf sich auf Standardcomputer-Hardware, wie
sie in der oder den Computertechniken bekannt ist, befinden und darauf
arbeiten. Die Hardware lässt
Software (beispielsweise Webserver-Software usw.) laufen, die das
System benutzt. Das System ist mit einer Web-Schnittstelle (beispielsweise
Web-Client 102) ausgebildet
und wird von dieser kontrolliert. Der oder die Server, die das Formularverwaltungssystem
nach 1 laufen lassen, haben Zugriff auf das Internet, wenn
das System Netzwerkcodes benutzt und mit Websites kommuniziert,
um die jeweiligen Formulare der Websites syntaktisch zu analysieren.
Da auch der Server Internetzugriff hat und als ein Web-Server läuft, müssen Benutzer
des Formularverwaltungssystems nicht bei der zentralen Website sein,
um das System zu benutzen/verwalten. Typischerweise sind sichere
bzw. geschützte
Anmeldungen, (die beispielsweise eine starke 128-Bit-Verschlüsselung usw.
benutzen) erforderlich, um ungeachtet des Ortes des Benutzers (d.
h. entweder eines Intranets oder des Internets) auf das System zuzugreifen. Wenn
sich der Benutzer des Formularverwaltungssystems einmal beim Web-Client 102 anmeldet, reicht
der Benutzer über
ein HTML-Vorderende (HTML front end) 104 eine URL-Adresse 106 bei
einem FMS 108 (FMS = Form Manager Servlet (Formular-Verwalter-Servlet))
ein. Das FMS 108 analysiert die mit der URL-Adresse 106 korrespondierende
angeforderte Webseite und erzeugt ein Sessionsobjekt (Sitzungsobjekt),
das Formulardaten 110 enthält, und bestimmt bei 126,
ob mehrfache Formulare des Sessionsobjekts 110 vorhanden
sind oder nicht. Wenn bei 128 bestimmt wird, dass mehr
als ein Formular auf der angeforderten Seite vorhanden sind, präsentiert
das FMS 108 dem Benutzer einen Formularselektor 132,
beispielsweise eine Webseite, welche die verfügbaren Formulare zeigt/auflistet,
und ermöglicht
dem Benutzer, sich die Formulare anzuschauen. Der Benutzer (oder
die zentrale Website) entscheidet dann, welches der Formulare in
einem Katalogformular 112, das beispielsweise als eine Webseite
implementiert ist, zu katalogisieren ist, und kann zurückgehen
und über
den Formularselektor 132 ebenso andere Formulare bearbeiten.
Wenn bestimmt wird, dass nur ein Formular aus dem Sessionsobjekt 110 vorhanden
ist, wird das Formular im Katalogformular 112 katalogisiert.
-
Nachdem
das oder die Formulare katalogisiert worden sind, wird dem Benutzer
eine aktualisierte Version des Katalogformulars 112 präsentiert,
das eine detaillierte Aufschlüsselung
und Analyse aller Formularobjekte des oder der Katalogformulare
enthält.
Im Katalogformular 112 ist beispielsweise neben jedem aufgelisteten
Formularobjekt ein Auswahlmenü bzw.
Drop-down-Menü vorhanden.
Der Benutzer benutzt dieses Drop-down-Menü, um jeweilige Formularfelder
von der mit der URL-Adresse 106 korrespondierenden Webseite
mit den Registrierungs-„Vorlage"-Feldern der zentralen
Website zu verbinden (das heißt
gemeinsame Feldtypen werden persönlichen
Informationsfeldern, die von der zentralen Website benutzt werden,
zugeordnet).
-
Beispielsweise
benutzen nicht alle Websites den Ausdruck „Benutzername (username)" für den Namen
ihrer Anmeldeidentifikation (beispielsweise benutzt Yahoo.com „yahooid", und einige Websites nennen
den Benutzernamen einen „ID-Namen (ID-name)" oder „Anmeldenamen
(login-name)" oder „Anmelde-ID
(login ID)" usw.).
Die Zuordnungen der zentralen Website kompensieren Unterschiede
bei Feldnamen über
verschiedenen Websites durch Verbinden gemeinsamer Feldtypen. Beispielsweise
werden alle Sites mit unterschiedlichen Feldnamen für einen
gemeinsamen Feldtyp wie beispielsweise „Anmelden (login)" dem gleichen „Vorlagen"-Formularfeldnamen
(beispielsweise „Benutzername") der zentralen Website
zugeordnet. Nachdem, wenn anwendbar, allen Feldern eine zentrale
Website-Zuordnung gegeben worden ist, übermittelt der Benutzer diese Zuordnungen über das
Katalogformular 112 einem FMS 118, welches das
gleiche FMS wie das FMS 108 sein kann. Da das Katalogformular 112,
bei dem die Zuordnungen hergestellt sind, ebenso ein HTLM-Formular
ist, werden diese Zuordnungsdaten 114 dem FMS 118 übermittelt
und wird zum FMS 118 automatisch ein Sessionsobjekt 116 weitergegeben. Das
FMS 118 nimmt für
jedes Formularobjekt die Zuordnungsdaten 114 und die Daten
vom Sessionsobjekt 116 (das heißt Formular-Kennzeichen/Felder) und erzeugt SQL-Anweisungs/Formular-Daten 120 (SQL
= Strucured Query Language (strukturierte Abfragesprache)), welche
die Formularobjektdaten und ihre Zuordnung enthalten. Diese Anweisungs/Formular-Daten 120 werden
zur Datenbank 122 gesendet und darin als Formulardaten 122b gespeichert.
Dem Benutzer wird dann über
den Web-Client 102 eine Bestätigungsseite 124 gegeben,
um dem Benutzer anzuzeigen, dass die Katalogisierung erfolgreich war.
Die Datenbank 122 speichert außerdem Benutzerkontodaten 122a,
Benutzerdaten 122c und Website-Linkdaten 122d,
wie sie später
beschrieben werden.
-
2 ist
ein Systemdiagramm zur Darstellung des automatischen Einloggens
bzw. Anmeldens von Benutzerinformation bei von mehreren Websites benutzten
Formularen von einer Zentralwebsite-Stelle aus. Nachdem die Formulardaten
wie oben unter Bezugnahme auf die 1 beschrieben
erfasst, katalogisiert und verwaltet worden sind, werden, wie es unter
Bezugnahme auf die 2 beschrieben wird, Benutzer
automatisch bei einer gewählten
Ziel-Site angemeldet.
-
Wenn
bei 2 sich der Benutzer der zentralen Website bei
einer der verwiesenen Websites des Benutzers anmelden will, tut
dies der Benutzer durch Eingabe des Passworts und Benutzernamens 204 des
Benutzers über
eine Anmeldeseite 202 des Web-Client 102. Dann
wird eine personifizierte Startseite 206 erzeugt, welche
die bevorzugten Website-Links des Benutzers enthält. Die Startseite 206 wird
von Verweis- bzw. Linkdaten 210 erzeugt, die mit in der
Datenbank 122 gespeicherten Daten 122d korrespondieren
und über
eine Benutzeridentifikation 208 dem Benutzer zugeordnet
sind. Die Benutzeridentifikation 208 wird vom Passwort
und Benutzernamen 204 des Benutzers abgeleitet.
-
Von
der Startseite aus kann sich der Benutzer bei jeder der Websites
anmelden, die mit den Linkdaten 210 korrespondieren und
auf der Startseite des Benutzers aufgelistet sind. Websites werden
mittels eines separaten Prozesses (das heißt über ein Benutzerregistrierungsservlet
(user registration servlet (URS)) 306, wie es in Bezug
auf die 3 beschrieben wird) einer Startseite
des Benutzers hinzugefügt
und von dieser entfernt. Wenn einmal ein Benutzer entscheidet, bei
welcher Ziel- bzw. Bestimmungswebsite sich der Benutzer anmelden
will, klickt der Benutzer auf der Basis von Linkdaten 210,
die als der Name der Bestimmungswebsite auf der Startseite 206 des
Benutzers dargestellt sind, auf einen Verweis bzw. Link. Dann werden
die ID-Nummer und die Website-Wahl 216 des Benutzers über das
Linkservlet 218 und die Daten 212 benutzt, um
Benutzerdaten und Formulardaten 214 von der Datenbank 122 wiederzugewinnen.
Die Benutzerdaten und Formulardaten 214 korrespondieren
mit den Daten 122a, 122b und 122c, die
in der Datenbank 122 gespeichert und der ID-Nummer des Benutzers
zugeordnet sind.
-
Das
Servlet 218 erzeugt dann auf der Basis der Benutzerdaten
und Formulardaten 214 dynamisch ein vollständiges Anmeldeformular 220 und „füllt es" durch Mischen der
Kontodaten 122a des Benutzers (das heißt Benutzername und Passwort
für die
Bestimmungswebsite) in das Formular 220 „aus". Wenn beispielsweise
die Anmeldeseite der Web-Ziel-Site ein Textfeld für den Benutzernamen und
das Passwort des Benutzers aufweist, werden diese Felder mit den
von der Abfrage wiedergewonnen Benutzernamen- und Passwortdaten
des Benutzers bestückt.
Wie oben beschrieben, werden, wenn das Formularverwaltungssystem
der 1 Formulare katalogisiert, Formularobjekte (beispielsweise Textfelder,
Passwortfelder usw.) mit korrespondierenden Felddaten aus der Vorlage
zugeordneten Feldnamen der zentralen Website katalogisiert. Benutzerdaten
wie beispielsweise eine Telefonnummer einer Person werden ebenfalls
mit korrespondierenden zentralen Website-Felddaten aus der Vorlage
katalogisiert.
-
Bei
dem obigen Beispiel „füllt" das Servlet 218 das
Formular 220 durch einfaches Einsetzen der erforderlichen
Benutzerdaten (beispielsweise als „Benutzername" zugeordnet) in das
korrespondierende Formularkennzeichen (beispielsweise ebenfalls
als „Benutzername" zugeordnet) „aus", wenn das Servlet 218 das
Formular 220 aus-„schreibt". Wenn dieses virtuelle
Formular 220 einmal vervollständigt ist, übermittelt das Servlet 218 das
Formular 220 der Bestimmungswebsite 218 als ein
Anmeldeskript 222, geradeso, als wenn jemand das Formular 220 manuell
ausgefüllt
hätte.
Die Bestimmungswebsite sendet dann entweder eine Konfigurationsseite oder
eine Fehlerseite 226 zu einem Servlet 228 der zentralen
Website, welches das gleiche Servlet wie das Servlet 218 sein
kann, zurück.
Das Servlet 228 analysiert dann syntaktisch die Seite 226,
um zu bestimmen, ob die Anmeldeoperation erfolgreich oder nicht
erfolgreich war oder nicht. Wenn die Anmeldeoperation als nicht
erfolgreich bestimmt wird, wie es durch das Element 224 gezeigt
ist, versucht das Servlet 218 den Anmeldeprozess eine vorbestimmte Zahl
mal (beispielsweise fünf
mal). Wenn die Anmeldeoperation als erfolgreich bestimmt wird, wie
es durch das Element 230 gezeigt ist, präsentiert
das Servlet 228 die korrespondierende Bestimmungswebsite-Startseite 206 in
einem neuen Webbrowserfenster oder der Zentral-Website-Startseite 206 des Benutzers.
Der Benutzer ist nun bei der Bestimmungswebsite bei seinem eigenen
Konto angemeldet. Wenn der Benutzer eine E-Commerce-Website als
die Bestimmungswebsite des Benutzers besucht, werden, wie es in
Bezug auf andere Ausführungsformen
der vorliegenden Erfindung beschrieben wird, alle Online-Transaktionen
geschützt.
-
3 ist
ein Systemdiagramm zur Darstellung automatisierter Registrierung
von Benutzerinformation bei mehreren Websites von einer Zentralwebsite-Stelle
aus. Wie oben unter Bezugnahme auf die 1 und 2 beschrieben,
kann gemäß der vorliegenden
Erfindung ein Benutzer die bevorzugten Websites des Benutzers besuchen,
ohne dass er jeweilige Benutzeranmeldeinformation eingeben muss. 3 wird
zum Beschreiben, wie ein Benutzer bei jeder gegebenen Website automatisch
registriert wird, benutzt.
-
Wenn
sich nach 3 ein Benutzer der zentralen
Website bei irgendeiner von mehreren Websites, für die automatisierte Registrierung
angeboten wird, registrieren will, geht der Benutzer einfach über den
Web-Client 102 zu einer Registrierungswebseite bei der
zentralen Website. Aus der Registrierungswebseite kann, wie in Bezug
auf 1 beschrieben, der Benutzer eine Liste von Sites
suchen, die vom Formularverwaltungssystem schon registriert worden ist.
-
Wenn
der Benutzer einmal entschieden hat, bei welcher Website der Benutzer
automatisch registriert werden will, klickt der Benutzer auf einen
diesen Sitenamen darstellenden Link. Die ID-Nummer 304 des
Benutzers und die Website-Registrierungswahl 302 werden
dann über
das HTLM-Vorderende 308 einem Benutzerregistrierungsservlet
(= user registration sevlet, nachstehend als „URS" bezeichnet) 306 zur weiteren
Verarbeitung zugeführt.
Das URS 306 frägt
(beispielsweise unter Verwendung einer SQL-Abfrage) die Datenbank 122 unter
Verwendung der ID-Nummer 304 des Benutzers und der Website-Registrierungswahl 302 als
Abfragekriterien ab, um korrespondierende Formulardaten 312 und
Benutzerdaten 314, die als Daten 122b und 122c gespeichert
sind, von der Datenbank 122 wiederzugewinnen. Wie in der 3 gezeigt enthält die Datenbank 122 Kontodaten 122a,
Websiteformulardaten 122b und Benutzerdaten 122c.
-
Das
URS 306 erzeugt dann dynamisch ein vervollständigtes
Formular 316 (das heißt „füllt es aus") durch Mischen der
Benutzerdaten 314 mit Formulardaten 312 für eine mit
der Website-Registrierungswahl 302 korrespondierenden Bestimmungswebsite 330.
Wenn beispielsweise die Anmeldeseite der Bestimmungswebsite 330 ein
Textfeld für
eine Telefonnummer des Benutzers aufweist, wird dieses Feld mit
dem von den Kontodaten 122a des Benutzers wiedergewonnenen
Telefonnummerdaten des Benutzers bestückt. Wenn die zentrale Website
Formulare (Formen) katalogisiert, werden Formularobjekte (das heißt Textfelder,
Passwortfelder usw.) mit korrespondierenden Felddaten katalogisiert,
die von der zentralen Website aus der Vorlage zugeordneter Feldnamen
der zentralen Website benutzt werden. Benutzerdaten wie beispielsweise
eine Telefonnummer einer Person usw. werden ebenfalls mit korrespondierenden
Felddaten katalogisiert, die von der zentralen Website aus der Vorlage
der zentralen Website benutzt werden.
-
Bei
dem obigen Beispiel erlaubt dies dem URS 306, das Formular 316 durch
einfaches Einsetzen der angeforderten Benutzerdaten (beispielsweise
als „Telefon
(telephone)" zugeordnet)
in das betreffende Formularkennzeichen (beispielsweise ebenfalls
als „Telefon" zugeordnet) „auszufüllen", wenn das URS 306 das
Formular 316 „ausschreibt". Wenn dieses virtuelle
Formular 316 vervollständigt ist,
wird das Formular 316 vom URS 306 einem korrespondierenden
Formular-URL bei der Bestimmungswebsite 330 übermittelt,
geradeso, als wenn jemand das Formular manuell ausgefüllt hätte. Die Bestimmungswebsite 330 sendet
dann entweder eine Bestätigungsseite
oder eine Zurückweisungsseite 318 zu
einem URS 322 zurück,
welches das gleiche wie das URS 306 sein kann. Das URS 322 analysiert
dann syntaktisch die Seite 318, um zu bestimmen, ob die
Registrierungsoperation erfolgreich oder nicht erfolgreich war oder
nicht. Wenn die Registrierungsoperation, wie durch das Element 320 gezeigt,
nicht erfolgreich ist, wiederholt das URS 322 den oben
beschriebenen Registrierungsprozess eine vorbestimmte Zahl mal (beispielsweise
fünf mal). Wenn
jedoch die Registrierungsoperation, wie durch das Element 324 gezeigt,
erfolgreich ist, werden neue Kontodaten 326 (das heißt der Benutzername und
das Passwort des Benutzers bei der Bestimmungswebsite 330)
in die Datenbank 122 eingegeben. Der Benutzer wird dann
zu einer Bestätigungsseite 328 umgeleitet,
die dem Benutzer anzeigt, dass der Benutzer bei der Bestimmungswebsite 330 erfolgreich
registriert ist und dass der korrespondierende Link des Benutzers
bei der zentralen Website aktiv ist.
-
Der
Benutzername und das Passwort für
die zentrale Website sind von all denen verschiedenen, die zum Anmelden/Registrieren
des Benutzers in den Bestimmungswebsites benutzt werden. Demgemäss sind
bei der bevorzugten Ausführungsform
CWS, DWS1, DWS2,... DWSn, bei denen CWS der Zentralwebsite-Anmeldename
und das Zentralwebsite-Passwort ist, und DWS1, DWS2, ... DWSn diejenigen
für die
Bestimmungswebsites. Jedoch sind andere Ausführungsformen, beispielsweise
(i) CWS = DWS1 = DWS2 = ... DWSn und (ii) CWS, DWS1 = DWS2 = ...
DWSn usw. möglich,
wie es die Fachleute der relevanten Technik(en) erkennen. Um außerdem eine
Online-Anonymität
des Benutzers aufrechtzuerhalten, können die Benutzernamen und/oder
-passwörter,
die mit CWS, DWS1, DWS2 und/oder DWSn korrespondieren, als eine
Reihe von Pseudozufallszahlen und/oder -zeichen gebildet sein, wie
es die Fachleute der relevanten Technik(en) erkennen. Wenn der Benutzer
wählt,
für CWS,
CWS1, CW2 und/oder DWSn seinen eigenen persönlichen Benutzeranmeldenamen
und sein eigenes Passwort zu benutzen, gibt die zentrale Website
eine Sicherheitswarnung an den Benutzer aus, um den Benutzer zu informieren,
dass seine Anonymität
und/oder Online-Sicherheit aus durch Benutzung vorher benutzter und/oder
leicht bestimmter Anmeldenamen und/oder Passwörter bestehen kann.
-
Online-Kredit/Debit-Kartentransaktionsverwaltung mit
minimierter Aktivierungszeit
-
In
Bezug auf die Verwaltung von Online-Kredit/Debit-Kartentransaktionen von einer Zentralwebsite-Stelle
aus mit minimierter Aktivierungszeit wird gemäß der vorliegenden Erfindung
ein Online-Kredit/Debit-Kartenkonto erzeugt. Das Online-Kredit/Debit-Kartenkonto
ist nur während
der Online-Transaktionsverarbeitung
aktiv gemacht, um die Risiken bei der Bewahrung der Kredit/Debit-Kartennummersicherheit
auf dem Internet zu vermindern.
-
Das
Online-Kredit/Debit-Kartenkonto gemäß einer Ausführungsform
arbeitet wie folgt: Die zentrale Website stellt Benutzern ein mit
gemeinsamer Handelsmarke versehenes Kredit/Debit-Kartenkonto (beispielsweise
die Central Web Site Visa Card) analog zu denen, die beispielsweise
von der Citybank den American Airlines (d. h. die America Airlines
Visa Card), von der Chase Manhattan Bank den New York Knicks (d.
h. die Knicks-Card) usw. bereitgestellt sind, bereit. Dieses Online-Kredit/Debit-Kartenkonto funktioniert
genau wie eine Kredit/Debit-Karte (bezeichnet auch als Kredit/Guthaben-Kredit/Kunden-, Kredit/Belastungs-,
Kredit/Soll-, Kredit/Debet-Karte), nur gibt es keine an den Benutzer
ausgegebene tatsächliche „Karte" (das heißt die Online-Karte
steht einem Benutzer nur zur Verfügung, während der Benutzer online ist).
Dieses Online-Kredit/Debit-Kartenkonto umfasst die oben beschriebene „Web-aktive (Web
active)" Kreditdiensteigenschaft
und stellt einem Benutzer die Befugnis bereit, die gleichen Ausgabefähigkeiten
und Online-Fähigkeiten
zu haben, die eine Kredit/Debit-Karte bereitstellt, ohne dass die Sicherheit
der persönlichen
Finanzen des Benutzers geopfert werden muss.
-
Demgemäss gibt
die zentrale Website mit gemeinsamer Handelsmarke versehene Online-Kredit/Debit-„Karten" an seine Benutzer
(beispielsweise durch Visa, Mastercard usw.) aus, mit der vorteilhaften
Ausnahme, dass für
die Benutzer der zentralen Website keine „realen" Karten hergestellt werden. Die Web-aktive
Krediteigenschaft erlaubt dem Online- Kredit/Debit-Kartenkonto nur aktiv zu
sein (das heißt
fähig zu
sein, Belastungen zu akzeptieren), während der Benutzer unter Benutzung
der Dienste der zentralen Website tatsächlich online ist. Jedesmal
wenn ein Benutzer der zentralen Website auf einen bevorzugten Link
zu einer bevorzugten E-Commerce-Website
(beispielsweise E-Commerce-Websites, Auktions-Websites usw.) anklickt, wie es oben unter
Bezugnahme auf die 2 beschrieben wurde, überträgt eine
Software bei der Zentralwebsite-Stelle gleichzeitig eine „Aktualisierungsdatei
(update file)„ über beispielsweise
verschlüsselte
E-Mail, sicheres Faksimile bzw. Fax, sichere Funkkommunikation,
sichere Telefonkommunikation usw. zu der oder den mit gemeinsamer
Handelsmarke versehenden Banken/Geldinstituten der zentralen Website,
wenn die zentrale Website den Benutzer bei der korrespondierenden
bevorzugten E-Commerce-Website anmeldet. Diese „Aktualisierungsdatei" wird zum „Aktivieren" des Online-Kredit/Debit-Kartenkontos
des Benutzers benutzt, jedoch nur während der Benutzer eine oder
mehrere bevorzugte Websites während E-Commerce-Transaktionen
anschaut.
-
Die „Aktualisierungsdatei" enthält eine
Texttabelle, welche die Online-Kredit/Debit-Kontonummern der Benutzer,
die gegenwärtig
bei einer Site sind, wo ihre Belastungsvermögen „aktiv" sein müssen, auflistet. Die zentrale
Website stellt dem Geldinstitut, das mit den Online-Kredit/Debit-Kartenkonten der
zentralen Website eine gemeinsame Handelsmarke aufweist, einen Syntaxanalysierungs-Softwarecode
bereit, um die „Aktualisierungsdatei", welche die zentrale
Website beispielsweise zum Geldinstitut E-mailt, syntaktisch zu
analysieren. Die eigenen Programmierer des Geldinstituts können die
Ausgabe der Syntaxanalysierungssoftware der zentralen Website zum
Arbeiten mit der eigenen Architektur des Geldinstituts kundenspezifisch
anpassen, um den Status der eigenen Online-Kredit/Debit-Kartenkonten
der zentralen Website entsprechend Tabellen in der „Aktualisierungsdatei" von „Akzeptieren" in „Verweigern" ändern.
-
Die
Software der zentralen Website sendet auch eine andere „Aktualisierungsdatei", um Belastungsmöglichkeiten
des Online-Kredit/Debit-Kartenkontos eines Benutzers der zentralen
Website zu deaktivieren, welche Zeit auch immer der Benutzer als
die vom Benutzer gewünschte „Zeit-Aus"-Periode (beispielsweise
im Bereich von 15 bis 30 Minuten nachdem die Online-Kredit/Debit-Karte
anfangs aktiviert wurde) einstellt. Diese „Zeit-Aus"-Periode stellt die Länge der
Zeit dar, in welcher der Benutzer einkaufen muss, bevor das Kredit/Debit-Kartenkonto des Benutzers
inaktiv wird. Sollte die Zeit eines Benutzers auslaufen, bevor der
Benutzer ausgecheckt hat, ist alles, was der Benutzer zu tun hat,
einfach erneut auf den Link des Benutzers für diese jeweilige Site in der
persönlichen
Webseite des Benutzers bei der zentralen Website zu klicken. Dann
fährt der
Benutzer mit den Checkout-Prozeduren
des Benutzers fort. Eine Bezahlung für bzw. an die angeschauten E-Commerce-Websites
wird vorteilhafter Weise durch Verwendung von in der Technik bekannten existierenden
Prozeduren zur Belastung eines Kredit/Debit-Karten"kontos" (beispielsweise
existierende Prozeduren von Visa, Mastercard usw.) geleistet. Eine
Zentralwebsite-Online-Kredit/Debit-Kartenkontonummer eines Benutzers wird,
wie es unter Bezugnahme auf die 1 und 2 beschrieben
ist, mit dem Vorlagenprofil des Benutzers querverwiesen, und das
Profil wird zum Registrieren des Benutzers bei neues Sites, die
eine Kredit/Debit-Karte erfordern, benutzt. Das oben beschriebene
System und Verfahren zur Verwaltung von E-Commerce-Transaktionen von
einer Zentralwebsite-Stelle mit minimierter Online-Kredit/Debit-Kartenkonto-Aktivierungszeit wird
nun unter Bezugnahme auf die 4 detailliert beschrieben.
-
Bei
der 4 meldet sich ein Benutzer bei der zentralen Website über den
Web-Client 102 an und stellt dem HTML-Vorderende der zentralen
Website, das die mit dem Benutzer korrespondierende persönliche Webseite 206 anzeigt,
einen Benutzernamen und ein Passwort 204 bereit. Der Benutzer klickt
auf einen Link zu einer Bestimmungs-E-Commerce-Website 418,
und die korrespondierende URL 216 wird zu einem Linkservlet 218 übertragen.
Das Servlet 218 gewinnt die korrespondierenden Formulardaten
für die
URL 216 von der Datenbank 122 wieder. Das Servlet 218 übermittelt
dann die korrespondiere Benutzerinformation 416 der gewählten Website 418.
Das Servlet 218 überträgt die in
den in der Datenbank 122 gespeicherten sind Anmeldeskriptformulardaten
für die
URL 216 enthaltene Benutzerinformation 416 zur
Bestimmungswebsite 418. Dies gibt in Wirklichkeit für den Benutzer
die Benutzerinformation 416 automatisch in das oder die
geeigneten Formulare bei der Bestimmungswebsite 418 ein. Die
von der Bestimmungswebsite 418 ausgegebene HTML-420-Webseite
wird dann über
den Web-Client 102 zum Benutzer übertragen.
-
Das
Servlet 218 überträgt auch
eine Aktualisierungsdatei 410 (beispielsweise über verschlüsselte E-Mail,
sicheres Faksimile bzw. Fax, sichere Funkkommunikation, sichere
Telefonkommunikation usw.) zu einem Kredit ausgebenden Geldinstitut 412 (beispielsweise
eine Bank), um das Online-Kredit/Debit-Kartenkonto
des Benutzers zu aktivieren. Nach einer vorbestimmten oder benutzerspezifizierten
Zeitperiode (15 bis 30 Minuten) wird eine andere Aktualisierungsdatei 414 zum
Geldinstitut 412 (beispielsweise über verschlüsselte E-Mail, sicheres Faksimile bzw. Fax, sichere
Funkkommunikation, sichere Telefonkommunikation usw.) gesendet,
um das Online-Kredit/Debit-Kartenkonto
des Benutzers zu deaktivieren. Nachdem das Geldinstitut 412 die
Aktualisierungsdateien 410 oder 414 empfangen
hat, werden die Dateien syntaktisch analysiert, um Datenelemente,
die mit Kontonummern korrespondieren, zu isolieren, Instruktionen
zu akzeptieren oder zu verweigern usw. Das Geldinstitut 414 querverweist
dann die analysierten Daten zu ihrer eigenen internen Kredit/Debit-Kartendatenbank
von Tabellen und vollendet die Operation. Die Verwaltung von E-Commerce-Transaktionen
von einer Zentralwebsite-Stelle mit minimierter Online-Kredit/Debit-Kartenkonto-Aktivierungszeit
wird nun unter Bezugnahme auf die 5 detailliert
beschrieben.
-
Bei
der 5 gewinnt ein Servlet 218, nachdem ein
Benutzer über
dem Web-Client 102 bei der zentralen Website angemeldet
ist und eine URL 216 für
eine gewählte
E-Commerce-Website 418 von
der persönlichen
Webseite des Benutzers übermittelt,
die korrespondierenden Formulardaten für die URL 216 von
der Datenbank 122 wieder. Das Servlet 218 überträgt die in
den in der Datenbank 122 gespeicherten Anmeldeskriptformulardaten
für die
URL 216 enthaltene Benutzerinformation zur Bestimmungswebsite 418.
Dies gibt in Wirklichkeit für
den Benutzer automatisch die Benutzerinformation 416 in
das oder die geeigneten Formulare bei der Bestimmungswebsite 418 ein.
Die von der Bestimmungswebsite 218 auf der Basis der eingegebenen
Benutzerinformation 416 ausgegebene HTLM-Webseite 420 wird
dann über
den Web-Client 102 zum Benutzer übertragen.
-
Das
Servlet 218 überträgt auch
eine Aktualisierungsdatei 410 (beispielsweise über verschlüsselte E-Mail,
sicheres Faksimile bzw. Fax, sichere Funkkommunikation, sichere
Telefonkommunikation usw.) zum Kredit ausgebenden Geldinstitut 412 (beispielsweise
eine Bank), um das Online-Kredit/Debit-Kartenkonto
des Benutzer zu aktivieren. Nach einer vorbestimmten oder benutzerspezifizierten
Zeitperiode (beispielsweise 15 bis 30 Minuten) wird eine andere Aktualisierungsdatei 414 zum
Geldinstitut 412 (beispielsweise über verschlüsselte E-Mail, sicheres Faksimile
bzw. Fax, sichere Funkkommunikation, sichere Telefonkommunikation
usw.) gesendet, um das Online-Kredit/Debit-Kartenkonto des Benutzers
zu deaktivieren. Nachdem das Geldinstitut 412 die Aktualisierungsdateien 410 oder 414 empfangen
hat, werden die Dateien analysiert, um mit Kontonummern korrespondierende
Datenelemente zu isolieren, Instruktionen zu akzeptieren oder verweigern usw.
Ein Kreditkartennetzwerk 508 (beispielsweise Visa, Mastercard
usw.) fordert dann eine Autorisierung von beispielsweise dem Geldinstitut 412 an,
das dem Kreditkartennetzwerk 508 die Transaktionsautorisierungsbestätigung sendet,
wenn die Gebühr
bzw. Belastung erfolgreich bearbeitet worden ist. Abhängig davon,
welche Konten die zentrale Website auf einen aktiven oder deaktiven
Status aktualisiert, wird die Autorisierung entsprechend bekannten
Prozeduren bearbeitet. Die Aktualisierungsdatei 410 wird
typischerweise immer zum Geldinstitut 412 gesendet, bevor
die Belastungsautorisierungsanforderung vom Kreditkartennetzwerk 508 von
einem Online-Händler, insbesondere
-Einzelhändler
(das heißt
der Bestimmungswebsite 418) empfangen wird.
-
Ein
Nachschaltprozess 524 des Geldinstituts 412 fordert
eine Autorisierung für
einen Dollarwert des oder der Käufe
des Benutzers an, und ein Nachschaltprozess 526 des Geldinstituts 412 querverweist
kritische Daten, die von den Aktualisierungsdateien 410 oder 414 syntaktisch
analysiert worden sind, zu den Datenbanktabellen 528 des
Geldinstituts, welche die Online-Kredit/Debit-Kartenkonten der zentralen
Website enthalten. Der Nachschaltprozess 526 nimmt die
kritischen Datenwert und ändert die
notwendigen Spalten- und Reihenwerte in der Datenbanktabelle 528 des
Geldinstituts, um den aktiven Status der Online-Kredit/Debit-Kartenkonten
der zentralen Website zwischen „aktiv" und „inaktiv" und umgekehrt hin- und herzuschalten.
-
6 ist
ein detailliertes Systemdiagramm zur Darstellung der Verwaltung
von E-Commerce-Transaktionen in einem Kreditkartennetzwerk von einer
Zentralwebsite-Stelle mit minimierter Online-Kredit/Debit-Kartenkonto-Aktivierungszeit
gemäß einer
anderen Ausführungsform
der vorliegenden Erfindung. Bei der 6 gewinnt
ein Linkservlet 218, nachdem ein Benutzer über den
Web-Client 102 in der zentralen Website angemeldet ist
und von der persönlichen
Webseite des Benutzers eine URL 216 für eine gewählte E-Commerce-Website 418 übermittelt
hat, die korrespondierenden Formulardaten für die URL 216 von
der Datenbank 122 wieder. Das Servlet 218 überträgt die in
den in der Datenbank 122 gespeicherten Anmeldeskriptformulardaten
für die URL 216 enthaltene
Benutzerinformation 416 zur Bestimmungswebsite 418.
Dies gibt in Wirklichkeit für den
Benutzer automatisch die Benutzerinformation 416 in das
oder die geeigneten Formulare bei der Bestimmungswebsite 418 ein.
Die von Bestimmungswebsite 418 ausgegebene HTLM-Webseite 420 wird dann
auf der Basis der eingegebenen Benutzerinformation 416 über den
Web-Client 102 zum Benutzer übertragen. Wenn der Benutzer
bei der Bestimmungswebsite 418 eine Online-Kreditkartentransaktion
ausführt,
wird diese Anforderung zu einem Kreditkartennetzwerk 508 (beispielsweise
Visa, Mastercard usw.) gesendet, und das Servlet 218 überträgt eine
Aktualisierungsdatei 608 (beispielsweise über verschlüsselte E-Mail,
sicheres Faksimile bzw. Fax, sichere Funkkommunikation, sichere
Telefonkommunikation usw.) in einen Kommunikationskanal des Kreditkartennetzwerks 508.
Ein Aktualisierungsdatei-Verifikationsserver (Update file verification
server, nachstehend mit „UFVS" bezeichnet) 602 überwacht den
Kommunikationskanal (beispielsweise unter Verwendung einer Java
script-„sniffer/snooper"-Software), um Kaufanforderungen
auszufiltern, die über
die zentrale Website von einem normalen Verkehr traditioneller Kreditkartentransaktionen
im Kommunikationskanal des Kreditkartennetzwerks 508 gemacht werden.
Der UFVS verifiziert die Konten der zentralen Website gegen die
von der zentralen Website über
das Servlet 218 gesendeten Aktualisierungsdatei 608.
Wenn der UFVS 602 bestimmt, dass die Aktualisierungsdatei 608 nicht
präsent
ist, wird die Transaktion automatisch zurückgewiesen, und der Benutzer
wird entsprechend informiert (beispielsweise über eine zur persönlichen
Seite des Benutzers bei der zentralen Website über E-Mail usw. gesendete Nachricht).
-
Wenn
jedoch der UFVS 602 feststellt, dass die Aktualisierungsdatei 608 präsent ist,
kann die Transaktion verarbeitet werden. Demgemäss nimmt das Kreditkartennetzwerk 508 über die
Aktualisierungsdatei 608 übertragene Benutzerinformation
und authentisiert, dass der Benutzer über den UFVS 602 der
zentralen Website online ist. Das Kreditkartennetzwerk 508 überträgt dann
eine Belastungsanforderung zu einem unterschreibenden Geldinstitut
(beispielsweise eine Bank) unter Verwendung bekannter Prozesse anstelle
von Kreditkartentransaktionen. Nur nachdem die Transaktion des Benutzers über die Aktualisierungsdatei 608 verifiziert
worden ist, wird die korrespondierende Kaufanforderung zu einem Transaktionsleitweglenker
bzw. -router 606 eines unterschreibenden Geldinstituts
zurückgesendet,
um in den gleichen Arbeitsfluss, bei dem traditionelle Kreditkartentransaktionen
behandelt werden, gemischt zu werden. Demgemäss nimmt ein Kreditkarten ausgebendes
Geldinstitut 412 (beispielsweise eine Bank) die vom Transaktionsrouter 606 des
unterschreibenden Geldinstituts übertragene
Kreditkartenkontonummer und prüft
seine Datenbank um zu bestimmen, ob genug Kredit vorhanden ist,
um die Transaktionsanforderung für
den Benutzer zu honorieren. Nachdem die Transaktion vom Kreditkarten ausgebende
Geldinstitut 412 verarbeitet ist, wird eine Akzeptierungs/Ablehnungs-Bestätigung 604 zum UFVS 602 zum
Einleiten der Beseitigung der Aktualisierungsdatei 608,
zum Kreditkartennetzwerk und zur Bestimmungswebsite 418 (das
heißt
Händler, insbesondere
Großhändler) gesendet,
wobei die Operation vollendet wird.
-
Zum
Auslösen
der Implementierung des Online-Kredit/Debit-Kartenkontos
mit minimierter Aktivierungszeit ist eine minimale Entwicklungszeit
notwendig, da der Dienst durch Benutzung existierender Architekturen
(beispielsweise existierende Architekturen von Visa, Mastercard,
Geldinstitut usw.) aufgebaut werden kann. Da die Online-Kredit/Debit-Kartenkonten der
zentralen Website tatsächliche „Kreditkarten"-Konten sind, akzeptieren
E-Commerce-Websites diese Konten leicht als eine alternative Bezahlungsform
während
E-Commernce-Transaktionen.
-
Demgemäss kann
ein Benutzer durch Begrenzung der Aktivierungszeit für das Online-Kredit/Debit-Kartenkonto
die finanzielle Bloßstellung
des Benutzers während
Online-Kredit/Debit-Kartentransaktionen
minimieren.
-
Online-Kredit/Debit-Kartentransaktionsverwaltung mit
minimierter finanzieller Bloßstellung
-
Das
Online-Kredit/Debit-Kartenkonto mit minimierter finanzieller Bloßstellung
arbeitet wie folgt. Das Online-Kredit/Debit-Kartensystem
arbeitet auf eine Weise, die zu einer Metrokarte (metro card) für Massentransitautorität (mass
transit authority) (beispielsweise eine MetroCard für die NYC
Mass Transit Authority) ähnlich
ist, wird jedoch von einem existierenden Kredit/Debit-Kartenkonto
eines Benutzers bei einer Bank oder einem anderen Geldinstitut „aufgeladen
(charged up)". Das
Online-Kredit/Debit-Kartenkontosystem kann auf dem gegenwärtigen Markt
beispielsweise durch Bank- oder Geldinstitute unterststützt werden,
die eine fortgeschrittene Verschlüsselung und Online-Bankgeschäftsdienste
schon an Ort und Stelle haben, und durch Geldinstitute, die Kredit/Debit-Belastungskarten
ausgeben. Die oben angegebene minimierte Finanzbloßstellungseigenschaft
stellt eine zusätzliche
Maßnahme
zur Überwachung,
wie viel Finanzen eines Benutzers während Online-Finanztransaktionen
bloßgestellt
werden, bereit, und kann allein oder in Kombination mit anderen Ausführungsformen
der vorliegenden Erfindung benutzt werden.
-
Die
Geldinstitute, die das laufende Kredit/Debit-Kartensystem stützen, erzeugen eine Online-Kredit/Debit-Kartenkontennummer,
die ihre eigene Kunden dazu berechtigen, einen vorbestimmten Geldbetrag
ihrem „neuen" Online-Kredit/Debit-Kartenkonto
auf dem Online-Kredit/Debit-System der zentralen Website zuzuteilen.
Das „Aufladen
(charging up)" des
Online-Kredit/Debit-Kartenkontos wird durch die existierenden verschlüsselten
Online-Bankgeschäftsnetzwerke
und -sites der die Unterstützung
für das
Online-Kredit/Debit-Kartenkontosystem
bereitstellenden Geldinstitute ausgeführt. Nachdem das Online-Kredit/Debit-Kartenkonto
erzeugt und geladen bzw. belastet ist, leitet das Geldinstitut, welches
das Konto ausgibt, die Bilanz- bzw. Saldoinformation und Kontonummer
zusammen mit Kundeninformation zur zentralen Website weiter. Die
Verwaltung von E-Commerce-Transaktionen von einer Zentralwebsite-Stelle
mit minimierter finanzieller Bloßstellung für ein Online-Kredit/Debit-Kartenkonto
wird nun unter Bezugnahme auf die 7 beschrieben.
-
Bei 7 gewinnt
ein Servlet 218, nachdem ein Benutzer über den Web-Client 102 in
der zentralen Website angemeldet ist und eine URL 216 für eine gewählte E-Commerce-Website 418 von
der persönlichen
Webseite des Benutzers übermittelt, von
der Datenbank 122 die korrespondierenden Formulardaten
für die
URL 216 wieder. Das Servlet 218 überträgt die in
den durch das Formularverwaltungssystem der 1 gespeicherten
Anmeldeskriptformulardaten für
die URL 216 enthaltene Benutzerinformation 416 zur
Bestimmungswebsite 418. Dies gibt in Wirklichkeit für den Benutzer
automatisch die Benutzerinformation 416 in das oder die
geeigneten Formulare bei der Bestimmungswebsite 418 ein.
Die von der Bestimmungswebsite 418 auf der Basis der eingegebenen
Benutzerinformation 416 ausgegebene HTML-Webseite 420 wird
dann über
den Web-Client 102 zum Benutzer übertragen.
-
Das
Servlet 218 überträgt auch
eine Aktualisierungsdatei 410 (beispielsweise über verschlüsselte E-Mail,
sicheres Faksimile bzw. Fax, sichere Funkkommunikation, sichere
Telefonkommunikation usw.) zu dem Kreditkarten ausgegebenen Geldinstitut 412 (beispielsweise
eine Bank), um das Online-Kredit/Debit-Kartenkonto
des Benutzers zu aktivieren. Nach einer vorbestimmten oder benutzerspezifizierten
Zeitperiode (beispielsweise 15 bis 30 Minuten) wird eine andere
Aktualisierungsdatei 414 zum Geldinstitut 412 (beispielsweise über verschlüsselte E-Mail,
sicheres Faksimile bzw. Fax, sichere Funkkommunikation, sichere
Telefonkommunikation usw.) gesendet, um das Online-Kredit/Debit-Kartenkonto des
Benutzers zu deaktivieren. Nachdem das Geldinstitut 412 die
Aktualisierungsdateien 412 oder 414 empfangen
hat, werden die Dateien syntaktisch analysiert, um mit Kontonummern
korrespondierende Datenelemente zu isolieren, Instruktionen zu akzeptieren
oder abzulehnen usw. Ein Kreditkartennetzwerk 508 (beispielsweise
Visa, Mastercard usw.) fordert dann eine Autorisierung von beispielsweise
dem Geldinstitut 412 an, das dem Kreditkartennetzwerk 508 die
Transaktionsautorisierungsbestätigung
sendet, wenn die Belastung bzw. Ladung erfolgreich ausgeführt worden
ist. Abhängig
davon, welche Konten die zentrale Website auf den aktiven oder deaktiven Status
aktualisiert, wird die Autorisierung entsprechend bekannten Prozeduren
bearbeitet. Die Aktualisierungsdatei 410 wird typischerweise
immer zum Geldinstitut 412 gesendet, bevor die Belastungsautorisierungsanforderung
vom Kreditkartennetzwerk 508 von einem Online-Händler, insbesondere
-Einzelhändler
(der Bestimmungswebsite 418) empfangen wird.
-
Ein
Nachschaltprozess 524 des Geldinstituts 412 fordert
die Autorisierung für
einen Dollarwert des oder der Käufe
des Benutzers an, und ein Nachschaltprozess 526 des Geldinstituts 412 querverweist
kritische Daten, die von den Aktualisierungsdateien 410 oder 414 syntaktisch
analysiert sind, zu den Online-Kredit/Debit-Kartenkonten der die
zentrale Website enthaltenden Datenbanktabellen 528 des Geldinstituts.
Der Nachschaltprozess 526 nimmt die kritischen Datenwerte
und ändert
die notwendigen Spalten- und Reihenwerte in der Datenbanktabelle 528 des
Geldinstituts, um den aktiven Status der Online-Kredit/Debit-Kartenkonten
der zentralen Website zwischen „aktiv" und „inaktiv" und umgekehrt hin- und herzuschalten.
-
Um
die finanzielle Bloßstellung
des Online-Kredit/Debit-Kartenkontos
zu begrenzen, autorisiert der Benutzer über beispielsweise die Website 730 des
Geldinstituts 412 oder eine andere existierende Einrichtung
das „Aufladen" (das heißt Vorauszahlung)
des Online-Kredit/Debit-Kartenkontos. Eine Guthaben-Online-Kredit/Debit-Kartenkontodatenbank 732 speichert
den vom existierenden Kredit/Debit-Kartenkonto autorisierten Vorauszahlungs-
bzw. Guthabenbetrag des Benutzers. Die Guthaben-Online-Kredit/Debit-Kartenkonto-Datenbank 732 ist
an die Datenbank 122 der zentralen Website gekoppelt, so
dass der Online-Kredit/Debit-Kartenkontosaldo des Benutzers und
andere Information in der Datenbank 122 der zentralen Website
gespeichert werden können.
-
Zum
Ingangbringen der Implementierung des Online-Kredit/Debit-Kartenkontos mit minimiertem
Saldo wird eine minimale Entwicklungszeit benötigt, da der Dienst durch Benutzung
existierender Architektur (beispielsweise existierende Architekturen von
Visa, Mastercard, Geldinstitut usw.) und mit der Hinzufügung einer
Guthaben-Online-Kredit/Debitkarten-Datenbank 732 aufgebaut
werden kann. Das Online-Kredit/Debit-Kartenkontosystem kann deshalb mit
existierenden und sich entwickelnden Websites als eine Alternative
zu herkömmlichen
Kreditkartennummern in ihren existierenden Registrierungsformularen
benutzt werden.
-
Demgemäss kann
ein Benutzer durch Begrenzung der Menge von dem Online-Kredit/Debit-Kartenkonto
zur Verfügung
stehenden Fonds die finanzielle Freilegung des Benutzers während Online-Kredit/Debit-Kartentransaktionen
minimieren.
-
Sichere Offline-Kreditkartentransaktionsverwaltung
-
Obgleich
die vorliegende Erfindung in Form einer Bereitstellung einer Online-Kredit/Debit-Karte in
der Form einer virtuellen Kreditkarte beschrieben ist und typischerweise
nicht die Ausgabe einer physikalischen bzw. körperlichen Realweltkarte zur
Folge hat, kann die vorliegende Erfindung, um Sicherheitsmängel anzusprechen,
durch Ausgabe einer physikalischen Realweltkreditkarte praktiziert
werden, was nun beschrieben wird.
-
8 ist
ein detailliertes Systemdiagramm zur Darstellung der Verwaltung
von rechnerunabhängigen
Kreditkartentransaktionen bzw. Offline-Kreditkartentransaktionen mit minimierter
finanzieller Freilegung eines Kreditkartenkontos gemäß der vorliegenden
Erfindung. Bei 8 versucht ein Kreditkartenbenutzer 802 bei
einem POS-Anschluss bzw. -Endgerät
(POS = Point-of-Sale (Kasse, Verkaufsplatz)) bei einem Einzelhandelskaufhaus
einen Offline-Kreditkartenkauf zu tätigen. Die Kreditkarte ist
so konfiguriert, dass sie ruht (das heißt nicht benutzbar ist) bis
die Identität
des Benutzers während
einer Kreditkartentransaktion auf verschiedenen möglichen Wegen,
wie sie durch das Element 804 gezeigt sind, bestätigt wird.
Die Identität
des Benutzers kann über eine
Biometrik/Intelligenzchip-Extraktionseinrichtung 806 (beispielsweise
eine biometrische Fingerabdruck/Sprachabdruck usw. -Extraktionseinrichtung 808),
die in die Kreditkarte eingebettet ist, über eine PIN-Nummer-Extraktion 810, über Sprach/Netzhaut-Merkmalextraktion
usw. bestätigt
werden.
-
In
jedem Fall wird die Identitätsinformation des
Benutzers extrahiert, wird diese Information zu einem Kreditkartenprozessor 814 (beispielsweise
im Einzelhandelskaufhaus lokalisiert) gesendet, der die Benutzeridentifikationsinformation
und die Kreditkartentransaktionsinformation aufnimmt und bestimmt, welches
Kreditkartennetzwerk die Kreditkartenbelastungsanforderung empfangen
soll. Der Kreditkartenprozessor 814 überreicht dann die Belastungsanforderung
einem geeigneten Kreditkartennetzwerk 816 (beispielsweise
Visa, Mastercard usw.). Das Kreditkartennetzwerk 816 nimmt
dann die über
den Kreditkartenleser 812 übertragene Information auf
und authentisiert die Identifikationsdaten des Benutzers, die durch
welches auch immer benutzte Verfahren (das heißt die biometrischen Daten,
PIN-Nummer-Daten usw. des Benutzers benutzend) gesammelt wurden.
-
Das
Kreditkartennetzwerk 816 benutzt eine Kreditkarten-Datenbank 818 zum
Authentisieren der Identitätsinformation
des Benutzers. Wenn die Authentisierung des Benutzers über die
Datenbank 818 nicht gemacht werden kann, bleibt die Kreditkarte
in einem ruhenden (das heißt
unbenutzbaren) Zustand, wird eine Belastungsanforderung zu dem die
Kreditkarte ausgebenden Geldinstitut 820 (beispielsweise eine
Bank) nicht weitergeleitet, und wird eine Kreditkartenbelastungszurückweisung
zum Kreditkartenleser 812 gesendet. Wenn jedoch die Authentisierung des
Benutzers über
die Datenbank 818 gemacht werden kann, überreicht das Kreditkartennetzwerk 816 die
Belastungsanforderung 822 zu dem die Kreditkarte ausgebenden
Geldinstitut 820 unter Verwendung der gleichen Prozesse,
die vom Kreditkartennetzwerk 816 für normale Kreditkartentransaktionsverarbeitung
hergestellt worden sind.
-
Demgemäss nimmt
das die Kreditkarte ausgebende Geldinstitut 820 die Kreditkarten-Kontonummer
von der Belastungsanforderung 822 und verifiziert über seine
Datenbank 818, ob genug Kredit vorhanden ist, um die Transaktionsanforderung
für den
Benutzer zu honorieren. Nachdem die Transaktion von dem die Kreditkarte
ausgebenden Geldinstitut 820 bearbeitet ist, wird über den
Kartenleser 812 eine Akzeptierungs/Ablehnungs-Bestätigung 822 zum Kreditkartennetzwerk 816 und
zum Händler,
insbesondere Einzelhändler
gesendet, wodurch die Kreditkartentransaktion vollendet ist.
-
9 ist
ein detailliertes Systemdiagramm zur Darstellung der Verwaltung
von Offline-Kreditkartentransaktionen
mit minimierter finanzieller Bloßstellung eines Kredit/Debit-Kartenkontos
gemäß einer anderen
Ausführungsform
der vorliegenden Erfindung. Das System der 9 ist ähnlich zum
System der 8, mit der Ausnahme, dass die
Kreditkartendatenbank 818 zur Authentisierung der Identitätsinformation
des Benutzers nicht direkt vom Kreditkartennetzwerk 816 kontrolliert
wird. Sonst arbeitet das System der 9 auf ähnliche
Weise wie das System der 8 und wird der Kürze wegen
nicht weiter beschrieben.
-
Demgemäss kann
ein Benutzer durch Kontrollieren des Offline-Kreditkartenkontos
die finanzielle Bloßstellung
des Benutzers während
der Offline-Kreditkartentransaktionen minimieren.
-
Untergeordnetes Kredit/Debit-Kartenkontrollsystem
-
Die
vorliegende Erfindung umfasst außerdem was als ein „Subordinate
Card Control System (untergeordnetes Kartenkontrollsystem)" bezeichnet wird,
das später
unter Bezugnahme auf die 10 bis 24 detailliert
beschrieben wird. Dieses sogenannte Subordinate Card Control System
(SCCS) arbeitet, um sowohl eine Offline- als auch Online-Kredit/Debit-Kartentransaktion
zu erleichtern, und kann in Verbindung mit jeder der oben beschriebenen
Ausführungsformen
der vorliegenden Erfindung benutzt werden.
-
Das
SCCS wirkt mit existierenden Architekturen von Banken/Geldinstituten
zusammen. Die Administrations/Kontroll-Funktion wird sowohl für Offline-
als auch Onlinetransaktionen über
die zentrale Website ausgeführt.
Sowohl das Online- als auch Offlinesystem erlaubt einem primären Kredit/Debit-Kartenhalter,
beispielsweise einem Elternteil, eine „untergeordnete (subordinate)" Kredit/Debit-Karte für einen
Benutzer, beispielsweise das Kind des Halters, abhängig auszugeben
usw., die ein vorbestimmtes Kreditlimit aufweist, das jederzeit
geändert
werden kann, so lange die primäre
oder „Master"-Kredit/Debit-Karte
einen verfügbaren
Saldo aufweist. Das vorbestimmte Kreditlimit für die untergeordnete Kredit/Debit-Karte
wird vom Halter eingestellt und an die Masterkarte gebunden. Ein
solches System kann als ein Werkzeug für Eltern benutzt werden, um
ihren Kindern zu lernen, wie Geld zu verwalten und auszugeben ist,
während
sie noch an die Karte der Eltern gebunden sind, für der Eltern
eigenes Komfortniveau der Kontrolle. Das heißt, das System stellt eine
Art vorübergehendes
Ausgabeprodukt für
ein Kind bereit, bis das Kind bereit ist, seine eigene Kredit/Debit-Karte
zu haben. Beispielsweise erlaubt das System einem Elternteil im
Vergleich zur herkömmlichen Kredit/Debit-Kartenmodellen,
an ihre/sein Kind eine untergeordnete Karte herauszugeben, wenn
das Kind zum College weggeht, wodurch dem Kind die mit der Kredit/Debit-Kartenerfahrung verbundene Verantwortlichkeit
gegeben wird.
-
Auf
dem einfachsten Operationsniveau erlaubt das System einem Elternteil
nicht nur ein Kreditlimit für
die untergeordnete Kredit/Debit-Karte (das heißt die Karte des Abhängigen)
einzustellen, sondern das System stellt auch Kontrollniveaus über die untergeordnete
Kredit/Debit-Karte für
den Elternteil bereit. Beispielsweise ist (i) eine Kalenderkontrolleigenschaft
bereitgestellt, welche dem Elternteil die Fähigkeit gibt, Käufe unter
Verwendung der untergeordneten Kredit/Debit-Karte nur während gewisser Zeiten
des Monats zu erlauben, (ii) ist eine Transaktionsbegrenzungseigenschaft
bereitgestellt, die dem Elternteil die Fähigkeit gibt, eine Zahl von
Transaktionen mit der untergeordneten Kredit/Debit-Karte innerhalb
einer vorbestimmten Zeitperiode (beispielsweise während einer Woche,
während
eines Monats, während
eines Tages usw.) zu beschränken,
und (iii) ist eine Händleridentifikations-
bzw. Händler-ID-Eigenschaft,
insbesondere Großhändler-ID-Eigenschaft bereitgestellt,
bei der Unterordnungs-Kredit/Debit-Kartentransaktionsdatenpakete
eine Händler-ID-Nummer zum Hinweisen
auf den Händler,
insbesondere Großhändler, der
während
der Transaktion gekaufte Güter/Dienste
verkauft, enthalten. Die zentrale Website hält eine Tabelle von Händler-ID-Nummern
und zugeordnete Transaktionsdaten aufrecht. Die Händler-ID-Nummern
werden außerdem
zum Identifizieren beispielsweise der Industrie, des Ortes usw.
des Händlers
benutzt, was einem Elternteil ermöglicht, die Käufe eines
Kindes unter Verwendung der untergeordneten Kredit/Debit-Karte in Bezug
auf Industrien wie beispielsweise Nahrungsmitteldienste, Supermärkte, Transportierung
usw. und in Bezug auf den Ort zu überwachen. Solche in den Tabellen
der zentralen Website aufrecherhaltenen ID-Nummern können vom
Elternteil dazu benutzt werden, Transaktionen nur auf spezielle
Händler,
insbesondere Großhändler (beispielsweise
Nahrungsmitteldienste, Transportierung usw.) zu beschränken und
kontrollieren und/oder Transaktionen für ein ganzes Genre von Händlern,
insbesondere Großhändlern (beispielsweise
Pornographie, Videospiele, Musik usw.) über eine von der zentralen
Website vorgesehene Kontrolleigenschafts-Schnittstelle zu beschränken.
-
Die
zentrale Website stellt die oben genannte Schnittstelle für den primären Benutzer
(beispielsweise ein Elternteil) bereit, um die oben genannten Kontrollen
einzustellen. Wenn dann eine untergeordnete Kredit/Debit-Kartentransaktion
auftritt, bearbeitet die zentrale Website die Transaktion (das heißt Weiterleiten
des Unterordnungs-Kredit/Debit-Kartentransaktionsdatenpakets
zur ausgebenden Bank bzw. Ausgabebank/zum ausgebenden Geldinstitut bzw.
Ausgabegeldinstitut der zentralen Website) nur, wenn die Transaktion
die vom Elternteil eingestellten Kontrollkriterien wie beispielsweise
während
einer vorbestimmten Zeit oder an einem vorbestimmten Ort erfüllt.
-
Das
oben beschriebene SCCS arbeitet sowohl für Online- als auch Offline-Unterordnungs-Debit/Kredit-Kartentransaktionen
nahtlos, da die zentrale Website die Transaktionsdatenpakete für alle Transaktionen,
sowohl online (rechnergebunden) als auch offline (rechnerunabhängig), sieht,
bevor sie die Pakete zur Ausgabebank/zum Ausgabegeldinstitut weiterleitet.
Demgemäss
entscheidet die zentrale Website, ob das Transaktionsdatenpaket
auf der Basis der vom Elternteil eingestellten Steuerungen über die
zentrale Website-Schnittstelle weiterzuleiten ist oder nicht. Das
SCCS wird nun unter Bezugnahme auf die 10 bis 24 beschrieben.
-
Bei 10 umfasst
das SCCS eine Benutzerschnittstelle 1002, ein Benutzermodem 1004,
einen zentralen Kontroller 1006 und eine zugeordnete Datenbanken
enthaltende Ausgabebankschnittstelle 1010, eine Ausgabebank-Netzwerkschnittstelle 1008,
eine Akquirierungsbankschnittstelle 1012, einen Offline-Händler, insbesondere
-Großhändler 1016 und
einen Online-Händler,
insbesondere -Großhändler 1014.
Die vorliegende Erfindung empfängt
eine CMDR (= conditional modification data request (bedingte Modifikationsdatenanforderung)) 1018 von
einem Benutzer, versucht die Anforderung zu bestätigen, und wenn die Anforderung
gültig
ist, aktualisiert sie lokale Untergeordnet-Kredit/Debit-Kartendaten
und sendet ein Aktualisierungssignal 1022 zur ausgebenden
Bank bzw. Ausgabebank 1010 der Karte. So kann ein Benutzer
von Ferne untergeordnet Kartenkontrollen wie beispielsweise Saldo-
und Transaktionsbeschränkungen
usw. über
die CMDR 1018 einstellen.
-
Wie
in der 10 gezeigt umfasst das SCCS
die Benutzerschnittstelle 1002, den zentralen Kontroller 1006,
die Ausgabebankschnittstelle 1010 und die Akquirierungsbankschnittstelle 1012.
Die oben genannten Komponenten des SCCS werden als „Knoten" bezeichnet. Jeder Knoten
ist beispielsweise über
eine Internetverbindung unter Verwendung eines öffentlichen Telefonnetzes wie
beispielsweise eines solchen, das von einer örtlichen oder regionalen Telefongesellschaft
bereitgestellt ist, verbunden. Die Verbindung kann auch durch dedizierte Datenleitungen,
zellulare Netzwerke, „PCS" (Personal Communication
Systems (Personalkommunikationssysteme)), Mikrowellen- oder Satellitennetzwerke usw.
bereitgestellt sein, wie es die Fachleute der relevanten Technik(en)
erkennen. Die Benutzerschnittstelle 1002 und Ausgabebankschnittstelle 1010 sind der
Eingabe- und Ausgabenetzübergang
bzw. -gateway für
Kommunikationen mit dem zentralen Kontroller 1006.
-
Unter
Verwendung der obigen Komponenten stellt die vorliegende Erfindung
ein Verfahren und System bereit, um Kartenhalter „Untergeordnetkartenkontrollen
(subordinate card controls)" wie
beispielsweise solche, die oben beschrieben sind, zu aktualisieren.
Wie in 11 gezeigt umfasst der Kontroller 1006 eine
zentrale Verarbeitungseinheit bzw. Zentraleinheit (Central Processing
Unit (CPU)) 1006g, einen Verschlüsselungsprozessor 1006c,
einen RAM 1006f, einen ROM 1006i, einen Bezahlungsprozessor 1006d,
einen Taktgeber 1006j, ein Betriebssystem 1006e,
eine Netzwerkschnittstelle 1006h und eine Datenspeichereinrichtung 1006k.
-
Als
der zentrale Kontroller 1006 kann ein konventioneller Personalcomputer
oder eine konventionelle Arbeitsstation mit ausreichendem Speicher- und
Verarbeitungsvermögen
benutzt werden. Bei einer Ausführungsform
arbeitet der zentrale Kontroller 1006 als ein Webserver,
der von Benutzern und/oder der zentralen Website erzeugte Daten
sowohl empfängt
als auch überträgt. Der
zentrale Kontroller 1006 muss typischerweise zur Hochvolumentransaktion und
Netzwerkverarbeitung fähig
sein, wodurch er eine beträchtliche
Anzahl mathematischer Berechnungen und Netzwerkoperationen bei Verarbeitungskommunikationen
und Datenbankabfragen ausführt.
-
Ein
Verschlüsselungs-
bzw. Kryptographikprozessor 1006c unterstützt die
Authentisierung von Kommunikationen zwischen den Knoten des SCCS sowie
von anonymen/sicheren Übertragungen
zwischen ihnen. Der Kryptographikprozessor 1006c kann auch
als Teil der CPU 1006g konfiguriert sein oder über Software
(beispielsweise unter Verwendung von PGP-Software (PGP = Pretty
Good Privacy) usw.) implementiert sein. Die Funktionen des Kryptographikprozessors 1006c werden
in Verbindung mit Verschlüsselungsauthentisierungs-Flussdiagrammen
der 21 bis 24 weiter
beschrieben.
-
Ein
Bezahlungsprozessor 1006d umfasst einen oder mehrere konventionelle
Mikroprozessoren (wie beispielsweise Intel Pentium III), der den
Transfer und den Austausch von Bezahlungen, Gebühren, Belastungen oder Debeten
bzw. sollseitigen Belastungen, die das Verfahren des Systems begleiten, unterstützen. Der
Bezahlungsprozessor 1006d kann auch als Teil der CPU 1006g konfiguriert
sein. Die Verarbeitung von Kredit/Debit-Kartentransaktionen durch
den Bezahlungsprozessor 1006d kann durch kommerziell erhältliche
Software unterstützt
sein.
-
Eine
Datenspeichereinrichtung 1006k kann eine Festplatte, magnetische
oder optische Speichereinheiten sowie CD-ROM-Laufwerke, Flash-Speicher
usw. aufweisen. Die Datenspeichereinrichtung 1006k enthält bei der
Verarbeitung von Transaktionen und Authentisierung benutzte Datenbanken
und enthält
beispielsweise Benutzerdaten 1006l, Ausgabebankdaten 1006n,
Formulardaten 1006o, Sitedaten 1006p, kryptographische
Schlüsseldaten 1006q, Zuordnungsdaten 1006r,
Transaktions/Bestätigungs-Daten 1006s,
eine Lizenznehmer/Teilnehmer-Datenbank 1006t und bedingte
Modifikationsdaten 1006m. Bei einer bevorzugten Ausführungsform wird
von der Oracle Corporation hergestellte Datenbanksoftware zum Erzeugen
und Verwalten der Datenbank 1006k benutzt.
-
Die
Benutzerdaten 1006l enthalten, wie oben unter Bezugnahme
auf die 1 bis 3 beschrieben,
Daten wie beispielsweise Namen eines Benutzers, Adresse, persönliche Information,
Anmelde- und Registrierungsinformation für alle verknüpften Sites
des Benutzers usw. Die Ausgabebankdaten 1006n enthalten
Daten wie beispielsweise Leitweglenkungsinformation in Bezug auf
Kommunikationen, Transaktionen usw. Die Formulardaten 1006o enthalten,
wie oben unter Bezugnahme auf die 1 bis 3 beschrieben,
Daten wie beispielsweise HTML-Formulardaten oder registrierte Websites
usw. Die Site-Daten 1006p enthalten, wie oben unter Bezugnahme
auf die 1 bis 3 beschrieben,
Daten wie beispielsweise Website-Namen und zugeordnete URLs usw.
Die kryptographischen Schlüsseldaten 1006q enthalten
Daten zur Erleichterung kryptographischer Funktionen, die sowohl
symmetrische als auch asymmetrische Schlüssel speichern, usw. Die als
die kryptographischen Schlüsseldaten 1006q gespeicherten
Schlüssel
werden vom Kryptographikprozessor 1006c zur Verschlüsselung
und Entschlüsselung
von Übertragungen
zwischen Knoten des SCCS benutzt. Die Zuordnungsdaten 1006r enthalten
Daten wie beispielsweise einen Namen eines Benutzers, Adresse usw.,
die, wie oben unter Bezugnahme auf die 1 bis 3 beschrieben,
dem oder den „Benutzervorlage"-Formularen des zentralen
Kontrollers zugeordnet und/oder darauf bezogen sind. Die Zuordnungsdaten 1006r enthalten
auch Daten wie beispielsweise eine Händler-, insbesondere Großhändler-ID-Nummer
und Daten für
Zuordnungen wie beispielsweise Verkaufsautomattyp usw. Mehrere Typen
von Zuordnungsdaten werden typischerweise zur Ausführung der
hier beschriebenen verschiedenen Ausführungsformen benutzt. Die Transaktions/Bestätigungsdaten 1006s enthalten Daten
wie beispielsweise Daten zur gesamten Führung der Zentralkontroller-Kredit/Debit-Karten-,
Benutzer- und Untergeordnungs-,
Transaktions/Bestätigungs-Aktivität usw. Die
Lizenznehmer/Teilhaber-Daten 1006t enthalten Daten wie
beispielsweise Daten zur Anmeldung von Lizenznehmer/Teilhaber-Namen, Identifikationsnummern
usw. und Daten zur Führung von
durch ein Vertragsverhältnis
gespeicherten Lizenznehmer/Teilhaber-Transaktionen mit der zentralen
Website. Die bedingten Modifikationsdaten 1006m enthalten
Daten wie beispielsweise Daten zur Anmeldung von Lizenznehmer/Teilhaber-Namen, ID-Nummern
usw. und Daten zur Durchführung
von durch ein Vertragsverhältnis
gespeicherten Lizenznehmer/Teilhaber-Transaktionen mit der zentralen Website.
-
Eine
Netzwerkschnittstelle 1006h ist als ein Gateway zum Kommunizieren
mit den Knoten des SCCS über
Signale 1102, die beispielsweise die Signale 1018, 1020, 1222, 1024 und 1026 der 10 enthalten,
vorhanden. Konventionelle interne oder externe Modems können als
die Netzwerkschnittstelle 1006h dienen. Die Netzwerkschnittstelle 1006h kann
Modems in einem Bereich von Baudraten von 1200 aufwärts aufweisen
und kann solche Eingaben in einer T1 oder T3-Leitung kombinieren,
wenn mehr Bandbreite erforderlich ist. Bei einer bevorzugten Ausführungsform
ist die Netzwerkschnittstelle 1006h mit dem Internet und/oder
irgendeinem der kommerziellen Onlinedienste wie beispielsweise America Online
oder das Microsoft-Network usw., die Benutzern und Ausgabebanken
einen Zugriff von einem weiten Bereich von Online-Kommunikationen
erlauben, verbunden. Alternativ dazu kann die Netzwerkschnittstelle 1006h als
eine Sprachmailschnittstelle, Website, BBS, Elektronikmailadresse
usw. konfiguriert sein.
-
Während die
e Ausführungsform
einen einzelnen Computer, der als ein zentraler Kontroller 1006 agiert,
beschreibt, realisieren die Fachleute der Technik, dass die Funktionalität über eine
Reihe von Computern verteilt sein kann. Bei einer Ausführungsform
ist der zentrale Kontroller 1006 in einer verteilten Architektur
konfiguriert, bei der die Datenbank 1006k und die Prozessoren 1006g, 1006c und 1006d in
separaten Einheiten oder Orten untergebracht sind. In einem solchen
Fall führen
gewisse Kontroller die primären
Verarbeitungsfunktionen aus und enthalten mindestens einen RAM,
ROM und einen generellen Prozessor. Jeder dieser Kontroller ist
bei einem WAN-Netzknoten bzw. -Hub angebracht, der als der primäre Kommunikationslink
zu den anderen Kontrollern und Schnittstelleneinrichtungen dienst.
Der WAN-Hub kann
selbst ein minimales Verarbeitungsvermögen aufweisen, das primär als ein
Kommunikationsleitweglenker bzw. -router dient. Den Fachleuten der
Technik ist klar, dass eine fast unbegrenzte Menge von Kontrollern
unterstützt
werden kann. Diese Anordnung ergibt ein flexibleres und dynamischeres System,
das weniger zu katastrophalen Hardwareausfällen, die das ganze System
beeinflussen, neigt. Die Hardware für diese Server wäre ähnlich wie
die für
den zentralen Kontroller 1006 beschriebene konfiguriert.
-
12 ist
ein Blockdiagramm zur Darstellung der Benutzerschnittstelle 1002 des
Systems der 10. Bei einer exemplarischen
Ausführungsform ist
die Benutzerschnittstelle 1002 ein konventioneller Personalcomputer,
der eine Eingabeeinrichtung 1002p wie beispielsweise eine
Tastatur, Maus oder konventionelles Spracherkennungssoftwarepaket, eine
Anzeigeeinrichtung wie beispielsweise einen Videomonitor 1002a und
eine Verarbeitungseinrichtung wie beispielsweise eine CPU 1002g aufweist.
Die Benutzerschnittstelle 1002 ist an eine Netzwerkschnittstelle
wie beispielsweise ein Modem 1004 gekoppelt. Die Einrichtung 1004 interagiert
mit dem zentralen Kontroller 1006 über Signale 1202,
die beispielsweise die Signale 1018 und 1020 des
Systems der 10 enthalten. Alternativ dazu
kann die Benutzerschnittstelle 1002 ein Sprachmailsystem,
ein elektronisches oder Sprachkommunikationssystem usw. sein. Wie
bei späteren
Ausführungsformen
beschrieben, sind auch Einrichtungen wie beispielsweise eine Faksimilemaschine,
ein zellulares Telefon, ein PDA, ein Pager usw. als eine Schnittstelleneinrichtung 1004 geeignet.
-
Wie
in 12 gezeigt, weist die Benutzerschnittstelle 1002 beispielsweise
eine Zentraleinheit (CPU) 1002g, einen RAM 1002f,
einen ROM 1002i, einen Taktgeber 1002j, einen
Videotreiber 1002b, einen Videomonitor 1002a,
einen Kommunikationsanschluss bzw. -port 1002m, eine Eingabeeinrichtung 1002p,
ein Betriebssystem 1002e, eine Biometrikeinrichtung 1002n,
einen Kryptographikprozessor 1002c und eine Datenspeichereinrichtung 1002k auf. Der
Kryptographikprozessor 1002c und die Biometrikeinrichtung 1002n sind,
wie später
beschrieben, zur Ausführung
von Authentisierungs- und Verschlüsselungsfunktionen enthalten.
Ein Pentium-Mikroprozessor der Intel Corporation kann als CPU 1002g und/oder
Grafikprozessor 1002c benutzt werden. Ein Taktgeber 1002j wie
beispielsweise ein chipbasierter Standardtaktgeber usw. ist vorhanden
und dient zu Zeitstempel- bzw. Zeitprotokolliermeldungen und anderen
Kommunikationen.
-
Das
Modem 1004 muss typischerweise keine Hochgeschwindigkeitsdatentransfers
aufweisen, da die meisten bedingten Modifikationen und Bestätigungen
kurze textbasierte Daten sind. Alternativ dazu kann die Benutzerschnittstelle 1002 eine
Netzwerkschnittstelle wie beispielsweise die bei 11 beschriebene
Netzwerkschnittstelle 1006h aufweisen. Die Datenspeichereinrichtung 1002k ist
eine konventionelle magnetbasierte Festplatten-Speichereinheit wie
beispielsweise ein von Western Digital hergestellte. Der Kryptographikprozessor 1002c kann ähnlich zu
den in 11 beschriebenen Prozessor 1006c sein.
Die Biometrikeinrichtung 1002n kann über spezialisierte Hardware,
Firmware und/oder Software implementiert sein und biometrische Funktionen
wie beispielsweise Spracherkennung, Retinaabtastung, Fingerabdruckerkennung usw.
ausführen.
-
13 ist
ein Blockdiagramm zur Darstellung der Ausgabebankschnittstelle 1010 des
Systems der 10. Bei einer exemplarischen
Ausführungsform
ist die Ausgabebankschnittstelle 1010 ein konventioneller
Personalcomputer oder eine Arbeitsstation mit ausreichendem Speicher-
und Verarbeitungsvermögen
und weist eine Verarbeitungseinrichtung wie beispielsweise eine
CPU 1010g auf, die an die Netzwerkschnittstelle 1008 gekoppelt
ist. Die Ausgabebankschnittstelle 1010 interagiert mit
dem zentralen Kontroller 1006 über die Netzwerkschnittstelle 1008 und
Signalleitungen 1302, die beispielsweise die Signale 1022 und 1024 der 10 enthalten.
Alternativ dazu kann die Ausgabebankschnittstelle auch über ein
Sprachmailsystem und ein elektronisches oder Sprachkommunikationssystem
usw. implementiert sein. Wie bei späteren Ausführungsformen beschrieben, sind
auch Einrichtungen wie beispielsweise eine Faksimilemaschine, ein
zellulares Telefon, ein PDA, ein Pager usw. als Schnittstelle 1008 geeignet.
-
Wie
in der 13 gezeigt weist die Ausgabebankschnittstelle 1010 eine
Zentraleinheit (CPU) 1010g, einen Kryptographikprozessor 1010g,
einen RAM 1010f, einen ROM 1010i, einen Bezahlungsprozessor 1010d,
einen Taktgeber 1010j, ein Betriebssystem 1010e und
eine Datenspeichereinrichtung 1010k auf. Die Ausgabebankschnittstelle 1010 ist
an die Netzwerkschnittstelle 1008 gekoppelt. Die oben genannten
Einrichtungen können ähnlich zu den
in Bezug auf die 11 und 12 beschriebenen
jeweiligen Einrichtungen sein.
-
Ein
herkömmlicher
Personalcomputer oder eine Arbeitsstation mit ausreichendem Speicher-
und Verarbeitungsvermögen
kann als die Ausgabebankschnittstelle 1010 benutzt werden.
Die Ausgabebankschnittstelle 1010 muss typischerweise zur Hochvolumentransaktion
und Netzwerkverarbeitung, die eine beträchtliche Anzahl von mathematischen Berechnungen
und Netzwerkoperationen bei Verarbeitungskommunikationen und Datenbankabfragen ausführt, fähig sein.
Die Datenspeichereinrichtung 1010k kann magnetische oder
optische Festplatten-Speichereinheiten sowie CD-ROM-Laufwerke, Flash-Speicher
usw. aufweisen. Die Datenspeichereinrichtung 1010k speichert
bei der Verarbeitung und Authentisierung von Transaktionen benutzte
Daten und enthält
beispielsweise Benutzerdaten 1010l, Ausgabebankdaten 1010m,
kryptographische Schlüsseldaten 1010n,
Transaktionsdaten 1010p und Master-Unterordnung-Kredit/Debit-Kartendaten 1010q.
-
Wie
in 14 gezeigt weist die Akquirierungsbankschnittstelle 1012 eine
Zentraleinheit (CPU) 1012g, eine Kryptographikprozessor 1012c, einen
RAM 1012f, einen ROM 1012i, einen Taktgeber 1012j,
einen Bezahlungsprozessor 1012d, ein Betriebssystem 1012e,
einen Videotreiber 1012, einen Videomonitor 1012a,
einen Online-Ausgabebankrouter 1406,
einen Offline-Ausgabebankrouter 1412, eine Sniffer/Snooper-Serversoftware
(Spürhund/Schnüffler-Serversoftware) 1012s und 1012v, Netzwerkschnittstellen 1408 und 1410,
Modems 1012t und 1012u und eine Datenspeichereinrichtung 1012k auf.
Die oben genannten Einrichtungen können ähnlich zu den unter Bezugnahme
auf die 11 bis 13 beschriebenen
jeweiligen Einrichtungen sein.
-
Ein
konventioneller Personalcomputer oder eine konventionelle Arbeitsstation
mit ausreichendem Speicher- und Verarbeitungsvermögen kann
als die Akquirierungsbankschnittstelle 1012 benutzt werden.
Die Akquirierungsbankschnittstelle 1012 muss typischerweise
zur Hochvolumentransaktions- und Netzwerkverarbeitung, die eine
beträchtliche
Anzahl von mathematischen Berechnungen und Netzwerkoperationen bei
der Verarbeitung von Kommunikationen und Datenbankabfragen ausführt, fähig sein.
-
Der
Bezahlungsprozessor 1012d weist einen oder mehrere konventionelle
Mikroprozessoren (wie beispielsweise Intel Pentium III), welche
den Transfer und Austausch von Bezahlungen, Gebühren und Debeten bzw. Debetbelastungen,
die das Verfahren des Systems begleiten, unterstützen. Der Bezahlungsprozessor 1012d kann
auch als Teil der CPU 1012g konfiguriert sein. Die Verarbeitung
von Kreditkartentransaktionen durch den Bezahlungsprozessor 1012d kann
durch kommerziell erhältliche
Software unterstützt
sein.
-
Die
Datenspeichereinrichtung 1012k kann magnetische oder optische
Festplatten-Speichereinheiten sowie CD-ROM-Laufwerke, Flash-Speicher usw. aufweisen.
Die Datenspeichereinrichtung 1012k speichert bei der Verarbeitung/Bestätigung von Transaktionen
und Authentisierung benutzte Daten und enthält Händlerinsbesondere Großhändlerdaten 1012l,
Ausgabebankdaten 1012m, kryptographische Schlüsseldaten 1012n,
Transaktions/Bestätigungs-Daten 1012o,
POS-Anschluss- bzw. -Endgerät-Identifizierungsdaten 1012p,
POS-Autorisierungs-Erfassungsdaten 1012q und
Austauschdaten 1012r.
-
Die
Händlerdaten 1012l enthalten
Daten wie beispielsweise eine Händleridentifikationsnummer, die
zum Identifizieren, welcher Händler,
insbesondere Großhändler eine
Kaufanforderung anfordert, benutzt wird, usw. Die Austauschdaten 1012r enthalten Daten
wie beispielsweise Bestätigung
einer abschließenden
Bezahlung einer Kaufanfrage, nachdem sie abgestimmt worden ist und
alle Parteien bezahlt sind usw. Diese Daten 1012r enthalten
Daten, die sich auf an die Ausgabebank(en) bezahlte Austauschgebühren zur
Bezahlung der Verarbeitung jeder Kreditkartentransaktion beziehen.
Die POS-Anschluss- bzw. POS-Endgerät-ID-Daten 12p enthalten
Daten, die zum Identifizieren eines POS-Anschlusses bzw. -Endgeräts, der
eine anfängliche
Transaktion anforderte, benutzt werden, usw. Die POS-Anschluss- bzw.
POS-Endgerät-ID-Nummer wird zum Zurücksenden
einer mit einem POS-Anschluss bzw. -Endgerät korrespondierenden Transaktions-Bestätigung/Zurückweisung
benutzt. Die POS-Autorisierungs-Erfassungsdatenbank 1012q enthält Daten wie
beispielsweise Elektronikdaten-Erfassungsdaten von einer POS-Einheit,
die eine elektronische Unterschriftenversion einer traditionell „unterzeichneten" Verkaufszeichnung
usw. darstellen.
-
Die
Ausgabebankrouter 1406 und 1412 werden von der
Akquirierungsbankschnittstelle zum Weiterleiten von Kredit/Debit-Kartenkaufanforderungen zum
zentralen Kontroller 1006 und/oder einer korrespondierenden
Ausgabebank zur Bezahlungsverarbeitung über die Signalleitungen 1402 und 1404,
die beispielsweise die Signale 1026 der 10 enthalten,
benutzt. Die Sniffer/Snooper-Serversoftware 1012s und 1012v kann
in der Akquirierungsbankschnittstelle 1012 als ein alternatives
Verfahren zur Weiterleitung der Kredit/Debit-Kartenkaufanforderungen
des zentralen Kontrollers 1006 für den zentralen Kontroller 1006 zur
Verarbeitung vorhanden sein.
-
Die
Betriebsweise des oben beschriebenen Systems wird nun unter Bezugnahme
auf die 15 bis 24 beschrieben.
Die vorliegende Erfindung bewirkt Kommunikationen zwischen einem
Benutzer und dem zentralen Kontroller 1006 über elektronische
Netzwerke, wobei der zentrale Kontroller 1005 als ein Webserver
agiert. Der Benutzer meldet sich beim zentralen Kontroller 1006 an,
erzeugt die CMDR 1018 und überträgt dann die CMDR 1018 zum zentralen
Kontroller 1006. Die CMDR 1018 wird vom zentralen
Kontroller 1006 empfangen und verarbeitet. Wenn die CMDR 1018 gültig ist,
aktualisiert der zentrale Kontroller 1006 die Unterordnungskarteninformation
und überträgt alle
nicht lokalen Änderungen
zur Ausgabebankschnittstelle 1010.
-
Bezugnehmend
auf die 15 ist dort ein Prozess beschrieben,
bei dem ein Benutzer eine CMDR 1018 formuliert und überträgt. Beim
Schritt 1502 meldet sich der Benutzer über das Benutzermodem 1004 und
die Benutzerschnittstelle 1002 beim zentralen Kontroller 1006 an,
wodurch ein Kommunikationenlink hergestellt wird. Es sei darauf
hingewiesen, dass der Benutzer eine Einzelperson, eine Gesellschaft,
eine Partnerschaft, eine Regierung oder jede andere Entität sein kann.
Es gibt viele kommerzielle Softwareanwendungen, welche die von der Ausgabebankschnittstelle 1010 oder
der Benutzerschnittstelle 1002 benötigten Kommunikationen ermöglichen.
Wenn der zentrale Website-Kontroller 1006 als ein Webserver
konfiguriert ist, kann konventionelle Kommunikationssoftware wie
beispielsweise der Internetexplorer-Webbrowser der Microsoft Corporation
usw. benutzt werden. Der Benutzer und die Ausgabebank können den
Internetexplorer-Browser zum Übertragen
der CMDR 1018 benutzen. Infolgedessen ist typischerweise
keine eigene bzw. Eigentumsoftware erforderlich.
-
Beim
Schritt 1504 wird auf dem Videomonitor 1002a der
Benutzerschnittstelle 1002 eine Webseite mit einem oder
mehreren Formularen angezeigt, wo der Benutzer Benutzerkarten- und/oder
Unterordnungskartensteuerungen anschaut und/oder konfiguriert. Ein
oder mehrere Formulare können
eine Kombination von Feldern, Listen, Markierungsfeldern (checkboxes),
andere Webseiten-Formularelemente usw.
aufweisen, die jeweils einen Zustand bzw. eine Bedingung der CMDR 1018 darstellen.
Wie durch das Element 1506 gezeigt, enthalten Kartensteuerungen
beispielsweise Aktivieren oder Desaktivieren einer oder mehrerer
Unterordnungskarten, personelle Benutzerinformation, Bilanz- bzw.
Saldodaten, Transaktionsdaten usw.
-
Beim
Schritt 1510 konfiguriert der Benutzer zusätzliche
Benutzerkarten- und/oder Unterordnungskartenbedingungen. Wie durch
das Element 1508 gezeigt, enthalten zusätzliche Bedingungen beispielsweise
Unterordnungskarten-Kreditbeschränkungen,
Protransaktionsgebührengrenzen, eine
Zahl von Transaktionen, die während
gegebener Zeitperiodengrenzen erlaubt ist, eine oder mehrere Händler, insbesondere
Großhändler/Verkäufer-Kontrollbeschränkungen
usw. Wenn einmal der Benutzer mit der CMDR 1018 zufrieden
ist, überträgt der Benutzer
die CMDR 1018 zum zentralen Kontroller 1006. Der
Benutzer tut dies beispielsweise durch Klicken auf einen „Übermittlungs"-Button, der sich
auf der Webseite, auf der er die CMDR 1018 erzeugte, befindet.
-
Anstelle
einer Web-basierten Schnittstelle kann ein Benutzer die CMDR 1018 über elektronische
Mail-, Sprachmail-, Faksimile- bzw. Fax-, Postsendungsübertragungen,
drahtlose Übertragungen, PDAs,
zellulare Übertragungen
usw. übertragen.
Mit einer Sprachmailübertragung
ruft der Benutzer den zentralen Kontroller 6 an und gibt die CMDR 1018 in Audioform
ab. Diese Anforderungen können
beim zentralen Kontroller 1006 in digitalen Text transkribiert
werden oder in ihrem originalen Format beibehalten werden. Bei einer
Postsendungsausführungsform
können
Anforderungen beim zentralen Kontroller 1006 in digitalen
Text transkribiert werden oder in ihrer originalen Form beibehalten
werden. Der CMDR 1018 kann auch bei Mailbox-Forum- bzw.
Schwarzes-Brett-Systemen
oder Webseiten, die vom zentralen Kontroller 1006 betrieben
werden, festgemacht werden. Der zentrale Kontroller 1006 unterstützt mehrere Übertragungsverfahren,
die eine breite Vielfalt von Übertragungsformaten
für die
CMDR 1018 erlauben. Gewisse Formate können jedoch vor einer weiteren
Verarbeitung durch den zentralen Kontroller 1006 geändert werden.
Die durch Postsendung in Papierform übertragene CMDR 1018 beispielsweise kann
unter Benutzung optischer Zeichenerkennungssoftware eingescannt
und digitalisiert werden, um digitalen Text zu erzeugen.
-
Beim
Schritt 1512 empfängt
der zentrale Kontroller 1006 die CMDR 1018 vom
Benutzer und versucht die CMDR 1018 des Benutzers beim
Schritt 1514 zu bestätigen.
Wenn festgestellt wird, dass der Benutzer nicht alle erforderlichen
Kriterien für
seine CMDR 1018 erfüllt,
oder wenn irgendein Attribut oder eine Bedingung der CMDR 1018 entweder
unklar ist oder Rechtschreib- und/oder Grammatikfehler enthält, wird
die CMDR 1018 beim Schritt 1516 abgelehnt und
zur Klärung
und/oder Korrektur zurückgeschickt,
und der Fehler wird in der Bedingtmodifikationsdatenbank 1006m angemeldet.
-
Wenn
jedoch festgestellt wird, dass die CMDR 1018 gültig ist,
führt der
zentrale Kontroller 1006 beim Schritt 1518 die
durch das Element 1520 gezeigten lokalen Änderungen
wie beispielsweise Kreditbeschränkungen,
Protransaktionsgebührbeschränkungen,
Zahl von Transaktionen innerhalb einer Periodengrenze usw. aus.
-
Beim
Schritt 1512 wird die CMDR 1018 in der Bedingtmodifikationsdatenbank 1006m angemeldet. Beim
Schritt 1524 verschlüsselt
der zentrale Kontroller 1006 Ausgabebankmodifikationen
in das Zentralkontrollersignal 1022. Beim Schritt 1528 wird
das Zentralkontrollersignal 1022 zur Ausgabebank übertragen.
-
Bezugnehmend
auf die 16 ist dort ein Prozess beschrieben,
durch den die Ausgabebankschnittstelle 1010 das vom zentralen
Kontroller 1006 gesendete Signal 1022 empfängt und
verarbeitet. Beim Schritt 1602 empfängt die Ausgabebank-Netzwerkschnittstelle 1008 das
die verschlüsselten
Modifikationsdaten enthaltende Signal 1022 vom zentralen
Kontroller 1006, und die Ausgabebankschnittstelle 1010 entschlüsselt es.
Beim Schritt 1604 extrahiert die Ausgabebankschnittstelle 1010 die
bedingten Modifikationsdaten vom entschlüsselten Signal 1022 des
zentralen Kontrollers 1006.
-
Beim
Schritt 1606 versucht die Ausgabebankschnittstelle 1010,
die Änderungen
vom Signal 1022 des zentralen Kontrollers 1006 zu
bestätigen. Exemplarische
Kriterien für Änderungen
sind durch das Element 1608 gezeigt, beispielsweise ob
der Benutzer eine ausreichende Kreditlinie bzw. -leitung hat, um
eine untergeordnete Karte zu modifizieren, ob ein Sessions-Zeit-Aus
aufgetreten ist usw. Beim Schritt 1610 wird festgestellt,
ob der Benutzer alle erforderlichen Kriterien für Modifikationen erfüllt oder nicht.
Wenn irgendein Attribut oder eine Bedingung der Modifikationen entweder
unklar ist oder Rechtschreib- und/oder
Grammatikfehler enthält,
werden beim Schritt 1612 die Modifikationen abgelehnt und wird
eine Fehler-Ausgabebankantwort 1024 zum zentralen
Kontroller 1006 zurückgeschickt,
und der zentrale Kontroller 1006 sendet eine geeignete
Antwort 1020 zum Benutzer.
-
Wenn
jedoch die Modifikationen gültig
sind, führt
die Ausgabebankschnittstelle 1010 beim Schritt 1614 die Änderungen
wie beispielsweise Kartensaldodatenhöhen für eine oder mehrere untergeordnete Karten,
Modifikationsanforderungs-Führungsnummer,
persönliche
Datenänderungen
usw. aus. Beim Schritt 1616 wird eine bestätigende
Ausgabebankantwort 1024 zum zentralen Kontroller 1006 übertragen,
und der zentrale Kontroller 1006 sendet eine geeignete
Antwort 1020 zum Benutzer.
-
17 ist ein Signaldiagramm zur Darstellung des
Formats des Signals 1020 bzw. 1022. Bei 17 enthält
das Signal 1020 bzw. 1022 beispielsweise ein Feld 1702 zur Übertragung
einer Primär- oder
Master-Kredit/Debit-Karten-Kontonummer,
ein Feld 1704 zur Übertragung
einer Untergeordnet-Kredit/Debit-Karten-Kontonummer, ein Feld 1706 zur Übertragung
von Bilanz- bzw. Saldomodifikationsänderungen für die untergeordnete Kredit/Debit-Karte, ein
Feld 1708 zur Übertragung
persönlicher
Datenänderungen
für die
untergeordnete Kredit/Debit-Karte, ein Feld 1710 zur Übertragung
der Identifikationsnummer des zentralen Kontrollers 1006,
ein Feld 1712 zur Übertragung
einer Modifikationsanforderungs-Führungsnummer. Obgleich ein
Signalformat nur für
das Signal 1022 bzw. 1020 gezeigt ist, können ähnliche
Signalformate für
die Signale 1018, 1020 bzw. 1022, 1024 usw.
benutzt werden, wie es die Fachleute der relevanten Technik(en)
erkennen.
-
18 ist ein Datenstrukturdiagramm zur Darstellung
eines von der Datenbank 1006k des zentralen Kontrollers 1006 benutzten
Datenstrukturformats. Bei 18 enthält die Datenstruktur
beispielsweise ein Feld 1802 zum Speichern einer Primär- oder
Master-Kredit-Debit-Karten-Kontonummer, ein Feld 1804 zum
Speichern einer Untergeordnet-Kredit/Debit-Karten-Kontonummer, ein Feld 1806 zum Speichern
gewünschter/bestätigter Bilanz-
bzw. Saldodatenhistorie für
die untegeordnete Kredit/Debit-Karte, ein Feld 1808 zum
Speichern von Persönlichdatenhistorie
für die
untergeordnete Kredit/Debit-Karte, ein Feld 1810 zum Speichern
einer Master-Zentralkontrollerbenutzer-Identifikationsnummer, ein
Feld 1812 zum Speichern der Untergeordnet-Kredit/Debit-Karten-Transaktions-Anforderungs/Bestätigungs-Datenhistorie,
ein Feld 1814 zum Speichern einer Untergeordnet-Zentralkontrollerbenutzer-Identifikationsnummer,
ein Feld 1816 zum Speichern von Masterbenutzerbeschränkungen
auf der untergeordneten Kredit/Debit-Karte und ein Feld 1818 zum Speichern
der Untergeordnet-Kredit/Debit-Karten-Kontrollhistorie auf. Obgleich ein Datenstrukturformat
nur für
die Datenbank 1006k gezeigt ist, können ähnliche Signalformate für die Datenbanken 1002k, 1010k, 1012 usw.
verwendet werden, wie es die Fachleute der relevanten Technik(en)
erkennen.
-
Bezugnehmend
auf die 19 ist dort ein Prozess beschrieben,
durch den eine Kredit/Debit-Karten-Kaufanforderung vom Online-Händler, insbesondere
-Großhändler 1014 zum
Kreditkartennetzwerk (repräsentiert
durch die Akquirierungsbankschnittstelle 1012) des SCCS-Benutzers
zur Online-Transaktionsbezahlungsverarbeitung gesendet wird. Bei 19 sendet der Online-Händler 1014 beim Schritt 1902 eine
einer Transaktion des zentralen Kontrollers 1006 zugeordnete
Kaufanforderung zur Akquirierungsbankschnittstelle 1012.
Beim Schritt 1904 empfängt
die Akquirierungsbankschnittstelle 1012 die Kaufanforderung
und leitet entweder die Kaufanforderung beim Schritt 1906 zum
zentralen Kontroller 1006 weiter oder sendet die Kaufanforderung
beim Schritt 1908 zum zentralen Kontroller 1006.
-
In
jedem Fall empfängt
der zentrale Kontroller 1006 beim Schritt 1906 die
leitweggelenkte bzw. geroutete oder weitergeleitete Anforderung
und versucht dann die Kaufanforderung zu bestätigen. Beim Schritt 1910 erlaubt
oder weist der zentrale Kontroller 1006 Käufe entsprechend
den durch das Element 1912 gezeigten Bedingungen/Vereinbarungen,
die vom „Master"-Benutzer bei der
bezüglich 15 ausführlich
behandelten Ausführungsform
eingegeben wird, zurück.
Wenn die Kaufanforderung beim Schritt 1914 die in der CMDR 1018 festgelegten
Bedingungen erfüllt,
wird die Anforderung beim Schritt 1920 zur Ausgabebankschnittstelle 1010 für das angeforderte
SCCS-Kartenkonto weitergeleitet. Wenn jedoch die Anforderung beim
Schritt 1914 die in der CMDR 1018 festgelegten
Bedingungen nicht erfüllt, wird
beim Schritt 1916 die Kaufanforderung abgelehnt, und beim
Schritt 1918 wird eine Zurückweisungsfehlermeldung zu
allen interessierten Parteien (siehe Schritt 1930, Schritt 1926 bzw.
Schritt 1922) gesendet.
-
Beim
Schritt 1924 empfängt
und verarbeitet die Ausgabebankschnittstelle 1010 die Bezahlung der
Kaufanforderung unter Verwendung bekannter Verfahren zur Verarbeitung
von Kreditkartentransaktionen. Nach Verarbeitung der Kaufanforderung
und Geben einer Bestätigungsnummer
sendet die Ausgabebank-Netzwerkschnittstelle 1008 beim
Schritt 1928 eine Transaktionsbestätigung zu allen interessierten
Parteien (siehe Schritt 1930, Schritt 1926 bzw.
Schritt 1922).
-
Bezugnehmend
auf die 20 ist dort ein Prozess beschrieben,
durch den eine Kreditkartenkaufanforderung von einem Offline-Händler, insbesondere
-Großhändler zum
Kreditkartennetzwerk (repräsentiert
durch die Akquirierungsbankschnittstelle 1012) des SCCS-Benutzers
für eine
Offline-Transaktionsbezahlungsverarbeitung gesendet. In 20 ist das SCCS-Offline-Transaktionsbezahlungsverfahren, bis
auf einen zusätzlichen
Schritt, dem Schritt 2032, ähnlich zu dem in 19 beschriebenen Verfahren. Außerdem zeigen beim Offline-Transaktionsbezahlungsverfahren
die Schritte 2002, 2022, 2032 und 2026 die
zusätzliche
Rolle der POS-Verarbeitung und des POS-Anschlusses bzw. -Endgeräts, die bei
den Offline-Kreditkartenbezahlungsprozeduren benutzt
werden. Die verbleibenden Details der Schritte des Offline-Transaktionsbezahlungsverfahrens
sind der Kürze
wegen fortgelassen.
-
Bei
den en Ausführungsformen
involviert die Authentisierung eines Benutzers und einer Ausgabebank
ein Prüfen
einer beigefügten
Identifikation oder eines beigefügten
Namens und einen Vergleich der Identifikation oder des Namens mit
denen der gespeicherten Benutzerdaten 1006l und der Ausgabebankdaten 1006n der
Datenbank 1006k des zentralen Kontrollers 1006.
Obgleich diese Prozedur gut in einer Umgebung mit niedriger Sicherheit
arbeitet, kann sie durch die Benutzung von Verschlüsselungs-
bzw. Kryptographikprotokolle signifikant verbessert werden. Diese
Protokolle verbessern nicht nur die Fähigkeit zum Authentisieren
eines Senders einer Nachricht, sondern auch zum Verifizieren der
Integrität
einer Nachricht selbst, zur Verifizierung, dass die Nachricht nicht
durch eine nicht autorisierte Partei geändert worden ist. Bei Verwendung
solcher Kryptographikprotokolle wird eine nicht autorisierte Partei daran
gehindert und ist nicht fähig,
einen Benutzer zu personifizieren.
-
Eine
Verschlüsselung
kann auch Horcher daran hindern, die Inhalte einer Nachricht zu
lernen. Infolgedessen kann durch Verwendung solcher Kryptographikprotokolle
eine nicht autorisierte Partei daran gehindert werden, beispielsweise
Nachrichten, die zu/von dem zentralen Kontroller 1006,
der Benutzerschnittstelle 1002, der Ausgabebankschnittstelle 1010,
der Akquirierungsbankschnittstelle 1012 usw. gesendet werden,
zu inspizieren. Solche Techniken seien generell als kryptographische
Sicherungsverfahren bezeichnet und umfassen die Benutzung sowohl
symmetrischer als auch asymmetrischer Schlüssel sowie digitaler Signaturen
und Hash-Algorithmen, die bei der oder den kryptographischen Techniken
bekannt sind. Die Praxis der Benutzung kryptographischer Protokolle
zum Sicherstellen der Authentizität von Sendern sowie der Integrität von Nachrichten
ist in der Technik wohlbekannt und wird hier der Kürze wegen
nicht detailliert beschrieben.
-
21 ist ein Flussdiagramm zur Beschreibung eines
kryptographischen Symmetrischschlüsselverfahrens, bei dem sich
der zentrale Kontroller 1006 und die Ausgabebankschnittstelle 1010 einen Schlüssel gemeinsam
teilen. Infolgedessen werden sowohl die Verschlüsselung als auch Entschlüsselung
der Ausgabebankantwort 1024 mit dem gleichen Schlüssel ausgeführt. Diese
Verschlüsselung
kann mit jedem bekannten Verschlüsselungsalgorithmus wie
beispielsweise DES (U.S. Government Standard (US-Regierungsstandard)), EDEA, Blowfish,
RC2, RC4, SAFER usw. ausgeführt
werden. In 21 verschlüsselt beim Schritt 2102 die
Ausgabebankschnittstelle 1010 die Ausgabebankantwort 1024 mit dem
zugeordneten symmetrischen Schlüssel
unter Verwendung des Kryptographikprozessors 1010g der
Ausgabebankschnittstelle 1010. Der Schlüssel wird beispielsweise als
die kryptographischen Schlüsseldaten 1010n der
Ausgabebankschnittstelle 1010 gespeichert. Die verschlüsselte Antwort 1024 wird
dann beim Schritt 2104 durch die Ausgabebank-Netzwerkschnittstelle 1008 zum
Kryptographikprozessor 1006c des zentralen Kontrollers 1006 übertragen.
Der Kryptographikprozessor 1006c extrahiert beim Schritt 2106 die
Ausgabebank-ID von der Ausgabebankantwort 1024 und schlägt beim Schritt 2108 den
symmetrischen Schlüssel
der Ausgabebank über
die kryptographischen Schlüsseldaten 1006q nach
und entschlüsselt
beim Schritt 2110 die Ausgabebankantwort 1024 mit
diesem Schlüssel. Die
kryptographischen Schlüsseldaten 1010n und 1006q enthalten Algorithmen
und Schlüssel
zur Verschlüsselung,
Entschlüsselung
und/oder Authentisierung von Nachrichten. Wenn beim Schritt 2122 die resultierende
Nachricht verständlich
ist, dann muss der gleiche Schlüssel
die Nachricht verschlüsselt
haben, was authentisiert, dass die Ausgabebankschnittstelle 1010 in
der Tat der Autor der Ausgabebankantwort 1024 gewesen sein
muss.
-
Die
obige Prozedur macht es für
eine nicht autorisierte Ausgabebank oder einen nicht autorisierten
Benutzer beträchtlich
schwieriger, eine legimitierte Ausgabebank zu repräsentieren.
Ohne kryptographische Prozeduren wäre eine nicht autorisierte
Ausgabebank, die eine abgetastete Ausgabebankantwort 1024 von
einer legitimierten Ausgabebank erhielt, fähig, die Ausgabebank-Identifikationsnummer bzw.
Ausgabebank-ID-Nummer zu extrahieren und dann diese ID-Nummer nicht
autorisierten Rusgabebankantworten beizufügen. Wenn jedoch die Ausgabebankantwort 1024 mit
einem symmetrischen Schlüssel
verschlüsselt
worden ist, entdeckt eine nicht autorisierte Ausgabebank, die eine
abgetastete Ausgabebankantwort 1024 erhält, nur die ID-Nummer der Ausgabebank
und nicht den symmetrischen Schlüssel.
Ohne diesen Schlüssel
kann die nicht autorisierte Ausgabebank nicht eine Ausgabebankantwort
erzeugen, die nicht vom zentralen Kontroller 1006 entdeckt
werden kann, da sie seine Nachricht nicht in der gleichen Weise
verschlüsseln
kann, wie es die autorisierte Ausgabebank könnte. Das Symmetrischschlüsselprotokoll
stellt auch sicher, dass die Ausgabebankantwort 1024 während der Übertragung
nicht beeinflusst worden ist, da eine Änderung der Nachricht die Kenntnis
des symmetrischen Schlüssels
erfordert. Eine verschlüsselte
Ausgabebankantwort 1024 verleiht der Ausgabebank auch mehr
Anonymität.
-
Nun
auf 22 Bezug nehmend ist dort ein Flussdiagramm
für ein
asymmetrisches Schlüsselprotokollverfahren
gezeigt, bei dem die Ausgabebankantwort 1024 mit einem
privaten Schlüssel
verschlüsselt
und mit einem öffentlichen
Schlüssel entschlüsselt wird.
Zwei solche Algorithmen für
diese Prozedur sind beispielsweise RSA und Digital Signature Algorithm
(DSA). In 22 verschlüsselt die Ausgabebankschnittstelle 1010 beim
Schritt 2202 die Ausgabebankantwort 1024 mit einem
privaten Schlüssel
unter Verwendung des Kryptographikprozessors 1010c der
Ausgabebankschnittstelle 1010. Die verschlüsselte Ausgabebankantwort 1024 wird dann
beim Schritt 2204 zum Kryptographikprozessor 1006c des
zentralen Kontrollers 1006 übertragen. Der Kryptographikprozessor 1006c extrahiert
beim Schritt 2206 die Ausgabebank-ID von der Ausgabebankantwort 1024 und
schlägt
beim Schritt 2208 den als die kryptographischen Schlüsseldaten 1006q gespeicherten
zugeordneten öffentlichen
Schlüssel
der Ausgabebank nach und entschlüsselt
beim Schritt 2210 die Ausgabebankantwort 1024 mit
dem öffentlichen
Schlüssel.
Wie vorher hat, wenn die Ausgabebankantwort 1024 verständlich ist,
der zentrale Kontroller 1006 die Ausgabebankantwort authentisiert. Wieder
ist eine nicht autorisierte Partei, welche die Ausgabebankantwort 1024 erhält, bevor
sie vom zentralen Kontroller 1006 erhalten wird, nicht
fähig, die
Ausgabebankantwort 1024 nicht detektierbar zu ändern, da
die nicht autorisierte Partei typischerweise den privaten Schlüssel der
Ausgabebank nicht kennt. Die nicht autorisierte Partei wäre jedoch
fähig, die
Ausgabebankantwort 1024 zu lesen, wenn die nicht autorisierte
Partei es Zustande brächte,
den öffentlichen
Schlüssel
der Ausgabebank zu erhalten. Nachrichtengeheimhaltung wird jedoch
aufrechterhalten, wenn die Ausgabebankschnittstelle 1010 die Ausgabebankantwort 1024 mit
einem öffentlichen Schlüssel verschlüsselt, der
erfordert, dass der Angreifer den privaten Schlüssel der Ausgabebank kennt,
um die Ausgabebankantwort 1024 anzuschauen.
-
23 ist ein Flussdiagramm zur Darstellung einer
kryptographischen Technik, die digitale Signaturen zur Bereitstellung
von Authentifizierung und Nachrichtenintegrität benutzt. Ein solcher Algorithmus
ist beispielsweise DSA, der im FIPS PUB 186 spezifizierte
U.S. Government Standard. Wie bei dem oben beschriebenen asymmetrischen
Protokoll weist jede Ausgabebank einen zugeordneten öffentlichen
und privaten Schlüssel
auf. Bei 23 signiert beim Schritt 2302 die
Ausgabebankschnittstelle 1010 über den Kryptographikprozessor 1010c die
Ausgabebankantwort 1024 mit einem privaten Schlüssel und überträgt beim
Schritt 2304 die signierte Ausgabebankantwort 1024 zum
zentralen Kontroller 1006. Der Kryptographikprozessor 1006c des
zentralen Kontrollers 1006 extrahiert beim Schritt 2306 die
Ausgabebank-ID und schlägt
beim Schritt 2308 den als die kryptographischen Schlüsseldaten 1006q gespeicherten
zugeordneten öffentlichen
Schlüssel
der Ausgabebank nach und verifiziert beim Schritt 2310 die
Signatur unter Verwendung der Ausgabebankantwort 1024 und
des öffentlichen
Schlüssels
der Ausgabebank. Wenn die Ausgabebankantwort 1024 verständlich ist,
akzeptiert der zentrale Kontroller 1006 beim Schritt 2312 die
Ausgabebankantwort 1024 als authentisch.
-
24 ist ein Flussdiagramm zur Beschreibung einer
kryptographischen Technik, die ein Hash-Protokollverfahren zur Verifizierung
der Authentizität
und Integrität
der Antwort 1024 der Ausgabebankschnittstelle 1010 benutzt.
Beim Hash-Protokollverfahren teilen sich die Ausgabebankschnittstelle 1010 und
der zentrale Kontroller 1006 gemeinsam einen symmetrischen
Schlüssel,
den beim Schritt 2402 die Ausgabebankschnittstelle 1010 in
einem Hash (Haschee) der Ausgabebankantwort 1024 enthält. Im Hash-Protokoll wird auf
eine digitale Darstellung der Ausgabebankantwort 1024 eine
Einwegfunktion angewendet, die einen Code erzeugt, der sehr stark
wie ein Fingerabdruck der Ausgabebankantwort 1024 wirkt.
Bei dem vorliegenden Verfahren kann jeder bekannte Hashing-Algorithmus
wie beispielsweise MAC-basierte Algorithmen usw. (beispielsweise
RIPE-MAC- IBC-Hash,
CBC-MAC usw.) angewendet werden. Nachdem beim Schritt 2404 die Ausgabebankantwort 1024 zum
zentralen Kontroller 1006 übertragen ist, extrahiert der
Kryptographikprozessor 1006c beim Schritt 2406 die
Ausgabebank-ID von der Ausgabebankantwort 1024. Dann schlägt beim
Schritt 2408 der Kryptographikprozessor 1006c den
als die kryptographischen Schlüsseldaten 1006q gespeicherten
symmetrischen Schlüssel
der Ausgabebank nach, hashiert beim Schritt 2410 die Ausgabebankantwort
mit dem symmetrischen Schlüssel und
vergleicht beim Schritt 2412 den resultierenden Hashwert
mit dem der Ausgabebankantwort 1024 beigefügten Hashwert.
Wenn die Hashwerte übereinstimmen
ist die Integrität
der Ausgabebankantwort 1024 zusammen mit der Authentisierung
der Ausgabebank verifiziert.
-
Obgleich
die en kryptographischen Verfahren die Authentisierung und Gültigkeit
der Ausgabebankantwort 1024 beschreiben, können diese
Verfahren ebenso auf die Authentisierung und Gültigkeit von Bestätigungsnachrichten,
Fehlernachrichten oder alle anderen Nachrichten und Kommunikationen
von/zu der Benutzerschnittstelle 1002, dem zentralen Kontroller 1006,
der Ausgabebankschnittstelle 1010, der Akquirierungsbankschnittstelle 1010 usw. (beispielsweise
die Signale 1018, 1020, 1022, 1026 usw.)
angewendet werden, wie die Fachleute der relevanten Technik(en)
erkennen.
-
Obgleich
kryptographische Techniken eine größere Vertraulichkeit bei der
Authentizität
von Nachrichten zwischen Knoten des SCCS bereitstellen können, sind
solche Techniken nutzlos, wenn die kryptographischen Schlüssel bloßgestellt
werden. Wenn die kryptographischen Schlüssel bloßgestellt werden, gibt es keinen
Weg, zu verifizieren, ob ein autorisierter Benutzer der wahre Autor
einer Nachricht war oder ob die Nachricht von einer nicht autorisierten
Partei, die bloßgestellte
kryptographische Schlüssel
benutzt hat, übertragen
wurde. Ein Weg zur Lösung
dieses Problems ist, Biometrikeinrichtungen wie beispielsweise Fingerabdruckleser,
Spracherkennungssysteme, Retinaabtaster usw. zur weiteren Verifizierung
der wahren Identität
eines Benutzers zu benutzen. Diese Einrichtungen nehmen ein physikalisches
Attribut des Benutzers in ihre Nachricht auf, das dann mit dem in
einer beispielsweise beim zentralen Kontroller 1006 lokalisierten
Datenbank gespeicherten Wert verglichen wird. Bei der vorliegenden
Erfindung können
solche Einrichtungen der Benutzerschnittstelle 1002 hinzugefügt werden. Eine
Fingerabdruckverifikation kann beispielsweise vor der Erzeugung
der CMDR 1018 in Reaktion auf Auforderungen vom zentralen
Kontroller 1006 oder in einer gewissen anderen vorbestimmten
oder zufälligen
Zeit ausgeführt
werden. Beispielsweise wird jeder lebend abgetastete Fingerabdruck
mit einer vorher gespeicherten Vorlage, die in der Datenspeichereinrichtung 1002k der
Benutzerschnittstelle 1002 gespeichert ist, verglichen,
und wenn die Abdrücke nicht übereinstimmen,
wird die CMDR 1018 abgelehnt.
-
Bei
einer Sprachverifikationsausführungsform
wird die Stimme des Benutzers zum Verifizieren der wahren Identität des Benutzers
benutzt. Diese Ausführungsform
hat den Vorteil, dass sie nicht die Benutzung einer spezialisierten
Hardware benötigt, da
sie über
eine Standardtelefonverbindung implementiert werden kann. Die Identität des Benutzers wird
beim zentralen Kontroller 1006 verifiziert. Der Prozess
der Gewinnung eines Sprachabdrucks und seine nachfolgende Benutzung
zum Verifizieren der Identität
einer Person ist in der Technik wohlbekannt und braucht hier der
Kürze wegen
nicht detailliert beschrieben zu werden. Jede ohne eine geeignete Sprachübereinstimmung
empfangene CMDR 1018 wird abgelehnt.
-
Obgleich
die oben beschriebenen biometrischen Verfahren die Authentisierung
und Validierung der CMDR 1018 beschreiben, können solche
Verfahren ebenso zur Authentisierung und Validierung von Bestätigungsnachrichten,
Fehlernachrichten oder alle anderen Nachrichten und Kommunikationen von/zu
der Benutzerschnittstelle 1002, dem zentralen Kontroller 1006,
der Ausgabebankschnittstelle 1010, der Akquirierungsbankschnittstelle 1010 usw.
(beispielsweise die Signale 1018, 1020, 1022, 1026 usw.)
angewendet werden, wie es die Fachleuten der relevanten Technik(en)
erkennen.
-
Wie
oben erwähnt
sorgt die vorliegende Erfindung für die Anonymität sowohl
eines Benutzers als auch einer Ausgabebank.
-
Eine
solche Anonymität
wird durch Eliminierung aller Hinweise auf die tatsächlichen
Namen der involvierten Parteien für alle Transaktionen ausgeführt. Ein
Benutzer würde
beispielsweise seine ID in die CMDR 1018 anstelle seines
Namens einbringen, was verhindert, dass Hacker die wahre Identität des Benutzers
entdecken. Auf ähnliche
Weise können auch
Ausgabebanken ihre Identität
als Geheimnis bewahren wollen. Obgleich die Benutzung von ID-Nummern
für Anonymität sorgen
kann, gibt es eine Anzahl potentieller Schwächen. Als erstes wird, wenn
die Datenbank der ID-Nummern, die als Benutzerdaten 1006l oder
die Ausgabebankdaten 1006n gespeichert sind, bloßgestellt
werden, die Anonymität
zerstört,
da der Nachrichtenabsender über
die Benutzerdaten 1006l oder die Ausgabebankdaten 1006n nachgeschlagen
werden kann. Um dies zu verhindern, werden alle Daten mit einem öffentlichen Schlüssel des
zentralen Kontrollers 1006 verschlüsselt, so dass, selbst wenn
solche Daten gestohlen werden, sie ohne einen privaten Schlüssel nutzlos sind.
Auf ähnliche
Weise können ähnlich alle
von der Benutzerschnittstelle 1002, der Ausgabebankschnittstelle 1010 und
der Akquirierungsbankschnittstelle 1012 gespeicherten Daten
vor der Speicherung verschlüsselt
werden.
-
Generelle Merkmale bzw.
Eigenschaften der vorliegenden Erfindung
-
Das
oben beschriebene System verleiht einem Benutzer die „Macht" darüber, wann
und wie oft genau die Finanzen des Benutzers auf dem Internet aktiv
sind und gibt Eltern die Kontrolle über Online- und Offline-Transaktionen
ihrer Kinder. Die Online-Kredit/Debit-Kartenkontonummer der zentralen Website
kann typischerweise nur für
Online-Käufe bei
E-Commerce-Sites und bei Kreditkartendienst-Websites benutzt werden,
und hat typischerweise keine Realweltanwendung. Dies deshalb, um die
Benutzung dieser neuen Online-Kredit/Debit-Kartenkontonummern bei
allen Arten von Betrug zu verhindern. Wann immer die Online-Kredit/Debit-Kartenkontonummern
gestohlen werden, so sind sie im Wesentlichen nutzlos, da der Dieb
nie wirklich weiß, wann
immer die Online-Kredit/Debit-Kartenkonten „aktiv" sind und/oder wie viel Geld darin verfügbar ist.
-
Mit
dem Online-Kredit/Debit-Kartenkontosystem hat der Benutzer eine
akzeptables Risikohöhe
während
E-Commerce-Transaktionen.
Die Fähigkeit,
die Vertraulichkeit eines Benutzers zu schützen und das Risiko der finanziellen
Bloßstellung
während E-Commerce-Transaktionen
zu begrenzen, resultiert im Wachstum von E-Commerce aufgrund der
durch die vorliegende Erfindung gebotenen erhöhten Sicherheit. Demgemäss erzeugt
das Online-Kredit/Debit-Kartenkontosystem gemäß der vorliegenden Erfindung,
aufgrund des dem Endbenutzer gegebenen neuen Sicherheitsgefühls, mehr
neue Kreditkartenkonten für
das oder die Geldinstitute, die das Online-Kredit/Debit-Kartenkontosystem
unterstützen.
-
Da
gemäß gewissen
Ausführungsformen
der vorliegenden Erfindung typischerweise keine tatsächlichen
Kredit/Debit„Karten" hergestellt werden müssen, kann
das von der Eliminierung der Notwendigkeit, Karten herzustellen,
gesparte Geld zum Helfen benutzt werden, für die Entwicklungskosten zu bezahlen,
die involviert sind, um die „Aktualisierungsdatei" der zentralen Website
mit der eigenen Datenbanktabelle von Konten jedes Geldinstituts
zu koordinieren.
-
Wenn
ein Benutzer nicht schon ein Online-Kredit/Debit-Kartenkonto bei der zentralen Website
hat, muss der Benutzer ein solches Konto einrichten, um Vorteil
aus den Website-Dienst-
und Kredit/Debit-Kartenkontoschutzvorteilen zu ziehen. Nachdem das
Online-Kredit/Debit-Kartenkonto eingerichtet ist, muss der Benutzer
diese neue Online-Kredit/Debit-Kartenkontonummer
nicht bei neuen E-Commerce-, Kreditkarten- und Auktions-Sites oder den
bevorzugten Websites des Benutzers niederschreiben, registrieren
oder erneut registrieren. Die Datenbank und Dienstsoftware der zentralen
Website lösen
diese Probleme für
alle Benutzer mittels des Benutzer-„Vorlage"-Registrierungsmerkmals, wie es in Bezug
auf die 1 und 2 beschrieben
ist.
-
Wenn
der Benutzer schon eine persönliche Webseite
bei der zentralen Website hat, wird die Bilanz- bzw. Saldoinformation
und Kontonummer des neuen Online-Kredit/Debit-Kartenkontos
des Benutzers mit der persönlichen
Webseite des Benutzers in der Datenbank 122 querverwiesen
und codiert. Durch Benutzung dieser Online-Kredit/Debit-Kartenkontonummern
anstelle einer oder mehrerer tatsächlicher Kredit/Debit-Kartenkontonummern
des Benutzers kann die zentrale Website ihre Dienste durch Registrierung
des Benutzers bei Websites, die Kreditkarteninformation erfordern,
ohne Verletzung der Sicherheit der wahren persönlichen finanziellen Kredit/Debit-Karteninformation
des Benutzers vervollständigen.
-
Die
zentrale Website behält
typischerweise nicht aktuelle Kredit/Debit-Kartenkontoinformation, die
zum Registrieren von Benutzern bei Websites, die solche Information
benötigen,
um ihre Dienste (beispielsweise E-Commerce- und Online-Auktions-Sites)
anzumelden und zu benutzen, notwendig sind, zurück. Die zentrale Website erzeugt
jedoch typischerweise Links mit dem Namen und Passwörtern des
Benutzers, die solche Benutzer schon bei diesen Typen von Sites
erzeugt haben. Die zentrale Website zieht typischerweise nicht vor,
aktuelle Kreditkartennummerinformation von Benutzern als Teil einer Dienstmethode
bzw. -politik zu halten, da die zentrale Website typischerweise
nicht die Sicherheit solcher Information, die von Benutzern ausgewählten Websites
bereitgestellt worden ist, garantieren kann. Das Online-Kredit/Debit-Kartenkonto
wird eingerichtet, um Benutzern die Ermächtigung zu ermöglichen,
die gleichen Ausgabefähigkeiten
und Onlinefähigkeiten zu
haben, die eine Kredit/Debit-Karte bereitstellt, ohne dass gleichzeitig
die Sicherheit ihrer persönlichen
finanziellen Information verletzt wird.
-
Die
zentrale Website hat typischerweise die exklusive Aufrechterhaltung
der Saldoinformation und ist der einzige Eigentümer der Bilanz- bzw. Saldoinformation
für die
Online-Kredit/Debit-Guthabenkartenkonten
des Benutzers und für Schirme
oder Fenster, die in persönlichen
Webseiten des Benutzers bereitgestellt sind. Demgemäss besteht,
da die aktuelle persönliche
Kredit/Debit-Karteninformation schon bei dem oder den Geldinstituten,
welche die Kredit/Debit-Karten ausgeben, gehalten wird, keine Notwendigkeit
für irgendein
anderes Institut, diese Daten, insbesondere Websites, zu haben.
Mit dem Online-Kredit/Debit-Kartenkontosystem gemäß der vorliegenden
Erfindung kennt, anders als die eigene Bank oder das eigene Geldinstitut
des Benutzers, niemand (anderer als ein Benutzer) die aktuelle Kredit/Debit-Karteninformation
des Benutzers.
-
Die
Online-Kredit/Debit-Kartenkontonummer kann typischerweise nur für Online-Käufe bei
Websites und bei Kredit/Debit-Kartendienstwebsites benutzt werden
und hat typischerweise keine andere Realweltanwendung. Dieses Merkmal
schützt
den Gebrauch dieser neuen Online-Kredit/Debit-Kartenkontonummern bei Haupttypen von
Betrug wie beispielsweise Mailordnungskatalogbetrug und Kreditkartenbetrug.
Die zentrale Website unterstützt
Benutzer auch dabei, beim Online-Kredit/Debit-Guthabenbelastungskartenkonto nur soviel
Geld anzulegen, wie sie bei jeder Online-E-Commerce-Bestimmung gerade
daran sind, auszugeben. Dieses Merkmal minimiert stark die während Online-E-Commerce-Transaktionen
einem Risiko ausgesetzte Geldmenge. Sollten außerdem die Online-Kredit/Debit- oder
Guthabenbelastungskartennummern jemals gestohlen werden, würde der
Dieb typischerweise niemals exakt wissen, wann im Online-Kredit/Debit-Kartenkonto
auszugebendes Geld wäre
oder wann das Online-Kredit/Debit- oder Guthabenbelastungskartenkonto
aktiv ist, um Belastungen zu akzeptieren.
-
Es
gibt sehr positive die Beziehung zur Öffentlichkeit betreffende Vorteile
bezüglich
der Unterstützung
des Online-Kredit/Debit-Kartenkontosystems
gemäß der vorliegenden
Erfindung, die es einem Benutzer ermöglichen, sicher zu sein, während er
online Geld ausgibt. Es ist eine minimale Entwicklungszeit notwendig,
um das Online-Kredit/Debit- Kartenkontosystem
gemäß der vorliegenden
Erfindung zu starten, da der Dienst mit einer existierenden Architektur
verbunden ist, die schon von den Geldinstituten, die das Online-Kredit/Debit-Kartenkontosystem
unterstützen,
entwickelt worden ist. Außerdem
funktioniert das Online-Kredit/Debit-Kartenkontosystem
gemäß der vorliegenden
Erfindung mit existierender Technologie bzw. Technik, die E-Commerce-Websites
zum Online-Bearbeiten von Kredit/Debit-Kartentransaktionen benutzen.
-
Das „syntaktische
Analysieren (parsing)" verschiedener
Daten und Dateien (beispielsweise der Aktualisierungsdateien 410, 414 und 608,
Bestimmungswebsite-Registrierungsformulare usw.) im Kredit/Debit-Kartenkontosystem
gemäß der vorliegenden
Erfindung wird wie folgt weiter beschrieben. Beispielsweise stellt
das auf dem Computer laufende Formularverwaltungssystem (form management
system (FMS)) eine TCP/IP-Verbindung mit einer auf einem zweiten
Computer laufenden Bestimmungswebsite her. Das FMS macht eine HTTP-Anforderung bzw.
-Anfrage an die Website und erhält
eine HTML-Seite von der Website als eine Textkette zurück. Diese
Textkette, welche die HTML-Seite ist, wird dann syntaktisch analysiert.
Der syntaktische Analysierungscode extrahiert vom HTML-Formular spezifische
Kennzeichen aus der Textkette durch Anwendung von beispielsweise
regelbasierten Verfahren wie durch den WWW HTML-Standard. Der syntaktische
Analysierungscode speichert dann die Formularkennzeichendaten in
eine als ein Array bekannte Sammlung von Daten. Die Daten in diesem
Array werden dann in die Datenbank 122 durch einen datenbankspezifischen
Code eingegeben, der regelbasierte Verfahren anwendet, um sicherzustellen,
dass Daten in der richtigen Datenbanktabelle gespeichert werden.
-
Syntaktisches
Analysieren ist eine Methodologie bzw. Methode, bei der ein Programm
Zeichen um Zeichen durch Text iteriert, um gewisse Textketten (Wörter) zu
extrahieren, wie sie durch Programmregeln spezifiziert sind. Der
HTML-Syntaxanalysierer (HTML-parser)
der zentralen Website wird aktualisiert gehalten, so dass die Regeln
konsequent dem W3- Konsortium-HTML-Standard
(W3 consortium HTML standard) treu bleiben, wenn er fortfährt, sich zu
evolvieren. Das heißt,
wenn neue Kennzeichen hinzugefügt
werden oder Kennzeichen modifiziert werden, werden die Regeln des
Syntaxanalysierer der Website aktualisiert, um solche Änderungen
zu reflektieren.
-
Ist
beispielsweise die Seitenkette
„<html>
<head>
<title>NY Times on the Web</title>
</head>
<body>
<form action=/cgi-bin/program.cgi
name=register>
.....
<input type=textfield
size=20 maxlength=50 name=username>
.....
</form>
</body>
</html>"
gegeben, wird durch syntaktisches
Analysieren des Textfeldes "<input type=textfield
size=20 maxlength=50 name=username>" extrahiert. Dieses Textfeld
wird nun für „type", „size", „maxlength", „value" syntaktisch analysiert,
und wenn das Feld nicht im Kennzeichen gefunden wird, wird es als
null eingegeben. In diesem Fall gilt Wert (value) = 0. Auf diese
Weise hat die zentrale Website Formulardaten einzugeben. In anderen
Worten hat die zentrale Website eine Formular-URL erhalten, welche
die korrespondierenden HTLM-Daten von einer Website bekommen muss.
-
Die
zentrale Website hat das „Aktions"-Feld („action" field) des Formulars
syntaktisch analysiert. In diesem Fall gilt Aktion (action) = „/cgi-bin/programm.cgi". Demgemäss hat die
zentrale Website eindeutige Identifizierer für alle Formulare durch Benutzung
der Formular-URL-Formularname-Formularaktions-Beziehung.
Formularen wird auf der Basis dieser Dreiparteienbeziehung eine
eindeutige Formularidentifizierungsnummer (beispielsweise 33) gegeben.
Dann werden alle Formularelemente in der Datenbank 122 gespeichert.
Für jede
Art von Element gibt es eine korrespondierende Datenbanktabelle.
So gibt für
das obige Textfeld die zentrale Website diese Daten in die korrespondierende
Textfeldtabelle der Datenbank 122 mit einem SQL-Statement wie
beispielsweise „INSERT
INTO TEXTFIELDS (NAME, SIZE, MAXLENGTH, VALUE, FORM ID, SPECIAL)
VALUES („username" 20, 50, NULL, 33, „login")" ein. Bei diesem Beispiel ist „Special
(speziell)" der
korrespondierende Feldidentifizierer der zentralen Website, der
aus einer Liste möglicher
Werte ausgewählt
wird. In diesem Fall stellt „username" einen Anmeldenamen
dar, so dass diesem Formularelement „login (anmelden)" zugeordnet wird.
-
Auf Benutzerinformation
basierte gezielte Werbung
-
Bei
einer anderen Ausführungsform
kann die zentrale Website auch eine gezielte Werbungsstrategie benutzen,
um ihren Benutzern relevante Werbung zu liefern, und sie verwendet
typischerweise nur die der zentralen Website in den Mitgliedschaftsformularvorlagen
bereitgestellte Information, um solche Werbung ins Ziel zu bringen.
Wenn beispielsweise ein Werbungskunde (beispielsweise Barnes & Noble) der zentralen
Website alle männlichen
Mitglieder im Alter über
50 der zentralen Website gerne dazu bringen will, sich eine Werbung
(beispielsweise für
Bücher)
anzuschauen, kann die zentrale Website eine solche gezielte Werbung
auf der Basis der Benutzerinformation (beispielsweise in der Datenbank 122 enthalten),
die zu solchen Zielkriterien passen, abgeben. In einer solchen Situation
erzeugt die zentrale Website eine Datenbank (beispielsweise in der Datenbank 122)
von Benutzeridentifikationsnummern auf der Basis der demographischen
Benutzerinformation, wie sie während
der anfänglichen
Registrierung der Benutzer der zentralen Website bereitgestellt
wurde. Demgemäss
können
Benutzerdemographieelemente wie beispielsweise Geschlecht, Region,
Alter, Zeitzone usw. gesammelt und zum Gewinnen von Inserenten benutzt
werden. Die zentrale Website benutzt dann die erzeugte Datenbank
zum Ändern
der Werbungen gemäß diesen
Charakteristikum- und Abzielkriterien. Um die Vertraulichkeit der Benutzer
der zentralen Website sicherzustellen, garantiert die zentrale Website
durch ihre Vertraulichkeitspolitik bzw. -methode, dass die Bestimmungen bzw.
Bestimmungsorte ihrer Benutzer nicht zur Zielwerbung geführt werden.
-
Demgemäss stellt
die zentrale Website gemäß der vorliegenden
Erfindung einen Online/Offline-Dienst bereit, der (i) für Benutzer
die Notwendigkeit einer Neueingabe der gleichen persönlichen
Information bei jeder neuen Site, bei welcher der Benutzer registriert
werden will, neu einzugeben, eliminiert, (ii) Benutzer von der Notwendigkeit,
die gleichen wiederkehrenden Benutzernamen und Passwörter durch
die Gateways der meisten Websites und E-Mail-Konten neu zu tippen,
erleichtert bzw. befreit, (iii) ein gezieltes Werbungssystem zum
Bedienen ihrer Benutzer mit relevanten Werbungen auf der Basis von
Demographie, aber typischerweise nicht auf der Basis von Website-Besuchsverhalten
(das heißt Web-Surfverhalten)
des Benutzers liefert, und (iv) Schwächen des Benutzers bei der
Sicherheit ihrer Kredit/Debit-Kartennummern
auf dem Internet löst, während es
noch die Fähigkeit
zum Einkaufen, Bieten bei Auktionen, karitative Gaben und Spenden
zu machen und anderweitige Benutzung von Kredit/Debit-Kartendienst-Websites
liefert.
-
Die
zentrale Website kann als eine mehrsprachige internationale Website
mit lokalen/globalen Domänen
für jede
Sprache implementiert sein. Die von der zentralen Website bereitgestellten
Dienste sind für
neue Internet-Benutzer, die noch die oben beschriebenen Verzögerungen
und Probleme berücksichtigen
müssen,
am nützlichsten.
Es gibt weit mehr Leute außerhalb
der Vereinigten Staaten, die sich noch nicht in das Internet gewagt
haben. Die Leichtigkeit und Effizienz der zentralen Website gemäß der vorliegenden
Erfindung helfen zu veranlassen, dass mehr Leute damit beginnen,
das Internet zu nutzen.
-
Die
zentrale Website kann auch eine eingeschränkte Version der Dienste der
Site enthalten, die vorteilhaft in Schulsystemen zu benutzen ist.
Diese eingeschränkte „Erziehungs"-Version erlaubt
dem Studenten, nur zu solchen Bestimmungen auf dem Web zu navigieren,
die Schulbedienstete zuvor empfehlen, wie beispielsweise Forschungssites,
Erziehungssites usw. und andere solche Bestimmungen.
-
Die
zentrale Website kann auch einen Kalender mit programmierbaren Erinnerungen
für Ereignisse
und spezielle Anlässe
enthalten, und die zentrale Website kann eine Anzeige bezüglich solcher
Erinnerungen enthalten, die an E-Commerce-Sites verkauft werden können, um
Geschenkideen vorzuschlagen.
-
Die
zentrale Website kann auch eine Broswer-Programmerweiterung (browser plug-in)
zur Bereitstellung der oben beschriebenen Dienste der zentralen
Website bereitstellen, wie es die Fachleute der relevanten Technik(en)
erkennen. Auf diese Weise kann ein Benutzer der zentralen Website
eine solche Programmerweiterung dazu benutzen, die URL, die der
Benutzer anschaut, zur zentralen Website als eine Anforderung für die zentrale
Website zu senden, um einen Link für die URL in einer persönlichen Webseite
mit einem Klick auf einen Button zu erzeugen.
-
Die
zentrale Website kann auch als eine Plattform für die Software der zentralen
Website entwickelt sein, um, wie es die Fachleute der relevanten Technik(en)
erkennen, zu ermöglichen,
dass auf Kontoinformation von Benutzern der zentralen Website auf
drahtlosen Einrichtungen wie beispielsweise PDAs, Zellulartelefonen
zugegriffen werden kann, um ein drahtloses Web zu unterstützen.
-
25 ist ein Systemblockdiagramm des obersten Niveaus
zur Implementierung der Systeme und Prozesse der 1 bis 3 gemäß der vorliegenden
Erfindung. Bei 25 ist der Server 2502 der zentralen
Website an eine auf dem Server 2502 oder einem anderen
Computer (beispielsweise für
Sicherheitszwecke) gehostete Datenbank gekoppelt. Die Benutzer können über Computer 2508 und
eine optionale Verifikationseinrichtung 2508a über das
Internet oder Intranet 2510 auf den Server 2502 der
zentralen Website zugreifen. Wenn einmal ein Benutzer über die
Computer 2508 im Server 2502 der zentralen Website
angemeldet ist, können
die oben beschriebenen Prozesse bezüglich der 1 bis 3 wie
oben beschrieben dazu benutzt werden, Information zu Servern 2506 anderer
Websites zu kommunizieren.
-
26 ist ein Systemblockdiagramm des obersten Niveaus
zur Implementierung der Systeme und Prozesse der 4 bis 24 gemäß der vorliegenden
Erfindung. Bei 26 ist eine Verifikationseinrichtung 2604 an
ein Verkaufsplatz- bzw. Kassenendgerät eines Handels-, insbesondere
Einzelhandelskaufhauses oder eine Website 2602 gekoppelt
und kann zum Implementieren der oben beschriebenen Benutzer-Identifikation/Autorisierung und
biometrischer Prozesse benutzt werden. Das Handelskaufhaus oder
die Website 2602 ist über
das Internet oder ein Intranet 2510 an die zentrale Website 2502 gekoppelt.
Die zentrale Website 2502 enthält die Datenbank 122 zum
Speichern von Benutzerkontoinformation, Bestimmungswebsite-Formularinformation
usw. Das Handelskaufhaus oder die Website 2602 und die
zentrale Website 2502 sind an ein Kommunikationsnetzwerk 2610 gekoppelt,
das zur Verarbeitung von Online- und Offline-Kreditkartentransaktionen
benutzt wird. Das Netzwerk 2610 kann das gleiche Netzwerk
wie das Netzwerk 2510 sein. Auch sind an das Netzwerk 2610 ein
oder mehrere akquirierende Geldinstitute bzw. Akquirierungsgeldinstitute 2608,
Karten ausgebende Geldinstitute bzw. Kartenausgabegeldinstitute 2606 und
Händler-Geldinstitute
(beispielsweise Online- oder Offline-Einzelhändler-Geldinstitute) 2612,
die jeweils ihre Datenbanken 2608a, 2606a bzw. 2612a enthalten,
gekoppelt. Demgemäss
können
die bezüglich
der 4 bis 24 beschriebenen
Prozesse über
das System der 26 implementiert werden.
-
27 ist eine schematische Darstellung eines Mehrzweck-
bzw. Universalcomputers 2700 (der beispielsweise mit dem
Server 2502, die Server 2506, die Computer 2508 der Benutzer
usw. korrespondiert), der entsprechend den Lehren der vorliegenden
Erfindung programmiert werden kann. Bei 27 implementiert
der Computer 2700 die Prozesse der vorliegenden Erfindung,
wobei der Computer beispielsweise eine Anzeigeeinrichtung 2702 (beispielsweise
einen Berührungsbildschirmmonitor mit
einer Berührungsbildschirmschnittstelle
usw.), eine Tastatur 2704, eine Zeigervorrichtung 2706,
ein Mauspad oder Digitalisierungspad 2708, eine Festplatte 2710 oder
andere Hochdichtmedienlaufwerke (high density media drives), die
unter Verwendung eines geeigneten Einrichtungsbusses (beispielsweise eines
SCSI-Busses, eines Enhance DIE-Busses, eines Ultra DMA-Busses, eines
PCI-Busses usw.) angeschlossen sind, ein Diskettenlaufwerk 2712,
ein Band- oder CD-ROM-Laufwerk 2714 mit
Band- oder CD-Medien 2716 oder andere entfernbare Medieneinrichtungen
wie beispielsweise magnetooptische Medien usw., und eine Hauptplatine 2718 aufweist. Die
Hauptplatine 2718 weist beispielsweise einen Prozessor 2720,
einen RAM 2722 und einen ROM (beispielsweise DRAM, ROM,
EPROM, EEPROM, SRAM, SDRAM und Flasch-RAM usw.) 2724, I/O-Ports
(E/A-Anschlüsse) 2726,
die zum Koppeln an periphere Geräte
und optionale Spezialzweck-Logikeinrichtungen
(beispielsweise ASICs usw.) oder konfigurierbare Logikeinrichtungen
(beispielsweise GAL und wiederprogrammierbare FPGA) 2728 zur Ausführung spezialisierter
Hardware/Software-Funktionen wie beispielsweise Tonverarbeitung,
Bildverarbeitung, Signalverarbeitung, Spracherkennungsverarbeitung,
Neuronennetzwerkverarbeitung, Fingerabdruckerkennungsverarbeitung,
Retinaerkennungsverarbeitung, automatisierte Klassifikation, Modem/DSL/ADSL/ISDN-Kommunikationsverarbeitung,
Website-Server-Verarbeitung,
Internetkommunikationsverarbeitung usw., ein Mikrofon 2730 und
einen oder mehrere Lautsprecher 2732 auf.
-
Wie
oben dargelegt weist das System wenigstens ein computerlesbares
Medium auf. Beispiele für
computerlesbare Medien sind Compakt-Disc (CD), Festplatten, Disketten,
Band, magnetooptische Platte, PROMs (EPROM, EEPROM, Flash-EPROM), DRAM,
SRAM „ SDRAM
usw. Die vorliegende Erfindung enthält auf irgendeinem oder einer
Kombination von computerlesbaren Medien gespeichert die Software
zur Steuerung sowohl der Hardware des Computers 2700 als
auch zur Ermöglichung,
dass der Computer 2700 mit einem menschlichen Benutzer
interagieren kann. Eine solche Software kann Einrichtungstreiber,
Betriebssysteme und Benutzeranwendungen wie beispielsweise Entwicklungswerkzeuge enthalten,
ist jedoch nicht darauf beschränkt.
Solche computerlesbare Medien können
auch das Computerprogrammprodukt der vorliegenden Erfindung zur Ausführung jedes
der oben beschriebenen Prozesse gemäß der vorliegenden Erfindung
enthalten. Die Computercodeeinrichtungen der vorliegenden Erfindung
können
jeder interpretierte oder ausführbare Codemechanismus
sein, darunter, aber nicht darauf beschränkt, Skripts, Interpreter,
dynamische Linkbibliotheken, Javaklassen vollständig ausführbare Programme usw.
-
Demgemäss können die
bei der vorliegenden Erfindung festgelegten Mechanismen und Prozesse
unter Verwendung eines konventionellen Mehrzweck- bzw. Universal-Mikroprozessors
oder -Computers, der entsprechend den Lehren der vorliegenden Erfindung
programmiert ist, implementiert sein, wie es die Fachleute der relevanten
Technik(en) erkennen. Geeignete Softwarecodierung kann von Fachprogrammierern
auf der Basis der Lehren der vorliegenden Erfindung leicht präpariert
werden, wie es die Fachleute der relevanten Technik(en) ebenfalls
erkennen. Jedoch kann, wie es die Fachleute der relevanten Technik(en)
leicht erkennen, die vorliegende Erfindung auch durch die Präparation
anwendungsspezifischer integrierter Schaltungen oder durch Zusammenschalten
eines geeigneten Netzwerks aus konventionellen Komponentenschaltungen
implementiert werden.
-
Die
vorliegende Erfindung umfasst auf diese Weise auch ein computerbasiertes
Produkt, das auf einem Speichermedium gehostet werden kann und Instruktionen
enthält,
die zum Programmieren eines Universal-Mikroprozessors oder -Computers
zur Ausführung
von Prozessen gemäß der vorliegenden Erfindung
benutzt werden können.
Dieses Speichermedium kann jeden Typ von Platten, darunter Disketten,
optische Platten, CD-ROMs, magnetooptische Platten, ROMs, RAMs,
EPROMs, EEPROMs, Flash-Speicher,
magnetische oder optische Karten oder jeden Typ von Medien, die
zum Speichern elektronischer Instruktionen geeignet sind, umfassen,
ist aber nicht darauf beschränkt.
-
Die
vorliegende Erfindung ist in Form einer Praktizierung des Verfahrens über das
Internet oder ein Intranet beschrieben. Die vorliegende Erfindung kann
durch jedes Kommunikationsmittel wie beispielsweise drahtlose Kommunikation
bzw. Funkkommunikation, Satellitenkommunikation usw. implementiert
werden, wie es die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Verarbeitung von Website-Registrierungsformularen
beschrieben ist, kann die vorliegende Erfindung zur Verarbeitung
aller Typen von Website-Formularen implementiert werden, wie es
die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form der die Aktualisierungsdateien 410/414/608 übertragenden
zentralen Website beschrieben ist, kann die vorliegende Erfindung
mit der die Aktualisierungsdateien 410/414/608 übertragenden
Bestimmungswebsite 418 und/oder mit den die Kreditkarten-Aktivierungsprozesse
ausführenden
Geldinstitute/Kreditkarten-Netzwerken
implementiert werden, wie es die Fachleute der relevanten Technik(en)
erkennen.
-
Obgleich
die vorliegende Erfindung in Form der die Aktualisierungsdateien 410/414/608 übertragenden
zentralen Website beschrieben ist, kann die vorliegende Erfindung
mit der Bestimmungswebsite 418, die Aktualisierungssignale,
welche die in den Aktualisierungsdateien 410/414/608 enthaltene Transaktionsinformation
enthalten, überträgt, implementiert
werden, wie es die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form der zentralen Website, die einen
vorbestimmten Zeitbetrag (beispielsweise 15 bis 30 Minuten) zur
Desaktivierung einer Online-Transaktion
benutzt, beschrieben ist, kann die vorliegende Erfindung unter Verwendung
anderer Zeitbeträge
(beispielsweise eine Stunde, ein Tag, eine Woche usw.) implementiert werden,
wie es die Fachleuten der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form der Aktualisierungsdatei-Verifikationseinrichtung 602,
die zwischen dem Servlet 218 und der Bank/dem Geldinstitut,
die/das die Kreditkarte ausgibt, lokalisiert ist, beschrieben ist,
kann die Einrichtung 602 in anderen Bereichen des Systems
wie beispielsweise zwischen dem Kreditkarten-Netzwerk 508 und
dem unterschreibenden Geldinstitut 606, zwischen der Bank/dem
Geldinstitut 412, welche/das die Kreditkarte ausgibt, und
dem unterschreibenden Geldinstitut 606 usw. lokalisiert
sein, wie es die Fachleuten der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form der Bereitstellung eines Online-Kredit/Debit-Karten-Sicherheitstransaktionsdienstes
für einen
Benutzer beschrieben ist, kann die vorliegende Erfindung einen vorläufigen Online-Kredit/Debit-Karten-Ausgabe/Genehmigungs-Dienst aufweisen,
wie es die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die Erfindung in Form der Bereitstellung eines Online-Kredit/Debit-Karten-Sicherheitstransaktionsdienstes
für einen
Benutzer beschrieben ist, kann die vorliegende Erfindung ein vorläufiges Aktivierungsmerkmal
für das
Online-Kredit/Debit-Kartenkonto über einen
vom Benutzer eingegebenen und an einen bei der zentralen Website gespeicherten
Aktivierungscode angepassten Aktivierungscode aufweisen, wie es
die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form der Benutzung von Servlets (beispielsweise
unter Benutzung einer Java-Programmierungssprache
implementiert) beschrieben ist, können andere Anwendungen und
Programmierungssprachen wie beispielsweise CORBA-Objekte, Active
X-Anwendungen, PEARL-Skripts
usw. benutzt werden, wie es die Fachleute der relevanten Technik(en)
erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Benutzung von HTML beschrieben
ist, können andere
Internet-Programmierungssprachen
wie beispielsweise XML, EXML usw. benutzt werden, wie es die Fachleute
der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Benutzeranmeldung in die
zentrale Website unter Verwendung eines Personalcomputers beschrieben
ist, können
andere Einrichtungen wie beispielsweise PDAs (personal data assistants
(persönliche Datenassistenten)),
Internet-bereite Zellulartelefone, welche die TCP/IP-, WAP-, 3G-Protokolle
usw. benutzen, zum Anmelden in der zentralen Website benutzt werden,
wie es die Fachleuten der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine E-Commerce-Website agierenden zentralen
Website implementiert werden, wobei die Online-Kredit/Debit-Karte
von der als eine E-Commerce-Website agierenden zentralen Website
aktiviert wird, wenn ein Benutzer die E-Commerce-Website besucht,
und beim Schließen des
Kassieren- bzw. Checkout-Prozesses
des Benutzers desaktiviert wird, wie es die Fachleute der relevanten
Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine ISP-Website (ISP = Internet Service Provider
(Internetdienstprovider)) agierenden zentralen Website implementiert
werden, wobei die Online-Kredit/Debit-Karte von der als eine ISP-Website
agierenden zentralen Website aktiviert wird, wenn ein Benutzer sich
in einer E-Commerce-Website
anmeldet oder diese besucht, und beim Abmelden oder nach einem Zeit-Aus
desaktiviert wird, wie es die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Auktions-Website agierenden zentralen
Website implementiert werden, wobei die Online-Kredit/Debit-Karte
von der als eine Auktions-Website agierenden zentralen Website aktiviert
wird, wenn ein Bieten des Benutzers akzeptiert wird, und nach Verarbeitung
der Bietgebühr
bzw. -belastung desaktiviert wird, wie es die Fachleute der relevanten
Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Nenne-deinen-eigenen-Preis-Website (name
your own price web site) agierenden zentralen Website implementiert
sein, wobei die Online-Kredit/Debit-Karte von der als eine Nenne-deinen-eigenen-Preis-Website
agierenden zentralen Website aktiviert wird, wenn ein Bieten des Benutzers
akzeptiert wird, und nach Verarbeitung des Bietens/der Bestellung
desaktiviert wird, wie es die Fachleute der relevanten Technik(en)
erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Reiseagentur-Website agierenden zentralen
Website implementiert sein, wobei die Online-Kredit/Debit-Karte von
der als eine Reiseagentur-Website agierenden zentralen Website aktiviert
wird, wenn ein Auftrag eines Benutzers akzeptiert wird, und nach
Bearbeitung des Auftrags desaktiviert wird, wie es die Fachleute der
relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Online-Abgabe-Website agierenden zentralen
Website implementiert sein, wobei die Online-Kredit/Debit-Karte
von der eine Online-Abgabe-Website agierenden zentralen Website
aktiviert wird, wenn ein Auftrag eines Benutzers akzeptiert wird,
und nach Verarbeitung des Auftrags desaktiviert wird, wie es die
Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Online-Lesezeichen-Website agierenden
zentralen Website implementiert sein, wobei die Online-Kredit/Debit-Karte von
der als eine Online-Lesezeichen-Website agierenden zentralen Website
aktiviert wird, wenn ein Benutzer eine Lesezeichenadressierte E-Commerce-Website
besucht, und nach einer vorbestimmten Zeit-Aus-Periode desaktiviert
wird, wie es die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Online-Bank/Geldinstitut-Website (oder
Traditionellbank-Site)
implementiert sein, wobei die Online-Kredit/Debit-Karte von einer
E-Commerce-Website aktiviert und desaktiviert wird, welche die als
eine Online-Bank/Geldinstitut-Website (oder Traditionellbank-Site)
von der Aktivierung und Desaktivierung informiert, wie es die Fachleute
der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Online-Rechnungsbezahlungs-Website agierenden
zentralen Website implementiert sein, wobei die Online-Kredit/Debit-Karte von der als
eine Online-Rechnungsbezahlungs-Website agierenden zentralen Website aktiviert
wird, wenn ein Auftrag eines Benutzers zum Bezahlen einer Rechnung
akzeptiert wird, und nach Verarbeitung der Transaktion desaktiviert
wird, wie es die Fachleute der relevanten Technik(en) erkennen.
-
Obgleich
die vorliegende Erfindung in Form einer Aktivierung der Online-Kredit/Debit-Karte
während
E-Commerce-Transaktionenen
von einer Zentralwebsite-Stelle aus beschrieben ist, kann die vorliegende
Erfindung mit der als eine Online-Währungssystem-Website implementiert
sein, wobei die Online-Kredit/Debit-Karte durch die als eine Online-Währungssystem-Website agierende
zentrale Website aktiviert wird, wenn ein Benutzer online Geld zum
Einkaufen bei teilnehmenden Händlern,
insbesondere Einzelhändlern
erwerben will, und nach Verarbeitung der Transaktion desaktiviert
wird, wie es die Fachleute der relevanten Technik(en) erkennen.
-
GLOSSAR
-
Im
Kontext der vorliegenden Erfindung beziehen sich:
-
„Akquirierungsbank
(acquiring bank)" oder „Händlerbank", (merchant bank)" auf eine Bank, die ein
Geschäftsbeziehung
mit einem Händler,
insbesondere Großhändler hat
und alle Kreditkartentransaktionen von diesem Händler empfängt.
-
„Autorisierung
(authorization)" auf
die Genehmigung einer Kreditkartentransaktion für einen Händler, insbesondere Großhändler, durch
eine Karten ausgebende Bank bzw. Kartenausgabebank.
-
„Asymmetrische
Verschlüsselung
(asymmetric encryption)" auf
ein kryptographisches System bzw. Verschlüsselungssystem, das zwei Schlüssel benutzt – einen
jedermann bekannten öffentlichen Schlüssel und
einen nur dem Empfänger
der Nachricht bekannten privaten oder geheimen Schlüssel. Wenn
John eine sichere Nachricht an Jane senden will, benutzt er Janes öffentlichen
Schlüssel
zum Verschlüsseln
der Nachricht. Jane benutzt dann ihren privaten Schlüssel um
sie zu entschlüsseln.
Ein wichtiges Element beim öffentlichen
Schlüsselsystem
ist, dass der öffentliche
und private Schlüssel
derart in Beziehung stehen, dass nur der öffentliche Schlüssel zum
Verschlüsseln
von Nachrichten benutzt werden kann, und nur der korrespondierende
private Schlüssel
dazu benutzt werden kann, sie zu entschlüsseln. Überdies ist es im Grunde genommen
nicht möglich, den
privaten Schlüssel
abzuleiten, wenn Sie den öffentlichen
Schlüssel
kennen.
-
„Autorisierungscode
(authorization code)" auf
einen von einer Kartenausgabebank einem Kreditkartenverkauf zugeordneten
Code, um zu zeigen, dass die Transaktion autorisiert ist.
-
„Bankkarte
(bank card)" auf
eine von einer Bank ausgegebene Kreditkarte (beispielsweise sind Visa
und MasterCard Bankkarten, und American Express und Discover sind
es nicht).
-
„Browser
(browser)" auf ein
Programm, das auf Dateien, die auf dem World Wide Web zur Verfügung stehen,
zugreift und diese anzeigt.
-
„Rückbelastung
(chargeback)" auf
eine Kreditkartentransaktion, die einem Händler, insbesondere Großhändler, der
den Verkauf tätigte,
zurück
in Rechnung gestellt wird.
-
„Client
(client)" auf einen
Computer oder ein Programm, der bzw. das Dateien von einem Server zur
Manipulation herunterladen kann.
-
„Cookie
(cookie)" auf Information,
dass sich eine Website auf eine Festplatte eines Benutzers setzt,
so dass die Website sich zu späterer
Zeit an etwas bezüglich
des Benutzers erinnern kann (mehr technisch gesehen ist ein Cookie
Information für
einen zukünftigen
Gebrauch, der vom Server auf der Client-Seite einer Client-Server-Kommunikation
gespeichert ist).
-
„Kryptographie
(cryptography)" auf
eine Technik zum Schutz von Information durch ihre Transformation
(ihre Verschlüsselung)
in ein nicht lesbares Format, verschlüsselter Text genannt. Nur diejenigen,
die einen geheimen Schlüssel
besitzen, können
die Nachricht im Klartext entziffern (oder entschlüsseln).
Verschlüsselte
Nachrichten können manchmal
durch Kryptoanalyse, auch Codebrechen genannt, aufgebrochen werden,
obgleich moderne kryptografische Techniken im Grunde genommen nicht
aufbrechbar sind,
-
„E-Commerce
(e-commerce)" (auch
als „electronic
commerce (Elektronik-Commerce)" oder „EC" bezeichnet) auf
das Kaufen und/oder Verkaufen von Gütern und/oder Diensten auf
dem Internet, insbesondere dem World Wide Web.
-
„URL" auf eine Darstellung,
die ein Übertragungsprotokoll
und eine Internet-Identifizierungsnummer
spezifiziert, die hauptsächlich
zur Bewegung von Site zu Site auf dem World Wide Web benutzt werden.
-
„Elektronische
Datenerfassung (electronic data capture)" auf die Eingabe und Verarbeitung von Verkaufszeichnungen
durch elektronische Mittel (bei Online-Bezahlungsschemata wird Erfassung
zum Bezeichnen der elektronischen Deponierung der Verkaufzeichnung
mit der Akquirierungsbank benutzt).
-
„E-Mail
(e-mail)" auf Nachrichten,
die über Telekommunikationslinks
wie beispielsweise zwischen Mikrocomputern oder Endgeräten gesendet und
empfangen werden.
-
„Verschlüsselung" auf die Umsetzung
von Daten in einen geheimen Code. Verschlüsselung ist der effektivste
Weg zur Erzielung von Datensicherheit. Zum Lesen einer verschlüsselten
Datei müssen Sie
Zugriff auf einen geheimen Schlüssel
oder ein geheimes Passwort haben, das Sie dazu befähigt, sie zu
entschlüsseln.
Nicht verschlüsselte
Daten werden Klartext genannt, verschlüsselte Daten werden als verschlüsselter
Text bezeichnet. Es gibt zwei Haupttypen von Verschlüsselung:
asymmetrische Verschlüsselung
und symmetrische Verschlüsselung.
-
„Hardware
(hardware)" auf
Computer und die zugeordnete physikalische Einrichtung, die direkt in
die Ausführung
von Datenverarbeitung oder Kommunikationsfunktionen involviert sind.
-
„Homepage
(home page)" auf
die zum Zugriff bei einer World Wide Web-Site verfügbare Datei,
die hauptsächlich
zum Begrüßen von
Besuchern vorgesehen ist, Information über die Website bereitstellt und
sie zu anderen Websites mit mehr verwandter Information leitet.
-
„HTML" (Hypertext Markup
Language (Hypertext-Auszeichnungssprache))
ist der Satz aus "Auszeichnungs"- bzw. „Beschreibungs"-Symbolen oder -Codes
(„markup" symbols or codes),
die in eine zur Anzeige auf einem World Wide Web-Browser vorgesehene Datei eingesetzt
sind. HTML ist die autorisierende Sprache, die zum Erzeugen von
Dokumenten auf dem World Wide Web benutzt wird. HTML ist ähnlich zu
SGML, obgleich sie nicht eine strikter Untermenge ist. HTML definiert
die Struktur und das Layout eines Web-Dokuments durch Benutzung
einer Vielfalt von Kennzeichen und Attributen.
-
„HTML-Formulare" auf ein formatiertes HTML-Dokument,
das Felder enthält,
die Benutzer mit Daten füllen
können.
Das Formular erscheint auf dem Anzeigeschirm des Benutzers, und
der Benutzer füllt
es durch Auswählen
von Optionen mit einer Zeigereinrichtung oder Eintippen von Text
von der Computertastatur aus. Die HTML-Sprache hat Codes zur Anzeige
von Formularelementen wie beispielsweise Textfelder und Markierungsfelder
(checkboxes) eingebaut. Typischerweise werden die in ein Web-basiertes
Formular eingegebenen Daten durch ein CGI-Programm verarbeitet.
-
„HTTP" (Hyper Text Transfer
Protocol (Hypertext-Übertragungsprotokoll))
auf das vom World Wide Web benutzte zugrundeliegende Protokoll. HTTP
definiert, wie Nachrichten formatiert und übertragen werden und welche
Aktionen Web-Server
und -Browser in Reaktion auf verschiedene Befehle ausführen sollen.
Wenn Sie beispielsweise eine URL in ihren Browser eingeben, sendet
dieser tatsächlich
einen HTTP-Befehl zum Web-Server, der ihn leitet, um die angeforderten
Webseiten zu erfassen und zu übertragen.
-
„Hypertext
(hypertext)" auf
ein computerbasiertes Textwiedergewinnungssystem, das dem Benutzer
ermöglicht,
auf Information, sich auf einen besonderen Text bezieht, zuzugreifen
oder diese zu gewinnen. Ein „Verweis
bzw. Link (link)", „Hyperlink
(hyperlink))" oder „Hypertextlink
(hypertext link)" bezieht sich
auf eine von einem Wort, Bild oder Informationsobjekt oder anderem
auswählbare
Verbindung.
-
„ISO (=
independent sales organization (Unabhängige Verkauforganisation))" auf Organisationen,
die als eine dritte Partei zwischen dem Händler und der Akquirierungsbank
agiert (beispielsweise wenn es nicht möglich ist, dass ein Geschäft durch eine
Akquirierungsbank Händler-
insbesondere Großhändlerstatus
erhält,
da die Bank es als ein zu großes
Risiko ansieht, muss es möglicherweise durch
eine ISO gehen, um Händlerstatus
zu erhalten.
-
„Austausch
(interchange)" auf
eine Transaktion, die zwischen der Akquirierungsbank und einer Kreditkartenausgabebank
stattfindet.
-
„Austauschgebühr" auf eine Gebühr, die
eine Akquirierungsbank einer Kreditkartenausgabebank bezahlt, um
eine Kreditkartentransaktion, die ein Konto eines Kartenhalters
involviert, zu verarbeiten.
-
„Internet" auf eine Matrix
von Computernetzwerken, die Computer rund um die Welt verbinden.
-
„Intranet" auf ein Netzwerk
von Computern oder ein Netzwerk von Computernetzwerken, das in einem
Unternehmen enthalten ist.
-
„Anmeldenamen
(login name)" auf
eine von einem Passwort unterschiedene Identifikationskette, die
zur Anmeldung bei einem Mehrbenutzersystem, Schwarzes-Brett-System,
LAN (local area network (lokales Datennetz)) oder Online-Dienst
erforderlich ist und auch als „Benutzername
(username)" oder „Benutzer-ID
(user ID)" bezeichnet
wird.
-
„Anmelden
(logon, login)" auf
die zum Bekommen eines Zugriffs auf ein Betriebssystem oder eine
Anwendung benutzte Prozedur, die erfordert, dass der Benutzer eine
Benutzer-ID und ein Passwort hat.
-
„Händlerskonto
(merchant discount)" auf
einen Prozentsatz eines Handel- bzw. Einzelhandelverkaufs, den ein
Händler,
insbesondere Großhändler an
eine Akquirierungsbank als eine Gebühr zur Bearbeitung einer Kreditkartentransaktion
bezahlt.
-
„Händlerstatus
(merchant status)" auf
ein Geschäft,
das eine Autorisierung von einer Akquirierungsbank, einer ISO oder
einem anderen Geldinstitut zum Akzeptieren von Kreditkarten hat.
-
„Modem
(modem)" auf ein
Gerät oder
Programm, das einen Computer dazu befähigt, Daten über Telefonleitungen
zu übertragen.
Computerinformation wird digital gespeichert, während über Telefonleitungen übertragene
Information in der Form von analogen Wellen übertragen wird. Ein Modem setzt
zwischen diesen beiden Formen um.
-
„Online
(online)" auf mit
einem Computer oder Computernetzwerk verbunden oder darauf zugreifen
können.
-
„Syntaktisch
analysieren (parse, parsing)" auf
das Aufbrechen einer Kette von Zeichen in Gruppen kleinerer Ketten
unter Verwendung eines spezifischen Satzes von Regeln.
-
„Passwort
(password)" auf
eine Folge von Zeichen, die zur Gewinnung eines Zugriffs auf ein Computersystem
erforderlich ist.
-
„Persönliche Webseite
(personal Web page)" auf
die zum Zugriff bei einer World Wide Web-Site verfügbare Datei,
die hauptsächlich
zum Begrüßen eines
speziellen Benutzers, Bereitstellen personalisierter Information
dem Benutzer und/oder Führen den
Benutzer zu benutzerspezifizierten Websites vorgesehen ist.
-
„Programmerweiterung
(plug-in)" auf Programme,
die als Teil eines Web-Browsers eines Benutzers leicht installiert
und benutzt werden können.
-
„Programm
(program)" auf eine
Prozedur zum Lösen
eines Problems, das eine Sammlung von Daten, Verarbeitung und Präsentation
von Resultaten involviert, wobei eine solche Prozedur für einen Computer
oder eine Anweisungs- bzw. Instruktionsfolge in programmierter Anweisung
bzw. Instruktion codiert ist.
-
„Verkaufszeichnung" auf ein Instrument,
das eine Obligation auf einem Teil eines Kartenhalters zur Zahlung
von Geld (das heißt
des Verkaufsbetrags) an einen Kartenausgeber zeigt (beispielsweise
ist dies das Stück
Papier, das Sie unterzeichnen, wenn sie einen Kauf mit ihrer Kreditkarte
tätigen).
Verkaufszeichnungsdaten können
elektronisch „erfasst" und gesendet werden,
um über
Finanznetzwerke verarbeitet zu werden.
-
„Schirm
(screen)" oder „Fenster
(window)" auf Daten
oder eine oder mehrere Dateien, die einem Benutzer über einen
Web-Browser präsentiert
werden.
-
„Sicherheit
(secure)" auf Daten,
die unter Benutzung einer Verschlüsselungseinrichtung oder anderen
Einrichtung codiert werden, so dass die Integrität der Daten sichergestellt
ist.
-
„Server
(server)" auf einem
Computer oder ein Programm, der bzw. das einen zentralen Aufbewahrungsort
von Daten, die in gewisser Weise durch einen Client heruntergeladen
werden können,
steuert.
-
„Servlet" auf ein kleines
Programm, das auf einem Server läuft.
-
„Sitzungs-
bzw. Sessionsobjekt (session object)" auf eine Serie verwandter Interaktionen
zwischen einem einzelnen Benutzer und dem Web-Server, die auf einer
Zeitreihe stattfindet. Diese Session könnte eine Reihe von Transaktionen
oder Anforderungen sein. Die Session kann aus mehrfachen Anforderungen
beim gleichen Servlet oder aus Anforderungen bei einer Vielfalt
unterschiedlicher Ressourcen auf der gleichen Website bestehen.
-
„S-HTTP" auf eine Erweiterung
des HTTP, um ein sicheres Senden von Daten über das World Wide Web zu unterstützen. Nicht
alle Web-Browser und Server unterstützen S-HTTP.
-
„Software
(software)" auf
Programme, Routinen und symbolische Sprachen, die das Funktionieren
der Hardware und Führen
ihres Betriebs steuern.
-
„SSL" (Secure Sockets
Layer (sichere Anschlussschicht)) auf eine Technologie bzw. Technik zur Übertragung
sicherer Kommunikationen über
das World Wide Web. SSL ist ein von Netscape zur Übertragung
privater Dokumente über
das Internet entwickeltes Protokoll. SSL arbeitet durch Bereitstellen
eines privaten Schlüssels
zum Verschlüsseln
von über die
SSL-Verbindung übertragenen
Daten. Sowohl der Netscapenavigator als auch der Internetexplorer unterstützen SSL,
und viele Websites benutzen das Protokoll, um vertrauliche Benutzerinformation
wie beispielsweise Kreditkartennummern zu erhalten. Kaufverträge, Webseiten,
die eine SSL-Verbindung benötigen,
starten mit „https: „anstelle
von „http".
-
„SQL" (Structured Query
Language (strukturierte Abfragesprache)) auf eine interaktive und
programmierende Standardsprache zum Bekommen von Information von
einer Datenbank und Aktualisierung derselben.
-
„Startseite
(start page)" auf
eine zum Zugriff bei einer World Wide Web-Site verfügbare Datei,
die für
einen eindeutigen Benutzer, nachdem der Benutzer sich in die/bezüglich der
Website angemeldet hat, vorgesehen ist.
-
„Symmetrische
Verschlüsselung" auf einen Typ von
Verschlüsselung,
bei dem zum Verschlüsseln
und Entschlüsseln
der Nachricht der gleiche Schlüssel
benutzt wird.
-
„Virtuell
(virtual)" bedeutet
generell die Qualität
der Bewirkung von Etwas ohne dieses Etwas tatsächlich zu sein.
-
„Website" auf eine Sammlung
von Web-Dateien bezüglich
eines speziellen Subjekts, die eine als eine Homepage bezeichnete
Beginndatei enthält.
-
„World
Wide Web" auf einen
Informationsserver bezüglich
des Internets, der aus miteinander verbundenen Sites und Dateien
zusammengesetzt ist, auf die mit einem Browser zugegriffen werden kann.