DE10046076A1 - Vorrichtung zur Durchführung eines Transaktionsdialoges - Google Patents

Abstract

Die Erfindung betrifft eine Vorrichtung zur Durchführung eines Transaktionsdialoges über ein elektronisches Datenübertragungsnetz, insbesondere das Internet, mit einer zum Zugreifen auf eine serverseitige Datenverarbeitungsvorrichtung über das Datenübertragungsnetz ausgebildeten clientseitigen Datenverarbeitungsvorrichtung, die ein mittels Fenstereinheiten (52, 54) realisiertes, zum gleichzeitigen Ausführen einer Mehrzahl von Anwendungen in einer jeweils zugeordneten Fenstereinheit sowie zum gleichzeitigen Anzeigen einer Mehrzahl von Fenstern auf einer Ausgabe- und/oder Anzeigeeinheit der clientseitigen Datenverarbeitungsvorrichtung ausgebildetes Betriebssystem aufweist, DOLLAR A wobei ein Zugriff auf die serverseitige Datenverarbeitungsvorrichtung zum Durchführen des Transaktionsdialoges mittels einer mehrfach in einer entsprechenden Mehrzahl von Fenstereinheiten ablaufenden Zugriffseinheit der clientseitigen Datenverarbeitungsvorrichtung erfolgen kann, DOLLAR A und wobei jeder zum Durchführen der Transaktion eingerichteten Fenstereinheit eine Priorisierungseinheit zugeordnet ist, die so ausgebildet ist, dass im Fall einer Mehrzahl von parallel zum Durchführen desselben Transaktionsdialoges eingerichteten Fenstereinheiten (52, 54) nur eine der Mehrzahl von eingerichteten Fenstereinheiten zum Durchführen des Transaktionsdialoges aktiviert wird DOLLAR A und die anderen der eingerichteten Fenstereinheiten so deaktiviert werden, dass keine Benutzereingabe ermöglicht ist.

Description

Die vorliegende Erfindung betrifft eine Vorrichtung zur Durchführung eines Transaktionsdialoges über ein elektroni­ sches Datenübertragungsnetz, beispielsweise das Internet, wie sie mit mittels eines handelsüblichen PC mit für das Internet geeigneter Browser-Software sowie ansonsten be­ kannter Internet-Zugangstechnologie realisiert sein kann.

Insbesondere modernere, fensterbasierte Betriebssysteme, etwa Windows der Firma Microsoft, Linux und andere Unix- Versionen oder aber Mac-OS, ermöglichen es, eine Mehrzahl von Anwendungen gleichzeitig auf der clientseitigen Daten­ verarbeitungsvorrichtung ablaufen zu lassen, wobei prinzi­ piell, je nach Konfiguration und Einstellung der Datenüber­ tragungstechnologie, eine Mehrzahl von Zugriffen auf die serverseitige Datenverarbeitungsvorrichtung gleichzeitig in verschiedenen, geöffneten Fenstern erfolgen können.

Außerdem sieht die moderne Browsertechnologie, insbesondere ab HTML-Version 3, die Möglichkeit vor, dass innerhalb ei­ nes Browsers eine Mehrzahl von sog. Frames, also Rahmen, geöffnet sein können, die selbst wiederum jeweils eine ei­ gene HTTP-Verbindung über die bestehende Internetverbindung unterstützen können.

Dies bedeutet, dass mit existierender Internet- Zugriffstechnologie die Möglichkeit besteht, dass ein Be­ nutzer während einer Benutzersession mit der serverseitigen Datenverarbeitungsvorrichtung gleichzeitig mehrfach kommu­ nizieren kann, indem nämlich ein serverseitig zur Verfügung gestelltes elektronisches Dokument in Form einer Webseite in mehreren Frames innerhalb eines Browser-Fensters und/oder gleichzeitig in mehreren Fenstern mit jeweiligen Browseranwendungen angezeigt wird.

In der praktischen Internetnutzung kommt es insbesondere dann zu solchen Konstellationen, wenn, etwa auf Grund von übertragungsbedingten Wartezeiten, ein Nutzer parallel über verschiedene Frames und jeweils darin enthaltene Linkknöpfe versuchte, auf eine gewünschte Serverseite (möglichst schnell) zuzugreifen.

Prinzipiell ist dann eine solche mehrfache (redundante) Darstellung der gewünschten, vom Server bereitgestellten Inhaltsseite auf der clientseitigen Datenverarbeitungsvor­ richtung unproblematisch, allerdings nur solange, wie nicht über eine serverseitig zur Verfügung gestellte Webseite ein Dialog mit dem clientseitigen Nutzer initiiert wird und dieser z. B. aufgefordert wird, in eine auf der Webseite bereitgestellten Maske Informationen einzugeben. Hier be­ steht dann das Problem, dass möglicherweise in eine erste Maske (in einem ersten Frame und/oder Window) gewisse In­ formationen eingegeben werden, die nicht mit den Informa­ tionen in einem zweiten Fenster übereinstimmen; Datenüber­ tragungsprobleme bzw. gar der Abbruch der Verbindung können die Folge sein.

Noch gravierender wird das Problem, wenn mittels solcher, serverseitig initiierter Dialogseiten ein Zahlungsdialog begonnen wird, also etwa zur Abgeltung gewisser, über das Internet heranzuführender Leistungen (etwa zu ladender elektronischer Dokumentdateien, zur Aufgabe einer Warenbe­ stellung oder dergl.) der Benutzer aufgefordert wird, in eine solche Webseitenmaske Bezahlungsdaten, z. B. eine Kre­ ditkartennummer, einzugeben. Sind zu diesem Zeitpunkt meh­ rere identische (und damit redundante) Dialogmasken für den Benutzer angezeigt und damit zugreifbar, besteht die Ge­ fahr, dass der Benutzer womöglich in mehr als einen Frame bzw. mehr als ein Fenster entsprechende Zahlungsdialogdaten einträgt und so, durch die serverseitig automatisiert ab­ laufenden Zahlungsprozesse, die Gefahr von Mehrfachzahlun­ gen oder gar unklarer und/oder unsicherer Zahlungstransak­ tionen besteht.

Da jedoch HTTP-basierte Verbindungen, wie sie etwa in einer Mehrzahl von gleichzeitig auf einem Bildschirm existieren­ den Frames ablaufen, weitgehend unabhängig und autonom sind, gibt es clientseitig das Problem einer Koordination der verschiedenen offenen Kanäle zur Vermeidung der ge­ schilderten Problematik.

Aufgabe der vorliegenden Erfindung ist es daher, eine gat­ tungsgemäße Vorrichtung zur Durchführung eines Transakti­ onsdialoges über ein elektronisches Datenübertragungsnetz wie das Internet dahingehend zu verbessern, dass die Gefahr mehrfacher, ggf. widersprechender Eingaben in redundante, von einer Servereinheit bereitgestellter Transaktionsmasken mit den daraus resultierenden Problemen vermieden werden kann.

Die Aufgabe wird durch die Vorrichtung mit den Merkmalen des Patentanspruchs 1 gelöst; vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen beschrieben.

In erfindungsgemäß vorteilhafter Weise ist jeder Fen­ stereinheit eine Priorisierungseinheit zugeordnet, die so ausgebildet ist, dass die dieselbe Inhaltsseite des Trans­ aktionsdialoges anzeigenden Fenstereinheiten untereinander eine Priorität dergestalt festlegen und bestimmen, dass le­ diglich eine dieser Fenstereinheiten die Interaktion mit dem Server durch Freigeben einer entsprechenden Eingabe er­ möglicht, während dem Nutzer eine Eingabe von Informationen in die nicht erfindungsgemäß priorisierten Fenster unmög­ lich ist.

Praktisch führt dies dazu, dass zwar noch eine Mehrzahl von Frames auf dem Bildschirm angezeigt sein können, der Inhalt sehbar bzw. für eine Dateneingabe nutzbar ist jedoch nur noch ein Frame, so dass insoweit die Eindeutigkeit herge­ stellt ist.

Dabei soll der Begriff "Fenstereinheit" im Rahmen der vor­ liegenden Erfindung so verstanden werden, dass er sowohl Frames im Sinne des HTML-Standards umfasst, als auch Fen­ ster, die innerhalb einer Betriebssystemumgebung zum gleichzeitigen Betreiben einer Mehrzahl von User- Anwendungen vorgesehen sind, wie etwa in den Betriebssyste­ men MS-Windows, Mac-OS, Unix usw. möglich.

Besonders bevorzugt ist der von der Mehrzahl von beteilig­ ten Priorisierungseinheiten durchgeführte Priorisierungs­ prozess dynamisch und wird stets dann durchgeführt, wenn mehr als ein Fenster im Sinne der Erfindung dasselbe Trans­ aktionsdialogfenster für einen Nutzer anbietet.

Auch der Begriff "Transaktionsdialog" im Rahmen der Erfin­ dung ist dabei weit auszulegen; prinzipiell ist jegliche Form einer serverinduzierten Eingabemöglichkeit von Ziffern oder Buchstaben für den Nutzer betroffen, wobei diese Daten dann im Rahmen des Dialogprotokolls zur Serverseite über­ tragen und dort einen Verarbeitungsschritt auslösen.

In der praktischen Realisierung bietet es sich dabei an, die an dem Priorisierungsvorgang beteiligten Fenstereinhei­ ten untereinander eine Abstimmung bzw. Abgrenzung vornehmen zu lassen, und zwar insbesondere dahingehend, welche Fen­ stereinheit zeitlich zuerst einen Transaktionsdialog mit der clientseitigen Datenverarbeitungsvorrichtung initiiert hat. Dieser würde dann gemäß einer bevorzugten Ausführungs­ form Priorität zukommen, so dass dem Nutzer nur noch das Eingeben in die zugehörige Eingabe- bzw. Dialogmaske dieser Fenstereinheit ermöglicht ist.

Gemäß einer bevorzugten Ausführungsform der Erfindung liegt ein wichtiger Aspekt darin, die Funktion und Wirkungsweise der erfindungsgemäßen Priorisierungseinheiten asynchron durchzuführen, d. h. diese unabhängig von einer übergeord­ neten Steuerroutine oder dergl. jeweils nur aus einer je­ weiligen Fenstereinheit selbst (Fensterobjekte) zu starten, so dass insoweit der erfindungsgemäße Priorisierungsvorgang autonom durch Wirkung der bevorzugt als Programmobjekte realisierten Fenstereinheiten erfolgt, die jede für sich und mittels der jeweils zugeordneten Priorisierungseinheit untereinander nach einem vorbestimmten, eindeutigen Krite­ rium - etwa die vorerwähnte zeitliche Reihenfolge, oder aber ein höchster oder niedrigster Wert einer eindeutig und individuell jeder Fenstereinheit zugeordneten Identifikati­ onskennung - die Fenstereinheit mit der Priorität ermit­ teln, welche dann allein für die weitere Durchführung des Transaktionsdialogs verantwortlich ist.

Gemäß einer bevorzugten Weiterbildung wird dann durch diese Fenstereinheit mit Priorität der Transaktionsdialog nicht in der existierenden Dialogmaske fortgeführt, sondern diese wird so modifiziert, dass zusätzlich die Inhalte der weite­ ren (nicht priorisierten) Fenstereinheiten aufgenommen wer­ den, so dass der von der Fenstereinheit mit Priorität al­ lein fortgeführte Transaktionsdialog dann auf der Basis ei­ nes kombinierten Formulars bzw. einer kombinierten Dialog­ maske erfolgt und insoweit einen summarischen Charakter be­ kommt.

Weitere Vorteile, Merkmale und Einzelheiten der Erfindung ergeben sich aus der nachfolgenden Beschreibung bevorzugter Ausführungsbeispiele anhand der Figuren sowie der Anhänge 1 bis 4 zu der vorliegenden Beschreibung. In den Figuren zei­ gen:

Fig. 1 eine Schemaansicht von zwei Frameobjekten, je­ weils zur Eingabe von Bestelldaten auf einem ge­ meinsamen Bildschirm;

Fig. 2 eine durch Funktion der vorliegenden Erfindung erreichte Zusammenfassung der beiden Frameobjekte aus Fig. 1 zu einem gemeinsamen, summarischen Frameobjekt und

Fig. 3 ein Flussablaufdiagramm von jeweiligen, asynchro­ nen und simultan ablaufenden Prozessschritten der einzelnen Frameobjekte.

Im dargestellten Ausführungsbeispiel soll der Fall be­ schrieben werden, dass ein Benutzer einer über das Internet angebotenen Verkaufsdienstleistung simultan eine Mehrzahl von Rahmenobjekten (Frameobjekten) angeboten bekommt, wobei durch die vorliegende Erfindung das Problem überwunden wird, dass durch mehrfache, ggf. redundante Eingaben des Benutzers in die einzelnen Frameobjekte unnötiger Aufwand bzw. gar Buchungs- und/oder Verarbeitungsfehler der einge­ gebenen Daten entstehen.

Eine derartige Ausgangssituation zeigt Fig. 1 mit dem Bild­ schirminhalt eines symbolisch dargestellten Bildschirms 50, wie er etwa eine aktuelle Ansicht einer Internet-Verbindung darstellt, die mittels eines auf einer herkömmlichen PC- Anlage laufenden Internet-Browsers mit entsprechender Ver­ bindungskonfiguration zu einem geeigneten Diensteanbieter hergestellt ist.

Genauer gesagt zeigt der Bildschirm 50 zwei Frameobjekte 52, 54, welche der Benutzer z. B. durch aufeinanderfolgen­ des Betätigen eines Anforderungsbuttons einer vorhergehen­ den Angebotsseite des angerufenen Angebotsservers erhalten hat. Wie die Fig. 1 verdeutlicht, sind in dem Bildschirm­ fenster 50 (welches insoweit auch ein durch ein Betriebssy­ stem vorgegebenes Anwendungsfenster - innerhalb einer Mehrzahl von möglichen, parallel ablaufenden Anwendungen und zugehöriger Fenster - sein kann) die zwei Frameobjekte 52, 54 weitgehend redundant ausgebildet, d. h. sie enthal­ ten in Formularform jeweils zum Ausfüllen bzw. zur Daten­ eingabe durch den Benutzer vorgesehene Identifikations- und Adressfelder 56 sowie Zahlungstransaktionsfelder 58, so dass die Formulare der beiden Frameobjekte 52, 54 insoweit redundant sind. Da der Benutzer beim Auswählen verschiede­ ner Artikel jeweils eines der Frameobjekte 52, 54 aufgeru­ fen hat, sind in diesen Frameobjekten jedoch die Einträge für ein jeweils mit einem als Formular ausgestalteten Fra­ meobjekt zu bestellenden Artikel unterschiedlich; so diffe­ riert eine Artikelangabe 60 im oberen Frameobjekt 52 der Darstellung gem. Fig. 1 mit zugehöriger Preisangabe 62 von einer Artikelbeschreibung 64 (samt Preisangabe 66) des un­ teren Frameobjekts 54.

Die vorliegende Erfindung in der beschriebenen Ausführungs­ form verhindert nunmehr wirksam, dass der Benutzer die Fel­ der 56, 58 (d. h. im oberen sowie im unteren Frameobjekt 52, 54) doppelt ausfüllen muss und es hier möglicherweise sogar zu Buchungs- bzw. Bestellproblemen kommt, insbesonde­ re dann, wenn - etwa durch Tippfehler - hier unterschied­ liche Angaben gemacht werden.

Die konkrete Vorgehensweise ergibt sich dabei aus der Über­ sicht gem. Fig. 3, welche die jeweiligen, innerhalb der Frameobjekte 52, 54 ablaufenden Prozesse verdeutlicht, so­ wie dem zugehörigen Programmcode der Frameobjekte, wie er in den Anhängen 1 bis 4 exemplarisch verdeutlicht ist.

Wie in Fig. 3 gezeigt, werden durch ein Ereignis im Schritt S 10 die einzelnen Frameobjekte 52, 54 aufgerufen (in der Darstellung der Fig. 3 entspricht dem Frameobjekt 52 der im linken Bereich gezeigte Prozessablauf, dem Frameobjekt 54 der in der Figurmitte gezeigte Prozessablauf, beginnend mit einem Schritt S 12 bzw. S 14, und endend mit einem Schritt S 32 bzw. S 34).

Das das Anzeigen der beiden Frameobjekte auslösende Ereig­ nis im Schritt S 10 ist in der Form eines HTML-Dokuments in Anhang 1 verdeutlicht; exemplarisch ruft das in Anhang 1 dargestellte Programm die Frameobjekte "frm2.htm" 52 sowie "frm3.htm" 54 auf. Selbstverständlich kann jedes andere Er­ eignis, etwa ein Hyperlink auf einer vorangehenden Website oder dergl., für einen entsprechenden Aufruf der Frameob­ jekte 52, 54 sorgen; Anhang 1 ist insoweit lediglich exem­ plarisch.

Die Darstellung der Fig. 3 soll verdeutlichen, dass die ak­ tivierten Frameobjekte 52, 54 quasi-simultan und asynchron ablaufen, d. h. jeweils aus sich heraus Prozessschritte durchführen und untergeordnete Routinen in Form von Klas­ senobjekten ausführen; der Begriff "quasi-simultan" bedeu­ tet dabei, dass natürlich unter Kontrolle des den Betrieb der beschriebenen Vorrichtung (etwa innerhalb eines Web­ browsers) steuernden Betriebssystems einzelne Programm­ schritte sequentiell durch eine Prozessoreinheit des Rech­ ners abgearbeitet werden; die sequentielle Reihenfolge fin­ det jedoch auf einer tieferliegenden Maschinenebene statt und ist insbesondere unabhängig von den in Fig. 3 gezeigten parallelen Prozessschritten der einzelnen Frameobjekte. Der Begriff "asynchron" bedeutet dabei, dass die von den ein­ zelnen Frameobjekten 52, 54 durchzuführenden Prozessschrit­ te nicht unter Kontrolle eines übergeordneten Objektes, et­ wa eines Masterframes oder dergl., durchgeführt werden, sondern die nachfolgend zu beschreibenden Prozessschritte, eingeschlossen das Feststellen, dass sämtliche Frameobjekte vollständig auf dem Bildschirm geladen sind, und das Ermit­ teln eines prioritätsbesten Frameobjekts unter diesen, ge­ schehen eigenständig und aus den jeweiligen Frameobjekten heraus.

So baut in Schritt S 12 das Frameobjekt 52 den oberen Bild­ schirminhalt des Bildschirms 50 auf, wie es in Fig. 1 ge­ zeigt ist. Anhang 2 verdeutlicht für das Frameobjekt 52 (und analog auch für das Frameobjekt 54) den HTML-Code, wie er zum Aufbau der in Fig. 1 gezeigten Formulare und zum An­ stoßen der weiteren Prozessschritte vorgesehen ist; insbe­ sondere durch Aufruf der Funktion "MakeFormular" (Zeile 32 von Anhang 2) wird hier das konkrete Formularbild für das Frameobjekt 52 (und analog in Schritt S 14 für das Frameob­ jekt 54) entworfen, wobei der HTML-Code in Anhang 2 unter Übergabe einer eindeutigen Formularidentifikationsnummer (welche im beschriebenen Beispiel vorgegeben ist, jedoch auch variabel durch einen Zufallsgenerator, durch Einbezie­ hung einer Zeitgröße oder dergl. erzeugt werden kann), un­ ter Übergabe des Beschreibungstextes für das Artikelbe­ schreibungsfeld 60 sowie des zugehörigen Preisfeldes 62 als Parameter eine entsprechende Java-Script-Funktion (Anhang 4 ab Zeile 13 mit dem zugehörigen Script-Listing) aufruft.

Der HTML-Code für das Frameobjekt 54 ist analog dem Code in Anhang 2 gebildet und ruft in entsprechender Weise mit den zugehörigen Übergabeparametern die Java-Script- Programmklasse in Anhang 4 auf.

Wie in der Fig. 3 gezeigt, folgt auf das Aufrufen bzw. Dar­ stellen der konkreten Formularmasken durch die Frameobjekte 52, 54 in Fig. 1 (Schritte S 12 bzw. S 14) jeweils ein Überprüfungsschritt, nämlich daraufhin, dass nicht nur das einem jeweiligen Frameobjekt zugehörige Formular geladen und vollständig auf dem Bildschirm 50 des Nutzers darge­ stellt wurde, sondern auch dass alle weiteren, auf dem Bildschirm dargestellten bzw. darzustellenden Frameobjekte vollständig geladen sind. Mit anderen Worten, jedes Frame­ objekt führt in einem eigenen Abfrageschritt eine entspre­ chende Überprüfung auf sämtliche Frameobjekte und deren La­ destatus durch, und erst nachdem diese Überprüfung positiv ausgegangen ist kann ein nachfolgender Schritt (S 20 bzw. S 22) ausgeführt werden. Dieser Umstand der asynchron reali­ sierten Überprüfung auf Vollständigkeit der Darstellung al­ ler Frameobjekte auf dem Bildschirm 50, realisiert durch den Verfahrensschritt S 16 im Frameobjekt 52 sowie den Schritt S 18 im Frameobjekt 54, wird schematisch darge­ stellt durch die gestrichelte Linie 80, die insoweit ver­ deutlicht, dass die jeweils in den Schritten S 16, S 18 ge­ troffenen Entscheidungen auch von anderen Frameobjekten als nur dem eigenen abhängen.

Programmtechnisch wird dies innerhalb des HTML-Codes gem. Anhang 2 durch die Funktion "CheckReady" (Zeile 15) reali­ siert, welche eine entsprechende Java-Script-Funktion in der Anhang 3 dargestellten Java-Script-Programmklasse (dort ab Zeile 16) aufruft. Genauer gesagt wird durch diese Funk­ tion eine Variable "isReady" auf WAHR gesetzt, wenn alle Frameobjekte, im dargestellten Ausführungsbeispiel solche, die den Namen "BrainShieldPaymentForm" tragen, vollständig geladen sind. Diese Überprüfung findet innerhalb einer ver­ schachtelten Schleife mit zwei Laufparametern statt (Java- Script-Progammcode in Anhang 3 ab Zeile 22), wobei inner­ halb einer äußeren Schleife (Laufvariable i) sämtliche Fra­ meobjekte innerhalb des Browserfensters durchlaufen werden und in einer inneren Schleife (Laufvariable j) alle inner­ halb eines jeweiligen Frameobjektes vorgesehene Formulare. Ergibt die Überprüfung - zusätzlich ist in den Zeilen 54 bis 60 eine Zeitverzögerung vorgesehen, um evtl. sich nur langsam aufbauende Formulardarstellungen zu erfassen -, so wird die Variable "isReady" auf WAHR gesetzt, und aus der Funktion "CheckReady" wird ein nachfolgender Schritt, näm­ lich das Ermitteln, ob ein jeweiliges Frameobjekt innerhalb der Mehrzahl von Frameobjekten eine Prioritätsstellung be­ sitzt, angestoßen.

Dieser Prozessschritt ist in Fig. 3 mit Schritt S 20 für das Frameobjekt 52 und mit S 22 für das Frameobjekt 54 sym­ bolisiert. Hinter der Feststellung der Priorität steckt der erfinderische Gedanke, dass bei einer Mehrzahl von redun­ danten bzw. denselben Eingabezweck verfolgenden Frameobjek­ ten mit zugehörigen Formularen, wie es bei der Fig. 1 ge­ zeigten Konstellation mit den Frameobjekten 52, 54 der Fall ist, nur eines dieser Frameobjekte eine Prioritätsstellung erhalten soll und dann alleine verantwortlich für den wei­ teren Dialog mit dem Benutzer, eingeschlossen das (nur ein­ malige) Erfassen der gewünschten Daten und das Weiterverar­ beiten derselben, sein soll.

Mit anderen Worten, mittels der Prozessschritte S 20 bzw. S 22 ermitteln die Frameobjekte 52, 54 jeweils untereinander, welches Frameobjekt zur Weiterführung des Benutzerdialoges die (alleinige) Priorität genießt; da auch diese Prozess­ schritte einen Abgleich zwischen sämtlichen aktiven Frame­ objekten auf der Bildschirmdarstellung 50 vorsehen, ist dies durch eine gestrichelte Linie 82 in Fig. 3 symboli­ siert.

Programmtechnisch findet dies seine Umsetzung durch die Funktion "Priority" (ab Zeile 100 von Anhang 3), worin wiederum innerhalb der vorbeschriebenen, zweifach geschach­ telten Schleife über alle Frameobjekte und alle darin exi­ stierenden Formulare, jeweilige, für ein Formular eindeuti­ ge Identitätsnummern miteinander verglichen werden und er­ mittelt wird, ob ein eigenes Formular des betreffenden Fra­ meobjekts den höchsten Wert der Identitätsnummer besitzt; in diesem Fall wird der Wert WAHR durch die Funktion "Priority" zurückgegeben, anderenfalls wird der Wert auf logisch FALSCH gesetzt. (Während im beschriebenen Ausfüh­ rungsbeispiel ein einfacher Vergleich vorgegebener, für je­ weilige Formulare unterschiedlicher Identitätsnummern zur Ermittlung der Priorität herangezogen wird, gibt es natür­ lich auch andere Möglichkeiten, auf eindeutige Weise eines der Frameobjekte zu priorisieren, etwa durch einen Ver­ gleich von jeweiligen Formularen der Frameobjekte zugehöri­ gen Zeitwerten, von beim Erzeugen der Formulare generierten Zufallswerten oder dergl.).

Ebenfalls ergibt das Durchführen der Schritte S 20 bzw. S 22 zur Prioritätsermittlung in den jeweiligen Frameobjekten eindeutig, dass nur eines der Frameobjekte Priorität, also Vorrang, im oben skizzierten Sinne genießt; im beschriebe­ nen Ausführungsbeispiel soll dies das Frameobjekt 52 sein, da dessen (einziges) Formular im Wert größere Identifikati­ onsnummer trägt als das (einzige) Formular des Frameobjekts 54 und insoweit die Funktion "Priority" innerhalb des Fra­ meobjektes 52 den Wert WAHR zurückgegeben hatte (S 20), während dieser Vorgang innerhalb des Prozessablaufes des Frameobjektes 54 mit dem Ergebnis logisch FALSCH ausging.

Entsprechend ergibt eine nachfolgende Überprüfung im Ent­ scheidungsschritt S 24 auch das Vorliegen von Priorität für das erste Frameobjekt 54 die Entscheidung "Ja", so dass die weiteren Schritte S 28, S 32 ablaufen können. Dagegen bricht durch eine Negativentscheidung in Schritt S 26 in­ nerhalb des Prozessablaufs des Frameobjektes 54 die in Fig. 3 gezeigte Routine ab, so dass die nachfolgenden Schritte S 30, S 34 (die insoweit analog zu S 28, S 32 sind) nicht ausgeführt werden.

Genauer gesagt erfolgt nunmehr in Schritt S 28 das Zusam­ menfassen sämtlicher Anzeigetexte der verschiedenen Formu­ lare gem. Fig. 1 (Beschreibungstexte 60, 64 sowie Inhalts­ angaben 62, 66) zu einem gemeinsamen Text- und Anzeige­ string (Zeilen 73 bis 82 von Anhang 3 innerhalb der Funkti­ on "CheckFramesWithPayment"), und im darauffolgenden Schritt S 32 wird innerhalb des Frameobjektes 52 ein neues (gemeinsames) Fenster mit einem neuen Formular erzeugt, welches nunmehr das einzige, auf dem Bildschirm 50 darge­ stellte Frameobjekt ist und in einem gemeinsamen Formular die Inhalte der ursprünglichen Frameobjekte 52, 54 zusam­ menfasst (realisiert durch den Java-Script-Code in den wei­ teren Zeilen 88 ff. von Anhang 3 und unter Aufruf der Funk­ tion "GetSammelformInnerHTML" ab Zeile 213 von Anhang 4).

Das Ergebnis dieser Darstellung gem. Verfahrensschritt S 28, S 32 mit einem gemeinsamen Formular 70 (gleichwohl un­ ter Kontrolle des Frameobjektes 52) zeigt die Fig. 2: Das Formular listet nunmehr die in Fig. 1 noch jeweils in einem einzelnen Formular enthaltenen Produktbeschreibungen 60, 64 samt Preisangaben 62, 66 gemeinsam auf, und in dem gemein­ samen Formular sind entsprechend noch gemeinsame Identifi­ kations- und Zahlungsfelder 56, 58 - lediglich einmal - durch den Benutzer auszufüllen.

In der weiteren Durchführung des Dialoges mit dem Benutzer ist damit sichergestellt, dass potentiell fehlerträchtige Mehrfacheingaben wirksam unterdrückt werden, denn der Be­ nutzer hat überhaupt nicht mehr die Möglichkeit, auf die Mehrzahl von ursprünglichen Formularen der Mehrzahl von Frameobjekten zuzugreifen; dies wurde erreicht durch die erfindungsgemäße Maßnahme, bei den, wie vorliegend, redun­ danten Formularen einem Frameobjekt die alleinige Kontrolle über die weitere Dialogführung mit dem Benutzer durch das Ermitteln und Festlegen der Priorität zuzuweisen.

Die vorliegende Erfindung ist nicht auf den Abgleich von Frameobjekten als "Frames" im Sinne von HTML sowie in der beschriebenen Browserumgebung beschränkt. Vielmehr bietet es sich an, den erfindungsgemäßen Ansatz auf beliebige Dia­ lograhmen, eingeschlossen etwaige, durch eine Betriebssy­ stemebene vorgegebene Rahmen, zu übertragen, bei denen in­ nerhalb eines Eingabedialoges mit einem Benutzer redundante Eingaben zu vermeiden sind.

Anhang 1

Anhang 2

Anhang 3

Anhang 4

Claims (9)

1. Vorrichtung zur Durchführung eines Transaktionsdialo­ ges über ein elektronisches Datenübertragungsnetz, insbesondere das Internet,
mit einer zum Zugreifen auf eine serverseitige Daten­ verarbeitungsvorrichtung über das Datenübertragungs­ netz ausgebildeten clientseitigen Datenverarbeitungs­ vorrichtung, die ein mittels Fenstereinheiten (52, 54) realisiertes, zum gleichzeitigen Ausführen einer Mehrzahl von Anwendungen in einer jeweils zugeordne­ ten Fenstereinheit sowie zum gleichzeitigen Anzeigen einer Mehrzahl von Fenstern auf einer Ausgabe- und/oder Anzeigeeinheit der clientseitigen Datenver­ arbeitungsvorrichtung ausgebildetes Betriebssystem aufweist,
und wobei ein Zugriff auf die serverseitige Datenver­ arbeitungsvorrichtung zum Durchführen des Transak­ tionsdialoges mittels einer mehrfach in einer ent­ sprechenden Mehrzahl von Fenstereinheiten ablaufenden Zugriffseinheit der clientseitigen Datenverarbei­ tungsvorrichtung erfolgen kann,
dadurch gekennzeichnet, dass
jeder zum Durchführen der Transaktion eingerichteten Fenstereinheit eine Priorisierungseinheit zugeordnet ist, die so ausgebildet ist, dass im Fall einer Mehr­ zahl von parallel zum Durchführen desselben Trans­ aktionsdialoges eingerichteten Fenstereinheiten (52, 54) nur eine der Mehrzahl von eingerichteten Fen­ stereinheiten zum Durchführen des Transaktionsdialo­ ges aktiviert wird
und die anderen der eingerichteten Fenstereinheiten so deaktiviert werden, dass keine Benutzereingabe er­ möglicht ist.

2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass
die Priorisierungseinheit zum Durchführen eines Priorisierungsprozesses zwischen der Mehrzahl von
eingerichteten Fenstereinheiten ausgebildet ist und als Ergebnis des Priorisierungsprozesses die eine Fenstereinheit aktiviert wird.

3. Vorrichtung nach Anspruch 2, dadurch gekennzeichnet, dass der Priorisierungsprozess diejenige aus der Mehrzahl von eingerichteten Fenstereinheiten ermit­ telt, die zuerst zum Durchführen des Transaktionsdia­ loges eingerichtet wurde, oder die einen größten oder kleinsten Wert eines individuell und eindeutig jeder Fenstereinheit zugeordneten Identifikationskenners besitzt.

4. Vorrichtung nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der Transaktionsdialog ein mit­ tels einer Eingabemaske (56, 58) od. dgl. realisierter Zahlungs- oder Eingabedialog ist.

5. Vorrichtung nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Fenstereinheiten als Frames innerhalb eines Internet-Browsers als Zugriffseinheit realisiert sind.

6. Vorrichtung nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Fenstereinheiten sowie die zugeordneten Priorisierungseinheiten als Objekte mit aktiven Codes, insbesondere auf der Basis von JAVASCRIPT, VISUAL BASIC SCRIPT, XML ausgebildet sind, eine Priorisierungseinheit jeder Fenstereinheit zugeordnet ist und asynchron aktiviert werden kann, sobald eine zur Durchführung des Transaktionsdialoges vorgesehene Dialogmaske auf jeder eingerichteten Fen­ stereinheit vollständig auf einem Bildschirm oder dergl. Ausgabeeinheit dargestellt ist.

7. Vorrichtung nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Priorisierungseinheit jeder Fenstereinheit automatisch aktiviert wird, sobald die clientseitige Datenverarbeitungsvorrichtung eine red­ undante Dialogmaske zur Eingabe durch einen Benutzer anbietet.

8. Vorrichtung nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Priorisierungseinheit Be­ standteil des Betriebssystems des clientseitigen und/oder serverseitigen Betriebssystems ist.

9. Vorrichtung nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Priorisierungseinheit zum Erfassen von Inhalten, (60, 62, 64, 66) aus allen zum Durchführen der Transaktion eingerichteten Fen­ stereinheiten, zum Erstellen und Anzeigen eines kom­ binierten Transaktionsfensters (70) daraus sowie zum Durchführen des Transaktionsdialoges mit diesem kom­ binierten Transaktionsfenster ausgebildet ist.