SYSTEM AND METHOD FOR USING HANDHELD DEVICE AS WIRELESS CONTROLLER

A method and system for using handheld device (100) as a wireless controller is provided. The method includes, receiving at least of roll data (208), pitch data (210), yaw data (212) and acceleration data (214) corresponding to the handheld device (100); determining one or more actions to be performed based on one or more values of the at least of roll data (208), pitch data (210), yaw data (212) and acceleration data (214); and enabling performance of actions that are displayed on at least one display that is discrete from the handheld device (100).

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

I. OVERVIEWII. EXEMPLARY SYSTEM ARCHITECTURE OF A HANDHELD DEVICEIII. EXEMPLARY BLOCK DIAGRAM OF A SENSORS MODULEIV. ANOTHER EXEMPLARY BLOCK DIAGRAM OF THE SENSORS MODULEV. EXEMPLARY METHOD TO USE DATA RECEIVED FROM THE SENSORS MODULEVI. EXEMPLARY BLOCK DIAGRAM OF A CONTROL MODULEVII. FLOWCHART OF AN EXEMPLARY METHOD FOR CALIBRATING YAW VALUEVIII. FLOWCHART OF AN EXEMPLARY METHOD FOR NORMALIZING YAW VALUES DURING A GAMING SESSIONIX. A FIRST EXAMPLE OF USING DATA RECEIVED FROM THE SENSORS MODULE

The following detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show illustrations in accordance with example embodiments. These example embodiments are described in enough detail to enable those skilled in the art to practice the present subject matter. However, it will be apparent to one with ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments. Within the scope of the detailed description and the teachings provided herein, additional embodiments, application, features, and modifications are certainly are recognized by a person skilled in the art. Therefore, the following detailed description is not to be taken in a limiting sense.

In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one. In this document, the term “or” is used to refer to a nonexclusive “or,” such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated.

II. Exemplary System Architecture of a Handheld Device

FIG. 1is a block diagram of an exemplary handheld device100, in accordance with an embodiment. The handheld device100, for example, can be a feature phone, smart phone or tablet, among other such devices. The handheld device100includes a control module102, a storage module104, an input module106, a communication module8108, a sensors module110and a display module112.

The control module102can include an Application-Specific Integrated Circuit (ASIC). In another embodiment, the control module102can include a microprocessor. The control module102can access instructions that may be stored in the storage module104. Further, the control module102can receive inputs from other modules/units of the handheld device100. The control module102processes the inputs as per the instructions and controls operation of one or more modules/units of the handheld device100.

The storage module104, for example, can include, read-only memory (ROM), random-access memory (RAM), subscriber identity module (SIM), optical data storage devices and hard disks. The storage module104stores instructions that can be retrieved by the control module102for controlling the operation of the handheld device100. The storage module104stores data generated during the operation of the handheld device100. Further, data that may be required for subsequent retrieval is also stored in the storage module104.

The input module106is configured to receive inputs from input means, such as, keypad, microphone and touch sensitive display, among others.

The communication module108is configured to transmit and receive data using communication channels. The communication module108for example, can be configured to communicate date with a television, using radio frequency.

The sensors module110includes sensors, such as, gyroscope and accelerometer. The sensors module110can also include magnetometer. These sensors sense the movement of the handheld device100, and communicate respective data to the control module102.

The display module112displays still images, moving images and characters. The display module112can be, for example, a LCD display or LED display, among others.

The handheld device100is configured to be used as a wireless controller for playing games, which will be displayed on a large display, such as a television. The handheld device100uses data received by the sensors module110to control video games. The video games that are controlled can be mobile games, such as, for example, tennis, table-tennis, badminton, baseball, cricket, fishing, fitness and rhythm games, dance simulation game, aerobics fitness, shooting games, point and shoot games, first person shooters, third person shooters, archery, sword fighting, Frisbee and disc throwing games, among others.

III. Exemplary Block Diagram of a Sensors Module

FIG. 2ais a block diagram of an exemplary sensors module110that is configured to communicate with the control module102, in accordance with an embodiment. The sensors module110includes a gyroscope202, a magnetometer204and an accelerometer206. The gyroscope202and the magnetometer204generate roll data208, pitch data210and yaw data212. The roll data208, pitch data210and yaw data212can be collectively referred to as attitude data. The accelerometer206generates acceleration data214. The attitude data and acceleration data214is communicated to the control module102, which processes the data to control the video game.

IV. Another Exemplary Block Diagram of the Sensors Module

FIG. 2bis a block diagram of another exemplary sensors module110that is configured to communicate with the control module102, in accordance with an embodiment. The sensors module110includes a gyroscope202and an accelerometer206. The gyroscope202generates the attitude data, while the accelerometer206generates acceleration data214. The attitude data and acceleration data214is communicated to the control module102, which processes the data to control the video game.

V. Exemplary Method to Use Data Received From the Sensors Module

In an embodiment, the control module102is configured to process data received from the sensors module110. The control module102includes an action library. The action library includes actions to be performed, for example in the video game that may be displayed on a television. The control module102processes data received from the sensors module110to control actions, which are displayed at least on a display, such as a television, which is discrete from the handheld device100. The control module102after receiving the data from the sensors module110determines the one or more actions to be performed by querying the action library.

In an embodiment, each action in the action library is based on values corresponding to one or more of roll data, pitch data, yaw data and acceleration data.

In an embodiment, each action in the action library is based on change in values corresponding to one or more of roll data, pitch data, yaw data and acceleration data.

In an embodiment, each action in the action library is based on range of values corresponding to one or more of roll data, pitch data, yaw data and acceleration data.

In an embodiment, the control module102performs the action in the handheld device100, which is displayed on a device, which has a relatively larger display, such as a television.

In an embodiment, the control module102communicates the data received from the sensors module110, to an external device, such as a set top box. The external device can include the action library, which queries the action library, and actions are performed based on the data received from the control module102and the action library.

In an embodiment, the control module102communicates the data received from the sensors module110, to an external device, such as a television. The external device can include the action library, which queries the action library, and actions are performed based on the data received from the control module2102and the action library.

In an embodiment, sensor data, such as the yaw data is normalized, so that the actions can be performed accurately.

VI. Exemplary Block Diagram of a Control Module

FIG. 3is a block diagram of an exemplary control module102that is configured to enable controlling of video games using the handheld device100, in accordance with an embodiment. The control module102includes a calibration module302, a normalization module304and an action determination module306.

The calibration module302calibrates yaw value by determining a normalization factor that is applied to yaw data, which is received from the sensors module110. The normalization factor is used to determine normalized yaw value, which is used to accurately control video games.

The normalization module304determines normalized yaw values by using the normalization factor and the yaw data, which is received from the sensors module110.

The action determination module306uses the yaw values, pitch data, roll data and acceleration data to determines the actions to be effected in the video game that is being played and controlled using the handheld device100.

VII. Flowchart of an Exemplary Method for Calibrating Yaw Value

Yaw value, as indicated inFIG. 4a, varies between 0 Radian to +3.14 Radian, and 0 Radian to −3.14 radian. The yaw value changes if a device, such as the handheld device100, changes orientation in either directions. It shall be noted that, 0 Radian of yaw is not fixed. The yaw value is set to 0 Radian when reception of yaw data is initiated.FIG. 4bis an exemplary illustration of a first orientation402of the handheld device100, when reception of yaw data is initiated, in accordance with an embodiment. At the first orientation402of the handheld device100, the yaw value is set to zero. It shall be noted that the orientation at which reception of yaw data is initiated can vary almost every time the handheld device100is used to control video games. Hence, controlling of games using this yaw data is not possible. Hence, conventionally, yaw data does not seem to have been used for controlling games using handheld devices, such as smart phones.

In order to use yaw data for controlling games using the handheld device100, yaw value is calibrated subsequent to initiation of reception of yaw data. In order to calibrate the yaw value, subsequent to initiation of reception of yaw data, user of the handheld device100is requested to hold the handheld device100as per an instructed orientation.FIG. 4cis an exemplary illustration of the handheld device100held in the instructed orientation404, in accordance with an embodiment. The instructed orientation404, can be, for example, holding the handheld device100perpendicular to the plane of a television on which the video game is being displayed. The yaw value at the instructed orientation is used to calibrate yaw data, thereby enabling usage of yaw data for controlling games using the handheld device100.

FIG. 5is a flow chart of an exemplary method for calibrating yaw data, in accordance with an embodiment. At step502, reception of yaw data from the sensors module110is initiated. As soon as the reception of yaw data from the sensors module110is initiated, yaw value of0Radian is assigned to the orientation of the handheld device110at which the reception was initiated (step504). Subsequently, the user orients the handheld device100to an instructed orientation. At step506, the yaw value with the handheld device100held as per the instructed orientation is recorded. The yaw value that is recorded with the handheld device100held as per the instructed orientation is used to determine a normalization factor (step508).

It shall be noted that, a user, although instructed to hold the handheld device100as per the instructed orientation, may not be holding the handheld device100as per the instructed orientation. However, if the user, either explicitly or implicitly, provides an input that the handheld device100is held as per the instructed orientation, then the control module102determines the normalization factor as per the yaw value recorded at the instant orientation at which the handheld device100is held.

FIG. 6is a flow chart of an exemplary method for determining the normalization factor, in accordance with an embodiment. At step602, the yaw value is recorded when the handheld device100is held as per the instructed position. Subsequently, at step604, a verification is carried out to determine whether the yaw value is greater than zero, less than zero or equal to zero. If it is determined that the yaw value is equal to zero, than at step606, the normalization factor is set to zero. On the other hand, if at step604, it is determined that normalization factor is greater than zero, than the normalization factor is calculated by subtracting PI, which is 3.14, from the yaw value (in Radian), which is recorded at step602. Further, if at step604, it is determined that normalization factor is less than zero, than the normalization factor is calculated by adding PI, which is 3.14, with the yaw value (in Radian), which is recorded at step602.

The normalization factor is used to normalize yaw values that are received during a gaming session (the same session in which the instant normalization factor is determined) to control the game using the handheld device100.

VIII. Flowchart of an Exemplary Method for Normalizing Yaw Values During a Gaming Session

FIG. 7is a flow chart of an exemplary method for normalizing yaw values during a gaming session, in accordance with an embodiment. At step702, normalization factor is determined. At step704, verification is carried out to check whether the normalization factor is greater than or less than zero. If the normalization factor is less than zero, then at step706, it is verified whether yaw value that has to be normalized, which is collected during a gaming session, is greater than the normalization factor. If the yaw value is less than the normalization factor, then at step708, normalized yaw value is determined subtracting normalization factor and yaw value from PI. On the other hand, if the yaw value is greater than the normalization factor, then at step710, normalized yaw value is determined subtracting normalization factor and PI from yaw value.

Similarly, if at step704, it is determined that normalization factor is greater than zero, then at step712, it is verified whether yaw value that has to be normalized, which is collected during a gaming session, is greater than the normalization factor. If the yaw value is less than the normalization factor, then at step714, normalized yaw value is determined subtracting the normalization factor from yaw value and PI. On the other hand, if the yaw value is greater than the normalization factor, then at step716, normalized yaw value is determined by subtracting normalization factor and PI from yaw value.

The normalized yaw values, roll data, pitch data and acceleration data are used by the control module to control the video game using the handheld device100.

IX. A First Example of Using Data Received From the Sensors Module

In an embodiment, the data received from the sensors module110is used to control a video game, such as a tennis video game. In this example, the video game is included in the handheld device100, which also includes the sensors module110. The video game, while being processed in the handheld device100, is displayed on a television. Therefore a gamer controls the video game using the handheld device100, while the video game is displayed on the television.

The yaw value is calibrated and the subsequent yaw values are normalized, as explained earlier. Further, the gamer provides an input as to whether the handheld device is held in the right hand or the left hand. This instant input is used to determine the type of tennis shot that is being played by the gamer.

Further, each yaw value is de-scaled, by applying a de-scaling factor. The de-scaling factor can vary based on game requirements. In this example, de-scaled yaw may be referred to as yaw.

Additionally, the yaw value, which may be polar form is converted into Cartesian coordinates in X, Y and Z direction. The conversion can be carried out as provided below:Direction Y=0.0;Direction X=−Sin (yaw);Direction Z=−Cos (yaw);

The above conversion provides the direction of the shot.

The yaw value is used to determine the shot hand in this tennis game. The shot hand, for example, is of four types, namely, right hand fore hand, right hand back hand, left hand fore hand and left hand back hand.FIG. 8is a flow chart of an exemplary method for determining short hand using yaw value, in accordance with an embodiment. At step802, start and end value of yaw is recorded by the control module102. Further, at step804, the control module102checks whether the handheld device100is held in the right or left hand, which is an input provided by the user. If the handheld device100is held in the right hand, then the control module102determines whether the difference obtained by subtracting end value of yaw from the start value of yaw is greater or equal to zero, at step806. If the instant difference is greater than or equal to zero, then the short hand is determined to be right hand fore hand, else the short hand is determined to be right hand back hand.

Alternatively, if the handheld device100is held in the left hand, then the control module102determines whether the difference obtained by subtracting end value of yaw from the start value of yaw is less than or equal to zero, at step806. If the instant difference is less than or equal to zero, then the short hand is determined to be left hand fore hand, else the short hand is determined to be left hand back hand.

The control module102also determines the tennis shot type. The shot type, for example, can be, normal, drop and lob. The control module102determines the shot type using the roll value. The control module102can use average roll value to determine the shot type. In order to determine the shot type, vertical upper and lower limit for roll, and horizontal upper and lower limit for roll may be preset. The limits can be, for example, as provided below:

Vertical lower limit=0.8

Vertical upper limit=2.35

Horizontal lower limit=2.35

Horizontal upper limit=3.14

FIG. 9is a flow chart of an exemplary method for determining short type using roll value, in accordance with an embodiment. At step902, the control module102records the roll value. At step904, the control module102checks, whether the roll value is greater than or equal to the vertical lower limit, and whether the roll value is lesser than or equal to the vertical upper limit. If the roll value is greater than or equal to the vertical lower limit, and the roll value is lesser than or equal to the vertical upper limit, then the shot type is determined to be a “normal” shot, at step906.

If it is determined that, at least one of, the roll value is not greater than or equal to the vertical lower limit, and the roll value is lesser than or equal to the vertical upper limit, then at step908, the control module102checks, whether the roll value is greater than or equal to the horizontal lower limit, and whether the roll value is lesser than or equal to the horizontal upper limit. If the roll value is greater than or equal to the horizontal lower limit, and the roll value is lesser than or equal to the horizontal upper limit, then the shot type is determined to be a “lob” shot, at step910. Else, the shot type is determined to be a “drop” shot.

In light of the foregoing description, it shall be noted that the determination of shot direction, shot hand and shot type enables controlling the video game using the handheld device100, while the game is displayed on a larger display screen, such as a television screen.

In an embodiment, acceleration data214is used to determine whether an action has to be performed or not. For example, threshold limits for acceleration data214are set for X, Y and Z axis. The control module102determines that an action, such as, playing of a tennis shot, has been performed. Subsequently, the control module102uses attitude data to query the action library for identifying the action to be performed.

In an embodiment, the control module102uses the acceleration data214for adding an attribute, such as speed of a shot, to an action. In an embodiment, the handheld device100is used as a wireless controller. The method of using the handheld device100as the wireless controller includes, receiving at least of roll data, pitch data, yaw data and acceleration data corresponding to the handheld device; determining one or more actions to be performed based on one or more values of the at least of roll data, pitch data, yaw data and acceleration data; and enabling performance of actions that are displayed on at least one display that is discrete from the handheld device.

In an embodiment, at least one of roll data, pitch data, yaw data and acceleration data corresponding to the handheld device is received by the control module102. The control module determines one or more actions performed by a user who is using the handheld device, based on one or more values of the at least one of roll data, pitch data, yaw data and acceleration data. Further, the one or more actions performed by the user are compared with benchmark. The comparison can be used to take required decisions.

For example, a dance game can use the functions of the control module102to determine steps (actions) performed by a gamer who dances while holding the handheld device. Later, the steps can be compared with benchmark steps. Subsequently, the gamer can be informed about how well the gamer has performed with respect to the benchmark.

The processes described above is described as sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, or some steps may be performed simultaneously.

In an embodiment, a computer program product is provided. The computer program product includes a computer readable medium. The computer readable medium includes instructions, that can be executed by a data processing system, such as, for example, a handheld device and a microprocessor. The execution of the instructions, causes the data processing system to operate as described herein.

Although embodiments have been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the system and method described herein. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. It is to be understood that the description above contains many specifications, these should not be construed as limiting the scope of the invention but as merely providing illustrations of some of the personally preferred embodiments of this invention. Thus the scope of the invention should be determined by the appended claims and their legal equivalents rather than by the examples given herein.