DE10101069A1

DE10101069A1 - Verfahren, Computerprogrammprodukte, System sowie Nebentransaktionsserver zur Durchführung von Nebentransaktionen im Rahmen von Haupttransaktionen über ein Netzwerk

Info

Publication number: DE10101069A1
Application number: DE10101069A
Authority: DE
Inventors: Piero Stinelli
Original assignee: KLANGUNDKLEID DE GmbH
Current assignee: KLANGUNDKLEID DE GmbH
Priority date: 2001-01-11
Filing date: 2001-01-11
Publication date: 2002-07-25

Abstract

Die Erfindung betrifft ein Verfahren zur Durchführung von Nebentransaktionen im Rahmen von Haupttransaktionen über ein Netzwerk, umfassend wenigstens einen Benutzerhost, einen Haupttransaktionsserver und einen Nebentransaktionsserver, wobei: der Benutzerhost ein Dokument (1) vom Haupttransaktionsserver anfordert; der Haupttransaktionsserver das angeforderte Dokument (1) an den Benutzerhost zurücksendet, wobei dieses wenigstens eine auf den Nebentransaktionsserver verweisende Referenz aufweist; der Benutzhost eine der Referenz entsprechende Anfrage an den Nebentransaktionsserver sendet, wobei im Falle, daß der zugehörige Benutzer für die Nebentransaktionen registriert ist, der Benutzerhost zusätzlich eine Benutzerkennung zur Identifizierung des Benutzers sendet; der Nebentransaktionsserver auf die Anfrage des Benutzerhosts hin eine nebentransaktionsbezogene Referenzinformation (x¶2¶; x¶3¶; x¶4¶; x¶5¶; x¶6¶) an den Benutzerhost zurücksendet, wobei im Falle, daß der Benutzer für die Nebentransaktionen registriert ist, die Referenzinformation (x¶2¶; x¶3¶; x¶4¶; x¶5¶; x¶6¶) von früheren Nebentransaktionen des Benutzers abhängt; der Benutzerhost das Dokument (1) darstellt, wobei die Referenzinformation (x¶2¶; x¶3¶; x¶4¶; x¶5¶; x¶6¶) in das Dokument (1) eingefügt wird. DOLLAR A Die Erfindung betrifft auch entsprechende Verfahren zum Ablauf auf einem Benutzerhost bzw. einem Nebentransaktionsserver, entsprechende Computerprogramm-Produkte, ein entsprechendes System und einen ...

Description

Die Erfindung betrifft Verfahren, Computerprogrammprodukte, ein System sowie einen Nebentransaktionsserver zur Durchfüh rung von Nebentransaktionen im Rahmen von Haupttransaktionen über ein Netzwerk.

Das Internet stellt heute das von der Allgemeinheit am mei sten genutzte Computer-Netzwerk der Welt dar. Das Internet ist ein Netzwerk von Computern und Computer-Netzwerken, die über standardisierte Arbeitsweisen und Protokolle (die sog. TCP/IP-Protokollsuite) miteinander kommunizieren können. Der am schnellsten wachsende Dienst des Internets beruht auf dem Hypertext Transfer Protocol (HTTP) und wird World Wide Web (WWW) genannt. Hierbei werden i. a. einzelne Dokumenten, sog. Web-Seiten oder Web-Pages, über das Netz übertragen, die sog. Hyperlinks aufweisen können und so einem Benutzer erlauben, sich im WWW von einer Web-Seite zur nächsten zu bewegen. Die Hyperlinks erscheinen dem Benutzer z. B. in Form von unter strichenem Text oder Grafikelementen, die er durch Anklicken mit dem Mauszeiger aktivieren kann, um zur nächsten Web-Seite zu gelangen.

Die Web-Seiten des WWW basieren überwiegend auf der Befehls sprache Hypertext Mark-up Language (HTML). Bei HTML handelt es sich um eine an sich statische Befehlssprache, d. h., daß eine einmal dargestellte Web-Seite nachträglich nicht mehr verändert werden kann. Um hier Abhilfe zu schaffen, sind Lö sungen wie dynamic HTML (dHTML) geschaffen worden, die es er möglichen, einzelne Elemente einer Web-Seite während der An zeige dynamisch zu verändern. Daneben sind Lösungen wie Com mon Gateway Interface (CGI) oder Active-Server-Pages (ASP) bekannt, die einen interaktiven Datenaustausch zwischen dem Web-Browser und einem Web-Server erlauben. Dabei werden vom Web-Server auf Eingaben des Benutzers hin neue Web-Seiten ge neriert und an den Web-Browser zurückgesendet.

HTTP ist ein Client-Server-Protokoll. Der Benutzer benötigt einen Client, üblicherweise Web-Browser genannt, um die ge wünschten Web-Seiten aufzurufen und darstellen zu lassen. Der Web-Browser fordert dazu die gewünschte Web-Seite unter Öff nung einer Verbindung von einem Webserver an, der diese dann an den Web-Browser zurücksendet und die Verbindung zum Browser schließt. Während sich ein Benutzer durch Anklicken verschiedener Hyperlinks innerhalb des WWW von Web-Seite zu Web-Seite bewegt, laufen viele solcher Anforderungs-Antwort- Vorgänge im Rahmen einzelner Browser-Server-Verbindungen ab.

Die von einem Web-Server übermittelte Web-Seite kann sog. Re ferenzen enthalten, die auf eine weitere Datei des gleichen oder eines anderen Web-Servers verweisen und den Web-Browser veranlassen, diese Datei von dem betreffenden Web-Server an zufordern. Eine Web-Seite kann sich also aus dem Inhalt meh rerer Dateien zusammensetzen, die jeweils von verschiedenen Web-Servern übermittelt werden. So ist es möglich, daß auf einer Web-Seite Inhalte dargestellt werden, die von einem an deren als demjenigen Web-Server stammen, von dem die Web- Seite angefordert wurde.

Diese Möglichkeit macht man sich heute z. B. zur Einblendung von Werbeinhalten nützlich, indem in die betreffenden Web- Seiten statt des gesamten Werbeinhalts nur jewiels eine entsprechende Referenz zu einem Werbe-Server eingebaut wird. Auf diese Weise ist es auch möglich, die Werbeinhalte unabhängig vom übrigen Inhalt der Web-Seiten zu verändern, so daß flexi ble Werbung bis hin zur Einblendung benutzerspezifischer Wer beinhalte möglich ist. In diesem Zusammenhang sind die Druck schriften US 5,948,061, WO 98/58334 und WO 00/08802 zu nen nen, aus denen Methoden zur Einblendung von Werbeinhalten be kannt sind.

Weiter handelt es sich bei HTTP um ein zustandsloses Proto koll, da nach jeder Erledigung einer Anforderung die Verbin dung zwischen Web-Browser und Web-Server wieder geschlossen wird. Die einzelnen Verbindungen sind unabhängig voneinander, d. h., daß der Web-Server keinen logischen Zusammenhang zwi schen den einzelnen Verbindungen schafft, auch wenn die zuge hörigen Anforderungen von ein und demselben Web-Browser stam men. Vielmehr wird für jede der Anforderungen eine eigene Verbindung geöffnet, die nach Zurücksenden der zugehörigen Antwort wieder geschlossen wird.

Aufgrund der technischen Gegebenheiten hat der Benutzer die Möglichkeit, sich innerhalb des WWW frei zu bewegen, d. h. den Datenaustausch zwischen Web-Browser und Web-Server jederzeit zu unterbrechen und von der gerade aufgerufenen zu einer an deren Web-Seite zu springen. Dies erschwert es den Anbietern im WWW, die Benutzer auf ihren Web-Seiten zu halten und als Kunden zu gewinnen. Hinzu kommt das ständig wachsende Angebot an neuen Web-Seiten, das aus Benutzersicht allein kaum zu überblicken ist. Die Web-Seiten-Anbieter sind daher zu einem hohen Marketingaufwand gezwungen, um die für die Durchsetzung am Markt notwendige Bekanntheit zu erlangen. Diese Probleme stellen den Nutzen des Internets als Werbe- und Verkaufsmedi um, insbesondere für weniger finanzstarke Unternehmen, stark in Frage.

Es ist daher wünschenswert, Möglichkeiten aufzuzeigen, die Bindung der Benutzer an bestimmte Web-Seiten-Anbieter bzw. Gruppen von Web-Seiten-Anbietern zu erhöhen.

Der Erfinder der vorliegenden Erfindung hat erkannt, daß man Referenzen in einem Dokument dazu nutzen kann, im Rahmen von ersten Transaktionen zwischen einem Benutzerhost und einem oder mehreren Haupttransaktionsservern, im folgenden Haupt transaktionen genannt, zweite Transaktionen zwischen dem Be nutzerhost und einem Nebentransaktionsserver, im folgenden Nebentransaktionen genannt, ablaufen zu lassen. Haupt- und Nebentransaktionen werden so ineinander "geschachtelt", wobei die einzelnen Nebentransaktionen voneinander abhängen und dem betreffenden Benutzerhost anhand einer Benutzerkennung zuge ordnet werden. Durch die logische Verknüpfung der Nebentrans aktionen und deren Verschachtelung mit den Haupttransaktionen entsteht aus Sicht des Benutzers auch zwischen den verschie denen Haupttransaktionen ein logischer Zusammenhang (auch wenn dieser tatsächlich nur zwischen den Nebentransaktionen besteht).

Im einzelnen stellt die Erfindung ein Verfahren zur Durchfüh rung von Nebentransaktionen im Rahmen von Haupttransaktionen über ein Netzwerk mit wenigstens einem Benutzerhost, einem Haupttransaktionsserver und einem Nebentransaktionsserver be reit, wobei folgende Schritte ablaufen: Der Benutzerhost for dert ein Dokument vom Haupttransaktionsserver an; der Haupt transaktionsserver sendet das angeforderte Dokument an den Benutzerhost, wobei dieses wenigstens eine auf den Neben transaktionsserver verweisende Referenz aufweist; der Benut zerhost sendet eine der Referenz entsprechende Anfrage an den Nebentransaktionsserver, wobei im Falle, daß der Benutzer für die Nebentransaktionen registriert ist, der Benutzerhost zu sätzlich eine Benutzerkennung zur Identifizierung des Benut zers sendet; der Nebentransaktionsserver sendet auf die An frage des Benutzerhost hin eine spezifische nebentransakti onsbezogene Referenzinformation an den Benutzerhost zurück, wobei diese im Falle, daß der Benutzer für die Nebentransak tionen registriert ist, von früheren Nebentransaktionen des Benutzers abhängt; der Benutzerhost stellt das Dokument dar, wobei die Referenzinformation in das Dokument eingefügt wird.

Der letztgenannte Verfahrensschritt kann dabei auch schon zeitgleich mit vorherigen Verfahrensschritten ablaufen, da der Benutzerhost bereits mit der Darstellung des Dokumentes beginnen kann, sobald er einen ersten Teil von diesem vom Haupttransaktionsserver empfangen hat.

Unter "Transaktionen" wird im Zusammenhang mit der Erfindung die kleinste atomare Ausführungseinheit bei einem Datenaus tausch zwischen Benutzerhost und Web-Server verstanden. Hier bei kann eine Transaktion einen einzelnen Verbindungsaufbau zwischen Benutzerhost und Web-Server zum Zwecke eines Anfor derungs-Antwort-Vorganges darstellen, aber auch mehrere sol cher Verbindungsaufbauten umfassen, wenn diese eine in sich geschlossene, von anderen Transaktionen unabhängige Einheit bilden.

Der Begriff "Server" beschränkt sich im Zusammenhang mit der Erfindung nicht auf einzelne Hosts, sondern umfaßt auch Ser versysteme mit mehreren Servern, an welche zusätzliche Daten banksysteme angeschlossen sein können.

Der Begriff "Dokument" richtet sich schließlich sowohl auf das auf dem Benutzerhost bzw. Web-Browser dargestellte Doku ment als auch auf die zugehörige Datei, in der die für die Darstellung des Dokuments notwendigen Anweisungen enthalten sind. Diese Anweisungen sind üblicherweise in einer Dokumen tenbeschreibungs-Sprache, beispielsweise in HTML, definiert.

Das erfindungsgemäße Verfahren ermöglicht dem Benutzerhost somit, zeitgleich zu ablaufenden Haupttransaktionen mit einem oder mehreren Haupttransaktionsservern, benutzerspezifische Nebentransaktionen ablaufen zu lassen, die im Falle eines re gistrierten Benutzers logisch miteinander verknüpft sind. Einzige Voraussetzung für den zeitgleichen Ablauf der Neben transaktionen ist, daß die im Rahmen der Haupttransaktionen aufgerufenen Dokumente, etwa verschiedene Web-Seiten im WWW, jeweils wenigstens eine auf den Nebentransaktionsserver ver weisende Referenz aufweisen. Da sich eine solche Referenz im Regelfall ohne größeren Aufwand in ein Dokument einfügen läßt, ist es leicht möglich, in kurzer Zeit viele Dokumente für den Ablauf von Nebentransaktionen einzurichten. Im Be darfsfall können auch komplizierte Nebentransaktionen beim Aufruf von Dokumenten durchgeführt werden, da diese auf dem Nebentransaktions-Server ablaufen und daher kein erhöhter Programmieraufwand auf Seiten der Haupttransaktionsserver entsteht.

Durch die logische Verknüpfung von Dokumenten verschiedener Haupttransaktionsserver über die Nebentransaktionen, werden Benutzer, die diese Nebentransaktionen durchführen möchten, veranlaßt, diese Dokumente aufzurufen. Bestimmte Benutzer gruppen können so mittels der Erfindung durch ein entspre chendes Angebot an Nebentransaktionen dazu gebracht werden, sich im vermehrtem Maße auf bestimmten Dokumenten, etwa den Web-Seiten bestimmter Anbieter, zu bewegen.

Im Gegensatz dazu sind die eingangs erwähnten Werbeeinblen dungen für das Ziel der Erfindung, nämlich die Bindung von Benutzern an bestimmte Web-Seiten-Anbieter bzw. Gruppen von Web-Seiten-Anbietern zu erhöhen, eher kontraproduktiv. Denn mit den Werbeeinblendungen werden zwar zusätzliche Inhalte in die Web-Seiten eingebracht, diese führen jedoch i. a. (da sie in aller Regel als Hyperlinks auf die Web-Seiten des werben den Unternehmens definiert sind) von der ursprünglichen Web- Seite weg.

Gemäß Anspruch 2 beruht die Registrierung des Benutzers auf einer vor Ablauf des Verfahrens stattfindenden Anmeldung beim Nebentransaktionsserver. Dem betreffenden Benutzerhost wird dann eine Benutzerkennung zugeordnet, die dieser dann bei zu künftigen Anfragen an den Nebentransaktionsserver mitsendet.

Gemäß Anspruch 3 wird dem Benutzer beim Ablauf der ersten Ne bentransaktion automatisch, also ohne vorhergehende Anmel dung, eine Benutzerkennung zugeordnet.

Anspruch 4 sieht vor, daß Benutzer, die nicht für die Neben transaktionen registriert sind, als Referenzinformation eine Standardinformation übermittelt bekommen, die für jeden nicht-registrierten Benutzer gleich ausgestaltet ist. Dies ist besonders in jenen Fällen vorteilhaft, in denen die Regi strierung des Benutzers eine vorhergehende Anmeldung beim Ne bentransaktionsserver erfordert. Die Standardinformation kann dann beispielsweise auf das Anmeldeerfordernis hinweisen oder so ausgestaltet sein, daß sie vom Benutzer gar nicht wahrge nommen werden kann. Letzteres kann dazu dienen, die Neben transaktionen nur angemeldeten Benutzern zugänglich zu ma chen. Gleichzeitig wird so verhindert, daß nicht-registrierte Benutzer durch nebentransaktionsbezogene Inhalte auf dem Do kument abgelenkt oder verunsichert werden.

Gemäß Anspruch 5 ist die auf den Nebentransaktionserver ver weisende Referenz als Grafikreferenz definiert, so daß auf grund der Referenzinformation eine Grafik in dem betreffenden Dokument dargestellt wird. Dabei kann die Referenzinformation die Grafikdaten selbst enthalten oder ihrerseits auf eine Da tei verweisen, in der die betreffende Grafik abgelegt ist.

Grundsätzlich ist die nebentransaktionsbezogene Referenzin formation von den ablaufenden Haupttransaktionen unabhängig. Abweichend hiervon wird die Referenzinformation gemäß An spruch 6 zusätzlich von den Haupttransaktionen des Benutzers beeinflußt. Der Benutzer kann dann aktiv auf den Verlauf der Nebentransaktionen Einfluß nehmen, indem er bestimmte Haupt transaktionen vornimmt. Im einfachen Fall kann die Referen zinformation beispielsweise auch nur dazu dienen, über den aktuellen Stand der laufenden bzw. der bereits gelaufenen Haupttransaktionen zu informieren.

Zusätzlich kann gemäß Anspruch 7 vorgesehen sein, daß die Re ferenzinformation eines Benutzers zusätzlich von den Haupt- und/oder Nebentransaktionen anderer Benutzer beeinflußt wird. Dabei können die Haupt- bzw. Nebentransaktionen des Benutzers umgekehrt wiederum die Referenzinformationen anderer Benutzer beeinflussen. Auf diese Weise sind im Rahmen der Nebentrans aktionen je nach Bedarf unterschiedliche Interaktionen zwi schen den Benutzern realisierbar.

Anspruch 8 sieht vor, daß der Benutzerhost bei der auf der Referenz basierenden Anfrage zusätzlich Referenzdaten an den Nebentransaktionsserver sendet. Vorzugsweise handelt es sich dabei um eine Haupttransaktionsserverkennung und/oder eine Dokumentkennung. So kann der Nebentransaktionsserver erken nen, von welchem Haupttransaktionsserver bzw. von welchem Do kument die betreffende Referenz stammt. Dabei kann gemäß An spruch 9 zumindest ein Teil der Referenzdaten dazu dienen, die Referenzinformation zusätzlich zu beeinflussen.

Gemäß Anspruch 10 ist die in das Dokument eingefügte Referen zinformation als Verweis, beispielsweise als Hyperlink, auf den Nebentransaktionsserver definiert und durch den Benutzer aufrufbar. Ruft dieser den Verweis auf, sendet der Benutzer host eine dem Verweis entsprechende Anfrage, gegebenenfalls zusammen mit einer Benutzerkennung, an den Nebentransaktions server, der daraufhin eine nebentransaktionsbezogene Ver weisinformation an den Benutzerhost zurücksendet. Diese wird darauffolgend vom Benutzerhost abgearbeitet.

Der Benutzer kann so durch Aufrufen des Verweises die nächste Nebentransaktion auslösen und so den weiteren Verlauf der Ne bentransaktionen direkt beeinflussen. Auf diese Weise wird eine direkte nebentransaktionsbezogene Interaktion zwischen Benutzer und Nebentransaktionsserver möglich, die aufgrund der Benutzerkennung auch benutzerspezifisch ausgestaltet sein kann. Der Aufruf eines Verweises kann beispielsweise bewir ken, daß ein neues Dokument vom Benutzerhost angefordert wird oder eine Formulareingabe ermöglichen, über die weitere Daten vom Benutzer an den Nebentransaktionsserver gesendet werden können.

Gemäß Anspruch 11 bewirkt die Verweisinformation, daß die Verfahrensschritte gemäß Anspruch 1 wiederholt werden, d. h., daß der Benutzerhost das zuletzt dargestellte Dokument noch mals von dem betreffenden Haupttransaktionsserver anfordert und dieses erneut darstellt. Dabei kann die Referenzinforma tion zusätzlich von den vorangegangenen Verweisaufrufen abhängen, so daß sich bei der erneuten Darstellung des Doku ments die eingefügte Referenzinformation von der vorhergehen den unterscheiden kann. Die Referenzinformation kann aber beispielsweise auch durch Haupt- oder Nebentransaktionen an derer Benutzer, die seit der letzten Anforderung und Darstel lung des Dokuments durchgeführt wurden, verändert worden sein. Sofern der übrige Teil des Dokuments gleich geblieben ist, verändert sich aus Sicht des Benutzers in diesen Fällen nur die eingefügte Referenzinformation. Der Benutzer bleibt so scheinbar auf dem Dokument, während die durch den Verweis aufruf ausgelöste Nebentransaktion abläuft und das Ergebnis dargestellt wird.

Gemäß Anspruch 12 beinhaltet das Dokument mehrere auf den Ne bentransaktionsserver verweisende Referenzen, so daß im Er gebnis entsprechend viele Referenzinformationen vom Neben transaktionsserver zurückgesendet und durch den Benutzerhost auf dem Dokument dargestellt werden. Gemäß Anspruch 13 kann zumindest ein Teil dieser Referenzinformationen wiederum als Verweise auf den Nebentransaktionsserver definiert und ein zeln durch den Benutzer aufrufbar sein. Analog zu den im Zu sammenhang mit Anspruch 11 gemachten Erläuterungen kann der Aufruf einer dieser Verweise zu einer Wiederholung der Ver fahrensschritte gemäß Anspruch 1 führen, wobei durch den Ver weisaufruf neben der zugehörigen Referenzinformation auch zu mindest ein Teil der übrigen Referenzinformationen beeinfluß bar ist. Auf diese Weise miteinander verknüpft, können die einzelnen Referenzinformationen zusammen eine logische Ein heit bilden, die auch komplexe Interaktionen zwischen Benut zer und Nebentransaktionsserver ermöglichen. Durch die Art der einzelnen Referenzinformationen, etwa deren grafische Ausgestaltungen, kann dem Benutzer beispielsweise auch ange zeigt werden, welche Optionen ihm gerade für die Interaktion mit dem Nebentransaktionsserver zur Verfügung stehen, sprich welche Nebentransaktionen er gerade ausführen lassen kann.

Das erfindungsgemäße Verfahren erlaubt somit die Durchführung von bestimmten Nebentransaktionen im Rahmen von Haupttransak tionen und dies praktisch über eine beliebige Anzahl von Haupttransaktionen und auch über verschiedene Haupttransakti onsserver hinweg. Einzige Voraussetzung hierfür ist, daß die von den betreffenden Haupttransaktionsservern übermittelten Dokumente entsprechende Referenzen enthalten. Der Benutzer bekommt dann bei jedem (erneuten) Dokumentaufruf die aktuel le(-n) Referenzinformation(-en) in dem betreffenden Dokument angezeigt. Auf diese Weise entsteht für den Benutzer, insbe sondere, wenn die Referenzinformationen auch von den Haupt transaktionen des Benutzers beeinflußt werden, der Eindruck eines logischen Zusammenhangs zwischen den einzelnen Dokumen ten, obwohl die zugehörigen Haupttransaktionen faktisch von einander unabhängig sein können. Aus Sicht des Benutzers kommt es so zwischen den betroffenen Haupttransaktionsservern zu einem Datenaustausch, der in Wahrheit gar nicht stattfin det, sondern der zentral (und ohne daß dies vom Benutzer wahrnehmbar sein muß) über den Nebentransaktionsserver reali siert wird.

Gemäß Anspruch 18 wird das erfindungsgemäße Verfahren dazu verwendet, ein Spiel über ein Netzwerk zu betreiben. Das Spiel findet dabei im Rahmen der Nebentransaktionen statt, wobei die Referenzinformation(-en) ein Spielelement(-e) dar stellen, welche(-s) die aktuelle Spielsituation repräsen tiert/-en. Wie die nachfolgenden Ausführungen noch genauer zeigen werden, ist das erfindungsgemäße Verfahren für das Be treiben eines solchen Spiels besonders geeignet.

Da auch die allgemeine Idee, mittels eines geeigneten Verfah rens ein Spiel im Rahmen von Haupttransaktionen zu betreiben, bei welchem die Spielelemente als Teil eines Dokuments darge stellt werden, nicht bekannt ist, beansprucht die Anmelderin hierfür zusätzlich eigenständigen Schutz. Im einzelnen umfaßt ein solches Verfahren bzw. Spiel gemäß Anspruch 19 folgende Schritte: Der Benutzerhost fordert ein Dokument vom Haupt transaktionsserver an; dieser sendet das angeforderte Doku ment an den Benutzerhost; der Benutzerhost stellt das Doku ment dar, wobei dieses ein oder mehrere Spielelemente enthält und der Benutzer den Fortgang des Spieles bestimmen kann, in dem er das/eines (dieser) Spielement(-e) aktiviert. Dazu können die Spielelemente beispielsweise als Hyperlinks in eine Web-Seite eingefügt werden, die der Benutzer dann durch An klicken mit dem Mauszeiger aufrufen kann.

Gemäß Anspruch 20 kann der Benutzer den Fortgang des Spieles zusätzlich dadurch bestimmen, daß er ein weiteres Dokument des ersten oder, sofern ein solcher vorhanden ist, eines wei teren Haupttransaktionsservers anfordert.

Gemäß Anspruch 21 werden die Spielelemente nur dargestellt, wenn der Benutzer sich zuvor als Spieler registriert hat und als solcher identifiziert wurde. Die Identifizierung kann da bei auf einer etwaig vorgesehenen Benutzerkennung beruhen und im Bedarfsfall eine Anmeldung beim Nebentransaktionsserver erfordern.

Gemäß Anspruch 22 hängt die aktuelle Spielsituation von frü heren Spielaktionen des Benutzers, etwa von vorhergegangenen Spielelemente-Aufrufen oder Dokument-Anforderungen, ab. Das Spiel kann auf diese Weise über mehrere Spielaktionen hinweg vom Benutzer logisch fortgesetzt werden.

Gemäß Anspruch 23 bietet das Spiel einen Anreiz, daß den Be nutzer veranlaßt, möglichst viele verschiedene Dokumente des ersten bzw. von etwaig vorhandenen weiteren Haupttransakti onsservern aufzurufen. Ein solcher Anreiz kann allein im Spieltrieb des Benutzers liegen, aber auch eine finanzielle Vergütung beinhalten.

Gemäß Anspruch 24 bietet das Spiel wiederum einen derartigen Anreiz, diesmal um den Benutzer zu veranlassen, die auf dem betreffenden Dokument dargestellten Werbebanner aufzurufen. Im einfachsten Fall kann das Spiel auch nur aus dem Aufrufen von Werbebannern bestehen, welche dann die einzig vorhandenen Spielelemente darstellen.

Wie anhand der Anspruchsformulierungen ersichtlich, läßt sich das erfindungsgemäße Verfahren gemäß Anspruch 19 und der dar auf rückbezogenen Ansprüche ohne einen Nebentransaktionsserver realisieren (dieser kann natürlich im Bedarfsfall zusätz lich vorgesehen werden). Um das Spiel dann über mehrere Doku mente verschiedener Haupttransaktionsserver hinweg logisch fortsetzen zu können, ist hierbei ein direkter Datenaustausch zwischen den betreffenden Haupttransaktionsservern vorgese hen. Durch den Datenaustausch ist es dann möglich, dem Benut zer beim Aufruf eines neuen Dokuments (in Verbindung mit ei nem Haupttransaktionsserver-Wechsel) die aktuelle Spielsitua tion, gegebenfalls in Abhängigkeit von seinen früheren Spielaktionen, anzuzeigen.

Zurückkommend auf das erfindungsgemäße Verfahren gemäß Pa tentanspruch 1 und den darauf rückbezogenen Ansprüchen ist zu sagen, daß sich ein solches Verfahren in technischer Hinsicht am einfachsten anhand des Zusammenwirkens der zumindest vor handenen Netzwerkbestandteile, nämlich Benutzerhost, Haupt transaktionsserver und Nebentransaktionsserver, beschreiben läßt, entsprechend den vorstehenden Erläuterungen. In pa tentrechtlicher Hinsicht können sich hierbei jedoch Probleme bei der Durchsetzung des Patentschutzes ergeben, da aufgrund des Delokalisierungscharakters von Netzwerken, insbesondere dem Internet, einzelne Bestandteile des Netzwerks möglicher weise ins patentfreie Ausland ausgelagert werden können und zudem der Benutzerhost fallweise im privaten Bereich angesie delt sein kann.

Aus diesem Grund enthält der beigefügte Anspruchsatz neben den bereits erläuterten Patentansprüchen, die sich auf das Gesamtverfahren richten, zwei Gruppen von nebengeordneten Verfahrensansprüchen, die sich auf die Einzelverfahren rich ten, welche auf dem Benutzerhost (Ansprüche 14 und 15) bzw. dem Nebentransaktionsserver (Ansprüche 16 und 17) ablaufen. Diese sind gefolgt von einer Gruppe nebengeordneter Vorrich tungsansprüche, die sich auf entsprechende Computerprogramm produkte zum Ablauf auf einem Benutzerhost (Anspruch 25) bzw. einem Nebentransaktionsserver (Anspruch 26), auf ein entspre chendes System (Ansprüche 27 bis 37) sowie einen entsprechen den Nebentransaktionsserver (Ansprüche 38 und 39) richten. Zur Vermeidung von Wiederholungen wird hinsichtlich dieser Anspruchsgegenstände im wesentlichen auf die obigen Ausfüh rungen zu den Ansprüchen 1 bis 13, 18, 23 bzw. 24 verwiesen.

Zu den auf die Computerprogrammprodukte gerichteten Patentan sprüche sei zusätzlich erwähnt, daß unter dem Begriff "Computerprogrammprodukt" ein Computerprogramm oder Computer programm-Modul zu verstehen ist, welches durch Speicherung (z. B. auf einem magnetischen Speichermedium oder in einem flüchtigen oder nicht-flüchtigen Halbleiterspeicher eines Computers) oder durch Signale, die über ein Netzwerk, insbe sondere das Internet, versendet werden, verkörpert ist. Dabei braucht das Computerprogramm nicht in einer unmittelbar aus führbaren Form vorzuliegen, vielmehr kann es auch in einer für die Installation auf den Benutzerhost vorbereiteten Form vorliegen, wobei es selbstverständlich gepackt, verschlüs selt, für eine etwaige Versendung über ein Netzwerk in Pakete zerteilt und mit übertragungsbezogenen Headern versehen sein kann, etc.

Die Erfindung wird nun anhand von Ausführungsbeispielen und der angefügten Zeichnung näher erläutert. In der Zeichnung zeigen:

Fig. 1 ein Netzwerk für den Ablauf eines erfindungsgemä ßen Verfahrens, welches zum Betreiben eines Spiels über das Internet verwendet wird;

Fig. 2 eine schematische Darstellung einer unter Verwen dung eines erfindungsgemäßen Verfahrens erzeugten Web-Seite;

Fig. 3 ein Flußdiagramm eines erfindungsgemäßen Verfah rens, welches über das in Fig. 1 gezeigte Netzwerk abläuft;

Fig. 4a ein Flußdiagramm eines erfindungsgemäßen Verfah rens für den Ablauf auf einem Nebentransaktions server zum Senden von Grafikinformationen gemäß Fig. 3;

Fig. 4b ein Flußdiagramm eines erfindungsgemäßen Verfah rens für den Ablauf auf einem Nebentransaktions server zum Senden von Verweisinformationen gemäß Fig. 3;

Fig. 5 eine schematische Darstellung von Dateien auf ei nem Nebentransaktionsserver.

Fig. 1 zeigt zwei Benutzerhosts 1 und 2, zwei Haupttransakti onsserver 1 und 2 sowie einen Nebentransaktionsserver, die mit dem Internet verbunden sind, um über dieses ein erfin dungsgemäßes Verfahren durchzuführen, welches zum Betreiben eines Spieles verwendet wird. Die Anzahl der gezeigten Benut zerhosts und Haupttransaktionsserver ist zu Anschauungszwec ken auf jeweils zwei beschränkt, ein solches Netzwerk kann jedoch in Wirklichkeit praktisch eine beliebige Anzahl Benut zerhosts bzw. Haupttransaktionsserver aufweisen. Der Neben transaktionsserver umfaßt im vorliegenden Beispiel einen Spieltransaktionsserver, eine Datenbank und einen Grafikser ver. Die Datenbank und der Grafikserver sind dabei nicht zwingend erforderlich, aber für die Leistungsfähigkeit (Performance) des Nebentransaktionsservers vorteilhaft. Im Bedarfsfall können auch mehrere Datenbanken bzw. Grafikserver vorhanden sein, wobei insbesondere die einzelnen Grafikserver geographisch weit voneinander delokalisiert sein können. Die se Delokalisierung kann beispielsweise dazu dienen, die Gra fikserver und Benutzerhosts näher zusammen zu bringen und so die Übertragungszeiten zwischen diesen zu verkürzen.

Im folgenden sollen zunächst die Merkmale des Spiels sowie des darauf basierenden Geschäftsmodells in groben Zügen er klärt werden, bevor darauffolgend auf die technischen Details des zugrunde liegenden Verfahrens eingegangen wird.

Im vorliegenden Beispiel stellt das Spiel eine Art Schatzsu che dar, dessen Ziel das Einsammeln von Münzen und anderen virtuellen Gegenständen ist, die auf bestimmten Web-Seiten der Haupttransaktionsserver angezeigt werden. Ein Benutzer muß dazu eine dieser Web-Seiten aufrufen und kann dann die angezeigten Münzen bzw. Gegenstände durch Anklicken mit der Maustaste einsammeln. Die auf diese Weise gesammelten Schätze kann der Benutzer zum Erwerb weiterer virtueller Gegenstände nutzen oder sich vom Spielbetreiber in realen Geld- oder Sachwerten vergüten lassen. Das aktuelle Guthaben an Schätzen wird dem Benutzer dabei auf der gerade dargestellten Web- Seite angezeigt. Beim Beenden des Spiels muß der Benutzer seine Schätze auf einer geeigneten Web-Seite eines Haupt transaktionsservers verstecken und kann diese bei späterer Wiederaufnahme des Spiels dort wieder einsammeln. Der Benut zer hat so jederzeit die Möglichkeit, das Spiel zu unterbre chen und dieses zu einem späteren Zeitpunkt mit dem alten Spielstand weiterzuspielen.

Das Spiel sieht vor, daß die von einem Benutzer bei Unterbre chung des Spiels versteckten Schätze von anderen spielenden Benutzern gefunden und eingesammelt werden können, wenn diese die betreffende Web-Seite aufrufen. Auf diese Weise entsteht eine Interaktion zwischen den verschiedenen Spielern. Dabei kann zusätzlich vorgesehen sein, daß der Benutzer, dessen Schätze gerade von einem anderen Spieler eingesammelt werden, hiervon mittels anderer Kommunikationsmittel wie E-Mail, SMS oder ICQ informiert wird, so daß der betreffende Benutzer auch am Spielgeschehen teilnimmt, wenn er nicht gerade aktiv spielt.

Das Spiel kann viele weitere Merkmale vorsehen, welche den Rahmen der möglichen Spielhandlungen erweitern und so die At traktivität des Spiels für die Benutzer steigern. Beispiels weise können virtuelle Kriegerfiguren vorgesehen sein, die ein Benutzer durch den Verkauf von eingesammelten Münzen er werben kann und mittels denen er seine versteckten Schätze während seiner Abwesenheit vom Spiel bewachen lassen kann. Im Rahmen dieser Patentanmeldung sind solche Spielmerkmale je doch nur beschrieben, sofern sie dem technischen Verständnis der Erfindung dienen.

Eine Besonderheit des Spiels ist, daß es sich in herkömmliche Web-Seiten implementieren läßt, indem diese so umgestaltet werden, daß sie die Anzeige der zugehörigen Spielelemente zu lassen. Es müssen vom Haupttransaktionsserver also keine ei genen Web-Seiten für das Spiel bereitgestellt werden. Viel mehr werden die Spielelemente in bestehende Web-Seiten inte griert, so daß ein Benutzer neben dem Spiel jederzeit auch die Möglichkeit hat, das aktuelle Informations- und Service angebot der jeweiligen Web-Seite zu nutzen.

Fig. 2 zeigt beispielhaft eine grob schematisierte Ansicht einer Web-Seite 1 mit integrierten Spielelementen 2 bis 6, wie diese von einem Web-Browser auf einem Benutzerhost darge stellt werden würde. Die gezeigten Spielelemente 2 bis 6 um fassen eine Spielstandanzeige 2, eine Anzeige der einsammel baren Münzen bzw. Gegenstände 3, sowie drei Buttons 4 bis 6 zum Auslösen verschiedener Spielaktionen. Die Spielelemente 2 bis 6 sind dabei auf einer Navigationsleiste 7 im linken äu ßeren Bereich der Web-Seite 1 angeordnet. Die Navigationslei ste 7 ist dabei nicht zwingend erforderlich, alternativ kön nen die Spielelemente auch über verschiedene Orte auf der Web-Seite 1 verteilt sein. Dem Benutzer werden dabei nur die jenigen Spielelemente angezeigt, die für die aktuelle Spiel situation gerade relevant sind. So wird im vorliegenden Bei spiel der Button 5, wie durch die Strichlinien angedeutet, nicht angezeigt, da die zugehörige Spielfunktion bei der ak tuellen Spielsituation nicht vorgesehen ist.

Neben den Spielelementen 2 bis 6 weist die Web-Seite 1 Grafi kelemente 8, Textfelder 9 und Werbebanner 10 auf, die den herkömmlichen Inhalt der Web-Seiten bilden, wie er schon vor Integration der Spielelemente bestanden hat.

Der Spielablauf sieht vor, daß ein Benutzer nur an dem Spiel teilnehmen kann, wenn er sich zuvor als Spieler registriert hat. Dabei kann das Spiel so ausgestaltet sein, daß nur regi strierte Benutzer die Spielelemente auf der Web-Seite 1 zu sehen bekommen. Nicht-registrierte Benutzer bekommen dann nur den herkömmlichen Inhalt der Web-Seite 1 zu sehen, so daß sie nicht durch die Spielelemente abgelenkt oder irritiert wer den. Im Bedarfsfall kann bei nicht-registrierten Benutzern zusätzlich vorgesehen sein, statt der Spielelemente eine Standardinformation, etwa einen Hinweis auf die Möglichkeit am Spiel teilzunehmen, anzuzeigen.

Die Vorteile, die sich für die Betreiber der betreffenden Haupttransaktionsserver ergeben, liegen somit zunächst darin, daß eine vermehrte Anzahl Benutzer durch das Spiel veranlaßt wird, die Web-Seiten dieser Betreiber aufzurufen und so auf deren Inhalte aufmerksam gemacht wird. Es entsteht so eine Art Werbeeffekt für diese Web-Seiten, der geeignet ist, E- Commerce oder andere kommerzielle Dienstleistungen, die dort angeboten werden, zu fördern.

Weiter können durch die vermehrten Seitenaufrufe auch höhere Werbeeinnahmen erzielt werden. Denn diese bemessen sich im allgemeinen daran, wie oft ein Dokument, das eine bestimmte Werbung zeigt, von den im Internet surfenden Benutzern aufge rufen wird (Impressions). Viele der kommerziellen Betreiber von Web-Seiten finanzieren sich ausschließlich über Werbeein nahmen, indem sie Werbetext und -grafiken in ihren Dokumenten einbetten. Sie versuchen daher, durch ein attraktives Infor mations- und Dienstleistungsangebot möglichst viele Benutzer dazu zu bewegen, ihre Web-Seiten aufzurufen. Das Spiel hilft die Attraktivität dieser Web-Seiten für weite Benutzerkreise im Internet zu erhöhen und damit die Werbeeinahmen zu stei gern.

Darüber hinaus kann zusätzlich vorgesehen sein, daß den Be nutzern im Rahmen des Spiels das Aufrufen von Werbeanzeigen oder Werbebannern vergütet wird, etwa in Form eines Zugewinns an Münzen. Die vermehrten Werbeaufrufe (Ad-clicks), die dar aus resultieren, bedeuten eine weitere Steigerung der Werbe einahmen für den Web-Seiten-Betreiber, da die Werbeaufrufe in aller Regel von den Werbetreibenden zusätzlich vergütet wer den.

Auf Grund der Vorteile und der zusätzlichen Einnahmen, die sich durch die Einbettung des Spieles für die Betreiber der Web-Seiten ergeben, ist zu erwarten, daß diese bereit sind, die Betreiber des Spieles für die Bereitstellung des Spieles zu bezahlen. Die Bezahlung kann hierbei erfolgsabhängig er folgen, z. B. durch Messung der durch das Spiel verursachten Seiten- bzw. Werbeaufrufe, so daß der Web-Seiten-Betreiber keinerlei finanzielles Risiko eingehen muß. Dabei wird die Bezahlung so bemessen, daß sie nur einen Bruchteil der durch das Spiel entstandenen Werbemehreinnahmen darstellt.

Gemäß einer Variante des soeben erläuterten Geschäftsmodelles kann auch vorgesehen sein, daß der Spiele-Betreiber eigene Werbeanzeigen oder -banner auf den betreffenden Web-Seiten plaziert. In diesem Fall erhält der Web-Seiten-Betreiber für die Seiten- bzw. Werbeaufrufe vom Spiele-Betreiber eine ent sprechende Vergütung, ohne selbst an den Spiele-Betreiber et was bezahlen zu müssen. Ein finanzielles Risiko für den Web- Seiten-Betreiber besteht somit wiederum nicht.

Im folgenden wird anhand der Fig. 3 unter Zuhilfenahme der Fig. 4a und 4b ein möglicher Verfahrensablauf, wie er durch einen spielenden Benutzer durchgeführt werden könnte, veran schaulicht, um ein tieferes technisches Verständnis der vor liegenden Erfindung zu ermöglichen. Beispielhaft wird der Verfahrensablauf hierbei anhand Benutzerhost 1, Haupttransak tionsserver 1 und Nebentransaktionsserver demonstriert. In analoger Weise könnte das Verfahren auch mit Benutzerhost 2 bzw. Haupttransaktionsserver 2 durchgeführt werden.

Vor Spielbeginn erfolgt im vorliegenden Beispiel zunächst ei ne Anmeldung des Benutzers beim Nebentransaktionsserver. Die Anmeldung kann dabei, wie in Fig. 3 gezeigt, direkt auf dem Nebentransaktionsserver (d. h. auf einer dafür eingerichteten Web-Seite von diesem) erfolgen, oder im Bedarfsfall auch in direkt über den Haupttransaktionsserver. Im letzteren Fall werden die Anmeldedaten des Benutzers dann von dem betreffen den Haupttransaktionsserver an den Nebentransaktionsserver weitergeleitet. Die Anmeldung ermöglicht eine Identifizierung des Benutzers, so daß diesem ein etwaig vorhandener Spiel stand aus einer früheren Spieletappe zugeordnet werden kann.

Nach Anmeldung des Benutzers sendet der Nebentransaktionsser ver eine Benutzerkennung, im vorliegenden Fall eine Session- ID, an den Benutzerhost 1. Diese Session-ID wird auf dem Be nutzerhost 1 in Form eines Cookies gespeichert und im folgen den Verfahrensablauf bei sämtlichen Anfragen des Benutzer hosts 1 an den Nebentransaktionsserver mitgesendet, so daß der Nebentransaktionsserver die Anfragen dem betreffenden Be nutzer zuordnen kann.

Ein solches Session-Konzept, bei dem eine Session-ID zur Identifizierung des Benutzerhosts bzw. Benutzers mitgesendet wird, ist aus dem Stand der Technik bekannt. Informationen hierzu finden sich beispielsweise im Zusammenhang mit der Programmierung von ASP unter:
http:/ / www.abigline.com/webmaster/articles/asp/042098.htm.

Durch die Zuordnung der einzelnen Benutzerhost-Anfragen auf Seiten des Nebentransaktionsservers lassen sich die einzelnen Anforderungs-Antwort-Vorgänge bzw. die Nebentransaktionen, die sich aus diesen zusammensetzen, logisch miteinander ver knüpfen. So können etwa Daten aus früheren Nebentransaktionen gespeichert und bei späteren Nebentransaktionen wiederverwen det werden. Die Verbindung zwischen Benutzerhost und Neben transaktionsserver, die normalerweise nur einen Anforderungs- Antwort-Vorgang überdauert, scheint somit während der gesam ten "Session", die im vorliegenden Ausführungsbeispiel mit der Anmeldung des Benutzers beginnt, geöffnet zu bleiben.

Durch das Session-Konzept ist es möglich, daß der Benutzer zwischen zwei Anfragen an den Nebentransaktionsserver prak tisch beliebig andere Haupttransaktionen auf dritten Servern durchführen kann und dennoch bei der nächsten Anfrage an den Nebentransaktionsserver von diesem wieder als registrierter Benutzer erkannt wird. Zur Entlastung des Nebentransaktions servers (der die Sessionen verwalten muß) kann allerdings vorgesehen werden, daß nach einer vordefinierten Zeitspanne, während der von einem Benutzerhost keine Anfrage mehr an den Nebentransaktionsserver gesendet wurde, die laufende Session abgebrochen wird, so daß zur Spielfortsetzung eine erneute Anmeldung des betreffenden Benutzers erforderlich ist. Nach Abbruch der Session wird der durch die Session beanspruchte Speicherplatz wieder frei.

Im Rahmen der Sessionen kann im Bedarfsfall zusätzlich vorge sehen werden, die an die Benutzer ausgelieferten Spielelemen te (oder auch andere ausgelieferte Informationen) zu proto kollieren und so einem Mißbrauch, etwa einem Erschleichen von Münzen durch gefälschte Anfragen, vorzubeugen. Dies kann zum Beispiel dadurch erfolgen, daß den ausgelieferten Spielele menten Chiffrierwerte zugeordnet werden anhand von denen überprüfbar ist, ob eine später darauf folgende Anfrage des Benutzers auf dem Aufruf eines dieser Spielelemente beruht (vgl. hierzu die nachfolgenden Erläuterungen über den Aufruf von Spielelementen) oder ob diese gefälscht ist.

Alternativ zu der vorgestellten Session-ID können auch andere Daten, die bei den Anfragen der Benutzerhosts standardmäßig an den Nebentransaktionsserver übermittelt werden, zur Iden tifizierung eines registrierten Benutzers und damit zur Rea lisierung einer Session herangezogen werden. Bei diesen Daten kann es sich beispielsweise um die IP-Adresse, um bestimmte Einstellungen des auf dem Benutzerhost verwendeten Web- Browsers oder Betriebssystems etc. handeln. Zur Verminderung der Fehlerwahrscheinlichkeit ist eine geeignete Kombination solcher Daten vorteilhaft. Diese werden bei der Anmeldung vom Nebentransaktionsserver erhoben und abgespeichert und können dann bei späteren Anfragen zum Vergleich herangezogen werden. Aufgrund der standardmäßigen Übermittlung der Daten ist bei dieser alternativen Lösung das Übermitteln einer spezifischen Benutzerkennung oder Session-ID (wie in Fig. 3 gezeigt) nicht zwingend erforderlich, kann aber im Bedarfsfall zusätzlich vorgesehen sein.

Zurückkehrend zu Fig. 3 sieht der weitere Verfahrensablauf vor, daß der Benutzer eine für das Spiel eingerichtete Web- Seite eines Haupttransaktionsservers aufruft. Im vorliegenden Beispiel ruft der Benutzer eine entsprechende Web-Seite des Haupttransaktionsservers 1 auf. Der Benutzerhost 1 bzw. der dazugehörige Web-Browser fordert das betreffende Dokument vom Haupttransaktionsserver 1 an, der diese daraufhin übermit telt. Der Web-Browser beginnt dann, im Regelfall schon wäh rend der Übermittlung des Dokuments, mit dem Abarbeiten von dieser bzw. mit dem Darstellen der Web-Seite. Insoweit wird die in dem Flußdiagramm gezeigte Chronologie nicht streng eingehalten.

Wie bereits im Zusammenhang mit Fig. 2 erwähnt, sind die Spielelemente dazu gedacht, in eine herkömmliche Web-Seite integriert zu werden. Um eine Web-Seite hierfür einzurichten, werden bestimmte HTML-Elemente und im Bedarfsfall zusätzlich bestimmte Java-Scripts (Java ist eine Marke der Sun Microsy stems, Inc.) in das betreffende Dokument integriert. Weitere Schritte, etwa die Installation zusätzlicher Software, ist auf Seiten der Haupttransaktionsserver vorteilhaft nicht zwingend erforderlich, kann aber im Bedarfsfall zusätzlich vorgesehen werden.

Zunächst zur Funktion der HTML-Elemente: Diese sind im vor liegenden Beispiel unter Bezugnahme auf Fig. 2 als Grafikre ferenzen definiert, die auf spezielle Dateien des Nebentrans aktionsservers verweisen. Jedes der Spielelemente 2 bis 6 wird dabei durch eine bestimmte Grafikreferenz repräsentiert. Beim Abarbeiten des Dokuments durch den Web-Browser eines Be nutzerhosts werden aufgrund der Grafikreferenzen die zugehö rigen Dateien auf dem Nebentransaktionsserver aufgerufen, dort bestimmte Befehle oder Anweisungen ausgeführt und das zugehörige Ergebnis in Form einer Grafikinformation vom Ne bentransaktionsserver an den betreffenden Benutzerhost über mittelt. Auf diese Weise wird durch die in den Dateien vor handenen Befehle bzw. Anweisungen für jede Grafikreferenz ei ne der aktuellen Spielsituation des betreffenden Benutzers entsprechende Grafikinformation ermittelt und an den Benutzerhost übermittelt. Die einzelnen, damit zusammenhängenden Schritte werden nachfolgend noch unter Bezugnahme auf Fig. 4a näher erläutert.

Im vorliegenden Beispiel sind die Grafikreferenzen der Spie lelemente 3 bis 6 zusätzlich als Verweise auf dem Nebentrans aktionsserver definiert. Die Spielelemente 3 bis 6 werden da her auf der Web-Seite 1 als Hyperlinks dargestellt und können somit vom Benutzer aufgerufen werden (mit Ausnahme des nicht angezeigten Spielelements 5). Einzelheiten zu den Verfahrens schritten, die durch Aufrufen eines solchen Hyperlinks ausge löst werden, werden nachfolgend noch unter Bezugnahme auf Fig. 4b näher erläutert.

Schließlich zur Funktion der Java-Scripts: Diese dienen der Ausführung verschiedener Funktionen, die lokal auf dem be treffenden Benutzerhost beim Abarbeiten des Dokuments ablau fen. Solche Funktionen sind beispielsweise die Ermittlung der URL (Uniform Resource Locator) der aktuell aufgerufenen Web- Seite oder die Generierung von Zufallszahlen, deren Bedeutung nachstehend noch genauer erläutert wird. Ein weitere mögliche Funktion ist das Öffnen von Pop-up-Windows, um zusätzliche Spielinformationen anzuzeigen oder weitere Spielhandlungen zu ermöglichen.

Zurückkommend auf den Verfahrensablauf in Fig. 3, ist dort zu sehen, daß der Benutzerhost 1 nach dem Erhalten des Dokuments nacheinander mehrere Anfragen nach Grafikinformationen x₂ bis x₆, jeweils zusammen mit der Session-ID, an den Nebentransak tionsserver sendet. Die Anfragen basieren auf den Grafikrefe renzen der Spielelemente 2 bis 6 und dienen dazu, die zugehö rigen Dateien auf dem Nebentransaktionsserver aufzurufen. Die Grafikreferenzen können dabei zum Beispiel wie folgt defi niert sein:
<img src= "http:/ / www.nebentransaktionsserver.com/spielstand.asp? webseitenbetreiber=haupttransaktionsserver1& URL = http:/ / www.haupttransaktionsserver1.com/home& TransID=2832323"<

Das Beispiel bezieht sich hierbei auf die Grafikreferenz des Spielelementes 2, welches den aktuellen Spielstand des Benut zers anzeigt. Aus Sicht des Web-Browser stellt diese in HTML geschriebene Definition eine normale Grafikreferenz (Image tag) dar, die scheinbar auf eine auf dem Nebentransaktions server abgelegte Grafikinformation verweist. Faktisch löst der Web-Browser aber mit seiner Anfrage die Abarbeitung der in der angegebenen ASP-Datei (www.nebentransaktions server.com/spielstand.asp) abgespeicherten Anweisungen aus, die dazu dienen den aktuellen Spielstand zu ermitteln und ei ne dementsprechende Grafikinformation auszuliefern. Auf den Inhalt dieser Anweisungen wird beispielhaft nochmals im Zu sammenhang mit Fig. 4a eingegangen.

Anhand der Beispieldefinition ist zu erkennen, daß die Gra fikreferenz neben dem Namen der aufzurufenden Datei noch wei tere Angaben für den Nebentransaktionsserver enthalten kann. In diesem Fall handelt es sich um eine Kennung des Web- Seiten-Betreibers und eine URL der gerade auf dem Benutzer host angezeigten Web-Seite, welche beide als Referenzdaten dienen. Die URL wird zuvor vom Web-Browser mittels eines da für vorgesehenen Java-Scripts ermittelt und in die Grafikre ferenz eingesetzt. Das Java-Script ist dabei Teil des zuvor übermittelten Dokuments (vgl. obige Erläuterungen zur Funkti on der Java-Scripts). Schließlich enthält die Grafikreferenz noch eine Transaktion-ID (TransID), welche für die Datenüber tragung im Netzwerk erforderlich ist.

Alternativ zu der Möglichkeit, die URL durch ein Java-Script zu ermitteln und als Teil der Grafikreferenz an den Neben transaktionsserver zu senden, kann die URL auch durch den Ne bentransaktionsserver selbst ermittelt werden. Dies geschieht etwa mittels eines Visual-Basic-Skripts (Visual Basic ist ei ne eingetragene Marke der Microsoft Corporation), welches die mit den Anfragen der Web-Browser standardmäßig übermittelten Informationen entsprechend auswertet. Hierdurch kann die Er mittlung der URL und das Einsetzen in die Grafikreferenz auf Seiten des Web-Browsers entfallen, womit auch das zugehörige Java-Script nicht mehr in die betreffenden Dokumente inte griert zu werden braucht. Zusätzlich bietet diese Lösung den Vorteil, daß einem etwaigen Mißbrauch durch fingierte URL- Adressen vorgebeugt werden kann.

Fig. 4a zeigt, daß der Nebentransaktionsserver auf die Anfra gen des Benutzerhosts 1 hin jeweils zunächst überprüft, ob diese mit einer Session-ID verknüpft sind. Ist dies nicht der Fall, sprich wenn es sich um einen nicht-registrierten Benut zer handelt, übermittelt der Nebentransaktionsserver als Gra fikinformation ein 1 × 1 Pixel. Dieses ist aufgrund seiner ge ringen Größe (bzw. einer etwaigen farblichen Abstimmung mit der Hintergrundfarbe der Naviogationsleiste 7) für das menschliche Auge auf der Web-Seite nicht wahrnehmbar, so daß für den Benutzer scheinbar an der betreffenden Stelle keiner lei Grafik angezeigt wird. Wie bereits erwähnt, kann einem nicht-registrierten Benutzer in diesem Fall alternativ auch eine Standard-Information, etwa ein Hinweis auf das Spiel oder eine Werbeeinblendung, angezeigt werden.

Sind die Grafikanfragen hingegen mit einer Session-ID ver knüpft, erkennt der Nebentransaktionsserver jeweils den Be nutzer als registrierten Benutzer und identifiziert die zuge hörige Session. Der Nebentransaktionsserver ermittelt dann anhand des Spielstandes des Benutzers und gegebenenfalls un ter Berücksichtigung weiterer Spieldaten die aktuelle Spiel situation des Benutzers und liefert daraufhin für jedes Spie lemement die jeweils passende Grafikinformation aus.

Im Falle des Spielelementes 3 (Anzeigefeld der auf der Web- Seiten einsammelbaren Münzen/Gegenstände) kann neben dem Spielstand beispielsweise zusätzlich berücksichtigt werden, ob ein anderer Spieler auf der betreffenden Seite seine Schätze versteckt hat. Zu diesem Zweck enthält die zugehörige Grafikreferenz, analog zu obiger Beispieldefinition, die URL der aktuell vom Benutzer aufgerufenen Web-Seite. Der Neben transaktionsserver hat hierzu außerdem in seiner Datenbank (siehe Fig. 1) abgespeichert, auf welchen Web-Seiten andere Spieler gerade ihre Schätze versteckt haben. Im Falle, daß ein Vergleich der aktuellen URL mit den gespeicherten Seiten daten ein positives Ergebnis liefert, wird vom Nebentransak tionsserver an den Benutzerhost 1 eine Grafikinformation übermittelt, welche die versteckten Schätze des betreffenden anderen Spielers symbolisiert.

Bei der Ermittlung der aktuellen Spielsituation können auch Zufallswerte vom Nebentransaktionsserver generiert und mit einbezogen werden. Dies etwa um darüber zu entscheiden, ob und gegebenenfalls wie viele Münzen zum Einsammeln auf der Web-Seite angezeigt werden sollen, wenn dort keine Schätze von anderen Spielern versteckt sind. Für das Spielelement 3 wird dann eine Grafikinformation übermittelt, welche eine entsprechende Anzahl Münzen symbolisiert.

Im vorliegenden Beispiel sind sämtliche, die verschiedenen Spielsituationen symbolisierenden Grafikinformationen auf dem Grafikserver des Nebentransaktionsservers abgespeichert. Zum Senden einer bestimmten Grafikinformation wird diese vom Spieltransaktionsserver ausgelesen und an den betreffenden Benutzerhost übermittelt. Alternativ hierzu kann dem betref fenden Benutzerhost anstelle der Grafikinformation auch eine entsprechende Referenz übermittelt werden, anhand der der Be nutzerhost die Grafikinformation direkt vom Grafikserver her unterladen kann. Diese Möglichkeit ist durch die gestrichel ten Linien in Fig. 1 angedeutet und wird nachfolgend nochmals im Zusammenhang mit Fig. 5 erläutert.

Daneben kann auch vorgesehen sein, daß die Grafikinformatio nen (anstatt vorgefertigt auf dem Nebentransaktionsserver bzw. Grafikserver abgespeichert zu sein) bei jeder Ausliefe rung jeweils direkt vom Nebentransaktionsserver neu generiert werden. Dies ist besonders dann vorteilhaft, wenn für das Spiel eine sehr hohe Anzahl an verschiedenen Grafiken zur Verfügung gestellt werden muß.

Nachdem sämtliche angefragten Grafikinformationen x₂ bis x₆ vom Nebentransaktionsserver an den Benutzerhost 1 übermittelt worden sind, kann letzterer das Abarbeiten des Dokuments be enden und die Web-Seite vollständig darstellen (vgl. Fig. 3). Wie bereits gesagt, werden dabei die Spielelemente 3, 4 und 6 im vorliegenden Beispiel als Hyperlinks dargestellt und kön nen durch den Benutzer per Mausklick angewählt werden.

Ruft der Benutzer in dieser Ausgangslage eine weitere Web- Seite des Haupttransaktionsservers 1 auf, wiederholt sich der vorstehend beschriebene Verfahrensablauf, wie durch die ge strichelten Linien in Fig. 3 angedeutet. In analoger Weise kann auch eine Web-Seite des Haupttransaktionsservers 2 auf gerufen und das Verfahren dort fortgesetzt werden. In jedem Fall, wird auf der betreffenden Web-Seite wiederum die aktu elle Spielsituation angezeigt, wobei diese möglicherweise ge genüber der vorhergehenden verändert ist (etwa weil dort im Gegensatz zu vorher kein Schatz eines anderen Spielers ver steckt ist).

Wählt der Benutzer in der besagten Ausgangslage hingegen ei nes der als Hyperlinks definierten Spielelemente 3, 4 oder 6 mit der Maustaste an, wird der betreffende Hyperlink akti viert und das Verfahren fortgesetzt, indem vom Benutzerhost 1 eine Anfrage nach der zugehörigen Verweisinformation y₃, y₄ bzw. y₆ an der Nebentransaktionsserver gesendet wird. Dabei wird wiederum eine Session-ID mitgesendet.

Anhand der zum Spielelement 3 (Anzeigefeld der auf der Web- Seiten einsammelbaren Münzen/Gegenstände) gehörenden Gra fikreferenz soll beispielhaft gezeigt werden, wie eine solche als Hyperlink definierte Grafikreferenz in HTML programmiert sein kann:
<a href= "http:/ / www.nebentransaktionsserver.com/einsammeln.asp? URL = http:/ / www.haupttransaktionsserverl.com/home& TransID=1632748"<
<img src= "http:/ / www.nebentransaktionsserver.com/muenzen.asp? webseitenbetreiber=haupttransaktionsserver1& URL = http:/ / www.haupttransaktionsserverl.com/home& TransID=1632748"< </a<

Man erkennt, daß der die Grafikinformation betreffende Teil (<img src= . . . TransID=1632748"<) analog zu der vorherigen Beispieldefinition des Spielelementes 2 aufgebaut ist. In diesem Fall wird durch das Spielelement jedoch nicht der Spielstand repräsentiert, sondern die auf der betreffenden Web-Seite einsammelbaren Schätze. Das Einsammeln geschieht dann gegebenenfalls durch Anklicken des Spielelementes 3 mit der Maustaste, wodurch der Hyperlink (<a href = . . . </a<) ak tiviert wird und eine entsprechende Anfrage vom Benutzerhost 1 an der Nebentransaktionsserver gesendet wird. Die Anfrage bewirkt die Abarbeitung der in der ASP-Datei "www.nebentrans aktionsserver.com/einsammeln.asp" abgespeicherten Anwei sungen.

Wie Fig. 4b zeigt, veranlassen diese Anweisungen den Neben transaktionsserver, die laufende Session des betreffenden Be nutzers anhand der Session-ID zu identifizieren und daraufhin den Spielstand dieser Session bzw. dieses Benutzers zu aktua lisieren. Die Aktualisierung erfolgt dabei entsprechend der Spielaktion, die dem Aufruf des Hyperlinks zugrunde liegt. Im vorliegend gewählten beispiel des Spielelementes 3 wäre dies das Einsammeln der Münzen/Gegenstände.

Der Nebentransaktionsserver übermittelt daraufhin eine Ver weisinformation in Form eines Re-direct-Befehls an den Benut zerhost 1, woraufhin dieser die aktuell dargestellte Web- Seite erneut vom Haupttransaktionsserver 1 anfordert und sich darauffolgenden Verfahrensschritte (wie in Fig. 3 durch den Pfeil links außen angedeutet) wiederholen. Hierbei wird der neue Spielstand für den Benutzer dadurch ersichtlich, daß die vom Nebentransaktionsserver übermittelten Grafikinformationen x₂ bis x₆ entsprechend dem aktualisierten Spielstand verän dert dargestellt werden. So wird das Einsammeln der Mün zen/Gegenstände, die durch das Spielelement 3 symbolisiert worden sind, dadurch ersichtlich, daß nunmehr das Spielelement 3 als 1 × 1 Pixel dargestellt wird, das Münzensymbol aus Sicht des Benutzers also verschwunden ist. Gleichzeitig wird das den Spielstand anzeigende Spielelement 2 um die entspre chende Münzenanzahl aktualisiert. Da sich im Regelfall bei der erneuten Darstellung der Web-Seite außer den betroffenen Spielelementen, in diesem Fall die Spielelemente 2 und 3, an dem Inhalt der Web-Seite nichts ändert, entsteht aus Sicht des Benutzers der Eindruck, daß die Web-Seite einfach beste hen bleibt, während sich die Spielelemente 2 und 3 verändern. Die Web-Seite scheint also aus Benutzersicht nur partiell verändert zu werden, während faktisch die Web-Seite komplett neu aufgebaut wird.

Um zu gewährleisten, daß bei einem wiederholten Anfordern und Darstellen einer Web-Seite tatsächlich die aktuellen Grafi kinformationen x₂ bis x₆ vom Nebentransaktionsserver ange fragt und übermittelt werden, werden die in den Grafikanfra gen enthaltenen Transaction-IDs bei jedem Durchlauf verän dert. Dies geschieht durch die bereits angesprochenen, im Do kument enthaltenen Java-Scripts (vgl. obige Erläuterungen zur Funktion der Java-Scripts), welche bei jedem Abarbeiten des Dokuments eine neue Zufallszahl generieren und diese als Transaction-ID in die betreffende Grafikreferenz einfügen. Auf diese Weise wird verhindert, daß der Web-Browser aufgrund übereinstimmender Transaction-IDs beim Abarbeiten der Grafi kanfrage auf seinen Cache-Speicher zurückgreift und mögli cherweise veraltete Grafikinformationen x₂ bis x₆ anzeigt. Gleichermaßen wird so verhindert, daß von einem Proxy-Server, wie er möglicherweise im Internet zwischen Benutzerhost 1 und Nebentransaktionsserver geschaltet ist, veraltete Grafikin formationen x₂ bis x₆ geliefert werden.

Die Funktionsweise des Nebentransaktionsservers soll nachste hend nochmals näher anhand von Fig. 5 erläutert werden. Fig. 5 zeigt beispielhaft und grob schematisiert die verschiedenen Dateien, die auf dem Nebentransaktionsserver abgelegt sind. Wie bereits gesagt wurde, ist die gewählte Aufteilung des Ne bentransaktionsservers in Spieltransaktionsserver, Datenbank und Grafikserver nicht zwingend erforderlich. Auch die gewählte Zuordnung der gezeigten Dateien zu diesen Nebentrans aktionsserver-Teilen ist nicht zwingend erforderlich, sondern kann im Bedarfsfall umgestellt werden oder ganz entfallen (zum Beispiel, wenn ein oder mehrere dieser Nebentransakti onsserver-Teile nicht vorhanden sind).

Der Spieltransaktionsserver enthält verschiedene ASP-Dateien, deren Abarbeitung (wie beispielhaft im Zusammenhang mit den oben erläuterten Beispieldefinitionen der Spielelemente 2 bzw. 3 bereits gezeigt wurde) jeweils durch bestimmte auf Grafikreferenzen beruhende Anfragen der Web-Browser ausgelöst wird. Die Anzahl der abgebildeten ASP-Dateien ist dabei kei neswegs vollständig, sondern zu Anschauungszwecken auf wenige Beispiele beschränkt, nämlich auf die in obigem Zusammenhang genannten ASP-Dateien spielstand.asp, einsammeln.asp und mu enzen.asp. Bei den ASP-Dateien handelt es dabei um Internet- Seiten, in welche ASP-Skripten in der Skriptsprache Visual Basic (Visual Basic ist eine eingetragene Marke der Microsoft Corporation) eingefügt sind. Im Bedarfsfall können diese ASP- Skripten auch in einer anderen geeigneten Skriptsprache, etwa Java-Skript, programmiert sein.

Die Datenbank ist vorliegend als relationale Datenbank pro grammiert und enthält mehrere Tabellen 1 bis 3, in denen ver schiedene Datensätze, die zumindest vorübergehend auf dem Ne bentransaktionsserver abgespeichert werden sollen, abgelegt sind. Diese Datensätze enthalten, wie im Beispiel gezeigt, Daten über die aktuell laufenden Sessionen, über die aktuell versteckten Schätze bzw. über die für das Spiel registrierten Benutzer und sind vom Spieltransaktionsserver im Rahmen der Abarbeitung obiger ASP-Dateien abrufbar.

Der Grafikserver enthält, wie weiter oben bereits erläutert wurde, die verschiedenen Grafikinformationen, durch welche die in Frage kommenden Spielelemente symbolisiert werden. Beispielhaft sind die Grafikinformationen für die Symbole "keine Münze" (1 × 1-pixel.gif), "eine Münze" (1muenzen.gif) und "zwei Münzen" (2muenzen.gif) etc. für die Anzeige der laut aktueller Spielsituation einsammelbaren Münzen sowie das Symbol "Schatz auf dieser Web-Seite verstecken" (verstecken.gif) für die Anzeige eines die entsprechende Spielaktion auslösenden Buttons dargestellt. Auch diese Dar stellung ist nicht vollständig, sondern ebenfalls zu Anschau ungszwecken auf wenige Beispiele beschränkt.

Wird nun beispielsweise die ASP-Datei muenzen.asp durch eine entsprechende Anfrage eines Web-Browsers aufgerufen, sollen, wie weiter oben im Zusammenhang mit Fig. 4a und der Beispiel definition des Spielelements 3 bereits beschrieben, folgende Schritte ausgeführt werden:

1. Überprüfen, ob für den betreffenden Benutzer eine Session besteht;
2. falls für den Benutzer eine Session besteht, Ermitteln der Anzahl anzuzeigender Münzen; ansonsten direkter Sprung zu Schritt 3;
3. Ausliefern der passenden Grafikinformation (im Fall, daß keine Session besteht, soll ein 1 × 1 Pixel ausgeliefert werden)

Eine entsprechende Programmierung der ASP-Datei muenzen.asp könnte hierfür folgendermaßen definiert sein (teilweise sind bei diesem Beispiel aus Vereinfachungsgründen keine realen Befehle aufgeführt, sondern lediglich sinngemäße Annäherungen hiervon):

Man erkennt, daß der Nebentransaktionsserver bei Abarbeitung der ASP-Datei in einem ersten Schritt überprüft, ob für den betreffenden Benutzer eine Session besteht (mittels der If- Abfrage, ob session ("BENUTZER") gleich 1 ist). Ist dies der Fall, sucht der Nebentransaktionsserver in der Tabelle TABEL- LE2 (vgl. Fig. 5) die URL derjenigen Web-Seite, welche aktu ell vom Benutzerhost aufgerufen wurde (AKTUELLEURLVOMBILD). Findet er diese dort, bedeutet dies, daß ein anderer Spieler auf dieser Web-Seite seinen Schatz versteckt hat. Die ent sprechende Anzahl Münzen dieses Schatzes (ANZAHLMUENZEN) ist nebenstehend in der Tabelle vermerkt und wird dann vom Neben transaktionsserver ausgelesen. Nachfolgend wird dem Benutzerhost als Antwort (response) eine Referenz übermittelt, welche auf die passende, d. h. die entsprechende Anzahl Münzen symbo lisierende, Grafikdatei verweist. So wird der Benutzerhost im Falle, daß der Schatz des anderen Spielers zwei Münzen ent hält, auf die Grafikdatei 2muenzen. gif verwiesen. Der Benut zerhost bekommt die Grafikinformation also nicht direkt über mittelt, sondern wird (mittels des redirect-Befehls) auf eine entsprechende Datei umgeleitet.

Ist hingegen auf der betreffenden Web-Seite kein Schatz ver steckt (findet der Nebentransaktionsserver also die zugehöri ge URL nicht in der Tabelle TABELLE2), wird in einem nächsten Schritt eine Zufallszahl (ZUFALLSZAHL) zwischen 0 und 5 er mittelt (mittels des randomize-Befehls). Diese Zufallszahl repräsentiert die Anzahl Münzen, die dem Benutzer dann (anstelle eines fremden Schatzes) zum Einsammeln auf der Web- Seite angezeigt werden soll. Ist die Zufallszahl größer als Null, wird dem Benutzerhost - in analoger Weise wie oben be schrieben - als Antwort (response) eine entsprechende Refe renz übermittelt. Ist die Zufallszahl hingegen gleich Null wird der Benutzerhost auf die Grafikdatei 1 × 1-pixel.gif ver wiesen, welche (wie weiter oben schon beschrieben) vom Benut zer nicht wahrnehmbar ist. Der Benutzer sieht dann auf der betreffenden Web-Seite kein Münzsymbol und kann dort folglich keine Münzen einsammeln.

Am Ende des Programmierbeispiels erkennt man, daß der Benut zerhost auch dann auf die Grafikdatei 1 × 1-pixel.gif verwie sen, wenn für den betreffenden Benutzer keine Session besteht (die Abfrage session("BENUTZER") also ein Ergebnis ungleich 1 liefert).

Die vorstehenden Ausführungen machen deutlich, daß sich das erfindungsgemäße Spiel besonders vorteilhaft mit dem vorge stellten technischen Mitteln realisieren läßt. Gleiches gilt auch für die zugrunde liegenden Geschäftsmodelle.

So erlaubt beispielsweise die zentrale Abwicklung des Spiel geschehens über den Nebentransaktionsserver, mit nur geringem programmiertechnischem Aufwand das Spiel in die bestehenden Web-Seiten der Haupttransaktionsserver zu integrieren. Insbe sondere ist während des Spielverlaufs kein Datenaustausch zwischen den Haupttransaktionsservern erforderlich. Dennoch gewinnt der Benutzer den Eindruck, daß die das Spiel enthal tenen Web-Seiten logisch miteinander zusammenhängen, so daß virtuell eine Web-Seiten-Gemeinschaft geschaffen wird, die faktisch nur über den Nebentransaktionsserver miteinander verbunden sein können. Durch die Attraktivität des Spiels werden Benutzer veranlaßt, sich bevorzugt innerhalb dieser Gemeinschaft zu bewegen, was die Grundlage für die angespro chenen Geschäftsmodelle schafft.

Daneben bieten die vorgestellten technischen Mittel den Vor teil, daß die Spielelemente wahlweise nur denjenigen Benut zern angezeigt werden, die sich für das Spiel angemeldet ha ben und somit auch tatsächlich spielen wollen. Auf diese Wei se kann vermieden werden, daß nicht-spielende Benutzer durch die Spielinhalte irritiert oder verärgert werden. Es besteht somit für den Betreiber einer Web-Seite bei Integration des Spieles kein Risiko, daß sich Besucher der Web-Seite, die nicht spielen wollen, von den Spieleinhalten abgeschreckt werden.

Ferner ist es durch die vorgestellten technischen Mittel auf einfache Weise möglich, statistische Erhebungen darüber anzu stellen, wie oft Benutzer aufgrund des Spieles bestimmte Web- Seiten und/oder Werbebanner aufgerufen haben.

Die Seitenaufrufe können beispielsweise anhand der in den Grafikreferenzen enthaltenen URLs ermittelt werden. Auf ana loge Weise lassen sich auch die Aufrufe von Werbebannern re gistrieren, indem diese als Verweise auf den Nebentransakti onsserver definiert werden. Der Aufruf eines Werbebanners be wirkt dann zunächst, daß eine dafür vorgesehene Datei auf dem Nebentransaktionsserver aufgerufen wird, diese den Werbeban ner-Aufruf registriert und anschließend den betreffenden Web- Browser zu der entsprechenden Werbeseite weiterleitet.

Durch die Möglichkeit genauer statistischer Erhebungen ist eine erfolgsabhängige Bezahlung des Spiele-Betreibers zur Verwirklichung der angesprochenen Geschäftsmodelle auf einfa che Weise möglich. Im Bedarfsfall können solche Erhebungen noch weitere Details, wie IP-Nummern, Datum und Uhrzeit, etc. umfassen.

Claims

1. Verfahren zur Durchführung von Nebentransaktionen im Rahmen von Haupttransaktionen über ein Netzwerk, umfas send wenigstens einen Benutzerhost, einen Haupttransak tionsserver und einen Nebentransaktionsserver, wobei:

a) der Benutzerhost ein Dokument (1) vom Haupttransak tionsserver anfordert;
b) der Haupttransaktionsserver das angeforderte Doku ment (1) an den Benutzerhost zurücksendet, wobei dieses wenigstens eine auf den Nebentransaktions server verweisende Referenz aufweist;
c) der Benutzerhost eine der Referenz entsprechende Anfrage an den Nebentransaktionsserver sendet, wo bei im Falle, daß der zugehörige Benutzer für die Nebentransaktionen registriert ist, der Benutzer host zusätzlich eine Benutzerkennung zur Identifi zierung des Benutzers sendet;
d) der Nebentransaktionsserver auf die Anfrage des Be nutzerhosts hin eine nebentransaktionsbezogene Re ferenzinformation (x₂; x₃; x₄; x₅; x₆) an den Benut zerhost zurücksendet, wobei im Falle, daß der Be nutzer für die Nebentransaktionen registriert ist, die Referenzinformation (x₂; x₃; x₄; x₅; x₆) von früheren Nebentransaktionen des Benutzers abhängt;
e) der Benutzerhost das Dokument (1) darstellt, wobei die Referenzinformation (x₂; x₃; x₄; x₅; x₆) in das Dokument (1) eingefügt wird.

2. Verfahren nach Anspruch 1, bei welchem die Registrierung des Benutzers durch eine Anmeldung des Benutzers beim Nebentransaktionsserver erfolgt.

3. Verfahren nach Anspruch 1 oder 2, bei welchem die Regi strierung des Benutzers durch die erste Nebentransaktion des Benutzers erfolgt.

4. Verfahren nach Anspruch 2 oder 3, bei welchem im Falle, daß der Benutzer nicht für die Nebentransaktionen regi striert ist, als Referenzinformation eine Standardinfor mation zurückgesendet wird.

5. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die Referenz als Grafikreferenz definiert ist und die Referenzinformation als Grafik dargestellt wird.

6. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die Referenzinformation zusätzlich von der/den Haupttransaktion(-en) des Benutzers abhängt.

7. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die Referenzinformation zusätzlich von Haupt- und/oder Nebentransaktionen anderer Benutzer abhängt.

8. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem der Benutzerhost mit der Anfrage zusätzlich Re ferenzdaten, vorzugsweise eine Haupttransaktionsserver kennung und/oder eine Dokumentkennung, an den Neben transaktionsserver sendet.

9. Verfahren nach Anspruch 8, bei welchem die Referenzin formation zusätzlich von zumindest einem Teil der Refe renzdaten abhängt.

10. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem die in das Dokument (1) eingefügte Referenzin formation (x₃; x₄; x₆) als Verweis auf den Nebentransak tionsserver definiert ist und durch den Benutzer aufruf bar ist, wobei nach Aufruf des Verweises:

a) der Benutzerhost eine dem Verweis entsprechende An frage an den Nebentransaktionsserver sendet, wobei im Falle, daß der Benutzer für die Nebentransaktio nen registriert ist, der Benutzerhost zusätzlich eine Benutzerkennung zur Identifizierung des Benut zers sendet;
b) der Nebentransaktionsserver auf die Anfrage des Be nutzerhosts hin eine nebentransaktionsbezogene Verweisinformation (y₃; y₄; y₆) an den Benutzerhost zurücksendet;
c) der Benutzerhost die Verweisinformation (y₃; y₄; y₆) abarbeitet.

11. Verfahren nach Anspruch 10, bei welchem die Verweisin formation des Nebentransaktionsservers bewirkt, daß die Schritte a) bis e) gemäß Anspruch 1 wiederholt werden, wobei die Referenzinformation durch den vorangegangenen Aufruf des Verweises zusätzlich beeinflußbar ist.

12. Verfahren nach einem der vorhergehenden Ansprüche, bei welchem das Dokument (1) mehrere auf den Nebentransakti onsserver verweisende Referenzen aufweist.

13. Verfahren nach Anspruch 12, bei welchem zumindest ein Teil der in das Dokument (1) eingefügten Referenzinfor mationen als Verweise auf den Nebentransaktionsserver definiert sind und durch den Benutzer aufrufbar sind, wobei durch den Aufruf einer als Verweis definierten Re ferenzinformation, im Falle einer Wiederholung der Schritte a) bis e) gemäß Anspruch 1, zumindest ein Teil der übrigen Referenzinformationen beeinflußbar ist.

14. Verfahren zur Durchführung auf einem Benutzerhost als Teil eines Netzwerkes zur Durchführung von Nebentransak tionen im Rahmen von Haupttransaktionen über das Netz werk, wobei der Benutzerhost:

a) ein Dokument (1) von einem Haupttransaktionsserver anfordert;
b) das angeforderte Dokument (1) vom Haupttransakti onsserver empfängt, wobei dieses wenigstens eine auf den Nebentransaktionsserver verweisende Refe renz aufweist;
c) eine der Referenz entsprechende Anfrage an einen Nebentransaktionsserver sendet, wobei im Falle, daß der Benutzer für die Nebentransaktionen registriert ist, der Benutzerhost zusätzlich eine Benutzerken nung zur Identifizierung des Benutzers sendet;
d) auf seine Anfrage hin eine nebentransaktionsbezoge ne Referenzinformation (x₂; x₃; x₄; x₅; x₆) vom Ne bentransaktionsserver empfängt, wobei im Falle, daß der zugehörige Benutzer für die Nebentransaktionen registriert ist, die Referenzinformation (x₂; x₃; x₄; x₅; x₆) von früheren Nebentransaktionen des Be nutzers abhängt;
e) das Dokument (1) darstellt, wobei die Referenzin formation (x₂; x₃; x₄; x₅; x₆) in das Dokument (1) eingefügt wird.

15. Verfahren nach Anspruch 14 mit einem oder mehreren ent sprechenden Merkmalen der Ansprüche 1 bis 13.

16. Verfahren zur Durchführung auf einem Nebentransaktions server als Teil eines Netzwerkes zur Durchführung von Nebentransaktionen im Rahmen von Haupttransaktionen über das Netzwerk, wobei der Nebentransaktionsserver:

a) eine auf einer Referenz beruhende Anfrage eines Be nutzerhosts empfängt, wobei im Falle, daß der zuge hörige Benutzer für die Nebentransaktionen regi striert ist, der Nebentransaktionsserver zusätzlich eine Benutzerkennung vom Benutzerhost empfängt;
b) auf die Anfrage des Benutzerhosts hin eine neben transaktionsbezogene Referenzinformation (x₂; x₃; x₄; x₅; x₆) an den Benutzerhost zurücksendet, wobei im Falle, daß der Benutzer für die Nebentransaktio nen registriert ist, die Referenzinformation (x₂; x₃; x₄; x₅; x₆) von früheren Nebentransaktionen des Benutzers abhängt.

17. Verfahren nach Anspruch 16 mit einem oder mehreren ent sprechenden Merkmalen der Ansprüche 1 bis 13.

18. Verfahren nach einem der Ansprüche 1 bis 17, welches da zu verwendet wird, Nebentransaktionen in Form eines Spieles durchzuführen, wobei die wenigstens eine Refe renzinformation (ein) Spielelement(-e) darstellt, wel che(-s) die aktuelle Spielsituation repräsentiert/-en.

19. Verfahren zur Durchführung von Nebentransaktionen in Form eines Spieles im Rahmen von Haupttransaktionen über ein Netzwerk, umfassend wenigstens einen Benutzerhost und einen ersten Haupttransaktionsserver, wobei:

a) der Benutzerhost ein Dokument (1) vom Haupttransak tionsserver anfordert;
b) der Haupttransaktionsserver das angeforderte Doku ment (1) an den Benutzerhost zurücksendet;
c) der Benutzerhost das Dokument (1) darstellt, wobei dieses wenigstens ein Spielelement (2, 3, 4, 5, 6) aufweist, welches die aktuelle Spielsituation re präsentiert;
d) der Benutzer den Fortgang des Spieles dadurch be stimmen kann, daß er das/eines (der) Spielement(-e) (2; 3; 4; 5; 6) aktiviert.

20. Verfahren nach Anspruch 19, bei welchem der Benutzer den Fortgang des Spieles zusätzlich dadurch bestimmen kann, daß er ein weiteres Dokument (1) des ersten oder eines etwaigen weiteren Haupttransaktionsservers anfordert.

21. Verfahren nach Anspruch 19 oder 20, bei welchem das we nigstens eine Spielelement (2, 3, 4, 5, 6) nur darge stellt wird, wenn der Benutzer für das Spiel registriert ist.

22. Verfahren nach einem der Ansprüche 19 bis 21, bei wel chem die aktuelle Spielsituation von früheren Spielak tionen des Benutzers abhängt.

23. Verfahren nach einem der Ansprüche 18 bis 22, bei wel chem das Spiel einen Anreiz bietet, daß den Benutzer veranlaßt, verschiedene Dokumente des ersten Haupttrans aktionsservers und/oder von etwaigen weiteren Haupt transaktionsservern aufzurufen.

24. Verfahren nach einem der Ansprüche 18 bis 23, bei wel chem das Spiel einen Anreiz bietet, daß den Benutzer veranlaßt, (ein) Werbebanner, das/die auf dem jeweiligen Dokument (1) angezeigt wird/werden, aufzurufen.

25. Computerprogrammprodukt in Form eines Dokuments, welches Befehlscode-Abschnitte umfaßt, mit denen das Verfahren gemäß Anspruch 14 oder 15 durchgeführt wird, wenn das Dokument (1) auf einem Benutzerhost zur Darstellung ab gearbeitet wird.

26. Computerprogrammprodukt, welches Befehlscode-Abschnitte umfaßt, mit denen das Verfahren gemäß Anspruch 16 oder 17 durchgeführt wird, wenn das Computerprogramm auf ei nem Nebentransaktionsserver läuft.

27. System, umfassend einen Benutzerhost, einen Haupttrans aktionsserver und einen Nebentransaktionsserver, zur Durchführung von Nebentransaktionen im Rahmen von Haupt transaktionen über ein Netzwerk, welches dazu eingerich tet ist, daß:

a) der Benutzerhost ein Dokument (1) vom Haupttransak tionsserver anfordert;
b) der Haupttransaktionsserver das angeforderte Doku ment (1) an den Benutzerhost zurücksendet, wobei dieses wenigstens eine auf den Nebentransaktions server verweisende Referenz aufweist;
c) der Benutzerhost eine der Referenz entsprechende Anfrage an den Nebentransaktionsserver sendet, wo bei im Falle, daß der zugehörige Benutzer für die Nebentransaktionen registriert ist, der Benutzer host zusätzlich eine Benutzerkennung zur Identifi zierung des Benutzers sendet;
d) der Nebentransaktionsserver auf die Anfrage des Be nutzerhosts hin eine nebentransaktionsbezogene Re ferenzinformation (x₂; x₃; x₄; x₅; x₆) an den Benut zerhost zurücksendet, wobei im Falle, daß der Be nutzer für die Nebentransaktionen registriert ist, die Referenzinformation (x₂; x₃; x₄; x₅; x₆) von früheren Nebentransaktionen des Benutzers abhängt;
e) der Benutzerhost das Dokument (1) darstellt, wobei die Referenzinformation (x₂; x₃; x₄; x₅; x₆) in das Dokument (1) eingefügt wird

28. System nach Anspruch 27, welches dazu eingerichtet ist, daß die Registrierung des Benutzers durch eine Anmeldung des Benutzers beim Nebentransaktionsserver erfolgt.

29. System nach Anspruch 27 oder 28, welches dazu eingerich tet ist, daß die Registrierung des Benutzers durch die erste Nebentransaktion des Benutzers erfolgt.

30. System nach einem der Ansprüche 27 bis 29, welches dazu eingerichtet ist, daß im Falle, daß der Benutzer nicht für die Nebentransaktionen registriert ist, als Referen zinformation eine Standardinformation zurückgesendet wird.

31. System nach einem der Ansprüche 27 bis 30, bei welchem der Nebentransaktionsserver dazu eingerichtet ist, die Haupttransaktion(-en) des Benutzers zu erfassen, wobei die Referenzinformation zusätzlich von zumindest einem Teil der erfaßten Haupttransaktion(-en) abhängt.

32. System nach einem der Ansprüche 27 bis 31, bei welchem der Nebentransaktionsserver dazu eingerichtet ist, die Haupt- und/oder Nebentransaktionen anderer Benutzer zu erfassen, wobei die Referenzinformation zusätzlich von zumindest einem Teil der erfaßten Haupt- bzw. Neben transaktionen anderer Benutzer abhängt.

33. System nach einem der Ansprüche 27 bis 32, welches dazu eingerichtet ist, daß der Benutzerhost mit der Anfrage zusätzlich Referenzdaten, vorzugsweise eine Haupttrans aktionsserverkennung und/oder eine Dokumentkennung, an den Nebentransaktionsserver sendet.

34. System nach Anspruch 33, welches derart eingerichtet ist, daß die Referenzinformation zusätzlich von zumin dest einem Teil der Referenzdaten abhängt.

35. System nach einem der Ansprüche 27 bis 34, welches dazu eingerichtet ist, daß die in das Dokument (1) eingefügte Referenzinformation (x₃; x₄; x₆) als Verweis auf den Ne bentransaktionsserver definiert ist und durch den Benut zer aufrufbar ist, wobei nach Aufruf des Verweises:

a) der Benutzerhost eine dem Verweis entsprechende An frage an den Nebentransaktionsserver sendet, wobei im Falle, daß der Benutzer für die Nebentransaktio nen registriert ist, der Benutzerhost zusätzlich eine Benutzerkennung zur Identifizierung des Benut zers sendet;
b) der Nebentransaktionsserver auf die Anfrage des Be nutzerhosts hin eine nebentransaktionsbezogene Ver weisinformation (y₃; y₄; y₆) an den Benutzerhost zurücksendet;
c) der Benutzerhost die Verweisinformation (y₃; y₄; y₆) abarbeitet.

36. System nach Anspruch 35, welches derart eingerichtet ist, daß die Referenzinformation zusätzlich von (zumindest einem Teil) der auf einem Verweis beruhenden Anfrage(-n) des Benutzerhosts abhängt.

37. System nach einem der Ansprüche 27 bis 36, welches dazu eingerichtet ist, Nebentransaktionen in Form eines Spie les durchzuführen, wobei die wenigstens eine Referenzin formation (ein) Spielelement(-e) darstellt, welche(-s) die aktuelle Spielsituation repräsentiert/-en.

38. Nebentransaktionsserver als Teil eines Netzwerkes zur Durchführung von Nebentransaktionen im Rahmen von Haupt transaktionen über das Netzwerk, welcher dazu eingerich tet ist:

a) eine auf einer Referenz beruhende Anfrage und/oder eine Benutzerkennung von einem Benutzerhost zu emp fangen;
b) anhand der etwaig empfangenen Benutzerkennung zu erkennen, daß es sich bei dem zugehörigen Benutzer um einen für die Nebentransaktionen registrierten Benutzer handelt;
c) auf die Anfrage des Benutzerhosts hin eine neben transaktionsbezogene Referenzinformation (x₂; x₃; x₄; x₅; x₆) bereitzustellen und an den Benutzerhost zurückzusenden, wobei im Falle, daß der Benutzer für die Nebentransaktionen registriert ist, die Re ferenzinformation (x₂; x₃; x₄; x₅; x₆) von früheren Nebentransaktionen des Benutzers abhängt.

39. Nebentransaktionsserver nach Anspruch 38 mit einem oder mehreren entsprechenden Merkmalen der Ansprüche 27 bis 37.