GB2555596A

GB2555596A - System and method of input verification

Info

Publication number: GB2555596A
Application number: GB1618480.6A
Authority: GB
Inventors: Fabian Istvan
Original assignee: Sony Interactive Entertainment Inc
Current assignee: Sony Interactive Entertainment Inc
Priority date: 2016-11-02
Filing date: 2016-11-02
Publication date: 2018-05-09
Also published as: GB201618480D0

Abstract

An input validation method in which the timings between at least two input events in a sequence are monitored. Upon observing an input event, the method predicts a timing from that event to a next input event in the monitored sequence. If the method detects that the next obtained input event occurs within a predetermined threshold deviation of the predicted timing, this input event is classified as machine generated. The input events may correspond to a sequence of a plurality of physical inputs, which may be obtained from a videogame to which the inputs are directed. If a predetermined number of consecutive input events are labelled as artificial, cheating may be declared. The method may be applied to detect the use of auto-fire, rapid-fire or turbo buttons in video games. Also disclosed are a computer readable medium and a system employing this method.

Description

(71) Applicant(s):

Sony Interactive Entertainment Inc.

1-7-1 Konan, MinatoKu 108-8270, Tokyo, Japan (72) Inventor(s):

Istvan Fabian (74) Agent and/or Address for Service:

D Young & Co LLP

120 Holborn, LONDON, EC1N 2DY, United Kingdom (51) INT CL:

A63F 13/75 (2014.01) A63F 13/44 (2014.01) G06F 21/44 (2013.01) (56) Documents Cited:

GAMERSFIRST Internet forum discussion, 21 July 2014 to 23 July 2014. FairFight middleware and Game controllers with rapidfire button. Available from: http://forums.gamersfirst.com/topic/356524fairfight-middleware-and-game-controllers-withrapidfire-button/

KR 2011/0032839

GAMEBLOCKS FAQ's. 4 February 2016. Available from: https://www.gameblocks.com/faqs (58) Field of Search:

INT CLA63F, G06F

Other: EPODOC, WPI, Patent Fulltext, Internet searching (54) Title ofthe Invention: System and method of input verification

Abstract Title: Method and system for input verification, and a computer readable medium for performing the method (57) An input validation method in which the timings between at least two input events in a sequence are monitored. Upon observing an input event, the method predicts a timing from that event to a next input event in the monitored sequence. If the method detects that the next obtained input event occurs within a predetermined threshold deviation ofthe predicted timing, this input event is classified as machine generated. The input events may correspond to a sequence of a plurality of physical inputs, which may be obtained from a videogame to which the inputs are directed. If a predetermined number of consecutive input events are labelled as artificial, cheating may be declared. The method may be applied to detect the use of auto-fire, rapid-fire or “turbo” buttons in video games. Also disclosed are a computer readable medium and a system employing this method.

Figure 3

¢1 to νΟ)

u.

rsj

ΙΛ ,ί

^α;α □ ο

1000ms

100ms

10ms

Π I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I

0.1s

1s

10s

100s f

Obtain the input event to input event timing of at least two successive input events in a monitored sequence s310

Predict the timing from the latest obtained input event to the next obtained input event in the monitored sequence s320

Detect whether the next obtained input event occurs within a predetermined threshold deviation of the predicted timing s330

C '

Classify the input event as a machine generated input event \_.

5340

Figure 3

SYSTEM AND METHOD OF INPUT VERIFICATION

The present invention relates to a system and method of input verification.

One source of enjoyment for players of videogames is the competitive aspect provided by multiplayer games. However this enjoyment is undermined if one or more players cheat in some fashion. Cheating becomes more serious still if it ever affects professional players in e-sports competitions.

Accordingly, it is desirable to limit the scope to cheat within videogames.

In a first aspect, an input validation method is provided in accordance with claim 1.

In another aspect, an input validation system is provided in accordance with claim 15.

Further respective aspects and features of the invention are defined in the appended claims.

Embodiments of the present invention will now be described by way of example with reference to the accompanying drawings, in which:

- Figure 1 is a schematic diagram of an input verification device in accordance with embodiments of the present invention.

- Figure 2 is a graph illustrating a derivation of thresholds for input verification in accordance with embodiments of the present invention.

- Figure 3 is a flow diagram of a method of input verification in accordance with embodiments of the present invention.

A system and method of input verification are disclosed. In the following description, a number of specific details are presented in order to provide a thorough understanding of the embodiments of the present invention. It will be apparent, however, to a person skilled in the art that these specific details need not be employed to practice the present invention. Conversely, specific details known to the person skilled in the art are omitted for the purposes of clarity where appropriate.

One means of cheating is to make use of adapted or specially made videogame controllers or controller interface software which provides an ‘auto fire’ function. Such a function can be thought of as simulating a rapid sequence of button actions. The most common sequence is a rapid repeated pressing of a weapons fire button (hence the ‘auto fire’ term), but is not limited to this.

Furthermore in principle the function is not limited to a single button but may relate for example to two or more buttons, for example in the form of a rapidly alternating activation of two buttons, as may be used in a sports game to make a character run. The function may go further still, and reliably output complex button sequences that unlock so-called ‘combo’ functions in a game that conventionally reward user dexterity and skill.

It would be desirable to detect when such a device is being used, and respond appropriately (the response potentially being a choice of a particular videogame designer).

However, problematically whilst the auto fire system may be rapid, it may be designed to be no faster than the best human players; this makes distinguishing between auto fire and human play based on the rapidity of fire very difficult (particularly in the case of professional e-sports, were by definition the players are likely to be highly proficient and more rapid themselves than many normal players).

Accordingly, in an embodiment of the present invention a method of input verification that seeks to address or mitigate this problem is implemented on an entertainment device such as a PlayStation 4 ® and/or a hosting server, as explained later herein. The implementation may be part of the device or server operating system, part of a videogame running on the device and/or server, or part of a middleware library used by a videogame running on the device and/or server.

Consequently will also be appreciated that a system for input verification may take the form of conventional hardware suitably adapted as applicable by software instruction (or by the inclusion or substitution of dedicated hardware).

Thus the required adaptation to existing parts of a conventional equivalent device may be implemented in the form of a computer program product comprising processor implementable instructions stored on a non-transitory machine-readable medium such as a floppy disk, optical disk, hard disk, PROM, RAM, flash memory or any combination of these or other storage media, or realised in hardware as an ASIC (application specific integrated circuit) or an FPGA (field programmable gate array) or other configurable circuit suitable to use in adapting the conventional equivalent device. Separately, such a computer program may be transmitted via data signals on a network such as an Ethernet, a wireless network, the Internet, or any combination of these or other networks.

Referring now to Figure 1, as noted above an example of a conventional computer device is the PlayStation 4 ®. This figure schematically illustrates the overall system architecture of a Sony®

PlayStation 4® entertainment device. A system unit 10 is provided, with various peripheral devices connectable to the system unit.

The system unit 10 comprises an accelerated processing unit (APU) 20 being a single chip that in turn comprises a central processing unit (CPU) 20A and a graphics processing unit (GPU) 20B. The APU 20 has access to a random access memory (RAM) unit 22.

The APU 20 communicates with a bus 40, optionally via an I/O bridge 24, which may be a discreet component or part of the APU 20.

Connected to the bus 40 are data storage components such as a hard disk drive 37, and a Blu-ray ® drive 36 operable to access data on compatible optical discs 36A. Additionally the RAM unit 22 may communicate with the bus 40.

Optionally also connected to the bus 40 is an auxiliary processor 38. The auxiliary processor 38 may be provided to run or support the operating system.

The system unit 10 communicates with peripheral devices as appropriate via an audio/visual input port 31, an Ethernet ® port 32, a Bluetooth ® wireless link 33, a Wi-Fi ® wireless link 34, or one or more universal serial bus (USB) ports 35. Audio and video may be output via an AV output 39, such as an HDMI port.

The peripheral devices may include a monoscopic or stereoscopic video camera 41 such as the PlayStation Eye ®; wand-style videogame controllers 42 such as the PlayStation Move ® and conventional handheld videogame controllers 43 such as the Dual Shock 4 ®; portable entertainment devices 44 such as the PlayStation Portable ® and PlayStation Vita ®; a keyboard 45 and/or a mouse 46; a media controller 47, for example in the form of a remote control; and a headset 48. Other peripheral devices may similarly be considered such as a printer, or a 3D printer (not shown).

The GPU 20B, optionally in conjunction with the CPU 20A, generates video images and audio for output via the AV output 39. Optionally the audio may be generated in conjunction with or instead by an audio processor (not shown).

The video and optionally the audio may be presented to a television 51. Where supported by the television, the video may be stereoscopic. The audio may be presented to a home cinema system 52 in one of a number of formats such as stereo, 5.1 surround sound or 7.1 surround sound. Video and audio may likewise be presented to a head mounted display unit 53 worn by a user 60.

In operation, the entertainment device defaults to an operating system such as a variant of FreeBSD 9.0. The operating system may run on the CPU 20A, the auxiliary processor 38, or a mixture of the two. The operating system provides the user with a graphical user interface such as the PlayStation Dynamic Menu. The menu allows the user to access operating system features and to select games and optionally other content.

Returning to the method of input verification, in a first step a sequence of two or more input events are recorded. Given two more input events, a predicted time until the next input event can be calculated. To a first approximation the predicted time of the next input event can be estimated as the average period between previous input events. Optionally only the last N input events may be used in order to provide a rolling average that can therefore slowly adapt to changes in the periodicity. N may correspond to a predetermined number such as 5 or 10, or may correspond to however many input events occur within a predetermined period of time, such as for example over the course of 1 second.

Whilst averaging is an example of a predictive method, others can clearly be considered such as Kalman filter prediction. Again such a predictive method may only use the last N events in order to provide a rolling or adaptive prediction, and/or may weight the periods between recorded events to favour the most recent values.

In any case, the timing or period between one input event and the next input event can be predicted.

Accordingly, the next input event can be recorded and compared with the prediction. If the input event is within ± a threshold deviation from the predicted time, then it is treated as part of the recorded input sequence and contributes towards future predictions.

It will be appreciated from the above discussion that therefore where the next input event occurred later than predicted but within threshold deviation, this will cause the predicted period to be extended by a proportionate amount, whereas where the next input event occurred earlier than predicted within the threshold deviation, this will cause the predicted period to be shortened by a proportionate amount, in dependence upon the prediction method used. Consequently, a drift in the timing of such input events can be tracked within the prediction.

Meanwhile input events that fall outside the threshold deviation are not treated as part of the recorded input sequence.

The threshold deviation itself may be adaptive, initially being a first amount or percentage of the predicted period when only two or a few input events have been recorded, but transitioning to a second amount or percentage of the predicted period as more input events are recorded or the system reaches a steady-state rolling number of recorded input events, where the first amount or percentage is larger than the second amount or percentage.

In other words, the threshold deviation can start comparatively wide before narrowing over time until it reaches a predetermined threshold deviation. This helps to account for possible initial errors in the prediction of the period between input events due to these being based on a statistically small sample.

The predetermined threshold deviation defines a degree of invariance in the input sequence that is considered to be indicative of machine generated inputs to the system. That is to say, the input verification method is based on the assumption that a human being cannot produce inputs that repeat exactly the same timing or even approximate that timing to within the predetermined threshold deviation.

Furthermore, the likelihood of a human being achieving such accurate timing by chance reduces geometrically with each subsequent input.

Accordingly for this method of input verification, where in the timing for a sequence of inputs are detected to be approximately the same to within the predetermined threshold deviation, this is interpreted as indicating that a machine generated input sequence has been used and hence that cheating has occurred. It will be appreciated that this technique may optionally be applied only where a sequence of M input events have been recorded as falling within the predetermined threshold deviation, where M is selected to reduce to an acceptable level the likelihood of the input being achieved by chance by a human being, and/or to account for any bootstrapping of the threshold deviation as mentioned previously herein, in which an initial threshold deviation gets smaller over the first 3, or 4, or 5, ..., or N-l input events, as applicable. Hence the input verification system may output a value indicative of the probability that the input events correspond to an auto firing system, or may only flag the detection of an auto firing system, after a predetermined number of input events successively falling within the predetermined threshold deviation have been detected. Notably the predetermined number of input events may be for the complete game session; hence for example the first 10 inputs may be used to establish a clear pattern within a predetermined threshold deviation, and subsequently any set of three or more inputs falling within that predetermined threshold deviation are flagged as cheat inputs.

It will be appreciated that the above technique can apply to input-event-to-input-event timings of any duration; hence for example it may apply to inputs having a periodicity in the order of 1-60 seconds, such as may be used to re-activate a shield, or retrieve or mine or otherwise gather resources automatically in a massively multiplayer on-line game; or it may apply to inputs having a periodicity in the order of 0.25-1.5 seconds, such as may be used to auto repeat a button in a dancing game. Perhaps most frequently however it may apply to inputs having a periodicity in the order of 0.01-0.25 seconds, which may be used to auto-fire a weapon. More generally however, it can be used to evaluate successive timings for any input event to a game.

Optionally, the predetermined threshold deviation can be a function of the duration; for example, with a duration in the order of 1/10 of a second, the predetermined threshold deviation may be (as a non-limiting example) five milliseconds. Meanwhile if the duration is one minute, the predetermined threshold deviation may be 0.5 seconds.

Notably the percentage represented by these threshold deviations is different in these examples; 5 milliseconds is one twentieth of 0.1 seconds, whilst 0.5 seconds is a one hundred and twentieth of seconds. This reflects an assumption that, for example, the average user has a finite reliable physical accuracy in enacting a button press or similar user input that is in the order of 20 ms, but has a mental accuracy for timekeeping in the order of 1% of the current time.

Hence referring to Figure 2 for example, the average user may be assumed to have a periodic input accuracy as defined by graph ‘A’, where the target periodicity is given on the x-axis and the average accuracy is given on the y-axis. As can be seen, one may assume a maximum accuracy in the order of 20 ms limited by physical ability until the periodicity is such that one percent of the period is greater than 20 ms, after which is dominated by mental accuracy. It will be appreciated that this is a crude approximation and that individual users are subject to variation. Furthermore, it is possible that a user may be more accurate at their maximum button pressing speed because in this circumstance the periodicity is determined by the physical properties of their fingers such as tendon elasticity, and consequently at least for a brief period of time until fatigue changes their behaviour, their fingers may exhibit a more closely periodic maximum tapping speed. This is indicated by graph A' in Figure 2. It may also be assumed that the maximum rate at which a user can press a button for a short burst of time is roughly 15 presses per second. However, this assumption may change depending on the nature of the button; for example a trigger button may be difficult to pull more than 10 times per second.

Consequently, a machine driven input may be assumed where the periodicity of the input events is more accurate than is assumed to be possible by a human being, typically by an accuracy differential ‘δ’ to reduce false positives. This accuracy differential itself may be a function of the periodicity in a similar manner to the threshold deviation. An example threshold accuracy is provided by graph ‘B’ in Figure 2.

Accordingly, the input validation method can set the predetermined threshold deviation to the value on the y-axis of graph ‘B’ for a given timing duration value on the x-axis of graph ‘B’; and any input-event-to-input-even timing t falling within the predetermined threshold deviation can be assumed to be a machine generated input.

Furthermore it will be appreciated that if the apparent button fire rate is higher than is assumed to be physically possible by a human user, then optionally in a first instance this may itself be taken as an indication of cheating, and/or optionally the accuracy threshold can be relaxed for this short frequency range as illustrated in graph B', whilst not crossing the line of graph A or optionally A'.

It will be appreciated that graph A or A' could be derived from empirical data. Furthermore, the variance of that empirical data could also be derived. Consequently graph B or B' could be defined in response to graph A or A', and optionally the accuracy differential δ could be made responsive to the variance relating to graph A or A'; for example δ could correspond two three or four standard deviations from the mean. Assuming a normal distribution for user accuracy, two standard deviations would ensure approximately 98.3% of users could not achieve the predetermined threshold accuracy, whilst three standard deviations would ensure that approximately 99.9% of users could not achieve the predetermined threshold accuracy. Meanwhile four standard deviations would ensure that approximately 99.99% of users could not achieve the predetermined threshold accuracy. Alternatively, δ could simply correspond to being 1.5, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, 50, or 100 times more accurate, as appropriate. It will be appreciated however that the predetermined threshold deviation represented by graph B or B' could instead simply be a fixed value irrespective of the duration on the x-axis, providing that value does not cross graph A or optionally A'.

Using the above techniques, a user cheating with an auto-fire type device or software could be detected if the device or software operated with an input-event-to-input-event timing accuracy greater or equal to that represented by graph B or B'. Furthermore it will be appreciated that specific knowledge of the cheating device or software is not needed to detect it, and that the technique is robust to a degree of variation in the timings generated by the device itself by virtue of the predetermined threshold deviation and the drifting estimate of timing used, as described previously herein.

As noted previously herein, the likelihood of a periodic sequence being generated by chance by a user which has an accuracy greater or equal to that represented by graph the or B' drops with the number of input events in that sequence; consequently the detection or declaration of cheating may require 3, or 4, or 5, ..., N-l or more input events in a row to have such accuracy. The number may depend upon the nature of the videogame and may be a game designer choice, or the choice of a multiplayer host or an e-sports organiser, as appropriate. Again as noted previously, the number may change for repeat detections once a reliable threshold deviation has been established. Furthermore, the number may change depending upon the actual accuracy detected; for example, in addition to the predetermined threshold deviation, one or more shorter thresholds may be evaluated, notionally narrowing down to a ‘bull’s-eye’ exact accuracy of timing. Consequently the input verification system may, by way of a non-limiting example, declare cheating after three exactly accurate timing repetitions of the button input, but may only declare cheating after seven repetitions of the button input timing to within the predetermined threshold deviation.

Similarly there may be a ‘standard’ and a ‘professional’ setting for detection, wherein for the professional setting, a greater number of input events in a row are required to indicate cheating (since professional players may be more accurate), and/or graph A or A' could be derived from a subset of empirical data corresponding to the top P% most accurate human players in the empirical data set (where P is any suitable number, such as 5), or could be derived from empirical data obtained from testing professional videogame players; similarly the accuracy differential δ could change for the professional setting from, as a non-limiting example, 2.5 standard deviations from the mean to 3.5 or 4 standard deviations, in order to reflect that professional players are likely to belong in that outlier group of legitimate users.

By using a system that detects successive input events that have timing accuracy greater than that assumed to be achievable by users, or greater than that measured to be achievable by at least a subset of users who contributed to the empirical data (or for example those within a first, second, third or fourth standard deviation of the mean, as applicable), advantageously most if not all auto-fire style cheating systems can be detected without advanced knowledge of the individual properties; in particular systems where simple electronics are used to generate a high-speed sequence of input events can be easily detected either because of the absolute speed of input being greater than that assumed to be possible by human, and/or because the periodicity of the input events is close to being perfect, affected only by factors such as electronic component tolerance and thermal changes (which as noted previously can be adapted to by the techniques herein). Meanwhile more sophisticated electronics that deliberately add jitter to input event timing can still generally be detected since typically the jitter will still represent a deviation from ideal periodicity that is less than the predetermined threshold deviation. This is because the predetermined threshold deviation itself is close to but distinct from human accuracy, and cheating devices will typically have little value if they themselves only approach human accuracy. Consequently the techniques disclosed herein have a good probability of catching any auto fire cheating system that generates a sequence of input signals of sufficient speed and accuracy to be of practical benefit to a would-be cheater.

It will be appreciated that periodic inputs may occur in isolated bursts; for example the need to rapidly fire as an enemy may only occur occasionally during gameplay. It will be appreciated therefore that the input verification technique described herein may interpret a gap in input events as signifying the end of a particular input sequence, but store the periodicity and tolerance values derived during that sequence potentially for use to bootstrap the tracking of a subsequent firing sequence.

As was noted previously, different buttons may be subject to different periods between inputs. Consequently each button may be separately analysed using the above techniques. Optionally in order to limit computational overhead, a game may specify for which buttons analysis is relevant; hence for example whilst a button used to summon the game menu is unlikely to be set to auto fire, by contrast a button used to block an attack or collect treasure or fire a weapon may well be a target for cheating.

Also as noted previously, two or more buttons may be used in concert to achieve a certain behaviour. The examples given previously herein included alternating between two buttons to make a videogame character run, but such button combinations are not limited to this and it is possible that sequences of input events may be programmed into a cheating system to enable the use of so-called ‘combo’ features of the game, such as special attack moves and the like. Typically these are activated when a predetermined sequence of buttons are pressed, usually within a time limit, in order to achieve an advantageous behaviour within the game. Normally these combo moves require considerable skill and dexterity, and hence the use of a preprogrammed input sequence will again be cheating.

Such multi-button sequences can be seen as a generalisation of input-event-to-input-event timings for a single button; rather than predicting that the same button is pressed within the predetermined threshold deviation, in this embodiment of the invention the input verification method predicts that the next button in a known combo sequence is pressed within a predetermined threshold deviation.

It will be appreciated that the predetermined threshold deviation in this case may be different to that for sequentially pressing the same button. Furthermore, there may be a separate predetermined threshold deviation for each input-event-to-input-event transition in the sequence.

The actual combo-sequence or sequences that are relevant to the current game may be made available by the game to the input verification system via an API, thereby enabling the verification system to monitor these sequences. Alternatively, for example for legacy games, these, sequences may be input either by a user, a multiplayer host, or an invigilator, or may be supplied by the producer of an input verification system as a combo sequence library in which combo sequences are associated with supported games, and the relevant sequences can be accessed by identifying when the relevant game is run (for example by looking up the name of the main executable file, or detecting a standard notification to the videogame console operating system or network identifying the game, for example as part of an existing trophy system).

As with the single button embodiment, an implementation of a combo sequence that is quicker than could be physically achieved by human being may be taken as an a priori indication of cheating. However again it can be expected that smart cheating systems will input combo sequences at a speed that is very good, but within the normal human range.

In the combo sequence case, the input verification system can evaluate the timing accuracy of the combo either on a button by button basis or on a whole combo basis to determine whether the accuracy is within a predetermined threshold deviation, and if it is then the combo input sequence may be assumed to be machine generated.

For inter-button timing, the relative timing of button presses within the sequence can be recorded for each instance of the sequence encountered during gameplay. Subsequently after the combo has been performed at least two times, an average or more sophisticated prediction of the buttonto-button timings can be determined in a similar manner to that described previously herein, and subsequently evaluated in a similar manner. Hence in effect the input verification scheme estimates a timing template for the combo and detects whether subsequent combo inputs match the respective timings of that template to within their respective predetermined threshold deviations.

As was noted previously, the likelihood of a user achieving by pure chance the higher level of accuracy or invariance implied by inter-button timing falling within a predetermined threshold deviation reduces as the number of times it occurs in succession increases. Consequently for a combo sequence of button presses, successive inter-button timings falling within respective predetermined threshold deviations can provide an increasingly strong indication that the combo is machine generated for sequences of 3, 4, 5 or more buttons. Again the length of sequence after which cheating is declared may be at the discretion of the game designer, a multiplayer host or an invigilator, and/or may be responsive to a detected degree of accuracy of the timings within the predetermined threshold deviation.

For whole combo timing, a predetermined threshold deviation for the total duration of the combo action can be established after two instances of the combo have been performed; thereafter subsequent performances of the combo that fall within the predetermined threshold deviation may be flagged as machine generated. Notably this approach may be more likely to generate false positives because random differences in timing accuracy by a user over a sequence of button presses may serve to cancel each other out rather than accumulate, resulting in an apparent level of accuracy for P button presses that will be greater than the sum of individual accuracies for A separately evaluated button presses. Furthermore, a smart cheating system could deliberately accumulate choose to slightly delay all button presses in one sequence and slightly advance all button presses another sequence to maximise the total variability in the combo. Consequently the whole combo timing approach is more likely to result in the apparent accuracy of machine generated combos overlapping possible accuracy of human generated combos. However for cheating systems that do not employ such sophisticated tactics, the whole, approach is suitable and carries a smaller computational and memory overhead than the more discriminating inter-button approach.

The above techniques have referred to how the input verification system analyses input events that fall within predetermined threshold deviations of predicted button presses; however optionally the input verification system can also process input events that fall outside the predetermined threshold deviations, and hence are assumed to be legitimate user inputs. The input verification system can characterise the timing of these inputs in terms of input event to input event timing and variance over the course of gameplay, and submit this data to a central repository, such as a server run by the manufacturer of the videogame console, and/or the publisher of a particular game. The central repository can calculate this data from a plurality of users to generate graph A or A' for repeated operations of the each button on the controller for rapid-fire cheating, and/or for sequential operations of buttons on the controller for combo cheating. The central repository can then derive a graph B or B', and consequently set predetermined threshold deviations for one or more buttons of the controller, either globally or in association with a particular game, and these threshold can be downloaded back to the videogame console. In this way the console can contribute to modelling of user input behaviour, and can be kept up-to-date with cheat models for the latest games, for example when they are installed on a particular videogame console.

It will be appreciated that graphs B or B' can in practice be represented by just one or more discrete values. For example, a trigger button for a particular game may be used to shoot a gun, and consequently it is only in the context of a rapid-fire action that cheating behaviour would make sense. Consequently the predetermined threshold deviation can be assumed to be a single value corresponding to repeated button presses with a timing shorter than, say 0.3 seconds. Referring to Figure 2, as a non-limiting example, such a value may be ±6ms.

Referring now to Figure 3, in a summary embodiment of the present invention an input validation method comprises:

- in a first step s310, obtaining the input event to input event timing of at least two successive input events in a monitored sequence, as described previously herein;

- in a second step s320, predicting the timing from the latest obtained input event to the next obtained input event in the monitored sequence;

- in a third step s330, detecting whether the next obtained input event occurs within a predetermined threshold deviation of the predicted timing;

and if so,

- in a fourth step s340, classifying the input event as a machine generated input event.

In an instance of this summary embodiment, the input events correspond to the use of one physical input (for example, the pressing of one button, or the movement of a joystick in one direction or within one quadrant, or the tapping of a predetermined input area on a touchscreen corresponding to a single input, etc.).

In an instance of this summary embodiment, the input events corresponding to use of a predetermined sequence of a plurality of physical inputs (for example a succession of different button presses and/or joystick movements, or tapping locations on a touchscreen, or key points within a drawn gesture on a touchscreen, such as but not limited to start and stop points and points of inflection).

In an instance of this summary embodiment, the method comprises the steps of predicting the cumulative timing of the predetermined sequence of input events, detecting whether input events corresponding to the predetermined sequence occur within a predetermined threshold deviation of the predicted cumulative timing, and if so, classifying the sequence of input events corresponding to the predetermined sequence as a machine generated sequence of input events, as described previously herein.

In an instance of this summary embodiment, the predetermined sequence of a plurality of physical inputs is obtained from one or more selected from the list consisting of a videogame to which the input events are directed, and a sequence library in which the predetermined sequence is stored in association with a videogame to which the input events are directed, as described previously herein.

In an instance of this summary embodiment, if the detected timing between the latest obtained input event in the monitored sequence and the next obtained input event occurs within the predetermined threshold deviation of the predicted timing, then the next input event is treated as the last (i.e. latest) input event the monitored sequence, and the detected timing is used in a subsequent prediction of the timing of the next obtained input event. Put the other way, if a subsequent input event falls outside the predetermined threshold deviation for the predicted timing, then it is not classified as machine generated input, and is also not treated as being part of the monitored sequence, either in terms of being treated as the last (i.e. new latest) input in that sequence for the purposes of predicting the timing for the next input, or in terms of the timing of that input contributing to the estimation process used to predict the timing of the next input.

In an instance of this summary embodiment, the predetermined threshold deviation is responsive to the predicted length of time between the latest obtained input event and the next obtained input event in the monitored sequence.

In an instance of this summary embodiment, the predetermined threshold deviation is responsive to measurements of timings between corresponding input events in the monitored sequence enacted by humans. In this instance, the predetermined threshold deviation may be set to be smaller than the deviation measured for a predetermined percentage of human users (for example by setting the predetermined threshold deviation to track the second, third or fourth standard deviation at the shorter end of the measured timings).

In an alternative instance of this summary embodiment, the predetermined threshold deviation is fixed for a given monitored sequence.

In an instance of this summary embodiment the method comprises the step of declaring cheating for a monitored sequence after a predetermined number of successive input events are classified as being machine generated. In this instance, the predetermined number of successive input events is set by one or more selected from the list consisting of, a designer of a game to which the input events are directed, a host of a multiplayer game, to one client of which the input events are directed, and an authorised invigilator, as discussed previously herein. Authorisation to adjust this parameter in the input validation scheme may be obtained by use of a digital signature, key, password or other known security mechanism to identify an authorised user.

In an instance of this summary embodiment, the method comprises the steps of declaring cheating in response to machine generated input events, and signalling to a game to which the input events are directed that cheating has occurred.

A game may respond to cheating one of several different ways; in a multiplayer game for example the avatar of the user whose inputs have been flagged as cheating may be modified to alert other users to a potential issue; for example the avatar may have an exclamation mark above its head. Alternatively or in addition the damage incurred by shots fired using a cheat mechanism may be discounted within the game. Alternatively or in addition a user may be suspended from play for a predetermined period of time, optionally with this period of time increasing with each detected cheat. Further optionally, this increase may be reset after a compliance period in which no cheating has been detected. The strategies are designed to accommodate the possibility that a good player may inadvertently be identified as cheating on rare occasions, and so avoid the user being kicked out of the game or banned immediately due to a false positive. However where the predetermined threshold deviations are set based on timing accuracies assumed or measured to be below those achievable by the vast majority of users (for example based on greater than third or fourth standard deviations from measured users), it may be assumed that cheating is occurring, and a more serious sanction may be applied. Alternatively or in addition, where as noted previously several predetermined thresholds are monitored in a ‘bulls eye’ fashion indicative of increasing grades of accuracy, then apparent cheating falling within these different grades of accuracy may trigger correspondingly significant sanctions. Hence for example if a first predetermined threshold deviation in accuracy was set at the equivalent of 2.5 or 3 standard deviations from mean user accuracy, then for rapid firing within this threshold the sanction may be a precautionary reduction in the impact of damage without any further action taking place, whereas if a second predetermined threshold deviation in accuracy was set at the equivalent of 3.5 or four standard deviations from mean user accuracy, then for rapid firing within this special the sanction may be a temporary time out from the game. Finally if a third predetermined threshold deviation in accuracy was set to be within 1 ms of the predicted timing (e.g. indicative of an auto-firing mechanism without any deliberate variability in timing at all other than due to component tolerances), then for rapid firing within this threshold the sanction may be ejection from the current instance of a multiplayer game. Specific strategies for handling cheats may be at the discretion of videogame designers, multiplayer game hosts, and/or invigilators, as appropriate.

As noted previously herein, the above techniques may be implemented as software instructions for known hardware such as a Sony ® PlayStation 4 ®.

With regards to such hardware, in a summary embodiment of the present invention, an input validation system 10 (such as the Sony ® PlayStation 4 ® operating under suitable software instruction) comprises an input receiver (33, 35) operable to receive input events (such as the Bluetooth receiver 33 or USB receiver 35); a processor 20 operable to monitor a sequence of input events (such as APU 20, utilising the CPU 20A and/or the GPU 20B); a timer 20 operable to obtain the input event to input event timing of at least two successive input events in a monitored sequence (again for example the APU 20); a predictor 20 operable to predict the timing from the latest obtained input event to the next obtained input event in the monitored sequence (again for example the APU 20); and a detector 20 operable to detect whether the next obtained input event occurs within a predetermined threshold deviation of the predicted timing (again for example the APU 20 in response to a received input event via the input receiver); and a classifier 20 (again for example the APU 20); wherein if in operation the detector detects that the next obtained input event occurs within the predetermined threshold deviation of the predicted timing, then the classifier is arranged to classify the input event as a machine generated input event.

It will be appreciated that hardware in the above summary embodiment is similarly operable to implement as appropriate the methods and techniques recited in the preceding summary embodiment and the description herein.

Claims

1. An input validation method, comprising the steps of:

obtaining an input event to input event timing of at least two successive input events in a monitored sequence;

predicting a timing from a latest obtained input event to a next obtained input event in the monitored sequence;

detecting whether the next obtained input event occurs within a predetermined threshold deviation of the predicted timing; and if so, classifying the input event as a machine generated input event.

2. The input validation method of claim 1, in which the input events correspond to use of one physical input.

3. The input validation method of claim 1, in which the input events correspond to use of a predetermined sequence of a plurality of physical inputs.

4. The input validation method of claim 3, comprising the steps of predicting the cumulative timing of the predetermined sequence of input events; detecting whether input events corresponding to the predetermined sequence occur within a predetermined threshold deviation of the predicted cumulative timing;

and if so, classifying the sequence of input events corresponding to the predetermined sequence as a machine generated sequence of input events.

5. The input validation method of claim 3 or 4, in which the predetermined sequence of a plurality of physical inputs is obtained from one or more selected from the list consisting of:

i. a videogame to which the input events are directed; and ii. a sequence library in which the predetermined sequence is stored in association with a videogame to which the input events are directed.

6. An input validation method according to any one of the preceding claims, in which if the detected timing between the latest obtained input event in the monitored sequence and the next obtained input event occurs within the predetermined threshold deviation of the predicted timing, then the next input event is treated as the last input event the monitored sequence, and the detected timing is used in a subsequent prediction of the timing of the next obtained input event.

7. An input validation method according to any one of the preceding claims, in which the predetermined threshold deviation is responsive to the predicted length of time between the latest obtained input event and the next obtained input event in the monitored sequence.

8. An input validation method according to any one of the preceding claims, in which the predetermined threshold deviation is responsive to measurements of timings between corresponding input events in the monitored sequence enacted by humans.

9. An input validation method according to claim 8, in which the predetermined threshold deviation is set to be smaller than the deviation measured for a predetermined percentage of human users.

10. An input validation method according to any one of claims 1-6, in which the predetermined threshold deviation is fixed for a given monitored sequence.

11. An input validation method according to anyone of the preceding claims, comprising the step of:

declaring cheating for a monitored sequence after a predetermined number of successive input events are classified as being machine generated.

12. An input validation method according to claim 11, in which the predetermined number of successive input events is set by one or more selected from the list consisting of:

i. a designer of a game to which the input events are directed;

ii. a host of a multiplayer game, to one client of which the input events are directed; and iii. an authorised invigilator.

13. An input validation method according to anyone of the preceding claims comprising the steps of:

declaring cheating in response to machine generated input events; and signalling to a game to which the input events are directed that cheating has occurred.

14. A computer readable medium having computer executable instructions adapted to cause a computer system to perform the method of any one of claims 1-13.

15. An input validation system, comprising:

an input receiver operable to receive input events; a processor operable to monitor a sequence of input events;

a timer operable to obtain an input event to input event timing of at least two successive input events in a monitored sequence;

5 a predictor operable to predict a timing from a latest obtained input event to a next obtained input event in the monitored sequence; and a detector operable to detect whether the next obtained input event occurs within a predetermined threshold deviation of the predicted timing; and a classifier;

10 wherein if in operation the detector detects that the next obtained input event occurs within the predetermined threshold deviation of the predicted timing, then the classifier is arranged to classify the input event as a machine generated input event.

Intellectual

Property

Office

Application No: GB1618480.6 Examiner: Mr Patrick Lucas