EP1839258A4

EP1839258A4 - Method, system and computer program product for producing, offering and executing recreational application programs

Info

Publication number: EP1839258A4
Application number: EP05817479A
Authority: EP
Inventors: Timo D Haemaelaeinen; Marko Haennikaeinen
Original assignee: ADVANT GAMES Ltd Oy
Current assignee: ADVANT GAMES OY LTD
Priority date: 2004-12-02
Filing date: 2005-11-30
Publication date: 2009-07-01
Also published as: US20080214303A1; NO20072760L; WO2006058957A1; FI119858B; FI20041563A0; EP1839258A1

Abstract

Recreational application programs are offered for execution through players' terminals. Said recreational application programs involve at least one of playing and gambling. The system comprises an event model (301), which is a process adapted to represent a sequence of subevents in a target event (202, 203, 204) in real time. The system is adapted to offer the execution of a recreational application program through players' terminals as a response to an incident taking place in said event model (301).

Description

Method, system and computer program product for producing, offering and executing recreational application programs

The invention concerns generally the technology of producing and executing application programs that have recreational value and involve playing and/or gambling. Especially the invention involves enabling swift and systematic generation of new recreational applications of said kind, as well as swift and systematic continuing development of existing applications.

A typical prior art recreational application program that involves a betting or gambling aspect is schematically represented in fig. 1. A betting engine program 101 comprises the means for executing the program proper. It receives registration information and bets from players and delivers responses to players through a player interface 102. Information about games is stored in a games database 103, and about the odds of possible outcomes of such games in an odds database 104 (which may be the same as the games database 103). User accounts for registered players exist in an accounts database 105, and the bets played by the players are stored in a bets database 106 (which may be the same as the accounts database 105). The game organiser can start and end games, set and change the odds, and otherwise affect the operation of the recreational application program through an operator interface 107.

Playing a game of chance using the program architecture shown in fig. 1 involves for example the following steps. A game organiser designs the rules of the game and the machine-readable instructions for following the rules and stores them in the games database 103. The game organiser also designs a user interface screen that informs a player about the games and its rules, and gives instructions about how to place a bet. This user interface screen is stored as a part of the user interface 102. When a player logs in, he follows the instructions and places a bet. Log data about the player's actions are stored in the accounts database 105, and the price of the bet is deducted from the player's account. The bet as such is stored in the bets database 106. On the basis of the distribution of all bets stored for a particular game the betting engine 101 repeatedly calculates the odds and updates them in the odds database 104. The outcome of the game becomes known either internally within the betting engine (e.g. if the game was a virtual process such as the electronic drawing of lots) or externally so that the game organiser feeds it in through the operator interface 107. The betting engine selects the winning bets, calculates their winnings and credits the accounts of the players that had placed them. It may spontaneously announce the results to the players through the user interface 102.

The drawback of such a prior art arrangement is its inflexibility. Basically each game has to be designed and programmed starting from scratch. Basic routines of the betting engine can be reused, if a "new game" is nothing more than a new betting subject, but this sets tight limitations to how the games can be formulated. Especially it would be difficult to realise fast, dynamically adaptive gaming opportuni- ties using such a prior art arrangement.

An objective of the present invention is to present a method and a system for systematically generating and developing gaming applications. An additional objective of the invention is to present a method and a system for generating and develop- ing dynamically adaptive gaming applications. A further objective of the invention is to present a method and a system for allowing the characteristics of a gaming application to be dynamically changed on the basis of unconsciously given input from a player. A yet another objective of the invention is to present a method and a system that would allow simulating and verifying a systematically generated new gaming application in a realistic and/or futuristic environment.

The objects of the invention are achieved by executing an event model in real time in order to represent the sequence of subevents in a target event, like a soccer game, car race or some other interesting event where a number of unpredictable minor subevents may occur. Simultaneously a gaming model is executed, which observes the developments that take place in the event model and looks for incidents that could constitute a gaming event. Additionally a player model can be parallelly involved, representing the actions of one or more players, which may be taken into account in the way in which the gaming events are made available for playing.

A method according to the invention is characterised by the features recited in the characterising part of the independent claim directed to a method.

The invention applies also to a system, which is characterised by the features recited in the characterising part of the independent claim directed to a system. The invention applies also to a method for synthesizing a recreational application program for execution through players' terminals, with characteristic features as recited in the characterising part of the independent claim directed to such a method.

Additionally the invention applies to a computer program product for offering recreational application programs for execution through players' terminals, with characteristic features as recited in the characterising part of the independent claim directed to such a computer program product.

According to a first aspect of the invention there is a computer-executable process that can be designated as the event model. It is a systematic representation of a sequence of subevents that are likely to occur and that together constitute a larger scale event that is likely to raise the interest of a large group of players. However, beforehand it is not known exactly, what subevents will occur in which order in said larger scale event. The operation of the event model can be easily understood by considering the event model as a state machine, although the actual implementation thereof does not need to comprise one. According to the state machine consideration, pieces of input information obtained from the event trigger transitions between states in the event model. The actual event may exist in the real world, like a sports event, election or other events of general interest. Alternatively even the actual event may have partly or completely virtual existence, like a computer game played by a number of players through a network or a fully computer-simulated sequence of subevents with no direct human interaction. In the last-mentioned case the implementation of the event model may be even integrated to the virtual event.

According to a second aspect of the invention there is another computer- executable process that can be designated as the gaming model. Its task is to run simultaneously with the event model, observe what happens in the event model and use its observations to consider, what kinds of games could be matched to the recent developments in the event model. For example, if the event model enters a state according to which a certain subevent is likely to occur in the immediate future, such subevent having two or more well-defined possible outcomes, the gam- ing model may respond by launching a game in which players may place bets on all possible outcomes of the subevent during the short time when the actual outcome is still unknown. According to a third aspect of the invention there is yet another computer- executable process that can be designated as the player model. Various tasks can be given to the player model. According to one approach, a task of the player model is to predict, how a typical player will react to a certain subevent that occurs in an event. Such a prediction may then be used to e.g. affect the way in which games are made available to the players. Properly applying a player model may assist in enhancing the emotional responsiveness of the gaming system to the players.

The event model, gaming model and player model may each have a library of routines at their disposal. An event model may be a combination of event model routines, stored in an event models library and tailored to match a certain specific event. A gaming model may use a library of possible gaming schemes, which it matches to the subevents that materialise in the event model. A player model may refer to a library of statistically compiled descriptions of how players have been known to react to certain situations.

For linking together the models explained above, a coordinating entity is needed. In this patent application we designate such a coordinating entity as the imple- menting technologies engine. It too may have the appearance of a state machine, although also other kinds of implementations are possible. The implementing technologies engine typically comprises e.g. interfacing routines for linking together the operation of various mutually different devices and operating systems. It may also comprise supervisory routines for ensuring smooth operation, e.g. by preventing contradictory situations where a rapidly deployed game would erroneously be made available for playing with terminals the use of which involve unac- ceptably long delays. Most advantageously the implementing technologies engine has access to an implementing technologies library where various previously created routines have been preparatorily stored.

For allowing a game organiser to exercise control over the operation of the system, it most advantageously comprises also a control interface.

The novel features which are considered as characteristic of the invention are set forth in particular in the appended claims. The invention itself, however, both as to its construction and its method of operation, together with additional objects and advantages thereof, will be best understood from the following description of specific embodiments when read in connection with the accompanying drawings. The exemplary embodiments of the invention presented in this patent application are not to be interpreted to pose limitations to the applicability of the appended claims. The verb "to comprise" is used in this patent application as an open limita- tion that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated.

Fig. 1 illustrates a prior art solution for a recreational application program, fig. 2 illustrates certain concepts related to the invention, fig. 3 illustrates an exemplary lottery part with connections, fig. 4 illustrates exemplary ways of obtaining inputs from a real-life event, fig. 5 illustrates an exemplary event model state machine, fig. 6 illustrates another exemplary event model state machine, fig. 7 illustrates an exemplary gaming model state machine, fig. 8 illustrates another feature of an exemplary gaming model state machine, fig. 9a illustrates an aspect of an exemplary player model state machine, fig. 9b illustrates another aspect of an exemplary player model state machine fig. 10 illustrates schematically an aspect of an implementing technologies engine, fig. 11 illustrates schematically the systematic development and synthesis of a new lottery and fig. 12 illustrates schematically a composition of a gaming technology server.

CONCEPTS AND DESIGNATIONS

Fig. 2 illustrates the use of certain concepts and designations that will be used in this description. A lottery 201 is a multi-user gaming entity which offers a large number of players the possibility of taking part in a process where placing stakes in favour of the possible outcomes of certain well-defined future subevents may result in earning winnings. Said well-defined future subevents take place in a virtual event 202, semivirtual event 203 and/or a real-life event 204. Of these the vir- tual event 202 is typically a process executed in a computer or a number of computers, where simulated subevents take place in a virtual environment. A non- limiting example of a virtual event is a simulated car race, in which "cars" only exist as computational processes in the memory of a computer, and their propagation through a "track" is controlled by virtual "drivers" that also themselves are computational processes. A semivirtual event 203 is a computer-executed process that depends directly on the way in which a number of users utilise their computer terminals: for example a virtual car race where the "drivers" are computer users that give control commands in essentially real time by using input means such as keypads, joysticks or steering wheel and pedal sets. The real-life event 204 is typically a sports event, a musical contest, an election or other real-life occasion that raises general interest and involves subevents that may occur arbitrarily (like corners in a soccer game) and may or may not lead to certain results (like scoring a goal).

What an individual player sees is the game interface 205 of a game 206. The game 206 as such can be seen as a subset of the whole concept of lottery 201. It should be noted that the designation "player" means in this patent application the players that participate in a lottery, while the persons the movements and actions of which constitute a real-life event 204 in sports (like the members of a soccer team) are designated as "sportsmen". The general designation "third party agents" in fig. 2 encompasses parties that have an effect on the outcome of an event but do not participate in a lottery. A non-limiting list of exemplary third party agents includes sportsmen, election candidates and computer users that do not themselves place stakes but only act e.g. as drivers of a semivirtual car race, are illustrated at the lower part of fig. 2.

The entities illustrated in fig. 2 have mutual interactions. Starting from the right, it is usually imperative that a lottery 201 must not have any effect on how a real-life event 204 is proceeding; on the other hand the lottery 201 needs some input 211 from the real-life event, like the information that a goal was scored. Similarly a virtual event 202 and a semivirtual event 203 give input 212 and 213 to the lottery 201 , concerning the proceeding of subevents: e.g. what were the lap times of the virtual cars or where and when did a collision occur. In the case of virtual and semivirtual events it may be acceptable to let the lottery 201 have influence 214 or 215 over the event. As an example, the relative number of players from different countries that have placed bets in advance for a car race may decide, which country's racing track will be selected for the race, or the players may vote, how difficult the track should be.

Continuous bi-directional exchange of information 216 between a player's game and the semivirtual event 203 is essential at least concerning those occasions where the player himself is also a participant in the semivirtual event, e.g. drives a virtual car. Even if the player only participated as a "spectator" in a virtual event 202, it is usually advantageous to arrange for a bi-directional exchange of information 217, in order to convey real-time information from the virtual event to the player's terminal, and to let the player give direct inputs like cheering to the virtual event. If only one direction is selected for conveying information, it is most naturally means conveying information from the event to the player's terminal.

When a player is playing a game 206, information 218 about his actions is conveyed to the lottery 201 which records them e.g. as announcing the player's inten- tion to place stakes. The return direction information 219 from the lottery 201 to the game 206 includes (but is not limited to) declaring new games, distributing game-related information like odds, and announcing results of unravelled subevents as well as the winnings earned by properly placed bets.

OVERVIEW OF LOTTERY PART

Fig. 3 illustrates an advantageous architecture for a lottery part 201. In the following we describe its parts and the tasks of the various parts as well as their interac- tions on a general level. A more detailed description of the most important parts will follow later in this text.

As an important part the lottery part 201 comprises an event model 301 , which is a real-time process designed to represent the sequence of subevents that will take place in a virtual, semivirtual or real-life event. The invention is not particularly limiting concerning the resolution or granularity at which the developments of an event are modelled in the event model 301 ; this subject will be discussed in more detail later.

Another section of the lottery part 201 is a gaming model 302. The task of a gaming model 302 is to follow the developments that take place in the event model 301 and to react appropriately. Since the event model 301 is a machine-executable representation of what is actually taking place in an event, we may say that the gaming model 302 observes the course of said event through the "filter" or sys- tematic representation offered by the event model 301. The advantage gained therethrough is that the gaming model 302 may use certain predefined, systematic criteria to determine, whether there happens something in the event model 301 that could become the subject of a game. The lottery part 201 also comprises a player model 303, the task of which is at least one of collecting information and producing predictions about the behaviour of players. The player model 303 may provide means for estimating and/or control- ling the emotional responsiveness of a game offered to players. This means that based on knowledge about how player(s) will react to certain game presentation, time schedule or other feature of a game, it becomes possible to optimise the way in which games are formulated for maximising the enjoyment experienced by players. Even if the player model 303 only collects information and does not ac- tively produce predictions of player behaviour or changes to actual games, such collected information can be later used for e.g. changing the criteria that the gaming model 202 uses in evaluating the appropriateness of certain game routines to certain situations that occur in an event model. Including a player model in the lottery part 201 is not obligatory, if it is not considered necessary to make operation dependent on player behaviour or to collect information about such behaviour.

An implementing technologies engine 304 links together the operation of the event model 301 , the gaming model 302 and the player model 303. The implementing technologies engine 304 comprises the necessary interfaces for arranging the communication of information between the different models. It will also be responsible for arranging the communication of information between the models and the outside world, including but not being limited to receiving information from events, transmitting information to virtual and semivirtual events, and exchanging information with the players' terminals. Most advantageously the event model 301 , the gaming model 302 and the player model 303 are all completely independent of any terminal or network technology, leaving the implementing technologies engine 304 responsible e.g. for translations between the standardised communication protocols applied within the lottery part 201 and the various communication protocols applied in the outside world.

For offering a game organiser the possibility of controlling the operation of the lottery part 201 there is a control interface 305, which has bi-directional connections to all other sections of the lottery part 201.

Each of the event model 301 , the gaming model 302, the player model 303 and implementing technology engine 304 have couplings with their respective databases or libraries. These are the event models library 311 , the gaming models Ii- brary 312, the player models library 313 and the implementing technologies library 314 respectively.

The utilisation of the libraries can be illustrated with the following, non-limiting ex- ample. We may assume, for the case of example only, that the event is a soccer match. In order to represent the event in the lottery part 201 there is used, as an event model 301 , a state machine that proceeds from one state to another according to inputs received from the actual event. It is impossible to say beforehand, how many subevents (like e.g. corners and penalty kicks) there will be in the event and when they will occur. Therefore there exists, in the event models library 311 , readily made component routines that are not fixed parts of the event model 301 but can be taken into use immediately when a certain triggering condition is fulfilled. For example, when information arrives that a penalty kick has been awarded, the event model 301 reads from the event models library 311 the appro- priate component routine and starts executing it, entering first a "penalty kick pending" state where certain attributes announce, which team has got the penalty and for what reason. After the penalty kick has been delivered, the event model returns (through a "read result" action) to a normal state and stows the component routine for possible later use.

In the example described above, information about the event model entering the "penalty kick pending" state would be delivered to the gaming model 302, which would recognise this situation as one for which a certain game could be set up. It consults the gaming models library 312 to obtain a component routine for setting up a quick betting game, in which the players must guess the result of the penalty kick situation. A player model 303 could react to the information about the penalty kick pending by noting the remaining playing time in the event and reading from the player models library 313, what is the probable reaction of players to a penalty kick at this stage of a soccer game. Information about such predicted behaviour could affect e.g. the odds that are given to the possible result alternatives in the quick betting game. Before announcing the quick betting game to players, the implementing technologies engine 304 would check from the implementing technologies library 314, what is the expected response time of different terminal types, and only allow the quick betting game to be announced through terminals the use of which will not involve prohibitively long delays.

As an alternative it is certainly possible to construct the event model 301 , the gaming model 302, the player model 303 and the implementing technologies model 304 to be completely self-contained so that they inherently include all possible component routines needed to arrange a lottery concerning a certain type of event. In that case we may consider the libraries 311 , 312, 313 and 314 as a kind of design-time aids, from which the designer of such a self-contained lottery part will find the component routines that are needed to make the models sufficiently complete.

In order to enable communication concerning the events and exchanging information with the players' terminals there are, at the disposal of the implementing tech- nologies engine 304, an event interface 306 and a player interface 307. In their simplest form these are just communications connections between the lottery part 201 and an event (event interface 306) and the lottery part 301 and a player's terminal (player interface 307). Part of the features that qualify as belonging to the event interface 306 and player interface 307 may be located physically elsewhere. As an example, a player's terminal that as such constitutes the so-called enabling technology may comprise a Java-based virtual machine, on top of which runs the actual user interface software that creates the audiovisual interface that will be available for the player. Parts of such user interface software may originate from the lottery part 201 , which thus transmits executable scripts to the players' termi- nals.

EVENT MODEL

We will next describe in more detail the implementation of an event model. As an illustrative, nonlimiting example we may consider the event model as a state machine, in which transitions between states occur when certain incidents take place in the event that is the subject of modelling. If the event is a virtual or semivirtual event, it is relatively easy to derive information about any incident event therein and to convey it to an event model, since the incidents themselves only exist in the form of computer-executed processes, and they are easily complemented to include information transmission routines that transmit information to an event model whenever anything of interest takes place in the virtual or semivirtual event.

In the case of a real-life event the case is a bit different, and depends heavily on the nature of the real-life event in question. Fig. 4 illustrates two exemplary alternatives in a case where the real-life event is a sports event. The most easily accomplished alternative is to make an observer 401 follow the event and to key in information describing the event using a terminal 402. Such an arrangement is easily set up and is adaptable to many kinds of different events, but also involves the chance of human error. Fig. 4 also illustrates how the sports field 403, the sportsmen 404 and other important elements 405 of the sports event may be equipped with sensors 406 that automatically produce information about how the sports event is proceeding. It is also possible to combine the two approaches so that information about the proceeding of the sports event is produced and transmitted to an event model both automatically and manually. The principles of manual observation and sensor-based automatic monitoring are easily generalised also to other kinds of real-life events.

Fig. 5 illustrates a simple state machine that can be used as an event model that represents the sports event of fig. 4. In the state machine representation of fig. 5, a block with rounded ends represents a state, a block with a triangular indent at an end represents receiving information and a block with an arrow-shaped end represents transmitting information. A diamond-shaped block is not used in fig. 5 but would represent a decision with more than one possible outcome, and a rectangular block would represent an action the results of which are internal to the state machine in question. The state machine is first at a waiting state 501 when a match is still to begin. Receiving information at 502 about the beginning of a match causes a transition to a match in progress state 503. When information comes at 504 about a known end result of the match, that can only mean that the match has ended. The state machine transmits the known end result at 505 to e.g. a gaming model or other process that needs it but did not receive it at the time when it came to the knowledge of the event model. Operation ends at a match ended state 506.

Fig. 6 illustrates a slightly more refined state machine for the same purpose. The waiting state 601 is similar to state 501 in fig. 5. Receiving information at 602 about the beginning of a match causes a transition to state 603, according to which a first half of the match is in progress. If at any time while in state 603 there is received information 604 about a scored goal, the updated score of the match is transmitted (e.g. to a gaming model) at step 605, after which follows an immediate return to state 603. Another possible transition from state 603 occurs when there is received information about the end of the first half at step 606. The intermediate score is transmitted at 607, after which the state machine spends the break at a waiting state 608. Information about the second half beginning at 609 causes a transition to a second half in progress state 610. Steps 604' and 605' are essentially the same as steps 604 and 605 above respectively, with the sole difference that they now occur during the second half, meaning that the return from step 605' goes to state 610 and not to step 603. The end whistle at step 611 causes the final result to be transmitted at step 612, after which operation ends at the match ended state 613.

Following the same model it is possible to build arbitrarily complex state machines, up to an ultimate limit in which each sportsman as well as the ball or puck or any other element of the sport carries sensors, and every movement is modelled and interpreted in the light of the known rules of the game (e.g. by not announcing the location of a forward as particularly advantageous despite of him being left free very close to the opposite goal, if he simultaneously is offside). An interesting feature of most state machine solutions is still that they can be built from a relatively limited number of simple, standardised building blocks, like

- beginning of subevent (timed or non-timed) - a current score or position, or change (upwards or downwards) in the current score or position of a participant or team

- a participant or team being awarded an advantage (a turn to service, a free kick or the like)

- a participant or team being awarded a disadvantage (a penalty, a handicap or the like)

- remaining time X

- remaining distance or other physical measure X

- current value X of speed, acceleration, weight or other physical quantity

- end of subevent (based on time or score reached).

Although sufficient for many purposes, the list above should not be construed as exhaustive. These building blocks may need parametrisation, so that e.g. a standardised representation of a change of score would come with a small number of parameters for specifying e.g. who scored, at what time, who assisted, how many points did that earn, what is the current score thereafter and so on.

Description languages such as SDL (Specification and Description Language) exist for setting up an arrangement in which the designer of a state machine picks standardised building blocks (represented as graphics or in character form) and couples them together, after which a computer automatically fetches the corresponding source language procedures or even machine-readable instructions and compiles them into an executable program. The arrangement automatically sets up the information transfer interfaces between different building blocks, so that in the description of an information transmitting step it only needs to specified, to which other step(s) in the state machine description the information is to be transmitted. Additionally or alternatively (depending on the description language) in the description of an information receiving step it needs to specified, from which other step(s) the information is to be received. The automatic compiler then takes care of actually creating the proper read and write operations that are needed in order to deliver information from the correct source(s) to the correct destination(s).

One advantageous way of using an event models library is such where the library is a passive collection of functionalities and rules for producing certain services.

For example, the library contains the code passages that an SDL compiler would use for compiling the machine-executable representation of a state machine built in a graphical user interface. Thus the state machine is a way of arranging the execution in proper order of certain functionalities and rules, that actually are read from the library for execution. In some cases the event models library may contain mutually alternative functionalities that are so close to each other that any of them could be used in principle to implement a function that was described in the state machine representation. In such a case it is advantageous if the compiler asks the designer of the event model, which functionality should be used in the machine- executable representation.

Most advantageously the state machine or other process that constitutes the event model is sufficiently independent so that its operation can be tested and verified either against a simulation program or by feeding in a large amount of historical data about known events and observing that the event model executes properly and gives the correct outputs.

There may also be several event models running simultaneously, representing the same event. For example, the event models represented as state machines in figs. 5 and 6 could be used simultaneously, for example if there are different kinds of games made available to players, different types of players' terminals, different kinds of network connections, different user interfaces for players, or other factors that require different resolution or level of accuracy in the description of the event.

GAMING MODEL Next we will discuss certain aspects of the gaming model and the associated gaming models library. On a relatively high level of abstraction, gaming principles can be classified into a number of classes, including but not being limited to

- chance: a prize will be awarded by random to a participant or to a number of par- ticipants among all participants

- guess: a finite number of possible outcomes are known beforehand, and prizes will be awarded to participants according to how accurately they guessed the outcome that was eventually realised

- exchange: participants trade something between them, like previously placed bets for subevents that have not yet unravelled

- individual goal: participant tries to perform as well as possible in a task or a series of tasks

- winning condition: participant wins if a certain criterion or condition is fulfilled, e.g. he or she is the 1000^th participant to do something.

On a slightly more practical level any of these higher-level gaming principles can be implemented according to one or more practical implementation principle, including but not being limited to

- drawing the winning lot(s) or otherwise determining the correct result regularly, with a fixed time interval between occasions

- finding the correct guesses or otherwise determining the correct result after a certain triggering subevent has occurred and

- updating a list or table of results after receiving new information, and announcing the updated list or a part thereof.

As illustrated in fig. 7, a gaming model may spend time in a wait state 701 , waiting for information about°the course of action that is taking place in one or more event models. At step 702 the gaming model receives information that a first condition has been fulfilled; for example, one of the currently executed event models has en- tered a state where arranging a game would basically be possible, if another condition also comes true. We assume here that it is typical to the first condition that it only remains valid for a certain known period of time. Therefore at step 703 the gaming model starts a timer. At the decision step 704 the gaming model repeatedly checks whether the timer has expired. If the timer makes it to expiry before the second condition is fulfilled, a return to the wait state 701 occurs. If, however, before that the gaming model receives information showing that also the second condition has been fulfilled according to step 705, it moves on to define a game according to certain predetermined rules at step 706. At step 707 the gaming model declares the game to an implementation technologies model, which is then supposed to announce the newly declared game to appropriate player terminals.

The number of conditions to be fulfilled before a game can be declared is not nec- essarily two. It may be one, or it may be significantly more than two. The timer example explained above should not be construed as limiting. Some condition that has been fulfilled once may remain in a fulfilled state forever, or until the gaming model receives explicit information showing that said condition is not fulfilled any more. Conditions may have mutual dependencies, e.g. so that a first condition is to be considered fulfilled if simultaneously a second condition is true and a third condition is false, but not if said second and third conditions are both true, or so that the first condition must be completely fulfilled if a second condition is false, but only needs to be partly fulfilled is said second condition is simultaneously true.

The invention does not limit the selection or formulation of conditions. Thinking about the soccer example discussed earlier, one exemplary set of conditions is the following: a soccer match is in progress (i.e. not in a "to come" or "ended" state), a free kick has been awarded but not yet delivered, and the sportsman selected to give the free kick is the "godchild" specifically sponsored by the lottery company. Considering that very many different kinds of events may be represented by different event models, more or less any conditions will do as long as they define a situation in which a large number of players have essentially equal possibilities of taking part and winning in a game the outcome of which is and remains equally unknown to all such players until a cut-off moment after which bets or other kinds of participation announcements are not accepted any more.

The gaming model may also be responsive to other kinds of information, and information coming from other sources, than just announcements that something has happened in a certain event model. In fig. 8 we assume that a gaming model that is in a wait state 701 (or, actually, in any state) receives some descriptive information at step 801. For example, a player model may announce that according to its statistical observations, a game that was recently declared and announced to players raised an exceptional amount of interest, i.e. attracted an exceptionally large number of players to participate. The gaming model may interprete such an announcement as positive feedback showing that said recently declared game was a successful move, after which it changes some criteria at step 802 in a way that is likely to promote the generation and declaration of similar games in the future. In an opposite case information about a game having only raised relatively modest interest could cause the gaming model to abstain from declaring similar games in the future.

PLAYER MODEL

We will next consider certain aspects of a player model. The purpose of a player model is to offer tools for observing, estimating and possibly controlling the emotional responsiveness of games. The player model obtains or has previously ob- tained information about the behaviour of players in certain situations encountered in games. It is possible to subject testees to various stimuli under laboratory conditions, and observe how their emotions and reactions are reflected in parameters that could be detected and measured in a gaming situation. Such parameters include but are not limited to observed way of moving a mouse, observed mouse clicking speed and frequency, observed reaction time to various stimuluses and observed way of using a keyboard. In special cases also physiological measurements can be used, such as observing the player's pulse, eye movements or breath rate or the concentration of adrenaline in blood. From the laboratory measurements it is possible to derive universally applicable deduction rules, which can be then included in a player model.

Fig. 9a illustrates schematically the operation of a simple player model state machine during a "learning" phase in which observations and/or measurements about players' reactions are used to compile statistics for later use. State 901 is a wait state. At step 902 the player model receives new information about observed player behaviour. At step 903 it uses the received information to update statistics that describe typical emotional responses of a player to certain conditions. At an optional step 904 it may transmit some key figures of the updated statistics to some other process that may need them, after which there occurs a return to the wait state 901.

During a game the player model will receive input from a user interface, indicating e.g. the most recently observed distribution of some parameter values of the kind mentioned above. As a result the player model will generate standardised outputs for the use of the other models, which outputs describe, what deductions the player model has made about the most recent developments in emotional responsiveness of the game. The player model may also receive inputs from the event and gaming models. For example, if a player model receives from the event model information about two or more interrelated subevents, it may refer to a database of previously produced laboratory measurements in order to estimate the emotional effect of such combination of subevents: a penalty kick awarded in a dead heat situation with only five minutes remaining in the match is likely to cause a differen- tial emotional response in players than a penalty kick during the very first minutes of a match or in a match the score of which is already clearly in favour of one team.

Fig. 9b illustrates schematically the operation of a simple player model state ma- chine during an "operational" phase in which it responds dynamically to conditions and/or combinations of conditions observed in an event model or a gaming model by providing estimates about player behaviour. State 901 is again a wait state. At step 912 the player model receives an announcement of an observed condition or a combination of conditions in an event model or a gaming model. At step 913 the player model maps said condition or combination of conditions into estimated player behaviour, for example by looking for a best match between a current condition and a previously used test condition, with reference to which there has been stored statistical information about player behaviour that was observed in a laboratory environment. One of the known suitable technical means for finding best matches of this kind is a neural network, although also other technical means can be applied. After having found some information about the most probable emotional response of a player to the current condition or combination of connections the player model transmits that information to e.g. a gaming model at step 914, after which there occurs a return to the wait state 901.

Above it was already mentioned how an indication about observed player enthusiasm can be used to control the kind and number of games announced to players. There are also other uses for the information generated in a player model. For example, subject to the permission of the player(s) concerned, a player model could monitor the behaviour of an individual player or a limited number of players in order to determine, whether said behaviour indicates excessive addiction or compulsion to playing. A positive indication could be used to trigger limiting action, so that the system would not allow the player(s) concerned to play more than up to a certain limit. A further possibility is to use an estimate of players' excitement for tuning the odds or other rules of a game.

IMPLEMENTING TECHNOLOGIES MODEL We will next consider certain aspects of an implementing technologies engine or -model. Various embodiments can be presented depending on the distribution of work between the implementing technologies model and the other models. Ac- cording to a centralised approach, the implementing technologies model is where the actual generation and storing of executable computer code takes place, utilising the higher-level definitions obtained from the other models. A more distributed approach would be to let the event model, the gaming model and the player model to generate their own machine-executable codes, and only use the implementing technologies model as an entity that arranges the communication of information between the other models.

Irrespective of the degree of centralizedness or distributedness, the implementing technologies model is responsible for consolidating the capabilities of the other components and the requirements placed to a game and the whole lottery part. The components selected for a certain implementation should have sufficient capacity: for example a calculationally very intensive routine can only be taken to constitute a part of an implementation if it can be ascertained that the available computing capacity will always be sufficient for executing said routine at all re- quired instances. Also security and confidentiality should be considered: an implementation should include e.g. necessary encryption and decryption routines for arranging cryptographically protected communication where needed. The implementing technologies model may also consider cost aspects, e.g. so that an implementation will not be allowed if it would involve causing excessive cost.

Technology components that are available to the implementing technologies model may include, among others, the following:

- algorithms, such as random number generators, encryption and decryption algorithms as well as checksum calculators and verifiers - procedures for defining odds according to some predefined criteria

- realisation of various game principles

- procedures for exchanging information with players' terminals, including setting up and maintaining connections (wireless, wired, dynamically changing); exploiting various communication technologies (Digital Video Broadcasting (DVB), Global System for Mobile telecommunications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications Services (UMTS), Wireless Local Area Networks (WLAN), Internet Service Providers (ISP)); and utilising various communications protocols (Secure Sockets Layer (SSL), Hypertext Transfer Protocol (HTTP), Traffic Control Protocol / Internet Protocol (TCP/IP)

- security procedures, such as terminal authentication, user authentication and account management - database procedures, such as maintaining centralised and/or distributed databases and connections to external databases

- procedures for setting up user interfaces, utilising various techniques such as Java, World Wide Web, Multimedia Home Platform (MHP), Short Message Service (SMS) or Multimedia Messaging Service (MMS).

Most importantly the implementing technologies model should include rules for verifying the technical compatibility of all selected components and functionalities, as well as for arranging their mutual hierarchy and relations. It must not allow setting up implementations involving significant technical risks for malfunctioning, or implementations where component procedures would be contradictory to each other. Additionally the implementing technologies model may consider the quality of playing experienced by players, expressed e.g. as robustness against disruptions in communication and/or minimisation of delays. If the successful playing of a game depends on providing responses fast enough, the implementation technolo- gies model should not allow announcing it to be played with terminals that involve, or the communication connections to which involve, significant risk of excessive delays.

Fig. 10 is an exemplary composition and model of operation for an implementing technologies model. The progress of events is determined by a technologies state machine 1001 , which is a programmed computer-executable process that proceeds from state to state, accepting inputs and producing outputs according to a well-defined causal chain. For carrying out operations that have some practical outcome for example in producing information or setting up connections it commu- nicates with component processes, of which four examples are shown in fig. 10. An odds calculating component 1011 exists for calculating odds, and is coupled to the technologies state machine 1001 through a component interface 1012, which standardizes the communication between the component and the technologies state machine 1001 so that for example a component can be exchanged to an up- dated version without having to touch the technologies state machine's side of the interface. Another component 1021 is provided generally for setting up a user interface, again with a component interface 1022 linking it to the technologies state machine 1001 and to other components, if required. Similarly fig. 10 shows the exemplary existence of an SSL connection component 1031 , which - with its component in- terface 1032 - is responsible for setting up a secured connection over an un- trusted network, as well as a TCP/IP connection component 1041 , which is meant to implement TCP/IP based parts of connections. Also the TCP/IP connection component 1041 has a component interface 1042. The most straightforward way of arranging functional dependencies is the one schematically shown in fig. 10, i.e. the one in which the technologies state machine 1001 is the immediate user of all component processes. As an alternative it is possible to arrange certain component processes to have hierarchical relationships with each other, e.g. so that a general "connection maintenance" component governs subcomponents meant for implementing various mutually alternative or augmenting protocols, and the tech- nologies state machine only needs to communicate with the connection maintenance component.

SYSTEMATIC DEVELOPMENT OF NEW LOTTERIES

The division of the lottery concept into models like an event model, a gaming model, a player model and an implementing technologies model makes it possible to develop and synthesize new lotteries in a systematical way, which may help to significantly speed up the process from an idea to an operational lottery while si- multaneously avoiding errors and saving effort. Fig. 11 illustrates schematically a development and synthesis process. It begins from an idea 1101 of what a new lottery should be like. Typically the next step is the development of an event model at step 1102, utilising knowledge about existing event model component routines in an event models library 311. The next step 1102 involves developing a gaming model, typically by adapting existing gaming model component routines from a gaming models library 312 to be associated with suitable subevents that may take place in the event model.

At step 1104 a player model is developed and bound to the event model and gam- ing model(s) developed at steps 1102 and 1103, again by utilising knowledge about player model component routines existing in a player models library 313 whenever possible. At step 1105 an implementing technologies model is developed to bind together the event model, gaming model and player model developed earlier. An implementing technologies library 314 is used as an aid. Assuming that the centralised approach mentioned earlier is used, the event models library 311 , the gaming models library 312 and the player models library 313 contain more or less human-understandable rules and definitions of the appropriate component routines, while the actual .exe files or corresponding computer-executable instructions appear in the implementing technologies library 314. While steps 1102, 1103 and 1104 involved working mostly with said human-understandable rules and definitions, at step 1105 the corresponding computer-executable instructions are fetched and linked together into an entity that finally constitutes the synthesized new lotter obtained at step 1106.

All and any of steps 1102, 1103, 1104, 1105 and 1106 may include verification, simulation, testing and comparison against user experiences, as is graphically illustrated as block 1111 in fig. 11. Although the development flow appears as a one-way road in fig. 11 , this should not be construed as a limitation; the development work may well include backward steps, if e.g. during the development of a gaming model it is found that a slightly differently formulated event model would make it easier to adapt a pre-existing gaming model component routine for use in the new lottery.

LOTTERY TECHNOLOGY SERVER

Fig. 12 illustrates an example composition of a server arrangement used to run a lottery according to an embodiment of the invention. In the operating system environment of the server arrangement there are means 1201 for executing the state machines that represent the event model, gaming model, player model and implementing technologies model. Similarly there are means 1202 for executing core components of the server arrangements, like internal data transfer. There are also means 1203 for performing server administration, such as memory allocation and maintenance, as well as means 1204 for perfoming other processes. Communications with other computer devices require the implementation of various protocols, which is taken care of by means 1205 for communications-related component execution. For setting up interfaces towards human users (i.e. control operators and players) there are means 1206 for executing components related to interfaces, as well as the actual interface parts 1207 and 1208. The libraries and state machines described earlier are not part of the server arrangement proper; we assume that the server arrangement is self-contained in the way that it has been pro- grammed with completed machine-executable routines, the creation of which may have involved the use of said libraries and the operation of which may correspond to proceeding according to the state machine representations.

Claims

1. A system for offering recreational application programs for execution through players' terminals, said recreational application programs involving at least one of playing and gambling, characterised in that:

- the system comprises an event model (301), which is a process adapted to represent a sequence of subevents in a target event (202, 203, 204) in real time and

- the system is adapted to offer the execution of a recreational application program through players' terminals as a response to an incident taking place in said event model (301 ).

2. A system according to claim 1 , characterised in that said event model (301) is adapted to proceed through a sequence of states (501 , 503, 506, 601 , 603, 608, 610, 613) at a pace set by input information obtained (502, 504, 602, 604, 604', 606, 609, 611 ) from said target event (202, 203, 204).

3. A system according to claim 1 , characterised in that it comprises a gaming model (302), which is a process adapted to respond to an incident taking place in said event model by announcing a game to be offered to players' terminals.

4. A system according to claim 1 , characterised in that it comprises a player model (303), which is a process adapted to describe an emotional response of at least one player to conditions occurring in the execution of a recreational application program.

5. A system according to claim 1 , characterised in that it comprises an implementing technologies model (304), which is a computer-executable process comprising said event model in the form or executable program code.

6. A system according to claim 5, characterised in that said implementing technologies model (304) additionally comprises a gaming model and a player model in the form of executable program code.

7. A system according to claim 1 , characterised in that it comprises an imple- menting technologies model (304), which is adapted to link together an event model (301), a gaming model (302) and a player model (303), which themselves are in the form of executable program code. 8. A method for offering recreational application programs for execution through players' terminals, said recreational application programs involving at least one of playing and gambling, characterised in that it comprises:

- modelling a sequence of subevents in a target event (202, 203, 204) in real time by executing an event model (301), and

- offering the execution of a recreational application program through players' terminals as a response to an incident taking place in said event model (301).

9. A method according to claim 8, characterised in that it comprises: - delivering event information about incidents taking place in said event model (301) to a gaming model (302) and

- responding to event information in said gaming model (302) by announcing a game to be offered to players' terminals.

10. A method according to claim 9, characterised in that it comprises:

- estimating an emotional response of at least one player to conditions occurring in the execution of a recreational application program,

- delivering emotional response information about estimated emotional response to said gaming model (302) and - responding to emotional response information in said gaming model (302) by changing a criterion concerning a task of announcing a game to be offered to players' terminals.

11. A method for synthesizing a recreational application program for execution through players' terminals, said recreational application programs involving at least one of playing and gambling, characterised in that it comprises:

- modelling a target event (202, 203, 204) with an event model (301 ), which is a process adapted to represent a sequence of subevents in a target event, - verifying operation of said event model (301 ) through simulating subevents of a target event and feeding inputs from simulated subevents to said event model (301) and

- using a verified event model (301 ) to feed inputs to a recreational application program executed through players' terminals.

12. A computer program product for offering recreational application programs for execution through players' terminals, said recreational application programs involving at least one of playing and gambling, characterised in that the computer program product comprises: - computer code for establishing an event model (301), which is a process adapted to represent a sequence of subevents in a target event (202, 203, 204) in real time and

- computer code for offering the execution of a recreational application program through players' terminals as a response to an incident taking place in said event model (301).