GB2562757A

GB2562757A - Input device and method

Info

Publication number: GB2562757A
Application number: GB1708309.8A
Authority: GB
Inventors: Mark Benson Simon; Winesh Raghoebardajal Sharwin; Connor Patrick
Original assignee: Sony Interactive Entertainment Europe Ltd
Current assignee: Sony Interactive Entertainment Europe Ltd
Priority date: 2017-05-24
Filing date: 2017-05-24
Publication date: 2018-11-28
Also published as: GB201708309D0

Abstract

A processing system comprises an input device, a processing device, and a display, the system comprising one or more pressure sensors associated with the input device that are operable by a user to provide inputs corresponding to squeezing of the input device by the user, an input characterisation unit operable to characterise inputs by one or both of the duration or force of squeezing of the one or more pressure sensors, and a password identification unit operable to identify an input password from the characterised inputs. The processing system finds particular application when applied to hand held games controllers.

Description

(71) Applicant(s):

Sony Interactive Entertainment Europe Limited 10 Great Marlborough Street, London, W1F 7LP, United Kingdom (72) Inventor(s):

Simon Mark Benson

Sharwin Winesh Raghoebardajal

Patrick Connor (74) Agent and/or Address for Service:

D Young & Co LLP

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

A63F13/218 (2014.01)

A63F13/92 (2014.01)

G06F 21/31 (2013.01) (56) Documents Cited:

US 20160239652 A1

US 20150015476 A1 (58) Field of Search:

INT CL A63F, G06F Other: WPI, EPODOC

A63F 13/24 (2014.01)

G06F3/01 (2006.01)

US 20150161368 A1

US 20100248822 A1 (54) Title of the Invention: Input device and method

Abstract Title: Password identification using pressure sensors (57) A processing system comprises an input device, a processing device, and a display, the system comprising one or more pressure sensors associated with the input device that are operable by a user to provide inputs corresponding to squeezing of the input device by the user, an input characterisation unit operable to characterise inputs by one or both of the duration or force of squeezing of the one or more pressure sensors, and a password identification unit operable to identify an input password from the characterised inputs. The processing system finds particular application when applied to hand held games controllers.

* '

Provide one or more inputs using pressure sensors

* *

Receive one or more inputs from the input device

620

630

600

610

Figure 6

1/3

Figure 2

2/3

Communication Unit 310	Input Characterisation Unit 320
Password Identification Unit 330
Processing Device 300

Input

Device

350

Figure 3

400

Figure 4

3/3

Time

Provide one or more inputs using pressure sensors

600

* *

Receive one or more inputs from the input device

610

f *

Characterise received inputs

620

f Ί

Identify an input password

630

Figure 6

INPUT DEVICE AND METHOD

This invention relates to an input device and method.

As internet connectivity for games consoles has become more widespread, it has become increasingly common for users to be able to login to the same user account as they use on their own console when playing on a different console. This is desirable, as a user may be able to track their in-game progress or access their account-specific content even when playing at a friend’s house.

However, to log in to their account a user is often required to type in a password which may be seen by other users. This is particularly true when using a controller that does not have a physical keyboard; in such a case, the password input process takes much longer as the user must navigate to each letter on an on-screen keyboard in turn. This makes it much easier for another person to see the user’s login credentials and as a result a user’s account may be compromised.

A similar problem arises when using portable games consoles, as much of the use of these is in public areas and many such consoles are not equipped with full keyboards to enable a faster and more secretive input.

The presently disclosed arrangement seeks to mitigate this problem by providing an alternative input method for account credentials.

Various aspects and features of the present invention are defined in the appended claims and within the text of the accompanying description and include at least an apparatus and a method, as well as a computer program.

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

Figure 1 schematically illustrates an input device provided with pressure sensors;

Figure 2 schematically illustrates an alternative input device provided with pressure sensors;

Figure 3 schematically illustrates a processing system;

Figure 4 schematically illustrates a password entry display screen;

Figure 5 schematically illustrates a pressure-based password example; and

Figure 6 schematically illustrates a password entry method.

Figure 1 schematically illustrates an input device 100 used for providing commands to an associated processing device. The input device 100 comprises pressure sensors 110 and 120 in addition to input buttons 130. The input device 100 is an example of a controller, as it may be used to control processing performed by an associated processing device, and as such the terms ‘input device’ and ‘controller’ may be used interchangeably in the following description.

An input device 100 according to the present disclosure may comprise any number of input buttons 130; indeed, this number could be zero in the case of an input device that provides inputs based upon a user’s motion rather than button presses.

The location and number of pressure sensors 110 and 120 are also exemplary; only one of these sensors may be provided, or a greater number could be present on the input device. The sensors 110 and 120 could cover only a front or rear portion of the controller, instead of covering the whole surface of the arms. Rather than being located on the arms of the controller, the sensors may be provided on any region of the controller in which it is convenient for the user to provide a pressure to the sensor.

Each of the pressure sensors 110 and 120 may comprise a single pressure-sensitive region in the case in which only one sensing element is provided. However, in some embodiments it is considered advantageous to provide a number of individual sensing elements in each pressure sensor 110 and 120.

This could allow a greater ability to determine which pressure was intended to be applied by the user; for example, it may be possible to determine a direction from which the pressure is applied or it may simply increase the area in which a user may apply a pressure. Alternatively, or in addition, a plurality of sensing elements may be provided for each pressure sensor to allow a user to provide localised pressure inputs in different places that may be interpreted as different inputs.

While the pressure sensors are described as being integrated with the controller, it is apparent that removable sensors could be used. For example, if a user is only using the sensors for providing password information then it may be inconvenient to have the sensors equipped at all times. The use of removable sensors is also advantageous in providing backwards compatibility with older input devices to enable pressure inputs.

Suitable pressure sensors include, but are not limited to, piezo-resistive strain gauges, piezoelectric pressure sensors, and inductive/reluctive pressure sensors.

It will be appreciated that a pressure sensor is different to a touch sensor, such as may be found on a mobile phone screen, or laptop; the user will typically hold (and thus touch) the device and pressure sensor, but needs to apply additional pressure over and above that exerted in normal use to constitute a pressure input (or a pressure input that exceeds a predetermined detection threshold). Similarly, it will be appreciated that a pressure sensor is different to a push switch or button, which physically moves from an off position to an on position when sufficient pressure is applied and hence requires a visible actuating movement on the part of the user.

Figure 2 schematically illustrates a PlayStation Move ® controller 42 as a further example of a controller that may comprise pressure sensors.

The controller 42 comprises a tracking object 420 such as an illuminated ball, which may be used to optically track the controller’s position in space by a camera connected to a host device apparatus (typically a videogame console such as the PlayStation 4® or PC, but potentially a server providing a streamed gaming experience). Other VR controllers may use a different configuration of optical tracking objects, or not include these at all and optionally instead use means such as magnetism, ultrasound, GPS, picocell/WiFi® radio triangulation, laser or light interferometry and I or accelerometer I gyroscope sensors (e.g. MEMs devices), or other suitable motion tracking techniques localised in the controller, the console (or a separate sensor peripheral) or any combination of the above.

The controller 42 also comprises a number of inputs 422, here labelled A-G. The position and number of controls in the figures are purely exemplary. These controls may be arranged in any manner suitable to the functioning and ergonomics of the controller. In the illustrated example, there are three basic groups; buttons A-D may correspond to buttons on a standard videogame controller and have corresponding functions, and similarly button E may correspond to a button on the standard controller such as a trigger or action button, but transposed relative to buttons A to D so as to be easily accessible by the user’s thumb. Button F is a trigger typically used with an index finger. Finally, button G is physically separate from the other buttons to avoid accidental use and may be used to trigger or select.

The controller 42 is further provided with pressure sensors 430 and 440 that are provided in separate areas of the controller. The greater number of sensors may be provided so as to provide a user with a greater range of possible pressure inputs, or simply so as to ensure that a user is always in contact with at least one sensor independently of how they are gripping the controller.

Pressure sensors as described above may be operable to measure a variety of inputs in dependence upon the actions of the user. For example, inputs could be characterised by the duration or hardness of the application of pressure to the sensor. If an input device is equipped with more than one pressure sensing element, the order in which pressure is applied to these elements may also be recorded; in some embodiments, the sensing elements may have pressure applied simultaneously which may also be recorded.

While measuring an absolute value for the pressure applied may be useful, this may be difficult to replicate on a regular basis - particularly if the user becomes stronger or weaker and thus isn’t able to gauge the amount of pressure to apply easily. An alternative to this is to categorise applied pressure as ‘hard’ or ‘soft’, or other methods for categorisation. This would mean that no absolute values of pressure must be considered, as the range of pressures applied during the password input could be used to determine which inputs are hard and which are soft. This may be advantageous as it allows passwords to be entered more reliably, and could allow a user to define a pressure-based password without using a pressure-enabled input device. Hence for example a record of pressure signals from the pressure sensor could be recorded, and a clustering algorithm, histogram or the like could be used to detect two groups of pressure values - nominal pressure, associated with merely holding the device (which could also be determined prior to password entry), and a higher pressure value, for example above a predetermined percentage or standard deviation about the nominal pressure reading.

This principle could be extended to additional clusters of pressure readings; so that ‘hard’ and ‘soft’ squeezes over and above a nominal holding pressure can be classified.

Alternatively or in addition, a long-term average value for a pressure signal can be maintained, which is indicative of a nominal holding pressure for the device. This may be established during an explicit calibration phase, or during a period of use that does not correspond to gameplay or password entry using the pressure technique. Then, as described above, a predetermined threshold corresponding to a value proportionately greater than that long-term average value (for example N% or M standard deviations from the value, where N and M are designer choices) may be used to classify an active squeezing of the controller’s pressure sensor(s).Meanwhile duration may be characterised by squeezing the sensor at a pressure above a predetermined threshold (such as that described above) for a predetermined period of time, followed by a relaxing of pressure below that threshold. Again, multiple thesholds may be provided to allow for a morse-code style input of long or short squeezes. These could use pre-set timings (as users typically have a better sense of timing and rhythm than they do absolute pressure) or alternatively an adaptive timing threshold could be determined in an analogous manner to the adaptive pressure threshold described above.

Where the duration of an input is used to provide a password, tactile, audio, or onscreen feedback indicative of a time may be provided. For example, a flashing icon on a screen could pulse with a constant frequency (for example, each second) so as to allow a user to time their inputs, or an intermittent sound could be provided to provide the same functionality. Alternatively, or in addition, a vibration function associated with the input device could be used. An example of this is to vibrate once after a short-duration input has been observed, twice after a medium-duration input and three times after a long-duration input.

Furthermore, combinations of timing and pressure could be used (e.g. long and short, and hard and soft) to create more complex passwords, or to create shorter passwords of similar complexity to a longer binary squeeze/release style input. If a user is comfortable with inputting such a sequence, then it would save them time. Hence optionally a user may be allowed to specify which modes of input and how many gradations of that input to use in generating a password, and may also be invited to test their ability to reliably replicate that password before it is assigned to their account or whatever feature is being password protected.

In some embodiments, the application of a pressure to a pressure sensor may be used as a modifier for inputs from buttons so as to increase the number of possible inputs. In a simple example, squeezing a sensor while selecting a letter using an on-screen keyboard could mean that the input is uppercase instead of lowercase. Hence more generally, squeezing the pressure sensor can be used to indicate selection of an alternative mode for another input.

While Figures 1 and 2 illustrate handheld devices, it would be appreciated that other input devices may be appropriate. For example, a wristband or armband that is in contact with the user’s skin may be equipped with sensors that detect the motion of the user’s muscles as an outwards pressure on the band. A user could then perform a predetermined set of hand gestures or the like in order to produce a specific pattern of muscle motion which in turn is measured as a pattern of pressure inputs on the band. The input device may therefore be wearable upon the user’s body.

In some embodiments, a user is equipped with a plurality of devices that may be operated successively (or simultaneously) to provide passwords. For example, a user with a pair of controllers as illustrated in Figure 2 could input a password for which the inputs are dependent upon which controller is squeezed. Alternatively, inputs from both controllers may be combined as one sequence, so that a user can arbitrarily divide a squeezing sequence between left and right hands according to personal preference, making unwanted monitoring of their actions even harder to achieve. The latter of these is also advantageous in that a user could input the same sequence in a different manner (by dividing the inputs between the controllers differently upon each entry) upon each entry, further obscuring a password to a third party.

The input devices as described above may communicate information about the pressure inputs in any suitable way. For example, a wired connection or a wireless connection (such as BlueTooth®) may be appropriate. Alternatively, or in addition, each of the input devices described above may be provided with a light source (such as the tracking object 420 in Figure 2) that is operable to transmit information about the pressure inputs that is detectable by the processing device, for example via a connected camera. Such a transmission is preferably in a coded fashion, so that an observer is not so easily able to interpret the inputs from viewing the light that is output.

As a further alternative, the input device and an associated processing device could be formed in a single unit (for example a portable device such as a hand held games console or mobile phone). In such a case, a large portion of the portable device may comprise a touch screen. Hence the pressure sensor may be located on a back panel of the device or incorporated into a rim or edge of the device. In this latter case, the sensor may be arranged to detect pressure directed towards the rim, or in an orthogonal arrangement, may be arranged to detect pressure corresponding to the user squeezing the front and back surfaces of the portable devices together, optionally at a particular location of the device near the sensor. Clearly this squeezing action may also be detected by a sensor coupling the front and back surfaces of the device.

Figure 3 schematically illustrates a processing system comprising a processing device 300 and an input device 350 which are able to perform wired or wireless communication using any suitable method. The input device 350 may be either of those input devices illustrated in Figures 1 and 2, or integral to the processing device (as in the case of a portable device), or indeed any input device with pressure sensors. The distribution of the different functional blocks in this diagram is entirely exemplary; for example, inputs could be characterised at the input device 350 before transmission to the processing device 300, or the input device 350 and the processing device 300 could be formed as a single unit.

The processing device 300 comprises a communication unit 310 operable to communicate with the input device 350, for example to receive controller inputs via buttons on the controller, pressure sensors on the controller, or tracking information for the controller. The processing device 300 also comprises an input characterisation unit 320 and a password identification unit 330.

The processing device 300 is an example of a processing device for use with an input device 350. There are one or more pressure sensors associated with the input device that are operable by a user to provide inputs corresponding to squeezing of the input device by the user.

The communication unit 310 is operable to receive inputs from the input device, the inputs corresponding to at least the operation of the one or more pressure sensors. In some embodiments, the communication unit 310 comprises a wired or wireless receiver. Alternatively, or in addition, the communication unit 310 comprises a camera.

The input characterisation unit 320 operable to characterise inputs by at least one of the duration or force of squeezing of the one or more pressure sensors.

The password identification unit 330 is operable to identify an input password from the characterised inputs. The password identification unit 350 may operable to identify an input password comprising inputs from the one or more input buttons in addition to the characterised inputs, and/or operable to identify an input password comprising motion of the input device in addition to the characterised inputs. For example, button presses and/or motion gestures using the input device could be used to add further complexity to a squeeze-based password input.

The input device 350 is an example of an input device for use with a processing device, the input device comprising one or more pressure sensors that are operable by a user to input a password to the processing system, wherein the input password is comprised of pressure inputs characterised by at least one or of the duration or force of operation of the one or more pressure sensors. The input device 350 may also comprise one or more input buttons separate from the pressure sensors (as shown in Figures 1 and 2), and the password may comprise inputs from the one or more input buttons in addition to the pressure inputs.

Figure 4 schematically illustrates a password entry screen 400. The screen 400 comprises a username entry field 410, a password entry field 420, and an on-screen keyboard

430. Each of these elements may be presented in a different form or omitted altogether, as is apparent from the embodiments described below. Indeed, it may be advantageous to omit a password entry screen altogether if the user is aware of when an appropriate time is to enter a password; this would mean that there is no visual indication to a third party that a password is being entered, and therefore the chances of someone trying to see the password entry are reduced.

A password according to the present application may comprise any number of elements, each element generally being a single pressure input to a single pressure sensor. However, it may be the case that an input from the one or more pressure sensors and an input from the one or more input buttons is characterised as a single identified input, and/or simultaneous operation of two or more pressure sensors may be characterised as a single identified input.

In some embodiments, a user’s password entry is entirely based upon the pressure sensor operation; in such an embodiment, it is apparent that the on-screen keyboard 430 is not required. Equally, the password entry field 420 may be omitted as the user is not faced with the same burden of remembering how far into entering a password they are due to the increased speed of input versus navigating an on-screen keyboard. Additionally, an on-screen representation of the pressure-based inputs would be readable by another person and so one advantage of the present disclosure may not be fully obtained in such an embodiment. While this may be information as simple as the number of inputs that the password consists of, if more detailed representations were provided then it could be possible to identify the password itself.

However, a progress bar may be included to assist the user. For example, if a pressure sequence password was broken down into four sections of four ‘beats’ where the user was expected to input a sequence of squeezes and rests, then an indication whether each section was complete could help the user determine their progress. Similarly potentially an indication of which sections are completed correctly might also assist a user who is having difficulty recalling their password sequence.

In some embodiments, the pressure sensor operation may be used as a modifier for inputs via the on-screen keyboard. For example, a user could select a single character on the keyboard (such as ‘n’) and then by applying a first pressure at the time of selection instead select a second input (such as ‘N’) and by applying a second pressure at the time of selection instead select a third input (such as “;’). These inputs could be applying pressure to particular sensors, or for a particular duration, or with a particular force; or any combination or other suitable method for distinguishing between pressure applications to a controller. In this example, the input from the one or more input buttons is indicative of the selection of an element from an on-screen keyboard displayed on a display associated with the processing device.

It should be appreciated that the on-screen keyboard is not required for such an embodiment in which the pressure input acts as a modifier; the modification could be applied to button presses instead. For example, a user could have a series of button presses as their password (for example, ‘ABC’ using the controller 42 of Figure 2), each with an associated pressure application (or lack thereof). This can increase the number of possible passwords, and thus increase security for a user.

In some embodiments, the pressure input is used as a second password in that the system also requires that a standard alphanumeric password is entered either before or after inputting the pressure-based password. This may be only in the case of logging in on a new device, for example, in which increased account security is desired to prevent fraudulent logins. Of course, any other security method could be used instead of a standard password in such an embodiment; retinal scanning, fingerprint detection and motion paths of motion-tracked controllers may each be an appropriate substitute for an alphanumeric password entry.

It may be advantageous for increasing security to combine the pressure inputs with other inputs to prevent unauthorised users from providing a correct password. An example of another input that may be suitable in this context is that of a fingerprint reader. Such a combination of inputs could be configured so as to only recognise pressure applied by a particular user’s fingers, for example. In a further example, it may be possible to correlate the motion of a controller with the timing of the pressure inputs in order to generate a more complex password; for example, a user may have to provide a particular combination of motion and squeezing in order to successfully access a feature. An exemplary password could comprise holding the controller high up and squeezing hard, followed by a long squeeze while lowering the controller, followed by a soft squeeze when reaching a particular height.

Entering a password using pressure sensors may be less precise than that of a standard character entry using a keyboard or the like; this is particularly true when duration or force of input is used to characterise inputs. It is therefore envisioned that different applications could have different levels of tolerance for the input of passwords in this manner; the respective tolerances for different applications may be determined either by the producer or the user of the application, for example. To give an example, a password entry for accessing a user’s bank account may have a very low degree of tolerance and thus require a very precise input; in contrast, a user wishing to log in to a local user profile (i.e. one that is not online-enabled and thus has limited features) may be able to provide a much lower-precision input and still be granted access.

Other variables that could dictate the tolerance applied may be defined. For example, the tolerance associated with the password input may be dependent upon information about the user, or dependent upon the information or interactivity that the password is intended to protect.

An example of the former is that of the age of the user (for example, a child’s user profile may have a higher degree of tolerance enabled for some or all inputs). The location of the user could also be considered, such that when a login attempt is made in a location that is not in a usual area (for example, outside of home or the town/county/country in which they usually login) the tolerance could be decreased so as to improve password security. This could be in a binary form (high tolerance at home, low tolerance elsewhere) or a more gradual form (such that the tolerance decreases as a function of distance from the user’s home). The current location could be determined using GPS functionality associated with the device being used, or via the device’s IP address or the like.

An example of the latter is that of if the password is for an in-game location (such as a virtual private bank vault), in which case the level of tolerance could be determined by the value of the contents. The examples of accessing a bank account and a user account above are also examples of this.

The type of input (if the pressure input is used as a modifier for a button press, it can be less precise) could also be used for determining an appropriate tolerance, as a further example of varying tolerances for different scenarios.

This illustrates that the system could apply an error-tolerance associated with the password identification that is dependent upon information about the user, and/or it could apply an error-tolerance associated with the password identification that is dependent upon the information or interactivity that the password is intended to protect.

It will be appreciated that tolerance in the above examples may take the form of timing tolerance (deviation from expected squeeze durations, or sequence timings) and/or pressure tolerance (deviation from expected squeeze pressure). Hence for example an ambiguous timing or a squeeze that falls between two input classifications (e.g. long/short, or hard/soft) may be treated as being the correct input. The range of ambiguity and the number of such ambiguous inputs may then be varied to set the effective password error tolerance. Separately, actual input errors (e.g. a clear ‘hard’ input where a ‘soft’ input was expected) may cause a password to be rejected, or may similarly be subject to an error tolerance.

A user may be required to define a different set of pressure inputs as a password for each type of input device that they may use, in recognition of the differing layout of pressure sensors that may be encountered. Alternatively, or in addition, a mapping between common input device’s pressure sensors may be made available to allow a user to translate a single pressure-based password between different input devices.

Figure 5 schematically illustrates a pressure-based input password. In this example, the horizontal axis measures time and the vertical axis represents the force applied to a pressure sensor associated with the input device. A complete or partial password in the form of such a pressure profile may be provided for each pressure sensor, in some embodiments, and each of the pressure profiles must be matched by the user’s input (to within a threshold amount for example as described previously) in order for the password to be considered correctly provided. In some embodiments, the password may be stored as a profile such as that shown in Figure 5, while in other embodiments the password is represented using information about the timing, duration and/or hardness of the input, so that the password is represented by values, flags or the like representing classifications of pressure inputs according to timing, duration, and/or hardness and the like, optionally together with data indicating a permitted error tolerance as discussed previously herein. The user’s input may then be similarly classified as described previously herein and compared to the password to determine a match.

In the example of Figure 5, the password comprises four squeezes, by a user, of the pressure sensors associated with an input device. A first peak corresponds to a short, hard squeeze of the input device. The second peak corresponds to a longer-duration and lighter squeeze of the device, a third peak is a short squeeze of an intermediate hardness. The final pressure input is a hard squeeze of a slightly longer duration than the first input.

As noted above, it may not be possible for a user to recreate the password perfectly upon each attempted entry, and as such a certain degree of tolerance may be allowed in both the hardness of the input and the duration of the input. Therefore the graph may have a broad line (in the case in which the password is stored in this way) with a width that corresponds to the error tolerance so as to encompass a greater range of times and pressures in the password entry. Meanwhile where the password is represented by classifications such as short and hard followed by long and soft, then the error tolerance serves to broaden the classification thresholds.

In some embodiments, the password entry may be tied to interactions with virtual or simply imagined objects. For example, in an embodiment in which a user is immersed in a virtual environment, the user may be presented with a table of objects as a password-entry prompt. Each of these objects may have a different virtual pressure resistance (for example, a virtual drinks can would be easier to crush than a virtual steel rod), and by selecting a particular object and performing a squeeze on the controller to indicate a particular crushing force to be applied to the virtual object a password entry may be indicated. Any pressure inputs that are excessive for crushing that object may be regarded as an incorrect password entry.

Of course, in such an arrangement a user may be required to interact with any number of objects in succession in order to enhance security. It is also possible that the properties of the virtual objects are not set (either by the user, a developer or the processing system) to mirror their real-world counterparts; for example, the steel rod could be extremely fragile while the drinks can could be extremely difficult to crush. This may enhance security in that an unfamiliar user may be unaware of the expected pressure input for each object. The properties of each object could be set on a random basis, and the selection of objects presented to the user may also be selected from a larger set of available items to increase the variety of possible inputs.

As noted above, the password entry may be tied to imagined objects; in this sense, a user may perform a squeeze that they associate with crushing an imagined object (such as a drinks can). While this is similar in implementation to setting a password in any other manner, it may assist a user in remembering their password if it is presented in this manner.

In each of these cases, the motion of the controller may be considered to be a part of the password entry in addition to the squeeze component. For example, a delay between picking up a virtual object and crushing it may be measured, or the speed at which a user lifts the virtual object. In the case of an imagined object, the user may be required to simulate picking the object up from a table, so as to add a degree of complexity to the password entry and thus increase security.

Of course, neither of these embodiments need by tied to the use of a virtual reality headset or the like; each is entirely compatible with any display arrangement, although some of the benefits may be reduced in the case that a third-party is able to observe the password input on the screen.

Alternative embodiments that are particularly suited to virtual reality applications are those in which the input device is displayed to the user as a different device. For example, the pressure sensors of the input device illustrated in Figure 2 could be rendered to the user as piano keys (wherein each key corresponds to a pressure sensing element, for example) or the like such that a squeeze could simulate pressing a key. By providing an arrangement in which the user is able to relate their password to another activity (such as playing a particular song on the piano), the password may be more memorable and could be input more quickly as it is a more familiar action. This may in turn allow a user to use a longer password that is input quickly, thus increasing security.

Figure 6 schematically illustrates a password entry method in which the steps are performed at either of the input and processing device as is appropriate.

A step 600 comprises providing one or more inputs using the pressure sensors on the input device.

A step 610 comprises receiving one or more inputs from the input device, the inputs corresponding to the operation of the one or more pressure sensors.

A step 620 comprises characterising the received inputs by one or both of the duration or force of squeezing the one or more pressure sensors.

A step 630 comprises identifying, using the characterised inputs, an input password. The password is comprised of pressure inputs characterised by one or both of the duration or force of operation of the one or more pressure sensors.

It will be appreciated that embodiments of the present invention may be implemented in hardware, programmable hardware, software-controlled data processing arrangements or combinations of these. It will also be appreciated that computer software or firmware used in such embodiments, and providing media for providing such software or firmware (such as storage media, for example a machine-readable non-transitory storage medium such as a magnetic or optical disc or a flash memory) are considered to represent embodiments of the present invention.

Claims

1. A processing system comprising an input device, a processing device, and a display, the system comprising:

one or more pressure sensors associated with the input device that are operable by a user to provide inputs corresponding to squeezing of the input device by the user;

an input characterisation unit operable to characterise inputs by one or both of the duration or force of squeezing of the one or more pressure sensors; and a password identification unit operable to identify an input password from the characterised inputs.

2. A processing system according to claim 1, comprising one or more input buttons associated with the input device, the input buttons being separate from the pressure sensors.

3. A processing system according to claim 2, wherein the password identification unit is operable to identify an input password comprising inputs from the one or more input buttons in addition to the characterised inputs.

4. A processing system according to claim 3, wherein the input characterisation unit is operable to characterise an input from the one or more pressure sensors and an input from the one or more input buttons as a single identified input.

5. A processing system according to claim 4, wherein the input from the one or more input buttons is indicative of the selection of an element from an on-screen keyboard displayed on a display associated with the processing device.

6. A processing system according to claim 1, wherein the input identification unit is operable to characterise simultaneous operation of two or more pressure sensors as a single identified input.

7. A processing system according to claim 1, wherein the password identification unit applies an error-tolerance associated with the password identification that is dependent upon information about the user.

8. A processing system according to claim 1, wherein the password identification unit applies an error-tolerance associated with the password identification that is dependent upon the information or interactivity that the password is intended to protect.

9. A processing system according to claim 1, wherein the input device is a handheld device.

10. A processing system according to claim 1, wherein the password identification unit is operable to identify an input password comprising motion of the input device in addition to the characterised inputs.

11. A processing system according to claim 1, wherein the input device and the processing device are formed as a single unit.

12. A processing system according to claim 1, wherein the display is operable not to display an indication that a password is being entered.

13. A password entry method for use with a processing system comprising an input device comprising one or more pressure sensors, a processing device, and a display, the method comprising:

receiving, at a processing device, one or more inputs from the input device, the inputs corresponding to the operation of the one or more pressure sensors;

characterising the received inputs by one or both of the duration or force of squeezing the one or more pressure sensors; and identifying, using the characterised inputs, an input password.

14. A computer program which, when executed by a computer, causes the computer to perform the method of claim 13.

15. A machine-readable non-transitory storage medium that stores a computer program according to claim 14.

Application No: GB1708309.8

Intellectual

Property Office