DE69923311T2

DE69923311T2 - Universelle formular-maschine

Info

Publication number: DE69923311T2
Application number: DE69923311T
Authority: DE
Inventors: Michael D. Hitchcock; James H. Wolfston Jr.; W. John STEDMAN; J. Andree HERTZ; Raymond L. Price
Original assignee: Collegenet Inc
Current assignee: Collegenet Inc
Priority date: 1998-06-04
Filing date: 1999-06-04
Publication date: 2006-03-16
Anticipated expiration: 2019-06-05
Also published as: US20090019351A1; US20020120628A1; AU763920B2; WO1999063454A1; CA2334169C; DE69923311D1; US20030145018A1; EP1084474A1; JP2002517823A; EP1084474B1; US7376891B2; US6460042B1; CA2334169A1; US6345278B1; AU4419599A; US20050080756A1

Description

Gebiet der Erfindung
Diese Erfindung betrifft ein computerimplementiertes Verfahren und eine Vorrichtung zum Verarbeiten von Formularen und insbesondere ein Verfahren und eine Vorrichtung zum Verarbeiten von individuell aufmachbaren Anmeldeformularen, die eine Information von einer erweiterbaren Datenbank gemeinsam nutzen.
Hintergrund der Erfindung
Die Verarbeitung von Collegezulassungs-Anmeldeformularen, die nachstehend beschrieben wird, stellt den aktuellen Zustand der Formularverarbeitung dar. Studenten, die sich an Colleges und Universitäten anmelden, stellen typischerweise eine separate Papieranmeldung für jede Institution, an der sie um Zulassung ersuchen, fertig. Jede Anmeldung wird dann zusammen mit einer Anmeldegebühr an die entsprechende Institution versandt.
Viele Institutionen würden den Anmeldeprozeß vereinfachen wollen, indem den Studenten ermöglicht wird, sich über das Internet anzumelden. Obwohl eine Internetanmeldung ermöglicht, daß eine Institution die Anmeldungsinformation elektronisch verarbeitet, muß ein Student dieselbe Information für jede nachfolgende Anmeldung an einer anderen Institution oder an derselben Institution für einen anderen akademischen Zeitraum erneut eingeben. Wenn die Institution das Anmeldeformular ändern will, muß die Institution überdies den Quellencode, der das Anmeldeformular erzeugt, typischerweise überarbeiten, wodurch Änderungen am Anmeldeformular aufwendig und unbequem gemacht werden.
Man könnte die Redundanz im Anmeldeprozeß verringern, indem Studenten ermöglicht wird, eine einzige, allgemeine Anmeldung fertigzustellen, die von einem Dritten bereitgestellt wird, der dann die Anmeldung zu irgendeiner festgelegten Institution übertragen würde. Solche Systeme würden es jedoch unmöglich machen, daß die Institutionen ihr Anmeldeformular individuell aufmachen. In einer Umgebung, in der Schulen um Spitzenstudenten konkurrieren, ist das Bild, das eine Schule potentiellen Studenten vermittelt, wichtig, und eine individuell aufgemachte Anmeldung kann helfen, das Bild, das die Schule erzeugen will, zu vermitteln. Die Fragen, die eine Schule bei ihrer Anmeldung stellt, spiegeln die Werte der Institution wider. Viele Schulen wollen eine Information, die von jener verschieden ist, die sich auf einem allgemeinen Formular befinden würde. Somit ist es unannehmbar für viele Institutionen, ein allgemeines Anmeldeformular zu verwenden.
Die meisten Institutionen verwenden daher weiterhin hauptsächlich Papieranmeldungen oder ihre eigenen Online-Anmeldungen mit den vorstehend beschriebenen Nachteilen. Überdies muß die Institution dann die Anmeldegebühr für Online-Anmeldungen verarbeiten, was erfordern kann, daß die Institution eine gewisse Sachkenntnis im elektronischen Handel hat.
WO 98/04976, veröffentlicht am 5. Februar 1998, beschreibt ein System, das einen Benutzer unterstützt, Formulare aus dem Internet fertigzustellen. Die Formulare werden heruntergeladen und eine durch einen Steuercode erzeugte "Blase" ermöglicht einem Benutzer, eine in ein Feld im Formular einzugebende Information auszuwählen. Das Programm kann auch die Tatsache nutzen, daß der Programmierer gewöhnlich ähnliche Namen für ein ähnliches Datenfeld verwendet, um Daten in ein Formular automatisch einzufügen, indem die Datenfeldnamen im Formular mit Kennzeichennamen in einer Datenbank verglichen werden und Daten eingefügt werden, wenn eine Übereinstimmung besteht. Dem Benutzer wird eine Gelegenheit gegeben, die Eingabe zu ändern, wenn die auf der Basis der übereinstimmenden Feldnamen eingefügten Daten falsch waren.
Zusammenfassung der Erfindung
Folglich ist es eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zum Verarbeiten von Formularen bereitzustellen. Diese Aufgabe wird durch ein Verfahren mit den Merkmalen von Anspruch 1 gelöst.
Es ist noch ein weiterer Aspekt der vorliegenden Erfindung, ein solches Verfahren bereitzustellen, das eine gemeinsame Datennutzung zwischen individuell aufmachbaren Formularen ermöglicht, wobei die individuelle Aufmachung das Kennzeichnen von Formularen für spezielle Institutionen umfaßt.
Es ist noch ein weiterer Aspekt der Erfindung, ein solches Verfahren bereitzustellen, das eine erweiterbare, sich Daten teilende Datenbank verwendet.
Es ist noch ein weiterer Aspekt der vorliegenden Erfindung, ein verbessertes Verfahren zum Verarbeiten von Zulassungsanmeldungen bereitzustellen.
Die vorliegende Erfindung umfaßt einen universellen Formularprozessor, der die Erzeugung und Verarbeitung von individuell aufmachbaren elektronischen Formularen und die selektive gemeinsame Nutzung einer Information zwischen den individuell aufgemachten Formularen ermöglicht. Ein Benutzer gibt folglich Daten nur einmal ein und die Daten werden über eine erweiterbare Datenbank zwischen ungleichen Formularen gemeinsam genutzt. Die Formulare werden von einem Benutzer über ein Computernetzwerk fertiggestellt und eine Information von jedem fertiggestellten Formular wird über ein Computernetzwerk zur entsprechenden Einheit weitergeleitet. Die Fähigkeit des Formularprozessors, ein Formular zur Benutzereingabe darzustellen, Daten vom Benutzer zu empfangen und die Daten zur entsprechenden Einheit zu liefern, ist von der Rechenplattform des Benutzers und der Einheit unabhängig. Irgendwelche Gebühren, die den Formularen zugeordnet sind, können über ein Computernetzwerk zusammen mit den Formularen elektronisch verarbeitet werden.
Die Erfindung erzeugt folglich Formulare, analysiert Daten auf Formularen, speichert Daten, ruft die Daten ab, und setzt die Daten auf anderen Formularen ein. Wenn zusätzliche Formulare fertiggestellt werden und eine zusätzliche Information ein Teil der Datenbank wird, nimmt die Menge an Information, die manuell in neue Formulare eingegeben werden muß, ab, da die neuen Formulare automatisch mit den vorher eingegebenen Daten gefüllt werden.
Ein Formular wird als im Wesentlichen ein Behälter für Daten betrachtet und impliziert einen zugehörigen Prozeß. Der Formularprozessor integriert das Formular, die Daten und die Verarbeitung ungeachtet des Aussehens des Formulars, der Art oder Bedeutung der Daten und der Verarbeitung, die der Sammlung der Daten folgt.
Metadaten, das heißt Informationen, die die Anmelderdaten kennzeichnen, werden auch gespeichert. In einem Ausführungsbeispiel beschreibt beispielsweise eine Attributtabelle Eigenschaften, wie z.B. zulässige Werte und Zugänglichkeit für verschiedenes Institutionspersonal, von Anmelderattributdaten. In einem weiteren Ausführungsbeispiel werden solche Eigenschaften der Anmelderattribute in XML-Dateien gespeichert. Das Speichern von Metadaten stellt eine größere Kontrolle über die Datenauswertung, die gemeinsame Nutzung zwischen Formularen, Gruppierung und Zugriff bereit.
Die Benutzerinformation und Anmeldungsinformation werden aus der Codierung entnommen, das heißt die Benutzerinformation und Anmeldungsinformation werden in einer Weise gespeichert, die ermöglicht, daß die Anmeldungsinformation und die Benutzerinformation ohne Umprogrammierung geändert werden. Diese Entnahme ermöglicht, daß der Satz von Benutzerdaten ohne Umprogrammierung erweitert wird, ermöglicht, daß die Benutzerdaten in verschiedenen Formaten in verschiedenen Anmeldungen angezeigt werden, ermöglicht, daß die Daten bewertet werden, um sicherzustellen, daß sie von den Institutionen verwendet werden können, und erleichtert den Zugriff auf die Information über das Web durch die Institutionen. Die Entnahme der Anmeldungsinformation ermöglicht, daß die Anmeldung selbst leicht verändert wird, und ermöglicht, daß Änderungen wie z.B. Änderungen an Anmeldungsdaten durch die Institutionen selbst vorgenommen werden. Die entnommene Information wird beispielsweise in einer relationalen Datenbank oder in einer XML-Datei gespeichert.
Der Gegenstand der vorliegenden Erfindung wird im abschließenden Teil dieser Beschreibung speziell aufgezeigt und deutlich beansprucht. Sowohl die Organisation als auch das Betriebsverfahren zusammen mit weiteren Vorteilen und Aufgaben derselben können jedoch am besten durch Bezugnahme auf die folgende Beschreibung in Verbindung mit den zugehörigen Zeichnungen verstanden werden, in denen sich gleiche Bezugszeichen auf gleiche Elemente beziehen.
Kurzbeschreibung der Zeichnungen
1 zeigt ein Netzwerk, über das Anmelder, ein Dienstleister und Institutionen verbunden sind, in einem bevorzugten Ausführungsbeispiel der Erfindung.
2 zeigt eine Eintrittswebseite, die einem Anmelder von 1 präsentiert wird.
3 zeigt eine Webseite, die die Ergebnisse einer Online-Collegesuche zeigt, die den Link zur Eintrittswebseite von 2 bereitstellte.
4 zeigt eine Webseite zum Erzeugen eines neuen Netzkontos beim Dienstleister von 1.
5 ist ein Diagramm, das schematisch zeigt, wie Netzkonten in einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung erzeugt werden.
6a–6d zeigen eine Webseite, die zum Liefern von Anweisungen und Informationen zum Anmelder von 1 verwendet wird.
7 zeigt eine Anmeldungsoptionsseite, die den Anmelder mit Links zu einer Anmeldungsanweisungsseite versieht.
8a–8d zeigen eine Anmeldungsanweisungsseite für eine Online-Anmeldung.
9a–9c zeigen die erste Seite einer Online-Zulassungsanmeldung.
10a–10c zeigen die zweite Seite einer Online-Zulassungsanmeldung.
11a und 11b zeigen die dritte Seite einer Online-Zulassungsanmeldung.
12a–12d zeigen die vierte Seite einer Online-Zulassungsanmeldung.
13 ist ein Diagramm, das schematisch den Dialogverkehr zwischen dem Anmelder, dem Formularprozessor und der Anmelderdatenbank während eines anfänglichen Zugriffs auf ein Anmeldeformular zeigt.
14 ist ein Diagramm, das schematisch den Dialogverkehr zwischen dem Anmelder, dem Formularprozessor und der Anmelderdatenbank zeigt, wenn Daten von einem Anmeldeformular abgesandt werden.
15 zeigt einen Ablaufplan des in 13 und 14 gezeigten Dialogverkehrs.
16 zeigt die Schritte, die in einem bevorzugten Ausführungsbeispiel vorkommen, wenn ein Anmelder den Formularprozessor kontaktiert.
17 zeigt die "Ausgangs"-Zustände, die während der Anmeldungsverarbeitung verfügbar sind.
18 ist ein vereinfachtes Beispiel von Klassen, die in einer objektorientierten Programmierimplementierung der Erfindung verwendet werden.
Ausführliche Beschreibung
Das System gemäß einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung umfaßt einen Formularprozessor, der Anmeldungen zur Zulassung zu Institutionen verarbeitet. Das bevorzugte Ausführungsbeispiel, das durch einen dritten Anmeldungsdienstleister betrieben wird, verwendet relationale Datenbanken zum Speichern von Informationen und steht mit Anmeldern und Institutionen über das World Wide Web in Verbindung. Die Erfindung ist jedoch nicht auf die Verarbeitung irgendeiner speziellen Art von Formular oder auf die Verwendung irgendeines speziellen Netzwerks oder irgendeiner speziellen Datenbank begrenzt.
Überblick über ein bevorzugtes Ausführungsbeispiel
1 zeigt mehrere Anmeldercomputer 14, die mit einem Server 16 über den Teil des Internets 18, der als World Wide Web (das Web) bekannt ist, in Verbindung stehen. Ein typischer Anmeldercomputer 14 umfaßt einen Personalcomputer wie z.B. einen auf Pentium basierenden Personalcomputer unter Verwendung eines auf Windows basierenden Betriebssystems, der einen kommerziell erhältlichen Webbrowser wie z.B. Netscape Navigator oder Internet Explorer betreibt. In einem bevorzugten Ausführungsbeispiel können die Anmeldercomputer 14 einen älteren Browser auf Textbasis verwenden, da die Verarbeitung wie z.B. Fehlerprüfung vielmehr am Server 16 als am Clientbrowser durchgeführt wird.
Der Server 16 ist ein Computer wie z.B. ein Sun Solaris UltraSparc Server, der einen Formularprozessor der vorliegenden Erfindung, sowie eine Webserver-Software, die Kommunikationen mit Besuchern auf der Formularprozessor-Website koordiniert, ausführt. Informationen und Formulare, die vom Server 16 übertragen werden, werden typischerweise in einer Hypertext-Markierungssprache (HTML) formatiert und können Text, Programme, Graphiken, Video- und Audioteile umfassen. Der Server 16 wird vorzugsweise von einem dritten Anmeldungsdienstleister 24 betrieben und ist mit einem sicheren Datenspeicher 26 verbunden. Ein Computer 28 mehrerer Institutionen, der von Institutionen wie z.B. Colleges oder Universitäten betrieben wird, die Zulassungsanmeldungen anfordern, steht auch mit dem Server 16 über das Internet 18 in Verbindung.
Obwohl das bevorzugte Ausführungsbeispiel der Erfindung unter Verwendung einer Internet-Website implementiert wird, ist die Erfindung nicht auf irgendeine spezielle Art von Computer oder Computernetzwerk begrenzt. Indem die Anmeldungen über das Web zur Verfügung gestellt werden, kann sich ein beliebiger Anmelder mit einem Webbrowser elektronisch anmelden. Eine Online-Anmeldung ermöglicht auch, daß die Anmeldegebühr online verarbeitet wird, so daß Kreditkartenbezahlungen, elektronische Bankeinzüge und andere Bezahlungsverfahren effizienter durchgeführt werden können und die Bezahlung durch den Dritten, der den Anmeldeformular-Prozessor betreibt, an dem mehrere Institutionen teilnehmen, leicht erleichtert werden kann.
2 zeigt eine Eintrittsseite 36, die einem Anmelder präsentiert wird, der auf den Server 16 von 1 zugegriffen hat. In einem bevorzugten Ausführungsbeispiel wird die Eintrittsseite 36 sowie alle anderen Seiten, die dem Anmelder präsentiert werden, als HTML-Seite präsentiert. Seiten, auf denen der Anmelder eine Information eingibt, verwenden das Kennzeichen HTML<FORM>. Das HTML-Formular sendet eine Information an den Server 16 ab, der ein übliches Gateway-Schnittstellen-(CGI) Programm ausführt, das vom Formular festgelegt wird, um die empfangene Information zu verarbeiten. Das CGI-Programm ist vorzugsweise in Perl, C, C++, Java oder einer anderen Sprache geschrieben, die CGI unterstützt. Das CGI-Programm greift auf eine Datenbank zu, die eine Information über das individuell aufgemachte Anmeldeformular und über den Anmelder umfaßt. Die Datenbank ist vorzugsweise eine relationale Datenbank, auf die unter Verwendung einer strukturierten Abfragesprache über ein Datenbankverwaltungssystem zugegriffen wird, wie z.B. Informix^® von Informix Software, Inc., mit Sitz in Menlo Park, Kalifornien. Die Erfindung ist nicht auf eine spezielle Implementierungstechnologie begrenzt. Es wird erwartet, daß sich die Implementierungsdetails der Erfindung ändern, wenn sich die Computertechnologie entwickelt.
Auf die Eintrittsseite 36 kann von der eigenen Seite des World Wide Web einer Institution zugegriffen werden und sie kann im selben Stil sein. Auf die Eintrittsseite 36 kann auch von anderen Links, beispielsweise durch einen Link 38 (3) auf einer Ergebniswebseite 40 von einer Online-Collegesuche wie z.B. dem System CollegeNET^TM zugegriffen werden, das vom Anmelder der vorliegenden Erfindung betrieben wird. Die Eintrittsseite 36 ist mit einem Logotyp 42 gekennzeichnet, der die Anmeldung als zu der Institution gehörend kennzeichnet, an die sie gerichtet ist, obwohl die Anmeldung vorzugsweise von einem Dritten beherbergt wird, um die gemeinsame Datennutzung über Institutionen und die elektronische Verarbeitung von Anmeldegebühren zu erleichtern.
Bevor von der Eintrittsseite 36 aus auf eine Anmeldung zugegriffen wird, muß jeder Anmelder ein Netzkonto beim Drittdienstleister 24 haben. Die Eintrittsseite 36 umfaßt einen Link 52 zum Erzeugen eines neuen Netzkontos. 4 zeigt ein Webseitenformular 54, das dem Anmelder präsentiert wird, um ein neues Netzkonto zu erzeugen. Obwohl das Netzkonto beim Drittdienstleister 24 liegt und verwendet werden kann, um an vielen Institutionen anzumelden, ist das Webseitenformular 54 mit dem Logotyp 42 der Institution, an der sich der Anmelder anmeldet, gekennzeichnet. Folglich ist es für den Anmelder durchschaubar, daß die Anmeldung vom Drittdienstleister 24 verarbeitet wird.
5 zeigt schematisch die Handlungen, die den Netzkontenerzeugungsprozeß 56 bilden, der zum Erzeugen eines Netzkontos erforderlich ist. Der Anmelder verwendet einen Webclient 58 wie z.B. Netscape Navigator, um eine persönliche Information wie z.B. Name, Adresse, Email-Adresse und einen Benutzernamen und ein Kennwort zum Zugreifen auf das System einzugeben. Das Kennwort wird verschlüsselt und zusammen mit dem Benutzernamen in einer Kennwortdatenbank 60 gespeichert, die mit dem Server 16 (1) verbunden ist, und die Benutzerinformation wird in einer Anmelderdatenbank 62 gespeichert, wobei die Datenbanken die Datenbank 26 umfassen.
Die Eintrittsseite 36 (2) stellt auch einen Informationslink 68 bereit, um die Anmeldung mit Anweisungen und Informationen zu versehen. 6a–6d zeigen eine bevorzugte Informationswebseite 70, die an den Benutzer als Reaktion auf eine Anforderung für Information zurückgegeben wird. Die Webseite 70 ist auch mit dem Logotyp 42 gekennzeichnet, der die Institution angibt, an die die Anmeldung gerichtet ist. Die Webseite 70 umfaßt einen Anmeldungsoptionsseitenlink 72 (6d) zur tatsächlichen Anmeldung, ebenso wie die Eintrittsseite 36. Die Eintrittsseite umfaßt auch einen Link 74 zur persönlichen Protokollseite des Benutzers. Das persönliche Protokoll beschreibt den Zustand aller Anmeldungen, die der Benutzer bearbeitet hat, einschließlich Anmeldungen, die übermittelt wurden, und Anmeldungen, die sich in verschiedenen Stufen der Fertigstellung befinden. Die Eintrittsseite 36 umfaßt auch einen Link 76 zum Ändern des Kennworts eines Benutzers.
7 zeigt eine Anmeldungsoptionsseite 82, die einen Anmeldungsanweisungsseitenlink 84, einen Anmeldungslink 86 und Links 92 zu ergänzenden Formularen wie z.B. Bericht eines Beraters oder Lehrerempfehlungsformularen bereitstellt, die eine Anmeldung begleiten. 8a–8d zeigen Anmeldungsanweisungen 94, die vom Anmeldungslink 86 aus erreicht werden.
9a–9c zeigen die erste Seite einer elektronischen Online-Zulassungsanmeldung 96, die hinsichtlich des Inhalts und Aussehens für eine spezielle Institution individuell aufgemacht ist. Wie in 9a gezeigt, ist jede Anmeldung individuell "gekennzeichnet", das heißt sie trägt den Namen und Logotyp 42 der Institution und erscheint in einem Stil, der für die Institution repräsentativ ist. Somit ist es für den Anmelder durchschaubar, daß ein Dritter die Anmeldung abarbeitet, das heißt der Anmelder kann sich nicht einmal bewußt sein, daß die Anmeldung von einem Drittdienstleister verarbeitet wird. Gemäß der Erfindung stellt der Drittdienstleister individuell aufgemachte Formulare für jede teilnehmende Institution bereit und Daten werden zwischen den individuell aufgemachten Anmeldungen gemeinsam genutzt. Information, die vorher in Verbindung mit früheren Anmeldungen an irgendeiner Institution eingegeben worden war, wird automatisch in das individuell aufgemachte Formular eingefügt. Die vom Anmelder in das Anmeldeformular eingegebene Information wird in einer Anmelderdatenbank zum automatischen Einfügen in anschließende Anmeldungen von diesem Anmelder gespeichert. Der HTML-Quellencode für die Seite 1 ist im Anhang 1 beigefügt. 10a–10c, 11a–11b und 12a–12d zeigen zusätzliche Seiten der Anmeldung 96.
13 zeigt schematisch die Beziehung untereinander, wenn Formularseiten an einen Anmelder zwischen einem Formularprozessor 104 der vorliegenden Erfindung, der Anmelderdatenbank 62, der Kennwortdatenbank 60 und dem Webbrowserclient 58, der auf dem Anmeldercomputer 14 läuft, geliefert werden. 13 zeigt, daß der Formularprozessor 104, der vorzugsweise als CGI-Programm implementiert wird, vier primäre Funktionen durchführt. Wenn der Anmelder ein Anmeldeformular für eine spezielle Institution anfordert und die Anforderung durch Vergleichen des Kennworts mit dem Kennwort in der Kennwortdatenbank 60 authentifiziert wird, ruft der Formularprozessor 104 die Benutzerinformation hinsichtlich des Zustands der Anmeldungen, die anhängig oder fertiggestellt sind, ab.
Der Formularprozessor 104 erzeugt dann ein individuell aufgemachtes Anmeldeformular auf der Basis einer Anmeldungsbeschreibung in einer Anmeldungsdatei 108. Der Formularprozessor 104 ruft dann Benutzerdaten ab, die bei vorherigen Anmeldungen eingegeben und in der Anmelderdatenbank 62 gespeichert wurden, und kombiniert die Benutzerdaten mit der aktuellen Anmeldung, die dann als HTML-Formular an den Anmelder zurückgegeben wird. Der Anmelder gibt dann irgendeine angeforderte Information ein, die nicht automatisch aus der Datenbank eingefügt wurde.
Die Anmeldung 96 umfaßt Felder für den Anmelder, um die spezifische Information einzugeben, die die Institution von ihren Anmeldern anfordert. Die Information wird in einem von der Institution gewählten Format angefordert. Der Stil und Inhalt der individuell aufgemachten Anmeldung drückt die von der Institution gehaltenen Werte aus. Der individuell aufgemachte Inhalt jeder Anmeldung ermöglicht, daß die Schule eine spezifische Information erhält, die sie wählt, um ihre Anmeldergruppe zu charakterisieren, einschließlich Faktoren, von denen sie annimmt, daß sie mit dem Studentenerfolg an der speziellen Institution korrelieren können.
14 zeigt schematisch den Dialogverkehr zwischen dem Formularprozessor 104, der Anmelderdatenbank 62 und dem Webclient 58 bezüglich des Formularprozessors 104, der Daten empfängt, die vom Anmelder abgesandt werden. Der Formularprozessor 104 führt eine "Vorfeld"-Bewertung an den abgesandten Daten 118 aus. Die Datenbewertung wird nachstehend im einzelnen erläutert. Wenn die Daten durch die Bewertung fallen, wird eine Datenkorrekturseite zum Anmelder gesandt. Wenn die Daten die Bewertung der ersten Stufe bestehen, wird die nächste Anmeldungsseite vorbereitet, indem die Anmelderinformation von der Anmelderdatenbank 62 mit der Formularinformation in der Anmeldungsdatei 108 vereinigt wird und die resultierende HTML-Anmeldungsseite zum Anmelder gesandt wird.
Nachdem alle Seiten die Bewertung der ersten Stufe bestanden haben und der Anmelder versucht, die fertiggestellte Anmeldung zur Institution zu übermitteln, wird eine Bewertung einer zweiten Stufe durchgeführt. Wenn die Bewertung der zweiten Stufe erfolgreich ist, werden Benutzerdaten 120 in die Anmelderdatenbank 62 geschrieben und Bezahlungsskripten 122 werden ausgeführt, in denen dem Benutzer eine Option gegeben wird, irgendeines von verschiedenen Online-Bezahlungsverfahren auszuwählen. Eine Kreditkarteninformation wird von einer Kreditkartendatenbank 124 überprüft. Nachdem die Information über die Anmeldung bewertet ist, wird sie zur Institution in einem Datenformat übertragen, das von der Institution festgelegt wird. Die Information wird auch zur Verwendung bei anschließenden Anmeldungen in einer Anmelderdatenbank 62 gespeichert, die von der Institution unabhängig ist.
15 ist ein Ablaufplan, der die Produkte in jedem Schritt der Verarbeitung durch den in 13 und 14 beschriebenen Formularprozessor 104 zeigt. Wahlweise Schritte sind in gestrichelten Linien gezeigt. 15 zeigt, daß ein Anmelder 126 den Formularprozessor 104 durch eine Browseranforderung für eine Anmeldung kontaktiert. Bevor einem Anmelder eine Anmeldeseite präsentiert wird, bestimmt der Formularprozessor 104 den Zustand des Anmeldeprozesses und präsentiert dem Anmelder nur entsprechende Seiten. Die meisten Institutionen weisen beispielsweise Anmeldungsdatenfenster auf, während denen Anmeldungen, ob elektronisch oder auf Papier, für einen speziellen Zeitraum angenommen werden. Der Formularprozessor überprüft, daß die Anmeldung innerhalb des zugelassenen Fensters übermittelt wird. Im Gegensatz zu vorgedruckten Papieranmeldungen versieht jedoch die Erfindung die Schulen mit der Flexibilität, das Anmeldedatenfenster leicht zu ändern, so daß die Zeit zum Anmelden verlängert werden kann, wenn die Institution zusätzliche Anmeldungen annehmen will.
Der Formularprozessor 104 verwendet Daten von der entsprechenden Anmeldungsdatei 108 (14) und vorher eingegebene Benutzerdaten, um eine Seite eines Formulars 128 zu erzeugen. Die Daten 130 werden auf der Formularseite durch den Anmelder oder von der Datenbank eingegeben und die Seite wird einer Datenbewertung 136 der ersten Stufe unterzogen, nachdem sie vom Anmelder abgesandt wurde. Ein Korrekturseitenformular wird an den Anmelder jedes Mal übermittelt, wenn eine Datenbewertung fehlschlägt, und die Daten werden nach einer erfolgreichen Bewertung in der Datenbank gespeichert. Der Prozeß wird für zusätzliche Seiten wiederholt, bis das Formular fertiggestellt ist und der Anmelder das Formular übermittelt.
Wenn der Anmelder angibt, daß die Anmeldung zur Übermittlung an die Institution bereit ist, wird eine letztliche, gründlichere Bewertung 136, die als Bewertung der zweiten Stufe bekannt ist, an den Daten durchgeführt. Die Bewertung der zweiten Stufe stellt sicher, daß die Information, die für die spezielle Institution erforderlich ist, an die die Anmeldung gerichtet ist, vorhanden ist und daß die Information bestimmte Inhaltskriterien erfüllt, die von der Institution festgelegt werden. Die Datenbewertung ist für jede Institution individuell aufgemacht. Wenn die Anmeldung durch die Bewertung der zweiten Stufe fällt, wird eine Datenkorrekturseite an den Anmelder zurückgegeben. Die bewerteten, übermittlungsfähigen Daten 140 werden in der Anmelderdatenbank 62 in Verbindung mit der Anmeldung gespeichert. Die Daten werden dann verarbeitet und transformiert 142, wie nachstehend in Verbindung mit Pseudonymen beschrieben, und zur Verwendung in anderen Formularen, die der Anmelder in der Zukunft fertigstellen kann, gespeichert. Eine Bezahlung 148 wird dann verarbeitet und eine Anmeldungstransaktionsverarbeitung 150 wird durchgeführt. Der Formularprozessor wandelt dann die Anmeldungsinformation in eine Form um, die mit den internen Datenbanken der Institution kompatibel ist, und liefert die Information 152 an die Datenbank 154 der Institution.
Wenn sich der Anmelder anschließend an einer anderen Institution oder an einem anderen Programm innerhalb derselben Institution anmeldet, wird eine neue Anmeldung, die für die andere Institution individuell aufgemacht ist, dem Anmelder präsentiert. Die Information, die bei vorher übermittelten Anmeldungen eingegeben wurde, wird aus der Datenbank abgerufen und dem Anmelder als gefüllte Felder der neuen Anmeldung präsentiert, so daß der Anmelder die Information nicht mehr als einmal eingeben muß. Der Anmelder kann die Werte in einem vorgefüllten Feld ändern, falls dies erwünscht ist, und die neuen Werte werden zur Verwendung bei anschließenden Anmeldungen gespeichert.
Wie nachstehend genauer beschrieben, wird die Information über die Anmelder als Satz von Attributen verwaltet, wobei jedes Attribut Datenbankfeldern entspricht. Wenn eine Institution wählt, in ihre Anmeldung eine Anforderung für ein Anmelderattribut einzuschließen, das nicht einem, das in der Datenbank enthalten ist, entspricht, wird die Datenbank leicht erweitert, so daß sie die neuen Anmelderattribute enthält, ohne den Formularprozessor umzuprogrammieren. Sobald das neue Attribut zur Datenbank hinzugefügt ist, steht es zum automatischen Aufnehmen in alle anschließenden Anmeldungen zur Verfügung.
Im bevorzugten Ausführungsbeispiel weist jedes zum Charakterisieren von Anmeldern verwendete Attribut einen eindeutigen Identifikator oder ein eindeutiges Pseudonym auf. Der eindeutige Identifikator ermöglicht, daß der Prozessor erkennt, wenn dieselbe Information durch verschiedene Bezeichnungen beschrieben wird oder in einem anderen Format auf anderen Anmeldeformularen eingegeben wird. Die Information kann dann zweckmäßig gespeichert und in anschließende Anmeldungen eingefügt werden, ungeachtet von Unterschieden im Eingabeformat und den Bezeichnungen in der ersten und anschließenden Anmeldungen. Somit können die Variablen universell sein und eindeutige Datenelemente mit verschiedenen Namen können unter den Anmeldungen gemeinsam genutzt werden.
Eine Institution kann beispielsweise bei ihrer Anmeldung auf den Nachnamen eines Anmelders als "Familiennamen" Bezug nehmen, während eine andere Institution auf den Nachnamen als "Nachnamen" (surname) oder "Nachnamen" (last name) Bezug nehmen kann, und dennoch würde der Formularprozessor die Daten korrekt zwischen solchen Anmeldeformularen gemeinsam nutzen. Wenn als weiteres Beispiel ein erstes Anmeldeformular eine Information vom Auswahltyp in Form von Optionsschaltflächen anfordert und das zweite Formular dieselbe Information in Form eines Balkenmenüs anfordert, würde die im ersten Formular in den Optionsschaltflächen eingegebene Information in einem Balkenmenükasten im zweiten Formular erscheinen.
Obwohl die Institution mit der Flexibilität versehen wird, die Information in einer beliebigen Weise, die sie auf ihrer individuell aufgemachten Anmeldung wählt, zu bezeichnen und anzufordern, ist die Information bei anschließenden Anmeldungen ungeachtet dessen abrufbar, wie die anschließenden Anmeldungen die Information bezeichnen oder anzeigen. Der Formularprozessor der vorliegenden Erfindung kann somit eine Information über Anmeldungen ungeachtet dessen, wie die Information in einer speziellen Anmeldung ausgedrückt wird, gemeinsam nutzen, wenn nicht die Daten als privat für eine spezielle Anmeldung und nicht gemeinsam nutzbar festgelegt wurden, wie nachstehend beschrieben.
Jedes Anmelderattribut ist durch eine oder mehrere Eigenschaften gekennzeichnet. Die Eigenschaften, die die Attribute eines Anmelders kennzeichnen, können beispielsweise festlegen, ob und unter welchen Bedingungen die Attributdaten zwischen Formularen gemeinsam genutzt werden können, ob das Attribut ein universell erforderliches Feld ist oder ob das Attribut für einen speziellen geographischen Bereich spezifisch ist. Ein "kalifornische Führerscheinnummer" genanntes Attribut ist beispielsweise nur auf Institutionen in Kalifornien anwendbar. Eine andere Information kann auf alle Institutionen innerhalb eines Bereichs, aber nicht auf andere Institutionen anwendbar sein. Einige Anmelderattribute sind nur auf Institutionen in einem speziellen Schulsystem anwendbar. Einzelne Informationsstücke können auch gruppiert werden und Eigenschaften können für die Gruppen festgelegt werden. Die Anmeldung kann auch eine Information umfassen, die die Leitung der Information zu Gruppen, wie z.B. Finanzhilfebeamte, innerhalb der Institution festlegt.
Die Erfindung ermöglicht nicht nur, daß eine Anmeldung für jede Institution individuell aufgemacht wird, sie ermöglicht, daß die von Anmelder übermittelte Information zu jeder Institution in einem beliebigen Datenformat übertragen wird, das die Institution anfordert, so daß die Institution die Daten nicht in ein brauchbares Format umwandeln muß. Mehrere Felder, wie z.B. Vorname und Nachname, können beispielsweise zu einem einzelnen Feld kombiniert werden und die Datenfelder können durch ein von der Institution festgelegtes Begrenzungszeichen begrenzt werden. Die Daten können auch beispielsweise als Namen-Wert-Paare, als feste Datensätze, in EDI- oder druckfähigem PDF-Format zur Institution übertragen werden. Somit wird die Anmelderinformation in einer individuell aufmachbaren Form an einem Browser eingegeben, der auf einer beliebigen Art von Computerplattform läuft, und beim Drittdienstleister 24 in einer Datenbank gespeichert. Die Information in der Datenbank ist dann in ein anderes individuell aufmachbares Anmeldeformular für eine andere Institution wiederladbar. Die Information ist auch zu einer Institution in ihrem bevorzugten Format ungeachtet der von der Institution zum Verarbeiten der Information verwendeten Plattform übertragbar. Nachdem eine Anmeldung zu einer Institution gesandt ist, bleibt die Information in der Datenbank des Drittdienstleisters für eine weitere Analyse durch die Institution verfügbar. Die Institution kann Anmelder beispielsweise auf der Basis von Attributen, wie z.B. Testpunktwerten, Notendurchschnitt, Teilnahme an Sport oder musikalischem Talent, sortieren oder betrachten. Überdies weist jedes Anmelderattribut eine Eigenschaft auf, die verwendet werden kann, um festzulegen, wer in der Institution Zugriff auf das Attribut für den Zweck des Hochladens der Information oder der Verarbeitung der Information zum Charakterisieren der Anmeldergruppe hat. Teile einer Anmeldung, die sich mit akademischem Hintergrund befassen, können beispielsweise von akademischen Fachbereichen betrachtbar sein, wohingegen eine persönlichere Information nur von Schulverwaltern betrachtbar sein kann.
Eine bevorzugte Implementierung der Erfindung umfaßt ein einzelnes Formularprozessorprogramm, eine einzelne Anmelderdatenbank, einschließlich der Information über alle Anmelder, und eine Anmeldungsdatei für jede unterschiedliche Anmeldung von jeder der teilnehmenden Institutionen. Die Anmeldungsdatei beschreibt das Format jeder Anmeldung und der Formularprozessor zeigt eine Information von der Datenbank in dem Format an, das von der Anmeldungsdatei vorgeschrieben wird.
Die Anmelderdatenbank kann erweitert werden, um neue Attribute aufzunehmen, ohne irgendwelche Änderungen an dem Formularprozessorprogramm oder an den Anmeldungsdateien von Institutionen, die wählen, die neuen Daten nicht aufzunehmen, vorzunehmen. Der Formularprozessor verwendet die Anmeldungsdatei automatisch, um die angeforderte Anmeldung im HTML-Format zur Anzeige auf dem Browser des Anmelders zu erzeugen. Die Anmeldungsbeschreibungsdatei kann leicht modifiziert werden, beispielsweise um Bezeichnungen zu ändern oder zusätzliche Felder hinzuzufügen. Das Aussehen der Anmeldung für jede Institution kann durch Ändern ihrer Anmeldungsbeschreibungsdatei geändert werden, ohne den Formularprozessor umzuprogrammieren. Die fertiggestellte Anmeldung wird mit den Daten in einem beliebigen Format, das die Institution bevorzugt, zur Institution übertragen. Die Institution kann daher die Daten direkt in ihre Anmelder- oder Studenteninformations-Systemdatenbank hochladen, wobei die Information nahtlos in ihren existierenden Arbeitsablauf übergeht, wodurch der zusätzliche Aufwand und Fehler der erneuten Tastatureingabe der Information vermieden werden. Der Formularprozessor hat somit die Fähigkeit, die Anmeldungsinformation universell über Plattformen auszugeben.
Eine Transaktionsdatenbanktabelle und eine Transaktionsoperationstabelle verfolgen vollendete Transaktionen und Operationen, um den Prozessor beim Verwalten der Information über den Zustand jeder Anmeldung zu unterstützen, so daß dem Anmelder nur geeignete Seiten präsentiert werden. Diese Tabellen ermöglichen auch, daß der Anmelder den Fortschritt seiner Anmeldungen und die Online-Bezahlung verfolgt.
Datenbankstruktur
Die nachstehend beschriebenen Tabellen werden in einem bevorzugten Collegezulassungs-Formularverarbeitungssystem verwendet. Die Erfindung kann zum Verarbeiten vieler verschiedener Arten von Formularen verwendet werden, ohne vom Schutzbereich der Erfindung abzuweichen, und Fachleute werden erkennen, daß verschiedene Datenbankstrukturen bei verschiedenen Anmeldungen erforderlich sind.
Attributtabelle
Eine erste Datenbanktabelle, die Attributtabelle, umfaßt eine Liste aller Attribute, die zum Beschreiben eines Anmelders verwendet werden können. Die Attributtabelle definiert somit den Variablenraum für das ganze System. Jedes Attribut, wie z.B. Name, Sozialversicherungsnummer und SAT-Punktwert, wird durch eine Zeile der Attributtabelle dargestellt und wird durch eine eindeutige Attributidentifikationsnummer identifiziert. Die Attributtabelle umfaßt Eigenschaften jedes Attributs, wie z.B., ob das Attribut ein erforderliches Feld für die Bewertung der ersten Stufe (nachstehend erläutert) ist und ob das Attribut ein Teil einer Datengruppe ist, wie z.B. ein geographischer Bereich oder eine Institutionsgruppe. Die Attributtabelle umfaßt auch Verweise auf Bewertungsregeln der ersten Stufe, falls vorhanden, für alle Attribute. Die Attributtabelle umfaßt nicht Werte des Attributs für irgendeinen speziellen Anmelder.
Benutzerattributtabelle
Die Attributen für einzelne Anmelder zugewiesenen Werte werden in einer Benutzerattributtabelle gespeichert. Jede Zeile der Tabelle umfaßt eine Benutzeridentifikation, eine Attributidentifikationsnummer, eine Sequenz für die Attributidentifikationsnummer und einen Datenwert. Wenn ein Anmelder eine Information in eine Anmeldungsseite im Web eingibt und das Formular an den Server absendet, wird die vom Anmelder eingegebene Information in der Benutzerattributtabelle nach der Bewertung der ersten Stufe gespeichert. Das Formular wird abgesandt, wenn der Anmelder zu einer anderen Seite wechselt oder wenn der Anmelder angibt, daß die Information gespeichert werden soll. Ein Anmelder kann die Werte eines Attributs von einer Anmeldung zur anderen ändern. Ein Anmelder kann beispielsweise seine SAT-Punktwerte ändern, um neue Testergebnisse widerzuspiegeln.
Die Benutzerattributtabelle umfaßt immer die letzte Information, die ein Anmelder eingegeben hatte, und wird verwendet, um eine Information für neue Anmeldungen zu liefern. Wenn der Benutzer eine Anmeldung zur Vollendung aufruft, werden Daten aus der Benutzerattributtabelle gelesen. Wenn eine neue Anmeldung Attribute umfaßt, die von keiner Anmeldung angefordert wurden, die der Benutzer vorher fertiggestellt hat, wird eine neue Zeile, die dem neuen Attribut entspricht, in die Benutzerattributtabelle eingefügt. Vorzugsweise umfaßt eine einzelne Benutzerattnibuttabelle die Attributinformation über alle Anmeldungen in dem System.
Tabelle für gesandte Benutzerattribute
Nachdem eine Anmeldung vollendet ist und sie die Bewertung der zweiten Stufe besteht, wird die in der Anmeldung enthaltene Information in einer Tabelle für gesandte Benutzerattribute gespeichert, die einen Schnappschuß der übermittelten Anmeldung darstellt. Die Struktur der Tabelle für gesandte Benutzerattribute ist zu jener der Benutzerattributtabelle sehr ähnlich. Der Hauptschlüssel der Benutzerattributtabelle ist ein Benutzeridentifikator (der Einlogname des Benutzers), wohingegen der Hauptschlüssel der Tabelle für gesandte Benutzerattribute ein Transaktionsidentifikator ist, der eine eindeutige Kombination von Benutzer, Anmeldung und Anmeldungszeitraum identifiziert. Somit können mehrere Datensätze für einen einzelnen Benutzer in der Tabelle für gesandte Benutzerattribute vorhanden sein, wenn der Benutzer mehrere Anmeldungen oder dieselbe Anmeldung für verschiedene Anmeldungszeiträume übermittelt hat.
Der Transaktionsidentifikator ist derselbe Identifikator, der in der nachstehend beschriebenen Transaktionstabelle verwendet wird. Somit kann man die Transaktionstabelle nach Transaktionsidentifikatoren abtasten, die Anmeldungen entsprechen, die als übermittelt gezeigt sind, und dann diese Identifikatoren verwenden, um Daten, die diese Anmeldungen betreffen, in der Tabelle für gesandte Benutzerattribute nachzuschlagen.
Die Bewertung der zweiten Stufe wird durchgeführt, bevor ein Datensatz in die Tabelle für gesandte Benutzerattribute geschrieben wird, und kann beispielsweise Felder wie z.B. Nachname und Vorname in ein einziges Feld kombinieren. Somit zeigt die Tabelle für gesandte Benutzerattribute exakt das, was zur Institution gesandt wurde, und umfaßt daher einen Datensatz für jede Anmeldung, die von einem Benutzer fertiggestellt wurde. Um durchzusehen, welche Daten gesandt wurden, sieht die Institution Informationen durch, die von den Datensätzen in der Tabelle für gesandte Benutzerattribute gewonnen werden, die dann in ein von der Institution angefordertes Format gebracht werden.
Anmeldungstabelle
Jede individuell aufgemachte Anmeldung wird innerhalb einer Anmeldungstabelle dargestellt, die den Datensatz für jede Anmeldung definiert. Jede Zeile in der Anmeldungstabelle betrifft ein Attribut in einer speziellen Anmeldung und umfaßt Informationen wie z.B. eine Anmeldungsidentifikationsnummer, eine Attributidentifikationsnummer, eine Attributsequenznummer innerhalb der Anmeldung, irgendwelche Regeln für die Bewertung der zweiten Stufe (nachstehend beschrieben), die Identifikationsnummer der Institution, zu der die Anmeldung gehört, usw.
Anmeldungsdatei
Die Anmeldungsdatei ist eine speziell formatierte Textdatei, die als Anmeldungsbeschreibung wirkt. Es handelt sich um eine Reihe von "Anweisungen" und wahlweisen Argumenten, die der Formularprozessor analysiert, um das HTML-Formular zu konstruieren und die Benutzerdaten einzufügen. Die Anweisungen werden mittels eines Nachschlags in einer Datenstruktur interpretiert, die die Anweisungsinterpretationen speichert. Eine Zeile in der Anmeldungsdatei kann beispielsweise "SS_NUM" sein. Nach dem Antreffen der Zeile schaut der Formularprozessor in eine Datenstruktur, um SS_NUM zu interpretieren. SS_NUM kann beispielsweise bedeuten, ein Textkästchen mit einer Bezeichnung anzuzeigen, die sich als "Geben Sie Ihre Sozialversicherungsnummer ein" liest, und den vorher gelieferten Wert für die Sozialversicherungsnummer (in der Benutzerattributtabelle gespeichert) in das Textkästchen einzusetzen. SS_NUM kann auch eine minimale Länge, maximale Länge vorschreiben und eine Funktion aufrufen, die das Texteingabekästchen erzeugt. Die Anweisung könnte auch Kennzeichen setzen, die einen speziellen Zustand für die Anmeldung angeben. Die Anmeldungsdatei kann wahlweise Argumente zu Anweisungen liefern. Argumente können beispielsweise den Formularprozessor anweisen, spezielle Bezeichnungen anzuwenden oder Vorgabewerte außer Kraft zu setzen, so daß die Bezeichnung oder das Format zur Eingabe der Daten individuell aufgemacht werden kann. Die Information in der Anmeldungsdatei könnte alternativ in der Anmeldungstabelle enthalten sein.
In einem alternativen Ausführungsbeispiel wird die Anmeldung, anstatt daß die Anmeldungsinformation als Anweisungen gespeichert wird und die Anmeldung aufgebaut wird, sobald ein Student sie online aufruft, durch ein Vorprozessor-Dienstprogramm aufgebaut, das einmal laufen lassen wird, um eine "Anmeldungsvorlage" mit einer regulierten Syntax zu erzeugen. Mit anderen Worten, ein Anmeldungsdateieintrag wie z.B. "SS_NUM" wird gegen eine Vorlagenzeile wie z.B. "SS_NUM|ITEXT|Sozialversicherungsnummer:|11|11" ausgetauscht.
Im vorher beschriebenen Ausführungsbeispiel stellen die Anmeldungsdateizeilen Funktionsaufrufe mit wahlweisen Argumenten dar. Der Formularprozessor führt diese Funktionsaufrufe aus, welche wiederum eine Formularelementerzeugungsfunktion wie "ITEXT", die ein Textkästchen erzeugt, ausführen. Somit muß der Formularprozessor nicht nur Hunderte von Funktionen zur Verfügung haben, er muß auch zwei (oder mehr) Ebenen der Funktionsausführung für jede Zeile in der Anmeldungsdatei ausführen.
Im alternativen Ausführungsbeispiel wird das meiste dieser Verarbeitung offline während der Anmeldungsentwicklungsphase durchgeführt und die Ergebnisse der Verarbeitung werden in der Vorlagendatei gespeichert. Der Online-Formularprozessor zieht dann diese "vorverdaute" Vorlagendatei ein. Jede Zeile der Vorlagendatei ist eine durch einen Filter "|" getrennte Liste von (1) Variablenname; (2) Formularelement [beispielsweise ist das Formularelement ITEXT ein Testkästchen, IRADIO ist (sind) (eine) Optionsschaltfläche(n) usw.]; (3) Fragebezeichnung; und (4) Argumente, die für die Formularelementfunktion erforderlich sind.
Während der Formularprozessor im ersten Ausführungsbeispiel zu einem Interpretierer analog ist, der eine Schalen-Befehlsdatei ausführt, ist die Vorlage im zweiten Ausführungsbeispiel zu einem kompilierten Code analog. Die Vorverarbeitung ist zu einer Kompilierungsphase analog und die Ausgangsvorlagendatei ist zu einem binären Objekt analog. Es besteht aus Befehlen für den Prozessor wie ein kompilierter Code aus Befehlen für die CPU besteht, während die Masse des Formularprozessors im ersten Ausführungsbeispiel einen Code umfaßt, um die Interpretation durchzuführen, weist der Formularprozessor im zweiten Ausführungsbeispiel einen sehr kleinen Befehlssatz auf: grundsätzlich einen Befehl pro Formularelement, plus einer Hand voll Spezialbefehlen.
Die Vorlagendatei gibt dem Anmeldungsentwickler absolute Freiheit, die Anmeldung ohne Bedarf, einen Programmcode für den Formularprozessor umzuschreiben oder hinzuzufügen, schnell zu aktualisieren. Die Verwendung von Vorlagen verringert auch die Anzahl von Funktionen, die für den Prozessor erforderlich sind, sowie den Ausführungsmehraufwand drastisch.
Die Vorlagendatei kann in Form von speziell gekennzeichneter HTML vorliegen; das heißt anstelle eines Satzes von Anweisungen Zeile für Zeile kann die Vorlage wie HTML mit eingebetteten speziellen Kennzeichen aussehen, die das Formularelement/die Variable/den Wert zur Interpolation darstellen.
Nachstehend befindet sich ein Beispiel, das der Deutlichkeit halber vereinfacht ist, eines Teils einer in einer speziell gekennzeichneten HTML dargestellten Vorlage.
Um die Vorlage zu verarbeiten, muß der Formularprozessor nur nach Abschnitten <QUESTION>...</QUESTION> suchen und sie analysieren. Viele andere Logikstücke könnten auch in die Vorlagen eingebettet werden. Die Ausgabe der verarbeiteten Vorlage ist ein HTML-Formular, das vom Studenten, der die Anmeldung fertig stellt, betrachtbar ist. Die Ausgabe aus dem obigen Vorlagen-Codestück könnte ebenso aussehen, wobei die speziellen QUESTION-Kennzeichen in HTML-Formatelemente umgewandelt sind und Benutzerdaten integriert sind:
Die obige Seite wird dann zum Benutzer übertragen.
Institutionstabelle
Die Institutionstabelle umfaßt eine Zeile für jede Institution. Jede Zeile umfaßt einen Institutionsidentifikator, einen Institutionsnamen, einen Identifikator für eine Mutterinstitution, falls vorhanden, und weitere Informationen über die Institution.
Institutionen können auch in einer Hierarchie angeordnet werden, wobei eine Institution zu einer anderen Institution gehört. Die Institutionstabelle ermöglicht die Konstruktion einer willkürlichen Hierarchie von Institutionen, die verwendet werden kann, um den Datenzugriff zu steuern. Informationen in der Kontakttabelle (nachstehend beschrieben) und Attributtabelle werden mit Informationen in der Institutionstabelle kombiniert, um den Zugriff auf spezielle Attribute in Anmeldungen festzulegen. Ein Finanzhilfebeamter in der medizinischen Schule einer Universität kann beispielsweise nur Zugang zu Finanzinformationen über die Anmeldung der medizinischen Schule haben, wohingegen ein Finanzhilfebeamter der Universität oder des Universitätssystems Zugang zu Finanzinformationen über alle Anmeldungen haben kann. Somit ermöglicht die Erfindung eine flexible Kontrolle der Daten bis auf die Attributebene hinab.
Institutionen können geographisch oder nach anderen Eigenschaften gruppiert werden. Die Institutionstabelle kann Felder aufweisen, die angeben, zu welchen Gruppen die Institution gehört. Somit kann der Formularprozessor Attribute steuern, die nur für Institutionen in einer speziellen Gruppe relevant sind.
Kontakttabelle
Die Kontakttabelle legt die Datenbankzugriffsberechtigungen von Leuten innerhalb einer Institution fest. Ein Verwalter in einem staatlichen Universitätssystem kann beispielsweise Zugriffsrechte auf Daten von Anmeldungen an allen Universitäten innerhalb des Systems haben, wohingegen ein Verwalter an einer speziellen Schule nur auf Anmeldungen an dieser Schule Zugriff haben kann.
Jede Zeile in der Kontakttabelle umfaßt einen eindeutigen Kontaktidentifikator, einen Institutionsidentifikator, der die Institution oder Gruppe von Institutionen definiert, auf die Zugriff gewährt wird, und die Operationen, die für den Kontakt zugelassen werden. Einem Kontakt können beispielsweise Rechte gewährt werden, um den Empfang einer Anmeldung zu bestätigen, Anmeldungsdaten unter Verwendung eines Dateiübertragungsprotokolls (FTP) zu übertragen oder eine druckbare, nicht-editierbare Version einer fertiggestellten Anmeldung zu empfangen.
Die Kontakttabelle kann auch zusätzliche nützliche Informationen enthalten, wie z.B. die E-Mail-Adresse oder den letzten Einlogzeitpunkt für den Kontakt.
Zeitraumtabelle
Die Zeitraumtabelle gibt die Anmeldungszeiträume an, die gerade zur Verfügung stehen. Jede Zeile der Zeitraumtabelle umfaßt einen eindeutigen Zeitraumidentifikator, einen Zeitraumschlüssel, die Start- und Ablaufdaten für Anmeldungen an der Institution für den Zeitraum, eine Textbeschreibung des Zeitraums und einen von der Institution definierten Zeitraumcode. Der von der Institution definierte Zeitraumcode wird verwendet, wenn Daten zur Institution hochgeladen werden, so daß die Daten nahtlos in das Informationssystem der Institution ladbar sind. Die nachstehend beschriebene Institutionsanmeldungstabelle definiert die für jede Institution verfügbaren Anmeldungen und umfaßt ein Zeitraumschlüsselfeld, das die Zeiträume identifiziert, für die die Anmeldung verwendet werden kann.
Institutionsanmeldungstabelle
Eine Institution, die durch eine Zeile in der Institutionstabelle dargestellt wird, kann mehrere Anmeldungen besitzen, von denen jede durch eine Zeile in der Institutionsanmeldungstabelle dargestellt wird. Eine Institution kann beispielsweise eine Anmeldung für Erstsemesterstudenten, eine weitere für überwechselnde Studenten, noch eine weitere für internationale Studenten usw. haben.
Die Institutionsanmeldungstabelle umfaßt eine Zeile für jede von einer Institution besessene Anmeldung und bringt die Informationen in den Anmeldungstabellen mit den in der Institutionstabelle beschriebenen Institutionen in Beziehung. Jede Zeile in der Institutionsanmeldungstabelle umfaßt einen Anmeldungsidentifikator, einen Institutionsidentifikator, den Zustand der Anmeldung, die Art der Anmeldung und eine Information, die die spezielle Anmeldung betrifft (d.h. Name, Campus etc.). Jede Zeile umfaßt auch einen Zeitraumschlüssel, der mit der Zeitraumtabelle verwendet wird, um festzulegen, welche Zeiträume gerade zur Anmeldung unter Verwendung der Anmeldung zur Verfügung stehen. Die Institutionsanmeldungstabelle kann auch eine Information über die Anmeldungsbearbeitungsgebühr und, wie die Gebühr zwischen der Institution und dem Prozessor zugeordnet wird, umfassen.
Transaktionsoperationstabelle
Jedesmal, wenn ein Anmelder eine Operation durchführt, wie z.B. Speichern einer Informationsseite, wird der Operation eine eindeutige Operationsidentifikationsnummer zugewiesen und eine neue Zeile wird zur Transaktionsoperationstabelle hinzugefügt. Jede Zeile der Transaktionsoperationstabelle umfaßt den eindeutigen Operationsidentifikator, einen Transaktionsidentifikator (nachstehend mit der Transaktionstabelle beschrieben), einen Code, der angibt, welche Operation die Zeile darstellt, einen Kontaktidentifikator und eine Zeitmarke, die das Datum und die Zeit der Operation angibt. Operationen umfassen beispielsweise Speichern, Speichern und Senden, Bestätigung, sichere Kreditkarte, keine Gebühr, ungültig und druckfähige Anmeldung betrachten.
Die Transaktionsoperationstabelle und die nachstehend beschriebene Transaktionstabelle werden verwendet, um die Zustandsinformation zu verwalten.
Transaktionstabelle
Eine Transaktionstabelle umfaßt Informationen über jede Benutzertransaktion, das heißt jede Anmeldung, auf die ein Benutzer zugegriffen hat und die er gespeichert hat. Jeder Eintrag in der Transaktionstabelle umfaßt einen eindeutigen Transaktionsidentifikator, einen Benutzeridentifikator, einen Anmeldungsidentifikator, einen Zeitraumidentifikator und einen Code, der den Zustand der Anmeldung angibt. Der Transaktionsidentifikator stellt eine eindeutige Kombination aus Benutzeridentifikator, Anmeldungsidentifikator und Anmeldungszeitraum dar. Es ist exakt eine Zeile in der Transaktionstabelle für jeden Transaktionsidentifikator vorhanden. Der Anmeldungszustand kann beispielsweise "im Gang", "übermittelt", "Bezahlung empfangen" und "durch die Institution bestätigt" usw. sein. Jeder Eintrag umfaßt auch einen Reihenfolgeidentifikator, eine Textzeichenkette, die den Benutzeridentifikator, den Anmeldungsidentifikator und eine Zeitmarke enthält. Der Reihenfolgeidentifikator wird für Kreditkartenbegleichung und in Übereinstimmung mit der Institution verwendet.
Wenn ein Benutzer auf eine Anmeldung zugreift, sucht der universelle Formularprozessor nach einer existierenden Transaktion, die den Benutzer und die angeforderte Anmeldung und den Zeitraum beinhaltet. Wenn eine solche Transaktion existiert, hängt die Antwort des Formularprozessors an den Benutzer vom Zustand der Transaktion ab. Wenn keine solche Transaktion existiert (d.h. dies der erste Zugriff auf diese Anmeldung durch den Benutzer ist), wird eine neue Transaktion begonnen. Ein neuer Eintrag wird in die Transaktionstabelle eingefügt. Ein Transaktionsidentifikator wird zugewiesen, wenn der Benutzer eine explizite Speicheroperation oder eine Operation "Speichern und Senden" für die neue Anmeldung anfordert. Ein Transaktionsidentifikator wird nicht lediglich auf der Basis eines Seitenwechsels auf einem mehrseitigen Formular zugewiesen.
Sobald der Benutzer die Schaltfläche "Speichern, Bezahlen und Senden" auswählt, werden die Felder Zeitraum, Zeitraumidentifikator und Reihenfolgeidentifikator gefüllt und der Zustand wird so festgelegt, daß er angibt, daß die Anmeldung übermittelt wurde. Nach der Bezahlung wird ein Bezahlungsoperationsfeld mit dem Operationsidentifikator für die Bezahlungsoperation gefüllt und der Zustand wird so gesetzt, daß er angibt, daß die Bezahlung empfangen wurde. Dies fährt fort, wenn sich die Transaktion durch die Bezahlung, Bestätigung usw. bewegt.
Anmelderseiten
Anmelderseiten sind diejenigen, die dem Anmelder präsentiert werden. Diese umfassen tatsächliche Anmeldungsseiten, die durch den Formularprozessor erzeugt werden und mit Bezeichnungen, die die angeforderten Informationen identifizieren, und geeigneten Formulardateneintragselementen für Anmelder zur Eingabe der angeforderten Information angezeigt werden. Anmeldungen bestehen typischerweise aus mehreren Seiten.
Eine weitere Anmelderseite zeigt dem Anmelder den Zustand aller Anmeldungen, die der Anmelder bearbeitet hat. Diese Seite wird von einem CGI-Dienstprogramm erzeugt, die die vorstehend beschriebenen Tabellen untersucht und eine HTML-Seite erzeugt, die zeigt, ob jede Anmeldung fertiggestellt, gespeichert, übermittelt oder bezahlt wurde und ob sie von der Schule bestätigt wurde.
Korrekturseiten werden dem Anmelder präsentiert, wenn die nachstehend beschriebene Bewertung der ersten oder zweiten Stufe fehlende oder falsche Daten erkennt.
Andere Seiten umfassen jene, die den Benutzer informieren, wenn keine Zeiträume zum Annehmen von Anmeldungen zur Verfügung stehen (das heißt das aktuelle Datum außerhalb der Übermittlungsfenster liegt) oder wenn eine angeforderte Anmeldung bereits für den angeforderten Zeitraum übermittelt wurde.
Datenbewertung
Die Anwesenheit und der Inhalt der Information wird vorzugsweise vielmehr am Server als durch den Browser auf dem Computer des Anmelders geprüft. Dies verringert die Anforderungen für den Browser, so daß der Anmelder nicht auf die Verwendung der neuesten Version eines Browsers eingeschränkt ist und, da weniger Berechnung vom Browser selbst durchgeführt wird, Kompatibilitätsprobleme verringert werden. Ein Anmelder kann einen Browser auf Zeichenbasis verwenden, wie z.B. Lynx, wenn er dies wählt. Wenn eine Information aus der Datenbank zum Einfügen in eine neue Anmeldung abgerufen wird, wird sie mit den Inhaltsanforderungen der Institution geprüft. Wenn die abgerufenen Daten die Kriterien nicht erfüllen, wird die Information vom Anmelder erneut angefordert.
Die Datenbewertung wird in zwei Stufen durchgeführt. Daten werden sowohl vor als auch nach jeder Bewertungsstufe gespeichert. Die erste Stufe besteht aus Prüfungen, die für alle Anmeldungen universell sind. Diese Prüfungen werden jedesmal durchgeführt, wenn eine Seite übermittelt wird, wie z.B. wenn eine nachfolgende Seite angefordert wird oder wenn eine Seite gespeichert wird. Die Bewertung der ersten Stufe kann beispielsweise prüfen, ob der Name des Anmelders vorhanden ist, ob die SAT-Punktwerte zwischen 200 und 800 liegen und ob, sobald die Nicht-Ziffer-Zeichen aus Sozialversicherungsnummern ausgestreift werden, eine Folge von neun Ziffern, die nicht mit "9" oder "000" beginnt, verbleibt.
Um es zu vermeiden, dem Anmelder eine überwältigen Anzahl von Feldern, die durch die Bewertungsregeln fallen, am Ende der gesamten Anmeldung zu präsentieren, ist es bevorzugt, so viele Felder wie möglich bei der Bewertung der ersten Stufe zu bewerten. Andererseits wird die Anzahl von erforderlichen Feldern in der ersten Stufe vorzugsweise minimiert, da ein Anmelder eine Anmeldung während einer Sitzung teilweise Fertigstellen wollen kann und die restlichen Felder zu einer anderen Zeit fertigstellen wollen kann.
Die Bewertung der zweiten Stufe wird durchgeführt, wenn eine Anmeldung an eine Institution übermittelt wird und das ganze Formular vollständig sein muß. Die zweite Stufe umfaßt typischerweise mehr erforderliche Felder und mehr spezifische Bewertungsregeln für übermittelte Datenfelder. Die Bewertung der zweiten Stufe wird an dem ganzen Datensatz für die Anmeldung durchgeführt und bewertet die Informationen gemäß Regeln, die von der Institution für die spezielle Anmeldung festgelegt werden. Zuerst werden die für die Institution spezifischen erforderlichen Felder überprüft. Da einige Institutionen beispielsweise eine Anmeldung verarbeiten wollen können, bei der das Feld Hobbies leer gelassen ist, ist dieses Feld bei der Bewertung der ersten Stufe nicht erforderlich. Wenn eine Institution anfordert, daß dieses Feld vollständig ist, wird während der Bewertung der zweiten Stufe ein unvollständiges Feld gekennzeichnet. Nachdem die Bewertung der zweiten Stufe erfolgreich beendet ist, sind die Daten bereit, zur Institution hochgeladen zu werden.
Die Anmeldungstabelle gibt an, welche Felder für die spezielle Anmeldung erforderlich sind. Die Anmeldungstabelle gibt auch bestimmte Datenbewertungsregeln an, wie z.B. zulässige Werte oder Formate für Daten. Die Bewertung der zweiten Stufe kann die Daten in ein Format umformatieren, das von der Institution gefordert wird. Einige Institutionen wollen beispielsweise den Namen des Anmelders in Form eines einzelnen Feldes, mit dem Nachnamen zuerst, gefolgt von einem Komma, und dann den Vornamen und die mittlere Initiale. Um es zu vermeiden, daß Anmelder Daten mehr als einmal eingeben, um Formatänderungen gerecht zu werden, wird die Information vorzugsweise in einfacheren Datenelementen gespeichert und dann während der Bewertung der zweiten Stufe in das von der Institution geforderte Format kombiniert.
Abhängigkeitsregeln werden während der Bewertung der zweiten Stufe geprüft. Ob beispielsweise ein spezielles Feld wie z.B. die Ausländerregistrierungsnummer erforderlich ist, kann von dem Wert abhängen, der vom Anmelder für ein anderes Feld wie z.B. Staatsbürgerschaft geliefert wird.
Ein Benutzer, der die Anmeldung mit der Absicht, sie zu übermitteln, ernsthaft ausfüllt, könnte nach der Übermittlung mit vielen von der Institution geforderten Feldern auf einer großen Datenkorrekturseite der zweiten Stufe konfrontiert werden. Um die Größe dieser Seite zu minimieren, wird dem Benutzer die Option gegeben, daß die Bewertung der ersten Stufe zusätzlich die Felder der aktuellen Seite nach Attributen abtastet, die für den Bewertungsprozeß der zweiten Stufe erforderlich sind.
Anfänglich ist diese Option aktiv. Wenn dem Benutzer eine Datenkorrekturseite präsentiert wird, weist die Oberseite der Seite Optionsschaltflächen und Befehle zum Aktivieren/Deaktivieren dieses Merkmals auf. Die Wahl des Benutzers wird zwischen Seiten über ein verborgenes Feld im Formular (in den Formularen) aufrechterhalten.
In dieser Weise kann der Benutzer, während er durch die Anmeldung fortschreitet, Werte für die für die zweite Stufe erforderlichen Felder in einer allmählichen Weise über den Bewertungsprozeß der ersten Stufe eingeben, anstatt daß er mit vielen Feldern, die bei der Übermittlung zu füllen sind, konfrontiert ist.
Wenn der Benutzer außerstande ist, einen Wert zu dem Zeitpunkt zu liefern, kann er dieses Merkmal deaktivieren und die Eingabe von Daten in das Feld verschieben, bis er bereit ist, die Anmeldung zur Institution zu übermitteln.
Attributpseudonymverwendung
Die Pseudonymverwendung von Attributen bezieht sich auf ein Sekundärbenennungsschema, das zum Erzeugen eines flexiblen Datenwörterbuchs entwickelt wurde. Unter Verwendung der Pseudonymverwendung kann ein Anmeldungsentwickler leicht Attribute auffinden, die vom System definiert werden, und das Erzeugen von doppelten Attributen, die dieselben Daten speichern, vermeiden.
Jedes Attributpseudonym ist eine Reihe von durch Doppelpunkte begrenzten Deskriptoren. Irgend etwas, das die Adresseninformation betrifft, verwendet beispielsweise einen Deskriptor "ADDRESS" ("ADRESSE"); Fragen, die den Geburtstag des Anmelders betreffen, verwenden einen Deskriptor "BIRTH" ("GEBURTSTAG").
Somit wird das Geburtslandattribut "BIRTH_COUNTRY" ("GEBURTS_LAND") genannt, aber sein Pseudonym ist "BIRTH:ADDRESS:COUNTRY" ("GEBURTSTAG:ADRESSE:LAND"). Ebenso wird das Geburtsdatumsattribut "BIRTH_DATE" ("GEBURTS_DATUM") genannt und wird mit dem Pseudonym "BIRTH:DATE" ("GEBURTS:DATUM") benannt.
Attribute des festen Wohnsitzes werden "STREET"; "STREET2", "CITY", "ZIP" ("STRASSE" "STRASSE2", "STADT", "PLZ") usw. genannt, aber die Pseudonyme sind "ADDRESS:PERMANENT:CITY" ("WOHNSITZ:FEST:STADT"), "ADDRESS:PERMANENT:ZIP" ("WOHNSITZ:FEST:PLZ") usw.
Postadressenattribute werden "MAIL_STREET" ("POST_STRASSE"), "MAIL STREET2" ("POST_STRASSE2"), "MAIL CITY" ("POST STADT"), "MAIL ZIP" ("POST_PLZ") usw. genannt, aber die Pseudonyme sind "ADDRESS:MAIL:CITY" (ADRESSE:POST:STADT"), "ADDRESS:MAIL:ZIP" ("ADRESSE:POST:PLZ") usw.
Die Verwendung der Pseudonymverwendung stellt die Fähigkeit bereit, nach dem Inhalt durch ein Schlüsselwort oder einen Satz von Schlüsselwörtern zu suchen. Um beispielsweise "Heimadresse des Vaters" zu finden, könnte man nach allen Attributen suchen, deren Pseudonyme die Deskriptoren "FATHER" ("VATER"), "ADDRESS" ("ADRESSE") und "HOME" ("HEIM") enthalten.
Diese Suche würde die Pseudonyme "FATHER:ADDRESS:HOME.1:STREET" ("VATER:ADRESSE:HEIM.1:STRASSE"), "FATHER:ADDRESS:HOME.1:CITY" ("VATER:ADRESSE:HEIM.1:STADT"), "FATHER:ADDRESS:HOME.1:COUNTRY" ("VATER:ADRESSE:HEIM.1:LAND"), "FATHER:ADDRESS:HOME.1:TELEPHONE" ("VATER:ADRESSE:HEIM.1:TELEFON") auffinden, die den Variablennamen "PERSON_AT_ADDRESS_SINCE.1" (PERSON_BEI_ADRESSE_SEIT.1"), "PERSON_CITY.1" ("PERSON_STADT.1"), "PERSON_COUNTRY.1" ("PERSON_LAND.1"), bzw. "PERSON_PHONE.1" ("PERSON_TELEFON.1") entsprechen.
Man kann den Schnitt oder die Vereinigung von Schlüsselwortsuchergebnissen betrachten, um schnell auf gewünschte Attribute zuzugreifen.
Somit wird das Pseudonymverwendungssystem hauptsächlich zum Entwickeln neuer Anmeldungen verwendet: nicht nur als Nachschlagewerkzeug, sondern auch zum Vermeiden des Hinzufügens von Attributen als neue Variablen, die bereits existieren. Schließlich stellt die Pseudonymverwendung eine maximale gemeinsame Datennutzung durch Aussondern von Duplikaten sicher, die die Daten zwischen zwei Namensräumen aufteilen würden. Es ist bevorzugt, dieses System als hauptsächliches internes Benennungsschema zu verwenden.
Verfahren
16 zeigt die Schritte, die in einem bevorzugten Ausführungsbeispiel vorkommen, wenn ein Anmelder den Formularprozessor kontaktiert. Schritt 156 zeigt, daß, wenn eine Anmeldung den URL des Formularprozessors kontaktiert, der Formularprozessor aufgerufen wird und sich durch Einlesen von Bibliotheken und Initialisieren von Variablen wie z.B. globalen Konstanten und Datenstrukturen initialisiert. Im ersten Ausführungsbeispiel der vorstehend beschriebenen Anmeldungsdatei wird beispielsweise eine assoziative Matrix von assoziativen Matrizes, die die vom Prozessor verwendeten Formularelemente, um das Anmeldeformular zu konstruieren, definiert, initialisiert.
In Schritt 157 sucht der Formularprozessor nach Daten, die vom Webseitenformular abgeschickt wurden. Es können zuerst keine Daten vorhanden sein, aber nachdem einige Informationen eingegeben wurden und eine Seite gespeichert oder geändert wurde, werden Daten zum Formularprozessor gesandt, der die Bewertung der ersten Stufe an den Daten durchführt. Der Formularprozessor verarbeitet dann Eingangsargumente und abgesandte Daten, um den Anmeldungszustand zu bestimmen, wie nachstehend beschrieben.
Schritt 158 zeigt, daß der Formularprozessor dann Datenbankaufrufe durchführt, um Variablen zu initialisieren, die die aktuelle Zulassungsanmeldung betreffen (ID #, Gebühreninformation, Institution usw.).
Schritt 159 zeigt, daß der Formularprozessor feststellt, welche Anmeldungszeiträume (z.B. "Herbst 1999" usw.) für diese Benutzer/Anmeldungs-Kombination zur Verfügung stehen. Der Benutzer kann beispielsweise bereits eine Anmeldung "Herbst 1999" übermittelt und für diese bezahlt haben und fordert nun dieselbe Anmeldung an. Diese Anforderung kann darin bestehen, 1) die übermittelte Anmeldung durchzusehen oder 2) für einen neuen Zeitraum anzumelden. Der Prozessor muß garantieren, daß der Benutzer nicht dieselbe Anmeldung mehr als einmal pro Zeitraum übermittelt. Der Suchprozessor berechnet eine Übermittlungszustandsinformation, um zu verhindern, daß ein Benutzer Daten in einer bereits übermittelten Anmeldung ändert, und sie dann in dem falschen Glauben erneut übermittelt, daß die Daten bei der Institution aktualisiert werden würden.
Es gibt drei Ergebnisse der Berechnung des Übermittlungszustands:

a. Keine derzeit verfügbaren Zeiträume. Jeder Zeitraum weist ein Beginndatum und ein Ablaufdatum auf. Wenn die aktuelle Zeit vor dem Beginndatum oder nach dem Ablaufdatum liegt, steht der Zeitraum nicht zur Verfügung. Es würden keine Zeiträume zur Verfügung stehen, wenn alle Anmeldungsfenster für eine Institution entweder abgelaufen sind oder noch nicht begonnen haben, oder wenn der Benutzer sich für alle derzeit verfügbaren Zeiträume angemeldet hat.
b. Der Benutzer hat sich für einen Zeitraum angemeldet und hat noch nicht eine neue Transaktion für diese Anmeldung eingeleitet.
c. Der Benutzer hat eine verfügbare "aktive", das heißt nicht übermittelte oder bezahlte, Transaktion für diese Anmeldung.

In Schritt 160 bestimmt der Prozessor auf der Basis der Verfügbarkeit eines Zeitraums und des Zustands irgendwelcher anhängiger oder übermittelter Anmeldungen, welches Anmeldeformular für den Benutzer erforderlich ist, und erzeugt das geeignete Anmeldeformular. Wenn der Benutzer eine verfügbare aktive Transaktion hat, gibt der Prozessor die entsprechende Seite der Anmeldung in einem HTML-Formular mit irgendwelchen bereits eingefüllten vorher übermittelten Daten zurück. Wenn der Benutzer die Anmeldung bereits übermittelt hat und keine aktiven Transaktionen hat, wird eine Seite "Bereits übermittelt" mit Hypertextlink(s) zu "druckfähigen" (uneditierbaren) Versionen der übermittelten Anmeldungen) und der Option, die Anmeldung für einen anderen Zeitraum als den Zeitraum (die Zeiträume), für den (die) bereits angemeldet wurde, auszufüllen, zurück. Wenn keine verfügbaren Zeiträume vorhanden sind, wird eine Seite "Keine verfügbaren Zeiträume" zurückgegeben, die dem Benutzer die Option gibt, die Anmeldung auszufüllen und zu speichern, aber sie nicht zu übermitteln, bis ein Zeitraum zur Verfügung steht. Im Fall, daß der Benutzer vorher eine Anmeldung für den angegebenen Zeitraum übermittelt hat und keine anderen Zeiträume zur Verfügung stehen, wird ein Hybrid der obigen zwei Seiten mit Links zu (einer) druckfähigen Versionen) von (einer) übermittelten Anmeldungen) und der Option, Daten einzufüllen und zu speichern, aber nicht die Anmeldung zu übermitteln, bis ein neuer Zeitraum zur Verfügung steht, zurückgegeben.
In Schritt 161 liest und analysiert der Formularprozessor die "Anmeldungsdatei", die der Anmeldung entspricht, um die entsprechende Seite der Anmeldung zu finden.
In Schritt 162 initialisiert der Prozessor eine Benutzerdatenstruktur, vorzugsweise eine assoziative Matrix vor. Schlüssel/Wert-Paaren oder ein Datenobjekt in einer objektorientierten Implementierungsprogrammierung unter Verwendung von Daten aus der Benutzerattributtabelle.
Wenn Daten abgesandt wurden, führt der Formularprozessor die Datenbewertung der ersten Stufe in Schritt 163 durch.
Wenn eine oder mehrere Daten die Bewertung nicht bestehen, erzeugt der Prozessor eine "Datenkorrekturseite" und gibt sie an den Benutzer zurück. Diese Seite wiederholt den Text der durchgefallenen Frage, zeigt eine Meldung an, die erläutert, warum die Daten durchgefallen sind, und wiederholt das Formularelement, das dieses Datenelement betrifft. Wenn der Benutzer diese Seite absendet, wird die Bewertung der ersten Stufe auf die eingehenden Daten angewendet, und wenn eine oder mehrere immer noch fehlerhaft sind, wird eine neue Datenkorrekturseite zurückgegeben. Dieser Prozeß fährt fort, bis alle Daten für diese Seite die Bewertung bestanden haben.
Wie vorstehend beschrieben, prüft die Bewertung der ersten Stufe wahlweise auf erforderliche Felder für die zweite Stufe, wodurch die Anzahl von Feldern verringert wird, die eine Dateneingabe während der Bewertung der zweiten Stufe erfordern. Auf jeder Datenkorrekturseite hat der Benutzer die Option, dieses Merkmal zu aktivieren/deaktivieren.
In Schritt 164 gibt der Formularprozessor eine entsprechende Seite in Abhängigkeit vom Zustand des Prozessors an den Benutzer aus.
Der Vorrechner, das heißt der Teil des Formularprozessors, der eingehende Daten vom Benutzer verarbeitet, ist im wesentlichen ein CGI-Programm, das die korrekte Handlung durch Analysieren der vom Webformular eingehenden Information in Kombination mit der Zustandsinformation von der Transaktionstabelle ermittelt. Der Benutzer könnte beispielsweise von einer Datenkorrekturseite zurückkehren, der Benutzer kann die Schaltfläche "Speichern und Senden" gedrückt haben oder der Benutzer kann Seiten gewechselt haben. Der Prozessor kann nach abgesandten Daten suchen und sie verarbeiten, usw.
Zustand
Der Formularprozessor kann sich nach dem Analysieren von eingehenden Daten in einem von mehreren möglichen Zuständen befinden. Die Daten können beispielsweise durch die Bewertung durchgefallen sein und der Formularprozessor muß daher eine Datenkorrekturseite ausgeben oder ein Benutzer kann angefordert haben, zur Seite "x" zu gehen, so daß der Formularprozessor die Seite "x" erzeugen und ausgeben muß; usw. (siehe nachstehende Erörterung des Zustands).
Die meisten Dialoge zwischen dem Benutzer und dem erfindungsgemäßen System geschehen durch "Vorfeldverarbeitung", die vorstehend mit Bezug auf 14 beschrieben wurde. Die Antwort des Prozessors hängt vom aktuellen Zustand ab. Das Web, das der Kommunikationskanal ist, den das System verwendet, ist per Definition zustandslos: wenn ein Browser (Webclient) eine Anforderung an einen Webserver übermittelt, wird eine Verbindung zwischen den beiden nur lang genug hergestellt, daß der Server die gewünschte Information überträgt. Der Server läßt dann die Verbindung fallen und jegliche Information, die durch den Client/Server-Dialog erzeugt wird, wird vom Server verworfen. Das nächste Mal, wenn der Client mit dem Server verbindet, ist der Zustand leer und sie beginnen diesen Dialog von vorn.
Das System benötigt eine Art und Weise, um die Zustandsinformation zwischen den Kontakten aufrechtzuerhalten. Das System verwendet zwei Zustandsmodelle, um die Zustände von zwei verschiedenen Aspekten des Systems zu beschreiben: ein "Sitzungszustand" gilt für den Vorfeldprozeß zum Erzeugen und Zurückgeben von Webformularen und ein "Transaktionszustand" betrifft den Zustand der Transaktion, das heißt den Zustand für eine spezielle Anmeldung eines Benutzers an einer Institution für einen speziellen Zeitraum. Transaktionszustände umfassen beispielsweise aktiv oder übermittelt oder bezahlt oder leer.
Jede Seite weist verborgene Felder auf, die eine Zustandsinformation bereitstellen. Der Sitzungszustand kann durch Analysieren der verborgenen Felder, die mit Daten zurückgegeben werden, bestimmt werden. Die Zustandsinformation kann beispielsweise die Versionsnummer der Anmeldung und die Seite, die der Benutzer vorher angefordert hat, umfassen. Die verborgenen Felder würden beispielsweise dem Server anzeigen, ob eine Seite zurückgegeben wird, da der Anmelder "Speichern, Bezahlen und Senden" ausgewählt hat, oder ob der Anmelder nur einen Seitenwechsel angefordert hat. Als weiteres Beispiel, wenn die Bewertung der ersten Stufe einen Fehler findet und eine Datenkorrekturseite an den Benutzer zurückgibt, umfaßt die Datenkorrekturseite verborgene Felder, die die Seite angeben, zu der der Benutzer versucht hat zu gehen. Wenn die Datenkorrekturseite übermittelt wird, analysiert der Prozessor die verborgenen Felder, um den Zustand zu ermitteln, und gibt die vorher angeforderte Seite an den Benutzer zurück.
Der aktuelle Transaktionszustand für eine spezielle Anmeldungs/Benutzer-Kombination wird durch Nachschlagen der Anmeldung in den vorstehend beschriebenen Datenbanktabellen ermittelt. Wenn der Anmelder beispielsweise eine Anmeldung für einen Zeitraum anfordert, für den der Anmelder bereits eine Anmeldung übermittelt hat, stellt der Prozessor fest, daß dies der Fall ist, und gibt anstatt die Anmeldung zurückzugeben, eine Seite zurück, die aussagt, daß die Anmeldung bereits übermittelt wurde. Dem Studenten wird die Option gegeben, die Anmeldung in einer druckfähigen, nicht-editierbaren Form zu betrachten oder ein Anmeldeformular für einen anderen Zeitraum zu öffnen. Der Prozessor siebt den Zeitraum aus, für den bereits angemeldet wurde, wenn er die Anmeldung zurückgibt. Wenn gerade keine Zeiträume zur Verfügung stehen, wird eine Seite zurückgegeben, die aussagt, daß gerade keine Zeiträume zur Verfügung stehen, aber dem Anmelder wird gestattet, das Fertigstellen einer Anmeldung zu beginnen, die gespeichert werden kann, bis ein Zeitraum zur Verfügung steht. In einem solchen Fall steht die Schaltfläche "Speichern und Senden" nicht zur Verfügung, bis ein Zeitraum zur Verfügung steht. Somit können Anmelder das Fertigstellen von Formularen beginnen, noch bevor ein Zeitraum zur Verfügung steht.
Im Hinblick auf das Vorfeldzustandsmodell ist das folgende eine Liste der Zustände, die der Prozessor durch die Handlung definiert hat, die bewirkt hat, daß sich der Prozessor in diesem Zustand befindet:

1. "Anfänglicher Kontakt" – Der Benutzer fordert das Anmeldeformular von außerhalb des Prozessors an. Der Prozessor erzeugt die erste Seite der Anmeldung, fügt irgendwelche passenden Benutzerdaten ein und gibt das Formular zurück.
2. "Seitenwechsel" – Für mehrseitige Anmeldungen ist der Benutzer von der Seite "x" gekommen und will zur Seite "y" gehen. Der Prozessor wendet zuerst eine Vorfeldbewertung auf die von der Seite "x" abgesandten eingehenden Daten an (was zur Rückgabe einer Datenkorrekturseite führen kann), speichert die bewerteten Daten, erzeugt die Seite "x", fügt irgendwelche passenden Benutzerdaten ein und gibt das Formular zurück.
3. "Explizites Speichern" – An der Unterseite jeder Seite befindet sich eine Schaltfläche, die ihnen ermöglicht, die aktuelle Datenseite zu speichern. Im wesentlichen ist die Handlung des Prozessors in diesem Zustand identisch zum "Seitenwechsel", aber "x" ist gleich "y" (d.h. die zurückgegebene Seite ist dieselbe Seitennummer wie die Seite, von der abgesandt wurde).
4. "Speichern und Senden" – Der Benutzer hat sich entschieden, die fertiggestellte Anmeldung an die Institution zu übermitteln. Der Prozessor führt die Vorfeldbewertung an der abgesandten aktuellen Seite durch, speichert Daten, führt eine Nachbewertung an allen Daten durch, die die Anmeldung betreffen, speichert Daten in der Tabelle für gesandte Benutzerattribute und übergibt die Steuerung an den Bezahlungsserver.
5. "Daten-CRX-(Korrektur) Seite" – Wenn entweder die Vorfeld- oder die Nachbewertung mißlungen ist, schaltet der Prozessor in diesen Zustand um, was bewirkt, daß der Formulargenerator eine Datenkorrekturseite erzeugt und in dieser Seite eine Zustandsinformation, einschließlich des Zustands, in dem sich der Prozessor vor dem Umschalten in diesen Zustand befand, verbirgt. (Wenn sich der Benutzer beispielsweise auf Seite 3 befindet und wählt, zu Seite 5 zu gehen, aber fehlerhafte Daten auf Seite 3 zu einer eingreifenden Datenkorrekturseite führen, umfaßt die Datenkorrekturseite verborgene Daten, die den Seitenwechsel auf Seite 5 angeben). Sobald die Daten erfolgreich geändert sind und der Benutzer die Datenkorrekturseite absendet, stellt der Prozessor fest, daß der vorherige Zustand ein "Seitenwechsel" auf Seite 5 war, und gibt die Seite 5 an den Benutzer zurück. Wenn der Benutzer "Speichern und Senden" ausgewählt hatte und eine eingreifende Vorfeld- oder Nachbewertungs-Datenkorrekturseite erhalten hat, dann schaltet, sobald sie korrigiert ist, das Absenden von dieser Datenkorrekturseite den Prozessor ebenso dann in die Betriebsart "Speichern und Senden" um und der Benutzer empfängt die Bezahlungsseite vom Bezahlungsserver.
6. "Anmeldungszeitraumseite" – In diesen Zustand wird eingetreten, wenn der Anmelder eine Anmeldung anfordert, die bereits übermittelt wurde oder für die keine Zeiträume zur Verfügung stehen: (a) eine Seite "Bereits übermittelt"; oder (b) eine Seite "keine Zeiträume verfügbar". Der Prozessor kehrt beide Male mit einer verborgenen Zustandsinformation zurück. Wenn eine dieser Seiten abgesandt wird, fügt der Prozessor dann kontinuierlich eine zusätzliche verborgene Zustandsinformation in anschließende Formulare ein, um sicherzustellen, daß das zukünftige Verhalten der Auswahl, die der Benutzer auf diesen Seiten durchgeführt hat, entspricht.
7. "Druckprozessor" – Der Prozessor wird in der Druckbetriebsart aufgerufen, um eine "druckfähige" (d.h. Nicht-Formular) Version der Anmeldungs/Benutzer-Daten zu liefern.
8. "Verlassen" – Der Benutzer hat die Schaltfläche "Sitzung beenden" auf der Anmeldungsseite gewählt und der Prozessor übergibt die Steuerung an die Benutzeraktivitäts-CGI, die eine Seite mit Information über die Anmeldungen, die der Benutzer bearbeitet hat, und ihren Zustand anzeigt.
9. "Suche" – Der Benutzer hat eine Suchschaltfläche ausgewählt, um die Auswahl eines Werts, beispielsweise eines Landes, zu unterstützen. Der Prozessor speichert irgendwelche überprüften Daten und zeigt eine Suchseite an, die Links zurück auf die Seite der Anmeldung, die der Benutzer verlassen hat, enthält.

Diese Links bewirken auch, daß der ausgewählte Wert in den Prozessor weitergeleitet wird, der ihn dann entsprechend im Formular anzeigt.
17 zeigt das Ausgangszustandsmodell für eine Anmeldung und die entsprechenden Transaktionsoperationen, die Änderungen zwischen Zuständen verursachen. Der Nullzustand 172 ist der Zustand, nachdem eine Anmeldung erzeugt wurde, aber bevor die Anmeldung vom Anmelder abgesandt wurde. Die Anmeldung schaltet in den aktiven Zustand 178 um, wenn der Anmelder eine Seite der Anmeldung speichert oder wenn der Anmelder versucht, eine Seite zu speichern, und ein Fehler verhindert, daß die Seite gespeichert wird. Wenn die Anmeldung übermittelt wird, tritt sie in einen übermittelten Zustand 180 ein. Dem Anmelder wird vorzugsweise eine Warnung gegeben, daß keine Änderungen an der Anmeldung vorgenommen werden können, nachdem eine Bezahlung durchgeführt wird, und ihm wird die Option gegeben, die Anmeldung zu ändern. Wenn der Anmelder einen Wunsch angibt, die Anmeldung zu ändern, oder wenn die Anmeldegebühr nicht bezahlt wird, kehrt die Anmeldung zum aktiven Zustand 178 zurück. Wenn der Anmelder einen Gebührenverzicht anfordert oder der Anmelder angibt, daß er per Scheck bezahlen will, tritt die Anmeldung in einen Haltezustand 182 ein, bis sich bestätigt, daß der Scheck gedeckt ist, oder der Gebührenverzicht von der Institution genehmigt wird. Gebührenverzichte werden von Institutionen verwendet, um Anmeldungen von qualifizierten Personen, die nicht in der Lage sein können, sich die Anmeldegebühr zu leisten, zu ermutigen.
Nachdem die Anmeldung übermittelt ist, bezahlt der Anmelder für die Anmeldung, die in einen bezahlten Zustand 184 eintritt, bis die Bezahlung von der Institution bestätigt oder geklärt ist. Im bezahlten Zustand 184 und in den nachfolgenden Zuständen kann die Anmeldung zum Drucken durch den Anmelder betrachtet oder durch eine Stapelübertragung oder ein Dateiübertragungsprotokoll durch die Institution heruntergeladen werden. Die Anmeldung wird dann von der Institution bestätigt und die Bezahlung wird geklärt. In Abhängigkeit davon, ob die Bestätigung oder Klärung zuerst geschieht, tritt die Anmeldung in einen bestätigten Zustand 186 oder einen geklärten Vorbestätigungszustand 192 ein. Nachdem sowohl die Klärung als auch Bestätigung geschehen, tritt die Anmeldung in einen fertiggestellten Zustand 190 ein. Die Anmeldung kann in einen ungültigen Zustand 194 eintreten, wenn sie unbrauchbar wird, beispielsweise da ein Anmelder die Anmeldung storniert oder die Zulassung zurückzieht, die Anmeldungsinformation zur Institution zu liefern. Ungültige Anmeldungen werden in einer separaten Datenbanktabelle verwaltet.
Datenformatierung
Wenn eine Anmeldungsinformation von der Institution hochgeladen und bestätigt wird, bleibt die ursprüngliche Anmeldungsinformation in der Anmelderdatenbank in der Tabelle für gesandte Benutzerattribute archiviert. Die Anmeldung kann gedruckt, erneut hochgeladen werden, usw. Institutionen können eine Information anfordern, die alle oder eine Teilmenge ihrer Anmeldungen betrifft, um beispielsweise zu sehen, welche neuen Anmeldungen gesandt wurden, und den Zustand von verschiedenen Anmeldungen zu sahen. Die Daten stehen zur Datenbearbeitung wie z.B, zum Sortieren nach Feldern oder Präsentieren der Anmeldungsinformation in verschiedenen Datenbankansichten zur Verfügung. Eine Schule kann beispielsweise Anmeldungen betrachten, die nach Testpunktwerten sortiert sind. Die Schule könnte auch alle Anmeldungen von Studenten von einem speziellen geographischen Gebiet oder Studenten, die einen speziellen Sport ausüben oder ein Instrument spielen, betrachten. Die Institution kann statistische Korrelationen zwischen Informationen an der Anmeldung und Klassen, die an der Institution nach Immatrikulation erzielt werden, durchführen, um festzustellen, welche Eigenschaften von Anmeldern mit dem Erfolg an der Institution korrelieren.
Die einzelnen Datenelemente werden nicht nur auf die Spezifikationen einer speziellen Institution zugeschnitten, der gesamte Datensatz wird formatiert, so daß er den Bedürfnissen dieser Institution entspricht. Die Datenformate können 1) durch Komma getrennte Werte, 2) durch einen Tabulator begrenzte Werte, 3) Formate mit fester Länge, 4) Name/Wert-Paare und 5) EDI 189 umfassen. Für alle dieser Verfahren werden die Daten natürlich nach Bedarf geordnet (z.B.
Sozialversicherungsnummer zuerst, Nachname als zweites, Hochschulname als 33. usw.).
Die Formatierung des gesamten Datensatzes wird über Nachdienstprogramme durchgeführt, die auf dem Server laufen und die speziell formatierte Textdateien verwenden, die die Datenformatierungsbeschreibungen und zusätzliche Datenbearbeitungsregeln enthalten. Diese Dienstprogramme werden ausgelöst, wenn die Kontaktperson der Institution auf das Verwaltungsdienstprogramm auf dem Formularprozessorserver zugreift und wählt, Datensätze hochzuladen.
Eine weitere Implementierung der Erfindung verwendet eine objektorientierte Programmierung und die erweiterbare Markierungssprache (XML), die verwendet wird, um eine individuell aufgemachte Markierungssprache zu erzeugen, die die Anmeldungsverarbeitung betrifft. In diesem Ausführungsbeispiel wird das meiste der Information über jeden Anmelder in einer XML-Datei, die diesem Anmelder entspricht, gespeichert, obwohl einige grundlegende Netzkonteninformationen über jeden Anmelder noch in einer Datentabelle verwaltet werden. Die Informationen über jede Anmeldung werden in einer XML-Anmeldungsbeschreibungsdatei gespeichert. Diese Implementierung erfordert weniger Dateien, wodurch die Verwaltung vereinfacht wird und der Laufzeitmehraufwand, der mit dem Lesen und Rekonstruieren von Anmeldungen aus mehreren Dateien verbunden ist, verringert wird. Die Bewertungsregeln der ersten und der zweiten Stufe werden in der XML-Anmeldungsbeschreibungsdatei verwaltet. Im Gegensatz zum vorher beschriebenen Ausführungsbeispiel ist eine Initialisierung nur erforderlich, wenn der Webserver gestartet wird, da die Anmeldung zusammen mit ihren Datenbankverbindungen bestehen bleibt, solange der Server arbeitet.
Ein XML-Analyseprogramm, das typischerweise in Perl geschrieben ist, analysiert die XML-Anmeldungsbeschreibungs-Quellendatei und ruft Programme auf, die durch Erzeugen und Speichern von binären Objekten die von den XML-Kennzeichen festgelegten Merkmale implementieren. Der Text zwischen einem Kennzeichen <Seite beginnen> und einem Kennzeichen <Seite beenden> wird beispielsweise verwendet, um ein Seitenobjekt mit Attributen zu erzeugen, die durch den Text zwischen den Kennzeichen definiert sind. Ebenso wird ein Objekt, das einem Element einer Seite entspricht, auf der Basis des Texts zwischen einem Kennzeichen <Element beginnen> und einem Kennzeichen <Element beenden> erzeugt. Die erzeugten Objekte definieren die Anmeldung, die dem Anmelder präsentiert wird.
18 zeigt Beispiele von binären Objekten, die durch das XML-Analyseprogramm erzeugt werden, und die Beziehungen zwischen einigen der Objekte. 18 zeigt beispielsweise, daß ein Seitenobjekt 204 ein oder mehrere Elementobjekte 206, Gruppenobjekte 208 und Tabellenobjekte 210 umfassen kann. Ein Elementobjekt 206, das beispielsweise als Frage auf der Anmeldung konkret dargestellt werden kann, umfaßt ein Vortextelement 212 und ein Nachtextelement 214 entsprechend Text, der der Frage zugeordnet ist, ein Eingabefeldelement 216 und irgendwelche Bewertungsregelelemente 218. Gruppenobjekte 208 können auch ein Vortextelement 212 und ein Nachtextelement 214 sowie Elementobjekte 206, andere Gruppenobjekte 208 und Tabellenobjekte 210 umfassen. Tabellenobjekte 210 können Tabellenkopfzeilenobjekte 220 und Zeilenelementobjekte 222 umfassen. Geschulte Programmierer können viele Klassen schreiben, um eine Anmeldung individuell aufzumachen, und verstehen, daß 18 ein erheblich vereinfachtes Beispiel ist, das verwendet wird, um die Prinzipien des Ausführungsbeispiels zu demonstrieren.
Das Gruppenobjekt ermöglicht, daß mehrere Elemente einer Gruppe zugeordnet werden, und erleichtert die Implementierung einer adaptiven Anmeldung, bei der der Inhalt von Anmeldungsseiten, die zu einem Anmelder gesandt werden, von den Antworten des Anmelders in vorherigen Seiten abhängen kann. Ob ein Element oder eine Gruppe angezeigt wird, hängt vom Wert eines Anzeigeattributs ab, welches verwendet werden kann, um die Bedingungen festzulegen, unter denen das Objekt auf dem Bildschirm oder in gedruckten Berichten angezeigt wird. Eine Gruppe von Fragen kann beispielsweise zu einem "Nicht-US-Staatsbürger"-Gruppenobjekt gehören. Fragen, die zum Nicht-US-Staatsbürger- Gruppenobjekt gehören, können eine Information wie z.B. Visumsart, Ausländerregistrierungsnummer und Herkunftsland anfordern. Wenn der Anmelder antwortet, daß er ein US-Staatsbürger ist, werden Elemente in der "Nicht-US-Staatsbürger"-Gruppe nicht angezeigt. Eine adaptive Anmeldung wäre auch für ein höheres Ausbildungssystem nützlich, das mehrere Schulen oder Campen umfaßt. Eine einzelne Anmeldungsdatei könnte verwendet werden, wobei die Fragen dem Anmelder in Abhängigkeit von der speziellen Schule, die der Anmelder wählt, präsentiert werden. Die Verwendung einer einzelnen Anmeldung vereinfacht die Verwaltung des Anmeldeformulars erheblich.
Die Anmelderinformation wird ebenso in einer Anmelder-XML-Datei gespeichert. Im Gegensatz zur Anmeldungsbeschreibungs-XML-Datei wird die Anmelderdatei geändert, wenn vom Anmelder Informationen abgesandt werden. Somit wird die Anmelder-XML-Datei jedesmal neu gespeichert, wenn Daten vom Anmelder abgesandt werden.
Obwohl die vorliegende Erfindung unter Verwendung eines Ausführungsbeispiels beschrieben wurde, das Collegezulassungs-Anmeldeformulare verarbeitet, ist sie nicht auf diese Anwendung begrenzt, sondern ist auf die Verarbeitung eines beliebigen Formulars, wie z.B. Einstellungsformularen und Studentendarlehensformularen wie z.B. für das PLUS-Studentendarlehensprogramm, anwendbar.
Obwohl ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung gezeigt und beschrieben wurde, ist es für Fachleute ersichtlich, daß viele Änderungen und Modifikationen vorgenommen werden können, ohne von der Erfindung in ihren breiteren Aspekten abzuweichen. Da die Computer- und Computernetzwerkgebiete sich schnell ändern, wird erwartet, daß die Implementierung der Erfindung sich signifikant ändert, wenn sich die Technologie entwickelt. Die spezielle Programmiersprache und die Art der Datenbank können in Abhängigkeit von den Vorlieben des Programmierers geändert werden.

Claims

Verfahren zum Verarbeiten von elektronischen Formularen (128) über ein Computernetzwerk (18), umfassend: Übergeben eines elektronischen Formulars an einen Formularbenutzer über ein Computernetzwerk als Reaktion auf eine Anforderung vom Formularbenutzer, wobei das Formular Felder umfaßt, damit der Formularbenutzer eine Benutzerinformation eingibt; Eingeben der Benutzerinformation in das Formular, wobei einiges der Benutzerinformation aus einer gespeicherten Information automatisch in das Formular eingefügt wird; Empfangen der vom Benutzer eingegebenen Benutzerinformation über das Computernetzwerk; dadurch gekennzeichnet, daß es die weiteren Schritte umfaßt: Erzeugen des elektronischen Formulars unter Verwendung eines Formulargenerators, der mehrere Formulare erzeugt, wobei jedes Formular einer von mehreren Institutionen entspricht, wobei die Formulare von einem dritten Formulardienstleister (24) erzeugt, an den Formularbenutzer übergeben und verarbeitet werden, welcher weder eine der Institutionen noch einer von mehreren öffentlichen Formularbenutzern ist, wobei jedes Formular im Aussehen und Inhalt gemäß der Vorliebe der Institution, an die das Formular gerichtet ist, individuell aufgemacht ist und eine Quellenangabe entsprechend der Institution, an die das Formular gerichtet ist, umfaßt, um für die öffentlichen Formularbenutzer das Aussehen bereitzustellen, daß die Formulare den speziellen Institutionen zugeordnet sind, an die sie gerichtet sind; Verwalten einer Datenbank (62) durch den dritten Dienstleister welche die Benutzerinformation (119) speichert, die in die individuell aufgemachten Formulare eingegeben wird, und automatisch die Benutzerinformation aus der Datenbank in nachfolgende Formulare einfügt, die vom Benutzer fertiggestellt werden, einschließlich Formularen, die an verschiedene Institutionen gerichtet sind, Eingeben einer Zahlungsinformation; Empfangen einer elektronischen Zahlungsinformation, die vom Benutzer eingegeben wird, vom dritten Formulardienstleister über das Computernetzwerk; Verarbeiten einer elektronischen Zahlung (148), die dem Formular zugeordnet ist, durch den dritten Formulardienstleister, wobei die verarbeitete Zahlung vom Formularbenutzer an diejenige der mehreren Institutionen geht, an die das Formular gerichtet ist; und Verarbeiten der Benutzerinformation durch den dritten Formulardienstleister gemäß den Vorlieben der Institution, an die das Formular gerichtet ist, um die Benutzerinformation für die Institution in einem durch die Institution festgelegten Format zur Verfügung zu stellen, wobei der dritte Formulardienstleister dadurch individuell aufgemachte Formulare für öffentliche Benutzer bereitstellt, die mit Institutionen identifiziert sind, und für die Institutionen speziell formatierte Daten bereitstellt, während die Institution von der Verwaltungslast der Verarbeitung von Formularen und Zahlungen entlastet wird.
Verfahren nach Anspruch 1, wobei das Eingeben der Zahlungsinformation das Eingeben einer Zahlungsinformation in das Formular umfaßt.
Verfahren nach Anspruch 1, welches ferner umfaßt: Übergeben eines zweiten Formulars, das an eine andere der mehreren Institutionen gerichtet ist, durch den dritten Formulardienstleister über ein Computernetzwerk als Reaktion auf eine Anforderung vom Formularbenutzer; und automatisches Einfügen einer Benutzerinformation, die vorher durch den Formularbenutzer in ein Formular eingegeben wurde, in das zweite Formular.
Verfahren nach Anspruch 1, wobei das Empfangen der vom Benutzer eingegebenen Benutzerinformation über das Computernetzwerk das Überprüfen, daß die Benutzerinformation Kriterien erfüllt, die von der einen der mehreren Institutionen festgelegt werden, an die das Formular gerichtet ist, umfaßt.
Verfahren nach Anspruch 1, wobei das Übergeben eines elektronischen Formulars an einen Formularbenutzer über ein Computernetzwerk als Reaktion auf eine Anforderung vom Formularbenutzer das Übergeben eines elektronischen Formulars mit mehreren Seiten umfaßt.
Verfahren nach Anspruch 5, welches ferner das Überprüfen der Benutzerinformation auf jeder der mehreren Seiten, wenn sie abgesandt werden, gemäß Bewertungskriterien umfaßt.
Verfahren nach Anspruch 6, wobei das Überprüfen der Benutzerinformation auf jeder der mehreren Seiten, wenn sie abgesandt werden, gemäß Bewertungskriterien das Überprüfen der Benutzerinformation an einem Clientcomputer oder an einem Servercomputer umfaßt.
Verfahren nach Anspruch 6, wobei die Bewertungskriterien durch die Institution festgelegt werden, an die das Formular gerichtet ist.
Verfahren nach Anspruch 5, welches ferner das Überprüfen der Benutzerinformation auf jeder der mehreren Seiten, wenn sie abgesandt werden, gemäß ersten Bewertungskriterien und das Überprüfen der Benutzerinformation gemäß zweiten Bewertungskriterien, wenn ein fertiggestelltes Formular übermittelt wird, umfaßt.
Verfahren nach Anspruch 9, wobei das Überprüfen der Benutzerinformation gemäß ersten Bewertungskriterien das Überprüfen der Benutzerinformation an einem Clientcomputer umfaßt und wobei das Überprüfen der Benutzerinformation gemäß zweiten Bewertungskriterien das Überprüfen der Benutzerinformation an einem Servercomputer umfaßt.
Verfahren nach Anspruch 1, welches ferner das Überprüfen der Benutzerinformation auf einem fertiggestellten Formular gemäß Bewertungskriterien umfaßt, wenn das fertiggestellte Formular übermittelt wird.
Verfahren nach Anspruch 11, wobei die Bewertungskriterien von der Institution festgelegt werden, an die das Formular gerichtet ist.
Verfahren nach Anspruch 11, wobei das Überprüfen der Benutzerinformation auf dem fertiggestellten Formular gemäß Bewertungskriterien das Überprüfen der Benutzerinformation an einem Clientcomputer oder an einem Servercomputer umfaßt.
Verfahren nach Anspruch 1, wobei die Verarbeitung der Benutzerinformation durch den dritten Formulardienstleister gemäß den Vorlieben der Institution, an die das Formular gerichtet ist, um die Benutzerinformation für die Institution in einem Format zur Verfügung zu stellen, das von der Institution festgelegt wird, das Verfügbarmachen der Information über das World Wide Web umfaßt.
Vorrichtung zum Verarbeiten von Formularen (128) über ein Computernetzwerk (18) mit: einer Einrichtung zum Übergeben eines elektronischen Formulars an einen Formularbenutzer über ein Computernetzwerk als Reaktion auf eine Anforderung vom Formularbenutzer, wobei das Formular Felder umfaßt, damit der Formularbenutzer eine Benutzerinformation eingibt; einer Einrichtung zum Eingeben einer Benutzerinformation in das Formular, wobei einiges der Benutzerinformation aus einer gespeicherten Information automatisch in das Formular eingefügt wird; einer Einrichtung zum Empfangen einer Benutzerinformation, die vom Benutzer eingegeben wird, über das Computernetzwerk; dadurch gekennzeichnet, daß sie ferner umfaßt: eine Einrichtung zum Erzeugen des elektronischen Formulars unter Verwendung eines Formulargenerators, der mehrere Formulare erzeugt, wobei jedes Formular einer von mehreren Institutionen entspricht, wobei die Formulare durch einen dritten Formulardienstleister (24) erzeugt, an den Benutzer übergeben und verarbeitet werden, welcher weder eine der Institutionen noch einer von mehreren öffentlichen Formularbenutzern ist, wobei jedes Formular im Aussehen und Inhalt gemäß der Vorliebe der Institution, an die das Formular gerichtet ist, individuell aufgemacht ist und eine Quellenangabe entsprechend der Institution, an die das Formular gerichtet ist, umfaßt, um für die öffentlichen Formularbenutzer das Aussehen bereitzustellen, daß die Formulare den speziellen Institutionen zugeordnet sind, an die sie gerichtet sind; eine Einrichtung zum Verwalten einer Datenbank (62) durch den dritten Dienstleister, die eine Benutzerinformation (119) speichert, die in die individuell aufgemachten Formulare eingegeben wird, und die Benutzerinformation aus der Datenbank automatisch in nachfolgende Formulare, die vom Benutzer fertiggestellt werden, einfügt, einschließlich Formularen, die an verschiedene Institutionen gerichtet sind; eine Einrichtung zum Eingeben einer Zahlungsinformation; eine Einrichtung zum Empfangen der vom Benutzer eingegebenen elektronischen Zahlungsinformation durch den dritten Formulardienstleister über das Computernetzwerk; eine Einrichtung zum Verarbeiten einer elektronischen Bezahlung (148), die dem Formular zugeordnet ist, durch den dritten Formulardienstleister, wobei die verarbeitete Bezahlung vom Formularbenutzer an die eine der mehreren Institutionen geht, an die das Formular gerichtet ist; und eine Einrichtung zum Verarbeiten der Benutzerinformation durch den dritten Formulardienstleister gemäß den Vorlieben der Institution, an die das Formular gerichtet ist, um die Benutzerinformation für die Institution in einem von der Institution festgelegten Format zur Verfügung zu stellen, wobei der dritte Formulardienstleister dadurch für öffentliche Benutzer individuell aufgemachte Formulare bereitstellt, die mit Institutionen identifiziert sind, und für die Institutionen speziell formatierte Daten bereitstellt, während die Institution von der Verwaltungslast der Verarbeitung von Formularen und Bezahlungen entlastet wird.
Vorrichtung nach Anspruch 15, wobei die Einrichtung zum Eingeben einer Zahlungsinformation eine Einrichtung zum Eingeben einer Zahlungsinformation in das Formular umfaßt.
Vorrichtung nach Anspruch 15, welche ferner umfaßt: eine Einrichtung zum Übergeben eines zweiten Formulars, das an eine andere der mehreren Institutionen gerichtet ist, über ein Computernetzwerk durch den dritten Formulardienstleister als Reaktion auf eine Anforderung vom Formularbenutzer; und eine Einrichtung zum automatischen Einfügen einer Benutzerinformation, die vorher vom Formularbenutzer in ein Formular eingegeben wurde, in das zweite Formular.
Vorrichtung nach Anspruch 15, wobei die Einrichtung zum Empfangen einer vom Benutzer eingegebenen Benutzerinformation über das Computernetzwerk eine Einrichtung zum Überprüfen, daß die Benutzerinformation Kriterien erfüllt, die von der einen der mehreren Institutionen festgelegt werden, an die das Formular gerichtet ist, umfaßt.
Vorrichtung nach Anspruch 15, wobei die Einrichtung zum Übergeben eines elektronischen Formulars an einen Formularbenutzer über ein Computernetzwerk als Reaktion auf eine Anforderung vom Formularbenutzer eine Einrichtung zum Übergeben eines Formulars mit mehreren Seiten umfaßt.
Vorrichtung nach Anspruch 19, welche ferner eine Einrichtung zum Überprüfen der Benutzerinformation auf jeder der mehreren Seiten, wenn sie abgesandt werden, gemäß Bewertungskriterien umfaßt.
Vorrichtung nach Anspruch 20, wobei die Einrichtung zum Überprüfen der Benutzerinformation auf jeder der mehreren Seiten, wenn sie abgesandt werden, gemäß Bewertungskriterien eine Einrichtung zum Überprüfen der Benutzerinformation an einem Clientcomputer oder an einem Servercomputer umfaßt.
Vorrichtung nach Anspruch 20, wobei die Einrichtung zum Überprüfen gemäß Bewertungskriterien eine Einrichtung zum Überprüfen gemäß Bewertungskriterien, die von der Institution festgelegt werden, an die das Formular gerichtet ist, umfaßt.
Vorrichtung nach Anspruch 20, welche ferner eine Einrichtung zum Überprüfen der Benutzerinformation auf jeder der mehreren Seiten, wenn sie abgesandt werden, gemäß ersten Bewertungskriterien und eine Einrichtung zum Überprüfen der Benutzerinformation gemäß zweiten Bewertungskriterien, wenn ein fertiggestelltes Formular übermittelt wird, umfaßt.
Vorrichtung nach Anspruch 23, wobei die Einrichtung zum Überprüfen der Benutzerinformation gemäß ersten Bewertungskriterien eine Einrichtung zum Überprüfen der Benutzerinformation an einem Clientcomputer umfaßt und wobei die Einrichtung zum Überprüfen der Benutzerinformation gemäß zweiten Bewertungskriterien eine Einrichtung zum Überprüfen der Benutzerinformation an einem Servercomputer umfaßt.
Vorrichtung nach Anspruch 15, welche ferner eine Einrichtung zum Überprüfen der Benutzerinformation auf einem fertiggestellten Formular gemäß Bewertungskriterien, wenn das fertiggestellte Formular übermittelt wird, umfaßt.
Vorrichtung nach Anspruch 25, wobei die Einrichtung zum Überprüfen gemäß Bewertungskriterien eine Einrichtung zum Überprüfen gemäß Bewertungskriterien umfaßt, die von der Institution, an die das Formular gerichtet ist, festgelegt werden.
Vorrichtung nach Anspruch 25, wobei die Einrichtung, die die Benutzerinformation auf dem fertiggestellten Formular gemäß Bewertungskriterien überprüft, eine Einrichtung zum Überprüfen der Benutzerinformation an einem Clientcomputer oder an einem Servercomputer umfaßt.
Vorrichtung nach Anspruch 15, wobei die Einrichtung zum Verarbeiten der Benutzerinformation durch den dritten Formulardienstleister gemäß den Vorlieben der Institution, an die das Formular gerichtet ist, um die Benutzerinformation für die Institution in einem von der Institution festgelegten Format zur Verfügung zu stellen, eine Einrichtung umfaßt, um die Information über das World Wide Web zur Verfügung zu stellen.