The present invention relates generally to video games and, more particularly, to a video game and a peripheral for a video game.
Toys such as dolls, cars and robots provide countless hours of fun and enjoyment for many. Toys often serve as a vehicle for expanding the imagination and cultivating creativity.
Video games also provide fun and enjoyment for many. Video games allow game players to participate in a variety of simulated activities. Video games allow game players to perform roles and experience activities that the game players may not be able or desire to experience directly, whether due to cost, danger, or equipment concerns, or simply due to a roll or activity being a fantasy.
However it is generally difficult to acquire marketing information from video game consumers. Market surveys have been used, but require significant effort to prepare the questions and substantial resources to collect the responses. These surveys also depend heavily on the truthful and accuracy recollection of the survey takers. Even still, a substantial expenditure of resources and capital are required before it is known whether the data collected is provide the desired information.
One aspect of the invention provides a system for collecting information related to a video game, comprising: a physical object including a memory for storing marketing information related to a video game; and a first video game system in communication with the toy for executing instructions to a conduct a video game play using the physical object, the first video game system being configured to monitor marketing information and write the information to the memory of the physical object.
Another aspect of the invention provides a system for collecting information related to a video game, comprising: a physical object including a memory for storing marketing information related to a video game; a first video game system in communication with the toy for executing instructions to a conduct a video game play using the physical object, the first video game system being configured to monitor marketing information and write the information to the memory of the physical object; and a server in communication with the physical object to receive the information and store the information in a storage unit.
These and other aspects of the invention are more fully comprehended upon review of this disclosure.
The instructions providing for game play are generally stored on removable media, for example, an optical disk. Accordingly, the game console may include an optical drive, for example, a DVD-ROM drive, for reading the instructions for game play. In some embodiments, the game console may be a personal computer, including similar internal circuitry as herein described, as well as, for example, a built-in display and built-in user input devices, such as a keyboard and a touch pad.
The display device is generally coupled to the game console by a cable, although in some embodiments a wireless connection may be used. In many embodiments, the display device is a liquid crystal display. In some embodiments, the display device is a television. A display screen 131 of the display device displays video images of game play, generally as commanded by the processor or other associated circuitry of the game console. In the embodiment of
The toy reader, in some embodiments and as shown in
Each toy includes machine-readable information, for example, memory, a radio frequency identification (RFID) tag or a barcode. The machine-readable information may be sensed, read, and/or in some embodiments written, by the reader, in some embodiments indirectly by way of sending data and commands to the toy to write the data to memory of the toy. The machine-readable information may include a numeric identifier. The machine-readable information allows the reader, or the processor of the game console, to distinguish one toy from other toys, and the machine-readable information may therefore be considered to include a toy identifier, and in some embodiments, each particular toy has its own distinct identifier. In addition, in many embodiments the machine readable information includes additional information about a corresponding game character, including in some embodiments, status of the game character in a game.
When a toy is read by the reader, the reader provides the game console an indication of the identifier and status information of the toy, and generally the processor of the game console commands display of a corresponding game character or otherwise makes the corresponding game character available in game play. Likewise, when a toy in the form of an article such as a hat is placed on the reader, the processor may make a corresponding article appear in the game and the article may affect changes or the ability to make changes in the game. For example, when a hat toy and a character toy are concurrently on the reader, the corresponding character in the game may possess the corresponding hat. Thus, video game play may be affected by use of real world objects, objects which may also be utilized for play and/or observation separate from video game play.
The processor is coupled to an audio driver 221 and a video driver 223. The audio driver produces sound signals and the video driver produces image signals. The sound signals and image signals are transmitted from the game console via a display I/O device 225. The display I/O device generally supplies the sound and image signals to a display device external to the game console. Sound signals may also be supplied to a peripheral device such as a toy reader.
The processor may also be coupled to a user I/O device 217, a wireless transceiver 219, an Internet I/O device 227, and other circuitry 229. The user I/O device may receive signals from a toy reader and/or signals from a keyboard, a mouse, and/or a game controller, with generally the keyboard, mouse, and/or controller being used by a user and providing user inputs, for example, during game play. Alternatively or additionally, the game console may receive user inputs via the wireless transceiver. The Internet I/O device provides a communication channel that may be used, for example, for multiple player games.
In one embodiment of an optical interface the toy includes a light source, for example an LED, to provide information of the machine readable information and a photodiode to receive information of commands, with circuitry operable within the toy to provide for associated operation of the LED and photodiode in performing communication functions. Power may be provided to the toy by way of a battery, by way of RFID operations, or by other sources. In such an embodiment the toy reader similarly includes a photodiode and LED for communication with the toy.
In another embodiment the toy reader includes an imaging device, for example a CCD and associated circuitry. In such embodiments the imaging device may generate an image, for analysis by the reader or in most embodiments by the game console, with the image providing information related to the toy. In some embodiments identity of the toy may be determined by shape or other features, such as color or reflectivity, of the toy or portions of the toy. Similarly, identity and other information of the toy may be provided by image information placed on the toy, including, for example, information of stickers placed on the bottom of the toy, placed either prior to receipt of the toy by a user or by the user, in which case the information may be changed by the user in accordance with game play results. The toy may instead or in addition may include bar code or bar code like information, with the reader including bar code scanning components.
Further in some embodiments the toy may include a wired connection to the reader, or in some embodiments, a wired connection to the game console, possibly dispensing with the reader. Similarly, in some embodiments the toy may include wireless communication capabilities of the type commonly used with computers, for example Bluetooth or Wi-Fi capabilities.
The information communicated between the toy and the peripheral and between the peripheral and the game console may be encrypted, and the information read from or written to the toy by the peripheral may also be encrypted.
The peripheral includes a controller 301 that is coupled to the USB interface and the radio-frequency interface. The controller adapts the signals between protocols used by the two interfaces. The controller generally includes a programmable device such as a microprocessor performing program instructions and a memory. The program instructions may be stored in the peripheral as firmware or downloaded from the game console.
The peripheral also includes, in some embodiments, a loudspeaker 331. The loudspeaker provides audio signaling to game players and the signaling may relate to a particular toy present on the peripheral. In some embodiments, the peripheral includes visual indicators such as light-emitting diodes 341a-c. The diodes may, for example, be illuminated with intensities or colors according to characteristics of the toy or to signal performance in the video game of characters associated with toys on the peripheral. Both the loudspeaker and visual indicators are coupled to the controller. The controller signals the loudspeaker and visual indicators to operate according to commands received via the USB interface.
In block 411, the process requests toys send their identifiers. For example, in an embodiment of the process that uses the ISO/IEC 14443 protocol, the process may transmit a request command (REQA) or a wake-up command (WUP). The process listens for and receives any responses to the request that toys send their identifiers. Each identifier is generally unique to a particular toy.
In block 415, the process determines whether multiple toys responded to the request sent in block 411. For example, multiple toys may respond when there are multiple toys on the peripheral device of
The process may, in block 411, include a range of identifiers in the request that toys send their identifiers. For example, the process may include a string of bits (for example, least-significant bits) in the request with only toys having identifiers with starting bits having values that match the string being requested to send their identifiers. The process may iterate through block 411 and block 415 with an increasingly narrow range of identifiers in the request until an identifier is individually received from each toy.
In block 421, the process selects a toy for further communication. The process may, for example, select the toy by sending a select command (SEL) that includes the identifier of the selected toy.
In block 425, the process determines whether it received an acknowledgment from the toy in response to the selection. The process may, for example, determine that it received an acknowledgment when it receives a selection acknowledge (SAK) message from the selected toy. When the process determines that it has received an acknowledgment, the process continues to block 431; otherwise, the process returns to block 411. In other embodiments, the process may return when an acknowledgment has not been received or may return to block 421. When the process does not receive an acknowledgment, the process may additionally inform a game with which the process is associated that the selected toy is not present.
In block 431, the process sends a command to the selected toy. For example, the process may send a read command to acquire data from the toy or a write command to supply data to the toy.
In block 435, the process determines whether it received an acknowledgment from the toy in response to the command sent in block 431. The process may, for example, determine that it received an acknowledgment when it receives a message containing a positive acknowledgment (ACK) from the selected toy. When the process determines that it has received an acknowledgment, the process continues to block 445; otherwise, the process returns. In other embodiments, the process may return to block 531 when an acknowledgment has not been received. When the process does not receive an acknowledgment, the process may additionally inform the game associated with the process that the selected toy is not present.
In block 445, the process determines whether it has any more commands to send to the selected toy. The process may determine that it has more commands for the toy, for example, by checking a list of actions in the game associated with the process. When the process determines that there are more commands for the selected toy, the process returns to block 431; otherwise, the process returns.
In block 511, the process determines whether it has received a request for an identifier associated with the toy. For example, in an embodiment of the process that uses the ISO/IEC 14443 protocol, the process may determine whether it has received a request command (REQA) or a wake-up command (WUP). When the process determines that it has received a request for its identifier, the process continues to block 515; otherwise, the process continues to block 531.
In block 515, the process sends an answer to the request for its identifier. The answer generally includes the identifier or a portion of the identifier. For example, the request for the identifier may have included a portion of the identifier with the process including the remaining portion of the identifier in the answer. Thereafter, the process returns to block 511.
In block 531, the process determines whether it has been selected for further data communication. The process may, for example, determine that it has been selected when a select command (SEL) is received that includes the identifier of the toy. When the process determines that it has been selected, the process continues to block 535; otherwise, the process returns to block 511.
In block 535, the process acknowledges the selection determined in block 531. The process may, for example, transmit a selection acknowledge (SAK) message.
In block 541, the process determines whether it has received a data command. The process may, for example, determine that it has received a command instructing it to read data from or write data to a memory. When the process determines that it has received a data command, the process continues to block 545; otherwise, the process continues to block 561.
In block 545, the process performs the command of block 541. For example, the process may perform a read command by reading values from the memory and transmitting the values. In another example, the process may perform a write command by writing values supplied with command to the memory and transmitting an acknowledgment of the command. Thereafter, the process returns to block 541.
In block 561, the process determines whether it has been deselected from further data communication. The process may, for example, determine that it has been deselected when it receives a deselect command (DESEL) or a halt command (HLTA). When the process determines that it has been deselected, the process continues to block 571; otherwise, the process returns to block 541. In some embodiments, the process may return when it determines that it has been deselected.
In block 571, the process determines whether it should wake-up. The process may, for example, determine that it should wake-up when it receives a wake-up command (WUP). When the process determines that it should wake-up, the process returns: otherwise, the process remains in block 571. When the process is in block 571, it may be considered to be in a halted state in that it does not respond to identification requests, selection commands, or data commands.
The data structure includes an area of fixed information 605. The fixed information includes information that identifies a type of toy and a particular instance of the toy, for example, the fixed information may include a 32-bit serial number. The fixed information may also include an identification of objects related to the toy, such as an identification of a trading card. The fixed information generally includes a field for data verification, for example, a cyclic-redundancy check value or checksum. The fixed information is generally written when the toy is created and not thereafter changed.
The data structure also includes a first data area 610 and a second data area 620. Each of the data areas contains corresponding fields for certain values representing status information about the toy. However, the first data area and the second data area contain values that reflect the toy's status at different times. For example, the first data area may contain current values and second data area may contain previous values. How which of the data areas is current may be determined and controlled is described further with reference to
The first data area 610 includes a first header 611. The first header includes information about the toy that may change frequently during game play, such as fields that store score values, experience levels, or money values. The first header may also include a field indicating how much cumulative time the toy has been used. The first header also contains a sequence field that may be used to determine whether the first data area contains current data.
The first data area 610 includes a first initial information area 612. The first initial information area includes information about the toy that facilitates adding the toy to game play. For example, the first initial information area may include a field that stores a name for the toy. The first initial information area may include additional fields that store information useful for displaying a representation of the toy in the game. For example, there may be information indicating upgrades that have been acquired for the toy or objects the toy may be wearing, such as hats.
The first data area 610 includes a first further information area 613. The first further information area includes fields that indicate additional information about the toy's status beyond the information contained in the first header and the first initial information area. The fields in the first further information area may include, for example, an indication of what challenges or skill tests the toy has completed in the game. The fields in the first further information area may also include information related to gameplay, for example, a value indicating when the toy most recently joined the game, a value indicating when the toy was first used in the game, a value indicating the total time that the toy has been used in the game, an identification of the different types of video game system that the toy have been used in connection with to play the game and the frequency of such use on each of a different types of video game systems. The information may also include game-related statistics such as hit points, score, a number of a collectible item collected. Further, the information may also include game state information. The game state information includes, but is not limited to, the level of the game being played, the mode of play, length of time played during a game play session.
The first data area generally includes one or more fields for data verification, for example, checksums. In one embodiment, the first header includes three checksums: a checksum for the entire first data area, a checksum for the initial information area, and a checksum for the header itself. The inclusion of three checksums may allow the corresponding areas to be verified or updated without reading or writing other areas.
The second data area 620 includes a second header 621, a second initial information area 622, and a second further information area 623. Each of the areas in the second data area corresponds to a like named area in the first data area.
In block 711, the process reads fixed information from the toy. The information may be read using a process as shown in
In block 721, the process reads header information for each of multiple data areas of the toy information. Each header is associated with a data area. The header information includes a sequence value indicating when, in comparison to other headers, the header was written. For example, the sequence value may be incremented modulo a maximum value each time a header is written.
In block 731, the process determines which of the headers is the current, or newest, header. The process may compare the sequence values of the headers to determine the latest sequence value, which indicates the current header. The process selects the data area associated with the current header for further use in the process.
In block 741, the process reads initial information from the toy. The initial information is read from the data area associated with the current header. In block 751, the process adds a representation of the toy in the video game. For example, the process may display a representation of the toy, including information about the toy included in the initial information, on the display screen of the video game system illustrated by
In block 761, the process reads further information from the toy. The further information is also read from the data area associated with the current header. In block 771, the process enhances the representation of the toy in the video game. For example, the process may add details read in block 761 to the representation of the toy.
The process of
In block 811, the process determines an event type that may result in updating information in the toy. The process may determine the event type based on game play events. If the process determines that the event type is a time change, the process returns. That is, a time-change event does not result in the process writing information to the toy.
If the process determines that the event type is a critical event, the process continues to block 831. A critical event is an event for which it is desirable to quickly update information in the toy. Critical-type events may include, for example, changes to the toy's name, changes to performance levels of the toy, or acquisition of upgrades for the toy.
If the process determines that the event type is a routine event, the process continues to block 821. A routine event is an event for which it is acceptable to delay writing information in the toy. Routine-type events may include, for example, changes to the toy's score or changes to the experience level of the toy. Routine-type events may occur frequently during game play and thus it may be desirable to otherwise use the time that would be used to write to the toy, for example, to read information from another toy.
In block 821, the process waits for a time delay. For example, the process may wait three seconds. The process thereafter continues to block 831. In some embodiments, further events may be evaluated in block 811 while the process is waiting in block 821. When a further event occurs, the process may continue waiting for the current time delay, restart the time delay, or end the time delay. For example, when the event is a time change, the process may continue waiting; when the event is a routine event, the process may restart the delay; and when the event is a critical event, the process may terminate the delay and continue to block 831.
In block 831, the process writes information to the toy. The written information generally corresponds to the event as analyzed in block 811. For example, when the event is an event to change the toy's name, a new name is written to the toy. The data is written to a data area that is the oldest of multiple data areas in the toy. The process may determine which data area to write to in a manner analogous to that used to determine the current data area in the process of
In block 841, the process writes the header of the data area in block 831. Writing the header includes writing a sequence number in the header to indicate that the associated data area is now the current data area. For example, a sequence number value from the current data area may be incremented, modulo a maximum value, and written to the header.
The process, in many embodiments, verifies that the information writes in blocks 831 and 841 were successful. For example, the process may read the values back from the toy and compare the results to the expected values. In the event of an error, the process may retry writing the information to the toy.
The system further includes a server 930 to receive information collected during video game play on the game console using the physical object. The server may be coupled to the game console via a communications network 925 such as the Internet such that the marketing information may be provided to the server for storage in a storage unit 940 such as a database or other data repository. The information may be provided to the server on a periodic basis or as the information is developed.
In an embodiment, the data may be read directly from the physical object via a personal computer and provided to the server without the use of a game console.
The information may be collected from a plurality of physical objects. In one example, the physical objects comprise a variety of fantastical creatures, each of which include a memory and may be used in connection with a video game console to conduct video game play. The collection of information may be analyzed to determine which creatures are most popular, which are used more frequently, and to identify which creatures are used most frequently on a particular type of gaming console. The information may also be analyzed to determine trends in use of each creature.
In one embodiment, the information may in a memory of the peripheral. In this case, the peripheral may store information related to each toy or object encountered in the detection area of the peripheral.
In block 1021, the process analyzes the information stored in the storage device .
Although the invention has been discussed with respect to various embodiments, it should be recognized that the invention comprises the novel and non-obvious claims supported by this disclosure.
Number | Name | Date | Kind |
---|---|---|---|
4840602 | Rose | Jun 1989 | A |
5413355 | Gonzalez | May 1995 | A |
5533920 | Arad et al. | Jul 1996 | A |
5661470 | Karr | Aug 1997 | A |
5752880 | Gabai et al. | May 1998 | A |
5766077 | Hongo | Jun 1998 | A |
5810666 | Mero et al. | Sep 1998 | A |
5853327 | Gilboa | Dec 1998 | A |
5873765 | Rifkin et al. | Feb 1999 | A |
6056618 | Larian | May 2000 | A |
6083073 | McFarlane et al. | Jul 2000 | A |
6167353 | Piernot et al. | Dec 2000 | A |
6290565 | Galyean, III et al. | Sep 2001 | B1 |
6354947 | Dobrusskin et al. | Mar 2002 | B1 |
6491566 | Peters et al. | Dec 2002 | B2 |
6544097 | Bain | Apr 2003 | B1 |
6709336 | Siegel et al. | Mar 2004 | B2 |
6729934 | Driscoll et al. | May 2004 | B1 |
6737957 | Petrovic et al. | May 2004 | B1 |
6761637 | Weston et al. | Jul 2004 | B2 |
6773325 | Mawle | Aug 2004 | B1 |
6773326 | Jarvis | Aug 2004 | B2 |
6796908 | Weston | Sep 2004 | B2 |
6905391 | Soto et al. | Jun 2005 | B2 |
6965298 | Feinberg | Nov 2005 | B2 |
6967566 | Weston et al. | Nov 2005 | B2 |
7001276 | Shinoda | Feb 2006 | B2 |
7066781 | Weston | Jun 2006 | B2 |
7081033 | Mawle et al. | Jul 2006 | B1 |
7244183 | England | Jul 2007 | B1 |
7297063 | Fujisawa et al. | Nov 2007 | B2 |
7331857 | MacIver | Feb 2008 | B2 |
7338377 | Shinoda | Mar 2008 | B2 |
7387559 | Sanchez-Castro et al. | Jun 2008 | B2 |
7425169 | Ganz | Sep 2008 | B2 |
7465212 | Ganz | Dec 2008 | B2 |
7488231 | Weston | Feb 2009 | B2 |
7500917 | Barney et al. | Mar 2009 | B2 |
7502759 | Hannigan et al. | Mar 2009 | B2 |
7524246 | Briggs et al. | Apr 2009 | B2 |
7534157 | Ganz | May 2009 | B2 |
7568964 | Ganz | Aug 2009 | B2 |
7604525 | Ganz | Oct 2009 | B2 |
7614958 | Weston et al. | Nov 2009 | B2 |
7618303 | Ganz | Nov 2009 | B2 |
7677948 | Ganz | Mar 2010 | B2 |
7789726 | Ganz | Sep 2010 | B2 |
7843471 | Doan et al. | Nov 2010 | B2 |
7846004 | Ganz | Dec 2010 | B2 |
7850527 | Barney et al. | Dec 2010 | B2 |
7862428 | Borge | Jan 2011 | B2 |
7878905 | Weston et al. | Feb 2011 | B2 |
7883416 | Dobrusskin et al. | Feb 2011 | B2 |
7883420 | Bradbury et al. | Feb 2011 | B2 |
20030076369 | Resner et al. | Apr 2003 | A1 |
20040214642 | Beck | Oct 2004 | A1 |
20060116192 | Okada | Jun 2006 | A1 |
20070006275 | Wright | Jan 2007 | A1 |
20070066396 | Weston | Mar 2007 | A1 |
20070143679 | Resner | Jun 2007 | A1 |
20070197297 | Witchey | Aug 2007 | A1 |
20070250597 | Resner et al. | Oct 2007 | A1 |
20070256716 | Resner et al. | Nov 2007 | A1 |
20080081694 | Hong et al. | Apr 2008 | A1 |
20080140528 | Ganz et al. | Jun 2008 | A1 |
20080141367 | Ganz et al. | Jun 2008 | A1 |
20080163055 | Ganz et al. | Jul 2008 | A1 |
20080274805 | Ganz et al. | Nov 2008 | A1 |
20080274806 | Ganz et al. | Nov 2008 | A1 |
20080274811 | Ganz et al. | Nov 2008 | A1 |
20080275789 | Ganz et al. | Nov 2008 | A1 |
20090053970 | Borge | Feb 2009 | A1 |
20090054155 | Borge | Feb 2009 | A1 |
20090063271 | Ganz et al. | Mar 2009 | A1 |
20090124165 | Weston | May 2009 | A1 |
20090132267 | Ganz | May 2009 | A1 |
20090132357 | Ganz | May 2009 | A1 |
20090132656 | Ganz | May 2009 | A1 |
20090158210 | Cheng et al. | Jun 2009 | A1 |
20090204420 | Ganz | Aug 2009 | A1 |
20090204908 | Ganz et al. | Aug 2009 | A1 |
20090228557 | Ganz et al. | Sep 2009 | A1 |
20090240659 | Ganz et al. | Sep 2009 | A1 |
20090248544 | Ganz | Oct 2009 | A1 |
20090254434 | Ganz et al. | Oct 2009 | A1 |
20090307609 | Ganz et al. | Dec 2009 | A1 |
20090318234 | Christensen et al. | Dec 2009 | A1 |
20100042486 | Borst et al. | Feb 2010 | A1 |
20100058235 | Borst | Mar 2010 | A1 |
20100062817 | Seydoux | Mar 2010 | A1 |
20100107214 | Ganz | Apr 2010 | A1 |
20100151940 | Borge | Jun 2010 | A1 |
20100161443 | Ganz et al. | Jun 2010 | A1 |
20100167623 | Eyzaguirre et al. | Jul 2010 | A1 |
20100262489 | Salinas | Oct 2010 | A1 |
20100293473 | Borst et al. | Nov 2010 | A1 |
20100325182 | Ganz | Dec 2010 | A1 |
20110040638 | Rabenold et al. | Feb 2011 | A1 |
20110077080 | Meer | Mar 2011 | A1 |
20110161093 | Ganz | Jun 2011 | A1 |
20120028707 | Raitt et al. | Feb 2012 | A1 |
Number | Date | Country |
---|---|---|
WO 2005050948 | Jun 2005 | WO |
Entry |
---|
Joint Technical Committee ISO/IEC JTC1/SC17, Information Technology, Subcommittee SC17, Final Committee Draft ISO/IEC 14443-3, Identification Cards—Contactless Integrated Circuit(s) Cards—Proximity Cards, Part 3: Initialization and Anticollision. Jun. 11, 1999. |
Atmel, Requirements of ISO/IEC 14443 Type B Proximity Contactless Identification Codes. Nov. 2005. |
Microchip, microlD 13.56 MHz RFID System Design Guide. 2004. |
Sonmicro, SM130, SM1013 Evaluation Kit, Mifare Brief Technical Information, SMRFID MIFARE v1.0 Software, User Manual, Jun. 2006. |
Number | Date | Country | |
---|---|---|---|
20120295714 A1 | Nov 2012 | US |