WO2001031476A1

WO2001031476A1 - Method and system for providing a turn-based game

Info

Publication number: WO2001031476A1
Application number: PCT/AU2000/001320
Authority: WO
Inventors: Richard Anthony Crane; Wayne John Simmons; Benedict Byron Palmer
Original assignee: That Game Pty Ltd
Priority date: 1999-10-28
Filing date: 2000-10-27
Publication date: 2001-05-03
Also published as: AU1117401A; AUPQ373399A0

Abstract

A system for providing a game to be played between a plurality of players over a network, including: server means (20, 25) in communication with the network and adapted to receive first and second turn requests from respective first and second players and to send first and second turn information corresponding to the first and second turn requests to the second and first players, respectively; a server engine (10) in communication with the server means (20, 25) and adapted to process the first and second turn requests to become first and second turn information, whereby the first and second turn information enables the first and second players to send and receive subsequent turn requests directly to and from each other.

Description

METHOD AND SYSTEM FOR PROVIDING A TURN-BASED GAME

FIELD OF THE INVENTION

The present invention relates to a method and system for providing a turn-based game and, more particularly, a turn-based game to be played by communication over a network.

BACKGROUND OF THE INVENTION

It has been possible to play games, such as chess, over the Internet by simply logging into a remote server which is designed to facilitate the game. In the example of the chess game server, the connection may be established by the user by a telnet command and, once registered with the game server as a player, the user can engage in real-time games with other users who are concurrently logged on. The players do not communicate directly with one another but instead send all game moves and personal messages to the game server which sends them on to the relevant player or number of players. The quality of the graphical user interface (GUI) varies from mere ASCII characters to high resolution graphical representations of the playing board and the pieces, depending on the service provider.

The known systems for game playing over a remote server generally require that the players register with, and log into, the server in order to play. These systems do not provide for non-real-time playing and do not allow the players to communicate with each other outside of the server while playing the game.

SUMMARY OF THE INVENTION

The present invention provides a method of providing a game to be played between a plurality of players over a network, including the steps of: receiving at a server system in communication with the network first turn request information from a first player relating to a first turn request to begin the game with a second player; sending from the server system first turn information including the first turn request to the second player; receiving at the server system second turn request information from the second player relating to a second turn request; and sending from the server system second turn information including the second turn request to the first player; wherein the first and second turn information enables the first and second players to send and receive subsequent turn requests to and from each other without communicating with the server system.

The present invention further provides a system for providing a game to be played between a plurality of players over a network, including: server means (20,25) in communication with the network and adapted to receive first and second turn requests from respective first and second players and to send first and second turn information corresponding to the first and second turn requests to the second and first players, respectively; a server engine (10) in communication with the server means (20,25) and adapted to process the first and second turn requests to become first and second turn information, whereby the first and second turn information enables the first and second players to send and receive subsequent turn requests directly to and from each other.

The present invention further provides a method of facilitating a game to be played between a plurality of players over a network, including the steps of: receiving at a first player terminal in communication with the network first turn request information from a second player relating to a first turn request to begin the game with the second player; and sending from the first player terminal a second turn request to a game server in communication with the network, whereby in response to receiving the second turn request, the game server is adapted to send second turn information including the second turn request to the second player, the first and second turn information enabling the first and second players to send and receive subsequent turn requests directly to and from each other.

The present invention further provides a method of facilitating a game to be played between a plurality of players over a network, including the steps of: sending from a first player terminal in communication with the network a first turn request to begin the game with a second player to a game server in communication with the network, whereby in response to receiving the first turn request, the game server is adapted to send first turn information including the first turn request to the second player; and receiving at the first player terminal second turn information from the game server, the first and second turn information enabling the first and second players to send and receive subsequent turn requests directly to and from each other.

The present invention further provides a method of providing a turn-based game to a plurality of players over a network, including the steps of: receiving at a server system in communication with the network a first turn request from a first player for starting a game, the first turn request including first information relating to a second player and second information relating to a first turn to be played in the game; adding to the first turn request first advertising information; and forwarding the first turn request from the server system to the second player.

The present invention further provides a system for providing a turn-based game to a plurality of players over a network, including: server means (20,25) in communication with the network and adapted to receive a first move request from a first player of the plurality of players for starting a game, the first move request including first identification information relating to a second player and second information relating to a first move to be played in the game; server engine means (10) adapted to add to the first move request a game executable program for instantiation in a terminal of the second player and first advertising information and to then forward the first move request to the server means for delivery to the second player.

The present invention further provides a method of facilitating a game to be played between a plurality of players over a network, each player using a system having therein a game executable program, the method including the step of: sending to a second player a first communication from a first player including a first game packet representing a game move for execution by the game executable program in the system of the second player.

The present invention further provides a method of facilitating a game to be played between a plurality of players over a network, at least one player using a player terminal having therein a game executable program, the method including the step of: sending to a second player a first communication from a first player including a game executable program and a game move, for instantiating the game executable program in a player terminal of the second player and thereby enabling the second player to accept the game move.

The present invention further provides a game system for facilitating a game to be played between a plurality of players over a network, each player using a terminal having therein a game executable program, the game system including: server means (25) adapted to send to a second player first information corresponding to a first communication from a first player, the first information including a first game packet representing a game move for execution by the game executable program in the system of the second player.

The present invention further provides a system for facilitating a game to be played between a plurality of players over a network, at least one player using a player terminal having therein a game executable program, the method including the step of: server means (25) adapted to send to a second player a first communication from a first player including a game executable program and a game move, for instantiating the game executable program in a player terminal of the second player and thereby enabling the second player to accept the game move.

The present invention further provides a method of providing a turn-based game over a network, including the steps of: receiving at a server system in communication with the network first information from a first player, at least a part of the first information relating to a first move to be played in the turn-based game; forwarding second information from the server system to a second player, at least a part of the second information corresponding to the first move and a further part of the second information relating to advertising information to be displayed to the second player.

The present invention further provides a system for providing a turn-based game over a network, including: server means (20,25) adapted to receive first information from a first player, at least a part of the first information relating to a first move to be played in the turn-based game, and to forward second information to a second player, at least a part of the second information corresponding to the first move and a further part of the second information relating to advertising information to be displayed to the second player.

The present invention further provides a method of providing a turn-based game over a network, the steps including: receiving at a server system in communication with the network a first email communication including first information from a first player, the first information including game move information relating to a first move; sending from the server system a second email communication including second information to a second player, the second information including advertising information to be displayed to the second player and game move information relating to the first move, selected by the first player, to be played in the turn-based game. The present invention further provides a system for providing a turn-based game over a network, including: a game server in communication with the network adapted to receive a first email communication including first information from a first player, the first information including game move information relating to a first move selected by the first player to be played in the turn-based game, and to send a second email communication including second information to a second player, the second information including the game move information and advertising information to be displayed to the second player.

BRIEF DESCRIPTION OF THE DRAWINGS

A preferred embodiment of the present invention is hereinafter described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is an overall block diagram of an email game system of an embodiment of the present invention;

Figure 2 is a block diagram of a game server for use in the email game system;

Figure 3 is a flow diagram of a method of processing a received move request from a player, in accordance with an embodiment of the present invention;

Figure 4 is a first part of a flow diagram of a method of providing a turn-based game in accordance with an embodiment of the present invention;

Figure 5 is a second part of a flow diagram of a method of providing a turn-based game in accordance with an embodiment of the present invention; Figure 6 is a third part of a flow diagram of a method of providing a turn-based game in accordance with an embodiment of the present invention;

Figure 7 is a fourth part of a flow diagram of a method of providing a turn-based game in accordance with an embodiment of the present invention;

Figure 8 is an example of an interface generated and seen by a player when playing a game of chess using the system of an embodiment of the present invention;

Figure 9 is an example of an interface generated and seen by a player when playing a game of spades using the system of an embodiment of the present invention;

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

An email game system 2 shown in Figure 1 includes a game server 4 and players A and B. Initially, the moves of the game can only be played through the game server 4, but after each player has played a move, they are allowed to communicate their moves directly to one another, outside of the game server 4. This serves to make sure that the game server 4 can maintain version and integrity control over the games played and gather information about the demographics of the players and the number of times the games are played, while minimising the amount of traffic handled by the server. Importantly, routing the initial moves between the players allows for updated and demographically specific advertising information to be added to the communications which contain the game moves.

The game server 4 can facilitate the initiation of a large number of games between a large number of players simultaneously and can provide a wide variety of turn-based games for the players to choose from. Demographic information is obtained from players by inspecting the global top level domain names of the player email addresses and by asking them to fill out questionnaires once they have played a game a certain number of times.

The questionnaire, game executable code and game moves (in the form of game packets, described below) are all communicated over the network as email attachments in a known fashion.

Screens generated for the game are similar to the examples shown in Figures 8 and 9. In the example of the chess game shown in Figure 8, there is a window 90, which includes an advertising area 80 in a prominent position for showing an advertiser's banner advertisement and a text area 82 for allowing the players to communicate text messages to each other. The window 90 also includes buttons for executing game control commands, such as: a send button 83 for sending a move to the opposing player (along with a text message if present); a help button 84 for providing information on how to play the game; a new button 85 for starting a new game; an undo button 86 for taking back a move which the player has played but which has not yet been sent to the opposing player; an end button 87 for ending the game. The window 90 also has a playing area 81 and provides for the communication of instructional text 88, preferably adjacent the playing area 81.

The screen layout shown in Figure 9 is largely similar to that of Figure 8 and like features are designated by like numerals. Scoring games such as spades, unlike chess, will require the game to keep score of the relative points of the players, in which case the window 90 has some means of displaying the current player scores.

When the player wishes to begin a game, he or she need only run the executable code for the game as received from the server 4 and the game will show the game window 90. If the player has not run the code before, there is preferably a welcome message shown prior to showing the game window 90. To play the game, each player need only move a cursor to the relevant location on the screen, click on, or otherwise select, the desired playing option and, if a game piece 92 is to be moved, drag the game piece 92 to the desired location. If the player decides to send that move to the opponent, he or she must select the send command (for example, by clicking on the send button 83 or by selecting a menu option). If it is the first move, the game will prompt the player for the details of the prospective opponent before completing the send function. If it is the second move (i.e. the opponent's first move), the move will be routed via the game server 4 before being sent on to the initiating player. Otherwise the game move is sent directly to the opposing player by email in response to the send command.

As shown in Figure 2, the game server 4 includes a central game server engine 10 which communicates with a logging system 12, an incoming mail server 20, an email blocking database 21, a player database 22, a game database 23, an advertiser database 24 and an outgoing mail server 25.

When an incoming email 14 is sent from a game client (for example, player A or B), it is received by the incoming mail server 20. The whole email 14 is forwarded to the game server engine 10 to check the validity of the details contained within the email 14. If any part of the email 14 is invalid, corrupt or has otherwise been tampered with, it is rejected. The email 14 is then scanned to detect what type of request it contains. Valid requests include the following: a game move; a request for advertiser information; a request for help in playing a game; or a request for the latest version of a particular game.

If the email 14 is a game move, the email will contain a packet including the address information of each player, as well as information relating to the move to be played, which of a number of games is to be played, the version number of that game held by the player sending the email 14 and additional data relating to, for example, advertising or a questionnaire. The information in the email 14 which relates to the game is called the game packet. The packet structure is described below.

If the email 14 is a game move, the server engine 10 checks the email blocking database 21 to determine if either the sending email address or the receiver email address is valid.

Email addresses are added to the blocking database 21 either by user request (e.g. the user specifically requests not to be sent any game moves from prospective challengers), or the server engine 10 will automatically add the user's email address if they are deemed to have abused the service, for example by sending too many game moves during a small period of time, either to multiple recipients, or to a single recipient. If the sending player's email address is in the blocking database 21, he or she is not allowed to send emails through the game system, and the game packet will be rejected. If the receiving player's email address is in the blocking database 21, he or she is not allowed to receive emails from the game system, the received game packet is rejected and the sender is sent an email informing him or her of this action.

If the email 14 is other than a requested game move, the game server engine will pass the request on to a system administrator for his or her personal attention. Alternatively, if the email is invalid, this is communicated to the sender by the server engine 10. Every action the game server engine performs is recorded in the logging system 12 to generate system measurement statistics and so that a system administrator can monitor the system as a whole.

If the email 14 is valid and not blocked by the blocking database 21, the player database 22 is then queried to see if either the sender or the receiver of the packet has previously played a game using the system. Information stored in the player database 22 includes the player's email address and questionnaire information, if they have completed one, and the version number of the game the player was last sent for each game they have taken part in. If either of the opposing players does not exist in there, he or she is added to the player database 22 with default values for demographics and game tracking information. For example, the tracking information may include which version of the game the player is running, the number of games started by that player and the number of different opposing players they play with.

Once the player database 22 has been queried, the game database 23 is then queried to find the latest game version number that uses the received game packet. This is then matched with the information pulled from the player database 22. If the receiver was last sent an older version of the game, the latest (most recent) game is added to the game packet on an outgoing email 16. In this way, the system ensures that all users are always playing the latest version of the game. The player database 22 is updated with the version number of the game sent to the receiver, if a new game was sent with the outgoing email 16.

Next, the advertiser database 24 is queried to find the currently available advertising options that can be included in the outgoing game packet. The server engine 10 will choose one advertising option based on the demographics information read from the player database and the structure of the player's email address, and then insert the selected advertising information in the outgoing game packet. The advertising information may include, for example, text, graphics, sound, or other media, or a combination of these. The game packet is then prepared for transmission by the server engine 10 and sent out via the outgoing mail server 25 to the designated opponent. Figure 3 shows a game initiation process flow diagram as seen from the perspective of the game server 4. When a player initiates a game and sends the first move or turn request at step 300, the game server engine 10 checks the incoming email 14 at step 305 to see if the player has filled out a questionnaire. If so, the game server engine 10 then distributes the information in the questionnaire to the appropriate databases at step 310, for example the player database 22. The game server engine 10 checks the game packet at step 315 to confirm whether or not it is the first move to be played in the game and, if so, then checks at step 320 whether or not the intended opponent is listed in the player database 22. If the intended opponent is not listed, his or her email address will be added to the player database 22 at step 325, together with any other relevant information such as the player's alias. At step 330, the game server engine 10 will determine whether or not to attach a questionnaire to the game packet when sending it on to the intended recipient. The questionnaire may be sent out to players who have played a game using the system 2, for example, 30 or 40 times. If the game server engine 10 determines that it is appropriate to attach a questionnaire, it is attached as a data packet to the outgoing email 16 at step 335. Next, the version of the game with which the packet is associated is checked at step 340 and the packet is converted to correspond to the latest version of the game, if necessary, at step 345. Otherwise, the packet is sent to the intended recipient at step 360 in the outgoing email 16. If the recipient was registered on the player database 22 at step 325, or if the packet was converted at step 345, the packet is loaded with new advertising information at step 350 and the packet is attached to the latest version of the game executable program at step 355 and the outgoing email is sent to the intended recipient at step 360.

Figures 4 to 7 are interlocking flow diagrams (for example, "A" in Figure 4 connects to "A" in Figure 5, and "C" in Figures 5 and 6 connect to "C" in Figure 7) which show the process of the operation of the game from an overall system perspective. A prospective player may obtain a copy of the game executable code either by receiving it with the first move from a challenging player (step 405), or by downloading it from a web site (step 400). These methods of obtaining the game are merely examples however, and should not be read as an exclusive list of the ways in which a player may initially receive a game executable program.

Once a player has received a game at step 410 in Figure 4, he or she may execute the game at step 415 by double clicking on a game icon (as an attachment to an email or as stored in the computer system memory) or otherwise commanding the execution of the game executable program. The game executable code and game packets are represented by different, but associated, icons. The server engine 10 checks at step 420 whether the player playing the move has played any games using the system 2 before. If not, the game is flagged at step 425 to ask for the player's details, such as email address and alias, before sending off the move. If the player has played a game using the game system 2, then at step 430 the server engine 10 checks whether the player has played the particular game before. If not, then at step 435 the game register extension is installed in the user's system registry (so as to associate game packets having that file name extension with that game). If that game has been played before, then at step 440 the version of the game is checked for currency. If the received game is a new version, the new game is written to memory in place of the older version at step 450. If the player does not have a new version of the game, the game will ask whether the player wishes to install the new version or not. If the player chooses not to install the new version, the game will exit. Following steps 435 and 450, the game is flagged to have a packet attached thereto and the new game version number is stored at step 455. Next, at step 460, the user's computer system (as instructed by game software) checks whether a game packet is attached to the packet in which the executable is contained, and if so, checks whether a move has been played at step 465. If no move has been played, then at step 470 a game packet is loaded into dynamic memory so as to be ready to be played and the move is flagged as an executable move. Generally, after a game is run and has checked the version number and whether the player is a first- time player, the game then checks whether a game packet was attached to the end of the packet which contained the executable. If there is no game packet or there is a game packet and the move within the game packet has been played, the game continues as normal (to step 500) and waits for the player to start a new game. If there is a game packet attached to the executable, and the move has not been played, the game loads the packet (at step 470) from the end of the packet into memory. The game then sets a flag to indicate that a move, which was attached to the executable packet, is waiting to be played. This allows the game to initiate a parsing sequence (described below) whenever required. For example, the game may indicate to the player on the title screen that there is a move waiting to be played. The player then has the option of playing that move or starting a new game. When the player finally sends a move after the game has set the executable move flag at step 470, the flag will be removed.

As shown in Figure 6, a game may be started at step 600 by playing a move which was stored in memory or received by email. Each game has a unique filename and associated extension for the relevant game packets. This means that if a player double-clicks on a game packet, the game packet extension (recorded in the system's extension registry) will dictate which game executable code the game packet is associated with and the code for that game will automatically be executed, thereby beginning the game. This is analogous to, for example, launching a resident Microsoft Word application by double-clicking on a file having a ".doc" file extension. If the game move is initiated by double clicking the game packet at step 605, the game packet is loaded into memory at step 610, and at step

620 the game checks if there is a game already in progress. If there is no other game running, the game continues as normal at step 655 and proceeds to step 500. If there is already a game running, then the move data is sent to that game at step 635.

If a stored move (stored on disk or on the email server) is dragged onto the game at step 625, the game packet is loaded into dynamic memory reserved for the game executable at step 630. Following steps 630 and 635, the game checks whether to immediately parse the loaded game packet at step 640. If the game is not set to immediately parse the game packet, the game will inform the player at step 645 that there is a new move waiting and will wait at step 650 for an instruction to parse the game packet. If the game is set to immediately parse the packet, then at step 700 (shown in Figure 7) the game packet will be parsed. The parsing method is described below. At step 705, the game will check whether there is particular advertising information to be attached to the game packet. If not, then at step 715, the game loads a default advertisement into the packet. Otherwise the particular advertising information is loaded into the packet and the default advertising information is removed at step 710. The game then moves onto step 525, shown in Figure 5.

At step 500, the game checks if there is move data available in the form of a game packet. If the data is available, then at step 505, the game may ask the player whether to play the move. If the move data is not available, the game will show a title screen at step 515 and wait for the user to play a move. At step 515, the game checks whether the current player chose the move to be played. If yes, the game moves on to step 700. If not, then at step 520, the game is initiated and is set to immediately parse the next game move. At step 525, which follows step 710 or 715, the game is initialised to show the opponent's move and at step 530, the move is shown to the current player. At step 535, the game waits for the player to play a move, either in response to the opponent's move, or as a first move. Once the move is played and the player chooses to send it, the move is sent to the opponent at step 540. If the move was an executable move (checked at step 545), it is marked as having been played at step 550, otherwise, the move is mailed to the opponent at step 555, and the game returns to step 500 to wait until there is another move to be played.

The game is configured to allow the player to play a number of possible moves without actually sending that move to the opponent. For example, a player may "undo" any move prior to sending the move to the opponent. Further, it is possible for a player to include a text message to be sent with the move in the email.

While the game is running it is possible that a different game packet could be "dragged and dropped" onto the game or double clicked from either an email message or from the system memory. When this occurs, the game will present a message acknowledging the different move and asking the player to confirm the move (as the drag and drop / double click may have been accidental). This allows players to play many games with different opponents by dragging game moves, in the form of game packet icons, onto the game and sending them off in quick succession. Once the player has requested to send the move, and if it is a move attached to the executable, the game marks the game packet as having been played. This is done here to allow the player to choose when they wish to play the executable move. The game then uses TCP IP socket calls to post the game move and any messages to the intended recipient using the mail server entered by the player. If the receiving player is off-line or that player's email server cannot be contacted, the move is stored in the sending player's system for sending again later, for example, when the sending player next starts up his or her system. The player also has an options menu for changing any of their mail settings.

The game code is comprised primarily of two parts, the operating system code and the game-specific code. This is because all the games share common operating system requirements, so the operating system is only written once while the separate games are run over the top of it. This is transparent to the user as the system libraries and game- specific code are brought together at compile time. The tasks are divided between the operating system and game-specific code roughly as follows (although this may vary slightly from game to game).

Operating System

•Display »Input (for example from the mouse or keyboard)

•Interface with operating system

•Interface with email client packages

•Handling of advertisements

•Handling of Update executable programs 'Directing email traffic to the game server 4 when required

•Collection of demographics information

•Packet compression and extraction

•Common graphical interface elements (MOBS, buttons, panels, text boxes, slider bars, background redraw, etc) Game-Specific

•Game rules •Game cycle of play •In-game message ability •Game art and presentation •Displaying opposition moves •In-game animations •Links to websites •Score tracking

The game packets sent between the players each contain an identification header followed by any number of "hunks" of data. The header includes information such as the total hunk data size, sender/receiver email addresses and player aliases. Each hunk has a header which includes hunk identification information and data size. A game packet may contain multiple hunks of the same type. A hunk typically contains data for the game move, questionnaire or advertising data.

Hunks are broken up into game specific hunks and system hunks. This allows games to create their own hunks and add them to a packet for sending and parsing. An example of a system hunk is the advertising data and questionnaire, whereas a game move is an example of a game defined hunk.

Below is an example of definition code of a packet header and packet hunk of a packet:

Packet Header:-

HUNKID Id; //This is a four byte identification field.

U32 Size; //Four bytes (long) which represents the //total data size for the packet starting //after this header.

U32 Gameld; //Four byte Game Id to which this packet //belongs ie Chess, Spades. U32 GameVersion; //Four byte game version number.

BYTE Sender[MAX_PATH]; //260 bytes Senders Email address.

BYTE Recipient[MAX_PATH] 11260 bytes Receivers Email address

Packet Hunk:-

HUNKID Id; //This is a four byte hunk identification field.

U32 Size; //Data size for this hunk.

BYTE DATA[1 ]; //Hunk Data

File format-

Packet Header,

Packet Hunk,

.etc.

The packet is parsed in a two stage operation. The first operation is to process the hunk through the operating system parser of the user system. If the hunk is not processed or recognised by the operating system parser, the hunk is then passed onto a game-specific parser (defined by the game executable code) for the game to handle. For example, the operating system parser will recognise an executable file in the packet but will not recognise game move hunks.

The advertising information displayed with the game graphics may be such that an advertiser's universal resource locator (URL) is displayed so as to allow the player to connect directly to an advertiser's web site. Further, the advertising information may be in the format of a standard graphics information file (GIF) or may be in some other form of graphical representation, including an animation file.

In order to further incorporate the advertising features of the game, it may be possible to have the game pieces marked with a sponsors logo, for example, or to have the game entirely controlled by an advertising theme. It is also possible to brand the game by, for example, displaying an advertiser's logo in the background graphics of the game.

It is also possible to use the game system 2 in order to facilitate games involving more than two players, for example, a game analogous to Monopoly.

The game system 2 can provide for player privacy and does not distribute the player details, such as email addresses, to the advertisers or other third parties. However the demographics information collected from the players may be collated and a statistical demographics report may be available to advertisers. Also advantageously, the executable files are only ever sent by the game server 4 at the initial set-up of the game. This provides added security for the game system 2 and for the integrity of the game executable programs by not allowing the players to send executable files directly to each other. The game packets are configured only as data files attached to an email.

An additional feature of the game server 4 is that it includes a web server for hosting a web site where players may obtain information relating to the games, such as the newest version available, the rules of the game or new game products which may be launched in the future.

As a further feature of the game server 4, an associated web server specifically for registered advertisers may be provided in order to allow the advertisers to check the statistics of the player demographics.

Advantageously, the game system 2 does not require the players of the game to log onto a server in order to play, instead facilitating the initial set-up of the game and then allowing the players to communicate directly. In this way, network and server traffic is kept to a minimum. Prospective players do not need access to the world wide web as they can play over an email connection. Players can challenge anyone for whom they have an email address as there is no requirement to match up the players for simultaneous play on the server, as is common in known systems. In the preferred embodiments of the invention, the game executable program has a relatively small size, preferably in the order of 500 Kb, so as to not take up too much memory on the players' computer systems.

In an alternative embodiment, game moves can be sent and received using an instant messaging protocol such as TCP/IP. For this to happen, the game software for each player must be provided with the IP address of the other player through a central server, for example such as game server 4 or the commonly known instant messaging system "ICQ", by notifying or 'pinging' the central server as soon as a player comes online and has the game running. The server will then check whether the other player is also online (having already pinged the server if he or she is online) and, if so, will provide the IP addresses of the players to each other's games. The game will then offer to each player the option of playing with the instant messaging facility. If either player does not wish to do so, play continues as normal. The server is again pinged by the game software when a player goes offline or shuts down the game so that the server does not continue to record that player as being online.

The instant messaging works in the same way as the email communication but instead of addressing the outgoing emails from the mail server to the other players' email addresses (for the first two moves), the game packets are sent directly between the IP addresses of the players while they are online and the game is running. This instant messaging arrangement is facilitated by the operating system code of the game.

Additional methods of network communication, apart from those described above, may be employed in accordance with embodiments of the invention. For example, the present invention may be adapted to operate with the use of the wireless application protocol (WAP) for mobile phones or other hand-held wireless devices.

Those skilled in the art will appreciate that the invention described herein is susceptible to variations and modifications other than those specifically described. It is to be understood that the invention includes all such variations and modifications which fall within its spirit and scope. The invention also includes all the steps and features referred to or indicated in this specification, individually or collectively, and any and all combinations of any two or more of those steps or features.

Claims

1. A method of providing a game to be played between a plurality of players over a network, including the steps of: receiving at a server system in communication with the network first turn request information from a first player relating to a first turn request to begin the game with a second player; sending from the server system first turn information including the first turn request to the second player; receiving at the server system second turn request information from the second player relating to a second turn request; and sending from the server system second turn information including the second turn request to the first player; wherein the first and second turn information enables the first and second players to send and receive subsequent turn requests to and from each other without communicating with the server system.

2. The method of claim 1, wherein the first turn request information includes first identification information of the first player and the method further includes the steps of: determining from the first identification information whether a version of the game used by the first player is a current version; and if the version is not the current version, including in the second turn information the current version of the game for instantiation on a computer system of the first player.

3. The method of claim 1, wherein the first turn request information includes second identification information of the second player and the method further includes the steps of: determining from the second identification information whether the second player is a registered player; and if the second player is not a registered player, including in the first turn information a current version of the game for instantiation on a computer system of the second player.

4. The method of claim 1, wherein the first turn request information is received, and the first turn information is sent, by electronic mail.

5. The method of claim 4, wherein the second turn request information is received, and the second turn information is sent, by electronic mail.

6. The method of claim 1, further including the steps of: monitoring the number of times the first player begins a game with the second player or another player; and sending from the server system a player survey form to the first player once the number of times exceeds a predetermined number.

7. The method of claim 2, further including the step of determining from the first or second player identification information whether the first or second player has played the game previously.

8. The method of claim 7, wherein if the first or second player has not previously played the game, further including the step of establishing a respective first or second player record in a player database in communication with the server system for the first or second player in response to receiving the first or second turn request information, the first or second player record including an IP address, a game indicator representative of the game to be played, a game version indicator representative of the version of the game and a counter representative of the number of times the first or second player has played the game.

9. The method of claim 8, wherein if the first or second player has previously played the game, further including the steps of updating the game version indicator if necessary and incrementing the counter.

10. The method of claim 2, further including the step of displaying advertising information embedded in the second turn information to the first player according to the first identification information.

11. The method of claim 3, further including the step of displaying advertising information embedded in the first turn information to the second player according to the second identification information.

12. A system for providing a game to be played between a plurality of players over a network, including: server means (20,25) in communication with the network and adapted to receive first and second turn requests from respective first and second players and to send first and second turn information corresponding to the first and second turn requests to the second and first players, respectively; a server engine (10) in communication with the server means (20,25) and adapted to process the first and second turn requests to become first and second turn information, whereby the first and second turn information enables the first and second players to send and receive subsequent turn requests directly to and from each other.

13. The system of claim 12, wherein the first turn request includes game version information and the server engine (10) is further adapted to determine from the game version information whether a version of the game used by the first player is a current version and, if the version is not the current version, to include in the second turn information the current version of the game for instantiation on a computer system of the first player.

14. The system of claim 12, wherein the first turn request includes second player identification information and the server engine (10) is further adapted to communicate with a player database (22) to determine from the second player identification information whether the second player is a registered player, and if the second player is not a registered player, to include in the first turn information a current version of the game for instantiation on a computer system of the second player.

15. The system of claim 12, wherein the server means (20,25) is adapted to receive the first and second turn requests and to send the first and second turn information by electronic mail.

16. The system of claim 12, wherein the first turn request includes first player identification information and the server engine is adapted to update a first player record of the player database (22) in response to receiving the first turn request by incrementing a counter representing the number of times the first player begins a game with the second player or another player.

17. The system of claim 16, wherein the server means (25) is adapted to send a player survey form to the first player once the counter exceeds a predetermined number.

18. The system of claim 16, wherein the server engine (10) is further adapted to insert advertising information in the second turn information according to the first player identification information.

19. The system of claim 14, wherein the server engine (10) is further adapted to insert advertising information in the first turn information according to the second player identification information.

20. The system of claim 12, wherein the first and second turn requests include respective first and second game packets representing first and second game moves executable by the game.

21. The system of claim 14, wherein the first turn request includes first player identification information and wherein the server engine (10) is further adapted to generate a statistical report of player demographic information based on the first and second player identification information.

22. A method of facilitating a game to be played between a plurality of players over a network, including the steps of: receiving at a first player terminal in communication with the network first turn request information from a second player relating to a first turn request to begin the game with the second player; and sending from the first player terminal a second turn request to a game server in communication with the network, whereby in response to receiving the second turn request, the game server is adapted to send second turn information including the second turn request to the second player, the first and second turn information enabling the first and second players to send and receive subsequent turn requests directly to and from each other.

23. A method of facilitating a game to be played between a plurality of players over a network, including the steps of: sending from a first player terminal in communication with the network a first turn request to begin the game with a second player to a game server in communication with the network, whereby in response to receiving the first turn request, the game server is adapted to send first turn information including the first turn request to the second player; and receiving at the first player terminal second turn information from the game server, the first and second turn information enabling the first and second players to send and receive subsequent turn requests directly to and from each other.

24. A method of providing a turn-based game to a plurality of players over a network, including the steps of: receiving at a server system in communication with the network a first turn request from a first player for starting a game, the first turn request including first information relating to a second player and second information relating to a first turn to be played in the game; adding to the first turn request first advertising information; and forwarding the first turn request from the server system to the second player.

25. The method of claim 24, further including the step of displaying the first advertising information to the second player after the second player receives the first turn request.

26. The method of claim 25, further including the step of receiving from the second player a second turn request, the second turn request including second turn information relating to a second turn to be played in the game.

27. The method of claim 26, further including the steps of adding to the second turn request second advertising information; and forwarding to the first player the second turn request.

28. The method of claim 27, further including the step of displaying the second advertising information to the first player after the first player receives the second turn request.

29. The method of claim 28, further including the step of allowing the first and second players to send subsequent turn requests after the second turn request directly to each other over the network without communicating with the server system.

30. The method of any one of claims 26 to 29, wherein the first or second turn request includes a text message written by the first or second player for display to the second or first player, respectively.

31. A system for providing a turn-based game to a plurality of players over a network, including: server means (20,25) in communication with the network and adapted to receive a first move request from a first player of the plurality of players for starting a game, the first move request including first identification information relating to a second player and second information relating to a first move to be played in the game; server engine means (10) adapted to add to the first move request a game executable program for instantiation in a terminal of the second player and first advertising information and to then forward the first move request to the server means for delivery to the second player.

32. The system of claim 31, wherein the server means is further adapted to receive a second move request from the second player, the second move request including second turn information relating to a second turn to be played in the game.

33. The system of claim 32, wherein the server engine means is further adapted to add to the second turn request a game executable program for instantiation in a terminal of the first player and second advertising information and to then forward the second turn request to the server means for delivery to the first player.

34. The system of claim 33, wherein the forwarded first and second move requests enable the first and second players to send or receive subsequent turn requests after the second turn request to or from each other over the network without communicating with the server means.

35. The system of claim 33, wherein the first move request further includes second identification information relating to the first player and wherein the second advertising information is added to the second move request according to the second identification information.

36. The system of claim 33 or 35, wherein the first advertising information is added to the first move request according to the first identification information.

37. The system of claim 33, wherein the first or second turn request includes a text message for display to the second or first player, respectively.

38. A method of facilitating a game to be played between a plurality of players over a network, each player using a system having therein a game executable program, the method including the step of: sending to a second player a first communication from a first player including a first game packet representing a game move for execution by the game executable program in the system of the second player.

39. A method of facilitating a game to be played between a plurality of players over a network, at least one player using a player terminal having therein a game executable program, the method including the step of: sending to a second player a first communication from a first player including a game executable program and a game move, for instantiating the game executable program in a player terminal of the second player and thereby enabling the second player to accept the game move.

40. A game system for facilitating a game to be played between a plurality of players over a network, each player using a terminal having therein a game executable program, the game system including: server means (25) adapted to send to a second player first information corresponding to a first communication from a first player, the first information including a first game packet representing a game move for execution by the game executable program in the system of the second player.

41. A system for facilitating a game to be played between a plurality of players over a network, at least one player using a player terminal having therein a game executable program, the method including the step of: server means (25) adapted to send to a second player a first communication from a first player including a game executable program and a game move, for instantiating the game executable program in a player terminal of the second player and thereby enabling the second player to accept the game move.

42. A method of providing a turn-based game over a network, including the steps of: receiving at a server system in communication with the network first information from a first player, at least a part of the first information relating to a first move to be played in the turn-based game; forwarding second information from the server system to a second player, at least a part of the second information corresponding to the first move and a further part of the second information relating to advertising information to be displayed to the second player.

43. A system for providing a turn-based game over a network, including: server means (20,25) adapted to receive first information from a first player, at least a part of the first information relating to a first move to be played in the turn-based game, and to forward second information to a second player, at least a part of the second information corresponding to the first move and a further part of the second information relating to advertising information to be displayed to the second player.

44. A method of providing a turn-based game over a network, the steps including: receiving at a server system in communication with the network a first email communication including first information from a first player, the first information including game move information relating to a first move; sending from the server system a second email communication including second information to a second player, the second information including advertising information to be displayed to the second player and game move information relating to the first move, selected by the first player, to be played in the turn-based game.

45. A system for providing a turn-based game over a network, including: a game server in communication with the network adapted to receive a first email communication including first information from a first player, the first information including game move information relating to a first move selected by the first player to be played in the turn-based game, and to send a second email communication including second information to a second player, the second information including the game move information and advertising information to be displayed to the second player.