Communication techniques relating to betting
Related application data
[0001] This application claims priority from EP application 04027250.2, the contents of which are incorporated herein by reference.
Background of the invention
[0002] The invention relates to communication methods, equipment and software products which relate to betting. As used herein, betting means grading the ability of a participating player (or a team of players) to make predictions concerning events, such as goals, in a sports match. For the purposes of the present invention, it is not essential that good predictions are rewarded with real money, and in some applications mere honour may be considered sufficient reward.
[0003] In traditional betting systems, clients place their bets on paper forms, convey the forms to a betting operator who accepts a fee and registers the forms. The processing of paper forms is eliminated in online gaming systems in which participants place their bets via online terminals. [0004] A problem underlying the present invention lies in the fact that online betting is technically challenging to mobile terminals. For instance, maintaining a connection between the mobiie terminal and mobile network consumes the mobile terminal's battery and radio resources in the mobile network being used.
Brief description of the invention
[0005] An object of the present invention is to provide a method and an apparatus for implementing the method so as to alleviate the above problems. In other words, the invention aims at providing a technique which enables users of mobile terminals to participate in sports-related betting such that the consumption of resources is considerably reduced in comparison with constant online betting techniques. The object of the invention is achieved by methods, equipment and software products which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.
[0006] Straightforward techniques of going over from online betting to offline betting involve serious problems. For instance, the mobile terminal's onboard clock may be offset from the clock used in the sports event. Even if the mobile
terminal's onboard clock is synchronized with the clock of the mobile network, the clock used by the organizers may not be accurate. As a result, participants may be able to place bets even after the relevant event has occurred. [0007] According to an aspect of the invention, there is provided a method for betting which relates to a sports game via a client terminal. The method comprises: installing a game server and providing the game server with input means for inputting an identification in respect of each of a first plurality of relevant events in the sports game; - providing the game server with a server component of a betting software; maintaining a game clock and operationally coupling it with the game server for providing a relevant time in respect of each relevant event in the first plurality of relevant events; - defining a permissible time frame which precedes each relevant event in the first plurality of relevant events; installing a client component of the betting software to the client terminal; performing the following acts at least partially by the client component: - registering the client terminal with the game server; receiving a user-initiated prediction in respect of each of a second plurality of relevant events in the sports game, and for associating a time to each user-initiated prediction; transmitting the user-initiated predictions with their associated times to the game server; performing the following acts at least partially by the server component: accepting the client terminal's registration; receiving in manager-initiated identification in respect of each of a first plurality of relevant events in the sports game, and for associating a time to each relevant event in the first plurality of relevant events; receiving the user-initiated predictions with their associated times from the client terminal; and
checking, in respect of each user-initiated prediction, whether the user-initiated prediction was correct and occurred in the permissible time frame.
[0008] Another aspect of the invention relates to the game server configured for carrying out the game server functions of the above method. Yet another aspect of the invention relates to client software for a mobile terminal, such that the execution of the client software causes the mobile terminal to carry out the client functions of the above method. [0009] The invention is implemented in a client-server configuration. The server portion of the client-server configuration comprises game server equipment and server software. The (game) server equipment may be implemented as a conventional server computer which is operationally coupled to a mobile network for communicating with the mobile terminals of the participating players. Because one of the objects of the invention is to reduce the consumption of the mobile terminal's battery and radio resources, the invention does not require connections with a high-bandwidth or rapid response time. Instead, the invention can be implemented by using virtually any available communication technology, including but not limited to short message service (SMS) or wireless application protocol (WAP) technology, or via general packet radio service (GPRS).
[0010] The game server equipment is also operationally coupled to a manager terminal, such as a man-machine interface (MMI) of a telecommunication exchange or a laptop computer. By means of the manager terminal a manager enters an identification in respect of each relevant event in the sports game. In an illustrative but non-restricting implementation, the manager may tap a key on the manager terminal's keypad to signal an occurrence of a relevant event, such as a goal. Typical interpretations of relevant events include a goal, score, or touchdown, but as regards solving the technical problems underlying the invention, the nature of the relevant events is irrelevant. For instance, the relevant events may even include penalties, fights, injuries, equipment malfunctions, or any events which arouse spectator interest in such a degree as to justify betting. For the purposes of the present invention, the set of relevant events as determined by the manager are called a first plurality of relevant events. A second plurality of relevant events includes the events deemed relevant by the user of the mobile terminal. Naturally, each mobile terminal user has a separate second plurality of relevant events. In a
representative implementation, the mobile terminal user's betting result is based on the similarity (eg, correlation) between the first plurality and the second plurality. However, the details regarding computation of the betting result do not relate to technical problems and are largely omitted. [0011] An element of the inventive idea is evaluation of the mobile terminal user's ability to predict outcomes of relevant events in the game. In one representative implementation, each prediction may cost the user a fee, but if the prediction is successful, the user will be awarded a bonus. Or, the user may be awarded a bonus if his/her predictions are better than random guesses. Thus the concept of prediction is crucial. Thus there must be a permissible time frame which precedes each relevant event. The permissible time frame has a beginning and an end. Obviously, the time frame which precedes each relevant event, such as a goal, must end before the occurrence of the relevant event. Or, considering the fact that persons have a finite response time (between 0.5 and 1 seconds), a prediction entered a small fraction of a second after the relevant event might still be considered a prediction.
[0012] On the other hand, the permissible time frame which precedes each relevant event should have a definite beginning which does not precede the end of the time frame by too much. In other words, the permissible time frame should relate to a scenario in the game which precedes each relevant event. For instance, in a football game, the user may be awarded a bonus for correct predictions of goals if the predictions are made in a time frame which begins no more than 10 to 30 seconds before the goal and ends approximately 0 - 1 seconds before the goal.
[0013] One of the problems underlying the invention resides in the fact that the mobile terminal's clock may be offset in relation to the clock used for keeping time of the game. In addition, many games use a clock which is stopped when the game is stopped. Solving of the timing-reiated problems requires cooperation of many elements of the invention. For instance, the server is operationally coupled to a to a game clock which measures absolute time even if the game in question happens to use net time (ie, the clock is stopped when the game is stopped). The game clock measuring absolute time is synchronized with the mobile terminal's clock. There are many alternative ways to synchronize the mobile terminal's clock with the game clock. In one implementation, the client software downloaded to the mobile terminal receives
the time of the absolute game clock during registration and compares it with the mobile terminal's onboard clock. The difference is recorded, and the times of the user's predictions are corrected accordingly.
[0014] The client portion of the client-server configuration can be implemented by providing a conventional mobile terminal with an appropriate client software. The mobile terminal must be able to support downloadable software components.
Brief description of the drawings
[0015] In the following the invention will be described in greater detail by means of specific embodiments with reference to the attached drawings, in which:
Figure 1 shows an embodiment of a system in which the invention can be used;
Figures 2 - 4 illustrate an illustrative implementation of client registration and time synchronization;
Figure 5 is a flow chart illustrating the operation of the client software in the mobile terminal according to an illustrative embodiment of the invention; and
Figure 6 illustrates an internal structure of the game server database according to an embodiment of the invention.
Detailed description of specific embodiments
[0016] First, an embodiment of the invention relating to mobile terminals, will be described in connection with Figures 1 to 6. A brief description of other, less challenging embodiments will follow. [0017] Figure 1 shows an embodiment of a system in which the invention can be used. The two major portions of the inventive concept are the game server and the users' mobile terminals which are complemented with appropriate betting software.
[0018] In one illustrative embodiment, the game server software is a J2EE application and as a whole operates within a servlet container. For example, the servlet container may be an Apache Tomcat, but any servlet container that supports Java servlet technology may be used. The server database can be implemented by using mySQL database, but virtually any SQL database may be used. In the current configuration both the servlet container and the database server are located on the same machine.
[0019] The game client and game manager client can be implemented as J2ME applications. Mobility of the game client can be supported by wireless messaging (WMA) technology. The game clients may communicate with the game server using http requests. Game clients may receive game data from the server using some appropriate transfer format. In one implementation the game client's predictions are sent from the mobile terminal as a short message (SMS) which comprises a compilation of several predictions. The short message is sent to an SMS gateway (SMS GW) which is operationally coupled to the game server. The SMS gateway forwards each short message as a http request to the game server for further processing. The results are coded into the short message using an appropriate message format and are decoded by the server during the grading phase in which the participants' predictions are evaluated. Game manager results may be sent directly to the server via a http connection. No short messages need to be sent from the game manager. Instead the game manager results may be sent in a http post-request using an appropriate message format.
[0020] Once the game is over, the server sends the game results to the game clients. The game results may be sent as a plain text short message, for example. There may be a charge involved. [0021] In one implementation, the server has a web-based graphical user interface that can be used from any web browser. The use of the server requires http authentication before use.
[0022] The game results may be displayed on a web page. The game list and player score data may be retrieved directly from the database, without any special software. For instance, the game list and player score lists may be created by PHP programs, but other technologies may be used as well. These lists may be viewed and used through any web browsers. [0023] The server processes incoming http get and post requests and passes them on to the game if they are in proper format. The server startup procedures are performed automatically whenever the insider web application is first started. After startup the server will look for configuration file, and if one exists, the server reads applicable configuration parameters from it. The server will also look for valid a licence file, and if one exists, it will read the licence file parameters into the game. If the licence file is not found or it can't be properly read, the server will report an error.
[0024] After completion of the startup phase, the server is up and running and games can be created and played. Once the first http request is received the server will attempt to establish a database connection and outputs an error message if it fails. [0025] All public access to the server is processed by PublicServlet class. Public access functions are those related to playing the game: registering, receiving game data or a request for game download via a short message. The PublicServlet receives an http request of a proper format, processes them, inserts the data in the request to the database and outputs a response. [0026] All server management functions are processed by PrivateServlet which requires authentication before use. Authentication takes place on the servlet container level. The servlet takes in request for creation of games, teams, tournaments along with deletion requests, processes them and outputs responses. Generally the server manager will always require confirmation for actions that cause major changes in the database such as deleting something or adding a new game. The program will not make changes to the database until the action is confirmed.
[0027] Operation during a game is as follows. During a normal game, the game is first created by the server manager, ie, a person with access to server manager software. Once the game's start time is within a predefined time limit, such as 24 hours, the game will appear on the active games list sent by the PublicServlet on request to the game clients. Once that happens, the players can register to the game. At this time the game manager assigned to this game can also register to the game using the game manager client software. Registration of a game manager requires authentication, such as a correct combination of a login name and password. At any time a result message from a player can arrive from the SMS gateway. Whenever a result message arrives, the server will store its contents to the database if a registration entry can be found in the player_guesses tabie in the database. Once the correct result guesses from a game manager arrive to the server, they are also stored into the database and a scorehandler thread for this game is initiated. The scorehandler will wait for its assigned delay time to expire and will then proceed to grade the game. During grading, the software will compare the guesses sent by the player to the correct guesses sent by the manager and assign point according to the rules set for this game. The rules are set in a rule_set table in the database. Once all players who have sent
results have been graded the server will send result short messages to all registered players through the SMS gateway defined in the server configuration. The result short messages are formatted according to the message_set table associated with this game. [0028] Registration and synchronization take place as follows. When the server software is about to go online, it downloads a list of active games from the insider server. The client will contact the server address that is found in the j ad file of that particular installation unless the user has specifically changed the game server address from the startup menu of the game client. The getlist request sent to the server also contains checksum data of the game's image file. The checksum is used to determine if the client already has a particular image file. The game server will process the request and calculates its own checksum data and then responds by sending a list of games along with image data that it has determined that the client does not have. The image data sent in this stage contains all image data except the background image (that depends on the sport type of the game) and an optional advertisement image.
[0029] Figures 2 - 4 illustrate an illustrative implementation of client registration and time synchronization. In one implementation, the time synchronization is implemented as follows. A game timer, which is maintained by the client software in the mobile terminal, obtains its time from a system clock maintained by the game server and modifies the time based on the game's start time. The client's start time is the successful completion time of the registration process (ie, a "registration successful" message received). The timer will count forward from this moment (starting from zero) and bet times are saved. The bet times may be indicated using a resolution of one second, for example.
[0030] On registration the client software causes the mobile terminal to send its system time to server. The mobile terminal's time will be used to calculate a time difference between the client and the server for the purposes of a synchronization check. The time difference is not necessarily used in the actual grading process, however. Instead, the time difference is saved to make sure the mobile terminal's clock has not been adjusted while the execution of the client software has been suspended. The server will record the time when the client's registration with the game is completed. This time will be called the client's game start time. The game start time is based on the server's system
time and is used to calculate if a bet was made in the specified time frame before a game manager marked a game event. Therefore delays in forming the connection and sending the registration request will not affect the synchronization of bet times, but lag in delivering the response to the player may cause problems. However, delays in connection establishment do affect the synchronization check process.
[0031] Figure 4 shows a synchronization check process. If the mobile terminal user suspends the execution of the client software and returns while the game is still active, it is beneficial to perform a synchronization check. The synchronization check helps to ensure that the mobile terminal's clock has not been adjusted while the execution of the client software was suspended, which would make cheating possible. In the synchronization check the client sends its system time to the server. This system time is used to calculate the time difference between client and server. If the time difference has changed more than by some predetermined margin, the synchronization check fails and the client is not allowed to continue playing.
[0032] In one implementation, the client software raises an error if it detects any sudden changes in the mobile terminal's time value. This feature prevents cheating by adjusting the mobile terminal's clock while the game is running. [0033] Figure 5 is a flow chart illustrating the operation of the client software in the mobile terminal according to an illustrative embodiment of the invention. [0034] First the client software checks if an active and valid game can be found from a record store. If yes, the client software will attempt to perform a synchronization check operation (if enabled), with the server to confirm that the mobile terminal's clock has not been manipulated. If the check succeeds (or it is disabled), the client software initializes a game timer and proceeds to display a game screen. Alternatively, if a game was not found or it had expired, the client software will display a welcome screen. After the mobile terminal user presses a "continue" button, the game software proceeds to download a list of active games from the server.
[0035] In the game list request, the client software will also send a checksum computed over any previously downloaded images. If the sent checksum data matches with checksum on the server, an image will not be sent and the image stored on the client is used. If valid games are found, the game list is returned along with any image data that didn't match the checksum data.
[0036] Once the user has selected a game for registration, the registration screen is displayed. The user should then enter his/her identification data, such as a name and/or telephone number, or the like. An actual registration request is not sent before the user continues from this screen. Once the registration request is sent, the client will receive game-specific data (such as game name and duration) along with game-specific images (such as the background image). If the registration is successful, the game timer will start. [0037] The client software preferably comprises a thread or process which constantly checks, while the game is active, if the game has expired or if the mobile terminal's time has suddenly changed by more than some predetermined margin (typically much less than one second). An abrupt change in the mobile terminal's time indicates a possible cheating attempt. [0038] In one implementation, the registration process grants the user a predetermined number of betting opportunities, or bets. Every time a bet is made, the game will check the remaining number of bets. Once the counter reaches zero, the timer will be disabled and an attempt to send a short message is made. If the short message can be sent successfully, any attempts to send further messages during exit are disabled. Any bets are also written to the record store to preserve game data in case of power loss or the user exiting the program.
[0039] If any problems occur, the game will proceed to an exit screen and set a proper exit message to the user indicating what is going on. A flag will also be set to disable sending short messages if necessary. If not, an attempt to send a short message will be made if any bets are in record. [0040] The user can also choose to forfeit the game in which case game data is erased and the game returns to the welcoming screen where the user can choose to exit or register again.
[0041] Finally, before quitting the program all relevant data are written into the record store in case the game is resumed. The user can also quit the program at any stage using the exiting capabilities provided by the operating system. In this case, the data is also saved into the record store.
[0042] Operation of the game manager software is as follows. The program flow of the game manager is analogous to the program flow of the game client, apart from the fact that the game manager does not perform the synchronization check operation if a game is resumed. Thus the operation is analogous to the client operation assuming that the synchronization check is
always successful. The game manager is usually trusted and no cheat detection is carried out during the game. The game manager will not send a result message automatically and the game manager will have to manually choose the 'send results' option from the menu to send the game data to server. There is no limit to the number of game events that can be made. The game manager can also freely adjust the previous game event after it has been recorded.
[0043] Figure 6 illustrates the internal structure of the game server database according to an embodiment of the invention. The major tables shown in Figure 6 are as follows. The acronym rap stands for "real action play" and can be ignored for the purposes of this technical description. Table rap_match contains data regarding the sports matches and their properties. Each match is associated with a single rule_set table entry that determines the grading rules and a single message_set entry that determines the format of the result message being sent. Table rap_player contains information about players who have registered to a match. This table does not contain information relevant to any single match. Game managers have also an entry in rap_player table. Game managers are marked in ismanager column. Table rap_match_team contains information about groups of rap players playing as a team. In table piayer_guesses, the rows contain ail guesses made by a player for a particular match and information relevant to them: e.g. synchronization data and score given for this guess after grading. Each guess entry is associated with a single match and a single player. Results sent by game managers are also treated as player guesses, but are not graded. Table rule_set contains rule information used in grading. Each match has a single rule set attached to it. Table sport contains information about various sports. Sport type (idsport) determines what background image is sent to the game client on registration. Table match__team contains information about the match teams playing against each other in a football/hockey etc. match. Table tournament contains information about various tournaments. Table notification contains entries for players and rap teams who would like to be informed about particular future games. Table message_set contains game result message texts. The software will replace all %n with the player's name, %s with score and %r with rank. Table donation contains information about donations made during a match. Table donation_organization contains a list of organizations that donations can be made to.
[0044] In some implementations of the invention, payment may be arranged by adding the betting-related charges to the mobile terminal's telephone bill. In some other implementations, radio frequency identification (RFID) tags may be used as an alternative payment method. A typical RFID tag includes an antenna and a silicon chip containing modulation circuits, control logic and non-volatile memory. The silicon chip derives electrical power from radio signals received by the antenna or from a battery, and is able to exchange data with a RFID tag reader, in this case the wireless communication device such as mobile phone or remote control, etc. by demodulating and modulating radio signals. The wireless device coupled to the RFID tag can read and write from and to the memory of the RFID tag using radio signal transmission. [0045] Betting-related information such as the name of the participant, year of birth, type of the sport match, number of allowed bets, and duration of validity, the price paid, etc. may be stored in the RFID tag as a unique serial number at the time of purchase.
[0046] An RFID-based solution comprises a tag reader software in the mobile phone when activated, emits a short-range radio signal that powers up the tag, enabling the data on the tag to be read. Each tag contains a specific serial number that the phone links with initiation of the betting service. The service can be initiated simply by touching the participant's mobile terminal with the RFID tag.
[0047] Separate sets of identical RFID tags can be purchased from licensed representatives at different prices for separate sports and/or separate modes of betting. To control legitimacy of the betting process performed during the betting process, separate RFID tags can be purchased for under-aged participants and adult participants, such that instead of money, under-aged participants may be awarded points which can be used in further betting. [0048] Radio frequency identification (RFID) enabled mobile phones in the market today e.g. Nokia 5140 RFID compatible phone is most suitable for these kinds of solutions in cases where payments as well as the legitimacy of the process e.g. age of participants are controlled through sales of RFID tags. Without the RFID tag betting will not be activated.
[0049] The contents of each RFID betting-tag is loaded only once to the phone. After that, the tag may be disabled. RFID-based betting tags may have different prices based on number of bets allowed, maximum amount allowed for each bet, type of the sport match, number of matches valid, or a specific
important athletic event, or the whole season for all matches in a specific sport, etc.
[0050] The above description of specific embodiments of the invention were based on the assumption that the client terminal is a mobile terminal. Technically, this is the most challenging embodiment, considering the problems relating to consumption of various resources (terminal battery, network bandwidth, etc.) and the problems relating to time synchronization. [0051] When this invention was made, speculations were made concerning various technologies for interactive television, particularly as regards transferral of uplink information, ie, information originating at the end-user end. Despite the speculations, no commercial implementations exist. But assuming that viable uplink technologies will be implemented, it is possible to use an interactive television as a transfer medium for the invention. If transferral of the uplink information takes place via a wired connection, such as the Internet, one can see that some of the problems cited in the background section of this application do not exist. For instance, if the interactive television set is mains- operated, its battery consumption cannot be a problem, whereby a connection between the client terminal (the interactive television set) and the game server can be maintained continuously. Accordingly, in such a case it will no longer be necessary to save the terminal's battery and network resources by compiling the user's predictions to a single message (or a small number of messages). Instead, the user's predictions can be sent in real-time, whereby the clock- synchronization problem is eliminated automatically. Any uplink transmission to the game server may experience a delay with a magnitude of approximately one second, but such delays are relative stable and can be compensated for, if deemed necessary. In other words, the invention which was made for existing mobile network technologies can be used with emerging technologies, such as interactive television, when such technologies will be installed in practice.
Betting schemes and related business techniques [0052] After solving the various technical problems, it is apparent that the invention can be used to implement a wide variety of different betting schemes and related business techniques.
[0053] In one implementation, all times within each permissible time frame are considered equivalent, as far as grading the predictions is concerned. In other words, all that matters is whether the participant made a correct prediction in
the permissible time frame. In an alternative implementation, the beginning of each permissible time frame has a higher weight than its end. This is because it is much more difficult to predict, say, a goal 10 seconds in advance than 1 second in advance. In one implementation, the permissible time frame does not end abruptly but the weight of the user's prediction gradually reaches zero. [0054] In some implementations, participants (users participating in betting) are arranged as teams, and the teams compete against each other in their combined ability to make predictions. [0055] In yet further implementations, the game manager server also maintains a list of organizations to which the participants can make donations. Any participant may choose to make a donation to an organization. The game server may send the client terminal a list of organizations to which donations can be made. Donations can be made at the time of registering to a sports game or at the time of exiting the game or at any time during the game. The amount of the donations can be charged to the user's telephone bill. Or, if the user has recently won a bet, some or all of his/her winnings can be transferred as a donation to a selected organization.
[0056] It is readily apparent to a person skilled in the art that the above descriptions of specific embodiments are intended to illustrate rather than restrict the invention. The inventive concept can be implemented in various ways, without departing from the scope of the invention as defined by the attached claims. For instance, the above description cited the use of short messages as a data transfer medium, but it is immediately apparent that virtually any other data transfer mechanism can be used.