DE19941504A1 - Verfahren zur Durchführung von Spielen über das Internet - Google Patents

Abstract

Verfahren zur Durchführung von Spielen über das Internet mit mindestens einem Teilnehmer mit einem Rechner, wobei das Spiel selbst auf einem Server abläuft, jedoch die gesamt Animation und Benutzerschnittstelle durch ein Programm auf dem Rechner des Teilnehmers dargestellt wird und eine Datenübertragung zwischen Server und Rechner des Teilnehmers nur auf Anforderung des Programms auf dem Rechner des Teilnehmers erfolgt, und solche Anforderungen immer dann erfolgen, wenn der Teilnehmer einen Spielzug durchführt oder eine vorgegebene Zeit T abgelaufen ist.

Description

Die Erfindung betrifft ein Verfahren zur Durchführung von Spielen über das Internet mit mindestens einem Teilnehmer mit einem Rechner, wobei das Spiel selbst auf einem Server ab­ läuft, jedoch die gesamte Animation und Benutzerschnittstelle durch ein Programm auf dem Rechner des Teilnehmers darge­ stellt wird.

Solche Verfahren sind im Stand der Technik bereits bekannt. Im einfachsten Fall wird ein Spielzug oder ein Einsatz zur Server übertragen, dieser überträgt dann sofort das Spieler­ gebnis oder den Gewinn/Verlust zurück. Dies läßt sich auch problemlos mit der im Internet-http 1.0-Protokoll vorgesehe­ nen Anfrage des Nutzers-Antwort des Servers-Struktur reali­ sieren.

Sofern jedoch kompliziertere Spiele, wie beispielsweise Rou­ lette oder Black Jack, bei denen das Spielgeschehen kompli­ zierter ist als der Spielzug des Teilnehmer-Ergebnis, oder wenn gar mehrere Teilnehmer gemeinsam Spiele wie Black Jack oder Roulette über das Internet spielen sollen, wobei jeder Teilnehmer auch die Spielzüge der anderen Teilnehmer beobach­ ten kann, ist diese Struktur ungeeignet.

Gemäß dem Stand der Technik war es dann nur möglich, eine permanente TCP-Verbindung zwischen dem Server und allen Teil­ nehmern aufzubauen und während des ganzen Spieles aufrecht zu erhalten.

Dies führte jedoch zu erheblichen Problemen, da einerseits die meisten an das Internet angeschlossenen Rechner heutzuta­ ge durch sogenannte "Firewalls" gegen Manipulationen ge­ schützt sind. Diese Firewalls lassen jedoch lediglich eine ganz geringe Anzahl von gleichzeitigen TCP-Verbindungen zu. Außerdem unterstützt das Internet-Protokoll http 1.0 keine dauernden TCP-Verbindungen. Selbst wenn man diese Probleme jedoch löst, so ist für permanente Verbindungen ein großer Hardware-Aufwand und erhebliche Systemresourcen erforderlich, und die Betriebssysteme der meisten Server können nur eine geringe Zahl dauernd offener Verbindungen handhaben.

Es ist daher Aufgabe der Erfindung, ein solches Verfahren zur Durchführung von Spielen über das Internet vorzuschlagen, bei dem auch komplizierte Spiele mit mehreren Teilnehmern, die ihre Spielzüge gegenseitig beobachten können, möglich sind, ohne daß permanente Datenverbindungen zwischen den Teilneh­ mern und dem Server aufrecht erhalten bleiben müssen.

Erfindungsgemäß wird diese Aufgabe dadurch gelöst, daß eine Datenübertragung zwischen Server und Rechner des Teilnehmers nur auf Anforderung des Programms auf dem Rechner des Teil­ nehmers erfolgt.

Erfindungsgemäß ist es besonders bevorzugt, daß Anforderungen zur Datenübertragung immer dann erfolgen, wenn der Teilnehmer einen Spielzug durchführt, oder nach Ablauf einer vorgegebe­ nen Zeit T seit der letzten Anforderung. Dadurch wird sicher­ gestellt, daß für den Teilnehmer selber sein Spielzug, den er gerade durchgeführt hat, sofort auf dem Bildschirm sichtbar wird, während er die Spielzüge anderer Teilnehmer beispiels­ weise erst nach fünf oder zehn Sekunden auf seinem Bildschirm sieht. Dies stört aber nicht, da der einzelne Teilnehmer ja nicht weiß, wann genau der jeweils andere Teilnehmer seinen Spielzug durchgeführt hat. Scheinbar läuft das System dann so, als ob permanente Verbindungen zwischen den Teilnehmern und dem Server bestehen würden.

Es ist dabei weiter bevorzugt, daß das Programm auf dem Rech­ ner des Teilnehmer jeder Aufforderung zur Datenübertragung einen Authentifizierungscode beifügen muß. Damit wird das Problem gelöst, daß jede Aufforderung zur Datenübertragung (und natürlich auch jeder Spielzug des Teilnehmers) einen neuen Aufbau einer Internet-Verbindung bedeutet. Dabei muß aber gegenüber dem Server jeweils eine Authentifizierung des anrufenden Teilnehmers ermöglicht werden, und gleichzeitig muß der entsprechende Anruf dem richtigen Teilnehmer zugeord­ net werden, damit die richtigen Spielstandsdaten übertragen werden können.

Zur Vereinfachung der Abläufe ist es bevorzugt, daß der Au­ thentifizierungscode dabei ursprünglich vom Server erzeugt und dem Rechner des Teilnehmers übermittelt wird.

Es ist dabei besonders bevorzugt, daß der Authentifizierung­ scode nur in verschlüsselter Form übertragen wird.

Da ohne permanent stehende Verbindungen nicht sichergestellt ist, daß jeder Anruf eines Teilnehmers aus dem Internet rechtzeitig beim Server eintrifft, ist es bevorzugt, daß jede Anforderung und jede Datenübertragung mit einer laufenden Nummer versehen ist. Dadurch können Teilnehmer, Rechner und Server feststellen, ob eine zwischenzeitlich gesendete Anfor­ derung bzw. Datenübertragung verloren gegangen ist.

Bei komplexeren Spielen mit mehreren Teilnehmern besteht das Problem, daß das Spiel erst dann beendet werden kann, wenn jeder Teilnehmer bestimmte Spielzüge vorgenommen hat. Damit müßten alle anderen Teilnehmer auf den "Letzten" warten. Dies kann dann zum Problem werden, wenn beispielsweise die Inter­ net-Verbindung zu diesem Teilnehmer abgerissen ist. Man könn­ te nun einfach den Einsatz dieses Teilnehmers für verloren erklären, und das Spiel mit den restlichen Teilnehmern zu En­ de führen. Dies würde jedoch zu großer Verärgerung bei denje­ nigen Teilnehmern führen, die ihre Einsätze verlieren und die ja meist für ein Zusammenbrechen der Internet-Verbindung gar nichts können. Es wird daher vorzugsweise vorgeschlagen, daß ein Teilnehmer, der nicht innerhalb einer vorgegebenen Zeit seine Spielzüge durchführt, aus dem Spiel mit mehreren Teil­ nehmern ausscheidet, und für ihn allein ein weiteres Spiel auf dem Server erzeugt wird. Auf diese Weise kann er allein unter den gleichen Bedingungen weiterspielen, sobald seine Internet-Verbindung wieder hergestellt ist. Sein Einsatz geht ihm nicht verloren.

In diesem Zusammenhang ist es auch bevorzugt, daß dem Teil­ nehmer eine Zeitanzeige zur Verfügung gestellt wird, die an­ zeigt, wie lange er noch Zeit hat, seinen Spielzug durchzu­ führen, damit dieser noch beim gegenwärtigen Spiel vom Server berücksichtigt werden kann.

Da die Laufzeit der entsprechenden Spielzugdaten im Internet nicht präzise vorhergesagt werden kann, und umgekehrt auch eine präzise Synchronisation zwischen Server und Teilnehmer wegen der unterschiedlichen Nachrichtenlaufzeiten auf dem In­ ternet nicht möglich ist, ist es bevorzugt, daß zur Erzeugung der Zeitanzeige der Server bei jeder Datenübertragung eine Information über die für den Spielzug verbleibende Zeit mitsendet, und das Programm auf dem Rechner des Teilnehmers die Zeitdauer zwischen Absendung der Anforderung und der An­ kunft der Datenübertragung davon abzieht.

Die vorgenannte Lösung gibt jedoch nur eine grobe Schätzung für die Laufzeit der Daten zwischen Teilnehmerrechner und Server, da sie davon ausgeht, daß diese der Gesamtlaufzeit der Daten zwischen Anforderung durch den Teilnehmerrechner und Ankunft der Daten beim Teilnehmerrechner entspricht.

Es ist daher weiter bevorzugt, daß verschiedene Zonen der Zeitanzeige erzeugt werden, nämlich eine erste Zone, in der die für den Spielzug verbleibende Zeit größer ist als die Zeitdauer zwischen Absendung der Anforderung und der Ankunft der Datenübertragung, eine zweite Zone, in der die für den Spielzug verbleibende Zeit größer ist als die halbe Zeitdauer zwischen Absendung der Anforderung und der Ankunft der Daten­ übertragung und eine dritte Zone, in der die für den Spielzug verbleibende Zeit kleiner ist als die halbe Zeitdauer zwi­ schen Absendung der Anforderung und der Ankunft der Daten­ übertragung.

Auf diese Weise verfügt der Spielteilnehmer über eine recht genaue Information, wie wahrscheinlich es ist, daß seine Spielzüge noch berücksichtigt werden können: So lange sich die Zeitanzeige in der ersten Zone befindet, ist mit größter Wahrscheinlichkeit damit zu rechnen, daß der Spielzug noch ausgeführt werden kann. In der zweiten Zone besteht lediglich eine gewisse Wahrscheinlichkeit dafür, und in der dritten Zo­ ne ist es nahezu ausgeschlossen, daß der Spielzug noch recht­ zeitig durchgeführt werden kann.

Die vorliegende Erfindung wird im folgenden anhand eines in der Zeichnung dargestellten Ausführungsbeispiels näher erläu­ tert. Es zeigt:

Fig. 1 den grundsätzlichen Aufbau der erfindungsgemäßen Da­ tenverbindungen.

Der technische Aufbau der vorliegenden Erfindung umfaßt einen Client 10, das heißt ein Programm, welches auf dem Rechner des Spielteilnehmers läuft. Dieses steht über http bzw. ab­ hörgeschützte http/ssl-Verbindungen mit dem Internet 12 in Verbindung. Über das Internet 12 ist eine weitere Verbindung im http/ssl-Protokoll mit dem Rechner 14, den beispielsweise ein Internet-Spielcasino betreibt, verbunden. Auf diesem Rechner 14 laufen verschiedene Server, wobei die Nachrichten aus dem Internet 12 zuerst einem sicheren www-Server 16 zuge­ leitet werden. Dieser steht mit den einzelnen Job-Servern 18, das heißt, den Programmen, auf denen die einzelnen Spiele laufen, in Verbindung. Die Job-Server 18 sind mit einem Zu­ fallszahlengenerator 20, der Kontoverwaltung 22, die die Kon­ ten der einzelnen Spieler verwaltet, und einer Protokol­ liereinheit 24 verbunden.

Das Client-Programm 10 ist ein Programm, das auf dem Spieler­ computer läuft und das die Schnittstelle zum eigentlichen Spiel verkörpert. Es zeigt dem Spieler den aktuellen Spiel­ stand an und kommuniziert für ihn mit dem Spiele-Server, der praktisch ein Bestandteil des Internet-Spielcasinos ist. Der Spiele-Server ist ein Programm, das für den Benutzer das Spiel realisiert. Er akzeptiert alle seine Spielzüge und rea­ giert auf sie. Ein Spiele-Server kann im Prinzip für eine be­ liebige Anzahl von Spielen zuständig sein. In der Regel wird jedoch ein Server nur einen bestimmten Spieltyp bedienen.

Der Spiele-Server kontaktiert die Datenbank für jeden Spiel­ zug, um die Benutzerdaten zu überprüfen und das Resultat zu speichern. Diese Kommunikation ist für den Spieler transpa­ rent, denn er sieht keine Details aus der inneren Struktur des Spiele-Servers 18.

Jeder Spieler benutzt ein lokales Programm 10, das mit dem Spiele-Server 18 kommuniziert. Dieses benutzt entweder nur den www-Browser, den Browser erweitert durch "Plug In's", "Applets" oder ähnliches, oder ein selbständig ausführbares Programm. Jedes Spiel wird zuerst aus einer oder mehreren Spielauswahlseiten ausgewählt. Danach wird ein neues Spiel­ fenster geöffnet, es zeigt die Spielgraphik an und der Spie­ ler kann anfangen zu spielen. Er kann zuerst seinen Einsatz wählen, der ganz einfach (Slot-Machine), oder ganz kompli­ ziert (Roulette) sein kann, und schließlich fordert er einen neuen Spielzug an. Das Spieler-Programm 10 kann dann eine Animation starten, z. B. das Roulette-Rad drehen, es sendet eine Nachricht an den entsprechenden Spiele-Server und wartet auf die Antwort. Wenn die Antwort des Servers kommt, stoppt das Programm die Animation, zeigt das Resultat an und wartet auf weitere Benutzeraktionen.

Auf diese Weise kann ein virtuelles Spielcasino im Internet realisiert werden, und bei entsprechender Absicherung der Da­ tenkommunikation kann sogar um "richtiges" Geld gespielt wer­ den.

Dabei müssen jedoch die Probleme der Kommunikation über das Internet berücksichtigt werden. Da die Internet-Kommunikation nicht 100-prozentig verläßlich ist, kann es passieren, daß die Server-Antwort zu spät, nur teilweise, oder überhaupt nicht ankommt. In diesem Fall muß der Spieler die Möglichkeit haben, den Spielzug zu wiederholen, so daß eine neue und hof­ fentlich erfolgreichere http-Verbindung mit dem Server zu­ stande kommen kann. Dabei macht es keinen Unterschied, ob der Server die letzte Spieler-Nachricht bekommen hat, aber seine Antwort verloren ging, oder ob er sie überhaupt nicht bekom­ men hat, da erfindungsgemäß in beiden Fällen das Resultat richtig bearbeitet werden muß. Wenn ein Spielzug vom Server nicht ausgeführt wird, und daher keine entsprechende Rückmel­ dung erfolgt ist, muß der Spieler lediglich erneut das ent­ sprechende Display-Element anklicken.

Während des Spiels kontaktiert das Client-Programm 10 den Server 18 in regelmäßigen Abständen und fordert den neuesten Spielstand an. Die Kommunikation wird dabei immer von dem Client-Programm 10 gestartet: Es sendet eine Nachricht an den Spiele-Server 18 und der Server 18 schickt ihm eine Antwort zurück.

Es ist daher erforderlich, daß ein entsprechendes Client- Programm 10 auf dem Rechner des Spielteilnehmers verfügbar ist. Dieses Programm kann entweder ebenfalls über Internet oder aber auf CD-Rom zur Verfügung gestellt werden. Im erste­ ren Falle kann das Programm einmal aus dem Internet geladen und dann auf der Festplatte des lokalen Rechners beim Teil­ nehmer gehalten werden.

Während eines Spiels mit mehreren Mitspielern muß jeder Mit­ spieler in der Lage sein, den gegenwärtigen Spielstand zu se­ hen, der Einsätze und andere Spielzüge aller anderen Mitspie­ ler umfaßt. Nachdem jede Kommunikation nach dem Internet- Protokoll immer von dem Client angefordert werden muß, hat der Server keine Möglichkeit, dem Client mitzuteilen, daß sich der Spielstand geändert hat. Der Server muß vielmehr warten, bis der Client den aktuellen Spielstand abfragt. Dar­ aus folgt, daß die Clients den Server in regelmäßigen Abstän­ den abfragen müssen, auch wenn ihr Spieler keine Aktion aus­ führt. Dies könnte unbefriedigend erscheinen im Vergleich zu Spielstandsaktualisierungen, die durch den Server bei jeder Änderung des Spielstands veranlaßt werden. Es ist jedoch tat­ sächlich die einzig ausführbare Art, um im vorliegenden Fall Aktualisierungen des Spielstandes zu verbreiten. Wenn das Spiel P Mitspieler hat, und jeder von ihm B Einsätze oder an­ dere Spielzüge während eines Spiels durchführt, müßte der Server B . P² Aktualisierungsmeldungen an die Clients schic­ ken. Bei Abfrage durch den Client, und unter Annahme von N Abfragen pro Spiel, muß der Server lediglich P . (B+N) Mit­ teilungen senden, wodurch Spiele mit wesentlich mehr Teilneh­ mern realisiert werden können.

Der Spielstand muß in regelmäßigen Abständen, beispielsweise im Abstand von 10 Sekunden abgefragt werden. Die Abfragen sollten jedoch nicht zu häufig erfolgen, damit nicht zuviel Datenverkehr beim Server anfällt. Die regelmäßige Abfragefre­ quenz von N Sekunden wird nur unterbrochen, wenn der eigene Spieler einen Spielzug macht: Mit der zugehörigen Antwort sendet der Server auch den gesamten Spielstand. Die nächste Erneuerung des Spielstandes kann deshalb nach N Sekunden nach der Antwort auf den Spielzug statt N Sekunden nach der letz­ ten Erneuerung des Spielstandes erfolgen. Auf diese Weise hat der Spieler den Eindruck, daß die entsprechenden Spielzüge in Echtzeit angezeigt werden, da er seine eigenen Spielzüge so­ fort im Spielstand berücksichtigt findet. Hinsichtlich der Spielzüge der anderen Mitspieler fehlt ihm ja eine zeitliche Zuordnung. Das erfindungsgemäße Verfahren erweckt daher bei jedem Mitspieler den Eindruck eines "echten" Echtzeitbe­ triebs, obwohl die Spielstände eigentlich nur in Zeitabstän­ den von 10 oder 15 Sekunden erneuert werden.

Ein weiteres Problem, welches das erfindungsgemäße Verfahren löst, beruht darauf, daß Spiele mit mehreren Mitspielern eine Synchronisation zwischen den Spielern und dem Server erfor­ dern. Dies ist schon in einem lokal verteilten System schwie­ rig genug, und ist natürlich in einem Internet-System noch schwieriger, da das Internet keine festen Nachrichtenlaufzei­ ten bietet.

Der Client muß nämlich beispielsweise wissen, wann der letzte Zeitpunkt gekommen ist, um eine Mitteilung zu schicken, so daß diese den Server vor dem Ablauf einer bestimmten Zeit, beispielsweise der Zeit zum Setzen im Roulette, erreicht. Dies bedeutet, daß der Client die Serverzeit als auch seine eigene Zeitdistanz zu dem Server kennen muß, um seine Aktio­ nen mit dem Server zu synchronisieren.

Erfindungsgemäß wird diese Synchronisation mit einem sehr einfachen Verfahren erreicht, welches darauf beruht, daß die Rundlaufzeit gemessen wird, d. h. die Laufzeit zwischen der Absendung einer Nachricht vom Client bis zu dem Zeitpunkt, an dem die Antwort des Servers vorliegt. Zusätzlich enthält jede Nachricht des Servers bei Spielen mit mehreren Teilnehmern die Variable "Server-Zeit". Dies kann beispielsweise eine ganzzahlige Zahl sein, die jede Sekunde während der Betriebs­ dauer des Servers heraufgezählt wird. Die Clients nutzen die­ se zusammen mit der gemessenen Rundlaufzeit ihrer Mitteilun­ gen, um daraus die aktuelle Server-Zeit abzuleiten. Wenn der Client beispielsweise einen Server-Zeit-Wert von 100 zurück­ geschickt bekommt, und die Rundlaufzeit 6 Sekunden betrug, kann der Client mit einiger Sicherheit darauf schließen, daß zu dem Zeitpunkt, an dem er die Nachricht vom Server erhalten hat, die Server-Zeit 103 betragen hat, und daß es 3 Sekunden dauert, um den Server zu erreichen. Nehmen wir nun an, daß bei dem nächsten Nachrichtenaustausch die Rundlaufzeit 12 Se­ kunden beträgt. In diesem Fall weiß der Client, daß seine laufende Annahme hinsichtlich der Server-Zeit genauer ist als die neue, weil nun die Rundlaufzeit länger ist und es nicht möglich ist, festzustellen, ob beide Übertragungswege der Nachricht die gleiche Zeit gebraucht haben, oder ob einer nur eine Sekunde und der andere 11 Sekunden gebraucht hat. Ande­ rerseits weiß der Client nun, daß er die Nachricht 6, und möglicherweise sogar 12 Sekunden eher senden muß, um den Ser­ ver noch rechtzeitig zu erreichen. Wenn der nächste Nachrich­ tenaustausch eine Rundlaufzeit von 4 Sekunden erreicht, kann der Client seine Annahme für die Server-Zeit korrigieren, aber er sollte den Sicherheits-Zeitabstand nicht korrigieren, es sei denn, daß die meisten der folgenden Nachrichten ähnli­ che Übertragungsgeschwindigkeiten erreichen.

Auf diese Weise sieht man, daß mit jedem neuen Nachrichten­ austausch der Client eine genauere Annahme hinsichtlich der Server-Zeit hat und über mehr Daten verfügt, um zu schätzen, wie lang es dauert, um den Server zu erreichen. Diese Daten sollten in einer bequemen Weise angegeben werden:
Die verbleibende Zeit bis zum Ablauf der Frist zur Durchfüh­ rung eines Spielzuges (in Server-Zeit) sollte immer angezeigt und aufgefrischt werden,
der mittlere Abstand, also die Zeit, die notwendig ist, um den Server zu erreichen sollte ebenfalls angezeigt werden,
ein farbiges Kästchen kann zeigen, ob es ziemlich sicher ist, daß der Server rechtzeitig erreicht werden kann (grün), wann es weniger wahrscheinlich wird (gelb oder orange) und wenn es sehr unwahrscheinlich oder unmöglich ist (rot).

Alle diese drei Angaben könnten auch beispielsweise als Ana­ log-Uhr mit zwei farbigen Zeigern oder als eine Digital-Uhr mit zwei Anzeigen dargestellt werden, wobei eine die Server- Zeit und die andere die Server-Zeit plus Laufzeit zwischen Client und Server anzeigt. Der farbige Hintergrund der Uhren kann dann seine Farbe entsprechend ändern.

Beim Roulette-Spiel ist diese Synchronisation im wesentlichen nur nötig, damit der Mitspieler weiß, bis wann er seine Ein­ sätze noch setzen oder ändern kann und wann das "rien ne va plus" auftritt.

Wesentlich komplizierter ist die Situation jedoch bei Black Jack, da dieses Spiel definierte Spielabschnitte (Setzen, Spielen) hat, und alle Spieler ihre Aktionen rechtzeitig durchführen müssen. Bei einem Spiel übers Internet verzichtet man vorzugsweise auf die normale Regel, daß alle Spieler se­ quentiell nacheinander spielen müssen, da der Spiel-Server im Gegensatz zu einem menschlichen "Black Jack-Dealer" mehrere Spieler gleichzeitig bedienen kann und die Erzwingung einer Reihenfolge das Spiel wesentlich langsamer und wesentlich ab­ hängiger von Spielern machen würde, die nur eine sehr langsa­ me Internet-Verbindung haben.

Wenn ein Spieler trotzdem seine erforderlichen Aktionen nicht rechtzeitig durchführt, wird er aus dem Spiel mit mehreren Teilnehmern entfernt und an einen "Privat-Tisch" versetzt, wo er allein spielt und keine Zeitbeschränkungen zur Beendigung des Spiels hat. Er kann sogar das Spiel unterbrechen und spä­ ter weiterspielen. Der Übergang von einem Spiel mit mehreren Teilnehmern an einen Privat-Tisch wird vom Server über ein "Private"-Flag an den Client mitgeteilt. Wenn das Client- Programm diese Meldung erhält, muß es den Spieler darüber in­ formieren, daß er aus dem ursprünglichen Spiel entfernt wor­ den ist. Dies muß in unmißverständlicher Weise geschehen. Üb­ licherweise passiert es dadurch, daß die Art, in der das Spiel am Bildschirm des Teilnehmerrechners dargestellt wird, geändert wird, so daß der Spieler weiß, was passiert ist.

Bei all diesen Spielen sendet der Server nach jeder Abfrage des Clients stets den gesamten Spielzustand, d. h. es werden keine inkrementellen Änderungen übertragen. Dadurch gibt es weniger Probleme, wenn eine Rückmeldung vom Server an den Client ausgefallen ist. Das Client-Programm muß prüfen, ob sich der Spielstand geändert hat, und dementsprechend die An­ zeige aktualisieren. Wenn beim Roulette ein neues Spiel be­ ginnt, wird der Tisch (wie im echten Casino) abgeräumt. Das würde normalerweise den letzten Einsatz des Spielers und das letzte Spielergebnis löschen, möglicherweise bevor der Spie­ ler genügend Zeit hatte, das Spielergebnis zu betrachten, oder bei sehr langsamen und schlechten Internet-Verbindungen sogar bevor das Spielergebnis vollständig übertragen worden ist. Um dieses Problem zu lösen, schlägt die vorliegende Er­ findung vor, diese Information dem Spieler zusätzlich auf be­ queme Weise zugänglich zu machen. Beispielsweise kann der Spieler selbst entscheiden, wann der Tisch abgeräumt ist und ein neuer Spielstatus abgefragt ist, oder das letzte Ergebnis kann gespeichert und vom Spieler durch Anklicken einer Schaltfläche nochmals dargestellt werden. Ebenso könnte das Client-Programm auch einige oder alle frühere Einsätze und die entsprechenden Spielergebnisse zwischenspeichern und die­ se dem Spieler auf Anforderung zugänglich machen.

Wenn ein Spieler beim Roulette während einiger aufeinander­ folgender Spiele keine Einsätze macht, wird er ebenfalls an einen Privat-Tisch versetzt. Um den Benutzer zu warnen, daß er bald versetzt werden wird, sendet der Server mit allen Übertragungen von Spielzustandsdaten eine entsprechende Mel­ dung während der letzten Runde vor Ablauf der Zahl der Spie­ le. Das Client-Programm kann dann rechtzeitig eine entspre­ chende Warnung ausgeben.

Erfindungsgemäß ist es auch möglich, daß ein Teilnehmer nur als "Gast" teilnimmt. Er benötigt dann kein Konto, kann dafür aber auch keine Einsätze machen. Das Client-Programm dieses Teilnehmers fragt dann nur alle N Sekunden den Spielstand ab und stellt diesen dann nach Übermittlung durch den Server auf dem Bildschirm dar. Wenn der Besucher zu lange bleibt, kann der Server ihn nach einiger Zeit entfernen und weitere Anfor­ derungen des Client-Programms mit einer entsprechenden Feh­ lermeldung beantworten.

Hinsichtlich der Zeitsynchronisation ist es erfindungsgemäß besonders bevorzugt, daß der Server mit jeder Antwort die Server-Zeit überträgt, die noch übrig ist, bis das Spiel (oder der entsprechende Teil des Spiels) endet und die ur­ sprüngliche Gesamtlänge des gesamten Zeitintervalls. Der Cli­ ent muß die Rundlaufzeit einer Meldung berücksichtigen, die zwischen dem Client und dem Server ausgetauscht wird, und die verbleibende Zeit sowohl als Client als auch als Server-Zeit anzeigen. Mit jeder Meldung, die er von dem Server erhält, bekommt der Client eine genauere Schätzung der Server-Zeit und kann sich synchronisieren, selbst wenn die Rundlaufzeit sich ändert. Wenn die Zeit in einem graphischen Balken darge­ stellt wird, entspricht die gesamte Balkenlänge der Länge des Gesamtintervalls und die abgelaufene Länge der bereits ver­ gangenen Zeit.

Das im Internet übliche http-Protokoll weist darüber hinaus noch die Problematik auf, daß es darin nicht möglich ist, Meldungen, die auf vorherigen Aktionen beruhen, zu identifi­ zieren. Erfindungsgemäß wird daher vorgeschlagen, ein soge­ nanntes "Zugangs-Zertifikat" (Access Certificate = AC) jeder Meldung hinzuzufügen, um dem Kommunikationsverfahren Stabili­ tät zu verleihen und gleichzeitig die Meldungen der einzelnen Spieler zu identifizieren. Das AC dient einem doppelten Zweck: Zuerst dient es dazu, Meldungen von Spielern zu iden­ tifizieren, die sich vorher erfolgreich eingeloggt haben, und zweitens zur Einführung von Stabilität. Wenn eine Meldung vom Client zum Server oder die Antwort des Servers verloren wor­ den ist, weiß der Client nicht, ob seine Anforderung akzep­ tiert worden ist oder nicht und so kann er nicht wissen, ob er sie wiederholen soll oder nicht. Dies ist aber ein sehr wichtiger Unterschied, denn wenn der Server die Anforderung nicht erhalten hat, kann der Spieler ewig auf die Antwort warten. Wenn andererseits der Spieler die Anforderung wieder­ holt und der Server sie doppelt erhält, könnte er beispiels­ weise den Einsatz zweimal setzen oder zwei neue Karten zie­ hen, ohne dies zu wollen.

Das AC hilft dieser Problematik ab. Mit dem AC kann der Ser­ ver Originalanforderungen von denen unterscheiden, die bei­ spielsweise von einem ungeduldigen Benutzer erzeugt wurden, der eine Schaltfläche mehrfach angeklickt hat, bevor er eine Bestätigung erhalten hat. Die vorliegende Erfindung benutzt einen Meldungsparameter, um dem Benutzer mitzuteilen, daß seine Anforderung mehrfach empfangen worden ist und nur die erste Anforderung akzeptiert worden ist.

Erfindungsgemäß können die Access Certificates auch als Zu­ gangskennung dienen. Nachdem ja auf dem Internet für jede Mitteilung vom Client zum Server eine neue Verbindung eröff­ net werden muß, muß sich der Client jedes Mal authentifizie­ ren, wenn er Kontakt mit dem Server aufnimmt. Es ist dem Be­ nutzer aber nicht zuzumuten, jedes Mal ein Passwort einzuge­ ben, wenn er einen Spielzug vornimmt.

Erfindungsgemäß wird daher vom Server an den Client eine Ant­ wort geschickt, die ein Access Certificate enthält, wenn der Benutzer erfolgreich eingeloggt hat. Das Access Certificate ist eine Folge von Bytes, die bestätigen, daß dieser Benutzer sich erfolgreich eingeloggt hat und daß er berechtigt ist, an den Spielen unter Benutzung eines bestimmten Kontos teilzu­ nehmen. Jedes AC gilt für einen bestimmten Zeitraum. Wenn es in diesem Zeitraum für mindestens ein Spiel benutzt worden ist, sendet das System dem Client ein neues, frisches AC. Auf diese Weise kann der Benutzer die ganze Zeit spielen, ohne sich erneut einzuloggen. Diese Möglichkeit läuft aber nach einer bestimmten Zeit, in der der Benutzer nicht gespielt, ab.

Es ist dabei zu beachten, daß das AC in einem gesicherten Übertragungsverfahren, beispielsweise mit der SSL-Technik übertragen werden muß, da jeder Dritte, der das AC abhört, auf Rechnung eines anderen spielen kann.

Da man durch Erraten eines gültigen AC's dieses zum Spielen verwenden könnte, muß das AC eine ausreichend lange Zufalls­ folge von Bytes umfassen, um "Brute force attacks" durch aus­ probieren entsprechend vieler Kombinationen sinnlos zu ma­ chen. Eine Kopie des AC wird in der Datenbank der Server ge­ speichert, so daß die Gültigkeit stets überprüft werden kann.

Ein Benutzer könnte zwar sein eigenes AC verwenden und damit Betrügereien versuchen. Die ist jedoch kein Problem, da die Lebensdauer eines AC's beschränkt ist und es auf jeden Fall nur für das eigene Konto des Benutzers verwendet werden kann.

Erfindungsgemäß enthält das AC folgende Daten:

• 1. Eine Zufallsfolge von Bytes
• 2. Einen Account Index, der es erlaubt, den Bereich der Da­ tenbank zu finden, der die Daten des Benutzers enthält. Dies kann die Kontonummer oder ein weniger auffälliger Schlüssel dafür sein.

Die erfindungsgemäße Aufteilung der Spielprogramme auf Client und Server ermöglicht also Spiele ohne permanente Rechner- Verbindung, insbesondere mit mehreren Teilnehmern gleichzei­ tig, die gegenseitig ihr Spiel beobachten können, einen ge­ ringeren Telekommunikationsverkehr und eine Sprachunabhängig­ keit des Servers, da alle Ausgaben die in Sprache erfolgen müssen, durch das Client-Programm durchgeführt werden können, während die Kommunikation mit dem Server nur durch einheitli­ che Codes erfolgt.

Claims (10)

1. Verfahren zur Durchführung von Spielen über das Internet mit mindestens einem Teilnehmer mit einem Rechner, wobei das Spiel selbst auf einem Server abläuft, jedoch die gesamte Animation und Benutzerschnittstelle durch ein Programm auf dem Rechner des Teilnehmers dargestellt wird, dadurch gekenn­ zeichnet, daß eine Datenübertragung zwischen Server und Rech­ ner des Teilnehmers nur auf Anforderung des Programms auf dem Rechner des Teilnehmers erfolgt.

2. Verfahren nach Anspruch 1 dadurch gekennzeichnet, daß An­ forderungen zur Datenübertragung immer dann erfolgen, wenn der Teilnehmer einen Spielzug durchführt, oder nach Ablauf einer vorgegebenen Zeit T seit der letzten Anforderung.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß das Programm auf dem Rechner des Teilnehmers jeder Anfor­ derung zur Datenübertragung einen Authentifizierungscode bei­ fügen muß.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß der Authentifizierungscode ursprünglich vom Server erzeugt und dem Rechner des Teilnehmers übermittelt wird.

5. Verfahren nach Anspruch 3 oder 4, dadurch gekennzeichnet, daß der Authentifizierungscode nur in verschlüsselter Form übertragen wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch ge­ kennzeichnet, daß jede Anforderung und jede Datenübertragung mit einer laufenden Nummer versehen ist.

7. Verfahren nach einem der Ansprüche 1 bis 6, mit mehreren Teilnehmern, dadurch gekennzeichnet, daß ein Teilnehmer, der nicht innerhalb einer vorgegebenen Zeit seine Spielzüge durchführt, aus dem Spiel mit mehreren Teilnehmern ausschei­ det, und für ihn allein ein weiteres Spiel auf dem Server er­ zeugt wird.

8. Verfahren nach einem der Ansprüche 1 bis 7 mit mehreren Teilnehmern, dadurch gekennzeichnet, daß dem Teilnehmer eine Zeitanzeige zur Verfügung gestellt wird, die anzeigt, wie lange er noch Zeit hat, seinen Spielzug durchzuführen, damit dieser noch beim gegenwärtigen Spiel vom Server berücksich­ tigt werden kann.

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daß zur Erzeugung der Zeitanzeige der Server bei jeder Datenübertra­ gung eine Information über die für den Spielzug verbleibende Zeit mitsendet, und das Programm auf dem Rechner des Teilneh­ mers die Zeitdauer zwischen Absendung der Anforderung und der Ankunft der Datenübertragung davon abzieht.

10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß verschiedene Zonen der Zeitanzeige erzeugt werden: eine erste Zone, in der die für den Spielzug verbleibende Zeit größer ist als die Zeitdauer zwischen Absendung der Anforderung und der Ankunft der Datenübertragung, eine zweite Zone, in der die für den Spielzug verbleibende Zeit größer ist als die halbe Zeitdauer zwischen Absendung der Anforderung und der Ankunft der Datenübertragung, und eine dritte Zone, in der die für den Spielzug verbleibende Zeit kleiner ist als die halbe Zeitdauer zwischen Absendung der Anforderung und der Ankunft der Datenübertragung.