U.S. Pat. No. 10,729,973

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

In an exemplary embodiment, the processor comprises a game console, such as an XBOX® game console for example.FIG. 1is a block diagram of an example game console100via which dynamic sensitivity adjustment for a sensor can be implemented. The game console100along with other devices described herein, such as a display device, are capable of performing the functions needed to accomplish dynamic sensitivity adjustment for a sensor, as described herein. A typical game console comprises hardware and software that are specifically designed to support a core set of usage scenarios.

Game console100has a central processing unit (CPU)101having a level 1 (L1) cache102, a level 2 (L2) cache104, and a flash ROM (Read-only Memory)106. The level 1 cache102and level 2 cache104temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput. The flash ROM106can store executable code that is loaded during an initial phase of a boot process when the game console100is initially powered. Alternatively, the executable code that is loaded during the initial boot phase can be stored in a FLASH memory device (not shown). Further, ROM106can be located separate from CPU101. Game console100can, optionally, be a multi-processor system; for example game console100can have three processors101,103, and105, where processors103and105have similar or identical components to processor101.

A graphics processing unit (GPU)108and a video encoder/video codec (coder/decoder)114form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit108to the video encoder/video codec114via a bus. The video processing pipeline outputs data to an A/V (audio/video) port140for transmission to a television or other display device. A memory controller110is connected to the GPU108and CPU101to facilitate processor access to various types of memory112, such as, but not limited to, a RAM (Random Access Memory).

Game console100includes an I/O controller120, a system management controller122, an audio processing unit123, a network interface controller124, a first USB host controller126, a second USB controller128and a front panel I/O subassembly130that may be implemented on a module118. The USB controllers126and128serve as hosts for peripheral controllers142(1)-142(2), a wireless adapter148, a wireless remote peripheral150, and an external memory unit146(e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). The network interface124and/or wireless adapter148provide access to a network (e.g., the Internet, home network, etc.) and may be any of a wide variety of various wired or wireless interface components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like. The wireless remote game peripheral150may connect to the game console through the wireless adaptor148as well.

System memory143is provided to store application data that is loaded during the boot process. A media drive144is provided and may comprise a DVD/CD drive, hard drive, or other removable media drive, etc. The media drive144may be internal or external to the game console100. When media drive144is a drive or reader for removable media (such as removable optical disks, or flash cartridges), then media drive144is an example of an interface onto which (or into which) media are mountable for reading. Application data may be accessed via the media drive144for execution, playback, etc. by game console100. Media drive144is connected to the I/O controller120via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 5394). While media drive144may generally refer to various storage embodiments (e.g., hard disk, removable optical disk drive, etc.), game console100may specifically include a hard disk152, which can be used to store game data, application data, or other types of data, and on which file system components may be implemented.

The system management controller122provides a variety of service functions related to assuring availability of the game console100. The audio processing unit123and an audio codec132form a corresponding audio processing pipeline with high fidelity, 5D, surround, and stereo audio processing according to aspects of the present subject matter described herein. Audio data is carried between the audio processing unit123and the audio codec126via a communication link. The audio processing pipeline outputs data to the A/V port140for reproduction by an external audio player or device having audio capabilities.

The front panel I/O subassembly130supports the functionality of the power button and any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the game console100. A system power supply module136provides power to the components of the game console100. A fan138cools the circuitry within the game console100.

The CPU101, GPU108, memory controller110, and various other components within the game console100are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures.

When the game console100is powered on or rebooted, application data can be loaded from the system memory143into memory112and/or caches102,104and executed on the CPU101. The application can present a graphical user interface that provides a consistent user experience when navigating to different media types available on the game console100. In operation, applications and/or other media contained within the media drive144may be launched or played from the media drive144to provide additional functionalities to the game console100.

The game console100may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the game console100may allow one or more users to interact with the system, watch movies, listen to music, and the like. However, with the integration of broadband connectivity made available through the network interface124or the wireless adapter148, the game console100may further be operated as a participant in a larger network community.

FIG. 2and the following discussion provide a brief general description of a suitable computing environment in which dynamic sensitivity adjustment for sensors within a remote game peripheral can be implemented. Although not required, various aspects of dynamic sensitivity adjustment for sensors within a remote game peripheral can be described in the general context of computer executable instructions, such as program modules, being executed by a computer, such as a client workstation or a server. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Moreover, implementation of a wireless protocol for voice-only devices in a gaming console can be practiced with other computer system configurations, including hand held devices, multi processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Further, dynamic sensitivity adjustment for sensors within a remote game peripheral also can be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

A computer system can be roughly divided into three component groups: the hardware component, the hardware/software interface system component, and the applications programs component (also referred to as the “user component” or “software component”). In various embodiments of a computer system the hardware component may comprise the central processing unit (CPU)721, the memory (both ROM764and RAM725), the basic input/output system (BIOS)766, and various input/output (I/O) devices such as a keyboard740, a mouse762, a monitor747, and/or a printer (not shown), among other things. The hardware component comprises the basic physical infrastructure for the computer system.

The applications programs component comprises various software programs including but not limited to compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users). In an example embodiment, application programs perform the functions associated with dynamic sensitivity adjustment for sensors within a remote game peripheral as described above.

The hardware/software interface system component comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel. An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system. A purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs.

The hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system. The application programs interact with the hardware/software interface system by requesting services via an application program interface (API). Some application programs enable end-users to interact with the hardware/software interface system via a user interface such as a command language or a graphical user interface (GUI).

A hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should run in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends messages to each application (and, in certain cases, to the end-user) regarding the status of operations and any errors that may have occurred. The hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations. On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.

A hardware/software interface system shell (referred to as a “shell”) is an interactive end-user interface to a hardware/software interface system. (A shell may also be referred to as a “command interpreter” or, in an operating system, as an “operating system shell”). A shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users. In contrast to a shell, a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.

As shown inFIG. 2, an exemplary general purpose computing system includes a conventional computing device760or the like, including a processing unit721, a system memory762, and a system bus723that couples various system components including the system memory to the processing unit721. The system bus723may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM)764and random access memory (RAM)725. A basic input/output system766(BIOS), containing basic routines that help to transfer information between elements within the computing device760, such as during start up, is stored in ROM764. The computing device760may further include a hard disk drive727for reading from and writing to a hard disk (hard disk not shown), a magnetic disk drive728(e.g., floppy drive) for reading from or writing to a removable magnetic disk729(e.g., floppy disk, removal storage), and an optical disk drive730for reading from or writing to a removable optical disk731such as a CD ROM or other optical media. The hard disk drive727, magnetic disk drive728, and optical disk drive730are connected to the system bus723by a hard disk drive interface732, a magnetic disk drive interface733, and an optical drive interface734, respectively. The drives and their associated computer readable media provide non volatile storage of computer readable instructions, data structures, program modules and other data for the computing device760. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk729, and a removable optical disk731, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like may also be used in the exemplary operating environment. Likewise, the exemplary environment may also include many types of monitoring devices such as heat sensors and security or fire alarm systems, and other sources of information.

A number of program modules can be stored on the hard disk, magnetic disk729, optical disk731, ROM764, or RAM725, including an operating system735, one or more application programs736, other program modules737, and program data738. A user may enter commands and information into the computing device760through input devices such as a keyboard740and pointing device762(e.g., mouse). Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner, or the like. These and other input devices are often connected to the processing unit721through a serial port interface746that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port, or universal serial bus (USB). A monitor747or other type of display device is also connected to the system bus723via an interface, such as a video adapter748. In addition to the monitor747, computing devices typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary environment ofFIG. 2also includes a host adapter755, Small Computer System Interface (SCSI) bus756, and an external storage device762connected to the SCSI bus756.

The computing device760may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer749. The remote computer749may be another computing device (e.g., personal computer), a server, a router, a network PC, a peer device, or other common network node, and typically includes many or all of the elements described above relative to the computing device760, although only a memory storage device750(floppy drive) has been illustrated inFIG. 6. The logical connections depicted inFIG. 2include a local area network (LAN)751and a wide area network (WAN)752. Such networking environments are commonplace in offices, enterprise wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the computing device760is connected to the LAN751through a network interface or adapter753. When used in a WAN networking environment, the computing device760can include a modem754or other means for establishing communications over the wide area network752, such as the Internet. The modem754, which may be internal or external, is connected to the system bus723via the serial port interface746. In a networked environment, program modules depicted relative to the computing device760, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

While it is envisioned that numerous embodiments of dynamic sensitivity adjustment for sensors within a remote game peripheral are particularly well-suited for computerized systems, nothing in this document is intended to limit dynamic sensitivity adjustment for sensors to such embodiments. On the contrary, as used herein the term “computer system” is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.

The various techniques described herein can be implemented in connection with hardware or software or, where appropriate, with a combination of both. Thus, the methods and apparatuses for dynamic sensitivity adjustment for sensors within a remote game peripheral, or certain aspects or portions thereof, can take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for implementing dynamic sensitivity adjustment for sensors within a remote game peripheral.

The program(s) can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language, and combined with hardware implementations. The methods and apparatuses for implementing dynamic sensitivity adjustment for sensors within a remote game peripheral also can be practiced via communications embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as an EPROM, a gate array, a programmable logic device (PLD), a client computer, or the like. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates to invoke the functionality of dynamic sensitivity adjustment for sensors within a remote game peripheral. Additionally, any storage techniques used in connection with dynamic sensitivity adjustment for sensors within a remote game peripheral can invariably be a combination of hardware and software.

In an exemplary embodiment shown inFIG. 3, a remote game peripheral410is connected to a game server400using a wireless or wired connection that is operative to transmit message between the game server400and the remote game peripheral410. If the connection is through a wireless adapter, the game sensitivity adjustment is transmitted as a standard part of the message protocol. In the exemplary embodiment, the message is composed for wireless transmission by first appending RF Setup334information that provides the hardware setup information for receipt of the message. The message Preamble336and Sync338fields are transmitted to achieve software preparation and synchronization to allow the incoming message to be properly decoded and saved in an incoming message input buffer. The message Header340provides identification information for the data342following such that the message information may be used for its intended purpose. In this exemplary embodiment, the Sensor Adjustment343command data is received as a portion of the message data342sent to the remote game peripheral. The Error Correction344field at the end of the message provides data security against mis-transmitted or garbled messages.

As shown inFIG. 4, a game peripheral410is located remotely from a game server400and connected to the game server400through a bidirectional communication channel. This bi-directional communication channel is used to transmit sensor measurements recorded by the game peripheral410to the game server400and to transmit game commands and settings from the game server400to the game peripheral410. In an exemplary embodiment, the game commands and settings may include a command to adjust a sensor sensitivity setting and the updated sensor setting that may be used to perform the adjustment. The adjustment to the sensor setting within the game peripheral410may be used to specify a new sensor sensitivity range for any one of the sensors within the remote game peripheral at any point during the playing of a game. Thus, if game play by a user requires an action, movement, or input that may only be captured if the resolution of the sensor sensitivity measurement within the sensor is set to the largest measurement range, the game server transmits a command dynamically when necessary to adjust the sensitivity range of the sensor to its largest measurement range. Alternatively, if game play by a user requires an action, movement, or input that may only be captured if the resolution of the sensor sensitivity measurement within the sensor is set to a smaller measurement range, the game server transmits a command to dynamically adjust the sensitivity range of the sensor to a smaller measurement range. Measurement ranges for the sensitivity settings differ with each type of sensor that may be used within the remote game peripheral410. However, each measurement range for a particular sensor is assigned an identifying value that is communicated from the game server400to the game peripheral410. The remote game peripheral utilizes the identifying value as a selection index for the sensitivity range table. The game peripheral410retrieves the measurement range setting from the sensitivity range table and adjusts the measurement range for the game peripheral dynamically.

In a non-limiting embodiment, an example of the functionality described above is represented inFIGS. 5A and 5B. In this non-limiting embodiment, the remote game peripheral410is represented by a hand-held device in which the sensor may be an accelerometer. The accelerometer may be used to measure hand-held device motion start and stop times, tilt of the hand-held device with respect to an initial frame of reference in x, y, z coordinate space, velocity and instant acceleration of the hand-held device. In this non-limiting embodiment gestures by the game player are captured as movement parameters by the sensor, an accelerometer in this example, and communicated to the game server. InFIG. 5Awithout setting the proper sensitivity range a gross gesture500by a game player such as swinging the hand-held remote game peripheral through a broad arc from one side of the body to the other may be clipped in this example the upper range of motion is not captured due to the sensitivity of the sensor being set to a range of measurement that is not broad enough to capture the entire arc of motion. To forestall clipping, and the associated loss of motion data, the game server400may send a command to the remote game peripheral to adjust the sensitivity of the sensor to a broader range when gross gestures are expected. The game server may know when gross or finer gestures are expected by following a game script. The game script, as prepared by the author of the game, may include sensor sensitivity settings that anticipate the type of gestures expected at any given point in the game. The game server is then able to dynamically prepare the remote game peripheral for the expected range of motion by transmitting a sensor sensitivity adjustment command and a new sensor sensitivity setting to the remote game peripheral as necessary.

In an exemplary embodiment, the game performs an initialization of the remote game peripheral when the game starts. An initial frame of reference is established in x, y, z axis coordinates for the position of the remote game peripheral. This initial position is set to x=0, y=0, and z=0. As represented inFIG. 5B, during a 20 second time window for measuring movement of the peripheral, the measurement of tilt angle for finer gestures may be represented by measurements of angular displacement along each of the x, y, and z axes. The expected gesture, according to the game script at this moment in the game, may be a finer gesture and the game server may send a sensor sensitivity adjustment to the game peripheral to adjust the measurement range to capture a small movement of the remote game peripheral. In this exemplary embodiment, a game player may be holding the remote game peripheral at an angle of 10 degrees in the z axis, with x and y axes at zero at an initial time=0 point510, which is the start point of the measured time window. At time=7 seconds520the tilt angle in the z axis has increased to 20 degrees, and at time=14 seconds530the tilt angle in the z axis has increased to 30 degrees. At the close of the measurement window, the tilt angle and time values are transmitted to the game server. The game server may then calculate the total tilt and time values for the remote game peripheral and determine the total movement of the fine gesture made by the game player. This information for the game player currently using the remote game peripheral is stored in the game server.

In this exemplary embodiment, the accelerometer transmits the start time, stop time, velocity and instant acceleration measurements to the game server. The game server may then calculate the distance the remote game peripheral has moved by doubly integrating the instant acceleration value. The distance traveled and the position information in x, y, z axis coordinates may then be compared against a pre-stored library of game user movements. Depending upon the game script the comparison of the game player's movement may be used to provide feedback to the game player that will allow the game player to assess personal performance in the game at the time the feedback is provided.

Another exemplary embodiment is referenced inFIG. 6. A game author creates a game script that utilizes the capability for the dynamic adjustment of sensor sensitivity and embeds sensor sensitivity settings in the script. Once the game script is initiated600, the initial sensor sensitivity setting is transmitted to the remote game peripheral. The setting value may be embedded within the command and setting message605as a pre-set number of bits as a dedicated sensitivity adjustment setting value. In this exemplary embodiment, the game server awaits messages from the remote game server indicating that the game player has moved the remote game server from the last recorded position610. The remote game peripheral sends sensor movement information that may include positional information in x, y, z axis parameters, velocity, instant acceleration, and tilt angle information if the sensor within the remote game peripheral is an accelerometer615. However, these sensor movement parameters should in no way be considered limiting as each sensor will have its own set of pre-defined measurements that are utilized to indicate repositioning or movement of the remote game peripheral. In the instant embodiment, by way of example, the game server may use the movement parameters received from the remote game server to calculate position, tilt, direction and other position related values from the sensor parameters received620. The game server may then retrieve a gesture from a library of gestures stored within the game server and compare the movement parameters calculated against the pre-stored gesture parameters. The game software may then be operative to compare the gesture against the timing and/or step within the game script to determine if the game player has exceeded a pre-set threshold value that indicates that the game player has performed an action that is worthy of a reward630based upon the pre-set expectations for the game script. If the game player has exceeded the action reward value, the game server may send a command to the remote game peripheral to turn on reward lights, generate a noise, or provide bonus points, or activate any other reward system available within the game software640. This reward feedback provides an indication to a game player that they are successfully mastering the scripted expectations of the game, thus enhancing the game player's enjoyment by providing indications of success in play.

Continuing in the exemplary embodiment, the comparison of the remote game peripherals motion against the retrieved library gesture may indicate that the game user has not performed an action that meets the minimum expected threshold value for a gesture at that moment in the game635. The game server may then instead of sending a reward command, the game server may send a correction command to the remote game server645. This command may light only a single light on the remote game serve, play a raucous noise, or provide another indication that the game player is not meeting the minimum expectations of the game. Once again, this correction feedback serves as a game enhancement by providing information to game user that they are not meeting the expectations of the game, and at what point they are not meeting the game expectations, such that correction is possible. This provides the game player with the knowledge of where expectations were not met such that they can improve their performance at those portions of the game such that they will improve over time. Once again, the remote game peripheral provides knowledge that will enhance the game player's experience in the game. The game script continues to advance625until the entire game script has been completed.

While dynamic sensitivity adjustment for sensors within a remote game peripheral has been described in connection with the example embodiments of the various figures, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same functions of dynamic sensitivity adjustment for sensors within a remote game peripheral without deviating therefrom. Therefore, dynamic sensitivity adjustment for sensors within a remote game peripheral as described herein should not be limited to any single embodiment, but rather should be construed in breadth and scope in accordance with the appended claims.