Patent Description:
<CIT> universal game controller for use with a plurality of different types of cellular phones and permits gaming software on the cellular phones to be played in a convenient manner. The controller includes a phone dock for replaceably receiving any of a plurality of types of cellular phones. A receptor is provided for making electrical connection to the cellular phone. Control pads are provided for receiving pressure from a user's thumbs and generating control and command signals that can be transmitted to the cellular phone.

<CIT> describes a video game/simulator system in a personal computer (PC) with game port and keyboard port includes a joystick includes a base and a joystick handle pivotally mounted on the base for two-dimensional movement. The joystick controller is connectable to both the game port of the personal computer and to the keyboard port via a second, throttle controller. The throttle and joystick controller inputs are reconfigurable to work with different video game/simulator programs by downloading a new set of keycodes from the personal computer via the keyboard port to a microcontroller and nonvolatile memory in the throttle controller.

<CIT> describes a reconfigurable video game controller for use with a video game program running on a personal computer, wherein the controller is reconfigured
or reprogrammed directly by the user so that user-defined keycodes are obtained from local memory and transmitted to the computer while playing. The controller is reconfigured by selecting input switches and then entering keycodes via an attached keyboard in setup mode.

<CIT> describes a gamepad that supports an internal mapping system. A user may remap functions associated with any input mechanism of the gamepad to any other input mechanism. The gamepad may include extra, non-standard, input mechanisms. Mapping may be stored internal to the gamepad.

<CIT> describes a system for using computer input devices with software applications. The system includes an input device mapper API, which uses a language of semantics as an interface between input devices and software applications. The input device mapper receives information about which semantics the devices connected to the computer are able to implement, and which semantics correspond to actions that a user can request the software to perform. The input device mapper maps controls on the available devices into user-requestable software actions by matching, as closely as possible, device controls and software actions that correspond to the same semantic.

<CIT> describes a method for running a computer game that includes the step of running the game on a hand-held game machine for which it is not designed without having to rewrite the game. This involves interfacing between the computer and the input/output and operational expectations of a current game. In one embodiment, the interfacing is performed with a compatibility layer having at least an input mapper to convert between input keys of the game machine and the input expectations of the current game.

<CIT> describes methods, systems, and computer programs for playing browser based game with alternative controls and interfaces are presented. In one method, a definition of native inputs defined for the game is received. The native inputs are originated in a native device and are capable of causing actions in the game. Further, the method detects an alternate device that does not have all the native inputs. The native inputs are mapped from the native device to alternate inputs from the alternate device.

The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known user input devices.

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

There are many computing devices which comprise a flat, continuous interaction surface (the device screen), including smartphones, tablets (which may also be referred to as slates), surface computing devices and touch-sensitive displays for desktop computers. As described above, the lack of physical reference points or tactile feedback provided by the touch-sensitive screen (unlike with physical buttons) can cause problems for some applications (e.g. games) and for some users (e.g. those with a visual impairment). It is easy for a user's fingers to move when playing a game so that the fingers are no longer aligned with the game's input controls and this is exacerbated where the game requires rapid or frequent input. Additionally, when in position, the user's fingers may obscure areas of the screen and this may impact usability, particularly for smaller form factor devices (e.g. smartphones).

<FIG> shows three schematic diagrams <NUM>-<NUM> in which reconfigurable input/output modules <NUM>, <NUM> are attached around the periphery of a touch-screen device <NUM> (i.e. around the edge of the display), which may, for example, be a portable or handheld device such as a tablet (of any size) or smartphone or a fixed touch-screen device (e.g. on an appliance or in a vehicle). In the first diagram <NUM>, the touch-screen device <NUM> is oriented in landscape and one input/output module <NUM>, <NUM> is attached on each of the short sides of the device (i.e. on the short sides of the face of the device which includes the display). In the second diagram <NUM>, the touch-screen device <NUM> is in portrait orientation and the input/output modules <NUM>, <NUM> are attached on the long sides of the device. In the third diagram <NUM>, there are four input/output modules <NUM>, <NUM> which are arranged at each end of the touch-screen device <NUM> and which may provide a pair of input/output modules <NUM> for use by a first user and a pair of input/output modules <NUM> for use by a second user, for example when playing a two player game on the touch-screen device <NUM>. Alternatively, the four input/output modules in the third diagram <NUM> may be used by a single user.

As shown by the three examples in <FIG>, the input/output modules <NUM>, <NUM> can be placed anywhere around the periphery of the touch-screen device <NUM> and may be rearranged by a user depending on the application displayed / running on the device, personal preference, or any other factor. Consequently, the modules may be described as reconfigurable (e.g. a user can choose where to place the modules and can move them if they wish). It will be appreciated that in some examples there may be positions where a module cannot be placed (e.g. over a camera or power button, although in many instances a module may be placed over either or both of these), but a user still has the ability to position the modules freely on the remaining periphery of the touch-screen device. Furthermore, although the examples in <FIG> show use of two and four modules, in other examples, a set of modules may comprise N modules, where N is an integer and N≥<NUM>.

At least one of the input/output modules <NUM>, <NUM> comprises an input control and in the examples shown, all the input/modules comprise an input control (e.g. four-way control <NUM> or buttons <NUM>). In various examples, the input control is a tactile input control, such as a physical control (e.g. one with a contoured profile which may move when pressure is applied by a user) which provides tactile feedback to a user that their finger / thumb is correctly positioned on the control. In other examples, the input control may not be tactile and instead may comprise an optical sensor, capacitive sensor or other sensor. In further examples, a combination of tactile and non-tactile input controls may be provided. It will be appreciated that the examples shown in <FIG> (a four-way control and a pair of buttons) are just examples of the input controls that may be provided on an input/output module. Further examples include, but are not limited to, a rotary knob, a slider, a single button (or different number of buttons), a switch and a small joystick. Examples of sensors which may be used include, but are not limited to, a hover sensor for hand position (e.g. based on reflecting IR or seeing IR shadows or thermal IR sensing or based on ultrasound), a magnetometer for sensing distortions due to rings worn on hands, or any other type of sensor that can detect a characteristic of the human or of something the human is wearing. If the device (e.g. the touch-screen device or the module) is flexible or articulatable, then the sensors may detect how the user flexes or articulates the device, e.g. using accelerometer.

Each input control <NUM>, <NUM> is mapped to a user input of an application or other program (e.g. the operating system or any other software) displayed / running on the touch-screen device <NUM>. The user inputs to which an input control <NUM>, <NUM> is mapped may be a touch-event (i.e. a user input that a user would usually provide by touching the touch-sensitive display) or may be an input via a physical button or control on the touch-screen device <NUM> or any input via a supported peripheral (e.g. a Bluetooth keyboard) or any other supported hardware (where the hardware need not be present but only be supported by the program receiving the user input). In some examples, the user inputs may be keystrokes such that the input/output modules may be used instead of an onscreen keyboard.

Where there are multiple input controls, as in the examples shown in <FIG>, each input control may be mapped to a different user input of the same application/program or the input controls may be mapped to user inputs of two or more applications/programs. In an example, both the four-way control <NUM> and buttons <NUM> may be mapped to user inputs of a game which is displayed or running on the touch-screen device. In another example, the four-way control <NUM> may be mapped to a user input of a game running on the touch-screen device <NUM> (or a cloud-based game which is displayed on the touch-screen device) and the buttons <NUM> may be mapped to functions within the operating system (OS) of the device, such as volume controls. In a further example, the four-way control <NUM> may be mapped to a user input of an application displayed / running on the touch-screen device <NUM> and one of the buttons may be mapped to a particular input in another application (e.g. an 'answer' button in an IP telephony application). The mapping may be fixed, dynamic or a combination of both fixed and dynamic (e.g. with a first subset of controls having a fixed mapping and a second subset of controls being dynamically mapped, where each subset does not comprise all of the controls). There may be a number of factors which influence the mapping and these may include the position of an input/output module, the relative position of more than one input/output module, the particular application (or other program) which is visible on the screen (or uppermost, where multiple applications are visible), user input, etc. The mapping of controls to inputs is described in more detail below.

In the examples shown in <FIG>, the input control is on the front face of a module (i.e. on the face which is substantially parallel to the touch-screen display in use or when the module is attached to the device). Alternatively, an input control may be provided on another face of the module or a corner of the module in addition to, or instead of, an input control on the front face (e.g. to provide finger trigger buttons on a top side of a module and/or tactile controls on a rear surface of the display). For example, an input control may be provided on both the front and rear faces.

In various examples, one or more of the modules may comprise an output device such as a visual indicator (e.g. a small display or one or more LEDs), audible indicator (e.g. a small speaker or buzzer or headphone socket), tactile (or haptic) feedback device (e.g. a vibration mechanism, any physical movement actuator or a movement retarder if the touch-screen device or module is flexible or articulatable) or other sensory feedback device (e.g. a heating / cooling device, such as a Peltier cooler, which can provide feedback by changing the temperature of a module or chemical outputs for smells, hormones, etc). In various examples, a module may comprise both an input device (e.g. a tactile control) and an output device (e.g. an indicator LED).

When positioned around the periphery of a touch-screen device <NUM> (and physically attached to the touch-screen device), the input/output modules <NUM>, <NUM> obscure little or none of the actual display area <NUM> and in the examples shown in <FIG>, the modules <NUM>, <NUM> do not obscure any of the actual display area <NUM>. This means that there is more real estate on the screen for viewing and increases ease of use. Although the modules are described herein as being attached around the periphery of the device, in other examples the modules may be attached in other places, i.e. to other non-display portions of the touch-screen device, such as the rear face of the device.

It will be appreciated that <FIG> is not necessarily drawn to scale, however, in various examples the modules are compact and have dimensions (e.g. the length of a side of the front face, as indicated by arrows <NUM>, <NUM>) which are considerably smaller than the touch-screen device <NUM> to which they attach. For example, the front face of the modules may be approximately <NUM> inch (<NUM>) square and used with touch-screen displays ranging from around <NUM> inches (~<NUM>) to <NUM> inches (~<NUM>) or more (where the screen size is measured on the diagonal). In other examples, however, the modules may not be considerably smaller than the touch-screen device to which they attach (e.g. as shown in <FIG> and described below). Although <FIG> shows all the modules being approximately the same shape and size, in some examples, the modules within a set may be of different sizes and/or shapes.

<FIG> shows a schematic diagram of an example set of input/output modules <NUM>, such as those shown in <FIG>. The set of input/output modules <NUM> shown in <FIG> comprises two modules <NUM>, <NUM> although other example sets may comprise more than two modules. Each module comprises a power source <NUM>, which may, for example, be a battery or super capacitor. Super capacitors have an extremely short charge time compared to batteries (e.g. a <NUM> second charge may be sufficient to power the module for about an hour of normal use) which makes them particularly suited to this application. Where super capacitors or rechargeable batteries are used, the module may further comprise charging circuitry <NUM>. The charging circuitry may take power from a mains electricity supply or may draw power from the touch-screen device (e.g. via a USB or proprietary connector on the device or using a wireless charging mechanism).

Each module <NUM>, <NUM> also comprises a processor <NUM> (such as a microcontroller, microprocessor or any other suitable type of processor for processing computer executable instructions) which controls the operation of the module, a wire-free communication element <NUM> and a physical attachment mechanism <NUM> which is used to attach the module to a touch-screen device (e.g. at different positions around the periphery of the device). Many different attachment technologies may be used and various examples are described below with reference to <FIG>. Although the module is shown comprising a processor <NUM>, it will be appreciated that in some examples, for example where a system on a chip architecture is used, the processor <NUM> may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method of operation of the module in hardware (rather than software or firmware). For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs).

The computer executable instructions (which are executed by the processor <NUM>) may be provided using any computer-readable media that is accessible by the module. Computer-readable media may include, for example, computer storage media such as memory and communications media. Computer storage media, such as memory, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transport mechanism. As defined herein, computer storage media does not include communication media. Therefore, a computer storage medium should not be interpreted to be a propagating signal per se. Propagated signals may be present in a computer storage media, but propagated signals per se are not examples of computer storage media. The computer storage media (e.g. memory) may be within the module or the storage may be distributed or located remotely and accessed via a network or other communication link.

The wire-free communication element <NUM> is arranged to communicate with the touch-screen device and/or with other modules within the set <NUM>. In particular, signals that represent the user inputs received at the module (via an input control <NUM>) are communicated to the touch-screen device via the wire-free communication element <NUM>. Where the module comprises an output device <NUM>, signals may also be communicated from the touch-screen device to the module via the wire-free communication element <NUM> and used to control an output device <NUM>.

At least one of the modules in the set <NUM> comprises a wire-free communication element <NUM> that is arranged to communicate with the touch-screen device and where a module comprises a wire-free communication element <NUM> that is not arranged to communicate with the touch-screen device, the element <NUM> may be arranged to communicate with another module in the set which may act as a gateway / relay for communications with the touch-screen device. In various examples, all of the modules in the set <NUM> may communicate directly with the touch-screen device rather than passing messages via one of the modules that acts as a gateway to the touch-screen device for all the modules in the set. Alternatively, one of the modules in the set <NUM> may act as a relay for the other modules in the set such that only the relay has a wire-free communication element <NUM> arranged to communicate with the touch-screen device and the remaining modules in the set comprise a wire-free communication element <NUM> that is arranged to communicate with the module that acts as a relay. In this way the non-relay modules act as slaves to the master module which acts as relay and communicates with the touch-screen device and this reduces overall power consumption.

Any suitable wire-free communication protocol or mechanism may be used and examples include:.

The term 'wire-free' is used herein to refer to any technology which does not rely on a direct electrical connection along electrical conductors (i.e. wires) between the module and the touch-screen device. The term 'wire-free' therefore encompasses all wireless (e.g. RF) technologies in addition to other technologies which do not rely on wires, such as other wave-based technologies (e.g. optical technologies, sound and use of vibrations).

In an example, each module may communicate directly with the touch-screen device using low energy Bluetooth® (e.g. BLE or Bluetooth® Smart) as most touch-screen devices have integrated Bluetooth® capabilities. Alternatively, where a proprietary or less common protocol is used by the wire-free communication element <NUM> and the touch-screen device is not equipped to receive such a protocol, a module may communicate (using the wire-free communication element <NUM>) with the touch-screen device via a communications module which may be connected to the touch-screen device using a wired connector (e.g. a mini or micro USB connector or proprietary connector). This communications module receives the unfamiliar protocol and converts the signals into a protocol that is recognized by the touch-screen device.

In another example, the wire-free communication element <NUM> may use sound to communicate with the touch-screen device. In an example implementation, the wire-free communication element <NUM> may comprise a small loudspeaker or buzzer which emits short audible beeps (e.g. at <NUM>) when a user presses an input control on the module or alternatively a tone may be generated mechanically. Within a set of modules, different input controls (or different movement of the same input control) may cause beeps of different durations. These beeps can be captured and decoded by the touch-screen device (e.g. via the touch-screen device's microphone) and then input into an application or the OS running on the device to simulate the user's tapping of onscreen controls. Alternatively, different frequency tones may be used (e.g. as in DTMF signaling or AFSK).

In some examples, the set of input/output modules may further comprise an input/output module which does not comprise a wire-free communication module but is instead connected to another input/output module via a wired connection.

As described above, at least one of the input/output modules in the set <NUM> comprises an input control <NUM>. As described above, this input control <NUM> may be tactile (e.g. a raised button or other control) and may provide tactile feedback to the user when pressure is applied (e.g. the control may tilt or otherwise move). Alternatively, the input control <NUM> may be a capacitive, optical or other sensor and not provide any tactile feedback. In some examples, an input/output module may be arranged such that the input control <NUM> is removable such that a module can be reconfigured by removing one input control (e.g. a four-way switch) and replacing it with a different input control (e.g. a single button).

Optionally the input control <NUM> may comprise NUI technology which enables a user to interact with the computing-based device in a natural manner, free from artificial constraints imposed by input devices such as mice, keyboards, remote controls and the like. Examples of NUI technology that may be provided include but are not limited to those relying on voice and/or speech recognition, touch and/or stylus recognition (touch sensitive displays), gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence. Other examples of NUI technology that may be used include intention and goal understanding systems, motion gesture detection systems using depth cameras (such as stereoscopic camera systems, infrared camera systems, rgb camera systems and combinations of these), motion gesture detection using accelerometers/gyroscopes, facial recognition, 3D displays, head, eye and gaze tracking, immersive augmented reality and virtual reality systems and technologies for sensing brain activity using electric field sensing electrodes (EEG and related methods).

A module may also comprise one or more additional elements, for example an output device <NUM> (as described above), an on/off switch <NUM>, a connecting mechanism <NUM> and/or a personal data store <NUM>. The connecting mechanism <NUM> may be arranged to physically connect the modules in a set together (e.g. for ease of storage and/or to reduce the risk of a module getting lost) and may, in some examples, also provide an electrical connection between modules such that the power sources <NUM> with the modules can be charged whilst they are connected together and requiring attachment of a single charging lead. In some examples, the attachment mechanism <NUM> may be arranged to also act as a connecting mechanism <NUM>.

The personal data store <NUM> may, for example, be used to store login details or credentials associated with an application or other program (e.g. a user's gaming login details) and/or other personal details associated with an application or other program (e.g. a user's skill level, highest score or profile) and/or configuration preferences for the input/output modules. In other examples, the personal data store <NUM> may be used to store authentication or security information (e.g. a user's private key or credentials). Data from the personal data store <NUM> may be communicated to the touch-screen device via the wire-free communication element <NUM> and may, for example, be used in configuring the input/output modules (e.g. when mapping inputs to touch events) and/or in configuring an application running on the touch-screen device. In an example, if a user stores their gaming login details on their modules (in the personal data store <NUM>), they may be automatically logged into a game when they attach the input/output modules to a touch-screen device on which the game is installed. They may also remain authenticated with the game until the modules are detached from the touch-screen device. In another example, login details stored in the personal data store <NUM> may be used to access user preferences from a remote (e.g. cloud-based) store instead of storing user preferences in the personal data store.

<FIG> shows schematic diagrams of various different attachment mechanisms which may be used to enable the modules to be physically attached anywhere around the periphery of a touch-screen device. All the examples shown in <FIG> use a clamp mechanism (or arrangement) as the attachment mechanism grips the edge of the touch-screen device in some way (e.g. by contacting two opposing parallel faces of the device). When gripping the touch-screen device, the inner faces of the modules that are in contact with the touch-screen device may be shaped (or structured) to prevent the module from slipping off the device (e.g. in a complementary manner to any structure on the touch-screen device itself) and/or non-slip surfaces may be provided on the inner faces. As described above, any suitable mechanism may be used including, but not limited to, clamp mechanisms, sprung mechanisms (i.e. mechanisms which involve some form of spring or deformation of material), magnets, friction-fit (or push-fit) mechanisms and mechanisms using suction or adhesion (whether temporary or permanent), where any module may use one or more of these mechanisms. Depending on the mechanism used, a module may fix to the touch-screen device by contacting at least two faces of the touch-screen device (as in <FIG>) or by fixation to a single face (e.g. fixation solely on the back of the touch-screen device).

The first two examples <NUM>, <NUM> in <FIG> show sprung mechanisms such that the front and back portions of the module clamp onto the touch-screen device <NUM>. This means that the module is unlikely to slip or move once positioned by a user and also the module can accommodate different thicknesses of touch-screen device (e.g. both a smartphone and a tablet).

In the first example <NUM>, the front portion <NUM> and back portion <NUM> of the module are connected by a pivot joint <NUM> and the mechanism is sprung, like a bull-dog clip or clothes peg, such that in the absence of a device <NUM> the jaws of the module <NUM> are forced together (i.e. the natural position of the module is with the jaws closed). By applying a pinching force on the other side of the joint <NUM> from the jaws (e.g. in the positions indicated by arrows <NUM>) a user can force the jaws apart so that the module can be clipped onto the touch-screen device <NUM>.

In the second example <NUM>, the module comprises a front plate <NUM> and a back plate <NUM> which are connected by springs <NUM> which pull the plates together. In order to clip the module onto a touch-screen device <NUM> (or other object), a user pulls the plates apart (e.g. as indicated by arrows <NUM>) and fits the module around the edge of the touch-screen device <NUM> before releasing the plates. Whilst this example may be more compact than the first example, particularly when the modules are not clipped to a touch-screen device (as the natural position of the module is with the two plates in contact with each other), the pivot mechanism of the first example makes it easier to attach the module to the touch-screen device.

In the third example <NUM>, the module <NUM> is formed such that it is a push-fit around the touch-screen device <NUM>. This means that the module <NUM> is designed for a particular thickness of touch-screen device (where the thickness is indicated by arrow <NUM>) and different module designs may be produced to fit different thicknesses of touch-screen device. Alternatively, magnets may be included within the module <NUM> so that the module attaches to the touch-screen device <NUM> even in situations where the module does not correspond exactly to the thickness of the touch-screen device (i.e. so that the module does not need to be a push-fit).

Although the examples shown in <FIG> clamp to the front and back faces of the touch-screen device, in other examples, the modules may clamp (or otherwise attach) to the top and bottom of the touch-screen device (e.g. at positions marked <NUM> in the first diagram <NUM> in <FIG>).

In some examples, the attachment mechanism <NUM> may be interchangeable so that for example in the third example <NUM> of <FIG>, a module can be adapted to attach to different form factor devices without having to replace the entire module (e.g. without replacing the electronics within the module).

As described above, a module may comprise an on/off switch <NUM>. Alternatively, a module may comprise a sensor which is arranged to detect whether the module is attached to a touch-screen device (or to anything else) or not and which is further arranged to switch the module on automatically when it is attached to something (or only when it is attached to the touch-screen device). Where such a sensor is used, this sensor may be integrated within the attachment mechanism <NUM> (e.g. within the spring clip arrangement of the first example <NUM> of <FIG>) or may be provided separately (e.g. an optical sensor on the face which is in contact with the front face of the touch-screen device and which detects whether the touch-screen is switched on). In addition, or instead, this sensor may be used for other purposes, for example, the sensor may be used to trigger an action (e.g. sending an identifier or calibration signal to the touch-screen device) when the module is attached to a touch-screen device. In some examples, a module may comprise both a sensor and an on/off switch.

As described above, the input controls on the modules are mapped to a user input of an application, the OS or other program displayed / running on the touch-screen device. This mapping may be static (e.g. set up initially and then remains the same) or dynamic (e.g. it may depend on which application is active on the touch-screen device or may change during operation of the application). In an example, the mapping of the input controls to user inputs may change dependent upon which program a user is interacting with on the touch-screen device at any time, such that where a user switches between applications (e.g. between a game and a calendar application) the mapping changes. In another example, the mapping may change dependent upon the location (or relative location) of the modules when attached to the touch-screen device. In other examples, a combination of any of the methods described herein may be used.

In examples where the mapping is dependent upon the position or relative position of the input/output modules, the position or relative position of modules may be detected by the touch-screen device or by the modules themselves. In a first example, one or more of the modules may comprise a module position sensor <NUM> which is arranged to detect either the position of the module itself (e.g. the position of module <NUM> in <FIG>) or the position of one or more other modules in the set (e.g. the position of module <NUM> in <FIG>). Where the position of another module is detected, characteristics of the separation of the two modules (e.g. distance between them) may be detected. Any suitable sensing technology may be used (e.g. visible light or IR) and in some examples, the wire-free communication element <NUM> may also be used as a module position sensor. In an example, one or more modules may comprise a module position sensor <NUM> which is a photodetector and may be arranged to detect visible light / IR emitted by an output device <NUM> (or other element) on another module and use the characteristics of the detected signal to determine the relative locations of the modules. For example, if a module comprises multiple photodetectors on different faces of the module, the relative position of other modules may be determined based on which photodetectors detect light / IR emitted by another module. Where the modules themselves detect their position or relative position, this information may be communicated to the touch-screen device via the wire-free communication element <NUM>.

In other examples, the position of input/output modules may be detected by the touch-screen device itself. For example, a module may have a code or marker on an inner face which is in contact with the screen of the touch-screen device and which may be read by the touch-screen device, even if the module is positioned outside of the display area (e.g. as the touch-sensitive area may extend beyond the area used for display). In another example, the input/output module may comprise an output device <NUM> (e.g. an LED or other active indicator) on the inner face to enable it to provide an identifier or other signal to the touch-screen device (e.g. again as detected by the touch-sensitive display). In various examples, an input/output module may have a unique ID or a type identifier (e.g. <NUM>-way control, <NUM> buttons, etc) which is communicated to the touch-screen device using a code, marker, active indicator or other means (e.g. via the wire-free communication element <NUM>) and this identifier may be used in the mapping.

In some examples, a target program (e.g. a game) may suggest positions for the input/output modules to the user (e.g. a program may advise the user where they consider the optimum position of modules to be). This information may be provided to the user as part of the program loading screens or other on-screen hints.

User inputs via the input controls on the input/output modules are mapped to user inputs in programs displayed / running on the touch-screen device, e.g. applications (such as games) or the OS, and the program with the user inputs that are the target of the mapping may be referred to as the 'target program'. This mapping may be performed automatically or there may be user involvement in the mapping. Where there is data communicated from the modules to the touch-screen device (e.g. identifiers, position information, data from the personal data store <NUM>, etc) this information may be used when performing the mapping. Similarly, where the touch-screen device can determine information about the modules (e.g. their position or characteristics of the modules, such as what input control they include), this may also be used when performing the mapping.

The mapping itself may be performed by the target program itself or by another program running on the touch-screen device or by a program running remotely from the touch-screen device and various examples are described below with reference to <FIG> and <FIG>. Where the input/output modules communicate with the touch-screen device using Bluetooth®, any supported profile may be used, such as the Bluetooth® HID (Human Interface Device) profile which provides support for keyboards, joysticks and mice. Alternatively A2DP or HSP may be used instead of HID. If a different communication technology is used to communicate between the modules and the touch-screen device (e.g. Wireless USB), an appropriate supported profile may be used.

<FIG> shows schematic diagrams <NUM>-<NUM> of four example methods of mapping inputs on an input/output module <NUM>, <NUM> to a user input in a game <NUM>-<NUM>. It will be appreciated that a game is used as an example of a program which may run on a touch-screen device <NUM> and other examples of programs include the OS or other applications.

In the first example <NUM>, the user input signals from the input/output modules <NUM>, <NUM> are received by the game <NUM>, e.g. using the Bluetooth® HID (or other HID), and the mapping of the user input signals to user inputs recognized by the game is performed by the game itself. In this example, the game <NUM> comprises a mapping table <NUM> which stores the mappings between an input signal (e.g. an input keystroke) and the corresponding user input in the game <NUM>.

In the second example <NUM>, a daemon <NUM> running on the touch-screen device <NUM> receives the input signals from the input/output modules <NUM>, <NUM> (e.g. using the Bluetooth® HID) and then provides signals to the game <NUM> which simulate a touch event. The game <NUM> does not need to be modified in any way because the user input signals it received from the daemon <NUM> are exactly the same as it would otherwise receive from the OS running on the touch-screen device when the user provides an input via the touch-screen. In this way, the daemon can simulate (or spoof) any touch event or in some examples may be configured to spoof other events (e.g. detected sounds).

In a variation of the second example <NUM>, the daemon <NUM> may be part of the OS on the touch-screen device <NUM> and may provide a configuration screen for the input/output modules <NUM>, <NUM> in a similar way to configuring a mouse via the control panel in an existing OS. Irrespective of whether the daemon <NUM> is separate from or integrated within the OS, the mapping between input signals and touch events may be fixed, user-configurable, dynamic (e.g. dependent upon the application being used by the user) or any combination thereof.

In some computing environments and/or with some games, it may not be possible to have a second program (e.g. daemon <NUM>) running on the touch-screen device <NUM> and providing the user input signals to the game (as is shown in the second example <NUM>). In such situations, an arrangement as shown in the third example <NUM> may be used. In this example, a reconfiguration application <NUM> running on the touch-screen device <NUM> sends reconfiguration commands to the input/output modules <NUM>, <NUM> which are dependent upon the game <NUM> that is about to be played on the touch-screen device <NUM>. These commands are received by the modules and change the input signals that are sent by the modules to the game in response to any user input received at the modules. A different reconfiguration application may be used for different games or alternatively, a single reconfiguration application may be configured to send reconfiguration commands for more than one game (or other program). In this way, the mapping is dynamic and dependent upon the game. Alternatively, the reconfiguration may be dependent upon the particular touch-screen device <NUM> and may be run as a one-off operation to configure the input/output modules <NUM>, <NUM> to work with the particular device <NUM>.

In comparing the first, second and third examples, in the first example <NUM>, it is the game <NUM> that is reconfigured in some way (e.g. to map received input signals to different user inputs within the game) whereas in the second example <NUM>, an intermediary (daemon <NUM>) performs the translation between signals received from the modules and the signals expected by the game <NUM> and in the third example <NUM>, the operation of the modules <NUM>, <NUM> is modified so that they output the input signals that are expected by the game <NUM>. In all these examples, the mapping may be performed automatically or there may be some user involvement, e.g. to run the reconfiguration application <NUM> or to specify a particular mapping (e.g. to configure the reconfiguration application <NUM> or daemon <NUM>).

In the fourth example <NUM>, the game <NUM> may be written with reconfigurable input/output modules in mind (i.e. the game may be considered to be aware of reconfigurable input/output modules). In the example shown the game <NUM> comprises a library <NUM> which comprises different sets of mappings between input signals from input/output modules <NUM>, <NUM> and user inputs within the game <NUM>. Depending on the input signals received from the modules by the game <NUM>, the game may select an appropriate set of mappings from the library to use. In an example, the modules may send an identifier signal when switched on which is used by the game to identify the appropriate set of mappings to select from the library. Alternatively, a user may select an appropriate set of mappings based on user preference (e.g. whether they are left or right-handed). In this example, the input signals from the input/output modules are not mapped through an existing mechanism (e.g. as in example <NUM> where a left button may be mapped to 'keyboard left arrow' and this may then be mapped in the game to 'turn left') but instead, the game receives the input signal from the peripheral and maps it directly to the game command (e.g. 'turn left') without using an intermediate mapping.

<FIG> and <FIG> show flow diagrams for example methods of operation of the systems shown in <FIG>. <FIG> corresponds to the first, second and fourth examples <NUM>, <NUM>, <NUM> in <FIG> although, as described below, block <NUM> may be omitted from the first and fourth examples and block <NUM> may be omitted from the first and second examples. <FIG> corresponds to the third example <NUM> in <FIG>.

In <FIG> a user input is received on an input/output module (block <NUM>), e.g. via an input control <NUM> as shown in <FIG>. In response to this input, a signal is generated (e.g. by processor <NUM>) and transmitted to the touch-screen device (block <NUM>), e.g. using the wire-free communication element <NUM> in <FIG>. This signal which is generated and transmitted (in block <NUM>) is indicative of (or otherwise representative of) the particular user input that was received. For example, if the module comprises two input controls (e.g. two buttons as in module <NUM> in <FIG>), a different signal is generated and transmitted if a user presses one button, compared to the user pressing the other button. These signals are then received by the touch-screen device (block <NUM>) and these may be received by a program running on the device, where this program may be the target program (e.g. game <NUM> in the first example <NUM> in <FIG> or game <NUM> in the fourth example <NUM>) or another program (e.g. daemon <NUM> in the second example <NUM>). The receiving program then maps the received signal to a user input within the target program running on the touch-screen device (block <NUM>), this user input within the target program may be referred to as the 'target user input'. Where the receiving program is not the target program (e.g. in example <NUM>), a user input signal corresponding to the target user input is then output to the target program (block <NUM>); however this step is omitted where the receiving program is the target program (e.g. in examples <NUM>, <NUM>). In some examples, (e.g. example <NUM>), a mapping set may be selected from a number possible mapping sets (block <NUM>) by the receiving program prior to performing the mapping (in block <NUM>) and by selecting a different mapping set, a user input on an input/output module may be mapped to a different target user input. In an example, the different mapping sets (from which the selection is made in block <NUM>) may correspond to different target programs.

In <FIG>, a trigger signal is received on the touch-screen device (block <NUM>) and these may be received by a reconfiguration application (e.g. reconfiguration application <NUM> in the third example <NUM> in <FIG>). This trigger signal may have been sent by an input/output module (block <NUM>) or may have been generated by another entity (e.g. by a program running on the touch-screen device which may, for example, be the target program). In response to receiving the trigger signal (in block <NUM>), the reconfiguration application sends reconfiguration instructions to the input/output modules (block <NUM>). The same instructions are broadcast to all modules and the modules determine which parts of those instructions need to be implemented by the receiving module. For example, referring to the module set shown in <FIG> which comprises a first module <NUM> with a four-way control and a second module <NUM> with a single button, a signal is transmitted which includes reconfiguration information for both a four-way control and a single button.

The reconfiguration instructions are received by the modules (block <NUM>) and implemented (block <NUM>). This implementation may change some or all of the signals which the input/output modules generate in response to user inputs. In some examples, implementation of the reconfiguration instructions (in block <NUM>) may not cause any changes, e.g. where the reconfiguration instructions correspond to the current settings within the input/output modules. An input/output module implements a subset of all the instructions contained in the reconfiguration signal based on the particular input controls present on the module. When a user input is subsequently received at an input/output module (block <NUM>), the signal which is generated (in block <NUM>) is compliant with the reconfiguration instructions which were implemented (in block <NUM>).

In the examples shown in <FIG>, the reconfiguration application <NUM>, daemon <NUM> and mapping table <NUM> are stored locally on the touch-screen device <NUM>. However, as shown in the examples of <FIG>, these elements may alternatively be located remotely from the touch-screen device and may be accessed via a network (e.g. over the internet). In the first example <NUM>, the reconfiguration application <NUM> runs as a web service on a remote server (e.g. a cloud service) and is accessed via a browser <NUM> running on the touch-screen device <NUM>. In this example, the browser <NUM> opens a website which triggers the web service to reconfigure the modules <NUM>, <NUM> according to the particular game <NUM> which is going to be played. Similarly, in the second example <NUM>, the daemon <NUM> runs as a remote web service (e.g. a cloud service). As in the corresponding example in <FIG>, the daemon <NUM> translates the signals from the modules into input signals which are recognized by the game <NUM>. In the third example <NUM>, there is an online database <NUM> which stores mapping data (e.g. in the form of a mapping table or various libraries) and which may be accessed by a game <NUM> and used to map the input signals received by the game from the input/output modules.

The example flow diagrams shown in <FIG> and <FIG> are also applicable to the systems shown in <FIG>. In the first example <NUM>, which corresponds to the flow diagram shown in <FIG>, the reconfiguration application <NUM> receives a trigger signal (block <NUM>) and transmits reconfiguration commands (block <NUM>) and it may be the browser <NUM> which transmits the trigger signal (in block <NUM>). In the second example <NUM>, which corresponds to the flow diagram shown in <FIG>, the daemon <NUM> receives the signals from the input/output modules (block <NUM>) and maps these to user inputs within the target program (block <NUM>) before transmitting corresponding user input signals to the target program (block <NUM>). In the third example <NUM>, which also corresponds to the flow diagram shown in <FIG>, the game <NUM> receives the input signals from the input/output modules (block <NUM>) and uses the remotely stored mapping information <NUM> when performing the mapping (block <NUM>). In some examples, the game <NUM> may select mapping information to use from the remote mapping information <NUM> (block <NUM>) prior to performing the mapping (block <NUM>).

In the examples described above, the target program is running on the touch-screen device. However, in some examples, the target program may be running on a separate device (e.g. a games console or smart TV, i.e. a television with interactive media capabilities) and the intermediary (e.g. the daemon described above) may be running on the touch-screen device. Such an example is shown in the schematic diagram in <FIG> and in this example the separate device is a games console <NUM> by way of example only. The game <NUM> is the target program, which runs on the separate device <NUM> and need not be modified to work with the input/output modules <NUM>, <NUM>. A daemon <NUM> running on the touch-screen device <NUM> receives the signals from the input/output modules <NUM>, <NUM> (e.g. as in block <NUM> in <FIG>), maps these to user inputs within the game <NUM> (e.g. as in block <NUM>) and then transmits these to the game (e.g. as in block <NUM>). In this way, the touch-screen device <NUM> with input/output modules <NUM>, <NUM> and running daemon <NUM> (and which collectively may be denoted <NUM>) can operate as a games controller for games console <NUM>. By using different daemons or reconfiguring the daemon, the combined device <NUM> may operate as a controller or remote control for different devices (e.g. in addition to games console <NUM>) and/or different target programs.

<FIG> shows a schematic diagram of a games controller <NUM> which comprises two halves <NUM>, <NUM>, each of which is operable as an input/output module as described above when the two are separated from each other and the entire device <NUM> (when the two halves are joined together) operates as a standard games controller. When separated, the two halves can be attached around the periphery of a touch-screen device <NUM> in the same way as the input/output modules described above. When the two halves <NUM>, <NUM> are attached to a touch-screen device, they may be used to provide user inputs to a target program running on the touch-screen device itself (e.g. as shown in <FIG>) or to a target program running on a separate device (e.g. as shown in <FIG>). Where the games controller <NUM> uses a proprietary wireless protocol, each half <NUM>, <NUM> may communicate (e.g. using a wire-free communication element <NUM>) with the touch-screen device <NUM> via a communications module which may be connected to the touch-screen device using a wired connector (as described above).

It will be appreciated that the shape of the games controller <NUM> shown in <FIG> is by way of example only and the games controller may be of any shape. Depending on the size of the touch-screen device <NUM> and the games controller <NUM>, the size of each half <NUM>, <NUM> may not be much smaller than the touch-screen device <NUM> to which they attach, e.g. if the touch-screen device <NUM> is a smartphone rather than a tablet, (unlike the earlier schematic drawings of input/output modules).

Although the present examples are described and illustrated herein as being implemented to provide user inputs to games, the system described is provided as an example and not a limitation. As those skilled in the art will appreciate, the present examples are suitable for application in a variety of different types of target applications. Furthermore, although much of the description relates to hand-held or portable touch-screen devices (which may also be referred to as mobile computing devices), the examples may also be applied to fixed or non-portable touch-screen devices. In addition, although many of the examples described above relate to the modules being attached around the periphery of the mobile computing device, in other examples, they may be attached to other non-display portions of the device, such as the rear face of the device. In some examples, the attachment mechanism may attach to only non-display portions of the device and in other examples, the attachment mechanism may attach to both non-display portions and display portions of the device (e.g. the attachment mechanism may attach to a small part of the display, as well as to non-display portions, and still obscure little or none of the actual display area).

Touch-screen devices are an example type of computing devices which comprise a flat, continuous interaction surface. Although the description refers to use of input/output modules with a touch-screen device, the modules may alternatively be used with other devices which comprise a flat, continuous interaction surface (e.g. a surface which uses non-contact sensing such as depth sensor or eye tracker and may also provide other input means to a user such as pen, gesture and speech input).

Additionally, although the input/output modules described above are intended to be used when attached to a touch-screen device, it will be appreciated that they could be clipped to a case or housing of the touch-screen device or to other objects which are close to the touch-screen device such that the wire-free communication element can still communicate with the touch-screen device.

The term 'computer' or 'computing-based device' is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realize that such processing capabilities are incorporated into many different devices and therefore the terms 'computer' and 'computing-based device' each include PCs, servers, mobile telephones (including smart phones), tablet computers, set-top boxes, media players, games consoles, personal digital assistants and many other devices.

The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible storage media include computer storage devices comprising computer-readable media such as disks, thumb drives, memory etc and do not include propagated signals. Propagated signals may be present in a tangible storage media, but propagated signals per se are not examples of tangible storage media. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

This acknowledges that software can be a valuable, separately tradable commodity.

Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

Claim 1:
A method of providing user inputs to a target program, the method comprising:
receiving broadcast reconfiguration instructions at an input/output module attached to a non-display portion of a computing device, the reconfiguration instructions specifying mappings between user input controls and user inputs in the target program (<NUM>);
implementing a subset of the reconfiguration instructions based on the user input controls present on the input/output module (<NUM>); and
in response to a subsequent user input on the input/output module (<NUM>), mapping the user input to a user input in the target program based on the reconfiguration instructions that were implemented and sending a user input signal corresponding to the user input in the target program from the input/output module to the computing device (<NUM>, <NUM>)
wherein the input/output module is one of a set of reconfigurable input/output modules, the set comprising at least two input/output modules, each comprising an attachment mechanism for attaching the module to a non-display portion of a computing device and one or more input controls.