DE60014341T2

DE60014341T2 - Server, der die automatische einfügung von daten in elektronische formulare auf einem nutzer-computer ermöglicht

Info

Publication number: DE60014341T2
Application number: DE60014341T
Authority: DE
Inventors: A. Matthew MARKUS; M. Erick HERRARTE
Original assignee: American Express Travel Related Services Co Inc
Current assignee: American Express Travel Related Services Co Inc
Priority date: 1999-01-15
Filing date: 2000-01-14
Publication date: 2005-12-15
Anticipated expiration: 2020-01-15
Also published as: WO2000042539A3; BR0007518A; AU2414400A; US6490601B1; DE60014341D1; EP1166216B1; DK1166216T3; EP1166216A2; WO2000042539A2; PT1166216E; ES2230057T3; JP2002535753A; ATE278222T1

Description

Hintergrund der Erfindung
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft im Allgemeinen Computersoftware zur Ausfüllung von Dokumentenformularen über ein Computernetzwerk. Die vorliegende Erfindung stellt insbesondere ein Verfahren und System zum automatischen Ausfüllen von Feldern in einem elektronischen Dokumentenformular mittels eines Browserprogramms bei Verwendung eines entfernten Servers zur Verfügung.
2. Stand der Technik
Rapides Wachstum und technologische Fortschritte haben die Art und Weise mit der die meisten Leute zurzeit den Computer nutzen verändert. Zu Beginn des Computerzeitalters gab es ein Paradigma, dass es mehr Computernutzer als Computer gibt und somit hatten die meisten Computer viele zugewiesene oder zugeordnete Nutzer. Mit Weiterentwicklung der Technologie tauchte der persönliche Computer ("PC") auf und es wurde üblich, dass viele Computer nur einen Nutzer hatten. Nachfolgendes Wachstum, insbesondere in den 90ern, hat eine Kultur entwickelt oder ein Paradigma auftauchen lassen, wobei ein Computernutzer Zugang zu mehr als einem Computer hat. Somit haben viele Individuen nun maßgeblichen Zugang zu mehreren Computern, beispielsweise am Arbeitsplatz, Schulen, Büchereien, daheim oder auf Reisen. Das Verhältnis an zugänglichen Computern pro Nutzer sollte mit der Zeit noch zunehmen. Es wird daher zunehmend erforderlich, computerbasierte Programme und Dienste zu haben, die von einem einzelnen Nutzer von irgendeinem Computer zugänglich sind und nicht von lediglich solchen Computern, die für diesen einzelnen Nutzer programmiert oder angepasst wurden.
Ein Ergebnis der jüngsten explosionsartigen Entwicklung auf dem Bereich der Computer betrifft den Datenübertragungsumfang, der nun zwischen einzelnen Computern oder Computersystemen auftritt. Viele Verfahren und Systeme existieren zur Zwecken der Datenübertragung zwischen Computern oder Computersystemen. Die spiegelt sich in vielerlei Zusammenhängen wieder, beispielsweise im Wachstum des Internets. Aus Gründen der Praktikabilität werden bei der nachfolgenden Beschreibung einige Verfahren und Systeme anhand des Internets beschrieben. Es sollte jedoch deutlich werden, dass dadurch nicht beabsichtigt ist, den Umfang dieser Beschreibung zu beschränken und dass viele andere verwendbare Vorrichtungen und Protokolle für die Computerdatenübertragung existieren, wie die "Intranets", geschlossene Proxy-Netzwerke, unternehmensweite Netzwerke, direkte Modem-zu-Modem-Verbindungen usw.
Ein Browser-Programm, welches in der Lage ist ein oder mehrere Fenster ablaufen zu lassen, kann einen einfachen Prozess zur Datenübertragung von Information über das Internet zwischen Computern verwenden, wie in 1 dargestellt ist. Typischerweise öffnet ein unabhängiger Internetnutzer 106 aus einem Pool von beliebigen, unabhängigen Internetnutzern 101–106 ein Browser-Fenster 131 in einem Internet-Browserprogramm, dargestellt durch Pfeil 161. Der Nutzer 106 gibt eine Anfrage einer Internet-Webseite 144 (beispielsweise eine HTML-Seite) ein, die auf das Browserfenster 131, das zum Nutzer 106 gehört, herunter geladen werden soll. Die Anfrage des Nutzer 106 wird vom Browserprogramm verarbeitet und eine Verbindung, dargestellt durch Pfeil 162, wird mit der geeigneten, entfernten Internet-Bezugsquelle 112 hergestellt, typischerweise ein Internet-Webserver, der aus einem Pool beliebiger Internet-Bezugsquellen 110–112 ausgewählt wird. Die entfernte Internet-Bezugsquelle schickt ein HTML-Dokument 143 zurück, dargestellt durch den Pfeil 163. Das HTML-Dokument 143 enthält im Wesentlichen den gesamten Inhalt, der benötigt wird, die vollständige Webseite 144 darzustellen. Die Webseite 144 wird dann dem Nutzer 106 im Browserfenster 131 wiedergegeben, dargestellt durch Pfeil 164.
Ein Modell, das im Stand der Technik als "Ad-Server"-Modell bekannt ist, entwickelt diese einfache Browserprogramm-Methode zur Informationsdatenübertragung über das Internet weiter. Viele Internet-Webseiten sind zusammengesetzte Seiten, die in Form von Bildern, Text und/oder Code Informationen benötigen, die von verschiedenen, entfernten Internetbezugsquellen hinzugezogen werden. Ad-Server werden im Allgemeinen verwendet, um zielgerichtetes, elektronisches Material, wie Bannerwerbung, in solche zusammengesetzte Internet-Webseiten zu integrieren. Daher sind Ad-Server ein Beispiel für eine entfernte Internet-Bezugsquelle, die auf separatem Weg Material für eine zusammengesetzte Webseite beisteuert. Ein Computernetzwerk-Datenübertragungsverfahren, welches einen Ad-Server verwendet ist auch in 1 dargestellt.
Ein unabhängiger Internetnutzer 102 öffnet ein Browserfenster 130 in seinem oder ihrem Internet-Browserprogramm, dargestellt durch den Pfeil 151. Der Nutzer 102 gibt eine Anfrage für eine Internet-Webseite 142 ein, die in das Browserfenster 130 heruntergeladen werden soll. Diese Anfrage wird durch das Browserprogramm verarbeitet und eine Verbindung, dargestellt durch den Pfeil 152, wird mit der entsprechenden entfernten Internet-Bezugsquelle 110, typischerweise einem Internet-Webserver, hergestellt. Die entfernte Internet-Bezugsquelle 110 liefert ein HTML-Rumpfdokument 140 zurück, dargestellt durch den Pfeil 153. Das Rumpfdokument 140 enthält einigen darstellbaren Inhalt und einen zusätzlichen Link zu einem anderen Bild 141, in diesem Fall eine Bannerwerbung, die auf einer separaten, entfernten Internet-Bezugsquelle 120, in diesem Fall einem Ad-Server, abgelegt ist. Das Browser-Programm analysiert das Rumpfdokument 140, um diesen Link zu finden und zum Abruf des Bildes 141 zu nutzen. Das Browserprogramm baut dann eine Verbindung, dargestellt durch den Pfeil 154, mit der entfernten Internet-Bezugsquelle 120 zum Abruf des Bildes 141 auf. Die entfernte Internet-Bezugsquelle 120 liefert das Bild 141 an das Browserprogramm zurück, dargestellt durch den Pfeil 155. Das Bild 141 wird dann mit dem darstellbaren Inhalt des Rumpfdokuments 140 zusammengeführt, um die vollständige Webseite 142 zu bilden. Die Webseite 142 wird dann dem Nutzer 102 im Browserfenster 130 dargestellt, wie durch den Pfeil 156 gezeigt. Es ist zu berücksichtigen, dass dieses Verfahren viele Male für viele separate Bestandteile einer einzelnen Webseite wiederholt werden kann. Tatsächlich enthalten viele Webseiten Links zu Dutzenden separater, entfernter Internetbezugsquellen, wodurch für jeden einzelnen Link dieses Verfahren durchgeführt werden muss.
Viele entfernte Internet-Bzugsquellen ordnen eine spezifische Nutzerkennung, die Statusinformation enthält, bezeichnet als Session-Kennung oder "Cookie", jedem einzelnen Nutzer zu, immer wenn ein Nutzer sich mit der Bezugsquelle verbindet, beispielsweise um eine Internet-Webseite abzurufen. Das Cookie wird im Browserprogramm hinterlegt, welches angewiesen ist, das Cookie bei nachfolgenden Besuchen der Bezugsquelle zu zeigen, so dass die Bezugsquelle den Nutzer identifizieren kann. Das Cookie legt der Bezugsquelle offen, wer der Nutzer ist und welches Dokument oder welches zugehörige Bestandteil der Nutzer haben will. Die Verwendung von diesen Cookies ist unentbehrlich, wenn Bestandteile aus verschiedenen, entfernten Internet-Bezugsquellen zu einer integrierten Webseite zusammengesetzt werden, da eine Bezugsquelle für ein HTML-Rumpfdokument mehrere Besuche oder Datenübertragungen eines Webbrowsers beim Zusammensetzen einer Seite erforderlich machen kann. Ohne solche Cookies würde die Verwendung solcher zusammengesetzten Webseiten wesentlich behindert. Viele Bezugsquellen vergeben zu diesem Zweck temporäre Cookies, die am Ende einer Session oder beim Schließen des Browserprogramms ablaufen. Andere Cookies jedoch werden langfristiger zu Identifikationszwecken über eine Internetsession hinaus vergeben. Bei einem solchen Verwendungszweck werden Nutzer mittels Langzeit- oder Dauercookies aufgrund spezifischer Nutzungsverläufe und Nutzerneigungen identifiziert, so dass Information, beispielsweise inhaltsspezifische Bannerwerbung, die in Bezug steht zu den Nutzungsverläufen und Nutzerneigungen, auf die identifizierten Nutzer zukünftig ausgerichtet werden kann.
Bei Proxy-Systemen sind im Allgemeinen viele individuelle Computer und Computernutzer zu einem einzelnen Netzwerk gruppiert. Dieses Netzwerk wird typischerweise von einem einzelnen Proxy-Server bedient, der die gesamte Datenübertragung zwischen den individuellen Netzwerknutzern und zwischen irgendeinem individuellen Netzwerknutzer und irgendeiner äußeren, entfernten, elektronischen Bezugsquelle oder Nutzer kanalisiert. Ein Proxy-Server kann viele nützliche Aufgaben erfüllen, wie eine schnellere Datenübertragung zwischen Netzwerknutzern, Firewallschutz für alle Netzwerkcomputer und große und effiziente Speicherkapazität. Ein Beispiel für die effiziente Speicherkapazität bei einem Proxy-Server zeigt sich gerade dann, wenn ein Netzwerknutzer eine Webseite von einer entfernten Bezugsquelle anfordert, die vor kurzem von einem anderen Netzwerknutzer aufgerufen wurde. Anstatt die selbe Webseite nochmals von der selben Bezugsquelle anzufordern, kann der Proxy-Server einfach die Webseite, die auf ihm bei der vorherigen Anfrage abgespeichert wurde, zustellen. Es ist zu bedenken, dass, obwohl durch die Verwendung von Proxy-Servern die Wege, über die die Information und Datenübertragung stattfindet, verändert werden, durch eine derartige Verwendung die Basisfunktionen der hiermit beschriebenen Verfahren und Systeme im Wesentlichen nicht verändert werden.
Im Allgemeinen können viele Verfahren verwendet werden, um einen Nutzer beim Ausfüllen eines elektronischen Dokumentenformulars zu assistieren. Ein solches Verfahren wird als "Brieftaschen"-Verfahren bezeichnet, das zum Beispiel mit "eWallet", zu finden unter http://www.ewallet.com, verwirklicht wird. Dieses Verfahren erfordert, dass ein Nutzer eine Softwareapplikation herunterlädt und auf seinem bzw. ihrem Computer installiert. Der Nutzer muss dann persönliche Informationselemente in die Applikation eingeben, die den Nutzernamen, -Adresse und Kreditkartendaten beinhalten, die auf dem Computer des Nutzers für zukünftige Verwendungen gespeichert werden. Dem Nutzer ist daher möglich, diese "eWallet"-Applikation und eingegebenen Informationselemente dazu verwenden, elektronische Dokumentenformulare, die mit der "eWallet"-Applikation in Beziehung stehen, automatisch auszufüllen. Immer wenn der Nutzer wünscht, ein zugehöriges elektronisches Dokumentenformular auszufüllen, öffnet der Nutzer die "eWallet"-Applikation und klickt eine virtuelle Kreditkarte an und zieht diese aus der virtuellen Brieftasche auf das Dokumentenformular. Die "eWallet"-Applikation fügt dann automatisch die eingegebenen persönlichen Informationselemente in das Dokument ein. Der Anklick- und Verschiebeschritt muss für jede Seite der elektronischen Dokumentenvorlage wiederholt werden. Dem Nutzer ist es dann möglich, die Dokumentenvorlage vor dem Versenden zu überprüfen und fertig gestellt freizugeben. Ein Beispiel einer "eWallet"-Anwendung ist in der internationalen Offenlegung mit der Anmeldenummer WO98/04976 veranschaulicht. Bei dem System, das in der WO98/04976 offenbart ist speichert ein im Client residentes Programm, wie ein Plug-In-Modul einer Webbrowserapplikation, persönliche Information auf einem Computer des Nutzers, um bei der Vervollständigung von elektronischen Formularen durch angepasste Feldnamen zu unterstützen.
Ein weiteres Verfahren, welches einen Nutzer beim Ausfüllen eines elektronischen Dokumentenformulars assistiert, wird als "Transactor"-Verfahren bezeichnet; dies ist zum Beispiel bei "Transactor Networks" unter http://www.transactor.net zu finden. Dieses Verfahren unterscheidet sich dahingehend vom Brieftaschenverfahren, dass es für den Nutzer nicht notwendig ist, irgendeine Software herunterzuladen und auf seinem oder ihrem Computer zu installieren. Stattdessen werden persönliche Informationselemente eingegeben und in einer Datenbank auf einem entfernten Server gespeichert, der immer dann kontaktiert wird, wenn ein elektronisches Dokumentenformular auszufüllen ist. Auf diesen entfernten Server, der die persönlichen Informationselemente enthält, wird über ein separates Browserfenster zugegriffen, das sich von dem Browserfenster unterscheidet, das das auszufüllende Dokumentenformular enthält. Dieses Verfahren erfordert somit Datenübertragung zwischen den unabhängigen Browserfenstern.
Ein Verfahren, das zum Ausfüllen eines elektronischen Dokumentenformulars dieses Transactor-Verfahren verwendet, wird in 2 illustriert. Ein unabhängiger Internetnutzer 202 aus einem Pool von beliebigen, unabhängigen Internetnutzern 201–206 öffnet ein Browser-Fenster 230 in seinem oder ihrem Internet-Browserprogramm, wie durch Pfeil 251 dargestellt ist. Der Nutzer 202 gibt eine Anfrage einer Webseite ein, die ein elektronischen Dokumentenformular 240 enthält, das in das Browserfenster 230 herunter geladen werden soll. Die Anfrage wird vom Browserprogramm verarbeitet und eine Verbindung, dargestellt durch Pfeil 252, wird mit der geeigneten, entfernten Internet-Bezugsquelle 210 hergestellt, typischerweise ein Internet-Webserver, der aus einem Pool beliebiger Internet-Bezugsquellen 210-212 ausgewählt wird. Die entfernte Internet-Bezugsquelle liefert ein HTML-Dokument 143, welches das elektronische Dokumentenformular enthält, zurück, was durch den Pfeil 253 dargestellt ist. Dieses Verfahren kann das Auslesen weiterer Bestandteile der Webseite aus verschiedenen entfernten, elektronischen Bezugsquellen beinhalten, wie zuvor anhand des Ad-Server-Modells beschrieben wurde. Der Nutzer 202 öffnet ferner ein separates Browserfenster 231, um das "Transactor"-Verfahren zu aktivieren, typischerweise geschieht dies mittels Lesezeichen. Das Browserprogramm stellt eine Verbindung, dargestellt durch einen Pfeil 255, mit einem Transactor-Server her, um die persönlichen Informationselemente 241 des Nutzers zu erhalten. Der Transactor-Server 220 liefert die persönlichen Informationselemente 241 an das Browserprogramm im Browserfenster 231 zurück, dargestellt durch den Pfeil 256. Es ist anzumerken, dass der Vorgang, der durch die Pfeile 254 und 256 wiedergegeben wird, vor oder nach dem Vorgang, der durch die Pfeile 251 bis 253 repräsentiert wird, beendet sein kann. Sobald beide Vorgänge abgeschlossen sind, initiiert das Fenster 231 die Datenübertragung mit Fenster 230, um das automatische Ausfüllen des elektronischen Dokumentenformulars 240 im Fenster 230 zu beginnen. Die Fenster kommunizieren soweit notwendig, bis das Formular ausgefüllt ist, was durch den Doppelpfeil 257 angedeutet wird. Das ausgefüllte elektronische Dokumentenformular wird dann dem Nutzer 202 im Browserfenster 230 angezeigt, dargestellt durch den Pfeil 258. Der Nutzer 202 kann dann die ausgefüllte Dokumentenvorlage 242 vor dem Absenden überprüfen und bei Vollständigkeit freigeben.
Es gibt aber einige Nachteile bei sowohl dem "Brieftaschen"- als auch dem "Transactor"-Verfahren. Beide Verfahren machen eine maßgebliche Investition von Zeit zu Beginn vom Nutzer erforderlich, um dessen persönliche Informationselemente einzugeben. Das Brieftaschenverfahren erfordert vom Nutzer zusätzlich das Herunterladen und Installieren von Software auf dessen bzw. deren Computer. Dies ist dahingehend problematisch, dass der Nutzer kein Zugang zu diesem Verfahren hat, wenn er oder sie irgendeinen Computer benutzt, der nicht das Brieftaschen-Programm hat und bei dem nicht die persönlichen Informationselemente des Nutzers eingegeben sind. Es ist nicht nur unbequem auf jedem Computer, zu dem der Nutzer Zugang hat, erneut zu installieren und Elemente wieder einzugeben, sondern es ist praktisch unmöglich, dass auf einem Computer, der von einem Nutzer zum ersten Mal verwendet wird, die persönlichen Informationselemente des Nutzers vorhanden sind. Obwohl das Transactor-Verfahren durch eine serverbasierte Datenbank diesen Nachteil des Brieftaschenverfahrens zu überwinden versucht, benötigt es eine übergreifende Datenübertragung zwischen den Fenstern, was im Stand der Technik dafür bekannt ist, die Sicherheit der Nutzerdaten zu gefährden. Zusätzlich verlangsamt der erforderliche Aufruf von Informationen von einer serverseitigen Datenbank während der fensterübergreifenden Datenübertragung signifikant den automatisierten Ausfüllvorgang der elektronischen Dokumentenvorlage.
Somit sind ein Verfahren und ein System für auf fernen Servern basierenden Applikationen erwünscht, um schnell und automatisch elektronische Dokumentenformulare auszufüllen, die dabei dem Nutzer die Last abnehmen Daten in solche Dokumentenformulare manuell eingeben zu müssen und dabei nicht zwingend erfordern, dass Nutzer sich an einem spezifischen Computer befindet und ohne die Sicherheit der Nutzerdaten zu gefährden. Mit anderen Worten ist ein Verfahren und ein System erwünscht, welches einem Computernutzer das automatische Ausfüllen von elektronischen Dokumentenformularen von irgendeinem Computer oder Client aus in einem Netzwerk durch einen einfachen Mausklick ermöglicht. Ferner ist die Fähigkeit erwünscht und inhärent in solch einem Verfahren und System, elektronische Dokumentenvorlagen auszufüllen, ohne dass dazu der Nutzer gezwungen ist, irgendeine Art von permanenter oder residenter Software auf irgendeinen Computer herunter zu laden oder zu installieren.
Zusammenfassung der Erfindung
Gemäß der vorliegenden Erfindung sind Verfahren, Vorrichtungen und Computerprogrammprodukte zum Aufbau und Versenden eines auf einem persönlichen Informationsservers, der als ein Geheimhaltungsbankserver bezeichnet wird, ausführbaren Softwaremoduls an einen entfernten Computer bekannt. Das Softwaremodul ist so aufgebaut, dass sobald es von einem, ein Formular darstellenden Browser empfangen wird, es ausgeführt wird und Nutzerdaten automatisch in das Formular eingefügt werden. Gemäß einem Aspekt der vorliegenden Erfindung wird ein Verfahren zum Aufbau eines versendbaren Softwaremoduls auf einem persönlichen Informationsserver, das geeignet ist zur Durchführung auf einem entfernten Computer, zum Einfügen von Datenstrings in ein elektronisches Formular beschrieben. Es wird ein Formularverzeichnis, welches eine Vielzahl von Zuordnungen zwischen Datenfeldern in dem elektronischen Formular ("Nicht- Standardfelder") und vorbenannten Datenfeldern ("Standardfelder") auf dem persönlichen Informationsserver enthält, ermittelt. Jedes Verzeichnis ist dem elektronischen Formular zugeordnet. Eine Rohdatendatei, welche Datenstrings enthält, wobei jeder Datenstring einem vorbenannten Feld entspricht, wird ermittelt. Jede Rohdatendatei ist einem registrierten Nutzer zugeordnet. Das Formularverzeichnis wird dazu verwendet, einen Datenstring mit dem Feld in dem elektronischen Formular zu verbinden, wo das vorbenannte Feld und das Feld in dem elektronischen Formular zueinander passen oder einander zugeordnet sind.
In einer Ausführungsform wird eine Bestimmungsausführbedingung, die jedem Feld in dem elektronischen Formular zugeordnet ist, mit einer jedem vorbenannten Feld zugeordneten Nutzungsvorzugsbedingung verglichen. Ein Datenstring wird mit dem Feld in dem elektronischen Formular verbunden, wenn die Bestimmungsausführbedingung des Feldes kleiner gleich als die Nutzungsvorzugsbedingung des vorbenannten Feldes ist. Gemäß einer weiteren Ausführungsform wird der Datenstring nicht mit dem Feld in dem elektronischen Formular verbunden, wenn die Bestimmungsausführbedingung des Feldes größer als die Nutzungsvorzugsbedingung des vorbenannten Feldes ist. In noch einer weiteren Ausführungsform wird das Formularverzeichnisses zur Verbindung eines Datenstrings mit dem Feld in dem elektronischen Formular genutzt und beinhaltet die Prüfung einer Vielzahl von Verhandlungsobjekten anhand von Annahme- oder Ablehnungsbenachrichtigungen, wobei sich jedes Verhandlungsobjekt aus dem Vergleich von zu dem Feld in dem elektronischen Formular gehörigen Daten mit zu dem vorbenannten Feld gehörigen Daten ergibt.
Gemäß einem weiteren Aspekt der Erfindung wird ein Server zur Ermöglichung des automatischen Einfügens von Datenstrings in ein elektronisches Formular mit einer Vielzahl von Datenfeldern auf einem fernsteuerbaren Computer, der dazu in der Lage ist, mit dem Server zu kommunizieren, beschrieben. Der Server umfasst einen Speicherbereich zum Speichern einer Vielzahl von Rohdatenprofilen, wobei jedes Rohdatenprofil einem zugehörigen registrierten Nutzer des vertraulichen Bankdienstes entspricht. Ein weiterer Speicherbereich speichert eine Vielzahl von Formularverzeichnissen, wobei jedes Formularverzeichnis einem einzelnen Formular entspricht, das mit dem vertraulichen Bankdienst von einem Händler oder dritten Verkäufer registriert ist. Ein Vergleichsmodul vergleicht oder "verhandelt" Nutzungsvorzugsdaten, die in den Rohdatenprofilen enthalten sind, mit Ausführvorzugsdaten, die in Formularverzeichnissen enthalten sind. Ein Softwaremodulkonstruktor erstellt und übermittelt ein versendbares Programm oder Softwaremodul, das sich zur Ausführung auf einem entfernten Computer eignet, um Datenstrings in ein elektronisches Formular auf dem entfernten Computer einzusetzen.
In einer Ausführungsform beinhaltet das Rohdatenprofil eine Vielzahl von Standardfeldnamen beinhaltet, wobei jeder Standardfeldname einen entsprechenden Datenstring und einen Nutzungsvorzugsdateneintrag, wie von dem zugehörigen registrierten Nutzer festgelegt, aufweist. Auf ähnliche Weise beinhaltet jedes Formularverzeichnis eine Vielzahl von Nicht-Standardfeldnamen aus dem elektronischen Formular, wobei jeder Nicht-Standardfeldname auf einen Standarddateinamen verlagert wird und einen Ausführvorzugsdateneintrag aufweist. Gemäß einer weiteren Ausführungsform enthält ein Verhandlungsverlaufsmodul, Verhandlungsmodule, wobei jedes Verhandlungsmodul eine Angebotskomponente und entweder eine Annahmekomponente oder eine Ablehnungskomponente aufweist.
Kurzbeschreibung der Figuren
Die Erfindung ist besser anhand der nachfolgenden Beschreibung mit Bezug auf die begleitenden Figuren zu verstehen.
1 ist eine schaubildliche Darstellung eines "Ad-Server"-Modells gemäß dem Stand der Technik.
2 ist eine schaubildliche Darstellung eines Transactor-Modells gemäß dem Stand der Technik.
3A ist eine schaubildliche Darstellung eines Systems zum automatischen Befüllen von elektronischen Dokumentenformularen gemäß einer Ausführungsform der vorliegenden Erfindung.
3B ist ein Blockdiagramm, welches die Komponenten eines Servers zeigt, der das automatische Einsetzen von Daten in ein elektronisches Formular auf einem entfernten Computer ermöglicht, gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Flussdiagramm eines Prozesses zum automatischen Befüllen einer elektronischen Dokumentenvorlage gemäß einer Ausführungsform der vorliegenden Erfindung.
5 ist ein Flussdiagramm eines Vorgangs für eine anfängliche Nutzersitzung, die den Dienst zur automatischen, elektronischen Formularfertigstellung gemäß einer Ausführungsform der vorliegenden Erfindung verwendet.
6 ist ein Flussdiagramm eines Vorgangs zur Erstellung und zum Versenden eines versendbaren Codesegments von einem Server an einen Nutzercomputer gemäß einer Ausführungsform der vorliegenden Erfindung.
7 ist ein Flussdiagramm eines Zuordnungsvorgangs, bei dem Formularnamen mit den Rohdatenwerten eines Nutzers gemäß einer Ausführungsform der vorliegenden Erfindung verknüpft werden.
8A, 8B und 8C sind Tabellen, die die Feldnamen und Format der Daten des registrierten Nutzers gemäß einer Ausführungsform der vorliegenden Erfindung zeigen.
9 ist ein Blockdiagramm eines typischen Computersystems, das sich zur Implementierung einer Ausführungsform der vorliegenden Erfindung eignet.
Detaillierte Beschreibung
Nachfolgend wird im Detail auf eine bevorzugte Ausführungsform der Erfindung eingegangen. Ein Beispiel der bevorzugten Ausführungsform ist in den begleitenden Zeichnungen illustriert. Obwohl die Erfindung anhand einer bevorzugten Ausführungsform beschrieben wird, sollte deutlich werden, dass die Erfindung auf eine bevorzugte Ausführungsform zu beschränken ist. Vielmehr ist beabsichtigt, dass Alternativen und Modifikationen in den Bereich der Erfindung fallen können, wie er durch die abhängigen Ansprüche vorgegeben ist.
Ein Verfahren und System zur automatischen Befüllung eines elektronischen Formulars auf eine Computer, das nicht das Herunterladen und Installieren irgendeiner residenter Software auf dem Computer vom Nutzer erfordert, ist in den verschiedenen Figuren beschrieben. Das die Gegenwart von Kaufleuten und Dienstleistungen im Internet zunimmt, wird der elektronische Handel oder e-commerce zunehmen. Mehr und mehr Verbraucher werden auf das Internet zurückgreifen, um zum Beispiel Waren und Dienstleistungen zu kaufen. Dies macht es typischerweise erforderlich, dass Verbraucher/Nutzer wenigstens einige Daten dem Händler zur Verfügung stellen, indem typischerweise ein elektronisches Formular mit verschiedenen Feldern, im Allgemeinen betreffend Namen, Adressen, Kreditkartennummern, Telefonnummern usw., ausgefüllt wird. Das wiederholte, manuelle Ausfüllen dieser Formulare kann für Verbraucher, die Waren von zahlreichen Handelsstellen kaufen und die möglicherweise unterschiedliche Computer verwenden (beispielsweise, die einen Computer auf der Arbeitsstelle, einen weiteren Computer daheim und nach einen weiteren unterwegs verwenden), ermüdend und ineffizient werden. Die vorliegende Erfindung versucht die Last zu lindern, die mit dem Ausfüllen von elektronischen Formularen verbunden ist, während der Verbraucher/Nutzer über Datenschutzmaßnahmen, die von einer spezifischen Handelsstelle ergriffen wurden, informiert wird und vermeidet, dass ein Herunterladen irgendeiner residenter Software erforderlich ist. Dem letzten Merkmal ist inhärent, dass es dem Verbraucher möglich ist, die Vorgänge der vorliegenden Erfindung von irgendeinem Computer, der mit dem Netzwerk, insbesondere dem Internet, verbunden ist, zu nutzen.
Die vorliegende Erfindung nutzt einen entfernten Server oder eine "vertrauliche Bank", eine neuartige elektronische Bezugsquelle, die auf eine Datenabfrage damit reagiert, dass ein spezielles Dokument in Form eines JavaScripts erzeugt und versendet wird. Dieses JavaScript wird von der vertraulichen Bank auf Empfang einer Datenabfrage dynamisch generiert. Das JavaScript, das von der vertraulichen Bank erzeugt wird, ist eine "Profil" oder eine Zuordnung zwischen Feldnamen in einem einzelnen Formular, welches der Nutzer bei einer einzelnen Handelsstelle (beispielsweise unter "www.fishermanstore.com") auszufüllen genötigt ist und standardisierten Feldnamen, die im vertraulichen Bankserver gespeichert sind. Sobald dem Browserprogramm des Nutzers dieses Profil von der vertraulichen Bank übermittelt ist, werden die Felder im Formular von Fishermanstore automatisch befüllt. Bei der beschriebenen Ausführungsform wird er Nutzer Mitglied der vertraulichen Bank-Bezugsquelle, indem er persönliche Informationen, auch als Rohdaten bezeichnet, der vertraulichen Bank einmal zur Verfügung stellt. Diese Rohdaten können von Zeit zu Zeit, falls erwünscht vom Nutzer aktualisiert werden. Bei einer weiteren Ausführungsform kann der Nutzer vertrauliche Regeln oder Erfordernisse einmal, wenn er zu Beginn Mitglied wird, eingeben. Der Nutzer ist nicht dazu gezwungen irgendeine Software von der vertraulichen Bank oder irgendeiner anderen Bezugsquelle herunter zu laden. Bei der beschriebenen Ausführungsform wird der Händler (beispielsweise The Fisherman Store) ein verbundenes Mitglied des vertraulichen Banknetzwerks, indem er ein Beispieldokument seines Formulars oder seiner Formulare zur Verfügung stellt. Die vertrauliche Bank kann dann eine Zuordnung zwischen den Feldern in dem Formular des Händlers und den standardisierten Feldern seiner eigenen Datenbank erstellen. Diese Vorgänge, Bestandteile und zugehörigen Datengrundelemente sind in den verschiedenen Figuren nachfolgend beschrieben.
3A ist ein Blockdiagramm eines Systems zum automatischen Befüllen von elektronischen Dokumentenformularen gemäß einer Ausführungsform der vorliegenden Erfindung. Eine Anzahl Endnutzer-Computer sind auf der rechten Seite des Diagramms dargestellt. Diese Computer können Client-Computer in einem Netzwerk mit Zugang zum Internet oder Teil eines Intranets sein. Bei der beschriebenen Ausführungsform ist ein Endnutzer-Computer 302 ein autonomer Computer mit Zugang zum Internet und beinhaltet ein Internet-Browserprogramm, dessen Browserfenster durch 304 dargestellt ist. Im Zentrum des Diagramms gibt es eine Anzahl von Web-Servern. Ein einzelner Webserver 306 ist ein Server für eine Handelsinternetpräsenz, wie www.fishermanstore.com, die Nutzer oder Verbraucher besuchen können, um Waren online über das Internet zu kaufen. Auf der linken Seite des Diagramms befindet sich eine spezialisierte elektronische Bezugsquelle, in der beschriebenen Ausführungsform als ein vertraulicher Bankserver-Computer 308 bezeichnet und die ebenso mit dem Internet verbunden ist.
Der Vorgang des automatischen Vervollständigens des elektronischen Formulars beginnt damit, dass ein Nutzer das Formular von einer Internetpräsenz, wie der Internetpräsenz von Fishermanstore, herunterlädt. Der Vorgang des Mitgliedswerdens eines Nutzers und des Einloggens im vertraulichen Bankserver ist detaillierter in 5 beschrieben. Nachfolgend wird auf die 3A zurückgegangen. Ein Nutzer/Verbraucher am Computer 302 ("Nutzer 302") öffnet ein Browserfenster 304 in einem Internetbrowserprogramm, wie dem Netscape Navigator oder dem Internet Explorer, dargestellt durch den Pfeil 310. Der Nutzer 302 besucht mit dem Browser www.fishermanstore.com, wie mit dem Pfeil 312 gezeigt und beschließt Waren zu kaufen. Der Nutzer 302 lädt dann von der Internetpräsenz, die im Webserver 306 enthalten ist, ein elektronisches Verkaufsformular herunter, das die Ausfüllung erfordert, wie mit Pfeil 314 dargestellt ist. Ein Verkaufsformular 316, typischerweise ein HTML-Dokument, wird zurückgeliefert und ins Browserfenster 304 geladen und darin angezeigt. An dieser Stelle, hätte der Nutzer 302 normalerweise jedes Feld des Verkaufsformulars 316 manuell auszufüllen. Die meiste Information betrifft typischerweise: Name, Anschrift, Telefonnummer, Zahlungsverfahren, Email-Adresse des Nutzers usw. Gemäß einer Ausführungsform der vorliegenden Erfindung kann der Nutzer 302 auf ein Symbol der vertraulichen Bank oder einen Knopf im Formular 316 klicken und das Formular automatisch ausfüllen lassen.
Wie zuvor angemerkt, wird in dieser Beschreibung angenommen, dass www.fishermanstore.com beim vertraulichen Bankdienst, der über den vertraulichen Bankserver 308 zugänglich ist, registriert ist und damit ein zughöriges Mitglied ist. Bei Mitgliedschaft des vertraulichen Bankdienstes umfasst das Kaufformular 316 ein vertrauliches Banksymbol oder -Knopf 318. Durch Anklicken des vertraulichen Banksymbols 318 schließt der Nutzer 302 im Wesentlichen einen Vorgang zum automatischen Befüllen des Formulars 316 ab, indem transparent ein vervollständigtes Formular an den vertraulichen Bankdienst auf dem Server 308 versendet wird, wie mit Pfeil 320 angedeutet ist. Die Information, die zum Ausfüllen des Formulars benötigt wird, wird an den Nutzer 302 versendet, sobald das Formular 316 (ein HTML-Dokument) analysiert ist, was dann geschieht, wenn das Formular 316 herunter geladen wird. Dieser Vorgang wird detaillierter in 4 beschrieben. Der Nutzer 302 informiert den vertraulichen Bankserver 308 über die Identität des Nutzers und von welcher Internetpräsenz und welches Formular auf der Internetpräsenz (falls mehr als eins vorhanden ist) der Nutzer auszufüllen wünscht. Diese Information wird an den vertraulichen Bankserver 308, unbekannt dem Nutzer 302, gesendet, wenn das Formular 316 herunter geladen ist. Techniken, um dies zu erreichen, sind nachfolgend beschrieben. Sobald der vertrauliche Bankserver 308 eine Anfrage vom registrierten Nutzer 302 (aufgrund eines externen Links im Formular 316, der ausgeführt wird, wenn das Formular durch den Nutzer 302 analysiert wird) empfängt, beginnt er die Information zu generieren, die benötigt werden das Formular 316 auf dem Computer des Nutzers 302 auszufüllen. Ein Vorgang zur Generierung der Information, die an den Computer des Nutzers 302 und den Browser 304 zurückgesandt wird und mit dem Pfeil 322 dargestellt ist, ist detaillierter in den 6 und 7 beschrieben. Bei der beschriebenen Ausführungsform ist die Information, die an den Computer des Nutzers 302 gesandt wird ein JavaScript-Programm 324, das als "Profil" bezeichnet wird. Kurz erklärt enthält dieses Profil eine Zuordnung von vertraulichen, standardisierten Bankfeldern und Feldern des Kaufformulars 316 und "Roh-", im Allgemeinen persönliche Daten, die mit dem Nutzer 302 zusammenhängen. Der Inhalt dieses Profils und des JavaScript-Programms im Allgemeinen ist detaillierter in den 7A und 7B nachfolgend beschrieben. Sobald das ausgefüllte Kaufformular 316 auf dem Computer des Nutzers 302 durch das Browserprogramm empfangen ist, wird es dem Nutzer 302 dargestellt, wie der Pfeil 326 zeigt. Dies tritt ein, wenn der Nutzer 302 auf das Symbol der vertraulichen Bank 318 drückt oder dieses anklickt. Die Information, die zur Vervollständigung des Formulars 316 benötigt wird, befindet sich bereits resident im Browserprogramm. An dieser Stelle, kann der Nutzer 302 entscheiden, ob er mit der Übermittlung des Formulars fortführen will (typischerweise nachdem er einige weitere Felder ausgefüllt hat, wie die Teile, die er zu kaufen beabsichtigt und die Anzahl usw.) oder ob er die Übermittlung des Formulars unterlässt, vielleicht nachdem er die Datensicherheitsbestimmungen der Internetpräsenz von Fishermanstore überprüft aus oder aus einem anderen Grund.
3B ist ein Blockdiagramm, welches Komponenten eines vertraulichen Bankservers zeigt, der die automatische Befüllung von elektronischen Formularen auf einem entfernten Nutzercomputer ermöglicht. Ein vertraulicher Bankserver, wie der Server 308 in 3A enthält einige Betriebs- und Speicherkomponenten, die zur Compilierung der Daten, die zur Befüllung eines Formulars, wie dem Formular 316 gebraucht werden, benötigt werden. In 3B sind vier Hauptkomponenten eines vertraulichen Bankservers in der beschriebenen Ausführungsform gezeigt. Diese Komponenten und Speicherbereiche umfassen einen Speicherbereich für Rohdatenprofil 328, einen Speicherbereich für Formularzuordnungen 330, ein Verhandlungsverlaufmodul 332 und einen Konstruktor für den versendbaren Code 334. Der Speicherbereich für Rohdatenprofile 328 enthält Datensätze, die in Zusammenhang stehen mit registrierten Nutzern des vertraulichen Bankdienstes, ein Satz oder Profil ist im Bereich 336 gezeigt. Ein registrierter Nutzer hat eine eindeutige Benutzerkontonummer, die als Kennung und als ein Passwort verwendet werden kann, wie in einem Bereich 338 gezeigt ist. Die Standardfeldnamen, die vom vertraulichen Bankdienst vorgegeben sind, die detaillierter in den 8A, 8B, 8C, 8D und 8E beschrieben werden, werden mit einem vom Nutzer eingegebenen Datenstring (wie der Rufnamen oder der Straßenname der Heimatadresse) gepaart, gefolgt von einer Nutzungsvorzugsbedingung. Die Nutzungsvorzugsbedingung wird im Verhandlungsverlaufsmodul 332 verwendet und ist detaillierter in 7 nachfolgend beschrieben. Diese Daten sind im Bereich 340 enthalten. Ein anderes Profil für einen anderen registrierten Nutzer ist in einem Bereich 342 gezeigt. Jeder registrierte Nutzer hat ein ähnliches Rohdatenprofil.
Der Formularzuordnungsbereich 330 beinhaltet mehrfache Formularzuordnungen, ein Beispiel hierzu ist in einem Bereich 344 gezeigt. Jedes elektronische Formular, das beim vertraulichen Bankdienst durch einen Onlinehändler oder -Verkäufer (d. h. einem zugehörigen Mitglied) registriert wurde, hat eine Formularzuordnung. Ein Standardfeldname der vertraulichen Bank, wie nachfolgend in den 8A, 8B, 8C, 8D und 8E beschrieben wird und wie zuvor erwähnt, im Bereich 340 ist auf einen "Nicht-Standard"-Feldnamen des elektronischen Formulars, das beim Dienst registriert ist, angepasst oder zugeordnet. Zum Beispiel kann ein Nicht-Standard-Feldname für den Nachnamen einer Person könnte "Nachname", "Zuname" oder einfach "Nachn." sein. Verschiedene Formulare verwenden unterschiedliche Variationen der Namen für dieses Feld und für andere Felder. Diese würde dem "Standard"-Feldnamen der vertraulichen Bank zugeordnet, der bei der beschriebenen Ausführungsform "PersonName.Last" ist. Eine Nutzungsvorzugsbedingung ist ebenso im Bereich 346 enthalten, die vom Onlinehändler oder Verkäufer bei der Registrierung de Formulars zur Verfügung gestellt wird. So wie die Nutzungsvorzugsbedingung im Bereich 340 wird diese Bedingung beim Verhandlungsverlaufmodul 350 und beim versendbaren Codekonstruktor 334 verwendet und wird detaillierter in 7 nachfolgend beschrieben. Eine andere Zuordnung 348 mit dem selben Format für ein anderes Formular folgt dem Bereich 344.
Das Verhandlungsverlaufmodul 332 wird zur Bestimmung verwendet, welche Felder im elektronischen Formular automatisch durch den vertraulichen Bankserver ausgefüllt werden. Ein Vorgang, der mit dem Verhandlungsverlaufmodul 332 verbunden ist, wird detaillierter in 7 beschrieben. Das Modul 332 beinhaltet mehrfache Verhandlungsobjekte, ein Beispiel hierzu ist in einem Bereich 350 dargestellt. Bei der beschriebenen Ausführungsform korrespondiert jedes Verhandlungsobjekt mit einem "Nicht-Standard"-Feld im Formular. Kurz erklärt, enthält das Verhandlungsobjekt 350 insoweit Information, ob das Feld im Formular basierend auf Vertraulichkeits- und Nutzungsvorzügen, die vom Nutzer vorgegeben sind, ausgefüllt werden soll (wie in der Nutzungsvorzugsbedingung im Bereich 340 ausgedrückt ist) und mit den beabsichtigten Ausführungen verglichen (wie in der Ausführungsvorzugsbedingung im Bereich 346 ausgedrückt ist). Dieser Vergleich wird im Verhandlungsverlaufmodul durchgeführt, welches einen Vermittler oder Komparator zum Vergleich dieser Bedingungen beinhaltet. Spezifische Bedingungen bei der beschriebenen Ausführungsform sind nachfolgend beschrieben. Wenn bestimmt ist, dass das Nicht-Standardfeld im Formular befüllt werden soll, wird ein Datenstring, dargestellt im Bereich 340 im Verhandlungsobjekt 350 aufgenommen. Der versendbare Codekonstruktor 334 greift auf die Komponente 332 und die Speicherbereiche 328 und 330 zu, um ein Softwaremodul zu erlangen, das an einen Nutzercomputer zu senden ist. Bei der beschriebenen Ausführungsform ist das Softwaremodul ein JavaScript-Programm, welches an einen Browser auf dem Nutzercomputer versendet wird und von diesem ausgeführt wird und dabei die Datenstrings in die Formularfelder eingesetzt werden.
Die 4A und 4B zeigen ein Flussdiagramm eines Vorgangs zum automatischen Befüllen von elektronischen Formularen in einem Computernetzwerk gemäß einer Ausführungsform der vorliegenden Erfindung. Der Vorgang, der nachfolgend beschrieben wird, kann in einer Anordnung von Servern und Computern, wie zuvor anhand 3A beschrieben, durchgeführt werden. In einem Schritt 402, der in 4A gezeigt ist, lädt ein Online-Nutzer/Verbraucher, der bestimmte Waren auf dem Internet zu kaufen wünscht, ein elektronisches Formular herunter, um einen Kauf im Browserprogramm des Nutzers zu tätigen. Im Schritt 404 analysiert der Browser den Inhalt des elektronischen Formulars, typischerweise ein HTML-Dokument, um alle externen Links zu identifizieren. Wie es üblich auf Webseiten ist, enthält HTML Links auf andere externe Internetpräsenzen von denen Inhalt oder andere Arten von Daten abgerufen werden. In vielen Fällen ist eine Webseite ein Verbund aus verschiedenen Komponenten von verschiedenen Internetpräsenzen, die in einem Rumpf-HTML-Dokument eingebettet sind. Ein Beispiel ist ein externer Link auf einen Ad-Server, um ein Bannerwerbungsbestandteil eines Rumpf-HTML-Dokuments abzufragen. In diesem Fall kann das elektronische Formular als ein Rumpf-HTML-Dokument angesehen werden. Dieses Analysieren erfolgt automatisch durch den Browser und ist ein gut bekanntes Merkmal.
Im Schritt 406 identifiziert der Browser einen externen Link auf den vertraulichen Bankserver. Bei der beschriebenen Ausführungsform ist dieser Link notwendigerweise vorhanden, das die Internetpräsenz eine zugehörige Präsenz des Netzwerks aus registrierten Präsenzen des vertraulichen Bankdienstes ist. Eine Beschreibung dessen, was in diesem Zusammenhang von "registriert" umfasst ist, ist detaillierter nachfolgend beschrieben. Im Schritt 408 führt der Browser den externen Link aus, um den Browser mit dem vertraulichen Bankserver zu verbinden. Der externe Link wird bei der beschriebenen Ausführungsform als ein versendbarer Codelink zum vertraulichen Bankserver bezeichnet. Der versendbare Code ist in diesem Kontext ein JavaScript-Programm, das vom vertraulichen Bankserver an den Computer und Browser des Nutzers versendet wird. Dieser versendbare Code ermöglicht die automatische Befüllung des elektronischen Formulars in einem Vorgang, der nachfolgend detaillierter beschrieben wird. Im Schritt 410 sobald der vertrauliche Bankserver mittels des versendbaren Codelinks im elektronischen Formular kontaktiert wurde, ermittelt der vertrauliche Bankserver, ob der Computer oder Browser des Nutzers einen gültige Zustandskennung, als "Cookie" bezeichnet, hat, die ihm zuvor durch den vertraulichen Bankserver vergeben wurde. Ein Cookie ist eine Kennung, die durch eine Internetpräsenz, sei es von einem Internetserver oder einem Server wie dem vertraulichen Bankserver, an einen Nutzer/Besucher vergeben wird, wenn der Nutzer die Internetpräsenz zum ersten Mal in einer vorgegebenen Sitzung (der Zeitablauf zwischen dem Zeitpunkt zu dem ein Nutzer sich ins Internet einloggt und dem Zeitpunkt zu dem er oder sie das Internet durch Schließen des Browsers verlässt). Das Cookie, das durch eine Internetpräsenz vergeben wird, gehört zu eine einzelnen Nutzer. In der beschriebenen Ausführungsform behält der Nutzer dieses Cookie während seiner Sitzung (ein temporäres Cookie) und falls der Nutzer zur Internetpräsenz während jener Sitzung zurückkehrt, wird der Internetpräsenz das Cookie angezeigt, mittels dem die Internetpräsenz den Nutzer identifizieren kann und Charakteristiken dieses Nutzers aus seiner Datenaufbewahrung hinzuziehen kann. Wie im Stand der Technik zur Programmierung von Internetapplikationen bekannt ist, kann das Cookie auch permanente Gültigkeit haben, indem es mit dem Nutzer fortdauert nachdem den Browser ausgeloggt hat und es kann in einer neuen Sitzung weiterverwendet werden. Das Konzept und die Implementierung von Cookies an sich sind auf dem Gebiet des Internets und allgemeiner auf dem Gebiet der Computernetzwerkprogrammierung wohl bekannt.
Falls der vertrauliche Bankserver ermittelt, dass der Computer oder Browser des Nutzers kein gültiges Cookie hat, impliziert dies, dass sich der Nutzer bis dahin noch nicht in den vertraulichen Bankdienst eingeloggt hat. In diesem Fall setzt sich die Steuerung mit Schritt 412 fort, indem der vertrauliche Bankserver einen Einloggsequenzcode abruft. Dieser Code löst eine Einloggsequenz aus und ermöglicht es dem Nutzer sich während eines späteren Schrittes des Vorgangs in den vertraulichen Bankdienst einzuloggen oder dort zu registrieren, wie nachfolgend detaillierter beschrieben wird. Im Schritt 414 bildet der vertrauliche Bankserver ein vervollständigtes Paket des versendbaren Codes, der den abgerufenen Einloggsequenzcode beinhaltet, so dass die Einloggsequenz in einem späteren Schritt des Vorgangs ausgelöst wird. Im Schritt 422 ruft der Browser das vervollständigte Paket aus dem versendbaren Code vom vertraulichen Bankserver ab. Der versendbare Code wird dann im Browser, der sich auf dem Computer des Nutzers befindet, gespeichert und wird bei Auslösung durch den Nutzer ausgeführt, was detaillierter nachfolgend beschrieben wird.
Wenn der vertrauliche Bankserver feststellt, dass der Nutzer/Browser, der durch Herunterladen des elektronischen Formulars die Verbindung herstellt und den externen Link ausführt, ein gültiges Cookie hat, geht die Steuerung über zu Schritt 416, bei dem der vertrauliche Bankserver das Cookie des Nutzers erhält und ausliest. In diesem Zusammenhang zeigt der Besitz eines gültigen Cookies an, dass der Nutzer sich bereits einer Einloggsequenz vor kurzem unterzogen hat, beispielsweise während einer existierenden Internetsitzung und somit ist es für den Nutzer nicht erforderlich, nochmals die Einloggsequenz durchzugehen. Durch Auslesen des Cookies des Nutzers kann der vertrauliche Bankserver ermitteln, wer der Nutzer ist und kann somit die Rohdaten des Nutzers abrufen, die von der vertraulichen Bank gespeichert sind. Der Inhalt und das Format dieser vertraulichen Rohdaten ist detaillierter in den 8A, 8B, 8C, 8D und 8E nachfolgend beschrieben. Beim Schritt 418 ruft der vertrauliche Bankserver die Daten des Nutzers ab, den durch das gültige Cookie abgerufen hat. Der vertrauliche Bankserver bringt die Nutzerdaten und eine Kennung, wie eine URL (uniform resource locator), zusammen, um festzulegen wie ein elektronisches Dokumentenformular gefüllt werden soll. Im Schritt 420 erzeugt der vertrauliche Bankserver ein vervollständigtes Paket des versendbaren Codes (Element 324 in 3A), das die Nutzerdaten enthält, die zur Befüllung des Dokuments verwendet werden. In der beschriebenen Ausführungsform liegt der versendbare Code, als Profil bezeichnet, in Form eines JavaScript-Programms vor. Dieser versendbare Code wird aus Informationen im Speicher der vertraulichen Bank ermittelt, die es ermöglichen, dass das Dokumentenformular automatisch in einem späteren Schritt des Vorgangs ausgefüllt werden kann. Im Schritt 422 empfängt der Browser den versendbaren Code oder das Profil vom vertraulichen Bankserver und hat dann Zugang zu diesem vom Computer des Nutzers, falls der Nutzer dies wünscht. Dieses Profil wird im Browser gespeichert, der auf dem Computer des Nutzers läuft und ist aufgrund einer Auslösung des Nutzers ausführbar.
Vorausgesetzt, der Nutzer wünscht die automatische Befüllung des elektronischen Formulars, löst er oder sie dies mittels einer Auslösung des Nutzers aus. Bei der beschriebenen Ausführungsform kommt die Auslösung zustande, wenn der Nutzer einen "Autofüll"-Knopf, der im Formular enthalten ist und der mit der vertraulichen Bank in Zusammenhang steht, in Schritt 424 anklickt. Durch Anklicken des Autofüllknopfs, gestattet der Nutzer dem Browser die Ausführung des versendbaren Codes oder Profils, das dort gespeichert ist. Im Schritt 426, der in 4B gezeigt ist, bestimmt der versendbare Code ob er Nutzerdaten enthält, die ein Ausfüllen des Dokumentenformulars erlauben. Falls Nutzerdaten im versendbaren Code enthalten sind, der auf dem Browser vorhanden ist, geht die Steuerung über zu Schritt 434, bei dem der Browser den versendbaren Code und die Nutzerdaten dazu nutzt, um das elektronische Dokumentenformular auszufüllen. Natürlich ist das Vorhandensein der Nutzerdaten im versendbaren Code davon abhängig, ob der Browser ein vorexistierendes gültiges Cookie hat, wenn das Dokumentenformular anfänglich empfangen wird, wie zuvor beschrieben ist.
Wenn jedoch keine Daten im versendbaren Code enthalten sind, der sich im Browser befindet, geht die Steuerung über zu Schritt 428, bei dem die Einloggsequenz initiiert wird, um den gegenwärtig unbekannten Nutzer zu identifizieren. Der versendbare Code, der in diesem Schritt vom Browser verwendet wird, enthält den Einloggsequenzcode, was ein Ergebnis dessen ist, dass der Browser kein vorexistierendes, gültiges Cookie hat, als das Dokumentformular anfänglich empfangen wurde, wie zuvor beschrieben wurde. Der Einloggvorgang des Schrittes 428 ist detaillierter in Teilen der 5 beschrieben. Sobald der Nutzer die Einloggsequenz im Schritt 428 vervollständigt, teilt der vertrauliche Bankserver dem Nutzer/Browser ein Cookie zu und ermöglicht sich somit die Möglichkeit, den Nutzer und Mitteilungen des Browsers des Nutzers in nachfolgenden Transaktionen wieder zu erkennen. Im Schritt 430 ruft der vertrauliche Bankserver Nutzerdaten des identifizierten Nutzers ab, verbindet diese Nutzerdaten und eine Kennung, wie eine URL (uniform resource locator), um zu bestimmen, wie das elektronische Dokumentenformular ausgefüllt werden soll und bildet ein vervollständigtes Paket des versendbaren Codes, welches die Nutzerdaten enthält, die dazu verwendet werden, das Dokumentenformular zu befüllen.
Dieser Schritt ist im Wesentlichen ähnlich den Schritten 418 und 420, wie zuvor beschrieben wurde. Im Schritt 430 empfängt der Browser den versendbaren Code oder das Profil vom vertraulichen Bankserver und hat nun dazu Zugang vom Nutzercomputer. Dieser versendbare Code enthält nun Nutzerdaten, die die automatische Befüllung des Dokumentenformulars ermöglichen. In diesem Zustand wird die Steuerung mit Schritt 434 fortgesetzt, in dem der Browser den versendbaren Code und die Nutzerdaten dazu nutzt, das elektronische Dokumentenformular automatisch auszufüllen. Weitere Eingaben seitens des Nutzers, wie ein zusätzliches Anklicken des "Autofüll"-Knopfs ist nicht erforderlich. Anders ausgedrückt, sobald die Einloggsequenz vom Nutzer sorgfältig abgeschlossen wurde, wird dann das Formular automatisch ausgefüllt und es ist für den Nutzer nicht notwendig den "Autofüll"-Knopf ein weiteres Mal anzuklicken.
Im Schritt 426 überprüft der Nutzer das ausgefüllte Formular und die vertraulichen Merkmale, die von der Internetpräsenz angeboten werden, visuell und entscheidet, ob das Formular akzeptabel ist. Wenn der Nutzer der Meinung ist, dass das Formular weiterer Anpassungen bedarf, passt der Nutzer das Dokument in Schritt 438 an. Dies kann manuell erfolgen und durch einen ergänzenden, automatisierten Vorgang, wie ein client-basiertes Makro. Dies kann das Ausfüllen von Feldern umfassen, die nicht durch das Profil, das vom vertraulichen Bankserver übermittelt wurde, befüllt werden konnten (mit anderen Worten: Felder, die nicht aus dem Rohdaten befüllt werden konnten). Solche Felder können beispielsweise Angaben, betreffend die Gegenstände, die gekauft werden, und deren Menge, beinhalten. Ebenso kann aktualisierte persönliche Information, wie eine neue Adresse oder Kreditkartennummer, betroffen sein. In diesem Fall überschreibt der Nutzer einfach, die in den Feldern bereits vorhandene Information. Die Steuerung kehrt dann zu Schritt 436 zurück, was vermutlich ausreicht, wenn einmal durch den Schritt 438 durchgegangen wurde. Im Schritt 440, übermittelt der Browser das ausgefüllte, elektronische Formular, das schließlich an den Internetserver des Händlers gesendet wird, sobald der Nutzer auf einen Formular-Versendungsknopf im Browserfenster klickt. Bei der beschriebenen Ausführungsform wird das ausgefüllte Formular zuerst zum vertraulichen Bankserver auf dem Nutzer unbekannten oder wenigstens transparenten Wege gesendet. Das vervollständigte Formular wird empfangen und vom vertraulichen Bankserver überprüft, der seien Rohdatenbestand aktualisiert, um Änderungen an der persönlichen Information, die der Nutzer vorgenommen haben könnte, zu berücksichtigen. Der vertrauliche Bankserver schickt eine Nachricht zurück an den Nutzercomputer (gemäß dem http Protokoll muss der Server eine Nachricht zurück an den Nutzercomputer schicken, wenn er von diesem ein HTML-Dokument erhält). Bei der beschriebenen Ausführungsform ist die Nachricht, die er zurücksendet oder an den Browser des Nutzers verschickt ähnlich einer "Klicken Sie hier, um fortzufahren"-Typ Meldung an den Nutzer. Hinter dieser Nachricht versteckt sich das vervollständigte Formular, das an den vertraulichen Bankserver versendet wurde. Wahrscheinlich wird der Nutzer klicken, um fortzuführen und indem er so vorgeht, übermittelt er das versteckte, vervollständigte Formular an den Internetserver des Händlers. Bei anderen bevorzugten Ausführungsformen wird das vervollständigte Formular sowohl an den vertraulichen Bankserver als auch an den Internetserver des Händlers zugleich versendet. In noch einer anderen, bevorzugten Ausführungsform wird das vervollständigte Formular automatisch vom vertraulichen Bankserver unmittelbar an die Internetpräsenz des Händlers versendet ohne zusätzliche Eingabe des Nutzers. In diesem Stadium ist der automatische Befüllungsvorgang abgeschlossen.
5 ist ein Flussdiagramm eines Vorgangs bei dem neue Nutzer dem vertraulichen Bankdienst zugeführt werden oder bei dem sich vorhandene Mitglieder einloggen, und es ihnen dadurch ermöglicht wird den Dienst gemäß einer Ausführungsform der vorliegenden Erfindung zu nutzen. Teile in 5 zeigen den Schritt aus 4 mit mehr Details, wobei die Einloggsequenz zur Identifizierung des Nutzers initialisiert wird. Sobald der vertrauliche Bankserver ermittelt, dass der Nutzer kein gültiges Cookie aufweist, fügt der Server einen Einloggvorgang für den Nutzer dem versendbaren Code bei, wobei ein Benutzerkonto angelegt werden kann, wenn der Nutzer nicht bereits eins hat. Dies erfolgt, da im Falle, dass dem Nutzer von der vertraulichen Bank für die laufende Sitzung des Nutzers noch kein Cookie zugeteilt wurde, angenommen wird, dass er oder sie sich noch nicht in den vertraulichen Bankdienst eingeloggt hat oder möglicherweise kein registriertes Mitglied ist. Das erste Ereignis, das bei der Einloggsequenz eintritt, ist, dass der vertrauliche Bankserver eine Einloggmaske im Fenster des Browsers des Nutzers anzeigt, wie in Schritt 502 angedeutet. In Schritt 504 entscheidet der Nutzer, ob er oder sie ein Mitglied der vertraulichen Bank ist und führt damit fort, dass er oder sie den geeigneten Abschnitt der Einloggmaske verwendet. Ein Abschnitt der Einloggmaske benötigt die Eingabe des Nutzerkennung und des Passworts für ein existierendes Konto vom Nutzer, wohingegen ein weiterer Abschnitt es dem Nutzer ermöglicht ein Symbol zu wählen, das die Sitzung weiter zu einer Maske zur Kontoerzeugung führt.
Zur Kontoerzeugung wählt der Nutzer bei der beschriebenen Ausführungsform ein "Neues Konto"-Symbol auf der Einloggmaske aus, wie veranschaulicht mit Schritt 506. Im Schritt 508 wird eine Maske zur Kontoerzeugung bei der vertraulichen Bank angezeigt. In Schritt 510 gibt der Nutzer seine oder ihre Nutzerkennung, ein Passwort, Name, andere Information und Hochvertraulichkeitsbevorzugungen in der Maske zur Kontoerzeugung ein. Im Wesentlichen konfiguriert der Nutzer das Konto und die persönlichen Informationselemente, die für ihn oder sie im vertraulichen Bankbestand gespeichert werden. Die Information, die in das neu geschaffene Konto eingegeben wird, wird dann zurück an den vertraulichen Bankserver geschickt, wie im Schritt 512 angedeutet. Im Schritt 514 nimmt der vertrauliche Bankserver die neue Konteninformation an und ordnet dem neuen Nutzer im Datenbestand der vertraulichen Bank eine Speicherstelle zu. Die frisch eingegebene Information wird dann in dieser Speicherstelle abgelegt. Der vertrauliche Bankserver vergibt ein Cookie für die laufende Nutzersitzung, wie in Schritt 522 angedeutet, und der Vorgang endet.
Beim Einloggen existierender Nutzer in der beschriebenen Ausführungsform gibt der Nutzer seine oder ihre vorhandene Kennung und Passwort ein, wie in Schritt 516 angedeutet. Im Schritt 518 wird diese Einlogginformation zurück an den vertraulichen Bankserver geschickt, der dann mit der Auswertung dieser Information fortführt. Im Schritt 520 bestimmt der vertrauliche Bankserver, ob die geschickte Information korrekt ist, d. h. ob sie oder ob sie nicht mit einer gültigen Nutzeridentifizierung mit richtigem Passwort entspricht. Wenn die geschickte Information nicht mit einer gültigen Nutzeridentifikation und Passwort übereinstimmt, dann schlägt das beabsichtigte Einloggen fehl und der Vorgang kehrt zu Schritt 502 zurück, wo eine neue Einlogg-Maske angezeigt wird. Ist die geschickte Information richtig, dann ist das Einloggen erfolgreich und der Vorgang setzt sich in Schritt 522 fort. Der vertrauliche Bankserver vergibt dann ein Cookie für die laufende Sitzung des Nutzers, wie in Schritt 522 dargestellt ist, und der Vorgang endet.
6 ist ein Flussdiagramm eines Vorgangs zum Herleiten der Teile, die beim Erstellen des versendbaren Codesegments oder Profils, das an den Nutzer verschickt wird, gemäß einer Ausführungsform der vorliegenden Erfindung benötigt werden. Es wird ein Vorgang bis zum Schritt 416 in 4 detaillierter beschrieben, bei dem der Browser den versendbaren Code, der von der vertraulichen Bank verschickt wurde, empfängt. Es wird daran erinnert, dass der Nutzerbrowser das elektronische Formular darauf analysiert, irgendwelche Links auf externe Bezugsquellen zu identifizieren und dann aufzurufen, um externe Komponenten für das HTML-Rumpfdokument zu erhalten. Im Falle des vertraulichen Bankservers (vorausgesetzt, dass die Händler-Internetpräsenz, von der das elektronische Formular heruntergeladen wird, ein zugehöriges Mitglied der vertraulichen Bank ist) empfängt der Server und beginnt die Vorgänge entsprechend dem Link vom Nutzer durchzuführen. In Schritt 602 empfängt der Nutzer zwei Elemente: das Nutzer-Cookie und die Kennung des Formulars, das der Nutzer auszufüllen beabsichtigt. Das Nutzer-Cookie (das dem Nutzer durch den vertraulichen Bankserver zugeteilt wurde, als sich der Nutzer beim Dienst einloggte) informiert den vertraulichen Bankserver von der Identität des Nutzers. Die Kennung des elektronischen Formulars enthält eine Kennung der Händler-Internetpräsenz und des spezifischen Formulars auf der Präsenz, das vom Nutzer heruntergeladen wurde, auch in Gestalt einer URL bei der beschriebenen Ausführungsform. In vielen Fällen kann es lediglich nur ein Formular auf der Internetpräsenz geben.
Im Schritt 604 verwendet der vertrauliche Bankserver das Nutzer-Cookie dazu, die Rohdaten des Nutzers aus dem vertraulichen Bankspeicher abzurufen. Die Aufmachung und der Inhalt der Rohdaten sind detaillierter in den 8A, 8B, 8C, 8D und 8E nachfolgend beschrieben. Die Rohdaten sind eine Anordnung von Datenelementen, die voraussichtlich zur Ausfüllung von gewöhnlichen elektronischen Verkaufsformularen benötigt werden. Wie nachfolgend detaillierter beschrieben wird, korrespondiert jedes Rohdatenelement mit einer spezifischen Standardbezeichnung oder -Namen der vertraulichen Bank. In Schritt 606 verwendet der vertrauliche Bankserver die URL oder eine andere Kennung des spezifischen, auszufüllenden Formulars, um eine Zuordnung zwischen jedem Feldnamen in den elektronischen Formularen (d. h. die Ursprungsnamen) zu den standardisierten Namen der vertraulichen Bank abzurufen. Diese Zuordnung oder dieses Feldnamenabstimmen wird dann durchgeführt, wenn ein Händler ein zugehöriges Mitglied des vertraulichen Bankdienstes wird. Zu diesem Zeitpunkt übermittelt der Händler ein oder mehrere Formulare an die vertrauliche Bank, die dann jeden Feldnamen in den Formularen beurteilt und dann einem Feldnamen der vertraulichen Bank zuordnet. Falls bei der beschriebenen Ausführungsform ein Ursprungsfeldname keinen zugehörigen Feldnamen der vertraulichen Bank hat, kann die Rohdatenkonfiguration der vertraulichen Bank dann aktualisiert werden, wenn angenommen wird, dass der spezifische Ursprungsfeldname in anderen Formularen auftauchen könnte. Andernfalls wird es dem Nutzer überlassen, dies manuell auszufüllen, wie in Schritt 424 der 4 beschrieben ist.
In Schritt 608 führt der Server die erhaltene Namensabbildung und die Rohdaten des Nutzers mittels eines Zusammenfügungsvorgangs zusammen. Die Fusion zweier Tupel: dem Ursprungsnamen-/vertraulichen Banknamentupel und dem vertraulichen Banknamen/Rohdatenwerttupel wird detaillierter nachfolgend beschrieben. Das Ergebnis dieser Fusion ist eine Reihe von Tupeln, die einen Ursprungsnamen einem Rohdatenwert, der mit dem Nutzer in Zusammenhang steht, zuordnet. Bei anderen bevorzugten Ausführungsformen kann diese Fusion unter Verwendung anderer Datenkonstruktionen und -Vorgängen ausgeführt werden. Das Ergebnis ist jedoch eine Paarung eines Ursprungsfeldnamen und eines Rohdatenwertes. Im Schritt 610 wird die Reihe an Tupeln aus der Fusion in einen versendbaren Code umgewandelt. Bei der beschriebenen Ausführungsform liegt der versendbare Code in Form eines JavaScript-Programms vor, der an den Browser auf dem Nutzercomputer versendet wird. Im Allgemeinen haben Browserprogramme eine JavaScript-Komponente, die durch JavaScript-Befehle manipulierbar ist. Diese JavaScript-Befehle im versendbaren Code werden zur Befüllung des elektronischen Formulars auf dem Browser verwendet, eine Technik die auf dem Gebiet der Internet- und Javaprogrammierung gut bekannt ist. Es erscheint hilfreich, dass hier angemerkt wird, dass das Formular tatsächlich auf dem Nutzercomputer mittels des Browsers unter Verwendung der JavaScript-Befehle im versendbaren Code ausgefüllt wird. Das Formular wird nicht auf dem vertraulichen Bankserver ausgefüllt; die Information zur Befüllung des Formulars wird dort zusammengestellt, wird aber dann an den Nutzercomputer versendet. An dieser Stelle ist der Vorgang zur Herleitung des versendbaren Codes auf dem vertraulichen Bankserver abgeschlossen.
7 ist ein Flussdiagramm eines Vorgangs für das Zuordnen, durch den Formularnamen zu Rohdatenwerten des Nutzers gemäß einer Ausführungsform der vorliegenden Erfindung zugeordnet werden. Wie zuvor beschriebenen verwendet der vertrauliche Bankserver in Schritt 702 die Formular-URL oder andere Kennung, um eine Zuordnung für das Formular zu erhalten, die einen Ursprungsnamen auf einen standardisierten Namen der vertraulichen Bank abbildet. Die Zuordnung enthält ferner eine oder mehrere Ausführungen zu jedem Feldnamen, die detaillierter nachfolgend beschrieben werden. Diese Zuordnung wird erstellt, wenn ein Händler oder Dienstanbieter sich entscheidet, zugehöriges Mitglied des vertraulichen Bankdienstes zu werden. Während des Registrierungsvorgangs teilt der Händler der vertraulichen Bank mit, welche Formulare er zu registrieren beabsichtigt und nennt die Feldnamen dieser Formulare, die dann mit den standardisierten Namen der vertraulichen Bank gepaart werden. In Schritt 704 wird das Nutzer-Cookie dazu verwendet, die Nutzerrohdaten zu erhalten, die aktuelle Datenwerte und Vorzüge, die mit jedem Datenwert verbunden sind, beinhalten. Die Ausführungen, die zuvor erwähnt wurden und die mit den Ursprungsnamen verbunden sind und die Vorzüge, die mit den Nutzerrohdatenwerten verbunden sind, sind in Form von Bedingungen angegeben. Bei der beschriebenen Ausführungsform gibt es verschiedene Bedingungen, wie Vermarktung (beabsichtigte), Systemadministration, Personalisierung, Forschung und Entwicklung und Komplettierung der Aktivität (d. h. Bestellung). Andere Ausgestaltungen können mehr oder weniger Bedingungen aufweisen.
Wenn sich ein Händler beim vertraulichen Bankdienst registriert, muss er angeben, welche Bedingungen er für jedes Ursprungsfeld verwenden will. Zum Beispiel für das Feld "Nachname" kann er angeben, dass seine Praxis die Verwendung für "Personalisierung" und "Komplettierung der Aktivität" vorsieht und nichts anderes. Für ein "Zahlungsweise"-Feld kann er angeben, dass seine Praxis lediglich die Verwendung für "Komplettierung der Aktivität", "Forschung und Entwicklung" und "Administration" vorsieht. Auf diese Weise erstellt der Händler eine Liste von Paaren (Ursprungsfeldname, Ausführung), die auf dem vertraulichen Bankserver gespeichert werden. Auf ähnliche Weise, wenn ein Nutzer Mitglied des vertraulichen Bankdienstes wird, ist er oder sie gezwungen die Rohdatenwerte (spezifische Felder für die Rohdaten sind nachfolgend beschrieben) und die entsprechenden Vorzüge anzugeben, die auch in Form von Bedingungen angegeben sind. Sie werden Vorzüge genannt, da sie aus Sicht des Nutzers ein Vertraulichkeits- oder Nutzungslimit anzeigen. Zum Beispiel kann eine Nutzerin vorgeben, dass ihr Nachname nur für "Personalisierung", "Komplettierung der Aktivität" und "Systemadministration" verwendet wird und kann somit vorgeben, dass er beispielsweise nicht für die beabsichtigte "Vermarktung" verwendet wird. Wenn bei der beschriebenen Ausführungsform der Nutzer keine Vorzugsbedingung spezifiziert, wird das Datenelement, wie eine Sozialversicherungsnummer oder der Mädchenname der Mutter, nicht freigegeben.
In Schritt 706 erhält der vertrauliche Bankserver ein einzelnes Paar (Ursprungsname, Ausführung) und dessen korrespondierenden, standardisierten Namen der vertraulichen Bank von der Formularzuordnung, die in Schritt 702 erhalten wurde.
Bei der beschriebenen Ausführungsform kann dieses Paar das erste Formularfeld auf dem Online-Formular des Händlers sein. In Schritt 708 erhält der Server ein korrespondierendes Paar (standardisierter Name der vertraulichen Bank, Vorzug) aus der Rohdaten-"Datei" des Nutzers. Der Name der vertraulichen Bank in solch einem Paar 10 sollte dem Namen der privaten Bank in dem Paar, das in Schritt 706 erhalten wurde, entsprechen:
[(Ursprungsname, Ausführung), vB-Name 1)]:[vB-Name 1, Vorzug]
In Schritt 710 vergleicht der vertrauliche Bankserver die Ausführungsbedingungen des Händlers auf der linken Seite mit den Vorzugsbedingungen des Nutzers auf der rechten Seite. Beispielsweise hat der Händler bezüglich des Nachnamenfeldes spezifiziert, dass es seiner Ausführung entspricht, dieses Datenelement für die Bedingungen "Personalisierung" und "Komplettierung der Aktivität" zu verwenden. Die Nutzerin hat angegeben, dass sie lediglich die Verwendung ihres Nachnamen für die Bedingungen "Personalisierung", "Komplettierung der Aktivität" und "Systemadministration" gestattet. Die Bedingungen des Händlers und die Bedingungen des Nutzers werden verglichen. In Schritt 712 legt der vertrauliche Bankserver fest, ob das Formularfeld des Verkäufers unter Berücksichtigung des Vertraulichkeitslimits des Nutzers für das Feld gefüllt wird. In der beschriebenen Ausgestaltung geschieht dies, indem bestimmt wird, ob die Vorzugsbedingungen des Nutzers eine Obermenge der Ausführungsbedingungen des Händlers bilden; das heißt, ob der Händler beabsichtigt, den Nachnamen des Nutzers für irgendetwas anderes zu verwenden, als der Nutzer angegeben hat. Bei dem Beispiel des Nachnamens sind die Vorzüge des Nutzers eine Obermenge der Ausführungen des Händlers: "Personalisierung", "Komplettierung der Aktivität" und "Systemadministration" umfassen wenigstens die Gesamtheit aus "Personalisierung" und "Komplettierung der Aktivität".
Wenn die Vorzüge des Nutzers keine Obermenge der Ausführungen des Händlers sind, geht die Steuerung zu Schritt 714 über, bei dem eine Nachricht dem Nutzer angezeigt wird, die indiziert, dass das Feld nicht automatisch gefüllt wird, da der Händler diese Information auf eine Art und Weise verwenden könnte, die nicht durch den Nutzer autorisiert ist. Bei der beschriebenen Ausführungsform wird, falls auf ein Feld im Formular diese Bedingung zutrifft, keins der Felder im Formular ausgefüllt und der Vorgang ist abgeschlossen. Bei anderen bevorzugten Ausführungsformen hat der Nutzer die Option, das Feld manuell auszufüllen und lässt den vertraulichen Bankserverdienst mit den verbleibenden Feldern weitermachen.
Falls die Vorzüge des Nutzers eine Obermenge der Ausführungen des Händlers sind, wird die Steuerung mit Schritt 716 fortgesetzt, wo das Feld mit dem Rohdatenwert befüllt wird. Die Schritte 710 und 712 können als ein zweistufiger Verhandlungsvorgang angesehen werden. Das Händlerformular, was als "Informationskäufer" angesehen werden kann, macht ein Angebot an den Nutzer, den "Informationsverkäufer". Das Angebot betrifft im Wesentlichen Folgendes, welches Datenelement der Informationskäufer haben will und was er damit zu tun beabsichtigt. Dies ist der erste Schritt des Verhandlungsvorgangs, bei dem der vertrauliche Bankserver als ein Unterhändler agiert. Der Nutzer bekommt das Angebot und überprüft, ob die Bedingungen des Händlers das überschreiten, was der Nutzer bevorzugt. Mit anderen Worten überprüft der Nutzer, ob der Händler beabsichtigt, das Datenelement für Zwecke zu verwenden, die nicht ausdrücklich durch den Nutzer genehmigt wurden. Wenn die Ausführungsbedingungen des Händlers akzeptabel sind (durch Durchführen des Obermengentests in Schritt 712), übermittelt der Nutzer seine Akzeptanz an den Händler, wobei zu diesem Punkt der Rohdatenwert empfangen wird und mit dem Ursprungsfeld in Verbindung gebracht wird. Wenn die Bedingungen des Händlers nicht akzeptabel sind, sendet der Nutzer im Wesentlichen eine "Ablehnungs"-Erklärung am den Händler über den Unterhändler ohne einen Rohdatenwert. Jede zweistufige Verhandlung wird als ein Objekt angesehen, das später dazu verwendet wird, ein JavaScript-Programm (den versendbaren Code) zu erzeugen, indem Standardtechniken der Javaprogrammierung verwendet werden.
In Schritt 718 überprüft der Server, ob es weitere Paare(Ursprungsname, Ausführung) im Formular des Händlers gibt. Falls es weitere Ursprungsfelder gibt, kehrt die Steuerung zu Schritt 706 zurück und der Vorgang wird wiederholt. Wenn es keine auszufüllenden Felder mehr gibt, ist der Vorgang abgeschlossen. An dieser Stelle existiert eine Reihe von Objekten oder ein Verlauf an Verhandlungen, die aus dem Zuordnungsvorgang hervorgegangen sind. Diese Reihe an Objekten wird dann verwendet, um das JavaScript-Programm zu schaffen. Bei der beschriebenen Ausführungsform sind alle Objekte vom Nutzer akzeptiert und haben somit einen Rohdatenwert beigefügt, der im JavaScript-Profil, das an den Browser/Nutzer übersandt wird, enthalten ist. In anderen, bevorzugten Ausführungsformen können einige der Objekte eine "nicht akzeptiert" oder Ablehnungsnachricht haben, die anzeigt, dass ein einzelnes Feld in dem Formular nicht ausgefüllt werden wird und hat somit keinen Rohdatenwert. Wie zuvor erwähnt wurde, wird bei der beschriebenen Ausführungsform, falls eines der Felder nicht ausgefüllt werden kann, da die Ausführungen des Händlers die Vorzüge des Nutzers übersteigen, das gesamte Formular nicht ausgefüllt. Der versendbare Code oder das Profil, das dem Nutzer gesandt wird, repräsentiert eine Reihe von Paaren (Ursprungsfeldname, Rohdatenwert) ohne Bezug auf Vorzüge oder Ausführungen, alle Verhandlungen betreffend die Datenwerte wurden auf dem vertraulichen Bankserver durchgeführt.
Die 8A, 8B, 8C, 8D und 8E sind High-level-Tabellendiagramme, die zeigen wie die Felder, die die Rohdaten und Vorzüge für einen Nutzer auf dem vertraulichen Server gemäß einer Ausführungsform der vorliegenden Erfindung organisiert sind. Eine Nutzertabelle der obersten Ebene 802, die in 8A gezeigt ist, hat vier Spalten: Nutzer 804, Kategorie 806, Typ 808 und angezeigter Kurzname 810. Die Nutzertabelle 802 hat vier Datenbereiche in der Spalte Nutzer 804, die durch vier Reihen repräsentiert werden: daheim 812, Arbeit 814, Fakturierung 816 und Versand 818. Bei der beschriebenen Ausführungsform ist der Nutzer mit diesen vier Datenbereichen konfrontiert, wenn er sich beim vertraulichen Bankdienst registriert und gibt Informationen ein, indem er durch alle diese Datenbereiche geht. Wird erst einmal die Kategorie 806 übergangen, geht die Typ-Spalte 808 im Rohdatenbereich eine Ebene von der obersten Ebene hinunter, die durch die Tabelle 802 repräsentiert wird. Beispielsweise ist der Typ des Datenfeldes daheim 812 Info. Dies fungiert als ein Verweis oder Link auf eine Infotabelle 820, gezeigt in 8B. Die erste Spalte 821 der Tabelle 820 ist mit Info bezeichnet, aber die anderen drei Spalten sind dieselben, wie in Tabelle 802 gezeigt ist; das sind Kategorie 806, Typ 808, angezeigter Kurzname 810.
In Tabelle 820 beginnt der Nutzer, Daten einzugeben, die für die Daheim-Information und den Versand versendet werden, da der Datenbereich 818 für den Versand in Tabelle 802 ebenso eine Info in seiner Typspalte 808 hat. Eine Namenreihe 822 hat in ihrer Typ-Spalte 808 einen Bezug auf eine noch eine andere Tabelle PersonName, die als Tabelle 824 in der 8C gezeigt wird. Ähnlich den Tabellen 802 und 820 hat die PersonName-Tabelle 824 eine erste Spalte mit der Bezeichnung PersonName und drei Spalten die denen der anderen Tabellen entsprechen. Alle fünf Datenbereiche in der PersonName Tabelle 824: Präfix, Erster, Mittlerer, Nach und Suffix haben als Typ eine einfache Form, die als Text bei der beschriebenen Ausführungsform bezeichnet wird. Text repräsentiert einen Datenstring, der das aktuelle Datenelement ist, das im vertraulichen Bankserver gespeichert wird. Bei Überprüfung der Typspalte 808 jedes Datenbereichs gibt der Nutzer all die persönlichen Rohdaten ein. Ein aktuelles Datenelement wird bei jedem Typ-Feld eingegeben, das Text enthält, was eine einfache Art oder einen Knotenpunkt indiziert, wenn es als Baumstruktur betrachtet wird. Wenn die Typspalte nicht "Text" enthält, existiert eine weitere Tabelle, die den Datenbereich weiterentwickelt.
Im Folgenden wird ein anderes Beispiel weiterverfolgt: Unter dem Datenbereich Fakturierung 816, der in Tabelle 802 angegeben ist, ist unter Typ 808 Fakturierinfo und nicht Text angegeben. Eine Tabelle Fakturierinfo hat sechs weitere Datenbereiche, wobei keiner davon vom Text-Typ ist, so dass auf dieser Ebene keine aktuellen Datenwerte aufgefunden werden können. Wird der Kreditkartenbereich als Beispiel genommen, ist unter Typ "Kreditkarte" angegeben. Die Tabelle Kreditkarte, die in 8E gezeigt ist, hat vier Datenbereiche: Typ, Nummer, Abl.Monat und Abl.Jahr, jeder davon ist vom Text-Typ, der aktuelle Datenwerte enthält.
Der angezeigte Kurzname Spalte 810 enthält einen String, der dem Nutzer während einer grafischen Nutzerinterfaces bei der Nutzerregistrierung angezeigt wird. Der Nutzer folgt dem Datenbaum mittels eines Nutzerinterfaces, welches die angezeigten Kurznamenstrings als Feldnamen verwendet oder durch die Dateneingabe führt. Die Datenbereiche, die vom einfachen Typ sind, die in der beschriebenen Ausführungsform Text ist, sind die Feldnamen der vertraulichen Bank die den Ursprungsfeldnamen in den elektronischen Formularen, die beim Dienst registriert sind, zugeordnet sind. In der beschriebenen Ausführungsform beinhalten die Namen der vertraulichen Bank Folgendes (in abgekürzter Form):
Die Kategorie Spalte 806 betrifft die Vertraulichkeitsvorgaben, die vom Nutzer vorgegeben werden und an die Vorzüge, die von einem Nutzer vorgegeben werden, gebunden sind und die mittels der Bedingungen definiert werden, wie zuvor, insbesondere in 7, beschrieben wurde. Die Bedingungen oder Verwendungsbeschränkungen in der beschriebenen Ausführung sind Vermarktung (beabsichtigte), Systemadministration, Personalisierung, Forschung und Entwicklung und Komplettierung der Aktivität (d. h. Bestellung). Die Kategorien, die in der beschriebenen Ausführungsform möglich sind und in den 8A, 8B, 8C, 8D und 8E gezeigt sind, sind physikalische Kontaktinformation, Online-Kontaktinformation, demographische Daten und Finanzdaten. Das Verhältnis zwischen den Kategorien und Bedingungen der beschriebenen Ausführungsform kann als eine fünf Reihen, vier Spaltentabelle (eine Tabelle mit 20 Zellen) beschrieben werden, wobei jede Bedingung als eine Reihe in der Tabelle und jede Kategorie eine Spalte in der Tabelle ist.
Die vorliegende Erfindung nutzt verschiedene computerimplementierte Vorgänge, die Daten beinhalten, die in einem Computersystem gespeichert werden. Diese Vorgänge beinhalten solche, die physikalische Beeinflussung von physikalischen Größen erfordern, aber sind nicht darauf beschränkt. Gewöhnlich, obwohl nicht notwendigerweise, liegen diese Größen in Form von elektrischen oder magnetischen Signalen vor, die gespeichert, übermittelt, kombiniert, verglichen oder anderweitig manipuliert werden können. Diese hierin beschriebenen Vorgänge, die Teil der Erfindung bilden, sind nützliche Maschinenbetriebsarten. Die Beeinflussungen, die durchgeführt werden, werden mit Worten beschrieben, wie Erzeugen, Identifizieren, Laufen, Bestimmen, Vergleichen, Ausführen, Herunterladen oder Detektieren. Es ist manchmal bequem, prinzipiell aus Gründen der allgemeinen Verwendung diese elektrischen oder magnetischen Signale als Bits, Werte, Elemente, Variablen, Zeichen, Daten oder Ähnliches zu bezeichnen. Es soll jedoch daran erinnert werden, dass all diese oder ähnliche Wörter mit den geeigneten physikalischen Größen in Verbindung zu bringen sind und es lediglich passende Bezeichnungen sind, die auf diese Größen angewandt werden.
Die vorliegende Erfindung betrifft auch eine Vorrichtung, System oder Apparat zur Durchführung der vorgenannten Vorgänge. Das System kann speziell für die notwendigen Zwecke entwickelt worden sein, oder es kann ein Mehrzweckcomputer sein, der durch ein auf dem Computer gespeichertes Computerprogramm selektiv aktiviert oder konfiguriert werden kann. Die zuvor präsentierten Vorgänge sind nicht inhärent mit einem spezifischen Computer oder einem Steuerungsapparat verbunden. Insbesondere können verschiedene Mehrzweckcomputer mit den Programmen verwendet werden, die gemäß der vorliegenden Lehre geschrieben wurden, oder alternativ kann es bequemer sein, ein spezialisierteres Computersystem zu entwickeln, um die notwendigen Vorgänge auszuführen.
9 ist ein Blockdiagramm eines Mehrzweckcomputersystems 900, das sich zur Durchführung der Verarbeitung gemäß einer Ausführungsform der vorliegenden Erfindung eignet. 9 stellt eine Ausführungsform eines Mehrzweckcomputersystems, wie den Nutzercomputer 302 der 3A, dar und beschreibt auch viele Komponenten, die im vertraulichen Bankserver 308 zu finden sind. Andere Computersystemarchitekturen und Konfigurationen können zur Verwirklichung des Verarbeitung der vorliegenden Erfindung verwendet werden. Das Computersystem 900, das aus verschiedenen Subsystemen, die nachfolgend beschrieben werden, besteht, beinhaltet wenigstens ein Mikroprozessor-Subsystem (auch als eine zentrale Prozessoreinheit oder CPU bezeichnet) 902. Das heißt die CPU 902 kann durch einen Einchip-Prozessor oder durch mehrere Prozessoren verwirklicht werden. Die CPU 902 ist ein Mehrzweck-Digitalprozessor, der den Betrieb des Computersystems 900 kontrolliert. Unter Verwendung von Befehlen, die sie vom Speicher erhält steuert die CPU 902 den Empfang und Beeinflussung von eingegebenen Daten und die Ausgabe und Darstellung von Daten auf Ausgabegeräten.
Die CPU 902 ist bidirektional mit einem ersten Primärspeicher 904, typischerweise ein Schreib-/Lesespeicher (RAM) und unidirektional mit einem zweiten Primärspeicher 906, typischerweise ein Nur-Lese-Speicher (ROM), durch einen Speicherbus 908 verbunden. Wie es im Stand der Technik wohl bekannt ist, kann der Primärspeicher 904 als ein allgemeiner Speicherbereich und als Pufferspeicher verwendet werden und kann ebenso dazu verwendet werden, eingegebene und verarbeitete Daten zu speichern. Er kann auch Programmanweisungen und Daten, in der Form von Datenobjekten oder JavaScript-Programmen, beispielsweise zusätzlich zu anderen Daten und Anweisungen, zur Verarbeitung durch die CPU 902 speichern, und er wird typischerweise zur schnellen Übertragung von Daten und Anweisungen auf bidirektionale Weise über den Speicherbus 908 verwendet. Wie ferner im Stand der Technik wohl bekannt ist, beinhaltet der Primärspeicher 906 typischerweise Basisbetriebsanweisungen, Programmcode, Daten und Objekte, die von der CPU 902 verwendet werden, um ihre Funktionen auszuführen. Die Primärspeichereinrichtungen 904 und 906 können irgendein computerlesbares Speichermedium beinhalten, wie nachfolgend beschrieben wird, lediglich abhängig davon, ob beispielsweise der Datenzugriff bidirektional oder unidirektional erfolgen muss. Die CPU 902 kann auch direkt und sehr schnell häufig benötigte Daten in einem Cache-Speicher 910 abrufen.
Ein austauschbares Massenspeichergerät 912 stellt zusätzliche Datenspeicherkapazität für das Computersystem 900 bereit und ist entweder bidirektional oder unidirektional mit der CPU 902 über einen Peripheriebus 914 verbunden. Zum Beispiel kann ein spezifisches austauschbares Massenspeichergerät, im Allgemeinen als CD-ROM bekannt, typischerweise die Daten unidirektional zur CPU 902 übermitteln, wohingegen eine Floppydisk Daten bidirektional mit der CPU 902 austauschen kann. Der Speicher 912 kann auch computerlesbare Medien, wie Magnetband, Flash-Speicher, Signale die in einer Trägerwelle verwirklicht sind, PC-Cards, tragbare Massenspeichergeräte, holografische Speichergeräte und andere Speichergeräte beinhalten. Ein fester Massenspeicher 916 kann auch zusätzliche Datenspeicherkapazität bereitstellen und ist mit der CPU 902 über den Peripheriebus 914 bidirektional verbunden. Das üblichste Beispiel eines Massenspeichers ist eine Festplatte. Im Allgemeinen ist der Zugriff auf diese Medien langsamer als der Zugriff auf den Primärspeicher 904 und 906.
Der Massenspeicher 912 und 916 speichert im Allgemeinen zusätzliche Programmanweisungen, Daten und Ähnliches, das nicht unter aktiver Verwendung der CPU 902 steht. Es ist zu bedenken, dass die Information, die im Massenspeicher 912 und 916 enthalten ist, auf übliche Art und Weise als Teil des Primärspeichers 904 (z. B. RAM) als virtueller Speicher eingearbeitet werden kann.
Neben der Aufgabe, der CPU 902 Zugang zum Speichersubsystem zu verschaffen, wird der Peripheriebus 914 dazu verwendet, Zugang zu anderen Subsystemen und such Geräten bereitzustellen. In der beschriebenen Ausführungsform umfasst dies einen Anzeigemonitor 918 und -Adapter 920, einen Drucker 922, einen Netzwerkinterface 924, ein zusätzliches Ein- und Ausgabegerätinterface, eine Soundkarte 928 und Lautsprecher 930 und andere Subsysteme wie benötigt.
Das Netzwerkinterface 924 ermöglicht der CPU 902 die Verbindung mit einem anderen Computer, Computernetzwerk oder Telekommunikationsnetzwerk, die die gezeigte Netzwerkverbindung nutzt. Durch das Netzwerkinterface 924 wird beabsichtigt, dass die CPU 902 Information während der Durchführung der zuvor genannten Verfahrensschritte von anderen Netzwerken empfangen könnte, beispielsweise Datenobjekte oder Programmanweisungen, oder Informationen an andere Netzwerke ausgeben könnte. Information, oft repräsentiert durch eine Anweisungssequenz, die durch eine CPU auszuführen sind, kann von einem anderen Netzwerk empfangen werden und an dieses ausgegeben werden, beispielsweise in der Form eines Computerdatensignals, das von einer Trägerwelle aufgenommen wird. Eine Interfacekarte oder ähnliche Einrichtung und geeignete Software, die auf die CPU 902 implementiert wurde, können verwendet werden, um das Computersystem 900 mit einem externen Netzwerk zu verbinden und um Daten gemäß Standardprotokollen zu übertragen. Das heißt, die Verfahrensausgestaltung der vorliegenden Erfindung kann lediglich durch eine CPU 902, oder kann über ein Netzwerk, wie dem Internet, Intranetzen oder lokalen Netzen in Verbindung mit ein entfernten CPU, die einen Teil der Verarbeitung übernimmt ausgeführt werden. Zusätzliche Massenspeichereinrichtungen (nicht gezeigt) können mit der CPU 902 über das Netzwerkinterface 924 verbunden werden.
Das zusätzliche I/O-Geräte-Interface 926 repräsentiert allgemeine und angepasste Interface, die es der CPU 902 ermöglichen Daten zu senden und noch typischer von anderen Geräten, wie Mikrophonen, berührungsempfindlichen Anzeigen, Wandlerkartenlesern, Bandlesegerten, Stimme- oder Handschrifterkennern, biometrischen Lesegeräten, Kameras, portablen Speichereinrichtungen und anderen Computern, Daten zu empfangen.
Ebenso ist ein Tastatursteuerchip 932 über den lokalen Bus 934 mit der CPU 902 verbunden, um Eingaben über die Tastatur 936 oder ein Zeigegerät 938 zu empfangen und decodierte Symbole von der Tastatur 936 oder dem Zeigegerät 938 an die CPU 902 zu senden. Das Zeigegerät kann eine Maus, Stift, Trackball oder Tablett sein und ist nützlich für die Interaktion mit einem grafischen Nutzerinterface.
Zusätzliche Ausführungsformen der vorliegenden Erfindung betreffen Computerspeicherprodukte mit einem computerlesbaren Medium das einen Programmcode enthält, um verschiedene computerimplementierte Vorgänge durchzuführen. Das computerlesbare Medium ist irgendein Datenspeichergerät, das Daten abspeichern kann, die danach von einem Computersystem gelesen werden können. Das Medium und der Programmcode können speziell zu Zwecken der vorliegenden Erfindung entworfen und konstruiert sein oder sie können von einer Art sein, die dem Durchschnittsfachmann auf dem Gebiet der Computersoftware wohl bekannt ist. Beispiele für computerlesbare Medien umfassen, ohne darauf beschränkt zu sein, alle zuvor genannten Medien: magnetische Medien, wie Festplatten, Disketten und Magnetband; optische Medien, wie CD-ROM-Scheiben; magneto-optische Medien, wie Floptical Disks und speziell gestaltete Hardware-Geräte, wie anwendungsspezifische integrierte Schaltkreise (ASICs), programmierbare Logikbausteine (PLDs) und ROM- und RAM-Bausteine. Das computerlesbare Medium kann auch als ein Datensignal in einer Trägerwelle über ein Netzwerk aus verbundenen Computersystemen verbreitet werden, so dass der computerlesbare Code auf verteilte Art und Weise gespeichert und ausgeführt wird. Beispiele des Programmcode beinhaltet entweder Maschinensprache, wie sie beispielsweise durch einen Kompiler erzeugt wird oder Dateien, die einen Code einer Hochsprache enthalten, der unter Verwendung eines Interpreters ausgeführt wird.
Es wird von Fachleuten bemerkt werden, dass es sich bei den zuvor beschriebenen Hardware- und Softwareelementen um Standarddesigns und -Konstruktionen handelt. Andere Computersysteme, die geeignet sind, mit der Erfindung verwendet zu werden, können zusätzliche oder weniger Subsysteme aufweisen. Ferner dienen der Speicherbus 908, der Peripheriebus 914 und der lokale Bus 934 der Illustration irgendeines Verbindungsschemas, das Verknüpfung der Subsysteme dient. Zum Beispiel kann ein lokaler Bus dazu verwendet werden, die CPU mit dem festen Massenspeicher 916 und dem Anzeigeadapter 920 zu verbinden. Das in 9 gezeigte Computersystem ist lediglich ein Beispiel für ein Computersystem, das zur erfindungsgemäßen Verwendung geeignet ist. Andere Computerarchitektur mit anderen Konfigurationen der Subsysteme kann auch genutzt werden.
Obwohl die vorhergehende Erfindung zu Zwecken des besseren Verständnisses mit einigen Details beschrieben wurde, ist es offensichtlich, dass bestimmte Veränderungen und Modifikationen im Bereich der abhängigen Ansprüche durchgeführt werden können. Es ist ferner anzumerken, dass es alternative Herangehensweisen gibt, sowohl das Verfahren und die Vorrichtung der vorliegenden Erfindung zu implementieren. Beispielsweise können die Rohdaten bei Bedarf mehr oder weniger Felder, als die beschriebenen, umfassen, und es können zusätzliche vertraulichkeits- oder nutzungsbeschränkende Bedingungen zu den fünf beschriebenen vorhanden sein.
Gemäß einem anderen Beispiel kann das ausgefüllte elektronische Formular automatisch an den Internetserver des Händlers versendet werden, nachdem der vertrauliche Bankserver seine Rohdaten mit zusätzlichen Eingaben vom Nutzer aktualisiert hat. Bei einem anderen Beispiel, können die Rohdaten und Ursprungsfelder gebündelt werden und in einem anderen Softwaremodul als einem JavaScriptmodul codiert werden. Demzufolge sind die vorliegenden Ausführungsformen zur Veranschaulichung gedacht und nicht beschränkend, und die Erfindung ist auf die hierbei angegebenen Details zu limitieren, aber kann innerhalb des Schutzbereichs der abhängigen Ansprüche modifiziert werden.

Claims

Verfahren zum Aufbau eines versendbaren Softwaremoduls auf einem persönlichen Informationsserver (308), das zur Ausführung auf einem entfernten Computer (302) zum Einfügen von Datenstrings in ein elektronisches Formular (316) geeignet ist, wobei das Verfahren umfasst: Ermitteln (702) einer Formularzuordnung (330), welche eine Vielzahl von Zuordnungen zwischen Datenfeldern in dem elektronischen Formular und vorbenannten Datenfeldern auf dem persönlichen Informationsserver enthält, wobei die Zuordnung dem elektronischen Formular zugehörig ist; Ermitteln (704) einer Rohdatendatei (328), welche Datenstrings enthält, wobei jeder Datenstring einem vorbenannten Feld entspricht und die Rohdatendatei einem bestimmten Nutzer zugeordnet ist; und Verwendung (706, 708) der Formularzuordnung (330), um einen Datenstring mit dem Feld in dem elektronischen Formular zu verbinden, wo das vorbenannte Feld und das Feld in dem elektronischen Formular einander zugeordnet sind.
Verfahren gemäß Anspruch 1 mit ferner dem Schritt des Vergleichens (710) einer jedem Feld in dem elektronischen Formular zugeordneten Bestimmungsausführbedingung mit einer jedem vorbenannten Feld zugeordneten Nutzungsvorzugsbedingung.
Verfahren gemäß Anspruch 2 mit ferner dem Schritt des Verbindens (716) eines Datenstrings mit dem Feld in dem elektronischen Formular, wenn die Bestimmungsausführbedingung des Feldes kleiner gleich als die Nutzungsvorzugsbedingung des vorbenannten Feldes ist.
Verfahren gemäß Anspruch 1 mit ferner dem Schritt des Empfangens einer dem bestimmten Nutzer zugeordneten Nutzerkennung und einer dem elektronischen Formular zugeordneten Formularkennung, wenn das elektronische Formular von dem bestimmten Nutzer herunter geladen wird.
Verfahren gemäß Anspruch 2 mit ferner dem Schritt des Ablehnens der Verbindung eines Datenstrings mit dem Feld in dem elektronischen Formular, wenn die Bestimmungsausführungsbedingung des Feldes größer als die Nutzungsvorzugsbedingung des vorbenannten Feldes ist.
Verfahren gemäß Anspruch 5, wobei die Bestimmungsausführbedingung und die Nutzungsvorzugsbedingung Sammlungen von Nutzungsartenbeschreibern sind.
Verfahren gemäß Anspruch 1, wobei die Nutzung der Formularzuordnung zur Verbindung eines Datenstrings mit dem Feld in dem elektronischen Formular ferner die Prüfung einer Vielzahl von Verhandlungsobjekten (350) bezüglich entweder der Annahme oder des Ablehnens umfasst, wobei sich jedes Verhandlungsobjekt aus dem Vergleich von zu dem Feld in dem elektronischen Formular gehörigen Daten mit zu dem vorbenannten Feld gehörigen Daten ergibt.
Verfahren gemäß Anspruch 7 mit ferner dem Aufbau eines JavaScript-Moduls aus jedem Verhandlungsobjekt, das zu einer Annahme führt.
Verfahren gemäß Anspruch 1, wobei das versendbare Softwaremodul ein JavaScript-Programm ist.
Server (308) zur Ermöglichung des automatischen Einfügens von Datenstrings in ein elektronisches Formular (316) mit einer Vielzahl von Datenfeldern auf einem entfernten Computer (302), der dazu in der Lage ist, mit dem Server zu kommunizieren, wobei der Server umfasst: einen ersten Speicherbereich (328) zum Speichern einer Vielzahl von Rohdatenprofilen, wobei jedes Rohdatenprofil einem zugehörigen registrierten Nutzer entspricht; einen zweiten Speicherbereich (330) zum Speichern einer Vielzahl von Formularzuordnungen, wobei jede Formularzuordnung einem elektronischen Formular entspricht, das auf dem Server registriert ist, und es eine Gruppe von Zuordnungen zwischen den Datenfeldern in dem elektronischen Formular und vorbenannten Standardfeldern auf dem Server enthält; ein Vergleichsmodul (332) zum Vergleichen von in der Vielzahl von Rohdatenprofilen enthaltenen Nutzungsvorzugsdaten mit in der Vielzahl von Formularverzeichnissen enthaltenen Ausführvorzugsdaten; und einen Softwaremodulkonstruktor (334) zur Erstellung und Übermittlung eines versendbaren Programms, das geeignet ist zur Durchführung auf einem entfernten Computer, um Datenstrings entsprechend dem Vergleich der Nutzungsvorzugsdaten und der Ausführvorzugsdaten in ein elektronisches Formular auf dem entfernten Computer einzusetzen.
Server gemäß Anspruch 10, wobei jedes Rohdatenprofil eine Vielzahl von Standardfeldnamen beinhaltet, wobei jeder Standardfeldname einen entsprechenden Datenstring und ein Nutzungsvorzugsdatenelement, wie von dem zugehörigen registrierten Nutzer bestimmt, aufweist.
Server gemäß Anspruch 11, wobei jede Formularzuordnung eine Vielzahl von Nicht-Standardfeldnamen aus dem elektronischen Formular beinhaltet, wobei jeder Nicht-Standardfeldname einem Standardfeldnamen zugeordnet wird und ein Ausführvorzugsdatenelement aufweist.
Server gemäß Anspruch 10, wobei das Vergleichsmodul eine Vielzahl von Bedingungen enthält, aus welchen die Ausführvorzugsdaten und die Nutzungsvorzugsdaten definiert werden.
Server gemäß Anspruch 10, mit ferner einem Verhandlungsverlaufmodul, das eine Vielzahl von Verhandlungsmodulen enthält, wobei jedes Verhandlungsmodul eine Angebotskomponente und entweder eine Annahmekomponente oder eine Ablehnungskomponente aufweist.
Server gemäß Anspruch 14, wobei die Annahmekomponente ferner einen Datenstring aufweist, der zumindest einem der vielzähligen Datenfelder in dem elektronischen Formular entspricht.
Server gemäß Anspruch 10, wobei das versendbare Programm ein JavaScript-Programm ist, welches Anweisungen bezüglich Datenfeldern enthält, in welche jeder Datenstring in dem elektronischen Formular auf dem entfernten Computer einzusetzen ist.
Server gemäß Anspruch 16, wobei das versendbare Programm ferner die Vielzahl von in das elektronische Formular einzusetzenden Datenstrings umfasst.
Server gemäß Anspruch 10 mit ferner einem registrierten Nutzerindex zur Lokalisierung eines bestimmten Rohdatenprofils, dem eine Nutzerkennung entsprechend einem registrierten Nutzer gegeben wurde.
Server gemäß Anspruch 18, wobei die Nutzerkennung ein Cookie ist.
Server gemäß Anspruch 10 mit ferner einem Formularzuordnungsindex zur Lokalisierung einer bestimmten Formularzuordnung, der eine elektronische Formularkennung gegeben wurde.
Server gemäß Anspruch 20, wobei die elektronische Formularkennung ein Uniform Resource Locator ist.
Computerprogrammprodukt (334) zum Erzeugen eines versendbaren Softwaremoduls auf einem persönlichen Informationsserver (308), das zur Durchführung auf einem entfernten Computer (302) zum Einfügen von Datenstrings in ein elektronisches Formular (316) geeignet ist, mit: einem Computercode, der eine Formularzuordnung (330) ermittelt, welches eine Vielzahl von Zuordnungen zwischen Datenfeldern in dem elektronischen Formular und vorbenannten Datenfeldern auf dem persönlichen Informationsserver enthält, wobei die Zuordnung dem elektronischen Formular zugeordnet ist; einem Computercode, der eine Rohdatendatei (328) ermittelt, welche Datenstrings enthält, wobei jeder Datenstring einem vorbenannten Feld entspricht und die Rohdatendatei einem bestimmten Nutzer zugeordnet ist; einem Computercode, der die Formularzuordnung (330) nutzt, um einen Datenstring mit dem Feld in dem elektronischen Formular zu verbinden, wo das vorbenannte Feld und das Feld in dem elektronischen Formular einander zugeordnet sind; und einem computerlesbaren Medium, das die Computercodes speichert.