CA2554917C

CA2554917C - Gesture control system

Info

Publication number: CA2554917C
Application number: CA2554917A
Authority: CA
Inventors: Juha Kela; Panu Korpipaa; Jani Mantyjarvi; Heikki Keranen; Tapani Rantakokko; Esko-Juhani Malm; Sanna Kallio; Jussi Holopainen; Jari Kangas; Samuli Silanto
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2004-02-06
Filing date: 2005-01-20
Publication date: 2015-11-10
Anticipated expiration: 2025-01-20
Also published as: WO2005076114A1; FI20040184A0; AU2005210778B2; FI117308B; US20050210419A1; US8819596B2; US20140325459A1; FI20040184A; AU2005210778A1; CA2554917A1; EP1711886A1

Abstract

A control system basing on the use of gestures and functioning especially in mobile terminals. The gesture control system is provided with a general purpose interface (320) with its commands for applications (310) to be controlled. The processing software (330) of the gesture signals includes a training program (331), the trained free-form gestures made by the user being stored in the gesture library, and a recognizing program (332), which matches a gesture made by the user to the stored gestures and chooses the most similar gesture thereof. Gestures can hence be used as commands for controlling any application configured or programmed to receive the command. One and the same application functions in different models of mobile terminals without matching, and in a certain mobile terminal all applications can be run, which applications use specified interface commands. The application (310) can be e.g. a game or an activity being included in the basic implementation of a mobile terminal.

Description

Gesture control system The invention relates to a control system basing on the use of gestures and func-tioning especially in mobile terminals. The invention also relates to a mobile termi-nal comprising the software of a gesture control system.
The gesture control system means a system, by means of which the managing of a application, observable with senses, takes place at least partly by hand motions.
The control system comprises motion sensors, which move along with the hand of a person using the application, and the converters and processing programs for the signals generated by the motion sensors. The hand motions, or gestures, then are recognized on grounds of e.g. accelerations occurring in the motions. The ap-plication controlled by gestures can be for example a game loaded into a mobile terminal or the controlling program of an external electromechanical device.
The "application" means in this description and the claims both an observable process and a program, which directly realizes said process.
Recognizing a motion by equipments, as such, is known from before. Recognition systems applying acceleration sensors are disclosed among other documents in the articles "Recognizing Human Motion with Multiple Acceleration Sensors"
(Man-tyjarvi & kumpp., IEEE International Conference on Systems, Man and Cybernet-ics, 2001) and "Recognizing Movements of a Portable Handheld Device Using Symbolic Representation and Coding of Sensor Signals" (Flanagan et al., Interna-tional Conference on Mobile and Ubiquitous Multimedia, 2002) and in the publica-tion WO 03/001340. The system in accordance with the last-mentioned publication includes also a gesture library and a program analyzing acceleration data and defining, if that data corresponds to a certain three-dimensional gesture.
Also the controlling of an application by hand motions is known from before.
For example the publication WO 00/63874 discloses a system, in which an application changes the shape of a pattern seen in the computer display and moves the pat-tern, depending on how a control device, to be held in the hand, is handled.
The control device comprises acceleration sensors for three dimensions and a button with a pressure sensor.
Fig. 1 presents a simplified diagram showing the interfacing an application to its control system, according to the prior art. The whole system comprises a hardware portion HW and a software portion SW. Regarding the hardware portion there is drawn in Fig. 1 a sensor unit SU, an interface IF of the sensor unit, a memory CONFIRMATION COPY

2 MEM and a computer bus. The software portion comprises a driver 140 for the interface IF, a processing software 130 for the signals which correspond to the hand motions, an application 110 controllable by the hand motions and an operation system OS of the computer at issue. The driver 140 stores the gesture signals, converted to digital form by the interface IF, to the memory MEM. The signal processing software then analyzes the gesture signals and provides a control to the application. Naturally, the signal processing software has to be matched to the application for the data transfer between them.
A flaw in the control systems like the above-mentioned systems is the limited scope of their use: Changing an application to another application presumes amending work in the software of the control system. Likewise transferring the system to another computer of other type requires matching work in the programs.
Objects of the invention are to reduce said disadvantages related to the prior art and to extend implementing environment of the gesture control systems to the mobile terminals.
Accordingly, in one aspect there is provided a method comprising: receiving a representation of a training hand gesture by capturing at least two three-dimensional points of the training hand gesture; receiving an indication of a command;
associating the training hand gesture with the command; with a processor, in response to identifying a subsequent hand gesture as the training hand gesture, executing the command; and calculating a likelihood of the training hand gesture to be recognized, based on the training hand gesture and at least one additional trained hand gesture.
According to another aspect there is provided an apparatus comprising at least one processor and at least one memory including computer program code comprising instructions which, when executed by the at least one processor, cause the apparatus to at least: receive an indication of a training hand gesture by capturing at least two three-dimensional points of the training hand gesture; receive an indication of a command; associate the training hand gesture with the command; in response to identifying a subsequent hand gesture as the training hand gesture, execute the command; and calculate a likelihood of the training hand gesture to be recognized, based on the training hand gesture and at least one additional trained hand gesture.

2a According to yet another aspect there is provided a non-transitory computer-readable storage medium having computer-executable program code instructions stored therein, the computer-executable program code instructions, when executed, carrying out: receiving an indication of a training hand gesture by capturing at least two three-dimensional points of the training hand gesture; receiving an indication of a command; associating the training hand gesture with the command; in response to identifying a subsequent hand gesture as the training hand gesture, executing the command; and calculating a likelihood of the training hand gesture to be recognized, based on the training hand gesture and at least one additional trained hand gesture.
According to still yet another aspect there is provided a gesture control system comprising: a sensor unit with motion sensors to be held in a user's hand and processing structure in communication with the motion sensors comprising means for providing a sensor interface; and processing structure comprising means for providing: a trainer configured to make gesture models, or trained gestures; a recognizer configured to recognize gestures during use of a controllable application;
and an interface between the trainer, the recognizer and the controllable application, wherein said interface between the trainer, the recognizer and the controllable application, together with said sensor interface, said trainer and said recognizer, form a general purpose platform to get specified commands from the application, to provide specified responses to different applications, and to make it possible to install a certain application to different devices, and wherein the processing structure further comprises means for providing a generic codebook, which contains gesture data collected from a number of people to create user-independent trained gestures.
The basic idea of the invention is as follows: The gesture control system is provided with a general purpose interface with its commands for applications to be controlled.
The system is preferably implemented in a mobile terminal.
An advantage of the invention is that one and the same application functions in different models of mobile terminals without matching relating to the models.
This is due to the above-mentioned general purpose interface. Likewise in a certain mobile terminal can be run all applications, which use specified interface commands.
Another advantage of the invention is that in a system according to it new and different gestures can easily be formed and put into use. A further advantage of the invention is that it makes possible the controlling by gestures of all possible activities being included in the basic implementation of a mobile terminal. A further ad-

3 vantage of the invention is that it remarkably expands possibilities to interact with game applications in the mobile terminals.
The invention will now be described in detail. Reference will be made to the ac-companying drawings wherein Fig. 1 presents as a layer diagram the interfacing an application to its control system, according to the prior art, Fig. 2 presents as a layer diagram the interfacing an application to its control system, according to the invention, Fig. 3 presents the general principle of the function of a system according to the invention, Fig. 4 presents as a flow diagram an example of a gesture training procedure in a system according to the invention, Fig. 5 presents as a flow diagram an example of a gesture recognizing proce-dure in a system according to the invention, Fig. 6 presents as a sequence diagram an example of a gesture training pro-cedure in a system according to the invention, Fig. 7 presents as a sequence diagram an example of a gesture recognizing procedure utilizing a button, in a system according to the invention, Fig. 8 presents as a sequence diagram an example of a gesture recognizing procedure without a button, in a system according to the invention, and Figs. 9a,b present examples of a mobile terminal according to the invention.
Fig. 1 was already discussed in connection with the description of the prior art.
Fig. 2 shows a diagram, corresponding to Fig. 1, about the interfacing an applica-tion to its control system, according to the invention. The whole system comprises a hardware portion HW and a software portion SW. Regarding the hardware por-tion there is drawn in the figure, also in this case, a sensor unit SU
reacting to the motion, a circuit-based interface IF of the sensor unit, a memory MEM and a com-puter bus. In addition, there is seen an audio part for possible use of voice mes-sages to the user and/or from the user. The software portion comprises a driver

4 PCT/F12005/000039 250 for the interface IF, a sensor interface 240, a processing software 230 for the signals which correspond to the hand motions, an interface 220 between said processing software and an application 210 to be controlled by the hand motions, the actual application 210 and an operation system OS of the device at issue.
An optional part in the software SW is audio interface 270 for above-mentioned voice messages. The operation system can be Symbian or Linux, for instance. The processing software for the signals which correspond to the hand motions is more briefly named "Gesture Engine" and different interfaces, or matching programs are named by an abbreviation API (Application Programming Interface). So the driver for the circuit-based interface IF is IF-API, the sensor interface is S-API
and the in-terface between the application and said Gesture Engine is G-API. IF-API
together with S-API stores the motion signals, converted to digital form, to the memory MEM. S-API then informs by messages to the Gesture Engine the data at issue, or the sensor data.
The sensor unit SU can be included in a host device or it can be external. In the latter case the transfer system between the sensor unit and interface IF can be based e.g. on Bluetooth or infrared technology, or can be wired. The motion sen-sors proper can be acceleration sensors or gyroscopes reacting to angular velocity or angular acceleration. They can also be magnetometers, or electronic corn-20. passes. In one and the same sensor unit there can occur more than one sensor type. When using acceleration sensors, the number of these is at least two, but preferably three to measure acceleration in each of three dimensions. The sensor unit further can include a button to inform the gesture engine the start and comple-tion of a gesture.
The interface G-API between the application and the Gesture Engine is, as men-tioned, general purpose, or standard-like. The application has an interface directly to the sensor interface S-API, too. That interface can be used for application con-trol directly, when an actual signal processing is not needed. The interface G-API, the Gesture Engine and the sensor interface S-API constitute a general purpose platform, on which different applications can be connected. Similarly a certain ap-plication can without difficulty be installed to different devices, which have the plat-form in question.
Fig. 3 shows the general principle of the function of a system according to the in-vention. As functional parts there are presented an application 310, the interface thereof 320, Gesture Engine 330 and a sensor interface, or S-API 340. In the Ges-ture Engine there are seen its main parts Gesture trainer and Gesture recognizer.

Both these parts utilize processing modules Preprocessor and Gesture capturer.

Certain operation phase starts from a command given by the application to the Gesture Engine. The Gesture Engine gives to the application a response required by the command. Giving a response often presumes information about motions of

5 the motion sensors. For this reason the Gesture Engine gives to S-API a request for sensor data, and S-API answers by informing the data when it can be read in the memory. In Fig. 3 also is seen the sensor unit SU in the hand of a user and an example GES of a hand motion, which causes said data.
The set of the specified commands and responses is as follows, for example. In the table the response corresponding a certain command is to the right from that command.
- CollectTrainingGesture - Train ingGestu reCollected - StartGestureTraining -GestureTrained - GestureNotTrained - StartGestureRecognition - GestureRecognized - GestureNotRecognized - DetectStill - DeviceStill - EndGesture - GestureRecognized - GetGestureNames - GestureNameList - AbortGestu re - SubscribeGestu re - UnsubscribeGesture - DeleteGestu re - RenameGesture The meaning of most important commands and responses appears more detailed in the descriptions of Figs. 6-8.
Fig. 4 presents as a flow diagram an example of a gesture training procedure in a system according to the invention. The procedure as such is known from before.
It is based on HMM-algorithm (Hidden Markov Model), which is applied on recogniz-ing e.g. speech and graphological text. In step 401 a person carrying out the train-ing has done a free form hand motion, and the sensor interface S-API provides the sensor data generated by the motion to the Gesture Engine. The data consists of samples of the analog sensor signals, the samples converted to a digital form.

6 There are three sample sequences, each of which corresponds to a motion in one dimension. In step 402 the data is normalized. That means increasing the number of samples by interpolation or decreasing the number of samples by decimation, to achieve the sample sequences of a certain length. In step 403 the data is quan-tized. This happens by means of a codebook CB containing fixed three-dimensional points, which characterize the space of the gestures. Using such a codebook alleviates the computing load. The result is a one-dimensional token se-quence, suitable for the HMM. In step 404 it is checked, whether the gesture being under training has been performed so many times as enough. If not, the above-described steps 401-403 are repeated. If yes, initial parameters are defined for the gesture model on grounds of accumulated, quantized data (step 405). In step 406 a model of the gesture at issue is formed by means of an expedient method such as the Baum-Welch algorithm, in accordance with the HMM. The Baum-Welch algorithm calculates, using probability theory, values for three parameters, which represent the gesture. Each parameter is a matrix containing then plurality of numbers. The obtained parameter values 407 are the result of the training, and they are stored to the gesture library LIB. The Baum-Welch algorithm is iterative by nature. The iteration converges the better the smaller the variation in the source data. However that variation has certain optimum value. If it is clearly lower than the optimum value, the recognition program discards too readily gestures made by the user, and if the variation is clearly higher than the optimum value, the result of the later recognitions is unreliable.
The result of the training can naturally be tested by trying the gesture regocnition directly after the training, according to a procedure described below. An estimate for the reliability is obtained by doing several times gestures, which are similar as in the training phase and "something like that". A speech synthesizer, if being in-cluded in the device, can be connected to that kind of testing so that the device tells by clear speech the name of the gesture, which it has recognized.
The codebook CB has been created in a blanket way, by means of a separate specific algorithm, which uses among other things gesture data collected from a number of people. The resulting codebook is serviceable to use for various per-sons without changes. "Generic code book" means here and in patent claims such a codebook. A generic codebook contributes to that also the trained gestures are user-independent. In addition, if a single trained gesture is transferred from a de-vice to another device, it is immediately serviceable in the new environment.
Such

7 gestures can be arranged to be loaded through the Internet, and they can be sub-jects to a charge.
Fig. 5 presents as a flow diagram an example of a gesture recognizing procedure in a system according to the invention. Also this procedure is based on HMM-algorithm and is known from before as such. In step 501 a person using the sys-tem has done a hand motion, and the sensor interface S-API provides the sensor data generated by the motion to the Gesture Engine. Also now the data consists for example of three sample sequences, each of which corresponds to a motion in one dimension. In steps 502 and 503 happen the data normalization and quantiza-tion as in steps 402 and 403 of Fig. 4. In step 504 the number I of gestures stored in the gesture library is loaded in a counter. In step 505 a reference figure is calcu-lated, which represents likelihood of the gesture being under recognition with the stored gesture pointed by the counter value. The calculation employs the parame-ter values defined for the stored gesture at issue, and it is run by means of an ex-pedient method such as the Viterbi algorithm, in accordance with the HMM.
After-wards the counter content is decremented by one (step 506). In following step it is checked, whether the counter value is zero. If not yet, the calculation accord-ing to step 505 is repeated, regarding now a new stored gesture. If yes, or all stored gestures are gone through, obtained reference figures are evaluated, step 508. In the evaluation the reference figures are compared with each other and with a certain treshold value. In step 509 a decision is made. If some reference figure is found to be disdinctly highest, and it further is higher than said treshold value, the gesture is considered to be regocnized. The chosen gesture is the stored gesture corresponding to the reference figure in question. If no one of the reference figures is disdinctly highest, or all of them are lower than said treshold value, the gesture is not considered to be regocnized.
Fig. 6 presents as a sequence diagram an example of a gesture training proce-dure in a system according to the invention. In the diagram the vertical dashed lines refer to functional parts of the software. These are, in the order from left to right, an application, "G" which means here the G-API and the upper level of the Gesture Engine together, the Preprocessor, the Gesture Capturer and the S-API.

In the diagram the time proceeds downwards. A vertical beam on a dashed line means a period, when the part of the software at issue is active. The example re-lates to a system, in which the motion sensor unit is equipped with a button.
The state information of the button is brought through the S-API to the Gesture Engine and further to the application. The diagram starts by command Collect Training-

8 Gesture provided by the application to the interface G-API. That command has been preceded by the starting of the training procedure in the application and the pressing the button B. The command contains as parameters the name chosen for the gesture to be trained, the button being used and the gesture timeout, which means the maximum time allowed for the collecting of training data. Said com-mand causes command StartGestureCapture to the Gesture Capturer inside the Gesture Engine, and this command in turn command SetSensorListener to the in-terface S-API. The last-mentioned command contains among other things informa-tion at which rate the Gesture Engine will get data packets. Afterwards the S-API
provides to the Gesture Capturer the samples of the sensor signals in data pack-ets, in the header of which the size of the packet at a given time is mentioned.
That transfer continues, until the button is released. In this case the application provides to the G-API command EndGesture, which results in command StopGes-tureCapture to the Gesture Capturer inside the Gesture Engine and command SetSensorListener to the S-API. The parameters included in the latter command cause the sampling to stop. The Gesture Capturer gives to its internal module command FindActualGesture, which module cleans the captured raw data delet-ing, according to certain criteria, from it the parts, which probably do not belong to the actual gesture. That kind of irrelevant data parts come from the small and unin-tended hand motions before and after the actual gesture. When the irrelevant data is deleted, the Gesture Capturer provides to the upper level of the Gesture Engine response GestureCaptured, by which the actual gesture data is informed. The Gesture Engine then provides to the Preprocessor command Normalize (actual gesture data), which starts the processing of the actual gesture data. The Pre-processor carries out the data normalization and quantization. The latter is started by command ExtractFeatures given to an internal module of the Preprocessor.
The Preprocessor then provides to the upper level of the Gesture Engine notice FeaturesExtracted. The data yielded by deleting irrelevant data, normalizing and quantizing is here and in claims called "feature data" in distinction from said raw data. Subsequently the Gesture Engine provides, by the G-API, to the application response TrainingGestureCollected. As a parameter of this response it is men-tioned, which repetition turn of the gesture to be trained is in question.
The above-disclosed operation sequence is repeated, when the gesture to be trained is repeated. The number of repetition turns is for instance 2-5. When the repetition is stopped, the application provides to the interface G-API command StartGesture Training. Parameter of this command is the name of the gesture.
The training procedure continues by command Train, given to an internal module of the

9 Gesture Engine. That module carries out the training algorithm, depicted in context of Fig. 4. Finally, the Gesture Engine provides, by the G-API, to the application re-sponse Gesture Trained. Parameters of this response are the name of the gesture and calculated values of the gesture parameters.
Fig. 7 presents as a sequence diagram an example of a gesture recognizing pro-cedure in a system according to the invention. This example, too, relates to a sys-tem, in which the motion sensor unit is equipped with a button, the state informa-tion of which is brought through the S-API to the Gesture Engine and further to the application. The diagram starts with command StartGestureRecognition provided by the application to the interface G-API. That command has been preceded by the starting of the recognizing procedure in the application and the pressing of the button B. The command contains as parameters the button being used and the gesture timeout, which means the maximum time allowed for the recognition.
Said command causes inside the Gesture Engine command StartGestureCapture to the Gesture Capturer, and this command in turn command SetSensorListener to the interface S-API, as in the training procedure of Fig. 6. Also from that point onwards the operation is equal to Fig. 6 until the Preprocessor provides to the upper level of the Gesture Engine notice FeaturesExtracted. The recognizing procedure then continues so that the Gesture Engine gives to its internal module command Rec-ognize. That module carries out the calculation and evaluation of reference fig-ures, which represent likelihood of the gesture being under recognition with the stored gestures, and makes a decision, as depicted in context of Fig. 5. Subse-quently the Gesture Engine provides, by the G-API, to the application response GestureRecognized provided that a gesture indeed has been chosen. As a pa-rameter of that response is the name of the recognized gesture.
Fig. 8 presents as a sequence diagram another example of a gesture recognizing procedure in a system according to the invention. This example relates to a sys-tem, in which the motion sensor unit is not equipped with a button or it is at least not used. The diagram starts by command DetectStill, provided by the application to the interface G-API. It is in question a still state of the sensor unit.
Because the button is absent, said state has to be separately detected, before storing of mean-ingful gesture signal can be started. Parameters of that command are the still state duration required and the timeout, which means the maximum time allowed for the still state detection. Said command causes inside the Gesture Engine command DetectStill to the Gesture Capturer, and this command in turn command SetSen-sorListener to the interface S-API. Afterwards the S-API provides to the Gesture Capturer the samples of the sensor signals in data packets. This transfer contin-ues, until an internal module of the Gesture Capturer observes that the sensor unit has been for a certain period in the still state and gives a notice DeviceStillDe-tected. The Gesture Capturer provides to the Gesture Engine response DeviceStill 5 and to the S-API command SetSensorListener with a parameter causing the sam-pling to stop. The Gesture Engine in turn provides by the G-API response De-viceStill to the application.
The procedure continues by command StartGestureRecognition provided by the application to the interface G-API. Command parameters are the matter that no

10 button is used and the gesture timeout, which means the maximum time allowed for the gesture performing. That command causes inside the Gesture Engine com-mand StartGestureCapture to the Gesture Capturer. Based on this command the Gesture Capturer in this case starts the still state detection function and provides to the S-API command SetSensorListener. After that the S-API again provides to the Gesture Capturer the samples of the sensor signals in data packets, which transfer continues, until an internal module of the Gesture Capturer observes that the sensor unit has been a certain period in the still state. The Gesture Capturer then provides to the S-API command SetSensorListener with a parameter causing the sampling to stop and gives to its internal module command FindActualGesture, which module cleans the captured raw data deleting, according to certain criteria, from it the parts, which probably do not belong to the actual gesture. When the irrelevant data is deleted, the Gesture Capturer provides to the upper level of the Gesture Engine response GestureCaptured, by which the actual gesture data is informed. The Gesture Engine then provides to the Preprocessor command Normalize (actual gesture data), which starts the processing of the actual gesture data. The Preprocessor carries out the data normalization and quantization, and provides to the upper level of the Gesture Engine notice FeaturesExtracted, as in the procedures of Figs. 6 and 7. The recognizing procedure continues from that point as in Fig. 7, when the Gesture Engine carries out the calculation and evaluation of reference figures, which represent likelihood of the gesture being under recognition with the stored gestures, and makes a gesture decision.
Finally the Gesture Engine also in this case provides, by the G-API, to the application response GestureRecognized provided that a gesture indeed has been chosen.
As a parameter of that response is the name of the recognized gesture.
Also the training procedure can be implemented without a button. In that case the difference with the sequence of Fig. 6 corresponds to the difference between se-

11 quencies of Figs. 8 and 7: When the situation presumes, it is waited until the sen-sor unit is in the still state.
The recognizing procedure can also be extended to concern a series of succes-sive gestures. In that case the recognition of the first gesture happens as in Fig. 8.
The recognition of the next gesture starts either immediately without any command from the application or on grounds of a command and after a still state again has been detected.
Fig. 9a presents an example of a mobile terminal according to the invention.
The mobile terminal MSA has one application or more, controllable by means of ges-tures. An application can be e.g. an activity being included in the basic implemen-tation of the mobile terminal, such as changing to a certain menu, sending a text message or some camera application. An application also can be a game being originally located in the mobile terminal or loaded later to it. For that kind of appli-cations the mobile terminal is provided with processing software of the gesture signals, which software comprises a trainer for modeling gestures and a recog-nizer for recognizing gestures. The interface program between the processing software and an application controllable by gestures forms a general purpose in-terface to get specified commands from the application and to provide specified responses to the application. The sensor unit SUA is placed inside the cover of the mobile terminal. That matter limits the usable applications to be of the type, that do not require watching the display during the gesture control.
Fig. 9b presents another example of a mobile terminal according to the invention.
The mobile terminal MSB is from the view point of invention similar to the mobile terminal MSA in Fig. 9a. The difference is that the sensor unit SUB belonging to the system now is an external device. The data transfer between the sensor unit and the mobile terminal can be based for example on Bluetooth or infrared tech-nology, or can be wired.
As mentioned above, the games form their own group among the applications to be controlled by gestures. A commercial game application can contain the pa-rameter values of the gestures to be used in the game, which values are stored in the gesture library of the Gesture Engine when the game is started. The game may be a spell game by nature, whereupon the hand motions have apparent magical effect on the game events. The gestures can be different by skill level.
The tougher gesture a player succeeds to make in a certain situation, the more powerful effect that gesture has. The grading may regard also an individual ges-

12 ture. Although a player does not succeed to make it well, the Gesture Engine cal-culates a reference figure and provides it to the application, on condition that the gesture is distinguished from other gestures. The effect on the game is naturally the smaller, the smaller the reference figure is. If a score is calculated for the player, points are granted the more, the tougher gestures he has performed, and the more accurately he has performed those gestures. The game can be played by one or more people. In the latter case the implementation can be a network game such that e.g. two players have the terminals of their own, and the gesture information is transferred to the opponents terminal for instance by using the GPRS (General Packet Radio Service). A player makes e.g. an attack by means of a certain gesture, the opponent sees the attack on his own terminal and de-fends by trying to make a sufficiently effective countergesture or a sequence of weaker gestures in a defined time.
A game application can also be executed as a background program so that a player makes something else at the same time. The player e.g. has joined a net-work game of numbers of players. When an action has been directed at his figure, the game application in the terminal of the player in question displaces other appli-cations and shows what is happening.
Two persons can also play with a single device. In that case there has to be also two sensor units, and each sensor data packet contains information, a data of which player is in question.
A game may also be programmed so that it allows to train and bring new gestures into use. For instance the device is trained in a relatively complicated motion se-quence, and the game would simply be such that the players try to repeat the mo-tion sequence, each in turn, and the application gives points. In the description of Fig. 4 it was already explained that user-independent trained gesture models can be transferred from a device to another device through the Internet. For example a network operator can offer a game service such that people having a terminal ac-cording to the invention can load trained gesture models therefrom.
A system according to the invention is described above. The implementation of the invention in its different points can naturally deviate from what is presented. The commands and responses of the interface G-API according to the invention can be specified in a different way. Working up the sensor data to a form suitable for the HMM can be implemented also by some other process than by data normalization

13 and quantization subsequent thereto, occurring in Figs. 4 and 5. For both training and recognizing can be used, instead of the whole HMM, some other solution, such as neural network or Bayesian network technology. The starting and com-pleting of a gesture can be informed, instead of a button, e.g. by voice control in the case of devices, which have speech recognition activity. Voice messages can also be used in contrary direction so that an application informs via Gesture En-gine the user of certain situations by means of the device's audio part and speaker. For that purpose there is also a command of its own. The inventional idea can be applied in different ways within the scope defined by the independent claims 1 and 19.

Claims

What is claimed is:

1. A method comprising:
receiving a representation of a training hand gesture by capturing at least two three-dimensional points of the training hand gesture;
receiving an indication of a command;
associating the training hand gesture with the command;
with a processor, in response to identifying a subsequent hand gesture as the training hand gesture, executing the command; and calculating a likelihood of the training hand gesture to be recognized, based on the training hand gesture and at least one additional trained hand gesture.

2. A method according to claim 1, wherein capturing a training hand gesture comprises:
capturing at least one repetition of the training hand gesture; and normalizing the at least one repetition.

3. A method according to claim 1 or 2, wherein identifying a subsequent hand gesture comprises accessing a codebook of hand gestures provided by more than one user.

4. A method according to any one of claims 1 to 3, further comprising:
causing transmission of the training hand gesture and associated command to a device different from a device on which the training hand gesture is captured.

5. An apparatus comprising at least one processor and at least one memory including computer program code comprising instructions which, when executed by the at least one processor, cause the apparatus to at least:
receive an indication of a training hand gesture by capturing at least two three-dimensional points of the training hand gesture;
receive an indication of a command;
associate the training hand gesture with the command;
in response to identifying a subsequent hand gesture as the training hand gesture, execute the command; and calculate a likelihood of the training hand gesture to be recognized, based on the training hand gesture and at least one additional trained hand gesture.

6. An apparatus according to claim 5, wherein capturing a training hand gesture comprises:
capturing at least one repetition of the training hand gesture; and normalizing the at least one repetition.

7. An apparatus according to claim 5 or 6, wherein identifying a subsequent hand gesture comprises accessing a codebook of hand gestures provided by more than one user.

8. An apparatus according to any one of claims 5 to 7, wherein the computer program code further comprises instructions which, when executed by the at least one processor, cause the apparatus to:
cause transmission of the training hand gesture and associated command to a device different from a device on which the training hand gesture is captured.

9. A non-transitory computer-readable storage medium having computer-executable program code instructions stored therein, the computer-executable program code instructions, when executed, carrying out:
receiving an indication of a training hand gesture by capturing at least two three-dimensional points of the training hand gesture;
receiving an indication of a command;
associating the training hand gesture with the command;
in response to identifying a subsequent hand gesture as the training hand gesture, executing the command; and calculating a likelihood of the training hand gesture to be recognized, based on the training hand gesture and at least one additional trained hand gesture.

10. A non-transitory computer-readable storage medium according to claim 9, wherein capturing a training hand gesture comprises:
capturing at least one repetition of the training hand gesture; and normalizing the at least one repetition.

11. A non-transitory computer-readable storage medium according to claim 9 or 10, wherein identifying a subsequent hand gesture comprises accessing a codebook of hand gestures provided by more than one user.

12. A non-transitory computer-readable storage medium according to any one of claims 9 to 11, further comprising computer-executable program code instructions which, when executed, carry out:
causing transmission of the training hand gesture and associated command to a device different from a device on which the training hand gesture is captured.