U.S. patent application number 11/791932 was filed with the patent office on 2008-09-04 for method, system and computer program product for producing, offering and executing recreational application programs.
This patent application is currently assigned to TAMPEREEN TEKNILLINEN YLIOPISTO. Invention is credited to Timo D. Hamalainen, Marko Hannikainen.
Application Number | 20080214303 11/791932 |
Document ID | / |
Family ID | 33547936 |
Filed Date | 2008-09-04 |
United States Patent
Application |
20080214303 |
Kind Code |
A1 |
Hamalainen; Timo D. ; et
al. |
September 4, 2008 |
Method, System and Computer Program Product For Producing, Offering
and Executing Recreational Application Programs
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).
Inventors: |
Hamalainen; Timo D.;
(Kangasala, FI) ; Hannikainen; Marko; (Pirkkala,
FI) |
Correspondence
Address: |
WOOD, PHILLIPS, KATZ, CLARK & MORTIMER
500 W. MADISON STREET, SUITE 3800
CHICAGO
IL
60661
US
|
Assignee: |
TAMPEREEN TEKNILLINEN
YLIOPISTO
Tampere
FI
|
Family ID: |
33547936 |
Appl. No.: |
11/791932 |
Filed: |
November 30, 2005 |
PCT Filed: |
November 30, 2005 |
PCT NO: |
PCT/FI2005/000518 |
371 Date: |
December 4, 2007 |
Current U.S.
Class: |
463/32 |
Current CPC
Class: |
G06Q 50/34 20130101;
A63F 13/10 20130101; G07F 17/32 20130101; A63F 2300/6018
20130101 |
Class at
Publication: |
463/32 |
International
Class: |
A63F 9/24 20060101
A63F009/24 |
Foreign Application Data
Date |
Code |
Application Number |
Dec 2, 2004 |
FI |
20041563 |
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 implementing 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: modeling 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: modeling 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).
Description
[0001] 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.
[0002] 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.
[0003] 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.
[0004] 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.
[0005] 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.
[0006] 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.
[0007] A method according to the invention is characterised by the
features recited in the characterising part of the independent
claim directed to a method.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] For allowing a game organiser to exercise control over the
operation of the system, it most advantageously comprises also a
control interface.
[0017] 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.
[0018] 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.
[0019] FIG. 1 illustrates a prior art solution for a recreational
application program,
[0020] FIG. 2 illustrates certain concepts related to the
invention,
[0021] FIG. 3 illustrates an exemplary lottery part with
connections,
[0022] FIG. 4 illustrates exemplary ways of obtaining inputs from a
real-life event,
[0023] FIG. 5 illustrates an exemplary event model state
machine,
[0024] FIG. 6 illustrates another exemplary event model state
machine,
[0025] FIG. 7 illustrates an exemplary gaming model state
machine,
[0026] FIG. 8 illustrates another feature of an exemplary gaming
model state machine,
[0027] FIG. 9a illustrates an aspect of an exemplary player model
state machine,
[0028] FIG. 9b illustrates another aspect of an exemplary player
model state machine
[0029] FIG. 10 illustrates schematically an aspect of an
implementing technologies engine,
[0030] FIG. 11 illustrates schematically the systematic development
and synthesis of a new lottery and
[0031] FIG. 12 illustrates schematically a composition of a gaming
technology server.
CONCEPTS AND DESIGNATIONS
[0032] 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 virtual 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).
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
Overview of Lottery Part
[0037] 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 interactions on a
general level. A more detailed description of the most important
parts will follow later in this text.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
Event Model
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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
[0053] beginning of subevent (timed or non-timed)
[0054] a current score or position, or change (upwards or
downwards) in the current score or position of a participant or
team
[0055] a participant or team being awarded an advantage (a turn to
service, a free kick or the like)
[0056] a participant or team being awarded a disadvantage (a
penalty, a handicap or the like)
[0057] remaining time X
[0058] remaining distance or other physical measure X
[0059] current value X of speed, acceleration, weight or other
physical quantity
[0060] end of subevent (based on time or score reached).
[0061] 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.
[0062] 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).
[0063] 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.
[0064] 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.
[0065] 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
[0066] 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
[0067] chance: a prize will be awarded by random to a participant
or to a number of participants among all participants
[0068] 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
[0069] exchange: participants trade something between them, like
previously placed bets for subevents that have not yet
unraveled
[0070] individual goal: participant tries to perform as well as
possible in a task or a series of tasks
[0071] winning condition: participant wins if a certain criterion
or condition is fulfilled, e.g. he or she is the 1000.sup.th
participant to do something.
[0072] 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
[0073] drawing the winning lot(s) or otherwise determining the
correct result regularly, with a fixed time interval between
occasions
[0074] finding the correct guesses or otherwise determining the
correct result after a certain triggering subevent has occurred
and
[0075] updating a list or table of results after receiving new
information, and announcing the updated list or a part thereof.
[0076] 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 entered 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.
[0077] 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.
[0078] 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.
[0079] 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 interpret 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
[0080] 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.
[0081] 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.
[0082] 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.
[0083] FIG. 9b 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.
[0084] 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
[0085] 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.
[0086] 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.
[0087] Technology components that are available to the implementing
technologies model may include, among others, the following:
[0088] algorithms, such as random number generators, encryption and
decryption algorithms as well as checksum calculators and
verifiers
[0089] procedures for defining odds according to some predefined
criteria
[0090] realisation of various game principles
[0091] 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)
[0092] security procedures, such as terminal authentication, user
authentication and account management
[0093] database procedures, such as maintaining centralised and/or
distributed databases and connections to external databases
[0094] 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).
[0095] 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.
[0096] 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 communicates 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 updated version without having to touch the
technologies state machine's side of the interface.
[0097] 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 interface
1032--is responsible for setting up a secured connection over an
untrusted 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
technologies state machine only needs to communicate with the
connection maintenance component.
Systematic Development of New Lotteries
[0098] 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. 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.
[0099] 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.
[0100] 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
[0101] 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 performing 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
programmed 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.
* * * * *