GB2400199A

GB2400199A - A method of evaluating a computer log file

Info

Publication number: GB2400199A
Application number: GB0307844A
Authority: GB
Inventors: Adrian Sack
Original assignee: Ideaworks 3D Ltd
Current assignee: Ideaworks 3D Ltd
Priority date: 2003-04-04
Filing date: 2003-04-04
Publication date: 2004-10-06
Also published as: GB0307844D0

Abstract

A method of evaluating a record of a session of user interactivity with a first program, the first program is run on a remote terminal and contains a set of rules; the method comprises the following steps: first providing the log file as an input to a second program, running the second program, which reconstructs at least a portion of the of the original user session, by being functionally identical to the first program at least in respect of the evolution of at least one parameter, and evaluating a portion of the reconstructed session based on the parameters.

Description

A method of Evaluating a Record of an Original Session of User Activity

Anti-Hack Protection System In the world of multiplayer gaming, one common service provided to garners is the ability to upload high scores to a central repository over a network. One of the major problems facing providers of such services is the threat of hacking, with hackers developing ever more sophisticated techniques for defrauding these systems. The motivations of these hackers are diverse and sometimes poorly understood, but they are often highly determined and very skilled. They pose a threat at a number of different layers in the client-server architecture (such as Black Box), as there are potential vulnerabilities in both software and hardware on the client.

The threats can be considered at three levels, each requiring a different kind of protection. Firstly, there is the approach of trying to upload fraudulent scores to the server from a terminal. Secondly, there is the approach of attempting to create a fraudulent new recording by modifying one of the existing recordings. Thirdly, there is the possibility of modifying either the client application or hardware platform such that the player has an unfair advantage. See Figure 1.

According to the present invention there is provided a method of evaluating a record of an original session of user interactivity in which a user interacts on a remote terminal with a first program which contains a set of rules, the method comprising the steps of: a) providing the record of the session as an input to a second program; b) running the second program with the record of the session as an input to reconstruct at least a portion of the original session; and c) evaluating a portion of the reconstructed session, wherein the second program is functionally identical to the first program at least in respect of the evolution of at least À . À À À À À À À À À e À À À À À À À À À À À À. À À À À À À À À À À.e À one parameter relevant to the evaluation.

Preferably, the record of the session includes one or more captured user inputs to the remote terminal.

Conveniently, the one or more captured user inputs comprise keystrokes.

Alternatively, the one or more captured user inputs comprise inputs from any analog or digital user input device such as a light gun, mouse, jogwheel, light pen, joy-stick, tracker-ball, touch-sensitive tablet or sound-activated system.

Advantageously, the record of the session is compressed to form a compressed record for transmission by the remote terminal, the method further comprising the step of decompressing the compressed record.

Preferably, the record of the session is indexed with reference to one or more points within the execution process of the first program.

Conveniently, the first and second programs each have a state variable which is volatile during running of the programs and the state of the variable is recorded in the record of the session, the state variable comprising a parameter relevant to the evaluation, the evaluating step comprising: comparing, at a point common to the original session and the reconstructed session, the state of the variable in the record of the session with the state of the same variable in the reconstructed session.

Advantageously, the state variable is sampled on a plurality of occasions and the record of the session includes those sampled variables and the user input between the respective samples.

Preferably, the evaluating step comprises evaluating with reference to more than one sampled state variable. À À Àe

À e.e À À ..

Conveniently, the first and second programs each generate an output which for the first program is recorded in the record of the session, the output comprising a parameter relevant to the evaluation, the evaluating step comprising comparing, at a point common to the original session and the reconstructed session, the output recorded in the record of the session with the output of the second program.

Advantageously, the evaluation step comprises confirming whether the evolution of the at least one parameter in the portion of the reconstructed session adheres to the set of rules at a point common to the original session and the reconstructed session.

Conveniently, the point common to the original session and the reconstructed session is at the end of the original session.

Alternatively, the point common to the original session and the reconstructed session is at a pre-designated point during the original session.

Preferably, the comparison is carried out at a plurality of designated points.

Conveniently, the session is a gaming session.

Advantageously, the parameter is a measure of user performance or a result at a given point in the game.

Preferably, the method comprises the further step of encrypting the record of the session.

Advantageously, the first and second programs each have a program variable which is volatile during running of the programs and the encryption utilises an encryption key which is generated as a function of one or more parameters including the volatile program variable in the first program, the generated encryption key encoding the record of the session.

À e À À À À À À ÀÀ À . À À -a-e À::: À. ÀÀ::: À À Àe. ..

Conveniently, the encryption key is generated as a function of the one or more parameters including the same volatile program variable in the second program for the purpose of decrypting the record of the session.

Alternatively, the first and second programs each have a set of program variables which are volatile during running of the programs and the encryption utilises an encryption key which is generated as a function of the one or more parameters including the set of volatile program variables in the first program, the generated encryption key encoding the record of the session.

Preferably, the encryption key is generated as a function of the one or more parameters including the same set of volatile program variables in the second program for the purpose of decrypting the record of the session.

Conveniently, the encryption key is regenerated at intervals.

Advantageously, the remote terminal has a unique identifier which is encrypted with the record of the session.

Preferably, the remote terminal is a mobile telephone and the unique identifier is an IMEI number of the mobile telephone.

Conveniently, at least one time-stamp is generated and supplied to the remote terminal, the method comprising the further step of adding the at least one time-stamp to the record of the session.

Advantageously, the evaluation step includes evaluating the portion of the reconstructed session to determine with reference to the at least one time-stamp whether the original session or any part thereof has a duration which differs from an expected duration by a threshold period.

Conveniently, a plurality of time-stamps and sequential portions of the reconstructed session are evaluated to check the rate of transmission of the record of the session À . . À À a À À e À-. À À- À . À À ea À À . À À À .. À . . and/or speed of execution of the first program at the remote terminal.

Alternatively, the encryption key is generated as a function of one or more parameters including at least one time-stamp and is supplied to the remote terminal.

Preferably, a plurality of time-stamps are generated according to a set pattern.

Conveniently, the generation of the or each time-stamp is triggered by one or more predetermined events occurring, or stages being reached, in the first program.

Advantageously, the remote terminal requests of a trusted host computer for a time- stamp which is sent to the remote terminal.

Preferably, the host computer stores a record of the or each time-stamp and the remote terminal to which the or each time-stamp was sent for use as the parameter for evaluation.

Conveniently, the host computer stores a record of the session being evaluated.

Advantageously, the host stores a record of a remote terminal identifier.

Preferably, the rate of transmission of the record of the session to a host is monitored at the host.

Conveniently, the record of the session is streamed to a host computer for evaluation.

Advantageously, the record of the session is sent to a host computer for evaluation at the end of the original session.

Preferably, the record of the session is sent to a host computer for evaluation during the original session.

À e À e -e À À.

À e e e À e ee e À e À e e e e À. À-.

Conveniently, the record of the session comprises one or more samples of the execution time of at least a portion of the session and the evaluation comprises comparing the run-time of the portion of the reconstructed session with the sampled run-time of the known section of the original session.

Advantageously, records of multiple original sessions are stored on the host computer for subsequent evaluation.

Preferably, the method further comprises the step of reconstructing part of the original session using a known original state of the session at a given point.

Conveniently, the given point is the start of the original session.

Advantageously, the original session is reconstructed in its entirety.

Preferably, the method further comprises the step of sending at least a part of the record of the original session to a remote terminal to be used as an input to a program on the remote terminal subsequent to the record of the original session being evaluated.

According to a further aspect of the present invention there is provided a method of reproducing at least part of an original session of user interactivity in which a user interacts on a remote terminal with a first program, wherein the method comprises the steps of: a) receiving the record of the session; b) running a program with the record of the session as an input to reconstruct at least a portion of the original session, wherein the program is functionally identical to the first program so as to allow playback of at least a portion of the original session.

Conveniently, the reconstruction of the playback session is carried out on the same remote terminal from which the record of the original session was provided, the first program and the program running the record of the session being the same.

À e À e À À À À À-. À À À ÀÀ À À À À À À À À À À À À À À À . - ...

Alternatively, the reconstruction of the playback session is carried out on another remote terminal.

According to a still further aspect of the present invention there is provided a method for checking at a terminal that the terminal is running at a pre-deterrnined running speed comprising comparing two independent timing signals one of which reflects the running speed of the execution of a program on a processor of the terminal.

Conveniently, one of the independent timing signals is received as a transmission to the terminal.

Advantageously, the transmission is a radio transmission.

First Level - Fraudulent Scores It would be fairly straightforward for a hacker to try to upload a fake high score. Black Box protects against this by requiring high scores to be authenticated by a valid game recording as described below. We protect against this as follows: À A technology enabling highly compressed recordings to be made of the progress of a video game session by ongoing logging of user key-press inputs.

These records are indexed by the display frames of the game. This enables an identical game session to be readily reproduced from the recorded inputs.

Use of the recordings detailed above to provide a mechanism to assure the integrity and validity of end user game high scores, that defeats many of the hacking strategies that are often adopted to defraud high score systems. The records are used to corroborate and authenticate a recorded score, by replaying the recordings through a game state engine that mimics the behaviour of the original game.

Second Level - Fraudulent Game Recordings A dedicated hacker may try to create game recordings by examining the format of an existing recording and attempting to modify it. Black Box mitigates this by use of a sophisticated shifting encryption system to encode the recordings.

A mechanism ensuring a secure level of encryption of the recordings above by generating frequently changing encryption keys from samples of volatile game state variables. This mechanism assures the technical difficulty of any attempt to produce a valid falsified recording.

À e e e À À e e a e e e e e e e e e e e e eve Àe Third Level - Modified Game Environment A determined hacker can modify The hardware or software environment to give them I unfair advantage, for example by having a slowrunning version of the game. Black Box deals with this by using server timestamps to verify that the game is running at the expected rate.

À The input recordings can be streamed in real time over the network to the server system in order to ensure that the game is progressing at the expected rate. This provides a verification that the game and related hardware has not been modified to operate at a slower speed.

À An alternative mechanism to that detailed above is to register the occurrence of well-specified game events (e.g. start, end of game level, end of game) with the server in real time, which is then able to establish, by examination of the game recording, whether the timings indicate that the game ran at normal speed.

À One well known hacking strategy is to run a background process in order to slow the game execution. This is mitigated by recording server and client time stamps at key points in the game, obtained from the system clock. The server I can then examine these timings later to ensure that they indicate a game and terminal running at the expected rate.

Ghost Recordings The input recordings can be used to produce exact reconstructions of the progress of a; game, by replaying them through a game emulator and sampling the game state variables such as the player position. These reconstructions can then be replayed in the game environment within a new game to provide the player with the experience of playing against an opponent "ghost".

A less secure version of the game recording can be generated on the server from the secure version as described previously. This is then downloaded and used by the client. The recording is trusted to be valid, as the server repository is a trusted and secure source due to the aforementioned technologies and so it can be used to re- check the recording after upload. This obviates the need to continually use the secured format in situations where it is inconvenient. By always generating the "ghost" recordings on the server, from the secure file, the high level of anti-hacking security is preserved.

À À À À À À À À e À. e À .e À * À À À À Àe ÀÀÀ À ÀÀÀ À À À.. ... . ! Hacking Strategies and Defences Threat Black Box Defence(s) 1. Sending false high score data to server The recording is used to corroborate the submitted score 2. Creating a fraudulent game recoding a. Encryption using regularly either from scratch or by changing keys requires detailed modifying/combining valid recordings knowledge of game state over time to produce a valid fake.

b. Snapshots of the game state taken at key points can be compared and the changes matched to the intervening input recording 3. Playing game through modified Server times/amps/streaming recordings hardware to slow it down or repeat parts of games 4. Attacks on server infrastructure (e.g. Closed operator network must be denial of service) compromised first 5. Modifying a downloaded "ghost" file Reconstructions of games on server check as a cheat method validity of recordings and outcomes 6. Running a process to deliberately slow check on Client-side run time of known the game speed game sections 7. Writing a control program to simulate Difficult to do on the given hardware human input to the game platform. Very laborious to create a fake high scoring game session.

Further Advantages of the Black Box System In addition to hack protection, Black Box and the Game Developer Kit provide a number of other features.

Minimal Bandwidth Usage The key input recordings are highly compressed compared to continuously capturing the full game state. By further use of a combination of Run Length Encoding and variable length bit fields, the compression is greater still, allowing fast network transfer and reduced cost of storage.

Low Memory Usage ? Fast Rewind of Recordings By inserting full state snapshots within the key recordings, the system can rapidly backtrack to any desired point by loading the previous state and replaying key inputs from this point.

À À e À À À À À À À Àe À À .. À À À À À À À .. a

_ _

Easy Game Integration A simple game-independent interface is provided such that the key input recordings can be streamed to and from the game to enable recording and playback. The native save/load mechanism of the game can be easily reused to provide the full state snapshots.

Single Recording Interface An intuitive user interface is provided that mimics that of a standard video recorder.

Users can quickly learn to record parts of game recordings and send them as movie clips.

Inbuilt Test Harness The key input streaming interface allows a developer to set up automated tests by creating and replaying input recordings. This will greatly reduce the time required for regression testing.

Full Game Restore After Interruption When a game is interrupted by an event such as an incoming call, the fast restore features allow the game to continue from exactly the same point.

Potential Extensions/Ramifications Server Timestamps By registering with the server at key points during the game session, server time stamps can be generated which can be checked for viability alongside a game recording to ensure that the duration of the game was in line with expectations.

Streaming recordings This is an enhancement of the timestamps. The compressed/encrypted game recording data is streamed to the server in real time as the game is being played, allowing the server to determine whether the timings of game events are valid.

Intermediate Game State Snapshots The complete state of game variables is captured in "snapshots" at known stages of the game session in order to allow reconstruction of the game at that point. These "snapshots" can be used to further validate the integrity of the ongoing input recordings between subsequent "snapshots". The cumulative value of the continuously changing variables is compared the to the net change of the same variables between the snapshots.

User Identification and Hacker Blacklisting The system architecture allows the unique identification of users such that hacking attempts can be linked to individual users allowing for blacklisting or other sanctions to be levied.

À À À À À À À À À À À ee. À .e À À e À e À À À Àe e e Competitive Game Verification The recordings described above can be archived on a server for use in comparing streams. Thus in competitive game modes, all tournament outcomes can be independently verified by game reconstructions.

Full Game Reconstruction This allows the state at any point in the game to be reconstructed from the log, by making use of the deterministic nature of the game and a known original state.

This document details the architecture and implementation detail of Black Box as implemented for a cellular mobile device.

Black Box allows for the recording, navigation and playback of game performances by allowing the capture and restoration of game state and user input.

Recording and Playback The Black Box system is implemented as a software layer that sits between the game controller inputs and the game process. The controller states are available to the Black Box recording/compression engine at all times. The engine will sample, compress and store controller input data in its memory cache in real time during game play. The details of this compression are discussed later in this document. The recorder is also able to capture the full game state - these records are known as snapshots.

For reconstruction of a game to be possible, the recordings require a known full initial snapshot of the game at or prior to the start of recording. The complete input recording since this snapshot must always be stored. Any point in the game can then be reconstructed by using the playback functionality.

The game is able to receive input from either the engine output or from the controller input directly, selecting between these with a software switch. Both are equivalent as far as the game is concerned, as they are simply buffered streams of controller input states. A Black Box enabled game that loads into memory will, by default, receive controller inputs directly, bypassing the recorder. See Figure 2.

"Video Recorder" Interface The recording/compression engine is controlled via an intuitive user interface that has playback, record, and shuttle functionality.

At playback, the input to the game is switched to receive from the output of the recorder/compressor. This will first transmit the initial snapshot to the state loader of the game, thus restoring the game to this state. This is followed by a buffered stream containing the key input data captured since the state snapshot. This is fed into the main loop of the program with the screen output disabled, such that the game is logically replayed without rendering to the display. This can generally be done at a much higher speed than that at which the game executes. Once the desired start point À À e À À À - À À À Àe À À À À À ..

for playback is reached, the display can be reactivated and the speed restored to normal. The game then replays in a manner indistinguishable from the original game.

The fast-forward function simply increases the playback rate by streaming the inputs at a higher rate - similar to the game restore functionality but with rendering enabled so that the game visibly executes at the higher speed. Rewind functionality is more complex, requiring for each rendered frame that the snapshot is reloaded and then run forward using the key input recording up to the current point. The design of the recording and playback system is optimised for forward play.

When the user is using the video recorder interface to make a recording, internally the system is simply creating time markers for the start and end of the video clip. The snapshot preceding the start of this clip, the controller input stream, and the marker positions are stored together to constitute a clip. This can be uploaded to a server via the communications layer.

It can then be downloaded later for replay through another instance of the system. It is loaded into the compressor/recorder memory and then played back as before. See Figure 3.

Memory State Snapshots and Delta Architecture Some games do not support saving/loading game state and in certain circumstances it can be difficult to add this functionality. In these circumstances, one option for saving and restoring is to snapshot the entire contents of the process memory of the game.

However, this is very costly in storage space. One way to reduce the space required is to maintain a "delta" snapshot, which represents the changes in process memory since a known previous state. If we have a snapshot representing, say, the start of a level, then we can create a delta snapshot later in the level that contains only the differences between the two. This will contain a large amount of unchanged memory, i. e. many zero values, and therefore lends itself to being compressed. This mechanism can be implemented as an alternative when required, broadening the range of games that can be given this restore functionality. See Figure 4.

Implementation Detail and Features Compression for Minimal Bandwidth Usage Key input recordings are highly compressed compared to continuously capturing the full game state. In the case of Tomb Raider, for example, a key input file will be around 1/2500 of the size of a continuous state recording. This is before any further compression, and relies on knowing the initial game state, which requires the specification of the level to be played (a few bits per recording).

Key input recordings are represented as a set of binary data channels containing the up/down state of the available buttons at every iteration of the game loop. These channel recordings are then individually compressed by use of Run Length Encoding.

This is highly efficient at compressing key input channels, as there tend to be very . À À À À À À À Àe À À À À. À À À À À À ÀÀ À a À - À a long sequences. We typically achieve a further compression ratio of 10 by use of this method.

Key ChannelRecord | Run Length Encoded | Walk Forward 000000111100000000011000000010001 6,4,9,2,7,1,3,1 Turn Left 00000000 1 111111111111000000000000 8, 1 3, 1 2 | Following this, we then store these values in variable length bit fields. This is a simple, fast, low- memory compression technique. It works by segmenting run length values into 2-bit sections ordered from least- to most-significant. A third bit is then added to each to signify whether more bits are to follow. This allows a large range of values to be stored without allocating large bit fields to every value. In use in the gaming context, we find that there is a spectrum comprised predominantly of very short and very long sequences. This variable length field storage lends itself well to this distribution, with the cost of extra punctuation bits being heavily outweighed by the overall compression. We typically achieve a further ? percent compression by using this method.

There are a number of further optimisations that can be made if they are suitably low in processing and memory overhead. For example, there is a second strategy employing our proprietary Derbh predictive statistical coding.

Run Length Binary Variable Bit Field

Representation 1 010 1 10 101 011010 1010 101100 1 00 1 1 00100 001011 1 01010 1000 1111101000 001101101111110 In this table, we give examples of the variable bit field representation and show the extra punctuation bits in bold text.

Using Derbh, a statistical coder is setup to encode a stream of button states. The coder continuously maintains a best estimate of the probability of each button state occurring and uses this to output each button state using the minimum possible number of bits. In this way if the user were to spend most of the game with 'Walk forward' pressed, the 'Walk forward pressed' button state would be given a very high probability. High probability states are allocated short bit patterns and therefore the recording file ends up very small.

In this way the compression problem reduces to being able to assign probabilities correctly. At the most basic level probabilities can be estimated from the total number of occurrences of each button state up to the current time. However, this can be improved on greatly by attempting to correlate different button states.

À . À e. . a. . À . . . A better method of probability prediction would use the previous set of button states to predict the next set. Instead of each button state being counted in a single table as would happen in the basic case above, multiple tables are used to count button states.

The table that is used depends on what the previous button state was. In this way if a press of 'Jump' is frequently followed by a press of 'Right', the table for 'previous input was Jump' would indicate a high count for 'Right', and thus the 'Right' button press would be output in few bits. This method can be extended to estimate probabilities from any number of previous input states. Low Memory Usage The compression is implemented in real time as the key

inputs are received, with little state required by the compressor itself. We retain only the compressed data in storage, and so the overall memory overhead is kept very small.

Fast Rewind of Recordings By inserting full state snapshots within the key recordings, the system can rapidly backtrack to any desired point by loading the previous state and replaying key inputs from this point. The frequency of state snapshots can be customised to suit a particular usage context. This can be chosen to optimise access time or to conserve memory, depending on the size of a game state snapshot for the particular game.

A further compression could be applied if the frequency is high by storing compressed differences between subsequent states, but the additional complexity and overhead may not be justified by the space benefit.

This architecture also supports games that allow saving state only at infrequent points e.g. start of each level.

Easy Game Integration A simple game-independent interface is provided such that the key input recordings can be streamed to and from the game to enable recording and playback. When there is a native save/load mechanism in the game, it can be easily reused to provide the full state snapshots. Otherwise the developer will need to capture the relevant variables if they require this functionality. The interface does not specify the format of this state data, but simply accepts and returns a data buffer.

Single Recording User Interface An intuitive user interface is provided that mimics that of a standard video recorder.

Users can quickly learn to record parts of game recordings in order to upload them as movie clips or replay chosen sequences.

e 1. a À À e e e -e Àa.

e. ....

Full Game Restore After Interruption When a game is interrupted by an event such as an incoming call, the fast restore features detailed above allow the game to continue from exactly the same point.

À e e e e e e e e e e e e can À e e ese e e e e e e e e c. e e

Claims

1. A method of evaluating a record of an original session of user interactivity in which a user interacts on a remote terminal with a first program which contains a set of rules, the method comprising the steps of: a) providing the record of the session as an input to a second program; b) running the second program with the record of the session as an input to reconstruct at least a portion of the original session; and c) evaluating a portion of the reconstructed session, wherein the second program is functionally identical to the first program at least in respect of the evolution of at least one parameter relevant to the evaluation.

2. A method according to Claim 1, wherein the record of the session includes one or more captured user inputs to the remote terminal.

3. A method according to Claim 2, wherein the one or more captured user inputs comprise keystrokes.

4. A method according to Claim 2, wherein the one or more captured user inputs comprise inputs from any analog or digital user input device such as a light gun, mouse, jog-wheel, light pen, joy-stick, tracker-ball, touch-sensitive tablet or sound- activated system.

5. A method according to any preceding claim wherein the record of the session is compressed to form a compressed record for transmission by the remote terminal, the method further comprising the step of decompressing the compressed record.

À e À . . . ... . . À À À . À .

6. A method according to any preceding claim wherein the record of the session is indexed with reference to one or more points within the execution process of the first program.

7. A method according to any preceding claim, wherein the first and second programs each have a state variable which is volatile during running of the programs and the state of the variable is recorded in the record of the session, the state variable comprising a parameter relevant to the evaluation, the evaluating step comprising: comparing, at a point common to the original session and the reconstructed session, the state of the variable in the record of the session with the state of the same variable in the reconstructed session.

8. A method according to Claim 7, wherein the state variable is sampled on a plurality of occasions and the record of the session includes those sampled variables and the user input between the respective samples. I

9. A method according to any preceding claim, wherein the evaluating step comprises evaluating with reference to more than one sampled state variable.

l O. A method according to any preceding claim, wherein the first and second programs each generate an output which for the first program is recorded in the record of the session, the output comprising a parameter relevant to the evaluation, the evaluating step comprising comparing, at a point common to the original session and the reconstructed session, the output recorded in the record of the session with the output of the second program.

11. A method according to any preceding claim, wherein the evaluation step comprises confirming whether the evolution of the at least one parameter in the portion of the reconstructed session adheres to the set of rules at a point common to the original session and the reconstructed session.

12. A method according to any one of Claims 7 to 11, wherein the point common to the original session and the reconstructed session is at the end of the original À e À e À À . À . ... . . . À e À .e À . . . . . . À À À. À. À i session.

13. A method according to any one of Claims 7 to 11, wherein the point common to the original session and the reconstructed session is at a predesignated point during the original session.

14. A method according to claim 13, wherein the comparison is carried out at a plurality of designated points.

15. A method according to any preceding claim, wherein the session is a gaming session.

16. A method according to Claim 15, wherein the parameter is a measure of user performance or a result at a given point in the game.

17. A method according to any preceding claim, comprising the further step of encrypting the record of the session.

18. A method according to Claim 17, wherein the first and second programs each have a program variable which is volatile during running of the programs and the encryption utilises an encryption key which is generated as a function of one or more parameters including the volatile program variable in the first program, the generated encryption key encoding the record of the session.

l 9. A method according to Claim 18, wherein the encryption key is generated as a function of the one or more parameters including the same volatile program variable in the second program for the purpose of decrypting the record of the session.

20. A method according to Claim 17, wherein the first and second programs each have a set of program variables which are volatile during running of the programs and the encryption utilises an encryption key which is generated as a function of the one or more parameters including the set of volatile program variables in the first program, the generated encryption key encoding the record of the session.

À e À e À. e Àe À e e À e e ee e - À À e e e À À -

21. A method according to Claim 20, wherein the encryption key is generated as a function of the one or more parameters including the same set of volatile program variables in the second program for the purpose of decrypting the record of the session.

22. A method according to any one of Claims 17 to 21, wherein the encryption key is regenerated at intervals.

23. A method according to any one of Claims 17 to 22, wherein the remote terminal has a unique identifier which is encrypted with the record of the session.

24. A method according to Claim 23, wherein the remote terminal is a mobile telephone and the unique identifier is an IMEI number of the mobile telephone.

25. A method according to any preceding claim, wherein at least one timestamp is generated and supplied to the remote terminal, the method comprising the further step of adding the at least one time-stamp to the record of the session.

26. A method according to Claim 25, wherein the evaluation step includes evaluating the portion of the reconstructed session to determine with reference to the at least one time-stamp whether the original session or any part thereof has a duration which differs from an expected duration by a threshold period.

27. A method according to Claim 26 wherein a plurality of time-stamps and sequential portions of the reconstructed session are evaluated to check the rate of transmission of the record of the session and/or speed of execution of the first program at the remote terminal.

28. A method according to any one of Claims 17 to 24, wherein the encryption key is generated as a function of one or more parameters including at least one time-stamp and is supplied to the remote terminal. À e .

. e..

À À À À À e.

À À . À

29. A method according to any one of Claims 25 to 28, wherein a plurality of time-stamps are generated according to a set pattern.

30. A method according to any one of Claims 25 to 29, wherein the generation of the or each time-stamp is triggered by one or more predetermined events occurring, or stages being reached, in the first program.

31. A method according to Claim 30, wherein the remote terminal requests of a trusted host computer for a time-stamp which is sent to the remote terminal.

32. A method according to any one of Claims 25 to 31, wherein the host computer stores a record of the or each time-stamp and the remote terminal to which the or each time-stamp was sent for use as the parameter for evaluation.

33. A method according to any one of Claims 25 to 32, wherein the host computer stores a record of the session being evaluated.

34. A method according to any one of Claims 25 to 33, wherein the host stores a record of a remote terminal identifier.

35. A method according to any preceding claim, wherein the rate of transmission of the record of the session to a host is monitored at the host.

36. A method according to any preceding claim, wherein the record of the session is streamed to a host computer for evaluation.

37. A method according to any preceding claim, wherein the record of the session is sent to a host computer for evaluation at the end of the original session.

38. A method according to any preceding claim, wherein the record of the session is sent to a host computer for evaluation during the original session. À e

À . À . À-. À .. e À À À e.

À À À

39. A method according to any preceding claim, wherein the record of the session comprises one or more samples of the execution time of at least a portion of the session and the evaluation comprises comparing the run- time of the portion of the reconstructed session with the sampled run- time of the known section of the original session.

40. A method according to any preceding claim, wherein records of multiple original sessions are stored on the host computer for subsequent evaluation.

41. A method according to any preceding claim, further comprising the step of reconstructing part of the original session using a known original state of the session at a given point.

42. A method according to claim 41, wherein the given point is the start of the Original session.

43. A method according to Claim 42 wherein the original session is reconstructed in its entirety.

44. A method according to any preceding claim, wherein the method further comprises the step of sending at least a part of the record of the original session to a remote terminal to be used as an input to a program on the remote terminal subsequent to the record of the original session being evaluated.

45. A method according to any preceding claim, wherein a statistical analysis is carried out on one or more records of sessions to identify behavioural patterns.

46. A method according to Claim 45, wherein the statistical analysis is carried out on the user input in the one or more records of sessions to identify behavioural patterns.

À e e e e e e e e e e Àee e e e eve e e e e e ee e e e e e e e

47. A method according to Claim 45, wherein the statistical analysis is carried out on the reconstruction from the one or more records of sessions to identify behavioural patterns.

48. A method of reproducing at least part of an original session of user interactivity in which a user interacts on a remote terminal with a first program, wherein the method comprises the steps of: a) receiving the record of the session; b) running a program with the record of the session as an input to reconstruct at least a portion of the original session, wherein the program is functionally identical to the first program so as to allow playback of at least a portion of the original session.

49. A method according to Claim 48, wherein the reconstruction of the playback session is carried out on the same remote terminal from which the record of the original session was provided, the first program and the program running the record of the session being the same.

50. A method according to Claim 48, wherein the reconstruction of the playback session is carried out on another remote terminal.

51. A method for checking at a terminal that the terminal is running at a pre- determined running speed comprising comparing two independent timing signals one of which reflects the running speed of the execution of a program on a processor of the terminal.

52. A method according to claim 51, wherein one of the independent timing signals is received as a transmission to the terminal.

53. A method according to Claim 52, wherein the transmission is a radio transmission.

À e À À e À À À e ee. e À À .. Be, e e..

54. A method according to any preceding claim, wherein a seed is generated and sent to the remote terminal to alter the initial state of a session so that the initial state of the session cannot be predicted at the remote terminal.

SS. A method substantially as hereinbefore described with reference to and as shown in the accompanying drawings.

56. Any novel feature or combination of features disclosed herein.

À À . À . À .. . À . . . . .