Game Device

Abstract

Game data that can be conveniently used by a game program is provided: a save API processing module is configured as an application processor calls a save data utility function for data saving; a status acquisition unit acquires status information indicating the status of environment for executing the game program; an appending unit appends the status information thus acquired to the game data acquired by a game data acquisition unit as additional information and stores the resultant data in a hard disk; an additional information acquisition unit in a load API processing module acquires the additional information from the saved data; a determination unit determines whether the current status information matches the additional information; and the result of determination is communicated by a notification unit to the application processor.

Description

TECHNICAL FIELD

The present invention relates to game devices for executing a game application and, more particularly, to a game device provided with the function of saving and/or loading game data.

BACKGROUND ART

By storing (saving) the status of progress of game play in a storage device, the user can continue the game play from where the user left off previously, using the game data stored in the storage device. Saved data is stored in, for example, a directory associated with a game application. The game device loads saved data into an internal memory from the directory associated with the game application to be executed.

Rearing simulation games are known to enable users to enjoy letting a character to grow over time. When the saved data for a grown character is duplicated for a user other than the user that originated the data, the duplicating user would be able to acquire high-level character data effortlessly, spoiling the meaning of the game. The same thing is true of other types of games. If it is easy to duplicate saved data, users will be less willing to advance the game by the user's own ability. This may ultimately detract from the value of the game application.

DISCLOSURE OF THE INVENTION

Problem to be Solved by the Invention

In view of this situation, it is favorable for the game device to provide a game application with an environment in which some counter measures can be implemented as needed. The degree of desire for duplicating high-level saved data created by others varies from one game application to another. Therefore, it is desirable that whether to use the environment provided by the game device be defined for each game application.

In this background, the general purpose of the present invention is to provide a technology related to saved data that allows a game program to carry out a desired process and to provide a technology for processing such saved data.

Means to Solve the Problem

A game device according to at least one embodiment of the present invention comprises: an application processor operative to execute a game program; a save processor operative to save game data related to the progress of game in a storage device; a load processor operative to load saved data from the storage device; and a status acquisition unit operative to acquire status information indicating the status of environment for executing the game program. The save processor comprises: an appending unit operative to append the status information acquired by the status acquisition unit to the game data as additional information, and the load processor comprises: an additional information acquisition unit operative to acquire the additional information from the game data stored in the storage device; a determination unit operative to determine whether the status information acquired by the status acquisition unit matches the associated additional information acquired by the additional information acquisition unit; and a notification unit operative to communicate a result of determination to the application processor.

Optional combinations of the aforementioned constituting elements, and implementations of the invention in the form of methods, apparatuses, systems, recording media and computer programs may also be practiced as additional modes of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a game system according to an embodiment of the present invention;

FIG. 2 is a functional block diagram of the game device;

FIG. 3 shows the hierarchy of the OS;

FIG. 4 shows the internal structure of the main controller;

FIG. 5 shows functional blocks of the API processing module configured in the OS execution unit; and

FIG. 6 is a sequence chart for list-based selective loading.

DESCRIPTION OF THE REFERENCE NUMERALS

1. . . game system, 10 . . . game device, 12 . . . output device, 20 . . . power button, 22 . . . LED, 24 . . . system controller, 30 . . . device controller, 32 . . . media drive, 34 . . . hard disk drive, 36 . . . switch, 38 . . . air interface, 40 . . . game controller, 50 . . . media, 100 . . . main controller, 102 . . . main memory, 104 . . . input acknowledging unit, 120 . . . execution unit, 122 . . . OS execution unit, 124 . . . application processor, 140 . . . flash memory, 142 . . . device ID storage, 144 . . . user ID storage, 160 . . . memory controller, 162 . . . local memory, 200 . . . output processor, 300a . . . save API processing module, 300b . . . load API processing module, 302 . . . status acquisition unit, 310 . . . status acquisition unit, 320 save processor, 322 . . . game data acquisition unit, 324 . . . appending unit, 330 . . . status acquisition unit, 340 . . . load processor, 342 . . . additional information acquisition unit, 344 . . . determination unit, 346 . . . notification unit, 350 . . . load execution unit

BEST MODE FOR CARRYING OUT THE INVENTION

FIG. 1 shows a game system according to an embodiment of the present invention. The game system 1 comprises a game device 10 for running a game application and an output device 12 for outputting a result of processing in the game device 10.

The game device 10 is an information processing apparatus for processing a game application and generating an image signal and an audio signal indicating the result of processing the game application. The game device 10 is connected to at least one output device 12 so as to display an image on the output device 12 or output sound. The output device 12 may be a television set provided with a display unit for outputting images and further with an audio output unit for producing an audio output. The output device 12 may be connected to the game device 10 by a cable or wirelessly connected to the device 10 via a wireless local area network (LAN).

FIG. 2 is a functional block diagram of the game device 10. The game device 10 is provided with a power button 20, an LED 22, a system controller 24, a device controller 30, a media drive 32, a hard disk drive 34, a switch 36, an air interface 38, a main controller 100, a main memory 102, and an output processor 200. The game device 10 holds identification information identifying itself (hereinafter, referred to as “device ID”) in a flash memory.

The power button 20 represents an input unit accepting the user input and is used to turn on or off the game device 10. The power button 20 may be a push button pressed to turn on or off the power. Alternatively, the power button 20 may have other structures with which the user is capable of turning on or off the power. For example, the button 20 may be a touch sensor. The LED 22 indicates whether the power is turned on or off. The system controller 24 detects whether the power button 20 is pressed or not. Upon detecting a transition from the power-off state to the pressed state, the controller 24 starts the main controller 100 to start a boot sequence of the operating system and controls the LED 22 to be lighted. When a power cable is connected to the game device 10, the system controller 24 maintains the standby mode even in the power-off state and monitors whether the power button 20 is pressed.

Like a south bridge, the device controller 30 is configured as a large-scale integrated circuit executing delivery of information between devices. As shown, the device controller 30 is connected to devices such as the system controller 24, the media drive 32, the hard disk drive 34, the switch 36, and the main controller 100. The device controller 30 cancels differences in electrical characteristics or in data transfer rates of the devices and controls the timing of data transfer.

The media drive 32 is a drive device that drives a media 50 storing a game program and reads the game program from the media 50. The media 50 is a recording media such as an optical disk, magnetooptical disk, or blue ray disk and is used as a media for supplying a game program by being inserted in the media drive 32. The media 50 stores identification information identifying the media 50 (hereinafter, referred to as “media ID”) in a predetermined storage area. A media ID is a number unique to the media and is different from media to media. A media ID may be assigned to all of the recording media capable of storing a game program. For example, a media ID may be assigned to a built-in recording media such a a hard disk and a flash memory 140. For the purpose of description, the media ID assigned to the media 50 will be described by way of example.

A game program contains an execution program that executes a game application and information identifying a game application (hereinafter, referred to as “application ID”). The execution program is a program necessary for processing applications. By running the execution program, a game application can proceed as programmed. The application ID is set up for each of different types of game applications and recorded in a predetermined storage area in the media 50.

The hard disk drive 34 is a drive device for driving an internal hard disk and writing and reading data accordingly. Game data related to the progress of game is stored (saved) in the internal hard disk of the game device 10. For example, the game data includes data indicating the status of progress of game play, highest score of the game, and character data. Not all of these types of data need be saved in the hard disk. Game data that requires saving is defined for each game application.

The switch 36 is an Ethernet (trademark) switch and is a device for transmitting and receiving information by establishing cable of wireless connection with an external device. The game device 10 can be connected to a network such as the Internet via the switch 36. In this embodiment, a delivery server is provided in an external network. For example, the game device 10 can download applications from the server. In this process, the user needs to register himself or herself in the server. Information identifying the user (hereinafter, referred to as “user ID”) is set up. The user ID thus set up is necessary to benefit from the delivery service and is also used as information uniquely identifying the user in the game device 10. Therefore, the game device 10 stores the user ID communicated from the delivery server in a flash memory. Users not registering themselves in the server are not assigned user IDs.

The switch 36 is connected to the air interface 38. The air interface 38 connects the device to the game controller 40, which is provided with the function for communicating wirelessly according to a communication protocol such as Bluetooth (trademark) or IEEE802.11. The game controller 40 functions as an input interface through which a user input for control is provided.

The main controller 100 is provided with a multicore CPU, a single CPU including a single general-purpose processor core and a plurality of simple processor cores. In this embodiment, the general-purpose processor core is referred to as power processing unit (PPU) and the remaining processor cores are referred to as synergistic-processing units.

The main controller 100 provides functions and environments that facilitate efficient usage of the game device 10 and executes an operating system for controlling the entirety of the game device (hereinafter, simply referred to as OS). A plurality of game applications can be run on the OS. The OS of the game device 10 according to the embodiment is implemented in three levels including the user level, kernel level, and hypervisor level, from top to bottom. The software for the user level, kernel level, and hypervisor level is integrated in the game device 10 so as to function as the “OS” of the game device 10. The software that manages the hypervisor level is referred to as “privileged software”. The hypervisor level is responsible for the functions of the bottom level. When the power of the device is turned on by using the power button 20, the hypervisor level is started by the privileged software in preference to the other levels.

FIG. 3 shows the hierarchy of the OS. When the power of the device is turned on by using the power button 20, the system controller 24 supplies power to devices including the main controller 100 and the output processor 200 via the device controller 30. When the main controller 100 is powered, the PPU first reads the privileged software by running a boot loader of the OS, whereupon the privileged software starts the hypervisor level of the host OS. Subsequently, the PPU starts the kernel level of the OS and then the user level so as to ready the device to accept the game program supplied from the media 50.

The game device 10 according to the embodiment may be provided with a plurality of OS's. In that case, the OS shown in FIG. 3 functions as a host OS so that a guest OS is run on a virtual machine created on the hypervisor level of the host OS. For the purpose of management by the main controller 100, the hypervisor level of the host OS should be running without interruption in order to run the guest OS, because the virtual machine environment and the guest OS are programs run on the host OS. Activation of the host OS is normally executed by the PPU but may be executed in coordination with the SPU alternatively.

The kernel level manages the resources of the system to make the resources available for other programs for operation. More specifically, the kernel level manages communication between the hardware, including the memory, CPU, and other devices, with software higher in the hierarchy, and represents the core of the OS.

The user level serves as an interface with the kernel level so that the application program can be run efficiently. The user level may be implemented by a plurality of function modules, which include an API processing module implementing the function of application programming interface (API) provided to the game program. An API is an interface for programming and generates rules for creating a program. In this embodiment, a save program for saving game data and a load program for loading saved data (hereinafter, referred to as “save data utility”) are prepared as libraries. By calling a save data utility function, an API processing module is configured. By configuring an API processing module for saving or loading, the game program is capable of saving game data in a hard disk and loading saved data from the hard disk. The game device 10 according to the embodiment is provided with a plurality of types of saving and loading functions. A save data utility function adapted for the process to be executed is prepared for the hard disk.

A summary of a plurality of types of saving and loading processes performed in the game device 10 will now be given. A save data utility function is prepared for each of saving and loading processes described hereinafter. By calling a save data utility function requested by the game program, an API processing module is configured in the user level of the OS. This makes it possible to execute a saving process or a loading process desired by the game program.

(1) List-Based Selective Saving/Loading

In list-based selective saving (ListSave( )), a list of existent saved data is presented to the user to prompt the user to overwrite one of the saved data items or create saved data. In list-based selective loading (ListLoad( )), a list of existent saved data is presented to the user so that the user loads the selected saved data.

(2) Fixed Saving/Loading

In fixed saving (FixedSave( )), one of the saved data items designated by the application is presented to the user so that the saved data presented is overwritten. In fixed loading (FixedLoad( )), one of the saved data designated by the application is presented to the user so that the saved data presented is loaded.

(3) Autosaving/Autoloading

In autosaving (AutoSave( )), one of the saved data items is designated by the application so that the saved data designated is overwritten without presenting it to the user. In autoloading (AutoLoad( )), one of the saved data items is designated by the application so that the saved data designated is loaded without presenting it to the user.

The main controller 100 is provided with a memory controller connected to the main memory 102. The PPU is provided with a register and a main processor for executing operations. The main processor efficiently allocates to the SPUs tasks that are basic units of processing in an application. The PPU may execute tasks on its own. The SPU is provided with a register, a subprocessor for executing operations, and a local memory (dedicated RAM) embodying a local storage area. The SPU is provided with a dedicated direct memory access (DMA) controller as a control unit. By transferring data between the main memory 102 and the local memory, data can be subject to high-speed stream processing and can be transferred at a high speed between a frame memory built in the output processor 200 and the local memory.

The output processor 200 is connected to the output device 12 and outputs a video signal and an audio signal produced as a result of processing the application. The output processor 200 is provided with a graphics processing unit (GPU) implementing image processing functions. High definition multimedia interface (HDMI) is employed in the GPU so that a video signal can be digitally output.

FIG. 4 shows the internal structure of the main controller 100. The main controller 100 is provided with an input acknowledging unit 104, an execution unit 120, a flash memory 140, a memory controller 160, and a local memory 162.

Referring to FIG. 4, the elements illustrated as functional blocks for performing processes are implemented in hardware by a CPU, a memory, or other LSI's, and in software by a program or the like loaded into the memory. As mentioned before, one PPU and a plurality of SPUs are provided in the main controller 100 so that the PPU and the SPUs may form functional blocks either alone or in combination. Therefore, it will be obvious to those skilled in the art that the functional blocks may be implemented in a variety of manners by hardware only, software only, or a combination of thereof.

The main controller 100 is provided with an input acknowledging unit 104 as a means for transmitting and receiving control information between the controller 100 and the device controller 30. The input acknowledging unit 104 acknowledges a user input for control from the game controller 40 and acknowledges, from the delivery server on the network, a user ID set up when a user registers himself or herself. The user of the game system 1 is capable of playing the game by providing an input for control of the game by using the game controller 40. The user is also capable of providing a control input requesting saving or loading of game data by using a graphical user interface displayed on the screen of the output device 12 using, for example, the API of the OS. In this embodiment, the user at least provides a control input requesting saving or loading of data. The input acknowledging unit 104 acknowledges the instruction and notifies the execution unit 120 accordingly. When a saving process or a loading process is started, the user provides an input for confirmation or selection using the GUI presented by the execution unit 120.

The flash memory is provided with a device ID storage 142 and a user ID storage 144. The device ID storage 142 holds a device ID as information to identify the game device 10. The user ID storage 144 holds the user ID acknowledged by the input acknowledging unit 104. As already described, the user ID is assigned when the user is registered in the delivery server. Absent user registration, the user ID storage 144 is left blank.

In the game device 10 of the embodiment, information such as the device ID set up for the game device 10 or the user ID assigned may be stored in a register of a hard disk instead of the flash memory. For convenience, FIG. 4 illustrates the device ID storage 142 and the user ID storage 144 as using areas of the flash memory 140. Alternatively, the device ID storage 142 or the user ID storage 144 may use an area of another recording device such as a hard disk.

The execution unit 120 is provided with an OS execution unit 122 for executing the OS and an application processor 124 for executing an application. When the device is powered on, the OS execution unit 122 starts the hypervisor layer of the OS in preference to the other layers, followed by starting of the kernel layer and a necessary user layer. As a result, an environment is provided whereby the application processor 124 is capable of executing an execution program of the game.

The memory controller 160 controls write/read operations in the external main memory 102 or in the local memory 162 built in the SPU. The memory controller 160 stores data read from a hard disk or a media 50 in the main memory 102 or the local memory 162. The execution unit 120 executes a process using the data stored in the main memory 102 and/or the local memory 162.

In saving or loading game data, the application processor 124 prompts the OS execution unit 122 to call a save data utility function for performing a desired type of saving process or loading process. When the OS execution unit 122 receives the call request, an API processing module is started in the user layer of the OS.

In this embodiment, the API processing module for a save operation has the function of appending, to the game data, status information indicating the environment of execution of the game program and saving the resultant data in a hard disk. The API processing module for a loading operation has the function of loading saved data from a hard disk such that the saved data is verified by referring to the information appended to the saved data and the status information indicating the environment of execution of the game program occurring when the program is loaded.

FIG. 5 shows functional blocks of the API processing module configured in the OS execution unit 122. A save API processing module 300a is configured as the application processor 124 calls a save data utility function for data saving. The save API processing module 300a is provided with a status acquisition unit 310 and a save processor 320. The save processor 320 is provided with a game data acquisition unit 322 and an appending unit 324.

The status acquisition unit 310 acquires the status information indicating the status of environment for executing the game program. Elements indicating the status of execution environment include the game device in which the game application is run, the media 50 in which the game program is supplied to the game device 10, the type of game program, and the user playing the game. In association with these elements, the status acquisition unit 310 acquires the device ID identifying the game device 10, the media ID identifying the media 50, the application ID identifying the application (game type) of the game program, and the user ID identifying the user.

The status acquisition unit 310 reads and acquires the device ID from the device ID storage 142, the media ID and the application ID from the media 50, and the user ID from the user ID storage 144. If the media ID and the application ID are already read into an internal memory such as the main memory 102 or the local memory 162, the IDs may be acquired from the internal memory. When the IDs are already read into a hard disk, the IDs may be acquired from the hard disk. Preferably, the status acquisition unit 310 acquires two or more items of status information. More preferably, the unit 310 acquires all of the information items. The larger the number of items of status information acquired, the larger the number of items of status information available to the game program. In other words, the game program can select necessary status information depending on the situation so as to perform a desired process adapted to the selected status information.

The save processor 320 has the function of saving game data related to the progress of the game in a hard disk. The game data acquisition unit 322 acquires game data to be saved, such as the result of processing the application, from the application processor 124. The appending unit 324 appends the status information acquired by the status information acquisition unit 310 to the game data acquired by the game data acquisition unit 322 as additional information and stores the resultant data in a hard disk. As a result, the saved data is stored as game data with additional information.

By thus appending status information to the game data to be saved, it is ensured that the game data includes the environmental status occurring when the data is saved. As a result, the game device 10 can learn the environment occurring at the time of saving the game data, by referring to the additional information included in the saved data.

By appending the device ID as status information, the game device 10 is capable of determining whether the game data was saved by the game device 10 or another game device by referring to the device ID appended.

By appending the media ID as status information, the game device 10 is capable of determining whether the saved data was produced in the same media as the currently loaded media or in another media, by referring to the media ID appended.

By appending the application ID as status information, the game device ID is capable of determining whether the saved data was produced in the same application as the currently run application or in another application, by referring to the application ID appended.

By appending the user ID as status information, the game device 10 is capable of determining whether the saved data was saved by the current user or by another user, by referring to the user ID appended.

A load API processing module 300b is configured as the application processor 124 calls a save data utility function for data loading. The load API processing module 300b is provided with a status acquisition unit 330, a load processor 340, and a load execution unit 350. The load processor 340 is provided with an additional information acquisition unit 342, a determination unit 344, and a notification unit 346.

Like the status acquisition unit 310, the status acquisition unit 330 acquires the status information indicating the status of environment for executing the game program. Preferably, the status acquisition unit 330 acquires at least two of the device ID, the media ID, the application ID, and the user ID as status information. The status acquisition units 310 and 330 are configured as the same program module and acquire the same type of status information.

The load processor 340 has the function of loading the saved data from a hard disk. Before loading game data, the additional information acquisition unit 342 acquires the additional information from the game data recorded in a hard disk. The determination unit 344 determines whether the pre-load status information acquired by the status information acquisition unit 330 matches the additional information acquired by the additional information acquisition unit 342. In principle, determination is made as to whether there is a complete match. The notification unit 346 communicates the result of determination by the determination unit 344 to the application processor 124.

The determination unit 344 processes a plurality of types of status information occurring at the time of loading and a plurality of types of additional information in the game data to determine whether a match exists, and produces the respective results of determination. For example, in case the status acquisition units 310 and 330 acquire the device ID, the media ID, the application ID, and the user ID, the determination unit 344 subjects the device ID, the media ID, the application ID, and the user ID to determination for a match. The notification unit 346 communicates the respective results of determination to the application processor 124. This allows the load API processing module 300b to provide the application processor 124 with detailed information related to the environmental status. Since the application processor 124 is capable of learning whether each aspect of the environmental status varies, the unit 124 is capable of running the application in adaptation to individual changes in the environment. Since the saved data is subject to verification by referring to a plurality of items of status information, reliability of the verification process is improved and the chances of providing useful information to various game programs are increased.

The determination unit 344 yields a determination of error when the status information occurring at the time of loading and the additional information in the saved data do not match. The notification unit 346 communicates the error information to the application processor 124. For example, the result of determination may be represented by a flag such that a match between the status information occurring at the time of loading and the additional information in the saved data is indicated by a flag value “0”, and a difference is indicated by a flag value “1”. If a mismatch is found, the result of determination is simply communicated to the application processor 124 as error information (i.e., a flag value “1”), facilitating the handling of the determination result from the determination unit 344 by the application processor 124.

FIG. 6 is a sequence chart for list-based selective loading. The application processor 124 sends a request to call the ListLoad( ) function to the OS execution unit 122 (S10). Designated as arguments are, for example, a prefix of the directory name storing the saved data to be acquired, and a pointer to the callback function (data list callback, data status callback, and file operation callback). The OS execution unit 122 calls the ListLoad( ) function (S12) so as to configure the load API processing module 300b. The load API processing module 300b acquires a list of saved data from a hard disk by referring to the prefix of the directory name (S14).

The load API processing module 300b calls a data list callback by using the list of saved data as an argument (S16). In data list callback, a saved data list to be presented to the user is produced by referring to the list of saved data thus delivered (S18). When control is returned from data list callback and the list to be presented to the user is delivered to the load API processing module 300b (S20), the load API processing module 300b displays the list of saved data on the screen using the GUI (S22) and awaits a user response. When the user selects saved data to be loaded (S24), the selection is communicated to the load API processing module 300b (S26) so that the load API processing module 300b displays a confirmation dialog on the screen using the GUI (S28). When the user confirms the selection (S30), the saved data is verified (S32). In this verification, the status information occurring at the time of saving and the current (load time) status information are compared to determine whether a match exists, as described with reference to FIG. 5.

The load API processing module 300b calls a data status callback (S34). Information delivered to data status callback includes the result of verification of the saved data, the directory name of the selected saved data, and the update date and time.

The application processor 124 determines whether to execute a loading process by referring to the result of verification of the saved data (S38). For example, if error information is communicated relative to the device ID, it is learned that the saved data was produced in a device different from the game device 10. In this case, there is a likelihood that the game is about to be executed using the data saved by another user so that the application processor 124 may terminate the loading process (S38).

Meanwhile, when error information is not communicated for any of the aspects of the status information, the application processor 124 determines to execute the loading process (Y in S38). Control is returned from data status callback so that a file operation pre-process is designated (S40). The load API processing module 300b performs a file operation pre-process (S42) and calls a file operation callback for each of the files forming the saved data (S44). Information delivered to file operation callback includes control information identifying a read operation. The application processor 124 designates files to be read (S48) until all of the files in the saved data are loaded (N in S46). The load execution unit 350 loads data from a hard disk (S50). When all of the files are loaded (Y in S46), the application processor 124 directs the load API processing module 300b to terminate the loading process (S52). The load API processing module 300b displays a message indicating completion on the screen, thereby terminating the loading process.

In the above-described example, the application processor 124 is assumed to determine whether to execute a loading process by referring to the result of verification of the saved data in S32. The application processor 124 is capable of behaving in a variety of manners depending on the type of error information.

A) In the Event that the Error Information Indicates that the Device ID is in Error

The application processor 124 may terminate the loading process as described above. This will make it difficult for other people to use one's saved data and also make duplication of the saved data by other people difficult. This is particularly useful if the saved data is frequently posted on the Internet. Namely, by prohibiting the usage and duplication of saved data when the device ID thereof is not as expected, posting of saved data on the network is rendered meaningless. The game device 10 may be allowed to use saved data created in a different game device as a guest user.

B) In the Event that the Error Information Indicates that the Media ID is in Error

The application processor 124 terminates the loading process. This will make it difficult for other people to use one's saved data and also make duplication of the saved data by other people difficult. This is particularly useful if the saved data is frequently posted on the Internet. Namely, by prohibiting the usage and duplication of saved data when the media ID thereof is not as expected, posting of saved data on the network is rendered meaningless. The game device 10 may be allowed to use saved data created in a different game device as a guest user.

C) In the Event that the Error Information Indicates that the Application ID is in Error

For example, game data of an old version in a game application series may be used in a new version of the game such that the game device 10 may grant privilege to the game data for the purpose of promotion.

D) In the Event that the Error Information Indicates that the User ID is in Error

Absence of a user ID will generate error information because no comparison can be made in determining a match. The error information will also allow the game device 10 to determine that the user is not registered in the delivery server. In the case of a game that requires a user ID, the application processor 124 may restrict the use of the saved data.

In the event that the user ID is not as expected, the game device 10 can learn that the saved data was saved by a different user and can identify the user that performed the saving operation. The user ID itself, instead of a flag, may be communicated to the application processor 124.

As described, by making a plurality of items of environmental status information available to the application processor 124, the processor 124 can perform a variety of processes responsive to each result of determination of a match of status information. This can enhance the level of protection of the game program. By granting privilege in association with the game progress, the appeal of the game program is enhanced.

Described above is an explanation based on an exemplary embodiment. The embodiment is intended to be illustrative only and it will be obvious to those skilled in the art that various modifications to constituting elements and processes could be developed and that such modifications are also within the scope of the present invention.

INDUSTRIAL APPLICABILITY

The information processing technology of the present invention is applicable to the field of games.

Claims

1. A game device comprising:

an application processor operative to execute a game program;

a save processor operative to save game data related to the progress of game in a storage device;

a load processor operative to load saved data from the storage device; and

a status acquisition unit operative to acquire status information indicating the status of environment for executing the game program, wherein

the save processor comprises:

an appending unit operative to append the status information acquired by the status acquisition unit to the game data as additional information and store the resultant information in the storage device, and

the load processor comprises:

an additional information acquisition unit operative to acquire the additional information from the game data stored in the storage device;

a determination unit operative to determine whether the status information acquired by the status acquisition unit matches the associated additional information acquired by the additional information acquisition unit; and

a notification unit operative to communicate a result of determination to the application processor.

2. The game device according to claim 1, wherein

the status acquisition unit acquires a plurality of items of status information and the appending unit appends the plurality of items of status information to the game data as additional information, the determination unit determines whether the plurality of items of status information acquired by the status acquisition unit respectively match the associated additional information acquired by the additional information acquisition unit, and the notification unit communicates the respective results of determination to the application processor.

3. The game device according to claim 2, wherein

the status acquisition unit acquires as status information at least two of information identifying the game device, information identifying a media in which the game program is supplied, application information on the game program, and information identifying a game user.

4. The game device according to claim 1, wherein

the determination unit yields a determination of error if the status information occurring at the time of loading and the additional information appended to the saved data do not match.

5. The game device according to claim 1, wherein

the application processor does not perform a loading process if a determination of error is yielded for a predetermined item of status information.

6. The game device according to claim 1, wherein

each of the save processor and the load processor is configured as an application programming interface processing module implementing the function of an application programming interface provided to the game program.

7. A computer program product comprising:

a module that executes a game program;

a module that saves game data related to the progress of game;

a module that load saved data from a storage device;

a module that acquires status information indicating the status of environment for executing the game program, wherein

the save module appends a plurality of items of status information acquired to the game data as additional information, and saves the resultant data in the storage device, and

the load module comprises:

a module that acquires the additional information from the game data stored in the storage device;

a module that determine whether the plurality of items of status information acquired respectively match the associated additional information acquired; and

a module that communicates a result of determination to the game application executing module.

8. A computer-readable recording media having embodied thereon the program product according to claim 7.