Patent Application
20080214303
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
Playing a game of chance using the program architecture shown in
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 opportunities 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 developing 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 gaming 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 implementing 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 unacceptably 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 limitation that does not exclude the existence of also unrecited features. The features recited in depending claims are mutually freely combinable unless otherwise explicitly stated.
a illustrates an aspect of an exemplary player model state machine,
b illustrates another aspect of an exemplary player model state machine
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
The entities illustrated in
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 bidirectional 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 intention 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 unraveled subevents as well as the winnings earned by properly placed bets.
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 modeled 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 systematic 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 controlling 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 actively 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 data-bases or libraries. These are the event models library 311, the gaming models library 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 example. 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 appropriate 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 technologies 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' terminals.
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 modeling. 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.
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 modeled 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
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 participants 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 unraveled
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 1000th 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
The number of conditions to be fulfilled before a game can be declared is not necessarily 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
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 obtained 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.
a 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 differential 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.
b illustrates schematically the operation of a simple player model state machine 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.
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. According 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 required 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 technologies 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.
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
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 simultaneously avoiding errors and saving effort.
At step 1104 a player model is developed and bound to the event model and gaming 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 lottery 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
| Number | Date | Country | Kind |
|---|---|---|---|
| 20041563 | Dec 2004 | FI | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/FI2005/000518 | 11/30/2005 | WO | 00 | 12/4/2007 |
