DE60128676T2

DE60128676T2 - Verfahren und system zur automatisierung von internettransaktionen mittels gespeicherter daten

Info

Publication number: DE60128676T2
Application number: DE60128676T
Authority: DE
Inventors: Jai Sunnyvale RAWAT; Samir Sunnyvale PALNITKAR
Original assignee: America Online Inc
Current assignee: Historic AOL LLC
Priority date: 2000-04-28
Filing date: 2001-04-27
Publication date: 2008-01-24
Anticipated expiration: 2021-04-28
Also published as: WO2001084359A2; EP1852784A2; DE60128676D1; WO2001084359A3; EP1279116B1; CN100435141C; US20040068693A1; ATE363692T1; EP1279116A2; US6981028B1; US6662340B2; US20020156846A1; US20050256841A1; AU2001259162A1; JP2004501426A; CN1439133A

Description

1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft im Allgemeinen die Übertragung von Daten während des Browsens im Internet und im Besonderen ein Verfahren und ein System für das Implementieren aufgezeichneter Daten zur Automatisierung von Interaktionen und Transaktionen, die im Internet vorkommen.
2. Beschreibung des verwandten Standes der Technik
Heutzutage nutzen viele Computerbenutzer vorrangig Internet-Browseranwendungen für den Zugang zum World Wide Web (WWW oder Web) und für das Korrespondieren mittels elektronischer Post (E-Mail). Der typische Browser dient als das Mittel, mit dem ein Benutzer in die Lage versetzt wird, von Site zu Site im Web zu navigieren, und er dient weiterhin als Schnittstelle, über welche dem Benutzer eine Interaktion mit diesen Sites durch den Zugang zum Informationsinhalt und zu verschiedenen angebotenen Leistungen ermöglicht wird.
Während einer bestimmten Sitzung des Forschens im Internet oder des "Web-Surfens" ist es wahrscheinlich, dass ein Benutzer eine oder mehr Sites vorfindet, für die eine Registrierung erforderlich ist, ehe der Zugang zu den vollen Möglichkeiten der Sites möglich ist. In der Tat werden Sites, für die eine Registrierung erforderlich ist, von Tag zu Tag mehr. Websites für den elektronischen Handel (E-Commerce) erfordern zum Beispiel typischerweise eine Registrierung, ehe Käufe getätigt werden können oder ehe Artikel durch einen bestimmten Benutzer für die Auktion platziert werden können. Als weiteres Beispiel ist für Websites, die Host für E-Mail-Leistungen sind, unbedingt eine Registrierung erforderlich, um eingehende Korrespondenz an den richtigen Empfänger zu liefern.
Das Registrierungsverfahren kann eine unterschiedliche Komplexität aufweisen – vom sehr einfachen Eingeben von Daten in ein oder zwei Felder bis zur sehr komplizierten Frage der Bereitstellung einer Sozialversicherungsnummer, der Ablaufdaten von Kreditkarten und dergleichen. In jedem Fall muss ein Benutzer zur Registrierungsseite einer Site navigieren und ein Formular ausfüllen, indem die Informationen bereitgestellt werden, die für die Registrierung erforderlich sind. In der Praxis wird der Benutzer, unabhängig von der relativen Komplexität des Registrierungsverfahrens, mit der Aufgabe belastet, die Informationen aufzuzeichnen, die er bereitgestellt hat, oder sich diese zu merken. Das Mindesterfordernis für die Registrierung bei einer bestimmten Website ist die Bereitstellung eines Benutzernamens oder "Login"-Namens und eines Passworts an die Site. Diese Daten werden danach von der Site benutzt, um den Benutzer jedes Mal, wenn er sich einloggt, zu identifizieren; umgekehrt wird der Zugang zu einem bestimmten Benutzerkonto verweigert oder beschränkt werden, wenn beim Einloggen nicht die korrekten Benutzerkonto-Informationen eingegeben werden.
Darüber hinaus muss der Benutzer ebenfalls eine Aufzeichnung der Sites führen, für die das Registrierungsverfahren vorgenommen worden ist, oder er geht das Risiko ein, unbeabsichtigt mehrere Benutzerkonten bei derselben Site offen zu haben, was zum Durcheinander führen kann. Wenn ein Benutzer die Absicht hat oder es vorzieht, mehrere Benutzerkonten bei derselben Site gleichzeitig offen zu haben, obliegt es weiterhin diesem Benutzer, genaue Aufzeichnungen von Benutzernamen und Passwörtern zu führen, um Zugriff auf die verschiedenen Benutzerkonten zu haben.
Selbst in dem Fall, wenn ein Benutzer sorgfältige Aufzeichnungen aller benötigten Informationen führt, müssen der korrekte Benutzername und die Passwort-Informationen jedes Mal angegeben werden, wenn auf die Site zugegriffen wird. Typischerweise muss ein eingetragener Benutzer einer bestimmten Website zur "Login-Seite" der Site navigieren und ein Formular ausfüllen, indem er die erforderlichen Daten bereitstellt, um Zugriff auf die volle Funktionsvielfalt der Site zu haben. In dieser Hinsicht sind selbst genaue Aufzeichnungen nicht von Nutzen, wenn sie nicht zugänglich sind; wenn ein Benutzer zum Beispiel Registrierungsinformationen bequemerweise in der Nähe eines Home-Computers speichert, werden diese Aufzeich nungen nicht von Wert sein, wenn jener Benutzer versucht, Zugriff auf ein Benutzerkonto von einem Computer an einem anderen Ort zu nehmen, wie zum Beispiel einem Büro, einer Bibliothek oder einem Web-Café. Gegenwärtig sind selbst drahtlose Geräte internettauglich, so dass ein Benutzer-Zugang zum Web oder zu E-Mail-Benutzerkonten faktisch von überall aus haben kann. Wenn ein solcher Benutzer sich zahlreiche Benutzernamen und Passwörter nicht einprägt oder sich nicht bemüht, schriftliche Aufzeichnungen immer in Reichweite zu haben, können sich sorgfältige Aufzeichnungspraktiken letztendlich als von eingeschränkter Nützlichkeit erweisen.
Weiterhin fordern viele Websites Benutzer auf, Daten über das Verfahren des Ausfüllens von Formularen unabhängig von Registrierungs- oder Login-Verfahren zu liefern. Es wird oft von einem browsenden Benutzer verlangt, Informationen anzugeben, wie zum Beispiel Post-Adresse, Rechnungs-Adresse, Kreditkarteninformationen oder E-Mail-Adresse. Da Internet-Aktivität zunimmt und E-Commerce mit rasantem Tempo zunimmt, gibt es einen anhaltenden und eskalierenden Bedarf an einem zweckmäßigen und effizienten System für das Organisieren der Informationen zum persönlichen Benutzerkonto eines Benutzers und, was noch wichtiger ist, das Implementieren dieser Informationen während des Browsens im Web.
Ein solches System könnte die Tatsache berücksichtigen, dass viele Benutzer gegenwärtig Zugriff auf das Internet von mehreren Orten und mehreren Computerterminals oder Arbeitsplätzen aus nehmen, und der Prozentsatz von Benutzern, welche dies tun, wird sich in der Zukunft wahrscheinlich erhöhen. Darüber hinaus sollte, um für maximale Annehmlichkeit und Nützlichkeit zu sorgen, ein System, welches die Informationen zu einem Benutzerkonto eines Benutzers organisiert und implementiert, einen Großteil der Interaktion automatisieren, der gegenwärtig manuell vollzogen wird. Ein System des Standes der Technik wird in der WO19/46701 im Namen von Amazon.com Inc. gezeigt, welches ein Verfahren für das automatische Ausfüllen von Online-Formularen zeigt.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorliegende Erfindung wendet sich den vorstehenden und anderen Mängeln des Standes der Technik zu, indem sie ein System für die Automatisierung von vielen der lästigen Interaktionen bereitstellt, die von einem Benutzer während einer typischen Browsing-Sitzung im Internet verlangt werden.
Gemäß einer ersten Ausführungsform der Erfindung wird ein System nach Anspruch 1 bereitgestellt. Bei einer Ausführungsform schließt das System der vorliegenden Erfindung das Speichern der Informationen zum persönlichen Benutzerkonto eines registrierten Benutzers in einer sicheren, verschlüsselten zentralen Datenbank ein, auf die von jedem internettauglichen Gerät aus mit einem einzigen Benutzernamen und Passwort Zugriff genommen werden kann. Ein Benutzername und Passwort kann zum Beispiel in Verbindung mit einem Benutzerkonto bei einer bestimmten Website, zusammen mit dem Universal Resource Locator oder URL der Login-Seite jener Site gespeichert werden. Für ein zweites Benutzerkonto bei einer zweiten Website kann der Benutzer einen anderen Benutzernamen und ein anderes Passwort ausgewählt haben; diese Informationen werden gleichfalls in der zentralen Datenbank zusammen mit der URL für die Login-Seite der zweiten Website gespeichert. Beim Einloggen in das System der vorliegenden Erfindung hat der registrierte Benutzer Zugriff auf die vollen funktionellen Möglichkeiten der einzigartigen Schnittstelle, die vom System bereitgestellt wird, sowie zu sämtlichen Benutzerkonto-Informationen, die sich auf die verschiedenen spezifischen Website-Benutzerkonten jenes Benutzers beziehen. Idealerweise erfordert dieses System das Merken von lediglich einem einzigen Benutzernamen und lediglich einem einzigen Passwort, ungeachtet der Anzahl von spezifischen Benutzerkonten, die zu einem gegebenen Zeitpunkt bei einer Vielzahl von unterschiedlichen Websites unterhalten werden.
Im Besonderen betrifft die vorliegende Erfindung ein System, welches eine Schnittstelle zwischen der vorstehenden zentralen Datenbank und den verschiedenen Websites bereitstellt, die vom Benutzer während des Browsens im Internet besucht werden. Ein Dienstprogramm-Fenster oder ein Navigationsleiste können dem Standard-Browser-Navigationsfenster des Benutzers hinzugefügt werden, und sie können als Schnittstelle mit dem System und für den Zugriff auf dessen Möglichkeiten ge nutzt werden. Die Programmier-Scripts, die in einem solchen Dienstfenster verkörpert sind und über dieses aufgerufen werden, erweitern die Fähigkeiten des Standard-Browsers, indem sie viele der Aufgaben automatisieren, die normalerweise manuell durch den Benutzer ausgeführt werden.
Das System kann zum Beispiel separat für die Verwaltung einer riesigen Datenbank von herkömmlichen Websites, einschließlich der URL ihrer jeweiligen Registrierungsseiten sowie der Art und des Formats ihrer jeweiligen Registrierungsformulare angepasst werden. Zweckmäßige Hyperlinks können einem Benutzer über das vorstehende Dienstprogramm-Fenster angeboten werden, zum Beispiel beim Einloggen in das System, dergestalt, dass, wenn der Benutzer sich bei einer abgebildeten Website registrieren möchte, der im System verkörperte Programmcode mit der richtigen Site kommuniziert und die entsprechenden Teile des Registrierungsformulars ohne eine Intervention seitens des Benutzers ausfüllt. Darüber hinaus kann, wenn ein Benutzer sich bei einer Website registrieren möchte und selbständig zu der Seite navigiert, welche das Formular enthält, das System so angepasst werden, dass es erkennt, dass der Benutzer versucht, ein registriertes Benutzerkonto einzurichten, der zuvor nicht verzeichnet wurde, und es kann den Benutzer dazu veranlassen, die Registrierungsinformationen, falls gewünscht, aufzuzeichnen.
Weiterhin ist das Formularausfüllmerkmal der vorliegenden Erfindung nicht auf Registrierungsformulare beschränkt. Viele andere Arten von Formularen existieren im Internet-Universum, und die vorliegende Erfindung ist dafür geeignet, Zugriff auf aufgezeichnete Benutzerdaten zu erlangen und dieselben beim Ausfüllen von praktisch jeder Art von Formularen zu implementieren, auf welche ein Benutzer stoßen kann. Im Besonderen ist eine verbreitete Art eines Formulars, das regelmäßig ausgefüllt wird, ein Log-in-Formular.
Ein Benutzer kann sich schnell und problemlos in eine Website einloggen, ohne dass er erneut einen Benutzernamen und ein Passwort bei jedem nachfolgenden Besuch eingeben muss. Wie oben festgestellt wurde, kann die zentrale Datenbank einen speziellen Benutzernamen und ein Passwort speichern, das einem jeden Benutzerkonto zugeordnet ist, der vom Benutzer geführt wird; wenn der Benutzer Zugriff auf ein bestimmtes Benutzerkonto auf einer spezifischen Website haben möchte, navi giert die Schnittstelle der vorliegenden Erfindung zur korrekten Site unter Nutzung des Browsers, nimmt Zugriff auf den entsprechenden Benutzernamen und die Passwortinformationen aus der Datenbank, liefert diese an das Formular, welches auf der Login-Seite der Website präsentiert wird und legt das Formular automatisch vor, wodurch der Benutzer in das Benutzerkonto auf der Site eingeloggt wird. Darüber hinaus ist das System so angepasst, dass es erkennt, wenn ein Benutzer versucht, sich manuell in ein Benutzerkonto einzuloggen, der in der zentralen Datenbank noch nicht aufgezeichnet worden ist, und es veranlasst den Benutzer, die Informationen zum Benutzerkonto aufzuzeichnen, falls dies gewünscht wird. Der Benutzer wird dadurch von der Pflicht befreit, sich daran zu erinnern, welches Passwort welchem Benutzerkonto auf einer gegebenen Website zugeordnet ist.
Ein wichtiger Aspekt der vorliegenden Erfindung ist, dass ihr Betreiben nicht auf einen Ort oder auf einen bestimmten Computerterminal oder einen Arbeitsplatz beschränkt ist. Nach der ersten Registrierung beim System wird der Benutzer danach in die Lage versetzt, Zugriff auf seine Funktionsvielfalt von praktisch jedem internettauglichen Computerterminal aus zu haben.
Gemäß einer zweiten Ausführungsform der Erfindung wird ein Verfahren gemäß An- spruch 14 bereitgestellt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die oben erwähnten und andere Vorteile der vorliegenden Erfindung werden offensichtlicher werden bei der Prüfung der nachfolgenden detaillierten Beschreibung der bevorzugten Ausführungsformen derselben unter Bezugnahme auf die Zeichnungen. Es zeigt:
1 eine vereinfachte grafische, schematische Ansicht der Interaktion, die gegenwärtig zwischen einem Internet-Benutzer und mehreren Sites erforderlich ist, bei denen jener Benutzer eingetragene Benutzerkonten unterhalten kann.
2 eine vereinfachte grafische, schematische Ansicht der Interaktion, die zwischen einem Internet-Benutzer und mehreren Sites erforderlich ist, bei denen jener Benutzer eingetragene Benutzerkonten unterhalten kann, wobei das System der vorliegenden Erfindung als Vermittler fungieren kann.
3 eine vereinfachte Ansicht der Grafischen Benutzer-Schnittstelle, dargestellt durch eine gewöhnliche Web-Browser-Anwendung, die so modifiziert wird, dass sie eine Ausführungsform der Schnittstelle der vorliegenden Erfindung einschließt.
4 eine vereinfachte grafische, schematische Ansicht der Interaktion zwischen dem Zentralserver der vorliegenden Erfindung und mehreren E-Mail-Servern, bei denen ein Benutzer eingetragene Benutzerkonten unterhält.
5 eine vereinfachte Ansicht eines typischen Formulars, auf welches ein Benutzer während einer Browsing-Sitzung im Internet stoßen kann.
6 eine vereinfachte grafische, schematische Ansicht der Interaktion zwischen dem Zentralserver der vorliegenden Erfindung und einer Formularseite einer typischen Website.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Unter Bezugnahme auf die Zeichnungen zeigt 1 jetzt eine vereinfachte grafische, schematische Ansicht der Interaktion, die gegenwärtig zwischen einem typischen Internet-Benutzer und mehreren Sites erforderlich ist, bei denen jener Benutzer zumindest ein eingetragenes Benutzerkonto unterhalten kann. Herkömmlicherweise geht der Benutzer eine Verbindung mit dem Internet ein mit Hilfe eines Computerterminals 110, wie zum Beispiel einem Arbeitsplatzrechner oder einem Tisch-Personalcomputer (PC) oder einem Arbeitsplatz, einem Laptop, einem Notebook, einem Unter-Notebook oder einem Taschengerät, einem drahtlosen Taschengerät und dergleichen. Sobald er mit dem Internet verbunden ist, nimmt der Benutzer Zugriff auf E-Mail-Benutzerkonten und besucht Web-Server oder Sites, wie zum Beispiel diejenigen, die durch die Bezugszeichen 121 bis 125 dargestellt werden, mit Hilfe von einer oder mehr Softwareanwendungen, wie zum Beispiel einem Web-Browser. Im Verlauf des Besuchs der zahlreichen Sites, die den Rahmen des Internets bilden, wird der Benutzer oft aufgefordert, sich bei einer bestimmten Site einzutragen oder ein Benutzerkonto dort zu öffnen; die Registrierung dient sowohl dazu, es dem Web-Server zu ermöglichen, den Benutzer zu identifizieren als auch dazu, bestimmte Aspekte der Interaktion mit der Site für den Benutzer bei nachfolgenden Besuchen zu vereinfachen.
Sites, welche sich auf Auktionen, den Verkauf von Waren, serviceorientierte Geschäftstransaktionen und dergleichen über das Internet (E-Commerce) spezialisieren, machen es zum Beispiel oft erforderlich, dass ein Benutzer ein eingetragenes Benutzerkonto bei der Site unterhält, ehe es dem Benutzer gestattet werden kann, die auf der Site angebotenen Leistungen zu nutzen. Die Menge und die Art der Benutzerkonto-Informationen für einen bestimmten Benutzer, die bei einer gegebenen Site verwaltet werden, variieren beträchtlich, abhängig von der Art des vorgenommenen Geschäfts; einige Beispiele der Art von Informationen, die vom Benutzer während der Registrierung abgefordert werden, schließen ein: Vorname und Familienname, Geburtsdatum, Postanschrift, Geschlecht, Sozialversicherungsnummer, Kreditkartennummern und Ablaufdaten, Mädchenname der Mutter, und so weiter. Rechnungsanschriften und bevorzugte Versandadressen sind übliche Daten, die von E- Commerce-Sites, welche sich auf den Verkauf von Waren spezialisieren, abgefordert werden. In der Theorie bietet das Verwalten entsprechender Datenbanken solcher Informationen für einen eingetragenen Benutzer durch die Sites dem Benutzer Bequemlichkeit und Effizienz bei nachfolgenden Besuchen der Website.
In der Praxis erlegt die Registrierung bei Websites jedoch dem Benutzer eine erhebliche Bürde auf. Die Bereitstellung von erforderlichen oder geforderten Informationen an die Site involviert im Allgemeinen das Ausfüllen und Vorlegen eines Formulars. Das Ausfüllen dieser Formulare ist beschwerlich, und es bringt unvermeidlich die Möglichkeit von Fehlern mit sich, wie zum Beispiel falsche Schreibweisen oder die Vertauschung von Zahlen, bei jeder Vorlage. Darüber hinaus obliegt es, sobald das Formular vorgelegt worden ist und der Registrierungsvorgang abgeschlossen ist, dem Benutzer, sich an den Benutzernamen und an das Passwort zu erinnern, die erforderlich sind, um Zugriff auf das eingetragene Benutzerkonto zu erhalten.
Wenn man sich 1 genauer ansieht, ist der Effekt der Unterhaltung eines Benutzerkontos durch den Benutzer bei einer Vielzahl von Sites offensichtlich. Die Registrierung bei einer Website, wie zum Beispiel die Sites 121-125 in 1, erfordert als Minimum die Erstellung eines Benutzerkontos, zu dem der Zugriff nur durch die Angabe des korrekten Benutzernamens und des Passworts während des Einloggens möglich ist. Das heißt, für den Zugriff auf den vollen Bereich von Leistungen, die bei einer bestimmten Site bei nachfolgenden Besuchen bereitgestellt werden, ist es erforderlich, dass ein Benutzer über einen Computerterminal 110 den Benutzernamen und das Passwort eingibt, die ursprünglich während des Registrierungsverfahrens ausgewählt wurden.
Wie sich aus der Betrachtung von 1 ergibt, muss ein Benutzer, der ein separates Benutzerkonto bei jeder der Sites 121 bis 125 hat, genaue Aufzeichnungen von zumindest fünf separaten Benutzernamen und Passwörtern führen. Bestimmte dieser Benutzernamen und Passwörter können zwar für mehr als ein Benutzerkonto genutzt werden, jedoch sind Benutzer oft der Meinung, dass ein unterschiedlicher Benutzername und ein unterschiedliches Passwort für jedes Benutzerkonto aus Sicherheitsgründen vorzuziehen sind.
Während einer typischen Browsing-Sitzung im Web kann es sein, dass ein Benutzer den Wunsch hat, sich bei einem eingetragenen Benutzerkonto bei einer bestimmten Website einzuloggen, wie zum Beispiel Site 121 in 1. Um sich auf Site 121 einzuloggen, muss der Benutzer zunächst zur korrekten Login-Seite navigieren, die der Site 121 zugeordnet ist. Beim Eintreffen an der Login-Seite wird dem Benutzer ein Login-Formular vorgelegt, in welches der Benutzer den korrekten Benutzernamen und das Passwort eingeben muss, um Zugriff auf das Benutzerkonto zu erhalten. Wenn das Formular ausgefüllt und vorgelegt worden ist, wird der Benutzer in das entsprechende Benutzerkonto bei Site 121 eingeloggt. Wenn der Benutzer dann den Wunsch hat, sich bei einem anderen eingetragenen Benutzerkonto einzuloggen, der sich bei einer anderen Website befinden kann, wie zum Beispiel Site 122 in 1, muss die obige Verfahrensweise bei der entsprechenden Login-Seite für Site 122 wiederholt werden.
In dem Falle, wenn ein Benutzer nicht bei einer speziellen Site registriert ist, wie zum Beispiel Site 123 in 1, kann vom Benutzer verlangt werden, dass er sich registrieren lässt, ehe er die verfügbaren Leistungen in vollem Umfang nutzt. Für die Registrierung bei Site 123 muss der Benutzer zunächst zur korrekten Registrierungsseite navigieren, die der Site 123 zugeordnet ist. Beim Eintreffen bei der Registrierungsseite wird dem Benutzer typischerweise ein Formular vorgelegt, in welches der Benutzer eine große Anzahl von Registrierungsinformationen eingeben muss, um ein Benutzerkonto zu erstellen. Wenn das Formular ausgefüllt und vorgelegt worden ist, kann sich der Benutzer danach bei dem neu erstellten Benutzerkonto einloggen, zum Beispiel in der oben beschriebenen Art und Weise.
Auf jeden Fall müssen Benutzerkontodaten zwischen dem Terminal 110 des Benutzers und den verschiedenen Sites 121 bis 125 jedes Mal übertragen werden, wenn sich der Benutzer bei einem bestimmten Benutzerkonto einloggen möchte; diese Datenübertragungsinteraktionen werden durch die Pfeile in 1 dargestellt. Die Interaktion zwischen dem Benutzer und der Website, die im Namen der "Zweckmäßigkeit" erforderlich ist, ist letztendlich lästig, und sie notwendigerweise der Entstehung von Fehlern ausgesetzt. Weiterhin sind, wie oben festgestellt wurde, die Daten, welche während des Registrierungs- und Einlog-Verfahrens erforderlich sind, typischerweise einmalig für jedes Benutzerkonto, was es erforderlich macht, dass der Benut zer sich diese Daten merkt oder dass er sie an einem leicht erreichbaren, jedoch sicheren Ort aufzeichnet.
2 ist eine vereinfachte grafische, schematische Darstellung der Interaktion, die zwischen einem Internetbenutzer und dem System der vorliegenden Erfindung erforderlich ist, welches als ein Vermittler zwischen dem Benutzer und den verschiedenen Sites fungiert, bei denen jener Benutzer eventuell eingetragene Benutzerkonten unterhält. Wie in 2 veranschaulicht wird, entspricht der Computerterminal 210 des Benutzers dem in 1 veranschaulichten Computerterminal 110. Wie oben erörtert wurde, kann dieser Computerterminal 210 jede Art von internetfähigem Gerät sein. Ein wichtiger Aspekt ist, dass das Verfahren oder die Mittel, mit deren Hilfe der Computerterminal 210 mit dem Internet verbunden ist, nicht von Bedeutung sind. Die Verbindung kann über die traditionelle "Einwahl" eines drahtgebundenen Telefons, über Digitale Teilnehmerschaltung (DSL), über Lichtwellenleiter- oder Kabelmodemverbindungen, drahtlose oder Satellitenkommunikation, T-1, T-3, ISDN, Netz und dergleichen hergestellt werden.
Sobald die Verbindung zum Internet, unabhängig vom Verfahren, hergestellt worden ist, kann der Benutzer eine Softwareanwendung einsetzen, wie zum Beispiel einen auf dem Computerterminal 210 installierten Web-Browser, um zum Beispiel zu einer Website zu navigieren, welche Host für einen zentralisierten Server und Datenbank ist, wie zum Beispiel durch Bezugszeichen 299 angegeben wird. Bei den verschiedenen Ausführungsformen der vorliegenden Erfindung kann der Benutzer ein eingetragenes Benutzerkonto beim zentralen, Webgestützten Server 299 öffnen. Dieses Registrierungsverfahren erfordert, wie bei typischen Website-Registrierungen, dass der Benutzer einen Benutzernamen und ein Passwort für Identifizierungs- bzw. Sicherheitszwecke auswählt. Nach der Registrierung beim Zentralserver 299 kann sich der Benutzer beim eingetragenen Benutzerkonto bei nachfolgenden Besuchen einloggen, indem er das Login-Formular mit dem korrekten Benutzernamen und Passwort ausfüllt und vorlegt. Die vorstehenden Verfahrensweisen unterscheiden sich nicht wesentlich von den typischen Registrierungs- und Einlog-Verfahrensweisen, die für normale Websites erforderlich sind. Die vorliegende Erfindung sorgt für wesentliche Vorteile hinsichtlich von Bequemlichkeit und Dienstprogramm, jedoch nachdem sich der Benutzer beim eingetragenen Benutzerkonto beim Zentralserver 299 eingeloggt hat.
Zum Beispiel ist es, wie in 2 veranschaulicht wird, erforderlich, dass sich der Benutzer lediglich einmal während einer bestimmten Browsing-Sitzung im Web beim Zentralserver 299 einloggt; nachfolgende Verfahrensweisen des Formularausfüllens und Einloggens bei verschiedenen anderen Sites erfordern wenig oder keine Interaktion seitens des Benutzers. Datenübertragungsinteraktionen werden durch die Pfeile in 2 dargestellt. Hinsichtlich der Verfahrensweisen des Formularausfüllens oder der Registrierung kann der Zentralserver 299 zum Beispiel alle Dateneingaben handhaben und Formulare automatisch ausfüllen; und für den Benutzer ist es lediglich erforderlich, die Informationen auf Genauigkeit zu prüfen und das ausgefüllte Formular vorzulegen. Was nachfolgende Einlog-Verfahrensweisen für eingetragene Benutzerkonten bei anderen Web-Servern, wie zum Beispiel 221 bis 225, betrifft, kann der Zentralserver 299 die Navigation, die Dateneingabe und die Aufgaben des Vorlegens des Login-Formulars automatisch handhaben und den Benutzer bei einem gewünschten Benutzerkonto bei einer bestimmten Website einloggen, wobei praktisch keine Aktion seitens des Benutzers erforderlich ist.
Der Zentralserver 299 ist dafür geeignet, für den Benutzer eine detaillierte Datenbank zu verwalten, einschließlich einer großen Vielfalt von persönlichen, vom Benutzer gelieferten Informationen. Die aufgezeichneten Daten können sowohl allgemeiner Art sein als auch benutzerkontenspezifisch. Allgemeine oder globale Informationen können zum Beispiel Vor- und Familiennamen, erste Rechnungsanschrift und Sozialversicherungsnummer und dergleichen einschließen; diese Informationen sind typischerweise konstant, ungeachtet der Website, bei der ein Benutzerkonto verwaltet wird. Beispiele von benutzerkontospezifischen Informationen können den Namen und das Passwort des Benutzers einschließen, die URL der Login-Seite für das Benutzerkonto, das Lieblingsgenre der Literatur und dergleichen; diese Informationen können entsprechend den Informationen variieren, die am relevantesten für die spezielle Site sind, bei welcher das Benutzerkonto geführt wird.
Es ist von Wichtigkeit, dass die bei der Datenbank aufgezeichneten vorstehenden allgemeinen und benutzerkontenspezifischen Informationen leicht zugänglich für den Benutzer sind, über das Einloggen beim Zentralserver 299, und dass sie zu geeigneten Zeitpunkten automatisch mittels der Funktionsvielfalt des Systems übertragen werden können, wie nachstehend im Detail dargelegt wird. In dieser Hinsicht werden der Benutzername und das Passwort, welche dem eingetragenen Benutzerkonto des Benutzers beim Zentralserver 299 zugeordnet sind, global; es ist lediglich erforderlich, dass sich der Benutzer diese zwei Informationspositionen merkt, um es dem System der vorliegenden Erfindung, über den Zentralserver 299, zu ermöglichen, als eine Schnittstelle mit dem übrigen Internet-Universum zu dienen. Der Benutzer wird somit von der Bürde befreit, sich zum Beispiel die URL der Login-Seite einer Site zusammen mit dem Benutzernamen und dem Passwort zu merken, die für ein bestimmtes Benutzerkonto bei jeder Site ausgewählt wurden.
Bei einer Ausführungsform der vorliegenden Erfindung wird eine einmalige Schnittstelle für den Zugriff auf die Funktionsvielfalt des Systems bereitgestellt. 3 ist eine vereinfachte Ansicht der Grafik-Benutzerschnittstelle (GUI), die von einer normalen Web-Browseranwendung bereitgestellt wird, die so modifiziert wurde, dass sie die erweiterte Schnittstelle der vorliegenden Erfindung einschließt. Eine herkömmliche Web-Browseranwendung liefert dem Benutzer eine GUI 310, über welche die Interaktion mit dem Internet ermöglicht wird. Bei einer Standardausführung kann die GUI 310 eine Menüleiste 311 für die Interaktion mit der Browsersoftware einschließen, eine Steuerleiste 312 für die Navigation, die Datenverwaltung und für andere Zwecke, und ein Textkästchen 313 für die Eingabe von Text, wie zum Beispiel die URL einer gewünschten Website. Diese Elemente sind auf dem Fachgebiet üblich. Das primäre Element der GUI 310 des Browsers ist das Navigations-Fenster 314, in welchem der Inhalt der verschiedenen Websites und Seiten angezeigt wird; der Website-Inhalt schließt zum Beispiel ein: Text, Video, Hyperlinks zu anderen Websites und interaktive Formulare, die ausgefüllt und eingereicht werden müssen.
Wie unten bei 3 zu sehen ist, schließt die GUI 310 des Web-Browsers, die gemäß der vorliegenden Erfindung modifiziert ist, ein Dienstprogramm-Fenster 350 ein, welches dem Navigationsfenster 314 beigefügt ist. Bei dieser Ausführungsform dienst das Dienstprogramm-Fenster 350 als Schnittstelle für den Zugriff auf die verschiedenen Fähigkeiten des Systems; der erforderliche Code für das Erweitern der Fähigkeiten des Browsers, um das Dienstprogramm-Fenster 350 einzuschließen, kann zum Beispiel automatisch bei der Registrierung beim Zentralserver 299 von 2 heruntergeladen und in den Computerterminal 210 des Benutzers installiert werden. Als Alternative kann die Browser-Software unabhängig vom Registrierungsverfahren modifiziert werden, wie zum Beispiel nachdem der Benutzer schon ein eingetragenes Benutzerkonto hat und Zugriff auf jenes Benutzerkonto von einem Computer aus nehmen möchte, bei dem die Software für das Dienstprogramm-Fenster 350 noch nicht installiert worden ist.
Typische Web-Browser-Softwareanwendungen unterstützen eine solche Einfügung eines Dritt-Softwarecodes, welcher die Fähigkeiten des Browsers oder der GUI 310 erweitert. Diese Unterstützung ermöglicht es einem Programmierer, Standardprogrammierungsverfahren einzusetzen, die zum Beispiel in JavaScript^® oder in anderen Programmierungssprachen verkörpert sind, um den Originalcode der Browser-Software in beschränktem Maße zu modifizieren, einschließlich der Hinzufügung von Funktionselementen zur GUI 310, wie zum Beispiel das Dienstprogramm-Fenster 350 der vorliegenden Erfindung. Der Code kann so geschrieben werden, dass er bestimmte Ereignisse erkennt, wie zum Beispiel, wenn das Navigations-Fenster 314 vom Benutzer verlegt worden ist, die Größe neu bestimmt worden ist oder dieses maximiert worden ist. Bei dieser Ausführungsform kann das Dienstprogramm-Fenster 350 dem Navigations-Fenster 314 rund um den Computerdisplay des Benutzers "folgen", wobei seine Größe bei jedem jeweiligen Ereignis entsprechend geändert wird oder es verlegt wird. Als Alternative kann das Dienstprogramm-Fenster 350 so angepasst werden, dass es stationär ist, unabhängig von Größenänderungs- oder Verlegungsereignissen, die mit der normalen Nutzung des Navigations-Fensters 314 des Browsers verbunden sind. Alternativ kann der Originalcode der Browser-Software so modifiziert werden, dass das Dienstprogramm-Fenster 350 im Inneren der Browser-GUI 310 selbst eingebettet werden kann.
Wie in 3 aufgezeigt ist, kann das Dienstprogramm-Fenster 350 eine Vielzahl von Bedienungstasten 351 oder Drop-down-Menüs 352 einschließen, mit Hilfe derer der Benutzer zum Beispiel Zugriff auf die verschiedenen Funktionen, die vom System unterstützt werden, haben kann. Die spezielle in 3 veranschaulichte Gestaltung ist lediglich als Beispiel gezeigt; die vom Dienstprogramm-Fenster 350 unterstützten Funktionen, die Weise, in der die Funktionen durch die Einbeziehung der Tasten 351 oder der Drop-down-Menüs 352 angezeigt werden, und selbst die Position des Dienstprogramm-Fensters 350 in Bezug auf das Navigations-Fenster 314 können für verschiedene Anwendungen oder Präferenzen in geeigneter Weise verändert werden. In dieser Hinsicht ist es vorzuziehen, dass die Funktionsvielfalt des Dienstprogramm-Fensters 350 durch den Programmcode auf dem Zentralserver 299 und nicht auf dem Computerterminal 210 des Benutzers selbst unterstützt wird.
Den Fachleuten wird es bekannt sein, dass das Anfügen des Dienstprogramm-Fensters 350 an das Navigations-Fenster 314 eine Frage des Einfügens eines kleinen Programmcodes, wie zum Beispiel eines einfachen Scripts, zum Beispiel in die Browser-Software ist. Wenn die zugrunde liegende Funktionsvielfalt der Schnittstelle, die über das Dienstprogramm-Fenster 350 zugänglich ist, in den auf dem Gerät des Benutzers installierten Code eingebettet würde, würde es dann jedoch dem Benutzer obliegen, Weiterentwicklungen und Aktualisierungen des Codes herunterzuladen und zu installieren. Die Installation einer vollständig neuen oder aktualisierten Version des Dienstprogramm-Fensters 350 selbst wäre für jeden Computerterminal, wie zum Beispiel 210 bei 2, erforderlich, von dem aus Zugriff auf das System genommen wird. Das System der vorliegenden Erfindung ist jedoch dergestalt vereinfacht, dass der auf dem Computerterminal 210 installierte Code lediglich die Browser-Software modifiziert, um das Dienstprogramm-Fenster 350 zu schaffen, und in einigen Fällen die oben beschriebene "Folge"-Funktion unterstützt. Die wirkliche Funktionsvielfalt der Schnittstelle wird jedoch andererseits beim Programmieren beim zentralen Webgestützten Server 299 bereitgestellt, und sie wird in das Dienstprogramm-Fenster 350 bei jedem Einloggen in das System lediglich importiert.
Wie oben festgestellt wurde, dient das Dienstprogramm-Fenster 350 als Vorfeld-Schnittstelle zwischen dem Benutzer und dem System; das System stellt seinerseits eine Schnittstelle zwischen dem Zentralserver 299 aus 2 und den verschiedenen Sites bereit, die durch den Benutzer besucht werden, indem es bestimmte lästige Aufgaben automatisiert, auf die man gemeinhin während des Browsens im Web stößt. Im Besonderen ist die Funktionsvielfalt, welche vom System bereitgestellt wird, im Wesentlichen wie folgt: effektives universelles Internet-Identitäts- und E-Mail-Filtern; automatisches Formularausfällen für faktisch jedes Formular, welches während des Browsens im Web angetroffen wird; und automatisches Einloggen bei Sites, wo ein eingetragenes Benutzerkonto geführt wird. Diese funktionellen Aspekte des Systems werden nachstehend im Detail angesprochen.
Wie oben unter Bezugnahme auf 2 vermerkt wurde, hat der Benutzer nach der Registrierung beim Zentralserver 299 einen effektiven universellen Benutzernamen und ein Passwort. Sobald er sich in das eingetragene Benutzerkonto beim Zentralserver 299 eingeloggt hat, ist es nicht erforderlich, dass der Benutzer sich zusätzliche Passwörter oder andere Informationen merkt, die eventuell an die verschiedenen Websites 221-225 für die Registrierung oder für die Verwaltung eines Benutzerkontos bei diesen weitergegeben wurden. Die benötigten Informationen werden auf dem Zentralserver 299 gespeichert und sind leicht zugänglich für den Benutzer, sobald er sich in das System eingeloggt hat. Zusätzlich zu der Befreiung von der Last, sich an eine überwältigende Menge von Informationen zu erinnern und diese zu organisieren, ist ein weiterer Vorteil für den Benutzer des Systems der vorliegenden Erfindung, dass der universelle Benutzername und das Passwort das E-Mail-Filtern erleichtern.
4 ist eine vereinfachte grafische, schematische Ansicht der Interaktion zwischen dem Zentralserver 499 der vorliegenden Erfindung und mehreren E-Mail-Servern 481 bis 483, bei denen ein Benutzer eingetragene Benutzerkonten unterhält. Der Zentralserver 499 entspricht demjenigen, der durch das Bezugszeichen 299 in 2 dargestellt wird, und der Computerterminal 410 des Benutzers entspricht demjenigen, der durch das Bezugszeichen 210 in 2 dargestellt wird. Verschiedene Websites 421-425 werden in 4 zusammen mit einer Vielzahl von E-Mail-Servern, als Server 481 bis 483 bezeichnet, gezeigt. Die E-Mail-Server 481 bis 483 können zum Beispiel einem Heim-E-Mail-Benutzerkonto, einem Schul-E-Mail-Benutzerkonto bzw. einem Arbeits-E-Mail-Benutzerkonto eines Benutzers entsprechen. Es versteht sich, dass ein Benutzer mehr oder weniger als drei E-Mail-Benutzerkonten unterhalten kann, und weiterhin, dass mehr als ein E-Mail-Benutzerkonto bei einem einzigen E-Mail-Server unterhalten werden kann, und dementsprechend wird die Anordnung von 4 lediglich beispielhaft veranschaulicht.
Gemäß einer Ausführungsform der vorliegenden Erfindung kann ein Benutzer eine universelle "virtuelle" E-Mail-Adresse nach der Registrierung beim Zentralserver 499 erhalten. Diese universelle E-Mail-Adresse wird als virtuell gekennzeichnet, da das System in der Tat eventuell kein E-Mail-Benutzerkonto mit vollem Service für den Benutzer beim Zentralserver 499 verwaltet, sondern vielmehr nur dazu dient, eintreffende Mail an einen oder mehr einer Vielzahl von eingetragenen E-Mail-Benutzer konten bei einem oder mehr einer Vielzahl von durch den Benutzer benannten E-Mail-Servern weiterzuleiten. Zum Beispiel kann eine E-Mail, die zur universellen virtuellen E-Mail-Adresse beim Server 499 übermittelt wird, selektiv ausschließlich zu einem einzigen Benutzerkonto beim E-Mail-Server 481 weitergeleitet werden, oder sie kann selektiv zu einem oder mehr eingetragenen Benutzerkonten bei allen E-Mail-Servern 481 bis 483 weitergeleitet werden. In jedem Fall werden die Freunde des Benutzers, seine Verwandten, seine Geschäftskontakte und andere, welche das gesamte Internet-Universum repräsentieren, alle elektronischen Briefwechsel zu einer einzigen Adresse beim Zentralserver 499 senden, von wo sie nach dem Belieben des Benutzers geleitet werden können.
Zusätzlich zu der einfachen Weiterleitung der eingehenden E-Mail an ein Benutzerkonto, das bei fernen E-Mail-Servern 481 bis 483 verwaltet wird, kann die eingehende Post syntaktisch analysiert werden, um zum Beispiel ihren Ursprung zu bestimmen. Auf diese Weise kann E-Mail, die in einer bestimmten Domain ihren Ursprung hat, zum Beispiel an ein erstes Benutzerkonto weitergeleitet werden, der vom Benutzer angegeben wird, während E-Mail, die ihren Ursprung in einer anderen Domain hat, an einen zweites angegebenes Benutzerkonto weitergeleitet werden kann.
Es versteht sich, dass das Dienstprogramm einer solchen universellen virtuellen E-Mail-Adresse durch das zusätzliche Merkmal erleichtert wird, dass es dem Benutzer gestattet wird, bestimmte Optionen zu handhaben, wie zum Beispiel die E-Mail-Adresse oder E-Mail-Adressen, an welche eingehende E-Mail weitergeleitet werden sollte und die Bedingungen, unter denen eine solche Weiterleitung gewünscht wird. Nach dem Einloggen beim Zentralserver 499 kann dem Benutzer zum Beispiel voller Zugriff gewährt werden, um die angegebenen Adressen zu ändern oder um den Bestimmungsort einer E-Mail, die aus einer bestimmten Domain stammt, neu zu bestimmen; da die Weiterleitungsadressen beim Zentralserver 499 geändert werden können, wird der Benutzer somit von der Last befreit, alle Internetkontakte von einer Änderung beim Internet-Serviceprovider (ISP) oder von einem anderen Ereignis zu informieren, welches eventuell eine Änderung bei der E-Mail-Adresse nötig machen kann. Idealerweise kann es dem Benutzer ermöglicht werden, die Annahme bestimmter unverlangter E-Mail ("Spam") schlankweg abzulehnen, dergestalt, dass alle Mail, die von einem bestimmten Ort ausgeht, zum Beispiel an den Absender zurückgesandt wird oder in der Zukunft anderweitig abgelehnt wird.
Diese E-Mail-Präferenzen können als ein Benutzerprofil-Datenbank-Datensatz gespeichert werden, verbunden mit einer bestimmten universellen virtuellen E-Mail-Adresse beim Zentralserver 499. Der eingetragene Benutzer kann in der Lage sein, den Programmcode aufzurufen, welcher auf diese Daten zugreift und deren Änderung über das Dienstprogramm-Fenster 350 gestattet, welches oben unter Bezugnahme auf 3 erörtert wurde.
Die vorstehende Funktionsvielfalt kann mittels des Programmcodes beim Zentralserver 499 implementiert werden. Beim Betrieb kann eingehende E-Mail, die an eine universelle virtuelle E-Mail-Adresse eines Benutzers adressiert ist, beim Eintreffen beim Zentralserver 499 syntaktisch analysiert werden; Vorsätze mit dem Ursprung und der Bestimmungsadresse von E-Mail-Paketen werden üblicherweise durch E-Mail-Server dergestalt syntaktisch analysiert, dass eine ordnungsgemäße Zustellung von elektronischem Briefwechsel möglich ist. Gemäß dieser Ausführungsform der vorliegenden Erfindung können die syntaktisch analysierten Daten jedoch zusätzlich mit den Benutzerpräferenzen verglichen werden, die der universellen virtuellen E-Mail-Adresse zugeordnet sind, welche in der Datenbank beim Zentralserver 499 gespeichert ist, und die Adressen-Vorsätze können entsprechend geändert werden. Nach dem Abschluss des Vergleichens und der Änderung der Adressen-Vorsätze kann die E-Mail an die vom Benutzer angegebene Adresse weitergeleitet werden.
Websites fordern oft dazu auf, dass ein mit Browsing beschäftigter Benutzer Informationen liefert, und viele der populärsten Websites, besonders diejenigen, die im E-Commerce tätig sind, verlangen dies in der Tat. Die Folge ist, dass ein Benutzer oft vor der lästigen Aufgabe steht, während einer gegebenen Browsing-Sitzung im Web Formulare auszufüllen. 5 ist eine vereinfachte Ansicht eines typischen Formulars 580, welches von einem Benutzer während einer Browsing-Sitzung im Internet angetroffen werden kann.
Zusätzlich zu dem Formular 580 selbst zeigt 5 ebenfalls die gesamte Browser-GUI 510, komplett mit dem Standardmenü 511, der Steuerleiste 512, dem Textkästchen 513 und dem Navigations-Fenster 514, in welchem das Formular 580 gezeigt wird. Die GUI 510, die in 5 gezeigt wird, ist so modifiziert worden, dass sie das Dienstprogramm-Fenster 550 einschließt, über welches auf die verschiedenen Funktionen, die beim Zentralserver gestützt werden, wie zum Beispiel Server 299 oder 499, Zugriff genommen werden kann. Im Besonderen schließt das Dienstprogramm-Fenster 550 zumindest eine Bedienungstaste, wie zum Beispiel Taste 555 ein, welche den Zugriff auf das automatische Formularausfüllmerkmal der vorliegenden Erfindung ermöglicht. Als Alternative kann der Zugriff auf das automatische Formularausfüllmerkmal ebenfalls durch andere Mittel als eine Taste ermöglicht werden, zum Beispiel durch ein Drop-down-Menü wie 556.
Es versteht sich, dass das spezielle Formular 580, welches in 5 veranschaulicht wird, lediglich repräsentativ ist; es kann sein, dass selbst Formulare, die zur Angabe identischer Daten auffordern, die Vorlage dieser Daten in anderen Formaten benötigen. Das Feld "Name" 581 kann so unterteilt werden, dass ein anderes Formular die gleichen Daten in drei verschiedenen Feldern abfragt, welche dem Familiennamen, dem Vornamen und dem Mittelnamen entsprechen. Gleichfalls kann das Feld "Telefon" 582 in drei verschiedene Felder unterteilt werden, welche der Vorwahlnummer, der Vermittlungsnummer und den letzten vier Zahlen entsprechen; und ein viertes Feld kann für eine Durchwahlnummer eingefügt werden. In gleicher Weise schließen verschiedene Formulare zusätzlich Drop-down-Menüs oder Funktasten ein, wobei der Benutzer aufgefordert wird, zum Beispiel einen Altersbereich, eine Beschäftigung oder einen Titel oder eine bevorzugte Kreditkartenart aus einer eingeschränkten Liste auszuwählen.
Wie oben beschrieben, führt das System der vorliegenden Erfindung detaillierte Datensätze von Informationen, die von einem Benutzer während des Registrierungsverfahrens und nach der Registrierung übermittelt werden, nach dem Ermessen des Benutzers. Das heißt, wenn ein Benutzer ein eingetragenes Benutzerkonto beim Zentralserver erstellt, erstellt der Server einen Datenbank-Datensatz für jenen Benutzer; verschiedene Benutzerdaten können zurückgehalten werden. Der Server kann Informationen vom Benutzer in einem Format, das so körnig wie möglich ist, abfordern, das heißt Telefonnummern können zum Beispiel in zumindest vier Felder aufgeteilt werden, welche der Landesvorwahl, der Ortsvorwahl, der vollständigen Telefonnummer und der Anschlussnummer entsprechen. Als weiteres Beispiel können Namen beim Server in einem Format als Vorname, Mittelname, Familienname anstatt in einem einzigen Feld gespeichert werden. Auf diese Weise kann das System der vorliegenden Erfindung so angepasst werden, dass es Daten an verschiedene Formulare übermittelt, die Daten in einem von zahlreichen Formaten benötigen.
Als Hintergrund sind die Formulare, auf die man beim Suchen im Web stößt, codiert in den Hypertext-Markup-Language (HTML)-Dokumenten oder -Seiten, die vom Benutzer während des Browsens besucht werden. Jede gegebene HTML-Seite kann ein oder mehr Formulare enthalten, die sich in dem zugrundeliegenden HTML-Code unterscheiden. Das System der vorliegenden Erfindung nutzt den Programmcode beim Zentralserver, um die HTML-Seiten syntaktisch zu analysieren, wenn der Browser des Benutzers von Seite zu Seite navigiert. Der Programmcode ist geeignet für das Identifizieren von Text-Strings im HTML-Code, die darin eingebettete Formulare repräsentieren; jedes Formular enthält ein oder mehr "Meta-Typen", die vom System erkannt werden können. Jeder Meta-Typ repräsentiert einen logischen Datenblock, der ein oder mehr Informationsfelder umfasst, die auf sinnvolle Weise in logischer Beziehung stehen. Jedem Informationsfeld ist wiederum ein spezielles Format zugeordnet. Die vorstehende Hierarchie von Formularkomponenten unterstützt das System bei der Zuordnung der körnigen Benutzerdaten zur korrekten Stelle im Formular während des Formularausfüllprozesses.
In dieser Hinsicht versteht es sich, dass die Einstufung von verschiedenen Typen von Daten nach dem Meta-Typ das System in die Lage versetzt, die Aufgabe des Ausfüllens von Formularen in einer effizienten Weise anzugehen, welche indirekte Systemkosten und Unbequemlichkeiten für den Benutzer minimiert. Entweder vor dem oder während des Formularausfüllprozesses kann zum Beispiel jeder Meta-Typ in seiner Gesamtheit, zusammen mit den spezifischen Daten, die für das Ausfüllen seiner Felder verwendet wurden, unabhängig ausgewählt werden; das heißt, der Benutzer kann Drop-down-Menüs oder andere GUI-Einrichtungen, die im Dienstprogramm-Fenster bereitgestellt sind, einsetzen, um aus einer Vielzahl von zuvor ge speicherten Daten innerhalb eines gegebenen Meta-Typs auszuwählen. Die Schnittstelle im Dienstprogramm-Fenster kann für eine solche Auswahl durch das Einfügen eines Drop-down-Menüs zum Beispiel für jeden Meta-Typ angepasst werden.
Die Datenbank beim Zentralserver kann eine Vielzahl von Daten-"Profilen" für jeden Meta-Typ verzeichnen; jedes Profil kann durch einen einmaligen Spitznamen identifiziert werden und ist über die Dienstprogrammfenster-Schnittstelle zugänglich. Der Benutzer kann zum Beispiel zwei Kreditkartenprofile mit dem Spitznamen "Kreditkarten" und "Kreditkarte2" als Kreditkarten-Meta-Typen oder zwei Versandadressen mit dem Spitznamen "Wohnung" und "Arbeitsstätte" als Versandadressen-Meta-Typen registrieren. Die Auswahl eines speziellen Profils aus der Schnittstelle im Dienstprogramm-Fenster bewirkt, dass alle Daten, die diesem Profil zugeordnet sind, im korrekten Feld in einem Formular eingefügt werden, bei dem einige oder alle der Daten aus diesem Meta-Typ abgefordert werden.
Wenn dem Benutzer ein Formular zum Ausfüllen vorgelegt wird, kann er die Daten, welche für die einzelnen Meta-Typen für Rechnungsadresse, Kreditkarte und Versandadresse genutzt werden sollen, selbständig auswählen. Gleichfalls können, wenn dem Benutzer ein ausgefülltes Formular zur Bestätigung vorgelegt wird, die Daten, die einem gesamten Meta-Typ zugeordnet sind, durch die Auswahl eines anderen Profils in der Dienstprogrammfenster-Schnittstelle geändert werden, während der Rest des ausgefüllten Formulars unverändert belassen wird. Wenn ein Formular zum Beispiel mit einer gewünschten Rechnungsadresse und Kreditkarteninformation ausgefüllt worden ist, der Benutzer sich jedoch dafür entscheidet, die Versandadresse vor der Vorlage des Formulars zu ändern, gestattet es eine Option in der Schnittstelle dem Benutzer, eine Auswahl aus einem einer Vielzahl von zuvor registrierten Versandadressen-Profilen zu treffen. Gleichfalls kann der Benutzer in die Lage versetzt werden, aus einer von einer Vielzahl von zuvor registrierten Versandadressen oder Kreditkarten auszuwählen.
Angesichts der oben beschriebenen Hierarchie, und wenn man sich das Formular 580 von 5 genauer betrachtet, versteht es sich, dass die verschiedenen Felder, die bei einem bestimmten Formular benötigt werden, wie zum Beispiel die Felder 581 bis 588, vom System der vorliegenden Erfindung als verwandte Daten erkannt wer den können. Das Feld "Adresse" 583, das Feld "Stadt" 584, das Feld "Staat" 585 und das Feld "Postleitzahl" 586 können zum Beispiel gemeinsam einem Adressen-Meta-Typ zugeordnet werden, da diese logisch verwandten Felder alle erforderlich sind, um eine spezielle Postanschrift zu definieren. Gleichfalls können das Feld "Kreditkartennummer" 587 und das Feld "Ablaufdatum" 588 in einem Kreditkarten-Meta-Typ kombiniert werden. Darüber hinaus können Meta-Typen einen oder mehr definierte Untertypen aufweisen; zum Beispiel können Informationen zur Rechnungsadresse und Informationen zur Versandadresse als zwei unterschiedliche Untertypen erkannt werden, welche die gleichen allgemeinen Datenkomponenten aufweisen.
Bei einem gegebenen Formular, ähnlich dem beispielhaften Formular 580, können Informationen in jedem von verschiedenen Formaten abgefordert werden; in Bezug auf das Feld "Staat" 585 kann das Formular zum Beispiel fordern, dass der Name des Staates voll ausgeschrieben wird, oder die Abkürzung des Staates in zwei Buchstaben kann gefordert werden. Alternativ kann der Staat zum Beispiel aus einem Drop-down-Menü oder einer anderen Art von Listen ausgewählt werden. Durch das Erkennen des speziellen Formats, das vom Formular gefordert wird, ist das System der vorliegenden Erfindung dafür geeignet, die erforderlichen Informationen in der geeigneten Konfiguration dergestalt zur Verfügung zu stellen, dass sie vom Server, dem das ausgefüllte Formular vorgelegt wird, akzeptiert werden.
Gemäß einer Ausführungsform der vorliegenden Erfindung werden die Benutzerdaten, die beim Zentralserver gespeichert sind, aus der Datenbank abgerufen und so gehandhabt, dass sie den Formatierungsanforderungen des Formulars durch die Programmsoftware beim Server entsprechen. Die ordnungsgemäß formatierten Benutzerdaten werden danach auf den Computerterminal des Benutzers übertragen; dort können die übertragenen Daten für das Ausfüllen eines gewünschten Formulars so genutzt werden, dass es nicht erforderlich ist, dass der Benutzer die Informationen manuell eingibt. Die Anzahl, der Typ und das Format von Formularen, die ein Benutzer im Internet antreffen kann, sind zwar so vielfältig wie die Anzahl von Websites, die deren Ausfüllen fordern, jedoch erkennt das System der vorliegenden Erfindung ein gegebenes Formular als eines von zwei breiten Kategorien: diejenigen Formulare, welche in die Datenbank des Systems gespeichert wurden, und diejenigen Formulare, die nicht gespeichert wurden.
Zusätzlich zur Verwaltung einer Datenbank von Benutzerinformationen bei einem zentralen Webgestützten Server ist das System der vorliegenden Erfindung dafür geeignet, eine Datenbank von Formulardaten zu verwalten, die sich auf die zahlreichen Formulare beziehen, welche am häufigsten durch Benutzer angetroffen werden, die im Web browsen; diese Formulare, welche von den populärsten oder am häufigsten besuchten Websites gefordert oder angefordert werden, können zum Beispiel abgebildet werden. Abgebildete Formulare sind zum Beispiel durch ein Software-Script, welches geeignet ist, den zugrundeliegenden HTML-Code der Web-Seite, welche das Formular enthält, zu lesen, syntaktisch analysiert worden.
Das Abbildungsverfahren ermöglicht es dem System, ein zuvor abgebildetes Formular bei nachfolgenden Antreffen derselben zu erkennen; das Erkennen der Felder und der Struktur eines bestimmten Formulars ermöglicht es wiederum dem Programmcode beim Server, die korrekten Benutzerdaten in jedes Feld, im korrekten Format, effizient und systematisch einzugeben. Demgemäß kann das Abbilden eines Formulars alle der folgenden Schritte involvieren: Prüfen des zugrundeliegenden HTLM Codes für das Analysieren der Struktur und der Anordnung des Formulars; Identifizieren der erforderlichen Felder, der optionalen Felder und des angeforderten Formats von jedem; Herstellung der Übereinstimmung der Formularfelder mit den Feldern der Benutzerdaten in der Datenbank, denen sie entsprechen; und Registrierung der vorstehenden Informationen unter einem einmaligen Identifizierungs-String, mittels dem das System zukünftig jenes bestimmte Formular identifizieren kann.
Einige oder alle der Elemente des Abbildungsverfahrens können sowohl Programmsoftware als auch Intervention des Bedieners inkorporieren. Während zum Beispiel die HTML durch ein Softwarescript syntaktisch analysiert werden kann und eine Liste von Feldern automatisch akquiriert werden kann, kann das Identifizieren eines bestimmten Feldes als optional, im Gegensatz zu gefordert, innerhalb der Struktur eines gegebenen Formulars die Eingabe durch einen Menschen erfordern. Als weiteres Beispiel kann, nachdem das Formular in seiner Gesamtheit abgebildet worden ist, ein automatisch operierender Softwarecode beim Server so programmiert werden, dass er die Tatsache feststellt, dass die Struktur des Formulars später geändert worden ist, jedoch kann es erforderlich sein, dass ein Bediener das Ausmaß der Än derung bewertet oder den Datensatz des Formulars in der zentralen Formular-Datenbank aktualisiert.
Wenn die HTML beim Zentralserver syntaktisch analysiert worden ist, kann der Code so analysiert werden, dass die Struktur des Formulars bekannt ist. Felder und Formate, die im Formular angefordert werden, können identifiziert und im Code verglichen werden; das heißt nach der Analyse der HTML in Verbindung mit einer Prüfung der Web-Seite, einschließlich des Formulars, des Typs und der Art der abgeforderten Informationen sowie des Formats, in welchem diese Informationen gewünscht werden, können diese mit Genauigkeit bestimmt werden. Auf diese Weise kann das System so angepasst werden, dass es bestimmt, ob das Formular erwartet, dass ein "Geburtsdatum"-Datenfeld im Format MM/DD/YY (Monat/Tag/Jahr) einerseits, oder im Format MM/DD/YYYY (Monat/Tag/Jahr) ausgefüllt werden soll, andererseits; das Feld "Geburtsdatum" für das bestimmte Formular kann entsprechend in die Datenbank hinein abgebildet werden.
Die HTML schließt natürlich die URL der Seite ein, welche das Formular enthält, und jene URL enthält wiederum unter anderem einen String, welcher den Domain-Namen der Website repräsentiert. Das Programm-Script, welchem die Aufgabe der syntaktischen Analyse der HTML zugewiesen ist, weist dem Formular, das analysiert wird, vorzugsweise eine einmalige Kennzeichnung zu. Die einmalige Kennzeichnung kann einen String aller Felder einschließen, die vom Formular gefordert werden, zusätzlich zu einem aus der URL abgerufenen String, wie zum Beispiel dem Domain-Namen. Die analysierten Felder und Formate, die vom Formular gefordert oder abgefragt werden, werden in einer Formular-Datenbank beim Zentralserver unter der einmaligen Formular-Kennzeichnung gespeichert.
Das Reinergebnis des vorstehenden Abbildungsvorgangs ist, dass ein bestimmtes Formular syntaktisch analysiert wird, dass seine Struktur analysiert wird und ein Identifizierungs-String geschaffen und so zugeordnet wird, dass das System danach jenes Formular erkennen kann. Der Identifizierungs-String schließt vorzugsweise einen Text-String ein, der eine Verkettung aller erforderlichen Felder im Formular, aller optionalen Felder im Formular und des Domain-Namens umfasst, die alle aus dem HTML-Code abgefragt werden. Das System verwaltet detaillierte Datensätze der Formular-Struktur, einschließlich der vorliegenden Meta-Typen und Unter-Typen, der jeden von ihnen zugeordneten Felder und des speziellen Formats für jedes Feld. Sobald das Formular auf dieser Detailebene abgebildet worden ist, handelt es sich um eine einfache Operation des Abgleichens der Formular-Datenfelder mit den in der Datenbank gespeicherten körnigen Benutzerdaten, um die korrekten Informationen in das korrekte Feld im entsprechenden Format einzufügen.
Bestimmte Formulare, auf welche der Benutzer stößt, sind vielleicht nicht abgebildet oder sie können nicht abgebildet werden, entweder vollständig oder zum Teil. Angesichts der riesigen Anzahl von Formularen im Internet-Universum ist es unwahrscheinlich, dass ein System in der Lage sein wird, einen Katalog jedes Formulars abzubilden oder zu verwalten. Des Weiteren können bestimmte Formulare dynamisch sein und somit Versuche, eine sinnvolle Abbildung zu erzeugen, zum Scheitern bringen. Nehmen Sie als ein Beispiel einen Benutzer bei einer E-Commerce-Site, der verschiedene Positionen für den Kauf auswählt. Wenn der Benutzer den Auswahlprozess abschließt, zeigt die Überprüfungsseite der E-Commerce-Website typischerweise ein Formular, welches Felder für eine Rechnungsadresse, eine Versandadresse usw. einschließt. Zusätzlich schließt das Formular üblicherweise Felder ein, die sich auf eines oder mehr des Folgenden beziehen: dem Benutzer wird die Option angeboten, die gewünschte Menge der ausgewählten Positionen zu ändern; dem Benutzer wird eine zusätzliche Position zu einem Diskontpreis auf der Grundlage des vorherigen Verhaltens des Benutzers angeboten; es werden Sonderangebote gemacht und so weiter. Diese zusätzlichen Felder sind dynamisch dergestalt, dass sie nicht immer in der Standardstruktur des Formulars vorhanden sind, und dass sie variabel als eine Funktion der Aktionen des Benutzers bei der Site sind.
Es versteht sich für die Fachleute, dass die dem Formular zugrunde liegende HTML wenig oder keine Unterstützung beim Abbildungsprozess geben kann, besonders im Fall von dynamischen Formularen. In bestimmten Fällen können Formulare so strukturiert sein, dass einem Feld oder mehr Feldern überhaupt keine Namen in der HTML zugeordnet werden, mehrfachen Feldern der gleiche Name zugeordnet wird oder dass einem Feld oder mehr Feldern dynamische Namen zugeordnet werden. Dies ist meistens eine Frage des Programmierungsstils und der Präferenz des Web-Designers, der für die Erstellung der HTML-Dokumente verantwortlich ist, welche die Website ausmachen. Der statische Teil dieser Formulare kann durch das System abgebildet werden. Alternativ können Felder entsprechend ihren relativen Positionen oder Orten im Formular abgebildet werden; wenn sich jedoch die Struktur des Formulars ändert, wird das Abbilden ungenau sein.
Beim Betrieb nutzt das Formularausfüllmerkmal der vorliegenden Erfindung sowohl den Programmcode beim Zentralserver als auch den Code, welcher der verbesserten Schnittstelle zugrunde liegt, die beim Computerterminal des Benutzers bereitgestellt wird. 6 ist eine vereinfachte grafische, schematische Ansicht der Interaktion zwischen dem Zentralserver 699 der vorliegenden Erfindung und einer Formularseite einer typischen Website, die von einem Benutzer an einem Computerterminal 610 besucht wird. In 6 entspricht das Formular 680 dem Formular 580, das oben unter Bezugnahme auf 5 erörtert wurde. Die Fähigkeiten des Standard-Internet-Browsers sind dergestalt verbessert worden, dass sie das Dienstprogramm-Fenster 650 einschließen, welches dem Dienstprogramm-Fenster 350 entsprechen kann. Wie oben unter Bezugnahme auf 3 erörtert, werden nach dem Einloggen beim Zentralserver 699 bestimmte System-Dienstprogramme in das Dienstprogramm-Fenster 650 mit Hilfe des Programmcodes importiert, was sich auf das Aussehen und den Betrieb des Dienstprogramm-Fensters 650 auswirken kann.
Bei dieser besonderen Ausführungsform der vorliegenden Erfindung wird die Schnittstelle des Benutzers mit der Formularausfüllfunktion aktiviert, und sie kann dem Benutzer in Form einer Bedienungstaste, wie zum Beispiel Taste 351 oder zum Beispiel als eine operative Option in einem Menü dargeboten werden. Der Benutzer kann zu der Seite, einschließlich des Formulars 680, auf verschiedene Weise gelangen. Der Benutzer kann zum Beispiel einfach nur browsen und im Laufe der Sitzung im Internet zufällig auf eine Seite, einschließlich eines Formulars, stoßen. Alternativ kann der Benutzer einem Hyperlink folgen, der im Dienstprogramm-Fenster 650 bereitgestellt wird, um automatisch zu einer Seite zu navigieren, die ein Formular enthält.
Wenn sich der Benutzer dafür entscheidet, ein Formular auszufüllen, kann das Formularausfüllmerkmal über das Dienstprogramm-Fenster 650 aufgerufen werden. Das Aufrufen der Formularausfüll-Software initiiert ein Programmscript, welches in das Dienstprogramm-Fenster 650 nach dem Einloggen beim Server 699 importiert wird, für das syntaktische Analysieren der HTML der Seite, die Text-Strings einschließt, welche die URL und das Formular 680 repräsentieren.
Text-Strings, welche alle im Formular eingefügten Felder repräsentieren, werden mit dem Domain-Namen verkettet, was alles aus der HTML abgerufen wird, um einen Identifizierungs-String zu erzeugen. Dieser Identifizierungs-String wird zum Zentralserver 699 übertragen, wo er mit der Vielzahl von Identifizierungs-Strings verglichen wird, die in der Datenbank aufgezeichnet sind, um festzustellen, ob das Formular zuvor abgebildet worden ist.
Wenn das Formular abgebildet worden ist, wird der Identifizierungs-String, der vom Computerterminal 610 des Benutzers übermittelt worden ist, exakt einem der Identifizierungs-Strings in der Datenbank beim Server 699 entsprechen, und das System kann die Daten für die Rückführung zum Computer 610 des Benutzers vorbereiten. Programmierungsroutinen beim Zentralserver 699 können erforderliche Funktionen auf den Benutzerdaten in der Datenbank ausführen, ehe die Daten, im entsprechenden Format, zum Computerterminal 610 des Benutzers zurückgeführt werden. Wenn die Information "Name" zum Beispiel als ein einziges Feld im auszufüllenden Formular formatiert ist, kann der Server 699 die Felder Vorname, Mittelname und Familienname, die aus der Datenbank abgerufen worden sind, verketten und Zwischenräume zwischen jedem Text-String hinzufügen, wodurch die Daten in dem Format angeordnet werden, welches von dem Server erwartet wird, dem das Formular letztendlich vorgelegt wird.
Wenn das Formular nicht zuvor abgebildet worden ist, oder wenn es seit dem letzten Abbilden modifiziert worden ist, wird der Identifizierungs-String, welcher zum Zentralserver 699 vom Computerterminal 610 des Benutzers übermittelt worden ist, keinem der Identifizierungs-Strings in der Datenbank entsprechen. Der nicht erkannte Identifizierungs-String kann jedoch gespeichert werden, und das System kann ein umgekehrtes Abbilden versuchen, wie nachstehend beschrieben werden wird.
Wenn er mit einem nicht erkannten Identifizierungs-String konfrontiert wird, analysiert der Programmcode beim Zentralserver 699 zunächst den Identifizierungs-String und versucht, Unter-Strings desselben zu identifizieren, welche bekannte Feldnamen rep räsentieren. In dem Fall, wenn die Struktur oder die Anordnung eines zuvor abgebildeten Formulars vor kurzem leicht durch die Host-Website geändert worden ist, zum Beispiel derart, dass der Identifizierungs-String nicht genau denjenigen in der Datenbank entspricht, kann die Analyse jenes Identifizierungs-Strings letztendlich enthüllen, dass die meisten oder alle der Felder erkennbar sind, obwohl sie in einer Reihenfolge präsentiert werden, auf welche das System zuvor nicht gestoßen ist. In ähnlicher Weise kann ein nicht abgebildetes Formular eine analoge Struktur aufweisen und die gleichen Feldnamen enthalten, wie ein abgebildetes Formular, in dem Fall, wo beide Formulare bei entsprechenden Websites die gleiche Host-Einheit haben oder zum Beispiel vom gleichen Webdesigner geschaffen wurden. Auf jeden Fall können bekannte Feldnamen mit entsprechenden Benutzerdaten ausgefüllt werden, die aus der Datenbank abgerufen werden, und ordnungsgemäß formatiert werden.
Danach versucht der im System verkörperte Programmcode, potenzielle Meta-Typen logischer Datenblocks aus Feldnamen zu identifizieren, die identifiziert werden können, wodurch eine angemessene Folgerung in Bezug auf die gesamte Struktur des nicht identifizierten Formulars auf der Grundlage dessen, was angemessen sicher ist, formuliert wird.
Das System kann zum Beispiel angepasst werden für die Verwaltung eines Betriebsprotokolls der Feldnamen, die zuvor in HTML-Formularen angetroffen wurden, sowie der Benutzerdaten, denen diese Feldnamen entsprechen. Das System kann daher erkennen, dass "Surname" (Familienname), "LastName" (Familienname) und "last_name" (Familienname), wenn sie in einem Formular vorgefunden werden, alle das gleiche Feld in der Datenbank repräsentieren, welches dem Familiennamen des Benutzers entspricht. Wenn ein nicht identifiziertes Formular ein Feld einschließt, das einen dieser Namen, oder etwas Ähnliches, wie zum Beispiel "nameLAST" (letzter Name) enthält, kann das System der vorliegenden Erfindung jenes Feld erkennen und diesen Teil des unbekannten Formulars entsprechend abbilden. Weiterhin kann das System versuchen, auf der Grundlage der Präsenz des bekannten Feldes einen vollständigen Meta-Typ zu rekonstruieren. Bei diesem besonderen Beispiel ist es wahrscheinlich, dass die Felder in der Nähe von "nameLAST" einen Vornamen oder zum Beispiel einen Mittelnamen repräsentieren. In dem Fall, wenn "nameLAST" und "nameFIRST" (erster Name) zusammen mit einem unbekannten dazwischen liegen den Feld identifiziert werden, kann das System der vorliegenden Erfindung versuchen, dieses dazwischen liegende Feld mit einem Mittelnamen oder mit einem Anfangsbuchstaben auszufüllen, selbst wenn der Name, welcher dem dazwischen liegenden Feld in der HTML des Formulars zugeordnet ist, nicht erkannt wird.
Den Fachleuten wird bekannt sein, dass das vorstehende "Fuzzy"-Ausfüllverfahren in Form eines heuristischen Algorithmus implementiert werden kann, der geeignet dafür ist, die Feldnamen-Strings oder Teile derselben im HTML-Identifizierungs-String zu analysieren und diese Strings und Unter-Strings mit den Informationen zu vergleichen, die in der Datenbank in Bezug auf abgebildete Formulare schon verzeichnet sind. Die hierarchische Struktur eines oben definierten Formulars ermöglicht es dem System, Bits von bekannten Daten zu logischen Meta-Typen zusammenzufügen, die zum Teil auf dem enormen Bestand von Informationen in der Datenbank beruhen und zum Teil darauf, wie diese Informationen typischerweise in den am häufigsten angetroffenen Situationen angeordnet sind. Dementsprechend kann die gesamte Struktur eines zuvor unbekannten Formulars potentiell in Echtzeit bestimmt werden.
Beim Betrieb durchläuft der Programmcode beim Zentralserver 699 den Formular-Identifizierungs-String und vollzieht die erforderlichen Operationen an den Benutzerdaten, um die Felder auszufüllen, die identifiziert werden können. Der Umfang, in welchem das Ausfüllen des Formulars möglich ist, beruht in großem Maße darauf, was mit Gewissheit identifiziert werden kann oder problemlos aus der HTML-Struktur abgeleitet werden kann. Selbst im Falle eines abgebildeten Formulars, bei dem jedes Feld im gesamten Formular durch das System ausgefüllt werden kann, ist es möglich, dass das Formular in Wirklichkeit nicht durch das System vorgelegt wird.
Bei einer bevorzugten Ausführungsform kann der Programmierungscode beim Zentralserver 699 zum Beispiel einfach die geeigneten Benutzerdaten aus den Datenbank-Datensätzen abrufen und diese Daten zum Computerterminal 610 des Benutzers für das Ausfüllen des Formulars 680 zurückführen; das ausgefüllte oder zum Teil ausgefüllte Formular 680 kann dann dem Benutzer angezeigt werden, der selektiv Informationen ändern, streichen oder hinzufügen kann. Diese Ausführungsform sorgt für zwei besondere Vorteile: der Benutzer hat die Möglichkeit, optionale Informationen zu streichen oder zu modifizieren, welche der Benutzer nicht als speziell in der Datenbank verzeichnete Informationen liefern möchte, und zuvor nicht abgebildete Formulare können gemäß den vom Benutzer bereitgestellten Informationen abgebildet werden.
Im Falle eines nicht abgebildeten Formulars kann der Programmcode beim Computerterminal des Benutzers so angepasst werden, dass er die HTML syntaktisch analysiert, wenn die Formular-Seite nicht geladen ist. Nach der Bestätigung des "Nichtgeladen"-Falles, was bedeutet, dass der Benutzer versucht, das Formular vorzulegen, kann der Programmcode beim Computer des Benutzers die vom Benutzer vorgelegten Daten erfassen und diese danach zum Server übertragen. Programmroutinen beim Server können dann die Struktur des Formulars umprogrammieren, auf der Grundlage dessen, was problemlos anhand der Daten abgeleitet werden kann, die vom Benutzer für jedes Feld bereitgestellt werden.
In ähnlicher Weise kann, selbst wenn die Struktur des Formulars abgebildet worden ist, das Formular in bestimmten Fällen Informationen erfordern, welche der Benutzer zuvor nicht an den Server geliefert hat; in diesem Fall kann es sein, dass alle erforderlichen Daten für das Ausfüllen des Formulars nicht sofort in der zentralen Datenbank verfügbar sind. Zusätzlich zur Bereitstellung einer Schnittstelle, welche den Benutzer zu dieser Eingabe veranlasst und selbige für das Ausfüllen des Formulars benutzt, kann das System so angepasst werden, dass es diese Daten am geeigneten Ort im Datenbank-Datensatz des Benutzers speichert.
Bei noch einem weiteren Szenario kann ein Benutzer, der beim Browsen auf ein abgebildetes Formular stößt, sich dafür entscheiden, die erforderlichen oder abgefragten Benutzerdaten einzugeben und das Formular manuell vorzulegen. Beim Erkennen des "Nichtgeladen"-Falles kann die HTML syntaktisch analysiert werden, und die manuell ausgefüllten Daten des Benutzers können zum Zentralserver übermittelt werden. Da das Formular abgebildet ist, kann das System die Feldnamen und die ihnen zugeordneten entsprechenden Benutzerdaten erkennen; in dem Fall, wenn der Benutzer Daten vorlegt, die noch nicht in der Datenbank verzeichnet sind, können Programmscripts beim Zentralserver die vom Benutzer bereitgestellten Daten mit den bekannten Feldnamen abgleichen, und die neu bereitgestellten Benutzerdaten können, vorbehaltlich der Zustimmung des Benutzers, an den geeigneten Orten im Datenbank-Datensatz gespeichert werden.
Alternativ kann das Formular bestimmte optionale Daten abfordern, die gegenwärtig in der Datenbank verzeichnet sind, welche der Benutzer jedoch nicht liefern möchte. Wie hinsichtlich der oben beschriebenen Ausführungsform festgestellt wurde, kann die Formularausfüllfunktion lediglich das Formular so weit wie möglich ausfüllen, während das ausgefüllte Formular in Wirklichkeit nicht vorgelegt wird. Es kann sein, dass es erforderlich ist, dass der Benutzer, der von der Last des manuellen Ausfüllens aller Felder befreit ist, dennoch das ausgefüllte Formular auf Genauigkeit prüft und zu diesem Zeitpunkt optionale Daten streicht und die bereitgestellten Informationen in einem gegebenen Feld ändert. Alternativ wird der Benutzer, in dem Fall, wenn das System dafür geeignet ist, das Formular automatisch vorzulegen, vorzugsweise dazu veranlasst, optionale Daten nach dem Ermessen des Benutzers selektiv zu liefern.
Aus dem Vorstehenden versteht sich, dass, sobald sich der Benutzer beim eingetragenen Benutzerkonto beim Zentralserver eingeloggt hat, das Formularausfüllmerkmal für eine wesentliche Bequemlichkeit sorgt. Der Benutzer kann, indem er lediglich die Formularausfülloption aus dem Dienst-Programmfenster auswählt, ein gesamtes Formular oder Teile eines Formulars automatisch mit einer geringen oder keinen manuellen Eingabe ausfüllen. Darüber hinaus kann das System die Eingabe des Benutzers erkennen, wenn eine bestimmte Seite nicht geladen ist, was darauf hinweist, dass ein Formular, welches vom Benutzer manuell ausgefüllt worden ist, unabhängig vom Formularausfüllmerkmal vorgelegt wird. Auf diese Weise kann das System von den Erfahrungen des Benutzers "lernen" und Formulare für zukünftige Formularausfülloperationen abbilden, die von anderen Benutzern aufgerufen werden.
Das System der vorliegenden Erfindung bietet ebenfalls eine spürbare Bequemlichkeit, wenn ein Benutzer sich bei einem bestimmten eingetragenen Benutzerkonto bei einem E-Mail-Server oder zum Beispiel bei einer E-Commerce-Website einloggen möchte. Eine typische Web-Browser-Anwendung offeriert eine Liste, die editiert werden kann, der am häufigsten vom Benutzer besuchten Websites. Wie sie gemeinhin implementiert wird, ermöglicht es eine "Lesezeichen"- oder "Favoriten"-Liste dem Benutzer lediglich, zu einer bestimmten Site zu navigieren, ohne dass es erforderlich ist, die URL der Site in das Textkästchen in der Browser-GUI einzugeben; das heißt, das Lesezeichen ist lediglich ein Navigationstool, das lediglich dazu in der Lage ist, den Browser zu einer angegebenen Adresse im Cyberspace zu lenken.
Die vorliegende Erfindung kombiniert andererseits das Navigations-Dienstprogramm des typischen Lesezeichens mit einer kundenspezifischen Formularausfülloperation einer Art ähnlich der oben beschriebenen. Das Reinergebnis dieser Kombination ist ein "smartes" Lesezeichen, welches den Benutzer nicht nur zur Einlog-Seite eines angegebenen Benutzerkontos navigiert, sondern ebenfalls das Einlog-Formular vorlegt und ausfüllt, wodurch es den Benutzer bei einem eingetragenen Benutzerkonto ohne eine weitere Intervention durch den Benutzer einloggt.
Die Schnittstelle für dieses Einlog-Merkmal kann in das Dienst-Programmfenster nach dem Einloggen beim Zentralserver installiert werden, wie oben unter Bezugnahme auf 3 beschrieben ist. Bei diesem besonderen Fall kann die Schnittstelle zum Beispiel ein Drop-down-Menü umfassen, das eine Betriebsoption für das Einrichten eines Benutzerkontos einschließen kann, der als eine unabhängige Auswahl im Menü angezeigt werden soll.
In der gleichen Weise kann ein Benutzer mehrere E-Mail-Benutzerkonten bei einem einzigen E-Mail-Server unterhalten, ein Benutzer kann mehr als ein registriertes Benutzerkonto bei anderen Arten von Servern, wie zum Beispiel E-Commerce-Websites unterhalten. Das System der vorliegenden Erfindung sorgt für die Aufzeichnung erforderlicher Daten hinsichtlich von mehreren Benutzerkonten in der gleichen Domain, die ein Benutzerkonto zu Hause und zum Beispiel ein Benutzerkonto an der Arbeitsstätte beim gleichen Server entsprechen. Umgekehrt kann ein Benutzerkonto bei einer Seite einen eingetragenen Benutzer zum Einloggen bei einer anderen Website bei einer vollständig anderen Domain berechtigen, die vielleicht durch die gleiche Einheit oder einen Co-Marken-Partner betrieben wird; das heißt, das Einrichten eines Benutzerkontos bei einer Website kann den eingetragenen Benutzer potentiell zum Zugriff auf die Partner Sites jener Website an anderen Orten berechtigen, indem der gleiche Benutzername und das Passwort verwendet werden, die von der Site erkannt werden, bei welcher der Benutzer eingetragen ist. Das System der vorliegenden Er findung ist in der Lage, diese Arten von Partnerschafts-Benutzerkonten zu erkennen, zumindest in Bezug auf abgebildete Sites.
Da auf eine Vielzahl von Benutzerkonten über die Schnittstelle Zugriff genommen werden kann, die zum Beispiel im Dienst-Programmfenster bereitgestellt wird, kann jedem Benutzerkonto, für welches das Einlog-Merkmal aufgerufen wird, eine einmalige Kennzeichnung oder ein Spitzname gegeben werden, der im Menü oder in der Liste für die Identifizierung des Benutzerkontos gezeigt werden soll. In dem Fall, wenn ein Benutzer versucht, Daten vorzulegen, die einen zweites oder nachfolgendes Benutzerkonto in der gleichen Domain betreffen, kann der Programmcode beim Zentralserver, der mit Hilfe des Schnittstellencodes beim Computerterminal des Benutzers operiert, den Benutzer informieren, dass an der ausgewählten Site bereits ein Benutzerkonto existiert und den Benutzer veranlassen, einen neuen Benutzernamen und ein neues Passwort zusammen mit einem anderen Spitznamen für das neue Benutzerkonto zu bestätigen.
Wie oben angemerkt, ist es während einer bestimmten Browsing-Sitzung im Web für einen Benutzer lediglich erforderlich, ein Benutzerkonto zum Beispiel aus dem Dropdown-Menü auszuwählen, um die Programmscripts aufzurufen, welche den Benutzer bei dem ausgewählten eingetragenen Benutzerkonto einloggen werden. Anfänglich müssen jedoch die Benutzerkonten, für welche das Einlog-Merkmal aktiviert wird, eingegeben werden, um vom System erkannt zu werden. Aus der Sicht des Benutzers gibt es drei potentielle Szenarien, welche eine Schnittstelle mit dem Einlog-Merkmal erfordern, um ein Benutzerkonto dergestalt einzurichten, dass das Einlog-Merkmal in Bezug auf jenes Benutzekonto in der Zukunft voll betriebsfähig ist: das Login-Formular ist schon abgebildet worden; der Benutzer ruft ein "custom add"-Merkmal auf, um ein Website-Benutzerkonto einzurichten; oder der Benutzer versucht, sich bei einem Benutzerkonto unabhängig vom Einlog-Merkmal einzuloggen.
Im ersten Fall ist das Login-Formular für eine bestimmte Website schon im System abgebildet worden, wie oben in Bezug auf das Formularausfüllmerkmal beschrieben wurde. Das System kennt daher schon die URL der Login-Seite und die Struktur des Login-Formulars; diese Informationen werden in einem Formular-Datenbank-Datensatz gespeichert, der einem speziellen Formular-Identifizierungs-String zuge ordnet ist, wie oben beschrieben wurde. Eine Liste erkannter Websites mit Login-Formularen, die schon abgebildet sind, kann für den Benutzer im Dienst-Programmfenster verfügbar sein, und der Benutzer kann eine der aktiven Optionen auswählen, um zur Login-Seite einer bestimmten Site zu navigieren.
Bei dieser Ausführungsform analysiert der in den Computerterminal des Benutzers importierte Programmcode syntaktisch die HTML der Login-Seite und identifiziert den "Geladen"-Fall, der das Eintreffen der Seite beim Browser des Benutzers anzeigt. Nach dem Feststellen des "Geladen"-Falles kann die oben erörterte Formularausfülltechnik aufgerufen werden; die HTML wird syntaktisch analysiert, der einmalige Formular-Identifizierungs-String wird an den Zentralserver übermittelt, und der Programmcode beim Server prüft den Datenbank-Datensatz des Benutzers, um festzustellen, ob ein Benutzername und ein Passwort für das auszufüllende identifizierte Login-Formular verzeichnet sind. Wenn das Benutzerkonto nicht zuvor im System verzeichnet worden ist, veranlasst die Formularausfüllroutine den Benutzer, den Benutzernamen und das Passwort anzugeben, welche dem bestimmten Benutzerkonto zugeordnet sind. Das System füllt nicht nur das Formular mit den Daten aus, die vom Benutzer zur Verfügung gestellt wurden, sondern speichert ebenfalls diese Daten im Datenbank-Datensatz des Benutzers in Zuordnung zum einmaligen Formular-Identifizierungs-String. Der Formularausfüllroutine werden dadurch alle erforderlichen Daten für das zukünftige Ausfüllen des Formulars in seiner Gesamtheit zur Verfügung gestellt.
Das Login-Merkmal der vorliegenden Erfindung schließt vorzugsweise den zusätzlichen Schritt der tatsächlichen Vorlage des Formulars ein. Der Programmcode beim Computerterminal des Benutzers führt ein Programmscript aus, welches das Formular vorlegt. Eine HTML-Seite mit einem Formular schließt üblicherweise eine Bedienungstaste oder einen anderen Mechanismus für das Ausführen des Vorlagescripts ein, der die Seite entlädt und die HTML-Daten zum Server liefert, der das Formular anfordert. Das Login-Merkmal kann den Programmcode einschließen, welcher die Auswahl der Bedienungstaste in der HTML-Seite simuliert. Demgemäß kann das Formular unter Softwaresteuerung vorgelegt werden, wodurch der Benutzer beim ausgewählten Benutzerkonto eingeloggt wird. Da alle erforderlichen Benutzerkonto-Daten jetzt im Zentralserver gespeichert sind, sind zukünftige Einlog-Operationen einfach eine Frage der Auswahl des Benutzerkontos in der Dienstprogrammfenster-Schnittstelle.
Die Erstellung eines Programmscripts, welches lediglich die Auswahl einer Taste bei der HTML, zum Beispiel für die Vorlage eines Formulars simuliert, ist eine relativ einfache Angelegenheit; wenn die Formularaktion jedoch ausgeklügelter ist, ist das Programmscript für das Simulieren der Einfügung erforderlicher Parameter zusammen mit der Formular-Vorlage entsprechend komplizierter. In bestimmten Fällen bietet der Mechanismus für die Vorlage eines gegebenen Formulars an einen Web-Server nicht ohne Weiteres die Vorlage des Formulars durch Softwareintervention oder auf programmatische Weise. Funktionsparameter, die in den HTML-Code eingebettet sind, der zum Server zurückgeführt wird, welcher das Formular anfordert, können zum Beispiel erforderlich sein, um die Art und Weise anzugeben, in welcher die Vorlage erfolgt; das Fehlen dieser Parameter führt zu einem erfolglosen Einlog-Versuch.
Das System der vorliegenden Erfindung ist dafür geeignet, komplizierte Formularaktionen zu erkennen, und es kann einen Programmcode einschließen, um die Aktion des Formulars zu ändern, welches vorgelegt werden soll. Bei der Änderung der Formularaktion kann die durch das System erzeugte Vorlage erforderliche Parameter einschließen, die ansonsten ausgelassen würden, wenn das Formular programmatisch unter Nutzung eines niederen Scripts vorgelegt würde, wie zum Beispiel eines, welches lediglich die Auswahl einer Taste simuliert. Es wird für die Fachleute selbstverständlich sein, dass dieses Modifizieren der Formularaktion eine Angelegenheit des anfänglichen syntaktischen Analysierens der HTML ist, um die erforderlichen Parameter zu identifizieren und als Reaktion darauf Textfelder einzufügen, welche diese Parameter in der HTML repräsentieren, das zusammen mit den Formulardaten vorgelegt wird.
Im zweiten Fall der Einrichtung eines Website-Benutzerkontos ist das Login-Formular zuvor nicht abgebildet worden, sondern der Benutzer ruft ein "custom add"-Merkmai aus dem Dienst-Programmfenster auf. Die Auswahl des custom add-Merkmals initiiert ein Programmscript, welches den Benutzer veranlasst, drei erforderliche Informationen einzugeben: die URL der Einlog-Seite; den Benutzernamen, unter welchem das eingetragene Benutzerkonto geführt wird, und das Passwort, welches dem Be nutzerkonto zugeordnet ist. Zusätzlich kann der Benutzer einen Namen eingeben, der im Menü oder in der Liste für die Identifizierung des Benutzerkontos angezeigt werden soll; alternativ kann das System einen Namen für das Benutzerkonto zuordnen oder vorschlagen, vorbehaltlich der Zustimmung des Benutzers, basierend auf dem Domain-Namen in der URL der Login-Seite.
Der Browser wird zur URL der Login-Seite navigiert, die HTML wird syntaktisch analysiert, und der einmalige Formular-Identifizierungs-String wird an den Server übermittelt. In dieser Situation kann, da das Login-Formular nicht abgebildet worden ist, der Programmcode beim Zentralserver den Identifizierungs-String nicht mit einem zuvor abgebildeten Formular abgleichen, und folglich verfügt das System über keine Informationen hinsichtlich der Struktur oder der Anordnung des Login-Formulars. Ein heuristischer Algorithmus wird beim Zentralserver implementiert, um die Art und die Struktur des Login-Formulars bei der vom Benutzer bereitgestellten URL zu identifizieren.
Der Algorithmus analysiert syntaktisch den HTML und sucht nach einem Login-Formular, bei welchem die Benutzernamen- und Passwortfelder im HTML-Code eingebettet sind. Da jede gegebene HTML-Seite mehr als ein Formular, welches in seinem Code eingebettet ist, aufweisen kann, versucht der Algorithmus zunächst, lediglich die Formulare zu identifizieren, die relativ wenige Felder haben, zum Beispiel vier oder weniger; dies ist sinnvoll, da die meisten Einlog-Formulare lediglich einen Benutzernamen und ein Passwort benötigen. Da das "Passwort"-Feld im HTML-Code charakteristisch ist, identifiziert der Algorithmus danach das Vorhandensein von Passwortfeldern und ignoriert jedes Formular, welches mehr als ein Feld hat; ein solches Formular würde höchstwahrscheinlich ein Registrierungsformular sein (welches typischerweise den Benutzer auffordert, erneut ein Passwort zur Verifizierung einzugeben), und kein Einlog-Formular. Wenn ein kurzes Formular mit einem einzigen Passwortfeld identifiziert worden ist, geht der Algorithmus davon aus, dass das Feld, welches dem Passwortfeld vorangeht, das Benutzernamenfeld ist.
Nach Abschluss des vorstehenden heuristischen Algorithmus ist das Einlog-Formular ausreichend im Detail geprüft worden, um es der Formularausfüllroutine zu ermöglichen, das Formular exakt auszufüllen, und das Szenario reduziert sich auf die erste Situation, in welcher das Einlog-Formular zuvor abgebildet worden war. Das Formularausfüllscript wird aufgerufen, der Benutzer kann zur Angabe des Benutzernamens und von Passwortdaten aufgefordert werden (wobei diese Informationen dann vorzugsweise im Datenbank-Datensatz des Benutzers gespeichert werden), und das Formular kann vorgelegt werden. Bei einer alternativen Ausführungsform kann das custom add-Merkmal so angepasst werden, dass es das Einlog-Formular nicht automatisch vorlegt, sondern vielmehr dem Benutzer die Möglichkeit gibt zu bestätigen, dass der heuristische Algorithmus das Formular korrekt abgebildet hat und um zu gewährleisten, dass der Benutzername und die Passwortdaten an den richtigen Stellen ausgefüllt wurden.
Im dritten Fall der Einrichtung eines Website-Benutzerkontos versucht der Benutzer, sich bei einem Benutzerkonto unabhängig vom Einlog-Merkmal einzuloggen. In dieser Situation erfasst der Programmcode beim Computerterminal des Benutzers den "Nichtgeladen"-Fall und analysiert syntaktisch die HTML, um durch Prüfen des einmaligen Formular-Identifizierungs-Strings festzustellen, ob der Benutzer ein Einlog-Formular vorlegt. Entweder ist das Formular zuvor abgebildet worden, in welchem Fall das Szenario ähnlich der oben beschriebenen ersten Situation ist, oder das Formular ist nicht abgebildet worden, in welchem Fall das Szenario als die oben beschriebene custom add-Situation behandelt wird.
Ungeachtet der Art und Weise, in welcher das eingetragene Benutzerkonto eingerichtet wird, um mit dem Einlog-Merkmal zu funktionieren, kann, sobald dem Zentralserver alle erforderlichen Daten zur Verfügung gestellt worden sind, ein nachfolgendes Einloggen in Bezug auf ein eingetragenes Benutzerkonto nach der Auswahl des gewünschten Benutzerkontos in der Dienstprogrammfenster-Schnittstelle automatisch sein. Die Programmscripts beim Computerterminal des Benutzers navigieren den Browser zur Einlog-Seiten-URL. Nach dem Erfassen des "Geladen"-Falles wird die Formularausfüllroutine aufgerufen, wobei die Einlog-Formulardaten zum Zentralserver gesendet werden, der Benutzername und die Passwortdaten aus dem entsprechenden Datenbank-Datensatz abgerufen werden, welcher dem Identifizierungs-String des Einlog-Formulars zugeordnet ist und Programmscripts beim Computerterminal des Benutzers genutzt werden, um diese Benutzerdaten in das Formular einzutragen. Schließlich simuliert ein Programmscript die Auswahl der Vorlage- Option bei der Login-Seite dergestalt, dass das Formular dem Web-Server vorgelegt wird und der Benutzer automatisch in das ausgewählte eingetragene Benutzerkonto eingeloggt wird.
Aus dem Vorstehenden ist ersichtlich, dass ein gemäß der vorliegenden Erfindung gestaltetes System eine vielseitige, effiziente und personalisierte Erweiterung der Möglichkeiten eines normalen Web-Browsers für spezialisierte Anwendungen bereitstellt, besonders im Hinblick auf das Automatisieren bestimmter Interaktionen, die normalerweise vollständig manuell erfolgen müssen. Die hierin offengelegten bevorzugten Ausführungsformen sind lediglich beispielhaft und nicht einschränkend beschrieben und veranschaulicht worden. Aus der vorstehenden detaillierten Offenlegung werden andere Ausführungsformen und Variationen der Erfindung für die Fachleute offenkundig sein. Es sind zwar nur bestimmte Ausführungsformen der Erfindung hierin besonders beschrieben worden, jedoch wird es offensichtlich sein, dass zahlreiche Änderungen an diesen vorgenommen werden können, ohne vom Schutzumfang der Erfindung abzugehen.

Claims

System für die Automatisierung von Datentransaktionen mit einem Computerserver, umfassend: einen ersten Computerserver, der eine erste Datenbank verwaltet, in der sich gespeicherte Benutzerdaten befinden; einen Programmcode beim ersten Server für die selektive Abfrage der gespeicherten Daten als Reaktion auf eine Anfrage; einen zusätzlichen Programmcode beim ersten Server, dadurch gekennzeichnet, dass der zusätzliche Code bestimmt ist für das Vergleichen unbekannter Feldnamen aus einem Formular, das von einem zweiten Server benötigt wird, mit einem Betriebsprotokoll beim ersten Server mit zuvor angetroffenen Feldnamen; das Abbilden der Daten von einem zuvor angetroffenen Feldnamen, das einen unbekannten Feldnamen mit den unbekannten Feldnamen vergleicht; wenn unbekannte Feldnamen verbleiben, Identifizieren der unbekannten Feldnamen auf der Grundlage der Nähe zu Feldern, die bekannte Feldnamen haben; und Ausfüllen der Felder des Formulars mit entsprechenden Daten.
System nach Anspruch 1, weiterhin umfassend: einen Programmcode für die Verkettung von Strings, die alle Felder im Formular repräsentieren, um einen Identifizierungs-String zu schaffen.
System nach Anspruch 2, weiterhin umfassend: Programmcode für das Identifizieren von Teilketten im Identifizierungs-String, der bekannte Feldnamen repräsentiert und für das Ausfüllen bekannter Feldnamen mit abgerufenen Daten.
System nach Anspruch 2, dadurch gekennzeichnet, dass der Identifizierungs-String einen URL (universal resource locator) für das Formular einschließt.
System nach Anspruch 1, dadurch gekennzeichnet, dass das Formular folgendes umfasst: ein Login-Formular; ein Registrierungsformular.
System nach Anspruch 1, dadurch gekennzeichnet, dass der erste Computerserver die Erstellung eines ausgefüllten Formulars unter Nutzung der abgerufenen Daten für das Ausfüllen des Blankoformulars gestattet.
System nach Anspruch 1, weiterhin umfassend: einen Programmcode für das Erstellen einer Formular-Karte für ein unbekanntes Formular, basierend auf Benutzerdaten, die während des Ausfüllens des unbekannten Formulars durch den Benutzer geliefert wurden.
System nach Anspruch 1, weiterhin umfassend: eine zusätzliche Datenbank, die beim ersten Computerserver verwaltet wird, wobei die zusätzliche Datenbank darin aufgezeichnete gespeicherte Formulardaten enthält und wobei die gespeicherten Formulardaten sich auf das Formular beziehen, welches vom zweiten Computerserver benötigt wird, dadurch gekennzeichnet, dass der zweite Server einen Web-Server umfasst.
System nach Anspruch 8, dadurch gekennzeichnet, dass der zusätzliche Programmcode Befehle für das Vergleichen von Datenfeldern im Formular mit den gespeicherten Formulardaten einschließt, die in der zusätzlichen Datenbank aufgezeichnet sind.
System nach Anspruch 8, dadurch gekennzeichnet, dass die gespeicherten Formulardaten syntaktisch analysierte Formulardaten vom zweiten Computerserver einschließen.
System nach Anspruch 9, weiterhin umfassend: Formularausfüll-Programmbefehle, welche ein Ergebnis des Vergleichens de Datenfelder im Blankoformular mit den gespeicherten Formulardaten für das Erstellen eines ausgefüllten Formulars durch das Ausfüllen des Formulars nutzen.
System nach Anspruch 11, weiterhin umfassend: Formularübermittlungs-Programmbefehle, welche ein Ergebnis der Formularausfüll-Programmbefehle für die automatische Übermittlung des ausgefüllten Formulars an den zweiten Computerserver benutzen.
System nach Anspruch 1, dadurch gekennzeichnet, dass der zusätzliche Programmcode Befehle für das syntaktische Analysieren des Formulars einschließt, um festzulegen, welche der abgerufenen Daten genutzt werden sollten, um zumindest einen Teil des Blankoformulars auszufüllen.
Verfahren für die Automatisierung von Datentransaktionen mit einem ersten Computerserver, folgende Schritte umfassend: den ersten Computerserver, der eine erste Datenbank verwaltet, in der sich gespeicherte Benutzerdaten befinden; selektive Abfrage der gespeicherten Daten als Reaktion auf eine Anfrage; dadurch gekennzeichnet, dass das Verfahren weiterhin folgende Schritte umfasst: das Vergleichen unbekannter Feldnamen aus einem Formular, das von einem zweiten Server benötigt wird, mit einem Betriebsprotokoll beim ersten Server mit zuvor angetroffenen Feldnamen; das Abbilden der Daten von einem zuvor angetroffenen Feldnamen, das einen unbekannten Feldnamen mit den unbekannten Feldnamen vergleicht; wenn unbekannte Feldnamen verbleiben, Identifizieren unbekannter Feldnamen auf der Grundlage der Nähe zu Feldern, die bekannte Feldnamen haben; und Ausfüllen der Felder des Formulars mit entsprechenden Daten.
Verfahren nach Anspruch 14, weiterhin umfassend den Schritt der Verkettung von Strings, die alle Felder im Formular repräsentieren, um einen Identifizierungs-String zu schaffen.
Verfahren nach Anspruch 15, weiterhin umfassend den Schritt des Identifizierens von Teilketten im Identifizierungs-String, die bekannte Feldnamen repräsentieren und das Ausfüllen bekannter Feldnamen mit abgerufenen Daten.
Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass der Identifizierungs-String einen URL (universal resource locator) einschließt.
Verfahren nach einem der Ansprüche 14 bis 17, dadurch gekennzeichnet, dass das Formular folgendes umfasst: ein Login-Formular; ein Registrierungsformular.
Verfahren nach einem der Ansprüche 14 bis 18, welches weiterhin folgenden Schritt umfasst: Identifizieren von Teilketten im Identifizierungs-String, die bekannte Feldnamen repräsentieren und das Ausfüllen bekannter Feldnamen mit abgerufenen Daten.
Verfahren nach einem der Ansprüche 14 bis 19, weiterhin folgenden Schritt umfassend: Erstellen einer Formular-Karte für ein unbekanntes Formular, basierend auf Benutzerdaten, die während des Ausfüllens des unbekannten Formulars durch den Benutzer geliefert wurden.
Verfahren nach einem der Ansprüche 14 bis 18, weiterhin folgenden Schritt umfassend: Verwaltung einer zusätzlichen Datenbank beim ersten Computerserver, wobei die zusätzliche Datenbank darin aufgezeichnete gespeicherte Formulardaten enthält und wobei die gespeicherten Formulardaten sich auf Formulare beziehen, welche vom zweiten Computerserver benötigt werden, dadurch gekennzeichnet, dass der zweite Computerserver einen Web-Server umfasst.
Verfahren nach Anspruch 21, weiterhin folgenden Schritt umfassend: syntaktisches Analysieren von Formulardaten von dem zumindest einen anderen Computerserver.
Verfahren nach Anspruch 21, weiterhin folgenden Schritt umfassend: syntaktisches Analysieren von Formulardaten von dem zumindest einen anderen Computerserver.
Verfahren nach Anspruch 23, weiterhin folgenden Schritt umfassend: Erstellen eines ausgefüllten Formulars durch das Ausfüllen des Blankoformulars unter Nutzung eines Ergebnisses des Vergleichens von Datenfeldern in einem Blankoformular mit gespeicherten Formulardaten.
Verfahren nach einem der Ansprüche 14 bis 24, weiterhin folgenden Schritt umfassend: syntaktisches Analysieren des Formulars, um festzustellen, welche der abgerufenen Daten genutzt werden sollten, um zumindest einen Teil des Blankoformulars auszufüllen.
Maschinenlesbares Medium, das Befehle enthält, welche, wenn sie von einem Computer gelesen werden, veranlassen, dass der Computer das Verfahren von einem der Ansprüche 14 bis 25 ausführt.