U.S. Pat. No. 8,529,350

DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

FIG. 1is an is an external view of a video game system and a historical event. An historical event11takes place. For example, the event may be a World Cup soccer game, or an American football game. In a more specific example, the event may be the occurrence of a new yearly completion percentage, or other performance statistic, of a specific quarterback in a specific professional American football game.

A datum17relating to the historical event11is recorded on a computer readable medium known as a network server14. A game machine20is coupled to the network server14. The game machine20downloads the datum17, which may, for example, represent a quarterback's completion percentage, a basketball player's freethrow percentage, or any other outcome of a realistic event. The datum17is then used to play a video game, which is displayed on a monitor24. A user28plays the video game using controller30. In this way, the user gets to play a video game the more accurately simulates a the real world.

For example, a datum representing a quarterback's new completion percentage is loaded into memory (not shown) in the game machine20. Then, the user28can play an American football video game with current statistics. This makes the video game more enjoyable to the user, adding increased realism. As real life professional players' performances change, users can still play with statistically accurate players.

FIG. 2is a block diagram of a video game system. The video game machine20incorporates a central processing unit (CPU)32and coprocessor (CP)34. The CP34includes a bus control circuit38for controlling buses, a signal processing unit (SPU)40for performing polygon coordinate transformation, shading treatment, etc., a display processing unit (DPU)45for rasterizing polygon data into an image to be displayed and converting the data into a data from (dot data) stored on a frame memory. The CP34is coupled to a cartridge connector50for detachably mounting with a ROM cartridge52, a disc drive connector54for detachably mounting with a disc drive56, and a RAM58. Also, the CP34is connected with an audio signal generating circuit61for outputting a sound signal to an audio output device62, processed by the CPU32, and an image signal generating circuit64for outputting an image signal to a display65. Further, the CP34is coupled with a controller control circuit67for serially transferring operational data for one or a plurality of controllers70A-70D and data for a RAM cartridge73for extension.

A modem72is coupled to the bus control circuit38. The modem72is also preferably coupled to the internet (not shown). As discussed with reference toFIG. 1, a server coupled to the internet stores performance, visual image and audio parameters. The modem72couples to the server and downloads a parameter for play in the video game. The CPU32sends a signal through the bus control circuit to initialize the modem72and control the modem72to download the parameter. Preferably, the parameter is stored in RAM58for play of the video game, as discussed below. It will be understood by those of skill in the art that other configurations of video game machines are possible. For example, the CPU32and the CP34, or portions of the CP34, may be incorporated as one component. Also, for example, RAM58, may be divided into more than one memory element, or other types of memory elements may be included.

Referring now toFIG. 3, a block diagram of a video game system is shown. A data server82is coupled to a network85. The network may be, for example, what is commonly referred to as the internet, or, alternatively, the network85may be another type of network, such as a local area network (LAN). The data server82stores information for use in video games. Advantageously, new statistical results or parameters can be stored on the data server82. For example, when a real professional athlete changes a performance rating, the changed performance rating can be stored on the data server82. For example, when a professional baseball player changes his batting average, the changed batting average can be stored on the data server82. Or, as a second example, if a professional American football quarterback changes his completion percentage the changed completion percentage can be stored on the data server82. This allows a video game player to play a video game with the new statistics. The changed statistic may be stored as the actual number that the statistic represents. For example, if a batting average goes from 0.275 to 0.278, then the number 0.278 may be stored on the data server. Or the new statistic may be stored on the data server as a parameter of a video game. The parameter can then be used to effect how the video game character interacts with the video game environment.

Referring again toFIG. 3, the user (not shown) plays the video game by entering inputs through a user interface87. The user interface87may be, for example, a video game controller (not shown). The user interface87is coupled to a video game machine90, which may be a video game machine20, as shown with reference toFIG. 2. The video game machine90, is coupled to a RAM95and a local memory99, preferably a read only memory (ROM). The RAM95is used for storing data and rules (described later with reference toFIG. 4) from the game medium103. Advantageously, the parameter is also stored on the RAM. Thus, the video game is played with the changed statistic. Advantageously, a video game character, such as, for example, an American football quarterback, will play more realistically based on the video game character's real life performance, such as, for example, a completion percentage.

The video game machine is coupled to a modem107for coupling to the network85. The parameter is downloaded by the video game machine90from the data server82by means of the modem107and the network85. As will be understood by those of skill in the art, the modem107may be incorporated as part of the video game machine90, or a separate component.

FIG. 4is a block diagram of a game medium, preferably a ROM109. The game medium may be, for example, a compact disc (CD), a digital video disc (DVD), or a cartridge. The ROM109includes many rules and parameters for the video game. Rules111are stored on the ROM109. The rules111are shown as Rule1, Rule2, Rule3, etc. The rules govern how the game is played and displayed on the user interface. Advantageously, the rules can be updated to match the rules of the real world.

There are also other parameters stored on the ROM109. For example, stadium parameters113may be stored. For example, the game may display Wrigley Field for play by the Chicago Cubs and Fenway Park for play by the Boston Red Socks. For example, the ivy on the homerun wall of Wrigley Field is green and flourishing during certain parts of the year, such as from May to July. During April, August and September, the ivy is browner. The color of the ivy shown in a baseball video game showing Wrigley Field can change based on the time of the year that the video game is played.

As another example of how realism can be increased, new memorials to great players can be implemented in the video game stadiums. For example, in 2002, Ted Williams' number, “9”, was displayed in the leftfield grass of Fenway Park after the start of the season. Baseball video games were already produced. So the video game fields did not have the number on the field, failing to duplicate real life. Now, the field can be changed to match real life after the game is produced, sold and played in the user's home.

Referring again toFIG. 4, referees115may be stored. Referees' appearances and performance may be stored. For example, some referees in basketball call technical fouls frequently. Some referees rarely call technical fouls. Parameters can be stored regarding the individual referees that simulate these real life differences.

Team statistics and other parameters can also be stored, such as, for example, the city, owners, trainers, coaches, players, etc. For example, Mike Bibby of the Sacramento Kings, during the 2001-2002 regular season averaged 13.7 points and 12.3 shots attempted per game. In the playoffs of the same season, he averaged 20.2 points and 16.1 shot attempted per game. These improved playoff statistics can now be downloaded. A video game player can play a basketball video game with a Mike Bibby character incorporating the better performing real world Mike Bibby.

As another example, the 2000-2001 Chicago Bears' opponents scored an average of 22.2 points per game with an average of 114.2 rushing yards per game. The 2001-2002 Chicago Bears' opponents scored an average of 12.7 points per game with an average of 82.1 rushing yards per game. This change was not reflected in video games played during the 2001-2002 season. At that time, the newest video games reflected the statistics from the 2000-2001 season. Thus, the Chicago Bears on the video games played poorly, whereas the Chicago Bears on the real football field played very well. This dichotomy between video game and real life is frustrating to many video game players.

FIG. 5is a block diagram of the players stored in ROM. Player1, Player2, Player3and several other players are shown. Under each player, several statistics are shown. For example, if the video game is basketball, Statistic1may be a player's field goal percentage. Statistic2may be a free throw percentage. Statistic3may be blocks per game. One skilled in the art will appreciate that the number and type of statistics stored will vary with the game and with the way the video game designer chooses to design the game.

FIG. 6is a block diagram of a RAM135used to store game parameters for play of a video game. RAM135may be used to store game parameters as are RAM58(FIG. 2) and RAM95(FIG. 3) Preferably, items are loaded from109(FIG. 7) into RAM135. Preferably, all of the rules111(FIG. 4) are loaded into RAM at138. However, only one stadium is loaded from ROM to RAM. Also, only two teams, shown as Team1and Team2are loaded. As discussed with reference toFIGS. 1-3, above, a new parameter is downloaded from the server and stored in RAM135. Preferably, the new parameter is stored in RAM in addition to the parameter as loaded from ROM.

Referring now toFIG. 7, a flowchart is shown. In step221, the method starts. In step224, it is determined whether autoupdate is enabled. If autoupdate is enabled, the method continues by going toFIG. 8, as shown at step227. If autoupdate is not enabled, the main menu is displayed at step230. In step232, a user chooses to start a game or request an update.

In step234, it is determined whether the user requested an update. In step236, the method continues by going toFIG. 9, if the user did not choose to update the video game. If the user did choose to update the video game, the method continues by going toFIG. 8, at step238.

Referring now toFIG. 8, in step241, the CPU initializes the modem. In step243, the modem establishes a network connection. Next, in step245, the CPU sends a request for data to the data server. At247and249, the data server sends the requested data to the CPU. Advantageously, the requested data may be updated, or changed, statistics for playing a more realistic video game. For example, as mentioned above, the user may be requesting updated batting averages for game characters in a profession baseball video game. Or, to continue the example from above, the video game player may be requesting a newly established completion percentage for an American football quarterback. Preferably, the request is for all the new statistics resulting from a real game that has already been played, or from a plurality of games.

Referring again toFIG. 8, at step250, the CPU receives the requested data and stores it in local memory254. In step251, the CPU disconnects the modem from the network. Next, at step253, the user is prompted that the data transfer is complete. The main menu is displayed at step255, and the method continues toFIG. 9for play of the game.

InFIG. 9, a flowchart is shown for the play of the video game. At step265, the game starts. Next, at step270, the CPU loads the game engine275from the game medium280into RAM285. Next, at step290, the CPU loads the requested data from local memory300into RAM285. The requested data295is preferably the changed statistics requested by the user and stored in local memory as shown inFIG. 8. This way, updated statistics, such as new player performance parameters resulting from current, real professional games can be used to play a more realistic video game, as shown at step305.

FIG. 10is a block diagram showing a portion of a flow diagram for authenticating a user of a video game. At step334, a CPU initializes a modem. The modem connects to a network at step337. The game machine displays a login/sign-up screen at step340. The user selects either to sign up or login in at step342. If the user selects to login, the next step depends upon whether an authentication code (AC) is required, as shown at step344. If no AC is required, the CPU sends the login data to the server at step346. The flow then continues atFIG. 11.

Alternatively, an AC may be required by the network, as shown at step348. This allows the network to verify that the user has a proper authentication code. For example, the authentication code may be provided at sign-up (described with respect toFIG. 12) by the network to the user. This way, the network administrator can verify that the user is a paying user. As another example, a new authentication code may be provided on a periodic basis, such as, for example, monthly. Thus, if a user is paying on a monthly basis, correct authentication is only available if the user's dues are current. As yet another example, the AC may be associated with a specific game machine by either the network or the CPU. This allows for security for preventing portability of AC's from one game machine to another.

Referring again toFIG. 10, if authentication is required, it depends whether the AC is auto-sent or not, as shown at step351. If the AC is auto-sent, the process continues at step346. If the AC is not auto-sent, the user enters a user verification code, at step354. At step357, the CPU compares the user verification code to a game machine authentication code. If the user verification code matches the game machine authentication code, at step360, the process continues at step346. As stated in step346, the login data363is stored at a network server366. Next, the process continues atFIG. 11.

FIG. 11shows a portion of a process for authenticating a video game user, continued fromFIG. 10. At step369, the server attempts to authenticate the login data and any AC present. The AC may include a user verification code, to verify that the user is authorized to receive updated game parameters. Also, the AC may include a code identifying a specific game machine. This identifying code may, for example, be a serial number from the game machine. Alternatively, the identifying code may be a code assigned by the network administrator to the game machine at sign-up (described with respect toFIG. 12). Further, the network administrator may verify that the identifying code, the verification code, and the user login data all match. The verification code may be a password.

At step372, the network checks whether the login data and any AC is authenticated. If the login data and any AC are authenticated, at step376, the server sends a menu of available data to the game machine. Then, at step384, the CPU displays the menu to the user and continues toFIG. 13. If the login data and any AC are not authenticated at step372, the server sends a failure message to the CPU, at step380. The CPU displays the failure message to the user, at step388. Preferably, the CPU next displays the login/sign-up screen to the user again. The process returns to the beginning ofFIG. 10, at step334.

FIG. 12is a flow diagram showing a process for signing up a new user of a video game with downloadable statistics. In step390, the CPU displays, a sign-up screen. In step393, the user enters the user's name and chosen password, and possibly other identifying information, such as a birthdate, address, etc. In step396, the process depends upon whether the AC is autosent. If the AC is autosent, the CPU sends the sign-up data404to the server408in step400. In step412, the server sends account options416to the game machine.

In step420, the CPU displays the account options to the user. In step424, the user selects what type of account the user chooses. In step428, the CPU sends the users choice of account type to the server408. For example, the user may choose to pay for downloads of new game parameters on a monthly basis. As another example, the user may choose to pay for downloads of new game parameters for an entire sports season. Or, as yet another example, the user may choose to pay for downloads of new game parameters on a pay per use basis. Other business models will be apparent to those of skill in the art.

In step432, the server verifies the information, creates an account and sends a menu of game data to the game machine. In step436, the CPU displays the menu to the user. Next, the process continues as shown inFIG. 13.

Alternatively, if in step396, the AC is not autosent, the user enters an AC, in step440. In step444, the CPU compares the user input AC with the game machine authentication code. In step446, the CPU determines whether the user input AC matches the game machine AC. If not, the process continues at step448and the CPU displays an error message to the user. If the user input AC matches the game machine AC, the process continues at step400.

FIG. 13is a flow diagram showing a download process of a new game parameter. In step450, the user selects a set of desired game parameters. For example, the desired parameters may comprise a complete set of new parameters for all teams in the game. As another example, the desired parameters may comprise the results of a single sports game for a single team. In step453, the CPU sends the request to the server.

In step456, the process depends on whether the game machine requires an authentication code. In step459, the server sends the requested parameters to the CPU In step459, the server sends the requested parameters to the CPU if the game machine does not require an authentication code. In step462, the CPU stores the new game parameters in local memory465.

Alternatively, if in step456, the game machine requires an AC, the process continues to step468. In step468, the server attaches account information and the AC to the parameter. In step471, the server sends the parameter to the CPU. In step474, the CPU compares the AC with the game machine AC. In step476, the game machine determines whether the AC sent by the server matches the AC stored on the game machine. If there is no match, the CPU displays an error message. If there is a match, the CPU stores the data at step479in local memory465. The data, or new game parameters, can then be used for play in a game with quantifiably increased realism.

FIG. 14is a flow diagram showing game play in a case in which an AC is required. In step490, the CPU displays a game menu. In step495, the user selects to load saved data500, which has been stored in local memory505. In step510, the CPU reads data from local memory. In step515, the CPU compares an AC associated with the data to the game machine AC. In step520, the process determines whether the AC associated with the data is the same as the game machine AC. If they don't match, the CPU displays an error message in step535. If they match, the CPU loads the parameter data into RAM525in step530. Then, the new game parameters are used for play in a game with quantifiably increased realism.