DE60007883T2

DE60007883T2 - Verfahren und vorrichtung zum durchführen von elektronischen transaktionen

Info

Publication number: DE60007883T2
Application number: DE60007883T
Authority: DE
Inventors: Russell Bennett; Fred Bishop; Elliot Glazer; Zyg Gorgol; G. William HOHLE; David Johnstone; D. Walter LAKE; Marvin Simkin; Nick Swift; Dirk White; Michael Johnson; Coby Royer
Original assignee: American Express Travel Related Services Co Inc
Current assignee: Gula Consulting LLC
Priority date: 1999-08-31
Filing date: 2000-08-30
Publication date: 2004-10-14
Anticipated expiration: 2020-08-31
Also published as: KR100806993B1; DZ3214A1; HUP0202471A2; WO2001016900A2; HK1048550A1; AU775976B2; TR200201280T2; JP2011060291A; CZ2002744A3; HK1048550B; ES2215064T3; NZ517840A; TR200202436T2; CA2382922A1; WO2001016900A3; SI1212732T1; KR20020039339A; HRP20020180A2; EP1212732B1; BR0013822A

Description

Gebiet der Erfindung
Die Erfindung bezieht sich im allgemeinen auf Verfahren und Vorrichtungen zur Durchführung von Netzwerktransaktionen. Genauer gesagt bezieht sich die Erfindung auf Systeme zur Authentifizierung und Durchführung von Geschäften über Datennetzwerke, wie z.B. das Internet.
Hintergrund der Erfindung
In den letzten Jahren entdeckten viele Konsumenten die Bequemlichkeit und Wirtschaftlichkeit einer elektronischen Beschaffung von Waren bzw. Gütern und Dienstleistungen. Es ist eine Anzahl von Kanälen für elektronische Beschaffungen bzw. Einkäufe (üblicherweise "e-Beschaffungen" genannt), verfügbar, einschließlich kaufe-von-zu-Hause-Fernsehnetzwerke, Anrufantworten auf Fernsehwerbungen und dgl. Seit ganz kurzer Zeit wurde eine Direktbeschaffung bzw. ein Direkteinkauf über das Internet extrem populär.
Bei einer typischen Internet-Transaktion identifiziert ein Konsument bzw. Kunde im allgemeinen Waren und/oder Dienstleistungen zur Beschaffung durch Betrachtung einer Online-Werbung, wie z.B. ein Dokument in Hypertext Markup Language (HTML), welches über einen World Wide Web (WWW) Browser zur Verfügung gestellt wird. Eine Bezahlung geht typischerweise über eine Kundenkartennummer bzw. Zahlkartennummer, welche über einen sicheren Kanal, wie z.B. eine Secure Sockets Layer (SSL) Verbindung zur Verfügung gestellt wird, welche zwischen dem Konsumenten und dem Händler aufgebaut bzw. etabliert ist. Eine Kundenkarten-Kontonummer ist typischerweise eine sechzehnstellige Kreditkartennummer. Kreditkartennummern entsprechen typischerweise einem standardisierten Format, wobei sie vier beabstandete Sätze von Nummern bzw. Zahlen haben, wie dies durch die Nummer bzw. Zahl "0000 0000 0000 0000" repräsentiert wird. Die ersten fünf bis sieben Stellen sind für Verarbeitungszwecke reserviert und identifizieren die ausstellende Bank, Kartentyp, usw. Die letzte sechzehnte Stelle wird als Summenprüfung für die sechzehnstellige Zahl verwendet. Die dazwischenliegenden acht bis zehn Stellen werden zur eindeutigen Identifikation des Konsumenten verwendet. Der Händler verarbeitet dann die Kundenkartennummer beispielsweise durch ein Empfangen einer direkten Direktautorisierung von dem Kartenaussteller, dann komplettiert bzw. vollendet der Händler die Transaktion. Der SSL Standard wird beschrieben beispielsweise durch "Die SSL Protokoll Version 3.0", datierend mit 18. November 1996, welche online verfügbar ist unter: http://home.netscape.com/eng/ssl/3/draft302.txt.
Obwohl jeden Tag Millionen von Transaktionen über das Internet erfolgen, weisen konventionelle SSL Transaktionen oft eine Anzahl von merklichen Nachteilen auf. Obwohl SSL typischerweise eine sichere Ende-Zu-Ende-Verbindung zur Verfügung stellt, welche ein Abhören (z.B. "Schnüffeln") durch gewissenlose Drittparteien oder ein Erhalten der Kundenkartennummer eines Käufers auf andere Weise verhindert, stellt das Protokoll keinerlei Mittel zur Verfügung, um sicherzustellen, daß die Kundenkartennummer selbst gültig ist oder daß die Person, welche über die Kartennummer verfügt, rechtsgültig dazu autorisiert ist. Durch das hohe Auftreten von Betrug bei Internettransaktionen betrachten die meisten Kundenkartenaussteller Netzwerktransaktionen als "Karte nicht-vorhanden" bzw. "Card Not Present"-Transaktionen, welche einem höheren Diskontsatz unterworfen sind. Anders ausgedrückt, berechnen durch das erhöhte Risiko von "Kartenicht-vorhanden"-Transaktionen, die meisten Kundenkartenaussteller dem Händler einen höheren Satz für ein Akzeptieren von Kartennummern über elektronische Mittel, als verrechnet würde, wenn die Karte physikalisch dem Händler präsentiert wurde.
Um die Sicherheitsmängel zu verbessern, welche einem Transportieren von Kundenkartennummern über unsichere Netzwerke inhärent sind, haben viele die Verwendung von "Smart Cards" bzw. Chipkarten nahegelegt. Smart Cards beinhalten typischerweise einen Chip einer integrierten Schaltung, welcher einen Mikroprozessor und einen Speicher zur Speicherung von Daten direkt auf der Karte hat. Die Daten können beispielsweise einem kryptografischen Schlüssel oder einer elektronischen Geldbörse entsprechen, welche einen elektronischen Wert an Bargeld enthält bzw. bietet. Im Stand der Technik wurden viele Smart Card Schemata angeregt, jedoch weisen diese typischerweise einen merklichen Nachteil darin auf, daß sie nicht standardisiert sind. Mit anderen Worten, müssen die Händler typischerweise neue, proprietäre Software für deren Web-Fassaden besorgen, um Smart Card Transaktionen zu akzeptieren. Darüber hinaus waren die Verwaltungs- bzw. Administrationskosten, welche bei einem Zuordnen und Instandhalten der kryptografischen Information in Verbindung mit Smart Cards beteiligt sind, bis zum heutigen Datum exzessiv bzw. übermäßig.
Der Secure Electronic Transaction (SET) bzw. sichere elektronische Transaktionsstandard wurde vorgeschlagen, um die Sicherheit von Internettransaktionen durch die Benützung von verschiedenen kryptografischen bzw. Verschlüsselungstechniken zu verbessern. Obwohl SET eine verbesserte Sicherheit gegenüber Standard SSL Transaktionen zur Verfügung stellt, hat die Administration, welche an den verschiedenen öffentlichen und privaten Schlüsseln beteiligt ist, die zur Durchführung von Transaktionen erforderlich sind, die weitverbreitete Akzeptanz von SET begrenzt. Auch macht SET spezielle Software für jene Händler erforderlich, welche es wünschen, SET Transaktionen zu unterstützen.
Die existierende Technologie einer digitalen Geldbörse bzw. Brieftasche, wie die Technologie der digitalen Brieftasche, welche beispielsweise von G1obeSet, Inc., 1250 Capital of Texas Highway South, Building One, Suite 300, Austin, TX, 78746 zur Verfügung gestellt wird, stellt Mittel für Konsumenten bzw. Kunden zur Verfügung, um Transaktionskartenprodukte anzuwenden (z.B. Kredit, Zahlung, Belastung, Smart Cards, Kontonummern und ähnliches), um für Produkte und Dienstleistungen on-line zu bezahlen. Im allgemeinen sind digitale Brieftaschen Werkzeuge bzw. Tools, welche persönliche Information speichern (Name, Adresse, Kundenkartennummer, Kreditkartennummer, usw.), um einen elektronischen Handel oder andere Netzwerkinteraktionen zu erleichtern. Die persönliche Information kann auf einem allgemeinen Server gespeichert sein oder auf einer Kundenörtlichkeit (PC oder Smart Card) oder auf einem Hybrid von sowohl einem allgemeinen Server wie auch einem Kundenserver bzw. Clientserver. Der allgemeine Server der digitalen Brieftasche umfaßt einen Webserver und einen Datenbankserver, welcher die persönlichen und Kreditkarteninformationen des Kunden, Einkaufsvorlieben und Profile von Online-Händlern zentral enthält.
Eine digitale Geldbörse bzw. Brieftasche führt vorzugsweise Funktionen durch, wie z.B. ein einzelnes Anmelden/ein Paßwort, ein automatisches Ausfüllen von Formularen von Überprüfungsseiten, Einkaufen mit einem oder zwei Klick(s), eine Personalisierung von Websites bzw. Webseiten, Online-Bestellung und Auslieferungsverfolgung, aufgegliederte elektronische Belege und an die Kundenwünsche angepaßte Offerte und Promotionen, basierend auf dem Aufwenden von Mustern und Anmeldungen bzw. Eintragungen. Genauer gesagt aktiviert ein Einkauf mit einem Klick die Geldbörse und bestätigt zur selben Zeit die Beschaffung. Eine Überprüfung bzw. ein Austrag mit zwei Klicks aktiviert zuerst die Geldbörse, worauf der zweite Klick die Beschaffung bzw. den Einkauf bestätigt.
Im Einsatz wird ein Lesezeichen der Brieftasche bzw. Geldbörse typischerweise durch den Kunden geklickt und es wird eine SSL Sitzung mit dem Brieftaschenserver etabliert bzw. aufgebaut. Ein Browser-Plug-in bzw. Browser-Zusatzprogramm wird ausgeführt und der Kunde gibt eine/ein ID/Paßwort oder eine Smart Card zur Authentifizierung ein, um einen Zugriff auf die Brieftaschendaten zu erlangen. Beim Einkaufen bei einem Online-Händler werden die passenden bzw. entsprechenden Brieftaschendaten von dem Brieftaschenserver zu dem Webserver des Händlers transferiert.
US-A-5,534,857 (BOWCOCK, MATTHEW P et al.), 9. Juli 1996, offenbart ein Verfahren und eine Vorrichtung für ein sicheres Schreiben von vertraulichen Daten von einem Aussteller bzw. Ausgeber an eine Smart Card eines Kunden ohne jegliche Möglichkeit, Zeugnisse bzw. Beglaubigungsschreiben bzw. Berechtigungsnachweise für einen Anwender zur Verfügung zu stellen, um einen Zugriff auf einen Dienst zur Verfügung zu stellen, nach einer Authentifizierung über eine Aufforderungsantwort.
US-A-5,832,212 (CRAGUN, BRIAN JOHN et al.), vom 3. November 1998, offenbart einen zensierenden Browser für ein Betrachten des Internet ohne einer Fernverarbeitung eines Scannens bzw. Abtastens von bestimmten Zeichen.
EP-A-O 917 120 (CITICORP DEV CENTER INC), vom 19. Mai 1999, offenbart einen digitalen Brieftaschenklient zum Erleichtern von elektronischen Transaktionen über ein digitales Netzwerk in Verbindung mit einem Browserprogramm.
Ein neues System zur Durchführung von elektronischen Übersetzungen wird deshalb gewünscht. Ein derartiges System sollte eine verbesserte Sicherheit zur Verfügung stellen, ohne zusätzliche Geschäftskosten für Kunden und Händler. Darüber hinaus sollte ein derartiges neues System gut in verschiedene Internet-Brieftaschen und andere Dienste bzw. Dienstleistungen integrierbar sein, welche von verschiedenen Anbietern zur Verfügung gestellt werden.
Zusammenfassung der Erfindung
Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren für ein Durchführen einer Transaktion zur Verfügung gestellt, wie dies in Anspruch 1 definiert ist.
Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Transaktionssystem zur Verfügung gestellt, um eine finanzielle Transaktion zu erleichtern, welche von einem Anwender bzw. Benutzer angefordert wird, der einen Anwender computer in einem Datennetzwerk betreibt, wie dies in Anspruch 5 definiert ist.
Gemäß einem anderen Aspekt der vorliegenden Erfindung wird eine Computer-implementierte Erfindung zur Verfügung gestellt, wie dies in Anspruch 17 definiert ist.
Ebenso wird hierin ein Computer-implementiertes Verfahren beschrieben, um einen Netzwerkserver davor zu schützen, als die Basis für einen Angriff auf einen Netzwerk-Klient verwendet zu werden, wobei das Verfahren umfaßt:
a. Empfangen einer Anfrage für eine Verbindung auf dem Server von dem besagten Netzwerk-Klient; und
b. Abtasten eines Bereichs des Netzwerkservers nach bestimmten Zeichen, die einem Protokoll zugehörig sind;
c. Nachprüfen bzw. Verifizieren, daß jegliche Antwort von dem Netzwerkserver an den besagten Netzwerk-Klient leer von speziellen Zeichen ist; und
d. Bereitstellen der Antwort von dem Netzwerkserver an den Netzwerk-Klienten.
Das Verfahren kann darüber hinaus einen einschränkenden Zugriff auf dem Netzwerkserver für das Protokoll zu dem Bereich des Netzwerkservers umfassen. Die speziellen Zeichen können durch gutartige Zeichen ersetzt werden, so daß ein Sicherheitsrisiko, welches durch das ausgewählte Protokoll dargestellt wird, reduziert wird, und optional können die speziellen Zeichen registriert werden, um ein Sicherheitsprotokoll zu bilden. Das Sicherheitsprotokoll kann überprüft werden, um zu bestimmen, ob die speziellen Zeichen feindselig sind.
Bei einer Ausführungsform umfaßt das Protokoll Javascript.
Dieses Verfahren kann zum Schutz des Netzwerkservers während einer elektronischen Einkaufstransaktion angewendet werden, beispielsweise wo die elektronische Einkaufstransaktion unter Benützung einer digitalen Brieftasche durchgeführt wird.
Ebenso wird hierin ein digitaler Brieftaschen-Klient beschrieben, um elektronische Transaktionen über ein digitales Netzwerk in Verbindung mit einem Browserprogramm zu erleichtern, wobei der digitale Brieftaschen-Klient umfaßt:
a. eine Brieftaschen-Applikation, welche dazu konfiguriert ist, um eine Sitzung bzw. Session mit einem Brieftaschenserver über das digitale Netzwerk in Beantwortung von Eingaben von einem Anwender zu veranlassen; und
b. eine Schnittstelle bzw. ein Interface zu einer Lesevorrichtung, wobei die Lesevorrichtung dazu konfiguriert ist, um ein Token bzw. bzw. eine Berechtigungsmarke zu akzeptieren, um die Identität des Anwenders zu verifizieren bzw. zu überprüfen; und
wobei die Brieftaschenapplikation operabel ist, um den Anwender an dem Brieftaschenserver zu authentifizieren, indem das Token verwendet wird, und um den Brieftaschenserver über das digitale Netzwerk zu kontaktieren, um die elektronischen Transaktionen zu vollenden.
Die digitale Brieftasche kann weiters einen Aktivator umfassen, um auf den Brieftaschenserver zuzugreifen, wobei der Aktivator Information mit dem Brieftaschenserver austauscht, um die elektronischen Transaktionen zu komplettieren.
Die digitale Brieftaschenanwendung kann weiters dazu konfiguriert sein, um den Anwender bei dem Brieftaschenserver zu authentifizieren, wenigstens teilweise darauf basierend, daß ein Zeugnis bzw. Berechtigungsnachweis an dem digitalen Brieftaschen-Klient von einem Sicherheitsserver in dem digitalen Netzwerk empfangen wird.
Der Aktivator des digitalen Brieftaschen-Klienten kann einen Statusindikator umfassen, welcher dem Anwender angezeigt wird, wobei der Statusindikator der Verfügbarkeit von Brieftaschendiensten für eine Website- bzw. Webseite entspricht.
Die Brieftaschenanwendung bzw. -applikation kann weiters dazu konfiguriert sein, daß eine digitale Signatur von dem Token erhalten wird und um die besagte digitale Signatur an den Brieftaschenserver über das digitale Netzwerk zur Verfügung zu stellen.
Ebenso beschrieben wird ein Brieftaschenserver zur Erleichterung einer Transaktion über ein digitales Netzwerk, wobei der Brieftaschenserver umfaßt:
a. eine Schnittstelle bzw. ein Interface zu einem digitalen Netzwerk; und
b. eine Brieftaschenserverapplikation in Kommunikation mit einer Datenbank, wobei der Brieftaschenserver dazu konfiguriert ist, eine Anfrage für eine Transaktion von einem Brieftaschen-Klient zu empfangen, um ein Zeugnis bzw. einen Berechtigungsnachweis zu verarbeiten, welches (r) von dem Brieftaschen-Klient empfangen wurde, um einen Anwender des Brieftaschen-Klienten zu authentifizieren, um Anwenderinformationen von der Datenbank nach der Authentifizierung des Anwenders abzufragen, und um die Transaktion im Namen des Anwenders zu komplettieren, wobei die Anwenderinformation benützt wird.
Der Berechtigungsnachweis kann eine digitale Signatur umfassen. Der Berechtigungsnachweis kann weiters einen zufälligen Auszug umfassen, welcher digital von einem Token signiert wurde, welches im Besitz des Anwenders ist.
Der Auszug kann an den Brieftaschen-Klienten durch einen Sicherheitsserver zur Verfügung gestellt werden.
Bei einer derartigen Ausführungsform umfaßt ein Komplettieren der Transaktion im Namen des Anwenders typischerweise ein Komplettieren eines Händlerformulars mit der Anwenderinformation.
Ebenso beschrieben wird ein computerimplementiertes bzw. in einem Computer implementiertes Verfahren zur Erleichterung einer Online-Beschaffung, umfassend die Schritte:
Authentifizieren an einem Sicherheitsserver;
Empfangen eines Zeugnisses bzw. Berechtigungsnachweises von dem Sicherheitsserver;
Identifizieren einer Händleradresse, von welcher die Beschaffung bzw. der Einkauf durchzuführen ist;
Bereitstellen des Berechtigungsnachweises an einen Brieftaschenserver, um den Anwender an dem Brieftaschenserver zu authentifizieren;
nach erfolgreicher Authentifizierung an dem Brieftaschenserver Umleiten von Kommunikationen mit der Händleradresse an dem Brieftaschenserver, so daß der Brieftaschenserver Einkaufs- bzw. Beschaffungsinformation über den Anwender an die Händleradresse zur Verfügung stellt; und
Empfangen einer Bestätigung für die Ergebnisse des Einkaufs .
Weiters wird hierin ein computerimplementiertes Verfahren zur Erleichterung einer Online-Beschaffung beschrieben, umfassend die Schritte:
Empfangen einer Anforderung für eine Transaktion von einem Anwender an einem Server, wobei die Anforderung eine Händleradresse und einen Berechtigungsnachweis umfaßt;
Verifizieren des Berechtigungsnachweises, um den Anwender zu authentifizieren;
Abfragen von Anwenderinformation von einer Datenbank in Beantwortung des Verifizierungsschritts;
Komplettieren eines Online-Formulars entsprechend der Händleradresse; und
Bereitstellen eines Einkaufsergebnisses an den Anwender.
Der Berechtigungsnachweis kann eine digitale Signatur umfassen. Der Berechtigungsnachweis kann weiters Daten umfassen, welche von einem Sicherheitsserver empfangen wurden.
In einer Ausführungsform ist der Sicherheitsserver an dem Server angegliedert.
Die digitale Signatur kann von einer Smart Card erzeugt werden.
In beispielhaften Ausführungsformen der Erfindung wird einem Anwender ein intelligentes Token zur Verfügung gestellt, wie z.B. eine Smart Card, welche bei der Durchführung von elektronischen Transaktionen verwendet werden kann. Das intelligente Token beinhaltet ein digitales Zertifikat und authentifiziert sich passend bei einem Server in dem Netzwerk, welches die gesamte oder Bereiche der Transaktion im Namen des Anwenders durchführt. Der Anwender ist ein Abnehmer bzw. Käufer, welcher eine Einkaufstransaktion durchführt, und der Server ist ein Brieftaschenserver, welcher mit einem Sicherheitsserver zusammenwirkt, um eine erweiterte Zuverlässigkeit und Vertrauen in die Transaktion zur Verfügung zu stellen.
Elektronische Transaktionen, wie beispielsweise Einkaufstransaktionen, werden durchgeführt durch:
Empfangen einer Transaktionsanforderung von einem Anwender an einem Server: Ausgeben einer Aufforderung an den Anwender; Empfangen einer Antwort von dem Anwender, basierend auf der Aufforderung; Verarbeiten der Antwort, um ein Transaktionsinstrument zu verifizieren; Zusammenstellen von Berechtigungsnachweisen, welche wenigstens einen Schlüssel für die elektronische Transaktion beinhalten; Bereitstellen wenigstens eines Bereichs der Berechtigungsnachweise an den Anwender; Empfangen einer zweiten Anforderung von dem Anwender, welche den Bereich der Berechtigungsnachweise einschließt; und Validisieren des Bereichs der Berechtigungsnachweise mit dem Schlüssel, um einen Zugriff zu einem Transaktionsdienst zur Verfügung zu stellen.
Darüber hinaus schützt die Erfindung einen Netzwerkserver vor einem Angriff durch: Beschränken eines Zugriffs auf den Netzwerkserver auf einen Bereich des Netzwerkservers für wenigstens ein ausgesuchtes bzw. ausgewähltes Protokoll und ein Scannen bzw. Abtasten des Bereichs des Netzwerkservers auf bestimmte Zeichen, welche dem ausgewählten Protokoll zugehörig bzw. zugeordnet sind. Die speziellen bzw. bestimmten Zeichen können entfernt oder durch freundliche Zeichen ersetzt werden, um das Sicherheitsrisiko zu redu zieren, welche das ausgewählte Protokoll darstellt. Vorzugsweise können die Zeichen registriert bzw. protokolliert werden, um ein Sicherheitsprotokoll zu bilden. Das Sicherheitsprotokoll kann überprüft werden, um zu bestimmen, ob die bestimmten Zeichen feindlich sind. Alternativ kann eine Anforderung zurückgewiesen werden.
Die vorliegende Erfindung beinhaltet auch ein Transaktionswerkzeug bzw. -tool, wie z.B. eine digitale Brieftasche, welche zur Durchführung von Einkaufstransaktionen verwendet wird, welche einen Aktivator und eine Werkzeugleiste bzw. einen Werkzeughalter bzw. Toolbar aufweist. Vorzugsweise gestattet es die Werkzeugleiste einem Anwender, ein kleines Download des Aktivators durchzuführen, und die Werkzeugleiste setzt eine oder mehrere Betriebssystemsteuerungen ein, z.B. ein Systemablagesymbol bzw. -icon. Das Transaktionswerkzeug beinhaltet auch eine Formularausfüllkomponente und eine automatische Erinnerungskomponente zum Vorausfüllen von Formularen mit Information, welche vorher durch den Anwender zur Verfügung gestellt wurde.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die obigen und andere Merkmale und Vorteile der vorliegenden Erfindung werden nachfolgend in der nachfolgenden detaillierten Beschreibung von beispielhaften Ausführungsformen beschrieben, welche im Zusammenhang mit den beigeschlossenen Zeichnungsfiguren zu lesen ist, wobei gleiche Bezugszeichen verwendet werden, um die gleichen oder ähnliche Teile in den ähnlichen Ansichten zu bezeichnen, und:
1A bis 1C Blockdiagramme von verschiedenen Ausführungsformen eines beispielhaften Transaktionssystems sind;
2 ein Blockdiagramm eines beispielhaften Einkaufssystems ist;
3 ein Blockdiagramm eines beispielhaften Sicherheitssystems ist;
4 eine Blockdiagramm eines beispielhaften Brieftaschenservers ist;
5 bis 8 beispielhafte Bildschirmdarstellungen einer Ausführungsform einer digitalen Brieftasche sind, welche in Übereinstimmung mit der vorliegenden Erfindung ausgebildet ist;
9 ein Flußdiagramm eines beispielhaften Verfahrens bzw. Prozesses ist, welches(r) durch eine beispielhafte Aktivator- bzw. Aktivierungsanwendung ausgeführt wird;
10 ein Botschaftssequenzdiagramm einer beispielhaften Einlog-Sequenz ist;
11 ein Botschaftssequenzdiagramm einer beispielhaften Einkaufssequenz ist;
12A ein Botschaftssequenzdiagramm ist, welches ein mögliches Sicherheitsproblem illustriert, welches bei vielen Skript-Sprachen angetroffen wird;
12B ein Botschaftssequenzdiagramm eines korrekten Kommunikationsflusses ohne die Sicherheitsprobleme ist, welche in 12A gezeigt sind; und
13 ein Flußdiagramm eines beispielhaften Prozesses zum Reduzieren oder Eliminieren eines unerwünschten, ausführbaren bzw. exekutierbaren Codes ist.
DETAILLIERTE BESCHREIBUNG VON BEVORZUGTEN, BEISPIELHAFTEN AUSFÜHRUNGSFORMEN
Die vorliegende Erfindung kann hierin in Termen von funktionalen Blockkomponenten und verschiedenen Be- bzw. Verarbeitungsschritten beschrieben werden. Es sollte geschätzt bzw. erkannt werden, daß derartige funktionale Blöcke durch eine beliebige Anzahl von Hardware- und/oder Softwarekomponenten realisiert werden kann, welche konfiguriert sind, um die bestimmten Funktionen durchzuführen bzw. zu erfüllen. Beispielsweise kann die vorliegende Erfindung verschiedene Komponenten einer integrierten Schaltung (I.C.), beispielsweise Speicherelemente, be- bzw. verarbeitende bzw. Prozessorelemente, logische Elemente, Nachschautabellen und dgl. verwenden, welche eine Vielzahl von Funktionen unter der Regelung bzw. Steuerung von einem oder mehreren Mikroprozessoren) oder anderen Regel- bzw. Steuervorrichtungen durchführen können. In ähnlicher Weise können die Softwareelemente der vorliegenden Erfindung mit jeder Programmoder Skriptsprache, wie beispielsweise C, C++, Java, COBOL, Assembler, PERL oder dgl. implementiert werden, wobei die verschiedenen Algorithmen mit jeder beliebigen Kombination von Datenstrukturen, Objekten bzw. Gegenständen, Verfahren bzw. Prozessen, Routinen oder anderen Programmierelementen implementiert sind bzw. werden. Weiters sollte festgestellt werden, daß die vorliegende Erfindung eine beliebige Anzahl von konventionellen Techniken für eine Datenübertragung, eine Signalübertragung, eine Datenbe- bzw. -verarbeitung, eine Netzwerksteuerung bzw. -regelung und dgl. verwenden kann. Noch weiters könnte die Erfindung verwendet werden, um Sicherheitsdetails bzw. -fragen mit einer Skript-Sprache, wie beispielsweise JavaScript, VBScript oder dgl., zu detektieren oder zu verhindern.
Es sollte geschätzt bzw. erkannt werden, daß die speziellen Implementierungen, welche hier gezeigt und beschrieben sind, für die Erfindung und ihre beste Ausführungsform illustrativ sind und daß nicht beabsichtigt ist, andernfalls den Rahmen der vorliegenden Erfindung in irgendeiner Weise zu beschränken. Tatsächlich können aus Gründen der Kürze ein konventionelles Daten-Netzwerk arbeiten, eine Applikations- bzw. Anwendungsentwicklung und andere funktionale Aspekte der Systeme (und Komponenten der einzelnen Betriebs- bzw. Betätigungskomponenten der Systeme) hier nicht im Detail beschrieben werden. Darüber hinaus sollen die in den verschiedenen, hierin enthaltenen Figuren gezeigten Verbindungslinien beispielhafte, funktionelle Zusammenhänge und/oder physikalische Kopplungen bzw. Verbindungen zwischen den verschiedenen Elementen repräsentieren. Es sollte festgehalten werden, daß viele alternative oder zusätzliche funktionelle Zusammenhänge oder physikalische Verbindungen in einem praktischen, elektronischen Transaktionssystem vorhanden sein können.
Um die Beschreibung der beispielhaften Ausführungsformen zu vereinfachen, wird die Erfindung oft beschrieben, daß sie sich auf ein System eines elektronischen Handels bezieht, welcher über das Internet abläuft. Es wird geschätzt bzw. erkannt werden, daß jedoch viele Anwendungen der vorliegenden Erfindung formuliert werden könnten. Beispielsweise könnte das System verwendet werden, um Anwender bzw. Benutzer eines Computersystems zu authentifizieren, oder ein Zugangscodesystem zu aktivieren oder zu irgendeinem anderen Zweck. In ähnlicher Weise könnte die Erfindung im Zusammenhang mit irgendeiner Art eines Personal Computers, eines Netzwerkcomputers, einer Arbeitsstation, eines Minicomputers, eines Mainframe oder dgl. verwendet werden, auf welchen irgendein Betriebsystem läuft, wie beispielsweise irgendeine Version von Windows, Windows NT, Windows2000, Windows 98, Windows 95, MacOS, OS/2, BeOS, Linux, UNIX oder dgl. Darüber hinaus wird, obwohl die Erfindung auch hierin oft beschrieben ist, daß sie mit TCP/IP-Kommunikationspro tokollen implementiert ist, leicht verstanden werden, daß die Erfindung auch unter Verwendung von IPX, Appletalk, IP-6, NetBIOS, OSI, oder einer beliebigen Anzahl von existierenden oder zukünftigen Protokollen implementiert sein könnte.
Darüber hinaus können der Kunde oder Händler eine einzelne Person, eine juristische Person oder ein Geschäft bzw. eine Firma darstellen, während die Bank andere Arten von eine Karte ausgebenden Institutionen, wie beispielsweise Kreditkartenfirmen, Kartensponsorfirmen oder Aussteller von Drittfirmen repräsentieren kann, welche unter Vertrag mit Finanzinstituten sind. Das Zahlungsnetzwerk beinhaltet existierende proprietäre Netzwerke, welche gegenwärtig Transaktionen für Kreditkarten, Kontokarten und andere Arten von Finanz/Bankkarten aufnehmen. Das Zahlungsnetzwerk ist ein geschlossenes Netzwerk, von welchem angenommen wird, daß es gegenüber Abhöreinrichtungen, wie beispielsweise das American Express^® Network, VisaNet^® Network und Veriphone^® sicher ist.
Zusätzlich können andere Teilnehmer in einigen Phasen der Transaktion, wie beispielsweise eine zwischengeschaltete Abrechnungs- bzw. Abschlußinstitution involviert sein, wobei diese Teilnehmer nicht gezeigt sind. Jeder Teilnehmer ist mit einem Berechnungs- bzw. Computersystem ausgerüstet, um Transaktionen zu erleichtern. Der Kunde hat einen Personal Computer, der Händler hat einen Computer/Server und die Bank hat einen Mainframe-Computer; es können jedoch jegliche der Computer ein Mini-Computer, ein PC-Server, ein Netzwerksatz von Computern, Laptops, Notebooks, Handhelds, Tischcomputern und dgl. sein.
Unter Bezugnahme nunmehr auf 1A beinhaltet ein Transaktionssystem 100 in geeigneter Weise wenigstens einen Anwendercomputer 110, einen Transaktions-Autorisierungscomputer 120, einen Sicherheits-Server 130, einen optionellen Transaktionswerkzeugserver 140. In verschiedenen Ausführungsformen, welche im Detail hier beschrieben sind, wird das Transaktionssystem 100 in elektronischem Handel verwendet, um Einkaufstransaktionen bzw. -vorgänge durchzuführen. Spezifisch ist der Benutzer- bzw. Anwendercomputer 110 ein Käufer- oder Kundencomputer, der Transaktions-Autorisierungscomputer 120 ist ein Händlercomputer und der Transaktions-Tool- bzw. -Werkzeugserver 140 ist ein digitaler Brieftaschenserver. Es wird geschätzt bzw. erkannt werden, daß, obwohl das hierin beschriebene Transaktionssystem ein elektronisches Handelssystem ist, die vorliegende Erfindung in gleicher Weise auf verschiedene andere elektronische Transaktionssysteme anwendbar ist.
Die verschiedenen Computersysteme und Server werden miteinander in geeigneter Weise durch ein Datennetzwerk 102 verbunden, welches ein beliebiges Datennetzwerk ist, wie beispielsweise das Internet oder ein anderes öffentliches Datennetzwerk. Andere geeignete Netzwerke 102 beinhalten das öffentlich geschaltete Telefonnetzwerk (PSTN), Firmen- oder Universitäts-Intranetze und dgl. In verschiedenen Ausführungsformen, wie beispielsweise der einen, welche in 1B gezeigt ist, ist ein Händlercomputer 120 elektronisch mit einem Sicherheitsserver 130 durch eine Datenverbindung 152 gekoppelt bzw. verbunden, welche von dem Netzwerk 102 getrennt ist. In ähnlicher Weise beinhalten verschiedene Ausführungsformen eine Verbindung 150 getrennt von dem Netzwerk 102, welches den Brieftaschenserver 140 und Sicherheitsserver 130 verbindet. Beispielhafte Datenverbin dungen, welche für eine Verwendung mit den Verbindungen 150 und 152 geeignet sind, beinhalten Telefonverbindungen, ISDN-Verbindungen, zugeordnete bzw. zugewiesene T1 oder andere Datenverbindungen, drahtlose Verbindungen und dgl. Es wird geschätzt bzw. erkannt werden, daß die Verbindung 150 und die Verbindung 152 identische Verbindungen sein können oder daß jede von einer vollkommen verschiedenen Form einer Verbindung in verschiedenen Ausführungsformen der Erfindung sein kann.
Verschiedene Ausführungsformen, wie beispielsweise die eine, welche in 1C gezeigt ist, beinhalten auch einen Applikations- bzw. Anwendungsserver 160. In verschiedenen Ausführungsformen können Datenbanken (nicht gezeigt) und/oder Profilserver (nicht gezeigt) mit dem Anwendungsserver 160 und/oder dem Brieftaschenserver 140 verbunden werden. Der Anwendungsserver 160 kann verwendet werden, um die Arbeitslast bzw. -belastung auszugleichen. Ein Verteilen der Arbeitslast bzw. Belastung zwischen der digitalen Brieftasche 140 und dem Anwendungsserver 160 kann die Effizienz und/oder Sicherheit erhöhen. Beispielsweise kann dem Anwendungsserver 160 einiges der Funktionalität durchführen, welche durch den Brieftaschenserver 140 durchgeführt wird, wie beispielsweise einen Datenbankzugang. Da der Anwendungsserver 160 nicht mit dem Datennetzwerk 102 verbunden ist, kann die Sicherheit dadurch erhöht werden, daß ein Datenbankzugang durch den Anwendungsserver 160 anstatt durch den Brieftaschenserver 140 durchgeführt wird.
Während verschiedene beispielhafte Ausführungsformen in 1A – 1C illustriert sind, wird erkannt bzw. geschätzt werden, daß andere Ausführungsformen möglich sind. Beispielsweise kann eine Ausführungsform eine Verbindung 150, jedoch nicht die Verbindung 152 beinhalten, oder umgekehrt. Darüber hinaus können Komponenten (beispielsweise Kunde 110, Händler 120, Sicherheitsserver 130, Brieftaschenserver 140 und Anwendungsserver 160) einzelne bzw. individuelle Computer oder vernetzte Gruppen von Computern sein, welche mit einem ähnlichen bzw. gleichen Zweck arbeiten, um die hierin beschriebenen Funktionen zu erfüllen. Eine Funktionalität, welche einer einzelnen Komponente zugeordnet ist, kann unter einem oder mehreren individuellen Computern verteilt werden, um die beschriebene Funktionalität zu erfüllen. Beispielsweise kann der Brieftaschenserver 140 tatsächlich eine Sammlung von Web-Servern, Anwendungsservern, Datenbankservern oder anderen Arten von Servern sein.
Um eine Transaktion durchzuführen, baut ein Kunde 110 in geeigneter Weise eine Verbindung durch das Netzwerk 102 mit einem Händler 120 auf. Wenn ein Einkauf getätigt werden soll, greift der Kunde 110 auf den Brieftaschenserver 140 zu. Der Kunde 110 wird dann zu dem Sicherheitsserver 130 umgeleitet, um zu verifizieren, daß sich eine Smartcard im Besitz des Kunden befindet. Die Smartcard kann ein digitales Zertifikat beinhalten, welches einzigartig die Karte derart identifiziert, daß digitale Beglaubigungen bzw. Berechtigungsnachweise, welche sich auf die Transaktion beziehen, erzeugt werden können, wie dies unten beschrieben ist. In verschiedenen Ausführungsformen werden Abschnitte der digitalen Berechtigungsnachweise zu dem Kunden 110 retourniert und ein Abschnitt wird an den Brieftaschenserver 140 über eine sichere Verbindung 150 zur Verfügung gestellt. Der Kunde 110 kann dann die digitalen Berechtigungsnachweise verwenden, um sich bei einem Brieftaschenserver 140 zu authentifizieren, wobei dieser die elektronische Transaktion als ein Ersatz für den Kunden 110 vervoll ständigen kann. Der Brieftaschenserver 140 kann eine Funktionalität zum Vervollständigen von Einkaufsformularen beinhalten, welche beispielsweise dem Händlercomputer 120 zugeordnet sind. Wenn der Händler 120 einen Identifizierer für ein sicheres Einkaufsinstrument von einem Kunden 110 oder vom Brieftaschenserver 140 erhält, kann eine Kartenautorisierung über die Verbindung 152 wie bei jeder gewöhnlichen Kreditkartenautorisierung stattfinden. Wie oben beschrieben, können die Kommunikationen unter Verwendung von verschiedenen Protokollen, wie beispielsweise SSL oder VPN und dgl. durchgeführt werden. Da die Smartcard identifizierende Information enthält, welche für die spezielle Karte einzigartig ist und welche dem Netzwerk durch elektronische Mittel bekannt gemacht werden kann, ist ein Einkaufsvorgang bzw. eine Einkaufstransaktion, welche(r) mit der Chip- bzw. Smartcard durchgeführt wird, sicherer als eine Transaktion, welche mit einer üblichen Zahlungs- oder Kreditkarte durchgeführt wird. Ein geringerer Diskontsatz kann für die sichere Transaktion gerechtfertigt sein, welcher durch den Kartenausgeber als eine Transaktion "Karte vorhanden" bzw. "Card Present" bearbeitet werden kann. Zusätzlich kann, wenn die Transaktion eine "Card Present" Transaktion ist, das Risiko eines Betrugs von dem Händler auf den Aussteller der Karte übertragen werden.
Unter Bezugnahme nunmehr auf 2 ist ein beispielhafter Käufercomputer 110 (welcher auch als ein Klienten-, Kunden-, oder Anwender- bzw. Benutzercomputer bezeichnet wird) ein beliebiges Computersystem, welches fähig ist, eine elektronische Einkaufstransaktion über ein Datennetzwerk 102 zu initiieren bzw. zu beginnen. In verschiedenen Ausführungsformen ist der Einkäufercomputer 110 ein Personal Computer, welcher mit einem beliebigen Betriebssystem 212 läuft, wie beispielsweise irgendeiner Version des Windows Betriebssystems, welches von Microsoft Corporation in Redmond, Washington, erhältlich ist, oder irgendeine Version des MacOS Betriebssystems, welches von Apple Corporation in Cupertino, Kalifornien, erhältlich ist.
Der Einkäufercomputer 110 beinhaltet in geeigneter Weise Hardware und/oder Software, um einer Smartcard 202 zu erlauben, mit einem Web-Browser 216 durch ein Betriebs- bzw. Betätigungssystem 212 zusammenzuwirken. Der Web-Browser 216 ist ein beliebiges Programm, welches mit dem Einkäufercomputer 110 kompatibel ist, so daß es über das Netzwerk 102 kommuniziert bzw. in Verbindung steht, wie beispielsweise Netscape Communicator, welcher von Netscape Corporation in Mountain View, Kalifornien, erhältlich ist, Internet Explorer, welcher von Microsoft Corporation in Redmond, Washington erhältlich ist, oder AOL-Browser, welcher von America Online Corporation in Dulles, Virginia, erhältlich ist. In verschiedenen Ausführungsformen beinhaltet der Einkäufercomputer 110 einen Brieftaschen-Klienten 214, welcher ein beliebiges Computerprogramm ist, welches konfiguriert ist, um mit dem Brieftaschenserver 140 zu kommunizieren. Ein beispielhafter Brieftaschen-Klient 214 ist der Microsoft Wallet oder der Globeset Wallet, welcher von Globeset Corporation in Austin, Texas, erhältlich ist, obwohl jegliches Wallet- bzw. Brieftaschenprogramm verwendet werden könnte.
Der Brieftaschen-Klient 214 und Brower 216 können mit der Smartcard 202 zusammenwirken, indem Daten durch das Betriebssystem 212 zu einem Kartenlesegerät bzw. -leser 204 gesandt werden. Das Kartenlesegerät 204 ist eine beliebige Lesevorrichtung, welche fähig ist, Information zwischen dem Brieftaschen-Klient 214 und der Smartcard 202 zu transfe rieren. In verschiedenen Ausführungsformen ist das Kartenlesegerät 204 ein ISO-7816 kompatibles Lesegerät, wie beispielsweise Model GCR410, welches von Gemplus Corporation in Redwood City, Kalifornien, erhältlich ist, oder irgendein anderes geeignetes Lesegerät.
Die Smartcard 202 ist jede beliebige Karte, welche fähig ist, elektronische Transaktionen durchzuführen, wie beispielsweise ein Smartcard, welche mit den folgenden ISO-Standards kompatibel ist:
ISO/IEC 7816-1:1998 Identification cards – Integrated circuit s) cards with contacts – Part 1: Physical characteristics;
ISO/IEC 7816-2:1999 Information technology – Identification cards – Integrated circuit (s) cards with contacts – Part 2: Dimensions and location of the contacts;
ISO/IEC 7816-3:1997 Information technology – Identification cards – Integrated circuit (s) cards with contacts – Part 3: Electronic signals and transmission protocols;
ISO/IEC 7816-4:1995 Information technology – Identification cards – Integrated circuit (s) cards with contacts – Part 4: Interindustry commands for interchange;
ISO/IEC 7816-5:1994 Identification cards – Integrated circuits) cards with contacts – Part 5: Numbering system and registration procedure for application identifiers;
ISO/IEC 7816-6:1996 Identification cards – Integrated circuits) cards with contacts – Part 6: Interindustry data elements; und
ISO/IEC 7816-7:1999 Identification cards – Integrated circuits) cards with contacts – Part 7: Interindustry commands for Structured Card Query Language (SCQL).
Eine beispielhafte Smartcard 202 ist eine Smartcard in Übereinstimmung mit den ISO 7816 Spezifikationen, beinhaltend einen Chip von Modell SLE66, welcher von Infineon Corporation in München, Deutschland, erhältlich ist. Der SLE66 Chip beinhaltet einen Speicher (wie beispielsweise einen 16 k Speicher, obwohl mehr oder weniger Speicher verwendet werden könnte) und einen Prozessor, auf welchem beispielsweise das Multos-Betriebssystem (wie beispielsweise Multos v.4) läuft. In verschiedenen Ausführungsformen beinhaltet die Smartcard 202 auch ein Applet zum Speichern und Bearbeiten von digitalen Zertifikaten oder anderen kryptografischen bzw. Verschlüsselungsfunktionen. Für eine Basiseinführung in Krytographie siehe beispielsweise "Applied Cryptography: Protocols, Algorthms, And Source Code In C," von Bruce Schneier und veröffentlicht von John Wiley & Sons (2. Ausgabe, 1996). Beispielsweise könnte ein X.509 Java Applet in der Smartcard 202 zum Bearbeiten eines darin gespeicherten X.509 Zertifikats enthalten sein. Während die hier beschriebenen Ausführungsformen eine Smartcard verwenden, wird geschätzt bzw. erkannt werden, daß andere intelligente Token bzw. Berechtigungsmarken, wie beispielsweise ein GSM-Mobiltelefon für die Smartcard in verschiedenen Ausführungsformen der Erfindung substituiert werden können.
Nunmehr unter Bezugnahme auf 3 beinhaltet ein Sicherheitsserver 130 in geeigneter Weise ein Interface bzw. eine Schnittstelle zu einem Netzwerk 102, eine Sicherheitsmaschine 304 und einen Autorisierungsserver 306, welcher mit einer Datenbank 310 kommuniziert bzw. in Verbindung steht. Das Netzwerk-Interface 302 ist ein beliebiges Programm, welches Kommunikationen am Netzwerk 102 erleichtert, wie beispielsweise ein Web-Server. In verschiedenen Ausfüh rungsformen basiert das Netzwerk-Interface 302 auf Netscape Enterprise Server, welcher von Netscape Corporation in Mountain View, Kalifornien, erhältlich ist. Das Netwerk-Interface 302 erhält elektronische Mitteilungen bzw. Botschaften am Netzwerk 102 und leitet diese zur Sicherheitsmaschine 304 oder zum Autorisierungsserver 306, wie dies geeignet ist.
Die Sicherheitsmaschine 304 und der Autorisierungsserver 306 können durch eine Firewall 308 getrennt sein. Die Firewall 308 ist eine beliebige Hardware- und/oder Softwareregelung bzw. -steuerung (wie eine Router-Zugangsregelung bzw. -steuerung), welche fähig ist, einen Datenfluß bzw. -strom zwischen einem internen und einem externen Netzwerk (nicht gezeigt) zu beschränken. In verschiedenen Ausführungsformen liegt die Sicherheitsmaschine 304 in geeigneter Weise außerhalb der Firewall, um Datentransfers bzw. -übertragungen zwischen dem Sicherheitsserver 130 und dem Kunden 110 oder dem Brieftaschenserver 140 zu administrieren bzw. zu verwalten. Der Autorisierungsserver 306 enthält wertvolle, vertrauliche Information wie die Datenbasis 310, welche eine Bezugnahme auf x.509 Zertifikate enthalten kann, welche auf den verschiedenen Smartcards 202 gespeichert sind, welche dem System 100 zugeordnet sind, so daß es in geeigneter Weise in einem internen Netzwerk für eine erhöhte Sicherheit gehalten bzw. enthalten sein kann. Es wird verstanden werden, daß die Funktionalität der Sicherheitsmaschine 304 und des Autorisierungsservers 306 in geeigneter Weise in verschiedenen Wegen kombiniert oder getrennt werden kann, ohne von dem Rahmen bzw. Bereich der vorliegenden Erfindung abzuweichen.
Unter Bezugnahme nunmehr auf 4 beinhaltet ein beispielhafter Brieftaschenserver 140 ein Netzwerk-Interface bzw. eine Netzwerk-Schnittstelle 402, einen optionellen Applet-Server 404 und eine Brieftaschenapplikation bzw. -anwendung 406. Das Netzwerk-Interface 402 ist ein beliebiges Programm, welches Kommunikationen bzw. Verbindungen am Netzwerk 102 erleichtert, wie beispielsweise ein Web-Server. In verschiedenen Ausführungsformen basiert das Netzwerk-Interface 402 auf dem Netscape Enterprise Server, welcher von Netscape Corporation in Moutain View, Kalifornien, erhältlich ist. Ein optioneller Applet-Server 404 stellt eine Serverfunktionalität für verteilte bzw. geteilte Programme, wie beispielsweise Java-Programme oder ActiveX Steuerungen zur Verfügung. Ein beispielhafter Applet-Server ist der Java Applet Server, welcher von Sun Microsystems in Mountain View, Kalifornien, erhältlich ist. Der Applet-Server 404 und das Netzwerk-Interface 402 stellen eine Support-Funktionalität für die Brieftaschenapplikation 406 zur Verfügung, welche eine Einlog-Funktionalität handhaben, Brieftaschendaten von der Brieftaschen-Datenbank 408 entnehmen und/oder Transaktionen administrieren kann, wie dies hier beschrieben ist. In verschiedenen Ausführungsformen der Erfindung kann der Brieftaschenserver 140 das SERVERWALLET (alias NETWALLET) Programm enthalten, welches von Globeset Corporation in Austin, Texas, erhältlich ist.
Verschiedene Ausführungsformen der Erfindung können eine Aktivator-Applikation bzw. -anwendung enthalten, welche in geeigneter Weise Kunden mit dem Brieftascheneinkaufsprozeß bzw. -verfahren hilft. Die Aktivator-Applikation kann beispielsweise eine Zustands- bzw. Statusinformation darstellen, oder kann aktiv den Brieftaschen-Klienten 214 (2) starten, wenn dies angebracht ist. Zusätzlich kann der Aktivator einen lokalen Zwischenspeicher von Sites bzw. Stellen aufrecht erhalten, welche durch die Brieftasche unterstützt sind.
Das Aktivator-Applikationsprogramm kann als eine konventionelle Computerapplikation bzw. -anwendung implementiert sein. In verschiedenen Ausführungsformen zeigt die Aktivator-Applikation Information als ein Systemablageicon bzw. -symbol, wie beispielsweise ein "floating bitmap", oder in jeder anderen geeigneten Weise an. Die graphischen Darstellungen (beispielsweise Ikons bzw. Bildsymbole) können eine Statusinformation anzeigen, wie beispielsweise "browsing at a supported site" ("Browsen an einer unterstützten Seite"), "browsing at a supported checkout page" ("Browsen an einer unterstützten Überprüfungsseite"), "browsing at a supported payment page" ("Browsen an einer unterstützten Zahlungsseite"), "now browser windows open" ("keine Browserfenster offen"), "browsing at an unsupported page" (Browsen an einer nicht unterstützen Seite") und/oder dgl.
Ein Floating-Bitmap kann mit jedem graphischen File oder Format beispielsweise mit einem Graphik-Austauschformat (GIF)-File implementiert sein. Alternative Ausführungsformen stellen Information in graphischen, hörbaren, visuellen, audiovisuellen, Multimedia-, animierten oder anderen Formaten dar. Darüber hinaus können GIF-Files bzw. -Dateien durch LZW-Files, TIFF-Files, animierte GIF-Files, JPEG-Files, MPEG-Files und/oder jede andere Art eines graphischen, Audio- oder Multimedia-Formats oder -Files ersetzt sein bzw. werden.
Vorzugsweise wird die vorliegende Erfindung verstärkt, indem ein Transaktionswerkzeug bzw. -tool mit einem Fenster zur Verfügung gestellt wird, welches eine Regelung bzw. Steuerung beinhaltet, welche einem Benutzer bzw. Anwender erlaubt, leichter das Transaktionstool bzw. -Werkzeug zu verwenden. Das Transaktionstool kann für verschiedene elektronische Transaktionen verwendet werden. Beispielsweise Einkaufstransaktionen, Finanz-Beratungs-Transaktionen, Versicherungstransaktionen, Kunden-Kunden-Transaktionen, wie beispielsweise Tausch- bzw. Barter-Transaktionen, Transaktionen, welche sich auf Angebote und Belohnungen beziehen etc. Das Transaktionstool, welches im Detail hier beschrieben ist, ist eine digitale Brieftasche, welche für elektronische Einkaufstransaktionen verwendet wird. Die digitale Brieftasche wird durch Bereitstellen eines Fensters mit Steuerungen für den Kunden verstärkt, um leichter die Brieftasche zu verwenden. Vorzugsweise beinhaltet die vorliegende Erfindung eine klientenseitige Implementierung für einen Zugang zu einer Funktionalität einer digitalen Brieftasche ("Aktivator"), und eine serverseitige Toolbar bzw. Werkzeugleiste, welche dem Anwender erlaubt, ein geringes Herunterladen des Aktivators durchzuführen und ein oder mehrere Regel- bzw. Steuerelement (e) des Operating System User Interface, beispielsweise eines Microsoft Windows Systemablageicons bzw. -bildzeichens zu verwenden.
Der Aktivator ist ein Objektcode, welcher auf dem Computer des Anwenders bzw. Benutzers läuft und eine Routine für einen Zugang zu dem Brieftaschenserver beinhaltet. Der Aktivator kann Vorfälle erzeugen und der Aktivator enthält eine prozedurale Logik, welche eine Kommunikation mit dem Brieftaschenserver in Antwort auf spezifische Anwender- und Systemaktionen bzw. -vorgänge oder -vorfälle erlaubt. Vor zugsweise stellt der Aktivator ein einzelnes graphisches Element dar, beispielsweise ein Ikon bzw. Bildzeichen, welches in einer Microsoft Windows Ausführungsform als ein Windows System Ablageicon erscheint, und welches es dem Anwender ermöglicht, das Erscheinen des Brieftaschen-Werkzeugbalkens bzw. -toolbars auszulösen. In verschiedenen Ausführungsformen ist der Brieftaschen-Werkzeugbalken bzw. die -Werkzeugleiste tatsächlich ein spezielles Browserfenster, welches auf den Brieftaschen-Server zugreift. Der Aktivator steht in Verbindung mit dem Brieftaschen-Server, um die Aktualisierung des Aktivator-Objektcodes über ein geringes Herunterladen zu automatisieren. Vorzugsweise wird der Anwender nach einer Bestätigung vor einem Durchführen der Aktivator-Herunterladung gefragt. In verschiedenen Ausführungsformen steht der Aktivator in Verbindung mit Applikationen bzw. Anwendungen verschieden von der Brieftasche, wie beispielweise Anboten von Belohnungen.
Das System stellt den Inhalt von relevanten Optionen auf jeder seiner Web-Seiten zur Verfügung, nämlich dynamische und vom Zusammenhang abhängige Information, welche für jede Seite spezifisch ist, welche durch den Benutzer bzw. Anwender betrachtet wird. Dies wird durch den Aktivator überwachende URLs und ein potentielles Festhalten an Seiten durchgeführt, so daß der Verwender auf potentielle Möglichkeiten aufmerksam gemacht werden kann. Beispielsweise kann der Aktivator überprüfen, um zu sehen, ob der Verwender eine Seite bzw. Stelle eines Händlers betrachtet und kann anwendbare Angebote (beispielsweise Rabatt bzw. Nachlaß für Handelsware, etc.) dem Anwender präsentieren. Der Aktivator kann auch Versionen von Software an dem System des Anwenders bzw. Benutzers überwachen und den Benutzer von möglichen Upgrade- bzw. Aktualisierungsversionen informieren. In einer beispielhaften Ausführungsform wird das System an irgendeinem Netzwerk, wie beispielsweise WAN, LAN, Internet oder einem beliebigen Personal Computer, einer drahtlosen elektronischen Vorrichtung oder einer anderen ähnlichen Vorrichtung implementiert. Das System kann auf einem Betriebssystem, beispielsweise Microsoft Windows, Mac OS, Linux, Windows CE, Palm OS und anderen implementiert sein.
Der Aktivator, welcher vorzugsweise an der Klientenseite implementiert ist, erlaubt dem Anwender 110, in konstanter oder intermittierender bzw. unterbrochener Verbindung mit dem Ausgeber bzw. der Ausgabestelle der digitalen Brieftasche 140, beispielsweise American Express, zu sein, ohne daß eindringende bzw. beeinflussende Fenster einen Raum auf der Anzeige des Anwenders einnehmen. Wie oben beschrieben, erlaubt dies dem Ausgeber der Brieftasche, mögliche Gegenstände von Interesse für den Anwender zu überwachen und diesen zu geeigneten Zeiten zu präsentieren. Die konfigurierbaren Steuerungen bzw. Regelungen, welche in dem Fenster präsentiert werden, erlauben dem Kunden, rasch zu den gewünschten Web-Sites zu navigieren, und unmittelbar eine gewünschte Funktionalität aufzurufen, wie beispielsweise ein Entnehmen bzw. Überprüfen eines digitalen Einkaufswagens. Vorzugsweise kann der Klient- bzw. Kunden-Werkzeugbalken ein getrenntes bzw. diskretes Fenster sein, welches einem Browserfenster des Anwenders zugeordnet ist, und behält eine Geometrie bei, welche es effektiv als ein Teil des Browsers des Anwenders macht. Obwohl das Fenster, wenn der Anwender auf seine Steuerungen drückt, in seinem originalen bzw. ursprünglichen Zustand verbleibt, sich das Fenster nämlich auf das Browserfenster richtet, um gewünschte URLs zu besuchen und bestimmte Aktionen (wie beispielsweise eine Verwendung der digitalen Brieftasche) aufzurufen.
Beispielsweise wird nach einem Auswählen eines Icons bzw. Bildzeichens der digitalen Brieftasche aus der Systemablage der Werkzeugbalken bzw. der Werkzeugleiste 502 der digitalen Brieftasche als ein diskretes bzw. getrenntes Fenster angezeigt, welches mit dem Browserfenster 500 des Anwenders assoziiert ist, wie dies in 5 gezeigt ist. In einer alternativen Ausführungsform bildet der Klienten-Werkzeugbalken das existierende Brieftaschenfenster ab, wobei zusätzliche Regelungen bzw. Steuerungen, wie sie oben beschrieben sind, in einer Erstreckung bzw. Erweiterung des Fensterbereichs zur Verfügung gestellt werden, welcher durch eine existierende Brieftasche zur Verfügung gestellt ist. In einer anderen alternativen Ausführungsform wird der Bereich in dem Standard-Browser-Fenster des Anwenders unterteilt, um einen Bereich zu erzeugen, welcher für die Brieftasche und die anderen, oben beschriebenen Steuerungen verwendet werden kann.
Das System stellt vorzugsweise einen angenehmen bzw. bequemen Weg für Kunden dar, nicht nur favorisierte URLs zu besuchen, sondern auch eine spezifische Funktionalität aufzurufen, welche anderenfalls viele Schritte bedingen kann und welche sich ändern kann, wenn bzw. da die Seiten bzw. Stellen von Verkäufern kontinuierlich aktualisiert werden. Das System stellt auch vorzugsweise eine einfachere Anwendererfahrung dar, indem es die Brieftasche und e-Commerce-Seiten bzw. -Stellen nicht nur leicht verwendbar macht, sondern indem es die Brieftaschen und den Klienten-Werkzeugbalken leicht auffindbar macht. Wenn ein Verwender viele verschiedene Fenster offen hat, kann ein Finden des Brieftaschenfensters schwierig und störend sein, insbesondere da bzw. wenn unterschiedliche Browserfenster einen GUI-Fokus während des Verlaufs einer normalen Navigation und Interaktion mit Stellen bzw. Sites ergreift. Derart stellt eine Verwendung des Systemablageicons und einer servuerseitigen Funktionalität eine erhöhte bzw. verbesserte Anwendererfahrung zur Verfügung. In einer bevorzugten Ausführungsform arbeitet das vorliegende System mit jeder bekannten Art eines Browsers, beispielsweise dem Netscape Navigator.
Während Systeme gemäß dem Stand der Technik einfach ein an einen Kunden anpaßbares bzw. angepaßtes Portal (beispielsweise MyAmericanExpress.com) zur Verfügung stellen können, welches es einem Benutzer bzw. Anwender erlaubt, die Seite zu betrachten und dann zu Links bzw. Verbindungen von dieser Seite überzugehen, stellt eine beispielhafte Ausführungsform der vorliegende Erfindung in geeigneter Weise ein Fenster mit Regelungen bzw. Steuerungen zur Verfügung, welche auf dem Desktop bzw. Arbeitsplatz der Anwender verbleiben werden, da bzw. wenn sie durch das Web navigieren. Zusätzlich stellt der Klienten-Werkzeugbalken Mittel zum Automatisieren von Aktionen bzw. Vorgängen für den Anwender zur Verfügung, wo diese Aktionen an e-Commerce-Stellen bzw. -Sites einer dritten Person stattfinden. Darüber hinaus können Systeme gemäß dem Stand der Technik ein getrenntes Browserfenster verwenden, um die Brieftaschen-Steuerungen zur Verfügung zu stellen, während jedoch die vorliegende Erfindung ein Standard-Browserfenster verwendet, welches unterteilt wurde, um einen Bereich zur Verfügung zu stellen, welcher durch die Brieftasche einzunehmen ist. Beispielsweise ist in einer bevorzugten Ausführungsform ein Ikon bzw. Bildzeichen der digitalen Brieftasche für den Anwender als ein Systemablageicon (nicht gezeigt) verfügbar. Bei einem Aufrufen des Ikons der digitalen Brieftasche wird der Werkzeugbalken 502 der digitalen Brieftasche angezeigt bzw. dargestellt, wie dies in 5 gezeigt ist. Der Werk zeugbalken der digitalen Brieftasche ist unaufdringlich, während er Regelungen bzw. Steuerungen enthält, welche dem Anwender erlauben, die digitale Brieftasche zu verwenden. Vorzugsweise ist der Werkzeugbalken 502 dem Browserfenster 500 zugeordnet.
Wie in 6 gezeigt, erweitert sich, wenn der Anwender einen Knopf für ein Einkauf-Verzeichnis von dem Werkzeugbalken 502 auswählt, der Werkzeugbalken zu einer Einkaufs-Verzeichnisseite 602. Der Anwender kann einen Händler von der Liste von Händlern 604 auswählen, welche in der Einkaufs-Verzeichnisseite 602 angezeigt bzw. dargestellt sind. Bei einem Auswählen eines Händlers von der Liste von Händlern 604, bringt die digitale Brieftasche den Anwender zu der Stelle bzw. Site 702 des ausgewählten Händlers, wie dies in 7 gezeigt ist. Vorzugsweise kehrt, wenn die digitale Brieftasche einen Anwender zu einer Händlerstelle 702 mitnimmt, der Werkzeugbalken 502 zu seiner normalen Größe zurück.
Wenn der Anwender einen Kauf von einem Händler tätigt, indem er beispielsweise Gegenstände in einen Einkaufswagen legt und zu einem Ausgang bzw. einer Überprüfung an der Site bzw. Stelle des Händlers fortschreitet, wird die Austritts- bzw. Überprüfungsfunktion teilweise durch die digitale Brieftasche der vorliegenden Erfindung durchgeführt. Wie dies in 8 gezeigt ist, wird, wenn der Anwender einen gewünschten Einkauf an einer Site bzw. Stelle 702 des Händlers anzeigt, das Checkout- bzw. Überprüfungs- bzw. Austritts-Kunden-Interface 802 der digitalen Brieftasche angezeigt bzw. dargestellt. Beispielsweise erscheint die Checkout-Anzeige 802 an einer Seite des Browserfensters, während das Händlerfenster 702 unverändert an der gegenüberliegenden Seite des Browserfensters angezeigt ist bzw. wird. Viele der Informationen, welche ein Anwender normalerweise an dem Ausgang bzw. der Überprüfung des Händlers (beispielsweise Name, Adresse, e-mail-Adresse, Kreditkarteninformation, etc.) eingeben müßte, ist bereits durch die digitale Brieftasche bekannt und wird in dem Checkout-Fenster 802 der digitalen Brieftasche vorausgefüllt. In einer bevorzugten Ausführungsform kann der Anwender die vorausgefüllte Information editieren bzw. bearbeiten.
Vorzugsweise beinhaltet das vorliegende System auch Verfahren und Vorrichtungen, welche die zuverlässige Population von HTML-Formularen an Web-Seiten erleichtern. Das Endresultat ist, da Anwender Informationsinhalte identifizieren können, von welchen sie wünschen, daß sie an Sites in einer allgemeinen Weise zur Verfügung gestellt werden, unabhängig von dem tatsächlichen Auftreten einer Bezeichnung bzw. Markierung und einem Verhalten von verschiedenen e-Commerce-Web-Seiten. Vorzugsweise beinhaltet die vorliegende Erfindung eine "Auto-Remember"-Komponente, welche einem Anwender erlaubt, Daten aufzunehmen bzw. zu erhalten bzw. zu erfassen, welche eingegeben sind bzw. werden und eine "Form-Fill"-Komponente (Formularausfüll-Komponente) welche einen wirkungsvollen Satz von Prozessen beinhaltet, welcher aus der Kombination von verschiedenen Modellen von Stellen bzw. Seiten und Anwendern bzw. Benutzern resultiert.
Die vorliegende Erfindung sammelt Information von Anwendern, speichert sie sicher und zuverlässig auf einem Server und stellt sie dann entsprechend Form- bzw. Formularfeldern unter der Anweisung des Anwenders zur Verfügung. Das System hält eine Aufzeichnung von Anwenderinformation zu den ver schiedenen HTML-Formfeldern von Seiten bzw. Stellen zur Verfügung, welche für den Anwender von Interesse sind. Diese Information kann dann anweisen, wie HTML-Formulare auszufüllen (oder vorauszufüllen) für Anwender sind, welche mit diesen Stellen bzw. Sites in Wechselwirkung treten möchten.
Unter Bezugnahme auf das "Auto-Remember"-Merkmal können digitale Brieftaschen gemäß dem Stand der Technik eine Remember-Funktion implementieren, wobei sie jedoch durch den Anwender initialisiert werden muß. Mit dem vorliegenden "Auto-Remember"-Merkmal müssen Benutzer bzw. Anwender der digitalen Brieftasche nicht einen Knopf anklicken, um sich das Formular in Erinnerung zu rufen, welches sie unmittelbar ausgefüllt haben, da sich das vorliegende System an die Felder erinnert, welche der Anwender an ein Händlerfenster abschickt. Wenn ein Formular abgeschickt bzw. eingereicht wird (beispielsweise ein Drücken eines "Absende"- bzw. "Submit"-Knopfs oder "Buy"- bzw. "Kauf"-Knopfs), antwortet die Online-Brieftasche durch ein Bestimmen, ob das Fenster, welches die Übertragung des Formulars ausgelöst hat, ein Händlerfenster von Interesse ist. Falls dies der Fall ist, merkt sich die Brieftasche in geeigneter Weise die Daten; andernfalls kann die Brieftasche eines Auftretens eines Einschickens des Formulars ignorieren und seinen normalen Betrieb fortsetzen.
Die Regelungen bzw. Steuerungen der digitalen Brieftasche beinhalten einen mit "remember" gekennzeichneten Knopf oder können auch ein Merkmal eines automatischen Merkens (automatic remember) unterstützen, welches immer aktiv ist. Im allgemeinen können Felder verschieden von denjenigen, welche automatisch bevölkert werden bzw. sind, durch die Brieftasche gemerkt werden. In diesem Zusammenhang bedeutet ein Merken eines Felds, daß, wenn ein Anwender Daten in ein bestimmtes Feld eingibt, der Wert durch das System gespeichert werden wird. Die Brieftaschen-Komponente wird Feldwerte detektieren, welche auf diese Weise eingegeben sind bzw. werden, und wird diese sicher an einen Server über das Internet übertragen. Wenn ein Anwender als nächstes zu dieser Seite weitergeht bzw. gelangt, wird die Brieftasche zusätzlich zu einem Ausfüllen der Formulare mit Feldern, welche von dem Brieftaschensystem zurückgeholt bzw. entnommen werden, auch die Formulare mit Werten ausfüllen, welche vorher gemerkt wurden. Bei einem Be- bzw. Verarbeiten des Formulars (Vorausfüllen) wird die Brieftasche sicher Feldwerte von dem Server abrufen bzw. zurückholen.
Genauer implementiert in bezug auf den Internet Explorer Browser die Erfindung in geeigneter Weise eine ActiveX Steuerung, welche sich selbst an eine Web-Site anlagert, wie beispielsweise die American Express Online Wallet. In einer bevorzugten Ausführungsform enthält die ActiveX Steuerung ein Verfahren, welches die Browserereignisse von allen interessierenden Internet Explorer Browsern empfängt, so daß die American Express Online Wallet auf diese Vorfälle bzw. Ereignisse, falls notwendig, durch eine JavaScript Funktion antworten kann, welche in der American Express Online Wallet geladen ist, wodurch dem System erlaubt wird, das vollständig heruntergeladene Dokument innerhalb eines Internet Explorer Browsers zu erhalten. Spezifisch erlaubt dies dem System, das Ereignis "Document Complete" bzw. "Dokument vollständig" zu erhalten, welches durch den Internet Explorer Browser ausgegeben wird, welches spezifiziert, wenn ein Dokument ein Laden beendet hat. Wenn dieses Ereignis einfangen wird, benachrichtigt die ActiveX Steuerung die American Express Online Wallet durch ein Aufrufen einer JavaScript Funktion, welche in der American Express Online Wallet geladen ist. Diese Funktion antwortet auf dieses Ereignis durch ein geeignetes Kommunizieren mit der ActiveX Steuerung, um die die Ereignisse "Form Submit" bzw. "Formular absenden" für alle Formen auf allen Internet Explorer Browsern einzufangen.
Wenn ein Verwender ein Formular auf einer Web-Seite ausfüllt und den "Submit" bzw. "Absenden"- (d.h. irgendeine Steuerung, wie beispielsweise einen Knopf, welcher ein Formular abschickt) Knopf für die Seite drückt, wird die American Express Online Wallet durch die ActiveX Steuerung aufmerksam gemacht bzw. verständigt, welche eine JavaScript-Funktion aufruft, welche in der American Express Online Wallet geladen ist. Die American Express Online Wallet bestimmt dann in geeigneter Weise, ob das Dokument, welches das Ereignis "Submit" hervorruft, von Interesse ist, indem die URL des Fensters überprüft wird, welches das Ereignis aufgerufen hat. Wenn das Ereignis zu bearbeiten ist, muß die American Express Online Wallet eine geeignete Funktion innerhalb der ActiveX Steuerung aufrufen, welche das Dokumentobjektmodel (DOM) enthält, welches das Ereignis aufgerufen hat. Das DOM kann übergangen werden und die Formularwerte können gespeichert bzw. gesichert werden, so daß sie zu dem Server für eine Speicherung im Speicher gesandt werden können. In einer bevorzugten Ausführungsform muß sich die ActiveX Steuerung in geeigneter Weise selbst von einem Einfangen der Browserereignisse lösen, und "Submit"-Ereignisse von Formularen bilden, so daß Laufzeitfehler minimiert sind bzw. werden.
In bezug auf den Netscape Browser fängt aufgrund der Netscape-Implementierung von Ereignissen das System das Ereignis innerhalb eines JavaScripts allein ein. Wenn das System erfolgreich das "Universal Browser Write"-Privileg (allgemeine Browser-Schreib-Privileg) erhält (d.h. welches durch den Anwender erteilt wird), kann dann das System erfolgreich eine Funktion aufrufen, welche es einem externen Fenster erlaubt, Ereignisse eines anderen Fensters zu nehmen bzw. einzufangen. Das System kann dann das Dokumentobjektmodell für alle Rahmen bzw. Bilder dieses Fenster übergehen. Wenn dies durchgeführt wird, verständigt das System jedes Formular des Fensters, daß das System das "Submit"-Ereignis einfangen will. Derart wird, wenn ein Benutzer ein Formular auf dem Fenster ausfüllt, welches das System notifiziert hat, und den Absende- bzw. "Submit"-Knopf drückt (d.h. jegliche Steuerung, wie beispielweise einen Knopf, welcher ein Formular abschickt) für diese Seite, die Online-Brieftasche verständigt und antwortet entsprechend. Ein Fachmann wird schätzen bzw. erkennen, daß die vorliegende Erfindung in jeglichem geeigneten Transaktionssystem implementiert werden kann, beinhaltend, jedoch nicht beschränkt auf ein geeignetes digitales Brieftaschensystem.
In Bezugnahme auf die Formularausfüllfunktion stellt die digitale Brieftasche, wie beispielsweise die American Express Online Wallet, eine Formularausfüllfunktionalität zur Verfügung, um Anwender beim Ausfüllen von Formularen zu unterstützen. Systeme gemäß dem Stand der Technik, wie beispielsweise das System, welches durch Globset Inc. zur Verfügung gestellt wird, verwenden typischerweise ein Browser Helper Object (BHO). Der BHO-Zugang beinhaltet oft Nachteile, wie beispielsweise, daß der Internet Explorer 5.0-Browser einen Fehler aufweist, wo er nur den ersten BHO laden wird, welcher in dem Register spezifiziert ist. Dies ist ein Problem für jegliche Anwendung, da es nicht sicher sein kann, ob sein BHO geladen ist oder nicht. Darüber hinaus wird bzw. ist ein BHO für jeden Fall des Internet Explorers geladen, so daß vielfache Instanzen eines BHO zu jeder Zeit laufen können – wodurch Speicher aufgebraucht wird und eine Navigation für alle Browser gegenüber dem einzigen von Interesse verlangsamt wird.
Die vorliegende Erfindung ersetzt vorzugsweise die BHO-Lösung durch eine Verwendung derselben ActiveX Steuerung, wie dies in dem "auto remember" Merkmal spezifiziert ist. Durch ein Festlegen einer ActiveX Steuerung an der Online Wallet Web-Seite erhält das System in geeigneter Weise das Dokumentobjektmodel für jedes Dokument, welches innerhalb eines gegebenen Internet Explorer Browsers beispielsweise durch ein Verwenden des Shell Windows API geladen wird. Wenn ein Anwender einer "Fill Form"-Knopfformular-Ausfüll-Knopf auf der Online Wallet anklickt, kann die Brieftasche antworten, indem sie zuerst das Dokumentobjektmodel durch die ActiveX Steuerung erhält. Als nächstes kann die Brieftasche den Namen der Felder speichern, welche Formulare herstellen und kann sie zu einer heuristischen Maschine auf dem Server senden. Der Server wird auf diese Anfrage bzw. Anforderung antworten, indem die Werte retourniert werden, welche verwendet werden sollten, um diese Felder auszufüllen. Die Felder können dann unter Verwendung desselben Dokumentobjektmodells ausgefüllt werden, welches früher erhalten wurde. Derart reduziert die vorliegende Erfindung das Problem, daß wiederholte Daten in Formulare an Web-Sites eingegeben werden müssen. Zusätzlich erhöht es neben einer Einsparung einer Anstrengung auf Seiten von Kunden bzw. Klienten eine Genauigkeit der eingegebenen Daten.
Genauer kombiniert die Architektur der vorliegenden Erfindung ein serverseitiges Modell von jeder Site bzw. Stelle (beispielsweise Felder, Seiten, Links bzw. Verbindungen etc.), ein serverseitiges Modell eines Anwenders (beispielsweise Profil), ein vom Anwender erzeugtes Modell einer Site (beispielsweise Macro Recording bzw. Makroaufnahme, Tagging bzw. Anzeichnen, Drag and Drop), ein Modell einer Site bzw. Stelle, welche manuell durch ein System erzeugt ist (beispielsweise um die durch den Anwender erzeugten Modelle zu vermehren und zu validisieren), und ein heuristisch erzeugtes Modell einer Site (beispielsweise Zusammenspiel von semantischer Information über Felder, Aktionen bzw. Tätigkeiten etc.). Das vorliegende System erzeugt und speichert verschiedene unterschiedliche Arten bzw. Typen von Modellen. Die erste charakterisiert die Site bzw. Stelle, beispielsweise wie ausgecheckt bzw. überprüft bzw. ausgetragen wird, wie etwas zu einem Einkaufswagen hinzugefügt wird, wie man nach einer Art eines Produkts sucht, wie Vorlieben bzw. Präferenzen (beispielsweise Reisen) eingegeben werden, etc. Das zweite Modell charakterisiert den Anwender bzw. Benutzer, beispielsweise welche Dinge ein Anwender tun bzw. machen kann und welches die Profilattribute eines Anwenders sind. Durch ein Kombinieren dieser zwei Modelle erzeugt das vorliegende System spezielle Prozesse bzw. Verfahren, welche eine große Flexibilität und Leistung hinzufügen. Das System katalogisiert von dem Modell, was ein Anwender tun kann, für das Modell der Site, wobei die Sitemodelle durch jedes bekannte Verfahren erzeugt werden. Derart kann das Sitemodell durch den Anwender, durch den Host, durch die Transaktionskartenfirma (Ausgabestelle) oder selbst durch den Provider der Site erzeugt werden. In einer bevorzugten Ausführungsform kann ECML/XML verwendet werden, um Modelle für die Site zu repräsentieren. In verschiedenen Ausführungsformen können Sitemodelle mit anderen Systemen ausgetauscht werden.
Beispielsweise kann ein User bzw. Anwender routinemäßig Sites bzw. Seiten von unterschiedlichen Flugzeug- und Reisedienstleistungsunternehmen besuchen, um Flugzeugtickets zu erwerben. Jede Site weist typischerweise Felder auf unterschiedlichen Schirmen zum Sammeln von Information auf, welche relativ ähnlich zwischen den verschiedenen Sites bzw. Stellen sind. Jede Site wird jedoch unterschiedliche HTML-Formularfelder verwenden, welche auf unterschiedlichen URLs angeordnet sind und welche sich auch mit der Zeit ändern können. Selbst obwohl die Information sehr ähnlich in ihrer Natur über die verschiedenen Sites ist, gibt es gegenwärtig keinen gemeinsamen Mechanismus, um den Prozeß eines Ausfüllens von Feldern für Anwender-Reisevorlieben (beispielsweise Sitzplatzwahl, Mahlzeiten, Flugzeiten, Zuneigungsbelohnungen etc.) zu automatisieren. Jede Site kann ihr eigenes Profil des Anwenders haben, welches vieles dieser Information speichert. Der Anwender müßte jedoch unverändert ein derartiges Profil unabhängig für jede Site erzeugen, wenn die gegenwärtige Praxis berücksichtigt wird.
Die vorliegende Erfindung beinhaltet eine auf heuristischen Erkenntnissen basierende Felderkennung. In diesem Zugang werden Feldmarkierungen durch ihre räumliche Nähe identifiziert, um interessierende Felder auszubilden. Eine Kombination von Feldlabels bzw. -markierungen bzw. -etiketten und von Form- bzw. Formularfeld-HTML-Attributen bzw. -Zusätzen (insbesondere das "Namen"-Attribut der HTML-"Eingabe"-, -"Auswahl"- und -"Aktion"-Elemente) wird als Eingabe zu einer heuristischen Maschine verwendet, welche ein Wörter buch enthält, um die Identifikation von gewünschten Feldern zu unterstützen.
In einer anderen Ausführungsform beinhaltet die vorliegende Erfindung eine durch den Anwender vermittelte Felderkennung. In diesem Zugang nimmt der Anwender bewußt eine Eingabe über einen "Remember"- bzw. -"Erinnerungs"-Knopf oder eine ähnliche Regelung bzw. Steuerung auf, welche Servern erlaubt, Information über die Sequenz von Aktionen bzw. Tätigkeiten aufzunehmen bzw. zu erlangen, welche der Anwender ausführt. Wenn der Anwender dies durchführt, kann er oder sie effektiv bzw. wirksam die Aktionen (ähnlich einem Makroscripting, welches in anderen Software-Systemen verwendet wird) "rückspielen". Derart können die Aktionen des Anwenders in die heuristische Maschine zugeführt werden und auch direkt in Feldausfülltabellen zugeführt werden, welche durch die Prozesse dieser Maschine verwendet werden..
In einer bevorzugten Ausführungsform können die obigen zwei Zugänge eine gewisse manuelle Interaktion erfordern, um vollständig Verfahrenskarten und Formularfeldkarten zu erzeugen, welche genau die Navigation und Formularfeld-Vervollständigungsmöglichkeiten darstellen, welche diese Erfindung ermöglicht. Falls notwendig, werden menschliche Analysten in einer ähnlichen Weise zu derjenigen arbeiten, welche während einer durch den Anwender vermittelten Felderkennung auftritt, obwohl sie viel mehr Information über ihre Navigations- und Formularausfüllprozesse zur Verfügung stellen werden, als dies der typische Anwender machen würde. In allen Fällen wird die Information, welche gesammelt ist bzw. wird, verwendet, um eine Verfahrens- bzw. Prozeßkarte (oder eine detaillierte Site-Karte) zu erzeugen, welche die Sequenz von Aktionen bzw. Vorgängen darstellt (For mular ausfüllen, HTTP-Post bzw. -Absenden, HTTP-Get bzw. -Erhalten etc.), durch welche verschiedene Aktivitäten auftreten können. Eine Feldkarte wird auch für jede der Web-Seiten in der Prozeßkarte erzeugt, wobei die Feldkarte die präzisen Namen von Feldern definiert, welche verwendet werden können, um eine Formulareinreichung zu automatisieren. Zustandskarten können auch erforderlich sein, um die Zustände von Anwendern zu verfolgen, wie sie mit den Web-Sites zusammenwirken bzw. interagieren (der Zustand des Anwenders, wie beispielsweise eingeloggt gegenüber nicht eingeloggt, wird die Resultate von verschiedene Aktionen auf der Site modifizieren).
In einer bevorzugten Ausführungsform kann der Prozeß, durch welchen der Anwender interagiert bzw. arbeitet, entweder vollständig automatisiert (wobei in diesem Fall der Anwender lediglich den Wunsch abschickt bzw. überträgt, eine eingeschriebene Aktion durchzuführen) oder kann durch einen Anwender vermittelt bzw. gesteuert sein (wobei in diesem Fall die Erfindung Formularfelder für den Anwender vorausfüllen kann, wodurch dem Anwender die Möglichkeit gegeben wird, jegliche Felder zu korrigieren, zu ändern oder zu vervollständigen, welche einen weiteren Dateneintrag erfordern). Zusätzlich zu den oben beschriebenen Produkten und Dienstleistungen kann die ermächtigende bzw. befehligende Technologie in der Form der Prozeß- und Feldkarten für neue Produkte und Dienstleistungen eingesetzt werden, wie beispielsweise um Firmen zu ermöglichen, die Eingabe von Formulardaten für die Besucher ihrer Site zu automatisieren. Beispielsweise kann, wenn eine Firma Prozeß- und Feldkarten zum Wohl bzw. Nutzen ihrer eigenen Kunden (durch irgendwelche der oben beschriebenen Mittel) kompiliert bzw. gesammelt hat, dann die Firma diese Information, Dienstleistun gen und Produkte an Kunden einer dritten Partei bzw. Person lizenzieren. Die Sites bzw. Stellen, für welche diese Karten existieren, können auch die vorliegende Erfindung verwenden, so daß die Sites davon profitieren, daß ein ähnlicher Service bzw. eine ähnliche Dienstleistung ihren Kunden geliefert wird, welche nicht von dem System profitieren. Die zugrundeliegenden Prozesse werden selbst auf ein System zurückgreifen, welches diese Information erhält und sie neu formatiert, beispielsweise XML und ECML. Diese Standarddarstellungen würden die Basis eines Informationsaustausches für die letzteren zwei Produkte/Dienstleistungen ausbilden.
Nunmehr unter Bezugnahme auf 9 beinhaltet ein Prozeß bzw. Verfahren 900, welcher(s) durch ein beispielhaftes Aktivatorprogramm implementiert ist, in geeigneter Weise ein Initialisieren der Anwendung bzw. Applikation (Schritt 902), ein Überwachen des Uniform Resource Locators (URL), wenn bzw. da der Anwender online browst bzw. blättert oder einkauft (Schritt 904), ein Bestimmen, ob der Anwender an einer unterstützten Site bzw. Stelle browst (Schritt 906), ein Bestimmen der Art der unterstützten Site (Schritte 908 und 912) und ein Antworten in geeigneter Weise bei den Bearbeitungsschritten 910 und 914 (jeweils). Andere Merkmale (wie beispielsweise Coupons bzw. Gutscheine, Spezialangebote, eine Überwachung, Sicherheit und dgl.) können bei Schritt 916 implementiert sein bzw. werden.
Der Initialisierungsschritt 902 bedingt in geeigneter Weise ein Öffnen der Aktivatoranwendung und ein entsprechendes Initialisieren der Anwendung. Die Aktivatoranwendung kann in Antwort auf einen Systemstart, eine Verbindung mit einem Netzwerk (wie beispielsweise dem Internet oder einem LAN) oder ein Initialisieren eines Browsers initialisiert werden (wie beispielsweise Internet Explorer, erhältlich von Microsoft Corporation in Redmond, Washington, oder Netscape Explorer, erhältlich von Netscape Corporation in Mountain View, Kalifornien). In verschiedenen Ausführungsformen kann die Aktivatoranwendung den Brieftaschenserver 140 (1), die Brieftaschenanwendung 406 (4) oder einen anderen Server auf dem Netzwerk 102 kontaktieren. Die Aktivatoranwendung kontaktiert in geeigneter Weise den entfernten Server, um Information, wie beispielsweise Listen von Websites, Domainnamen oder URLs zu erhalten, welche durch die Brieftasche unterstützt werden. Diese Information kann auf einer regulären Basis (beispielsweise täglich, wöchentlich, monatlich oder bei jeder Initialisierung der Agent-Anwendung) erhalten werden oder wenn sie durch die Aktivatoranwendung oder den Server abgefragt wird. In verschiedenen Ausführungsformen speichert die Aktivatoranwendung die Liste von unterstützen URLs in einem Cache bzw. Zwischenspeicher oder einem File bzw. einer Datei auf einem lokalen Treiber oder in einem Speicher an dem Klienten-Computer.
Wenn bzw. da der Anwender das Internet oder ein anderes Datennetzwerk 102 browst bzw. durchsucht, überwacht die Aktivatoranwendung in geeigneter Weise den Ort des Anwenders an dem Netzwerk. Ein Verfahren zum Überwachen des Browsens bzw. Durchsuchens des Anwenders ist es, die URL zu überwachen, welche durch den Browser des Users verwendet wird. In derartigen Ausführungsformen erhält die Aktivatoranwendung die gegenwärtige URL von dem Browser des Anwenders (oder von dem System-Netzwerk-Interface, falls zutreffend) und vergleicht (Schritt 906) die gegenwärtige URL mit der Liste von unterstützten URLs, welche von dem entfernten Server im Initialisierungsschritt 902 erhalten wird. Diese Vergleiche sind in logisch getrennten Schritten 906, 908, 912 und 916 in 9 gezeigt, obwohl diese Schritte in jeder beliebigen Weise kombiniert oder getrennt werden könnten, ohne den Bereich der Erfindung zu verlassen. Beispielsweise könnte, obwohl 9 zeigt, daß mehrfache Vergleiche durchgeführt werden, ein einzelner Vergleich von jeder gegenwärtigen URL mit der Liste von unterstützten URLs in gewissen Ausführungsformen ausreichend sein.
Wenn die gegenwärtige URL einer unterstützten URL entspricht, antwortet die Aktivatoranwendung entsprechend. Beispielsweise führt, wenn die gegenwärtige URL eine unterstützte Überprüfungs- bzw. Austragsseite (ja in Schritt 908) ist, die Aktivatoranwendung einen Überprüfungsprozeß (Schritt 910) durch. Der Überprüfungsprozeß kann ein Informieren des Anwenders beinhalten, daß die Überprüfungsseite durch eine Popup-Botschaft unterstützt wird, oder durch Anzeigen eines speziellen Bildzeichens bzw. Ikons in der Systemablage oder in dem laufenden Fenster. Wenn die Brieftaschen-Klient-Anwendung 214 nicht schon offen ist, kann die Aktivatoranwendung ein Dialogfenster präsentieren oder eine andere Anforderung an den Anwender veranlassen, welche anzeigt, daß die Seite durch die Brieftaschen-Anwendung 214 unterstützt ist. Die Aufforderung bzw. Anforderung kann auch einen Knopf oder einen anderen Mechanismus zur Verfügung stellen, durch welchen der Anwender die Brieftaschen-Anwendung 214 öffnen kann.
Wenn die vorliegende URL einer unterstützten Zahlungsseite (ja in Schritt 912) entspricht, kann die Aktivatoranwendung Zahlungsinstruktionen an die Brieftaschen-Anwendung zur Verfügung stellen oder kann anderweitig die Regelung bzw. Steuerung an die Brieftaschen-Anwendung (Schritt 914) übergeben. Botschaften, welche zwischen der Aktivatoranwendung, der Brieftaschen-Anwendung, dem Browser und dgl. gesandt werden, können durch Open-Desktop-Botschaften, Object-Linking-and-Embedding-(OLE)-Botschaften, Objektroutinenaufrufe, OS-Aufrufe oder dgl. gesandt werden.
In verschiedenen Ausführungsformen wird die oben beschriebene Funktionalität unter Verwendung von Cookies erzielt, wie dies als nächstes beschrieben ist. Cookies werden verwendet, um einen gültigen Anwenderkontext zu detektieren bzw. festzustellen. Wenn ein gültiger Anwenderkontext detektiert ist, wird der Aktivator entweder: eine Serveranwendung starten oder eine Server-Werkzeugleiste bzw. einen Server-Werkzeugbalken starten, welche(r) dem Anwender bzw. Benutzer ermöglicht, andere Anwendungen zu starten. Beispielsweise kann ein Browser eines Anwenders verschiedene Cookies aufweisen, welche die Fähigkeit anzeigen, entweder über eine private Zahlung oder ein spezielles Kartenprodukt einzukaufen. Der Aktivator kann eine Werkzeugleiste bzw. einen Werkzeugbalken starten, welche(r) dem Anwender erlaubt, ein gewünschtes Zahlungsinstrument (beispielsweise von privaten Zahlungen oder einer Karte in der digitalen Brieftasche des Anwenders) auszuwählen. Es wird geschätzt bzw. erkannt werden, daß die verfügbaren Anwendungen nicht notwendigerweise alle zu einer Einkaufstransaktion in bezug stehen. In verschiedenen Ausführungsformen wird die Kontextinformation sowohl auf einem Server als auch in Cookies gespeichert, welche dem Browser zugeordnet sind. Beispielsweise können die Cookies als ein Schlüssel wirken bzw. agieren, durch welchen die Kontextinformation von dem Server abgerufen bzw. ausgelesen werden kann.
Eine andere Funktionalität (Schritt 916) kann auch in die Aktivatoranwendung aufgenommen sein. Beispielsweise könnten Sicherheitsmechanismen (beispielsweise diejenigen, welche oben und unten beschrieben sind), Kunden-Überwachungsfunktionen, Gutschriften bzw. Coupons, spezielle Angebote und dgl. implementiert sein bzw. werden. In dem Fall von Coupons oder speziellen Angeboten könnte der Aktivator die gegenwärtige URL als einem speziellen Produkt oder einer Web-Site entsprechend erfassen. Wenn der Anwender zu der bestimmten, unterstützten URL "surft" oder browst, stellt die Aktivatoranwendung die Übereinstimmung fest und präsentiert dem Anwender (über ein Dialogfenster oder den Browser oder dgl.) ein spezielles Angebot, wie beispielsweise eine Gelegenheit, ein bestimmtes Produkt zu erstehen bzw. zu kaufen oder einen speziellen Rabatt bei einem Einkauf zu erhalten. Es wird geschätzt bzw. erkannt werden, daß eine andere Funktionalität in der Aktivatoranwendung aufgenommen werden könnte, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
In verschiedenen Ausführungsformen der Erfindung ist der Brieftaschen-Klient 214 (2) mit Information vorausgefüllt, welche für den bestimmten Anwender/Kunden spezifisch ist. Unter Bezugnahme auf 1 kann sich ein Anwender für eine digitale Brieftasche durch ein Kontaktieren eines Webservers, wie beispielsweise den Brieftaschen-Server 140 im Netzwerk 102 anmelden. Der Anmelder füllt ein Registrationsformular aus (welches beispielsweise durch CGI-Scripts erzeugt werden kann), um sich für die Brieftasche anzumelden. Der Brieftaschen-Server 140 empfängt bzw. erhält in geeigneter Weise demografische, Konto- und andere Information (beispielsweise Adresse, Versandadresse, Name, Kreditkartennummer und dgl.) von einem Authentifizierungsserver 306 (3) oder einem anderen Server in einem privaten Netzwerk. Diese Information kann verwendet werden, um einen Brieftaschen-Klienten 214 (2) zu konfigurieren, welcher für den speziellen Anwender bzw. Benutzer einzigartig ist. Ein Verfahren zum Konfigurieren des Brieftaschen-Klienten 214 ist, ein Konfigurationsfile bzw. eine Konfigurationsdatei zu erzeugen, welche(s) dem Klienten 214 zugeordnet ist und welche(s) durch den Klienten 214 gelesen wird, um eine Brieftaschen-Information, wie oben beschrieben, zu erhalten.
Vorzugsweise beinhaltet die Registrationsinformation auch Kartenlesegerät-Information, welche beinhaltet, ob der Kartenlesegerätanschluß seriell oder ein USB-uPort bzw. -Anschluß sein soll. Wenn die Brieftaschen-Anmeldung zugelassen bzw. angenommen wird, kann ein Kartenlesegerät an den Anwender versandt oder diesem auf andere Weise zur Verfügung gestellt werden, und ein spezieller Code (wie beispielsweise ein kryptografischer Schlüssel oder ein Paßwort oder eine andere Art eines elektronischen oder gedruckten Codes) wird dem Anwender auch zur Verfügung gestellt. Der Anwender registriert sich dann für das Online-Brieftaschen-Service durch ein elektronisches Kontaktieren des Brieftaschen-Servers 140 und durch ein Authentifizieren an den Server mit der Karte und/oder mit dem speziellen Code. Nach einem Bereitstellen des speziellen Codes erhält der Anwender eine speziell konfigurierte Kopie der Brieftaschen-Software, welche auf einem Kundencomputer 110 in geeigneter Weise installiert werden kann. Der Brieftaschen-Vorausfüll-Vorgang kann mit jeder Kreditkarte oder Zahlkarte durch ein einfaches Assoziieren einer Version des Brieftaschen-Programms mit einem speziellen Code verwendet werden. Konfigurationsinformation für einen bestimmten Anwender ist einem Code zugeordnet, welcher dem Anwender zur Verfügung gestellt wird, welcher später den speziellen Code präsentie ren kann, um sich bei dem Brieftaschen-Server 140 zu authentifizieren bzw. seine Identität nachzuweisen, um eine Kopie der Brieftasche zu erhalten, welche bereits mit Daten vorkonfiguriert wurde, welche für den bestimmten Anwender spezifisch sind.
Insbesondere unter Bezugnahme nunmehr auf 1 und 10 beginnt bzw. initialisiert ein Kunde 110 in geeigneter Weise eine Transaktion, indem er sich auf dem Brieftaschen-Server 140 unter Verwendung einer Smartcard 102 einloggt. Um sich auf dem Brieftaschen-Server einzuloggen, kann sich der Kunde 110 zuerst mit dem Sicherheits-Server 130 über einen Browser 260 verbinden. Der Anwender wählt einen bestimmten Uniform Resource Locator (URL) für die Einlog-Seite durch eine Markierung, eine Internet-Kurzverbindung, einen Hyperlink oder eine andere geeignete Technik. Der Sicherheitsserver 130 kann dann eine Einlog-Seite über ein Netzwerk-Interface bzw. eine Netzwerk-Schnittstelle 302 zur Verfügung stellen. In verschiedenen Ausführungsformen werden ein Formulareingabe- und -absendeknopf für eine Anwender/Paßwort-Eingabe und eine Hypertext-Verbindung für ein Smartcard-Einloggen als Teil der Einlog-Seite zur Verfügung gestellt. Der Anwender wählt das Smartcard-Einloggen und der Browser 216 antwortet in geeigneter Weise durch ein Bereitstellen einer Einlog-Anforderungs- bzw. -Anfragebotschaft 1002 (10). Der Sicherheits-Server 130 empfängt eine Einlog-Anfrage 1002 und initialisiert den Smartcard-Einloggprozeß in geeigneter Weise. In verschiedenen Ausführungsformen formatiert der Sicherheits-Server 130 eine kryptografische bzw. verschlüsselte Abfrage bzw. Challenge durch den Autorisierungs-Server 306 oder die Sicherheitsmaschine 304 in Antwort auf die Einlog-Anfragebotschaft 1002. Eine kryptografische bzw. Verschlüsselungsaufforde rung bzw. -abfrage 1004 ist eine Art einer Abfragebotschaft, welche Replay- bzw. Wiederholungsattacken verhindert (beispielsweise betrügerische Botschaften, welche durch ein neuerliches Senden von gesandten Authentifizierungs-Paketen erzeugt werden), wie beispielsweise eine Abfrage, welche auf Zufallszahlen basiert und ausgebildet bzw. konstruiert ist, um eine Antwort von der X.509-Anwendung, welche auf der Smartcard 202 gespeichert ist, zu erzwingen bzw. herauszufordern. Die Abfrage wird dann in geeigneter Weise dem Kunden 110 über das Netzwerk 102 als eine Challenge- bzw. Abfragebotschaft 1004 zur Verfügung gestellt.
Bei einem Erhalt einer Abfragebotschaft 1004 gibt der Browser 216 in geeigneter Weise die Botschaft 1002 an den Brieftaschen-Klienten 214 für ein Be- bzw. Verarbeiten mit der Smartcard 202 weiter. Wenn der Brieftaschen-Klient 214 nicht läuft, kann der Browser 216 automatisch das Programm öffnen. Der Brieftaschen-Klient 214 bereitet dann die Signatur- bzw. Unterschriftantwort in geeigneter Weise vor. Beispielsweise kann der Brieftaschen-Klient 214 die Serverpbfrageinformation entnehmen bzw. extrahieren, eine neue Klientenabfrage (d.h. eine zweite, kryptografische bzw. verschlüsselte Aufforderung bzw. Abfrage für die Smartcard 202) formatieren, beide Abfragen in eine Doppel-Abfrage kombinieren und ein Hash der Doppel-Abfrage für eine spätere Verwendung beispielsweise in einem kryptografischen bzw. Verschlüsselungsblock eines Public Key Cryptographic System 1 (PKCS1) berechnen. Der Hash kann in Übereinstimmung mit irgendeinem Algorithmus, wie beispielsweise MD3 oder MD4 berechnet werden und wird geeigneterweise verwendet, um die Vollständigkeit und Genauigkeit der Daten in dem Doppel-Abfrageblock zu garantieren. Es wird verstanden, daß PKCS1 ein Public Key Cryptographic Standard bzw. Verschlüsselungsstandard mit öffentlichem Schlüssel ist, welcher Mechanismen zum Verschlüsseln und Signieren von Daten unter Verwendung von RSA Public Key Crypto Systemen bzw. RSA-Verschlüsselungssystemen mit öffentlichem Schlüssel definiert. Der PKCS-Standard ist vollständig definiert in PKCS#1: RSA Cryptography Specifications Version 2.0, datiert September 1998 (erhältlich online von http://www.rsa.com/rsalabs/ pubs/PKCS/html/pkcs-l.html).
Der PKCS1-Block wird in geeigneter Weise der Smartcard 202 über ein Lesegerät bzw. einen Leser 204 für eine Bearbeitung zur Verfügung gestellt (Schritt 1006 in 10) . In verschiedenen Ausführungsformen wirkt das Kartenlesegerät 204 mit einem Kundencomputer 110 zusammen, um den Anwender zu einer persönlichen Identifikation aufzufordern, beispielsweise eine Personal Identification Number (PIN, persönliche Identifiaktionsnummer) oder eine andere, einzigartige Identifikation, um Zutritt zu der Karte zu erlangen. In einer bevorzugten Ausführungsform wird ein PIN auf der Smartcard 202 gespeichert. Alternativ kann ein PIN oder eine andere persönliche Identifikation an einer anderen Stelle an dem System, beispielsweise auf dem Lesegerät 204 oder auf dem Kundencomputer 110 gespeichert sein. Der Anwender gibt in geeigneter Weise die persönliche Identifikation ein, um die Smartcard 202 zu entriegeln, welche den Doppel-Abfrageblock von dem Brieftaschen-Klienten 214 erhält, und unterschreibt digital den Block in geeigneter Weise. In verschiedenen Ausführungsformen enthält die Smartcard 202 einen privaten Schlüssel, welcher verwendet wird, um eine digitale Signatur des Blocks zu berechnen. Der unterfertigte Block wird dann zu dem Brieftaschen-Klienten 214 in geeigneter Weise retourniert. In verschie denen Ausführungsformen stellt die Smartcard 202 auch ein Zertifikat (wie beispielsweise ein X.509-Zertifikat) zur Verfügung, welches dem privaten Schlüssel entspricht, welcher verwendet wurde, um die digitale Signatur zu berechnen.
Nach einem Erhalt der Signatur und des Zertifikats von der Smartcard 202 erzeugt der Brieftaschen-Klient 214 in geeigneter Weise eine entsprechende Antwortbotschaft 1008, welche an den Sicherheits-Server 130 zu senden ist. Obwohl eine Antwortbotschaft 1008 in jedem beliebigen Format sein kann, formatieren verschiedene Ausführungsformen Antwortbotschaften 1008 als eine PKCS7-Botschaft, wie sie in PKCS#7: Cryptographic Message Syntax Standard, An RSA Laboratories Technical Note, Version 1.5, überarbeitet 1. November 1993, erhältlich online von ftp://ftp.rsa.com/pubpkcs/doc/pkcs-7.doc, definiert ist.
Nach einem Empfang bzw. Erhalt der Antwortbotschaft 1008 bearbeitet der Sicherheits-Server 130 in geeigneter Weise (Schritt 1010 in 10). In verschiedenen Ausführungsformen wird die Antwortbotschaft 1008 zu dem Autorisierungsserver 306 umgeleitet, welcher das Zertifikat und die Signatur bzw. Unterschrift verifiziert bzw. überprüft, welche durch die Smartcard 202 zur Verfügung gestellt wird. Bei einer erfolgreichen Verifizierung des Zertifikats und der Gültigkeit der Unterschrift kann in verschiedenen Ausführungsformen ein Sicherheitstoken bzw. eine Sicherheits-Berechtigungsmarke erzeugt und an den Kunden 110 oder die Smartcard 202 retourniert werden.
Auf diese Weise stellt eine nachfolgende Präsentation der Sicherheits-Berechtigungsmarke Mittel für den Anwender zur Verfügung, um die Identität aufzubauen und sicher mit dem Brieftaschen-Server zu verkehren. In verschiedenen Ausführungsformen kann auch der Autorisierungs-Server 306 eine zusätzliche Sicherheits-Berechtigungsmarke erzeugen, welche den Anwender bzw. Benutzer identifiziert. In verschiedenen Ausführungsformen kann diese Berechtigungsmarke aus mehrfachen Abschnitten bestehen, welche dann zu einem entsprechenden, digitalen Zertifikat, der Smartcard oder anderen Daten, möglicherweise unter Verwendung von Daten in einer Datenbank 310, führen können. In verschiedenen Ausführungsformen können die zusätzliche Sicherheits-Berechtigungsmarke und/oder Abschnitte darin dem Kunden 110 im Zusammenhang mit einer Umleitungs- bzw. Rückführungsbotschaft 1012 zur Verfügung gestellt werden. In verschiedenen Ausführungsformen kann die zusätzliche Sicherheits-Berechtigungsmarke dem Kunden zur Verfügung gestellt werden oder an dem Autorisierungsserver 306 aufrecht erhalten werden.
Bei einem Erhalt einer Redirect- bzw. Umleitungsbotschaft 1012 kontaktiert der Kunde 110 in geeigneter Weise den Brieftaschen-Server 140, um eine Verbindung anzufordern. In verschiedenen Ausführungsformen kann die Botschaft 1014" Anfrage verbinden" in geeigneter Weise die Sicherheits-Berechtigungsmarke und möglicherweise die zusätzliche Sicherheits-Berechtigungsmarke in ihrer Gesamtheit oder als Teil der Redirect- bzw. Umleitungsbotschaft 1012 enthalten. Der Brieftaschen-Server 140 fragt den Sicherheits-Server 130 unter Verwendung einer gewissen Kombination von Sicherheits-Berechtigungsmarken im Ganzen oder teilweise ab, um eine Identifikation des Kunden 110 zu erhalten. Die Abfrage 1016 und Antwort 1018 werden in geeigneter Weise über das Netzwerk 150 übertragen, welches in einigen Ausführungsformen getrennt von dem Netzwerk 102 aufrecht erhalten wird, um die Sicherheit des Systems 100 zu erhöhen. Eine alternative Ausführungsform verwendet das Netzwerk 102, welches in einigen Ausführungsformen eine erhöhte Sicherheit durch ein Virtual Private Network, SSL-Protokoll, eine Verwendung von geteilten Geheimnissen und/oder anderen kryptografischen bzw. zurückgesandte bzw. Rückbeglaubigungen bzw. -berechtigungsnachweise 1018 in Ordnung sind, erhält der Brieftaschen-Server 140 dem Kunden 110 zugehörige bzw. entsprechende Attribute von der Brieftaschen-Datenbank 408 und verständigt den Kunden 110 von einem erfolgreichen Einloggen über eine Botschaft 1020. Es wird geschätzt bzw. erkannt werden, daß alternative Ausführungsformen einer Einlogg-Sequenz möglich sind. Es wird auch geschätzt werden, daß jegliche Art von Verschlüsselungsschemata, Botschaftsformaten und dgl. verwendet werden kann, um eine Einlog-Sequenz 1000 zu implementieren.
Nunmehr unter Bezugnahme auf 11 beginnt ein beispielhaftes Authentifizierungs-Flußdiagramm 1100, welches für eine Verwendung während einer Einkaufstransaktion geeignet ist, damit, daß ein Kunde 110 eine Anforderung bzw. Anfrage 1102 bei dem Brieftaschen-Server 140 für einen Fall (beispielsweise einen Einkauf) plaziert, für welchen eine Authentifizierung bzw. ein Nachweis erforderlich ist. Der Brieftaschenserver 140 erkennt in geeigneter Weise den Vorfall bzw. das Ereignis und überträgt eine Anforderungsbzw. Anfragebotschaft 1104 an den Sicherheits-Server 130 beispielsweise über einen Kommunikationskanal 150, um eine Anfragebotschaft zu formatieren. Der Authentifizierungs-Server 306 (oder eine andere Komponente des Sicherheits-Servers 130, falls geeignet) formatiert dann eine Abfragebotschaft 1106 (welche Zufallsdaten enthalten kann) und stellt die Anfragebotschaft 1106 an den Brieftaschen-Server 140 beispielsweise über die Verbindung 150 zur Verfügung. Der Brieftaschen-Server 140 erhält die Abfragebotschaft 1106 und leitet die Abfragedaten an den Browser 216 als eine Signatur- bzw. Unterschrifts-Abfragebotschaft 1108 weiter. Der Browser 216 öffnet, falls notwendig, den Brieftaschen-Klienten 214 und leitet die Signatur-Abfragebotschaft 1108 weiter. Wie oben beschrieben, formatiert der Brieftaschen-Klient 214 einen Signatur-Anfrageblock, wie beispielsweise einen PKCS1-Block, welcher eine Serverabfrage, eine Klientenabfrage und einen Hash beinhaltet. Der resultierende Signatur-Anfrageblock wird der Smartcard 202 über das Lesegerät 204 zur Verfügung gestellt. Die Smartcard 202 signiert bzw. unterschreibt in geeigneter Weise den Block und stellt eine Kopie ihres X.509-Zertifikats in geeigneter Weise zur Verfügung.
Der unterschriebene Block kann dann zu dem Brieftaschen-Klienten 214 retourniert werden, welcher in geeigneter Weise eine entsprechende Signatur-Antwortbotschaft 1110 (wie beispielsweise eine PKCS7-Botschaft) formatiert und sie an den Brieftaschen-Server 140 sendet. Der Brieftaschen-Server 140 formuliert dann eine Gültigkeits-Überprüfungsbotschaft 1112, welche Daten von der Signatur-Antwortbotschaft 1110 und der Sicherheits-Berechtigungsmarke beinhaltet, welche dem Kunden 110 während des Einlog-Vorgangs bzw. -Prozesses zugeordnet ist (wie beispielsweise dem beispielhaften Einlogg-Prozeß, welcher in 10 gezeigt ist). In alternativen Ausführungsformen wird die Sicherheits-Berechtigungsmarke von dem Kunden 110 als Teil einer Signatur-Antwortbotschaft 1110 erhalten. Die Gültigkeits-Überprüfungsbotschaft 1112 wird an den Sicherheits-Server 130 über die Verbindung 150 in geeigneter Weise übersandt. Der Sicherheits-Server 130 kann dann die Gültigkeits-Überprüfungsbot- Schaft an den Autorisierungs-Server 306 in geeigneter Weise weiterleiten, welcher die Signatur bzw. Unterschrift überprüfen kann und die geeignete Sicherheits-Berechtigungsmarke von der Datenbasis 310 entnehmen kann (Schritt 1114 in 11). Die Sicherheits-Berechtigungsmarke und/oder optional der einzigartige Identifikationsode, welcher von der Datenbank entnommen wird, wird dann mit der Sicherheits-Berechtigungsmarke oder dem ID verglichen, welcher von dem Brieftaschen-Server 140 erhalten wird. Wenn die zwei Objekte (beispielsweise Sicherheits-Berechtigungsmarken oder IDs) übereinstimmen, kann abgeleitet werden, daß die gegenwärtig durch den Kunden 110 verwendete Karte dieselbe Karte ist, welche durch den Kunden 110 zum Zeitpunkt eines Einloggens verwendet wird bzw. wurde. Eine entsprechende Zustimmungs- oder Abweisungsbotschaft 1116 wird dann von dem Sicherheits-Server 130 an den Brieftaschen-Server 140 übersandt und es wird erlaubt, daß die Transaktion fortschreitet.
In verschiedenen Ausführungsformen agiert bzw. wirkt der Brieftaschen-Server 140 als ein Ersatz für den Kunden 110 während Transaktionen. Beispielsweise kann der Brieftaschen-Server 140 Einkaufsformulare, beinhaltend Versandadresse, Kartennummer und dgl., im Namen des bzw. für den Einkäufer(s) 110 vervollständigen. Der Händler 120 kann dann den Einkaufsvorgang als eine Standard-Zahlungskarten-Transaktion unter Verwendung von konventioneller Hardware und Software autorisieren. Es wird jedoch erkannt werden, daß die zusätzliche Sicherheit, welche durch die hierin geoffenbarten Systeme zur Verfügung gestellt wird, ein zusätzliches Vertrauen in die Identität des Einkäufers erlauben wird, wodurch eine geringere Diskont- bzw. Nachlaßrate für die Transaktion gerechtfertigt ist.
Verschiedene Ausführungsformen der Erfindung nehmen einen zusätzlichen Schutz gegen einen Sicherheitsbruch auf. Da viele serverseitige Funktionen, welche in den Sicherheits-Server 130 oder den Brieftaschen-Server 140 aufgenommen sind, beispielsweise verschiedene Scriptkomponenten, beinhalten können, welche in Script-Sprachen, wie beispielsweise JavaScript (wie durch Sun Microsystmems in Mountain View, Kalifornien definiert) oder VBScript (wie durch Microsoft Corporation in Redmond, Washington definiert), geschrieben sind, können Server, welche mit dem Netzwerk 102 gekoppelt sind, verschiedene Funktionalitäten den mehrfachen bzw. vielen Klienten 110 durch derartige Serversprachen durch ein Bereitstellen von Scripts (oder Codes) von dem Server an den Klienten zur Verfügung stellen. Der Code wird interpretiert, kompiliert oder auf andere Weise durch den Klientencomputer 110 ausgeführt. In Ausführungsformen, welche JavaScript beinhalten, werden beispielsweise Scripts durch ein Browserprogramm (beispielsweise Internet Explorer, Netscape Communicator oder dgl.) interpretiert und ausgeführt, welche auf dem Klientencomputer 110 laufen. Andere Ausführungsformen beinhalten Nicht-PC-Browser, wie beispielsweise Wireless Application Protocol (WAP) Telefone, welche Wireless Markup Language (WML) Scripts unterstützen. Die verschiedenen Script-Sprachen können Instruktionen, Objekte bzw. Gegenstände oder andere Datenmechanismen beispielsweise für ein Zugreifen auf Files bzw. Dateien auf dem Hardeware-Treiber des Anwenders oder für ein andersartiges Manipulieren von Daten auf dem Computer des Anwenders enthalten. Um nicht-autorisierte Quellen daran zu hindern, einen exekutierbaren Code an den Anwender zur Verfügung zu stellen, können die Script-Sprachen einen Mechanismus enthalten, um den Anwender zu erlauben, Scripts zu genehmigen, welche nur von vertrauenswürdigen Quellen zur Verfügung gestellt werden. Beispielsweise kann ein Anwender, welcher eine elektronische Transaktion, wie oben beschrieben, durchführt, erlauben, daß Scripts, welche von dem Brieftaschen-Server zur Verfügung gestellt werden, ausgeführt werden, wobei er jedoch verhindern kann, daß andere Scripts, welche durch andere Quellen zur Verfügung gestellt werden, auf dem Computer des Anwenders ausgeführt werden.
Ein mögliches Sicherheitsproblem, welches bei vielen Script-Sprachen angetroffen wird, ist in 12A gezeigt. Ein skrupelloser "Cracker" kann eine Web-Site 1204 erzeugen, welche ausgebildet ist, um bösartige Aktivitäten gegen Verwender bzw. Anwender eines legitimen bzw. berechtigten Web-Servers 1206 durchzuführen. Die Cracker-Site 1204 (welche als die "kriminelle Site bzw. Stelle" in der Figur gezeigt ist) kann beispielsweise einen Abschnitt eines Codes, wie beispielsweise ein Script, an den Anwender zur Verfügung stellen. Die kriminelle Site 1204 kann auch den Web-Browser 216 des Anwenders veranlassen, eine spezielle Uniform Resource Locator (URL) bei dem legitimierten Server 1206 anzufordern bzw. aufzurufen (wie beispielsweise den Brieftaschen-Server 140 oder einen anderen Server im Netzwerk 102). Die angesprochene URL kann bewußt so ausgebildet sein, daß der legitimierte Server 1206 beispielsweise eine Fehlerbotschaft oder eine andere Antwort an den Browser 216 des Klienten übermittelt. In verschiedenen Ausführungsformen kann die Antwort von dem legitimierten Server 1206 automatisch einen Abschnitt oder eine Abwandlung der Anforderung von dem Web-Browser 216 des Anwenders beinhalten. Falls diese Antwort JavaScript, VBScript oder einen anderen Code beinhaltet, welcher als ein Resultat der bösartigen Absicht der kriminellen Site 1204 erzeugt wurde, kann dann der Code auf dem Computer des Anwenders ausgeführt werden. Dieses Beispiel illustriert eine von vielen Techniken, in welchen ein "Cracker" einen legitimierten bzw. berechtigten Web-Server 1206 veranlassen kann, bösartige Instruktionen an einen Web-Browser 216 eines Anwenders zu schicken. Da die verschiedenen codierenden und Script-Sprachen Instruktionen für einen Zutritt zu einem File- bzw. Dateiensystem eines Hostcomputers, einem Register oder dgl. enthalten, wird verstanden werden, daß die nicht-autorisierte Ausführung eines derartigen Codes höchst unerwünscht ist. Nichtsdestotrotz kann die in 12A gezeigte Technik erlauben, daß ein Script oder ein anderer Code von einer kriminellen Site 1204 einem Computer eines Anwenders zur Verfügung gestellt wird. Da der Computer des Anwenders glaubt, daß das Script von einer vertrauenswürdigen Quelle (d.h. dem Brieftaschen-Server) stammt, kann der Computer des Klienten den Code von der kriminellen Site ausführen, wodurch das Potential für einen Schaden, eine nicht-autorisierte Datenverteilung bzw. -verbreitung oder eine Zerstörung oder dgl. erzeugt wird. 12B illustriert den korrekten Kommunikationsfluß, welcher auftreten sollte (im Gegensatz zu dem Flußdiagramm der kriminellen Attacke, welches in 12A gezeigt ist) .
Um dieses mögliche bzw. potentielle Sicherheitsproblem zu verhindern, beinhalten verschiedene Ausführungsformen der Erfindung in geeigneter Weise Techniken zum Reduzieren oder Eliminieren eines unerwünschten, ausführbaren bzw. exekutierbaren Codes. Unter Bezugnahme auf 13 beinhaltet ein Prozeß 1300 zum Reduzieren der Wahrscheinlichkeit von Script-Attacken in geeigneter Weise die Schritte eines Beschränkens bzw. Begrenzens der Abschnitte des Servers, welche 'eine erhöhte Erlaubnis aufweisen (Schritt 1302), eines Entfernens von gefährlichen Zeichen bzw. Buchstaben innerhalb des Abschnitts der Site (Schritt 1304), eines Codierens von gewissen Zeichen bzw. Buchstaben, wo notwendig (Schritt 1306), und gegebenenfalls eines Einloggens bzw. Einbringens von Daten, welche von Anwendern von dem relevanten Abschnitt der Web-Site zur Verfügung gestellt werden (Schritt 1308).
Unter Bezugnahme auf Schritt 1302 beinhaltet eine Web-Site typischerweise verschiedene Seiten, wobei jede Seite eine einzigartige URL aufweist. Verwender bzw. Anwender dieser Site können eine erhöhte Vertrauenswürdigkeit in bestimmte Server setzen (wie beispielsweise diejenigen entsprechend Finanzinstituten oder Händlern, welche vertrauenswürdig sind bzw. einen guten Ruf haben). Durch eine Beschränkung der erhöhten Vertrauenswürdigkeit nur auf einen Abschnitt bzw. Bereich der Web-Site (beispielsweise einen begrenzten Untersatz von URLs entsprechend der vertrauenswürdigen Web-Site), wird das Niveau der dem Rest der Site zugeordneten Vertrauenswürdigkeit entsprechend reduziert und die Sicherheit erhöht. Die Vertrauenswürdigkeit kann auf einen beschränkten Abschnitt der Site durch ein Konfigurieren des Web-Browsers des Anwenders beschränkt werden, indem beispielsweise nur einem Abschnitt der Site vertraut wird. Der Web-Browser des Anwenders kann manuell oder durch ein Konfigurationsscript konfiguriert werden, welches beispielsweise durch einen Brieftaschen-Server zur Verfügung gestellt wird. Wenn nur gewisse Seiten (d.h. ein Abschnitt) der Web-Site mit erhöhter Vertrauenswürdigkeit ausgestattet sind, werden jegliche Scripts, welche in Referenzen bzw. Bezugnahmen auf andere Seiten enthalten sind, entweder nicht ausgeführt oder werden nicht mit erhöhter Vertrauenswürdigkeit ausgeführt.
Zusätzlich zu (oder als eine Alternative zu) einem Konfigurieren des Klienten derart, daß der Klient nur einem gewissen Abschnitt des Servers "vertraut", kann der Server konfiguriert sein, um die Sicherheit der Klient-Server-Interaktion zu verbessern. Beispielsweise kann ein Scripting mit erhöhter Vertrauenswürdigkeit in den meisten Bereichen des Servers nicht zugelassen sein, um die Sicherheit zu erhöhen. Darüber hinaus können Daten, welche dem vertrauenswürdigen Abschnitt der Web-Site zur Verfügung gestellt werden, überwacht und/oder modifiziert werden, bevor sie an die Anwender retourniert werden (Schritte 1304 und 1306). Die meisten Script-Sprachen erfordern gewisse Zeichen zum Formatieren von Befehlen. Beispielsweise ist die JavaScript-Sprache häufig mit Script-Instruktionen codiert, welche zwischen winkeligen Klammern ("<" und ">") angeordnet sind. Somit können die Spitzklammern von jeglichem Inhalt entfernt werden, welcher durch einen vertrauenswürdigen Abschnitt der Web-Site retourniert wird. Wenn eine Web-Seite, welche von einem vertrauenswürdigen Abschnitt der Web-Site zur Verfügung gestellt wird, ein "kriminelles" JavaScript-Programm enthalten sollte, welches versucht, beispielsweise Spitzklammern zu verwenden, würden die Script-Instruktionen nicht an dem Computer des Anwenders ausgeführt werden, da die Script-Instruktionen nicht ordnungsgemäß nach einem Entfernen der Spitzklammern formatiert wären. Alternativ könnten verschiedene bzw. gewisse "gefährliche" Zeichen (wie beispielsweise die Spitzklammern in JavaScript) in ein alternatives Format, beispielsweise in eine "Etzeichen-Notation" mit einem Etzeichen ("&") und einen Wert des American Standard Code for Information Interchange (ASCII) für das spezielle Zeichen oder durch ein Ersetzen des "gefährlichen" Zeichens mit einem sicheren Zeichen, wie beispiels weise einem "Leerraum"-Zeichen (Schritt 1306) rückgeführt werden. Es wird erkannt werden, daß jegliche Zeichen in verschiedenen Ausführungsformen der Erfindung in Abhängigkeit von den speziellen Sprachen, den Script-Umgebungen und dgl. eliminiert oder codiert werden können, welche verwendet werden können.
In verschiedenen Ausführungsformen beinhaltet ein optionaler Schritt 1308 in geeigneter Weise ein Aufrechterhalten eines Datenprotokolls von Information, welche durch die verschiedenen Abschnitte der Web-Site zur Verfügung gestellt wird. Sämtlicher Inhalt, in welchem Zeichen codiert oder entfernt wurden, kann geloggt bzw. protokolliert werden, so daß das Protokoll überprüft werden kann, um zu bestimmen, ob die Web-Site verwendet wird, um einen Netzwerk-Klienten zu schädigen bzw. zu beeinträchtigen. Beispielsweise können der gesamte Inhalt, welcher von der Web-Site zur Verfügung gestellt wird, der gesamte Inhalt, welcher von innerhalb des vertrauenswürdigen Abschnitts zur Verfügung gestellt wird, der gesamte Inhalt, welcher Script/Programmier-Inhalt enthält, der gesamte Inhalt von außerhalb des vertrauenswürdigen Abschnitts oder von jeglichem Teil des Web-Site-Inhalts in ein oder mehr Datenfile(s) protokolliert werden. Die Datenfiles können in geeigneter Weise durchsucht oder anders konsultiert bzw. befragt werden, um zu bestimmen, ob Versuche existierten, einen nichtautorisierten Inhalt an Anwender durch den Server zur Verfügung zu stellen.
In einigen Fällen können interne Maschinen durch eine "kriminelle" Site attackiert werden, welche Inhalte sendet, welche ein Script an einen Netzwerk-Server enthalten, welcher den Inhalt in Prüfungs- (beispielsweise Protokoll-) Files protokollieren kann. Unter der Voraussetzung, daß ein Browser mit einer erhöhten Vertrauenswürdigkeit für auf dem Server vorhandene Files bzw. Dateien konfiguriert worden sein kann, kann in verschiedenen Ausführungsformen, wenn ein Anwender die Prüfungs-Files bzw. -Dateien des Web und von anderen e-Commerce-Servern unter Verwendung des Browsers überprüft, ein Script auf dem Netzwerk-Klienten mit dem Vertrauensniveau des Netzwerk-Servers ausgeführt werden, welche die Prüfungsaufzeichnungen (beispielsweise mit einem erhöhten Vertrauenswürdigkeitsniveau) geliefert hat. Eine Ausführung dieses Scripts kann eine Attacke bewirken, welche auftreten kann, lange nachdem das Script an den Netzwerk-Server gesandt wurde. Diese Attacke ist unter Verwendung derselben Methoden und Prozeduren, welche oben beschrieben wurden, verhinderbar, um ein Cross-Site-Scripting zu verhindern, wie beispielsweise die "kriminellen" Attacken, welche oben beschrieben sind. Ein Filter, wie beispielsweise das in 13 beschriebene, welches auf einem Netzwerk-Server, wie beispielsweise einem Web-Server, oder einem Netzwerk-Klienten, wie beispielsweise einem PC-Browser, läuft, kann nach Script-Steuerzeichen filtern und die Zeichen codieren, die Zeichen verwerfen oder die gesamte Rufzeichnung verwerfen.
Der Umfang der Erfindung sollte durch die zugelassenen Ansprüche eher als durch die oben gegebenen Beispiele bestimmt werden.

Claims

Ein Verfahren zum Bedienen einer Computervorrichtung zum Durchführen einer Transaktion, wobei das Verfahren Folgendes beinhaltet: a. Empfangen einer Transaktionsanfrage (1002; 1102) von einem Anwender an einem Server (140; 130); b. Ausgeben einer Abfrage (1004; 1106, 1108) an den Anwender; c. Empfangen einer Antwort (1008; 1110, 1112) vom Anwender basierend auf der Abfrage; d. Verarbeiten der Antwort, um den Anwender zu überprüfen (1010; 1114); e. Assemblieren von Berechtigungsnachweisen für die Transaktion, wobei die Berechtigungsnachweise mindestens einen Schlüssel beinhalten; f. Versorgen des Anwenders (1012) mit mindestens einem Anteil der Berechtigungsnachweise; g. Empfangen einer zweiten Anfrage (1014; 1110) vom Anwender, wobei die zweite Anfrage einen Anteil der Berechtigungsnachweise umfaßt; und h. Validieren (1016, 1018; 1112, 1116) des Anteils der Berechtigungsnachweise mit dem Schlüssel, um Zugang zu einem Transaktionsdienst bereitzustellen.
Verfahren gemäß Anspruch 1, wobei die Transaktion eine elektronische Einkaufstransaktion ist.
Verfahren gemäß Anspruch 2, wobei die elektronische Einkaufstransaktion durchgeführt wird, indem eine digitale Brieftasche (140; 214) verwendet wird.
Verfahren gemäß Anspruch 1, 2 oder 3, wobei der Anwender die Transaktion über eine Smart- bzw. Chip-Karte (202) durchführt.
Ein Transaktionssystem (100) zum Vereinfachen einer finanziellen Transaktion, die auf einem Datennetz (102) von einem Anwender, der einen Anwendercomputer (110) bedient, erfragt wird, wobei das System Folgendes beinhaltet: a. einen Transaktionsautorisierer (120); und b. einen Sicherheitsserver (130), der konfiguriert ist, um zu überprüfen, daß der Anwender eine intelligente Berechtigungsmarke besitzt, und um den Anwendercomputer mit einem digitalen Berechtigungsnachweis zu versorgen, wenn diese Überprüfung erfolgreich ist; wobei der Transaktionsautorisierer (120) konfiguriert ist, um eine vom Anwender erfragte Transaktion mindestens teilweise auf der Basis des digitalen Berechtigungsnachweises, der von dem Anwendercomputer über das Datennetz (102) bereitgestellt wird, zu autorisieren.
Transaktionssystem gemäß Anspruch 5, das ferner einen Transaktionstoolserver beinhaltet.
Transaktionssystem gemäß Anspruch 5 oder 6, das ferner einen Brieftaschenserver (140), der über das digitale Netz (102) mit dem Anwendercomputer (110) kommuniziert, beinhaltet.
Transaktionssystem gemäß Anspruch 7, wobei der Brieftaschenserver (140) konfiguriert ist, um eine Anfrage (1102) nach einer Transaktion vom Anwendercomputer (110) zu empfangen, um ein Händlercomputersystem (120) zu kontaktieren und das Händlercomputersystem mit Informationen über den Anwender (110) zu versorgen.
Transaktionssystem gemäß einem der Ansprüche 5-8, wobei der Anwendercomputer (110) ein Transaktionstool und einen Leser (204) beinhaltet, wobei der Leser konfiguriert ist, um Informationen zwischen dem Transaktionstool und der intelligenten Berechtigungsmarke zu übertragen.
Transaktionssystem gemäß Anspruch 9, wobei das Transaktionstool ein Brieftaschenkunde (214) ist.
Transaktionssystem gemäß einem der Ansprüche 5-10, wobei die intelligente Berechtigungsmarke eine Smart- bzw. Chip-Karte (202) ist.
Transaktionssystem gemäß einem der Ansprüche 5-11, wobei die Verbindung zwischen dem Sicherheitsserver (130) und dem Transaktionsautorisierercomputer (120) durch eine vom Datennetz (102) separate Datenverbindung (152) erfolgt.
Transaktionssystem gemäß Anspruch 9, wobei das Transaktionstool mit dem Sicherheitsserver (130) über eine vom Datennetz (102) separate Datenverbindung (150) kommuniziert.
Transaktionssystem gemäß einem der Ansprüche 5-13 wobei die intelligente Berechtigungsmarke ein digitales Zertifikat beinhaltet, das den der intelligenten Berechtigungsmarke zugeordneten Anwender eindeutig kennzeichnet.
Transaktionssystem gemäß Anspruch 14, wobei der Anwender der intelligenten Berechtigungsmarke durch einen persönlichen Kennzeichner den Zugang zum digitalen Zertifikat freischaltet.
Transaktionssystem gemäß einem der Ansprüche 5-15, wobei die intelligente Berechtigungsmarke von einem Ausgeber ausgegeben wird und wobei eine unter Verwendung des Transaktionssystems ausgeführte Transaktion als eine "Card-Present"-Transaktion betrachtet wird, wie es von dem Ausgeber der intelligenten Berechtigungsmarke angesehen wird.
Ein im Computer eingesetztes Verfahren zum Vereinfachen des Zugangs zu einem Dienst, wobei das Verfahren folgende Schritte beinhaltet: Empfangen einer Einlog-Anfrage (1002) von einem Anwender; Überprüfen, daß der Anwender eine Berechtigungsmarke besitzt (1004, 1006, 1008, 1010); Versorgen des Anwenders mit einem Berechtigungsnachweis, wenn die Überprüfung erfolgreich ist (1012); Empfangen einer Transaktionsanfrage von einem Anwender (1014), wobei die Transaktionsanfrage mindestens einen Teil des Berechtigungsnachweises beinhaltet; und Verarbeiten des mindestens einen Teils des Berechtigungsnachweises, um Zugang zu dem Dienst (1016, 1018) bereitzustellen.
Verfahren gemäß Anspruch 17, wobei der Überprüfungsschritt eine Abfrageantwort beinhaltet.
Verfahren gemäß Anspruch 18, wobei die Abfrageantwort der Berechtigungsmarke bereitgestellte Zufallsdaten beinhaltet.
Verfahren gemäß Anspruch 19, wobei die Abfrageantwort ferner eine digitale Signatur der Zufallsdaten beinhaltet.
Verfahren gemäß einem der Ansprüche 17-20, wobei der Dienst eine finanzielle Transaktion ist.