Control system, server, and control method

Abstract

In the present invention, before a game is provided, a state is established in which each of a server 2 and a user terminal 3 can use common node definition data ND corresponding to the game. A plurality of nodes indicating a state of the game are defined in the node definition data ND. While the game is being played by a user, the user terminal 3 transitions a node on the basis of the node definition data of the user terminal 3, changes the value of terminal-side setting information, and records, in log data as a log, the value of the changed terminal-side setting information and transition reproduction information capable of reproducing the transition of the node. Furthermore, the user terminal 3 transmits, to the server 2, transmission log data DL including the log. The server 2 reproduces the transition of the node on the basis of the transition reproduction information of the transmission log data and the node definition data ND of the server 2, changes the value of the server-side setting information in accordance with the transition of the node, and compares the value of the server-side setting information with the value of the terminal-side setting information recorded in the transmission log data.

Description

Control system, server and control method

[0001] The present invention relates to a control system that provides a game using a server and terminals, a control device, and a control method using the control system.

[0002] Conventionally, a control system is known in which a server and a terminal connected to the server via the Internet cooperate to provide a game to a user. In this type of game, cheating may occur by modifying the terminal's program or tampering with communications between the server and the terminal. For example, cheating may occur by fraudulently modifying game characters, items used in the game, points available in the game, or other game-related elements to give a user an advantage in the game. Regarding cheating, Patent Document 1 describes how cheating can be prevented by having the server execute all processing required to progress the game (see, in particular, paragraph 0004).

[0003] Japanese Patent Application Laid-Open No. 2019-154667

[0004] Control systems in which terminals and servers work together to provide a game are required to be highly resistant to fraudulent activity. As disclosed in Patent Literature 1, a control system can be effectively prevented from fraudulent activity by configuring the server to execute processes for progressing the game (including processes for generating screen information in accordance with the progress of the game), while the terminals only display screens based on the screen information. However, this configuration has the following problem. Specifically, this configuration results in frequent communication between the terminal and the server as the game progresses. This frequent communication can cause delays in the progress of the game, which can reduce user satisfaction. These problems exist.

[0005] The present invention has been made to solve such problems, and aims to suppress delays in the progress of a game and improve resistance to cheating.

[0006] To solve the above-mentioned problems, the present invention has the following configuration. Specifically, before a game is provided, a state is established in which both the server and the terminal can use common node definition data corresponding to the game. This node definition data defines multiple nodes indicating game states. While a user is playing the game, the terminal transitions the nodes based on the node definition data of the terminal, changes values ​​of terminal-side setting information corresponding to the node definition data of the terminal in response to the node transitions, and records transition reproduction information capable of reproducing the node transitions and values ​​of the terminal-side setting information changed in response to the node transitions in the log data as a log. When a log transmission condition for transmitting the log is met, the terminal transmits transmission log data including the log recorded in the log data to the server. Meanwhile, the server reproduces node transitions based on the transition reproduction information in the transmission log data received from the terminal and the node definition data of the server, changes values ​​of server-side setting information corresponding to the node definition data of the server in response to the node transitions, and performs a verification process in which the values ​​of the server-side setting information are compared with the values ​​of the corresponding terminal-side setting information recorded in the transmission log data.

[0007] The present invention configured as described above provides the following advantages. That is, when providing a game, a state is established in which the server and the terminal can use common node definition data. The terminal then transitions nodes based on its own node definition data and progresses the game. That is, the terminal progresses the game without having the server make any decisions regarding node transitions. This prevents frequent communication between the terminal and the server regarding the progress of the game, thereby suppressing delays in the progress of the game.

[0008] Furthermore, according to the present invention, the terminal records transition reproduction information capable of reproducing node transitions and values ​​of terminal-side setting information that have changed in response to the node transitions in log data as a log. Furthermore, when a predetermined condition is met, the terminal transmits transmission log data including the log to the server. Meanwhile, the server reproduces node transitions based on the transmission log data and its own node definition data. Furthermore, the server changes the value of the server-side setting information in response to the node transitions and compares the changed value with the value of the corresponding terminal-side setting information recorded in the transmission log data. If these values ​​are not the same, this indicates that the value of the terminal-side setting information in the terminal has deviated from the correct value. Therefore, in this case, it is highly likely that some kind of fraudulent activity has occurred in the terminal. Therefore, comparing these values ​​is equivalent to the server determining whether or not fraudulent activity has occurred in the terminal. In other words, according to the present invention, it is possible to detect fraudulent activity and, upon detection of fraudulent activity, to perform processing to prevent or prevent fraudulent activity or to suppress the adverse effects caused by fraudulent activity.

[0009] That is, according to the present invention, delays in the progress of the game can be suppressed and resistance to cheating can be improved.

[0010] FIG. 1 is a diagram showing the main parts of a control system. FIG. 2 is a diagram showing the configuration of the control system. FIG. 3 is a block diagram showing an example of the functional configuration of a server and a user terminal. FIG. 4 is a diagram showing a screen of a bonus game. FIG. 5 is a diagram showing an example of node definition data. FIG. 6 is a diagram showing node transitions in a bonus game. FIG. 7 is a diagram showing the contents of a record in a node definition data management database. FIG. 8 is a flowchart showing a control method by the control system. FIG. 9 is a diagram showing the contents of node-related information. FIG. 10 is a diagram showing the contents of a record in an active game management database. FIG. 11 is a diagram showing a control method by a terminal. FIG. 12 is a diagram showing a control method by a terminal and a control method by a server. FIG. 13 is a diagram showing an example of a log. FIG. 14 is a diagram showing a control method by a server. FIG. 15 is a diagram showing a control method by a server. FIG. 16 is a diagram showing the contents of random number usage history information. FIG. 17 is a diagram showing a control method by a terminal and a control method by a server.

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0012] <Outline of the Present Embodiment> First, an outline of the present embodiment will be described. FIG. 1 is a diagram showing the main components of a control system 1. As shown in FIG. 1, the control system 1 includes a server 2 and a user terminal 3 (terminal) capable of communicating with the server 2. The server 2 and the user terminal 3 cooperate to provide a game. The server 2 includes a server control unit 10. The user terminal 3 includes a terminal control unit 13. Both the server control unit 10 and the terminal control unit 13 execute processing through cooperation between hardware and software. For example, the server control unit 10 executes processing by a processing device including a CPU reading and executing programs stored in a ROM or other storage unit. The server 2 also includes a server storage unit 12 that stores data. The user terminal 3 includes a terminal storage unit 17 that stores data.

[0013] Before the game is provided, a state is established in which the server 2 and the user terminal 3 can each use common node definition data ND corresponding to the game. The node definition data ND defines multiple nodes indicating the state of the game. While the user is playing the game, the terminal control unit 13 of the user terminal 3 transitions the nodes based on the node definition data ND of the user terminal 3 and changes the values ​​of the terminal-side setting information corresponding to the node definition data ND of the user terminal 3 in accordance with the node transition. Meanwhile, the terminal control unit 13 records transition reproduction information capable of reproducing the node transition and the values ​​of the terminal-side setting information that have changed in accordance with the node transition in the log data LD as a log LG. Furthermore, when a log transmission condition for transmitting the log LG is met, the terminal control unit 13 transmits transmission log data DL including the log LG recorded in the log data LD to the server 2 (step S1).

[0014] The server control unit 10 of the server 2 reproduces node transitions based on the transition reproduction information in the transmission log data DL and the node definition data ND of the server 2. Furthermore, the server control unit 10 changes the value of the server-side setting information corresponding to the server's node definition data ND in accordance with the node transitions, and executes a verification process that compares the value of the server-side setting information with the value of the corresponding terminal-side setting information recorded in the transmission log data DL. The configuration of the control system 1 can suppress delays in the progress of the game and improve resistance to cheating.

[0015] <Details of this embodiment> Next, details of this embodiment will be described. Fig. 2 is a diagram showing an example of the configuration of a control system 1 according to this embodiment. As shown in Fig. 2, the control system 1 is configured to include a server 2 (computer) and one or more user terminals 3 (terminals, computers). The server 2 and the user terminals 3 can communicate with each other via a network N, which may include the Internet, a telephone network, or other communication networks. The server 2 and the user terminals 3 work together to provide a game to users.

[0016] The server 2 provides services related to the game (hereinafter referred to as the "Service"). In the game according to this embodiment, the user terminal 3 provides the screen and accepts user operations. Furthermore, in the game, predetermined information related to the game is stored on the server 2, and communication occurs between the user terminal 3 and the server 2 while the game is being played. In FIG. 2 and FIG. 3 (described later), the server 2 is represented by a single block. However, this does not mean that the server 2 is composed of a single server device. For example, the server 2 may be composed of multiple server devices. In this case, the server devices constituting the server 2 may include a web server or web application server. In particular, a system may be configured with multiple server devices having the same functions for load balancing, communication facilitation, or other purposes. In this configuration, requests are distributed to each server device by, for example, a load balancer. In this configuration, the server 2 may be one or more of the multiple server devices.

[0017] The user terminal 3 is a terminal used by a user. A user refers to a person who can play a game using the control system 1. The user terminal 3 is a convenient reference to a terminal used by a user, and does not refer to a terminal used exclusively by a user. The user terminal 3 may be of any type. For example, a tablet computer (including so-called smartphones), a desktop computer, a notebook computer, a game console, or a wearable device can function as the user terminal 3.

[0018] Fig. 3 is a block diagram showing an example of the functional configuration of the server 2 and the user terminal 3. As shown in Fig. 3, the server 2 includes, as its functional configuration, a server control unit 10, a server communication unit 11, and a server storage unit 12. The user terminal 3 includes, as its functional configuration, a terminal control unit 13, a terminal communication unit 14, a terminal display unit 15, a terminal input unit 16, and a terminal storage unit 17.

[0019] The server control unit 10 of the server 2 includes a processing unit and a primary storage device. The processing unit is a device with information processing capabilities and includes a CPU. The CPU includes a control unit, an arithmetic unit, a register, and a cache memory. The primary storage device includes a DRAM and other volatile memory. The server control unit 10 executes processing by having the processing unit load programs stored in the server storage unit 12 (or other storage area) into the primary storage device and execute them. In other words, the server control unit 10 executes processing through cooperation between hardware and software. The server communication unit 11 includes a communication device capable of communicating with external devices. The communication device includes a communication control unit and a network interface. The server communication unit 11 communicates with external devices via the communication device under the control of the server control unit 10. Hereinafter, detailed description of communication using the network N by the server 2 and other communications will be omitted, assuming that they are appropriately performed by the server communication unit 11. The server storage unit 12 includes a hard disk drive (or other magnetic storage device), ROM, flash memory, and other nonvolatile memory. The server storage unit 12 stores data in the nonvolatile memory.

[0020] As shown in FIG. 3, a database server 20 is connected to the server communication unit 11. The database server 20 stores a node definition data management database 21 and an ongoing game management database 22. Hereinafter, the node definition data management database 21 will be referred to as the "data management DB," and the ongoing game management database 22 will be referred to as the "game management DB." The server control unit 10 can access the data management DB and the game management DB. FIG. 3 shows a diagram in which the server 2 and the database server 20 are directly connected. However, the connection form between the server 2 and the database server 20 is not limited. The server 2 and the database server 20 may be connected via a network N, a LAN, or directly via wired or wireless connection.

[0021] The terminal control unit 13 of the user terminal 3 includes a processing device with information processing capabilities and a primary storage device. The terminal control unit 13 executes processing by having the processing device read a program stored in the terminal storage unit 17 (or another storage area) into the primary storage device and execute it. In other words, the terminal control unit 13 executes information processing through cooperation between hardware and software. The terminal communication unit 14 includes a communication device having a communication control device and a network interface. The terminal communication unit 14 communicates with external devices via the communication device under the control of the terminal control unit 13. Hereinafter, detailed description of communication using the network N and other communications by the user terminal 3 will be omitted, assuming that they are appropriately performed by the terminal communication unit 14. The terminal display unit 15 includes a liquid crystal panel, an organic EL panel, or other display device. The terminal display unit 15 displays images on the display device under the control of the terminal control unit 13. The terminal input unit 16 includes a keyboard, a mouse, a touch panel, or other input device. The terminal input unit 16 detects input to the input device and outputs the detection result to the terminal control unit 13. The terminal storage unit 17 includes non-volatile memory. The terminal storage unit 17 stores data in a non-volatile memory.

[0022] As shown in FIG. 3, a game-related application AP (hereinafter referred to as the "game application AP") has been downloaded to the user terminal 3. Hereinafter, the game corresponding to the game application AP will be referred to as the "game." The game application AP is, for example, an application for smartphones. In this case, the game application AP is downloaded to the user terminal 3 using, for example, an application download service. The game application AP has functions to provide various screens related to the game, to accept operations by the user and execute processing corresponding to the operations, to send and receive various information to and from the server 2, and to execute other processes related to the game.

[0023] In this embodiment, the following bonus game may be used as an example. For example, a bonus game is initiated within the game when a predetermined event occurs while the user is playing the game. Hereinafter, an example in which a bonus game is used will be referred to as the "example." FIG. 4 is a diagram used to explain the bonus game. In the bonus game, the user holds points. Points are measured in units of "pt." As indicated by reference character Z4A in FIG. 4, in the bonus game, a pre-selection screen G1 is first displayed on the terminal display unit 15. The pre-selection screen G1 depicts the backs of four cards. The contents of the cards are either a winning or losing card. If the user selects a winning card, the point balance increases by 1000 pt, and if the user selects a losing card, the point balance remains unchanged. The user uses the cursor to select one of the four cards and operates the confirm button B1 to select that card. Then, as shown by symbol Z4B, a post-selection screen G2 indicating whether the card selected by the user was a winning card or a losing card is displayed on the terminal display unit 15. The user's point balance also changes depending on whether the card selected was a winning card or a losing card. The user checks the content of the screen, and if they wish to end the bonus game, they operate the end button B2.

[0024] Here, in a game provided through cooperation between a terminal and a server, fraudulent activities may occur. With regard to the bonus game, if no allowance is made, fraudulent activities may occur, such as increasing the point balance when a losing card is selected, or increasing the point balance by 100,000 points when a winning card is selected. Fraudulent activities are typically committed by modifying the terminal's program (in this embodiment, the game application AP or a program associated therewith) or by tampering with communications between the terminal and the server. As will become clear later, the control system 1 according to this embodiment has achieved improved resistance to fraudulent activities.

[0025] As will become clear later, the bonus game progresses using the corresponding node definition data ND (described later). Hereinafter, a game that uses node definition data ND to progress, such as a bonus game, will be referred to as a "unit game." In this embodiment, before a situation arises in which a unit game can be played by a user, the node definition data ND corresponding to the unit game is uploaded to the server 2 and stored in the data management DB. Note that "before a situation arises in which a unit game can be played by a user" refers to, for example, before the corresponding game application AP is released or before the unit game becomes playable due to an update of the game. An example of the flow until the node definition data ND corresponding to the unit game is stored in the data management DB will be described below.

[0026] First, the entity developing the present game creates node definition data ND corresponding to the unit game. Hereinafter, the entity developing the present game will be referred to as the "developer." FIG. 5 is a diagram showing the contents of node definition data ND corresponding to a bonus game, simplified for ease of explanation. Hereinafter, the node definition data ND corresponding to a bonus game will be referred to as the "present node definition data NDa." The node definition data ND is data / files used to progress the unit game. The node definition data ND is used to manage at least the nodes of the unit game and the status of certain items related to the unit game. A node refers to a state that the unit game can be in. Herein, a state refers to each state represented by a state transition diagram (state machine diagram). Hereinafter, the "state of the unit game" managed as a node will be referred to as the "game state."

[0027] FIG. 6 is a state transition diagram for the nodes defined in the present node definition data NDa of FIG. 5. As shown in FIG. 6, in this example, when a bonus game starts, the game state transitions to a standby node. When a card selection event occurs while the game state is at the standby node, the game state transitions to a lottery node. With regard to node transitions, an event refers to an event (trigger event) that triggers a node transition. A parameter can be added to an event. The parameter is, for example, an argument passed to a program / function executed after the event is executed. When a lottery completion event occurs while the game state is at the lottery node, the game state transitions to a standby node. When an end event occurs while the game state is at the standby node, the game state transitions to an end node. When the game state transitions to the end node, the bonus game ends. The details of each node and each event will be made clear later. In this example, the bonus game progresses as nodes transition according to the state transitions shown in FIG. 6.

[0028] State variable information can be defined in the node definition data ND. The state variable information defines state variables that indicate the state of specific items related to the unit game. As shown in FIG. 5, the node definition data NDa defines the number of selections <item>, point balance <item>, and lottery result <item> as state variables. In this embodiment, the expression "<item>" indicates that the corresponding term is an item / variable that has a value. The number of selections <item> stores a value indicating the number of times a card is selected by the user in the bonus game. The point balance <item> stores a value indicating the user's point balance. The lottery result <item> is a variable that stores a value indicating the result of the card selection.

[0029] The node definition data ND also defines initial node information. The initial node information defines the node to which a transition should first be made at the start of a unit game (hereinafter referred to as the "initial node"). As shown in FIG. 5, the node definition data NDa defines a standby node as the initial node. The node definition data ND also defines individual node information for each of a plurality of nodes. Defining individual node definition information in the node definition data ND is equivalent to defining a node in the node definition data ND. Acceptance event information, transition processing information, and completion issuance event information can be defined in the individual node definition information.

[0030] The accepted event information defines the events that are accepted when the game state is stagnating in the node. The accepted event information defines an event by describing the event type, name, and other identification information. Hereinafter, an event defined in the accepted event information will be referred to as an "accepted event." When the game state is stagnating in a node and an accepted event defined in that node occurs, a transition from that node to another node will occur in accordance with the transition rules described below.

[0031] The transition process information defines a transition process that is executed when a transition occurs to the current node. The transition process information defines the transition process by describing identification information (e.g., a function name) of a program corresponding to the transition process. The transition process information also defines the transition process by directly describing a program (script) corresponding to the transition process. The transition process may include a process that changes the value of a state variable. When the game state transitions from one node to another node, if one or more transition processes are defined for the other node, each of the defined transition processes is executed.

[0032] The completion-issued event information defines an event that should be issued after a transition to the current node has been made and the execution of each transition-time process defined for the current node has been completed. However, if no transition-time process is defined for the current node, the transition-time process is not executed after a transition to the current node, and the event defined in the completion-issued event information is issued. The completion-issued event information defines an event by describing the event type, name, and other identification information. Hereinafter, an event defined in a completion-issued event is referred to as a "completion-issued event." When the game state transitions from one node to another node, if a transition-time process is defined for the other node, the transition-time process is executed. If no transition-time process is defined for the other node, the transition-time process is not executed. Thereafter, if a completion-issued event is defined for the other node, the completion-issued event is issued. Note that in this embodiment, for convenience of explanation, it is assumed that no completion-issued event is defined for the initial node. In other words, in this embodiment, a completion-issued event is not issued in response to a transition to the initial node.

[0033] As shown in FIG. 5 , the node definition data NDa defines individual node information for each of a standby node, a lottery node, and an end node. That is, the node definition data NDa defines a standby node, a lottery node, and an end node. Focusing on the standby node, a card selection event and an end event are defined as acceptance events for the standby node. This means that if a card selection event or an end event occurs when the game state is the standby node, a transition to another node occurs in accordance with the transition rules described below. Furthermore, no transition processing or completion issuance event is defined for the standby node. This means that after the bonus game transitions to the standby node, no transition processing is executed and no completion issuance event is issued. Focusing on the lottery node, a lottery completion event is defined as an acceptance event for the lottery node. This means that if a lottery completion event occurs when the game state is the lottery node, a transition to another node occurs in accordance with the transition rules described below. Furthermore, a lottery processing is defined for the lottery node as transition processing. This means that a lottery processing is executed when the game state transitions to the lottery node. In addition, a lottery completion event is defined as an event to be issued at the completion of the lottery node. This means that the game state transitions to the lottery node and the lottery process is completed, and then the lottery completion event is issued.

[0034] The node definition data ND defines transition rule information. The transition rule information defines transition rules, which are rules regarding node transitions. The transition rule defines an event (trigger event) that triggers a node transition and the mode of node transition when the event occurs. In this embodiment, the transition rule defines a combination of a node before the transition (identification information indicating the node), an event (identification information indicating the event) that triggers the node transition, and a node after the transition (identification information indicating the node). For example, assume that transition rule JA defines node NA as the node before the transition, event IV as the event that triggers the node transition, and node NB as the node after the transition. In this case, transition rule JA indicates that when event IV occurs when the game state is node NA, the game state transitions from node NA to node NB.

[0035] As shown in Fig. 5, the node definition data NDa defines transition rules J1 to J3. Transition rule J1 defines a standby node as the node before the transition, a card selection event as the event that triggers the node transition, and a lottery node as the node after the transition. This transition rule J1 indicates that if a card selection event occurs when the game state is at the standby node, a transition occurs from the standby node to the lottery node. The contents of transition rules J2 to J3 are as shown in Fig. 5. In Fig. 6, the transition rules are clearly indicated in association with the events that trigger the node transition.

[0036] In this embodiment, the node definition data ND is a program file in which a program written in a predetermined programming language is written. The node definition data ND contains various pieces of information written in the predetermined programming language. The predetermined programming language is a dedicated programming language specialized for the node definition data ND. However, the predetermined programming language may also be HTML or another existing programming language. For example, a developer creates the node definition data ND using a tool or software development kit provided by the administrator of the server 2. In this embodiment, the node definition data ND is a program file in which information is written by a program. However, the node definition data ND may not be a program file, but may be data in which information is written in JSON or another description format. The node definition data ND may also be data in which information is written in a unique format. One piece of node definition data ND may reference one or more other pieces of node definition data ND. In this case, a combination of multiple pieces of node definition data ND functions as "node definition data." The node definition data ND is data in which information regarding state transitions is recorded and can be considered equivalent to a state machine.

[0037] After creating the node definition data ND, the developer uploads the data to the server 2. The server 2 provides the developer with a means for uploading the node definition data ND. When the node definition data ND is uploaded, the server control unit 10 of the server 2 executes the following process. Specifically, the server control unit 10 generates a data ID that is a unique value that identifies the uploaded node definition data ND. The server control unit 10 then registers a record including the generated data ID and the uploaded node definition data ND in the data management DB of the database server 20. However, the record may store, instead of the node definition data ND, the address of the storage location of the data, the path to the storage location of the data, or other information for accessing the data. FIG. 7 shows the contents of one record in the data management DB. Furthermore, the server control unit 10 notifies the developer of the generated data ID in a predetermined manner. As a result of the above process, a record in which the data ID and the node definition data ND are associated is registered in the data management DB before a situation in which a unit game can be played by a user is created. The developer is also notified of the data ID.

[0038] The above is an example of the flow until the node definition data ND is stored in the data management DB. However, the illustrated flow is just an example, and the node definition data ND may be stored in the data management DB in a flow different from the illustrated flow. In this embodiment, for each unit game, a record including a data ID and node definition data ND is registered in the data management DB. Note that a developer or other authorized entity can change the contents of the node definition data ND stored in the data management DB.

[0039] Next, the operation of the control system 1 will be described. Below, the operation of the control system 1 will be described, particularly when a unit game is played by a user. FIG. 8 is a flowchart showing an example of the operation of the control system 1 during the period when a unit game is being played. Flowchart FA in FIG. 8 shows an example of the operation of the user terminal 3, and flow chart FB shows an example of the operation of the server 2. At the start of the flowchart in FIG. 8, it is assumed that the game application AP is running on the user terminal 3 and that the user is playing the game. Hereinafter, in this example, a user playing a bonus game will be referred to as a "noted user." It is assumed that the noted user's point balance is 1,000 pts before the noted user plays the bonus game.

[0040] As shown in flowchart FA, when an event occurs within the game that triggers the start of a unit game, the terminal control unit 13 of the user terminal 3 transmits start notification information notifying the server control unit 10 of the start of the unit game (step SA1). The start notification information includes the data ID of the node definition data ND corresponding to the unit game. In this embodiment, the node definition data ND is stored in the data management DB in association with the data ID for each unit game. Then, when a unit game is started on the user terminal 3, the terminal control unit 13 transmits the data ID of the node definition data ND corresponding to the unit game to the server control unit 10.

[0041] As shown in flowchart FB, when the server control unit 10 of the server 2 receives the start notification information, it acquires the corresponding node definition data ND (step SB1). More specifically, the server control unit 10 references the data management DB and identifies a record corresponding to the data ID included in the start notification information. The server control unit 10 then acquires the node definition data ND of the identified record. In this way, the server control unit 10 can acquire any node definition data ND stored in the data management DB. This means that the server control unit 10 is able to use any node definition data ND stored in the data management DB.

[0042] After processing step SB1, the server control unit 10 executes server-side initial startup processing (step SB2). More specifically, the server control unit 10 first generates an instance of the node definition data ND acquired in step SB1. "Generating an instance of the node definition data ND" means reserving an area for the node definition data ND in a primary storage device or other memory area, and enabling the server control unit 10 to execute processing based on the node definition data ND. In this way, in this embodiment, the node definition data ND functions as a class that serves as the basis for the instance.

[0043] When an instance of node definition data ND is generated, memory space is reserved for each item of node-related information corresponding to the node definition data ND, and a value can be stored in each item. Node-related information is information used in the node definition data ND and the unit game corresponding to the node definition data. The node-related information is made up of multiple items / variables for which memory space is reserved in response to the generation of an instance of node definition data ND. In response to the generation of an instance of node definition data ND, the server control unit 10 stores values ​​in each item of the node-related information, updates the values ​​of each item, and becomes able to reference the values ​​of each item.

[0044] FIG. 9 is a diagram illustrating the contents of node-related information. As shown in FIG. 9 , in this embodiment, the node-related information includes the running game ID (item), random number seed (item), node transition count (item), current node (item), and state variables defined in the node definition data ND. In FIG. 9 , the state variables are expressed as first state variable, second state variable, etc. The running game (item) and random number seed (item) do not change their values ​​after initial values ​​are stored. The node transition count (item), current node (item), and state variables are items whose values ​​can change as the unit game progresses. Hereinafter, these items are collectively referred to as setting information. Of the items in the setting information, the node transition count (item) and current node (item) are items that are not defined as state variables. Hereinafter, these items are collectively referred to as management information. Hereinafter, the "value of each item of node-related information" may be simply referred to as the "value of node-related information." The same applies to other information composed of multiple items.

[0045] After generating an instance of the node definition data ND, the server control unit 10 sets an initial value for each item of the node-related information. Specifically, the running game ID, which is identification information for the generated instance, is stored in the running game ID <item>. The server control unit 10 generates a unique running game ID and stores it in the running game ID <item> as an initial value. The random number seed <item> stores a random number seed. The random number seed is a value input to the random number generator when generating random numbers. In this embodiment, the random number generator is a module that generates random numbers using a recurrence formula and can output consecutive random numbers from a single random number seed. In this embodiment, the server 2 and the user terminal 3 can each use a common random number generator for the unit game. A common random number generator means that the recurrence formula corresponding to the random number generator is the same. Therefore, common random number generators output the same value when the input value is the same. Hereinafter, the random number generator used by the server 2 for the unit game will be referred to as the "server-side random number generator." The server-side random number generator is stored, for example, in the database server 20, or in the server storage unit 12. The random number generator used by the user terminal 3 for the unit game will be referred to as the "terminal-side random number generator." The server control unit 10 generates a random number seed using a program that has the function of generating random values ​​in a predetermined format, and stores the random number seed <item> as an initial value.

[0046] The node transition count <item> stores the node transition count indicating the number of node transitions that occurred during the unit game. The server control unit 10 stores a node transition count indicating 0 in the node transition count <item> as the initial value. The current node <item> stores current node information indicating the node where the game state is currently stagnating (hereinafter referred to as the "current node"). The server control unit 10 stores a dummy value indicating that no node transition has occurred in the current node <item> as the initial value. The server control unit 10 also stores appropriate initial values ​​for each state variable. In this example, the server control unit 10 stores a selection count indicating 0 in the selection count <item>, a point balance indicating 1000 points in the point balance <item>, and a dummy value indicating neither a win nor a loss in the lottery result <item>. The server control unit 10 obtains the point balance of the target user from a user management database (not shown). The user management database is stored in the database server 20. The value of each item of the node-related information is actually expressed in an appropriate format according to the defined data type.

[0047] The above is the server-side initial startup process. The server-side initial startup process enables the server control unit 10 to execute processing based on the node definition data ND, and stores initial values ​​in each item of the node-related information corresponding to the generated instance. In the following description, the node definition data ND that served as the basis for the instance generated by the server control unit 10 is referred to as the "server-side node definition data NDs." The execution of processing by the server control unit 10 using the generated instance is expressed as "executing processing based on the server-side node definition data NDs" or "executing processing using the server-side node definition data NDs." The node-related information, configuration information, management information, and state variables corresponding to the instance generated by the server control unit 10 are referred to as the server-side node-related information, server-side configuration information, server-side management information, and server-side state variables, respectively.

[0048] In the server-side initial startup process, not only the processes described above are performed, but also the processes necessary for the server control unit 10 to establish a state in which the server can execute the processes based on the node definition data ND are appropriately performed. Even if not otherwise specified, the processes necessary to achieve the purpose of the processes are performed, and this is the same for other processes.

[0049] After processing step SB2, the server control unit 10 registers one new record in the game management DB (step SB3). The registered record includes values ​​for each item of the server-side node-related information. However, at this stage, the values ​​for each item of the server-side node-related information are initial values. Hereinafter, with regard to the node-related information contained in the game management DB record, the node-related information, setting information, management information, and state variables are referred to as registered node-related information, registered setting information, registered management information, and registered state variables, respectively. Figure 10 shows the contents of the record registered in the game management DB in step SB3 for this example. In the example of Figure 10, the value of the game running ID is set to "GM01," and the value of the random number seed is set to an appropriate value.

[0050] After processing step SB3, the server control unit 10 transmits the node definition data ND acquired in step SB1 and the registered node-related information included in the record registered in the game management DB in step SB3 to the terminal control unit 13 (step SB4). Note that the node definition data ND is transmitted from the terminal control unit 13 to the server control unit 10 by, for example, having the user terminal 3 download the node definition data ND from the server 2. After processing step SB4, the instance generated in the server-side initial startup processing in step SB2 is discarded.

[0051] As shown in flow chart FA, terminal control unit 13 receives the node definition data ND and registered node related information transmitted by server control unit 10 in step SB4, and stores each piece of data in terminal storage unit 17 (step SA2). The processing of step SA2 enables terminal control unit 13 to use the node definition data ND. In this manner, in this embodiment, before a unit game (game) is provided, a state is established in which both server 2 and user terminal 3 can use the common node definition data ND corresponding to the unit game.

[0052] After processing step SA2, the terminal control unit 13 executes terminal-side startup processing (step SA3). In step SA3, the terminal control unit 13 generates an instance of the node definition data ND received in step SA2 and establishes a state in which processing can be executed based on the node definition data ND. In response to the generation of the instance, memory space is reserved for each item of node-related information, allowing values ​​to be stored in each item. In the following description, the node definition data ND that served as the basis for the instance generated by the terminal control unit 13 will be referred to as "terminal-side node definition data NDd" for convenience. Furthermore, the execution of processing by the terminal control unit 13 using the generated instance will be expressed as "executing processing based on the terminal-side node definition data NDd" or "executing processing using the terminal-side node definition data NDd." Furthermore, the node-related information, setting information, management information, and state variables corresponding to the instance generated by the terminal control unit 13 will be referred to as terminal-side node-related information, terminal-side setting information, terminal-side management information, and terminal-side state variables, respectively. As will be apparent later, the values ​​of each item of the terminal-side setting information are updated by the terminal control unit 13 in accordance with the progress of the unit game.

[0053] The terminal control unit 13 initializes the values ​​of the terminal-side node-related information based on the registered node-related information received in step SA2. Initializing the values ​​of the terminal-side node-related information based on the registered node-related information means storing the values ​​of each item of the received registered node-related information in each item of the terminal-side node-related information. As a result, each item of the terminal-side node-related information is stored with its initial value.

[0054] After processing step SA3, the terminal control unit 13 starts game progression processing (step SA4). The game progression processing is processing in which the terminal control unit 13 progresses the unit game using the terminal-side node definition data NDd. The game progression processing is described in detail below. Flowchart FC in FIG. 11 shows processing executed by the terminal control unit 13 based on the terminal-side node definition data NDd in relation to the progress of the unit game. Note that in addition to the processing shown in Flowchart FC, the presentation of various screens, the output of audio, the acceptance of user operations, and other processing related to the game are naturally executed in the progress of the unit game.

[0055] As shown in the flowchart FC of FIG. 11 , the terminal control unit 13 transitions the game state of the unit game to the initial node based on the initial node information in the terminal-side node definition data NDd (step SC1). In response to the transition to the initial node, the terminal control unit 13 increments the value of the node transition count <item>, which is terminal-side management information, and further stores a value indicating the initial node in the current node <item>. In this embodiment, even if not otherwise specified, the values ​​of the node transition count <item> and current node <item> are updated when a node transition occurs. Next, the terminal control unit 13 determines whether a transition process is defined for the initial node (step SC2). If a transition process is defined (step SC2: YES), the terminal control unit 13 executes the transition process (step SC3). If the transition process is a process that changes the value of a state variable, the value of the state variable is updated in response to the execution of the transition process. This also applies to the following steps. After processing step SC3, the terminal control unit 13 proceeds to step SC4. If no transition process is defined for the initial node (step SC2: NO), the terminal control unit 13 proceeds to step SC4.

[0056] In step SC4, the terminal control unit 13 monitors whether an event that triggers a node transition has occurred. Note that the completion issue event issued in step SC11, described below, may also be the event that triggers a node transition. When an event that triggers a node transition has occurred (step SC4: YES), the terminal control unit 13 executes a transition reproduction information recording process (step SC5). The transition reproduction information recording process is a process of recording transition reproduction information capable of reproducing a node transition as a log LG in the log data LD. The log data LD is generated upon the start of a unit game and stored in a predetermined storage area of ​​the terminal storage unit 17. In particular, in this embodiment, the transition reproduction information recording process is a process of recording event content information indicating the content of the event that has occurred in the log data LD when an event that triggers a node transition has occurred. In other words, in this embodiment, the event content information corresponds to the transition reproduction information.

[0057] Regarding the recording of event content information in the log data LD, the terminal control unit 13 records event timing information indicating the timing at which the event occurred, information indicating that the log type is an event, and event content information in the log data LD according to a format. In this embodiment, the event timing information is information indicating the date and time (date + time) at which the event occurred. However, the event timing information may be any information that allows for understanding the chronological timing of when the event occurred. This also applies to the status acquisition timing information described below. The event content information includes identification information of the event. Furthermore, if parameters are added to the event, the event content information includes the values ​​of the added parameters.

[0058] If it is determined in step SC4 that an event has occurred (step SC4: YES), the terminal control unit 13 further executes the following process. That is, the terminal control unit 13 transitions the node in accordance with the transition rules defined in the terminal-side node definition data NDd (step SC6). The terminal control unit 13 updates the terminal-side setting information in accordance with the node transition. After processing step SC6, the terminal control unit 13 determines whether or not a transition process is defined for the node after the transition (step SC7). If it is defined (step SC7: YES), the terminal control unit 13 executes the transition process (step SC8) and proceeds to step SC9. If it is not defined (step SC7: NO), the terminal control unit 13 proceeds to step SC9.

[0059] In step SC9, the terminal control unit 13 executes a terminal-side setting information recording process. The terminal-side setting information recording process is a process for recording the values ​​of the terminal-side setting information as a log in the log data LD. In particular, in this embodiment, the terminal control unit 13 records a state hash value, which is a hash value of the values ​​of the terminal-side setting information, in the log data LD as the values ​​of the terminal-side setting information. More specifically, the terminal control unit 13 acquires the values ​​of each item of the terminal-side setting information at the current time. Each item of the terminal-side setting information includes management information and state variables. Next, the terminal control unit 13 generates data (hereinafter referred to as "arrangement data") in which the values ​​of each item of the terminal-side setting information are arranged according to a rule (hereinafter referred to as "arrangement rule"). Next, the terminal control unit 13 derives a hash value of the array data using a predetermined hash function. The derived hash value is the state hash value. Next, the terminal control unit 13 records state acquisition timing information indicating the current time, information indicating that the log type is terminal-side setting information, and the state hash value in the log data LD according to a format. In this way, in this embodiment, after a node transition occurs, if a transition processing is defined for the node after the transition, the terminal control unit 13 executes that processing, and then records the value of the terminal side setting information (in this embodiment, a state hash value based on the value of the terminal side setting information) in the log data LD as a log LG.

[0060] After processing step SC9, the terminal control unit 13 determines whether a completion issue event is defined for the node after the transition (step SC10). If it is defined (step SC10: YES), the terminal control unit 13 issues a completion issue event (step SC11) and returns the processing procedure to step SC4. If it is not defined (step SC10: NO), the terminal control unit 13 returns the processing procedure to step SC4.

[0061] Next, the game progression process executed by the user terminal 3 in this example will be described. Flowchart FD in FIG. 12 shows the details of the game progression process according to this example. For ease of explanation, in Flowchart FD, only the node transition process and the transition process are shown along the main axis of the flowchart. In Flowchart FD, the process of generating an event, the transition reproduction information recording process, the terminal-side setting information recording process, and the process of displaying various screens are shown in association with the main axis of the flow. In Flowchart FD, the contents of the terminal-side node definition data NDd are the contents of the present node definition data NDa in FIG. 5.

[0062] As shown in flowchart FD, the terminal control unit 13 transitions the game state of the bonus game to a standby node based on the initial node information in the terminal-side node definition data NDd (step SD1). In response to the transition to the standby node, the terminal control unit 13 increments the value of the node transition count (item) from 0 to 1 and updates the value of the current node (item) to a value indicating the standby node. After processing step SD1, the terminal control unit 13 displays a pre-selection screen G1 (see FIG. 4) on the terminal display unit 15 using the function of the game application AP (step SD2). In this embodiment, the game application AP is programmed to display a screen corresponding to the value of the terminal-side state variable selection count (item). In step SD2, the terminal control unit 13 references the value of the selection count (item) and determines that the number of card selections is 0, and then displays the pre-selection screen G1. The terminal control unit 13 also references the value of the terminal-side state variable point balance (item) and displays information indicating the point balance on the pre-selection screen G1. In this way, the state variables are referenced as appropriate by the terminal control unit 13 executing the game application AP while the unit game is being played. After the pre-selection screen G1 is displayed, the terminal control unit 13 monitors whether or not the confirmation button B1 on the screen has been operated by the user of interest.

[0063] Thereafter, when the user of interest operates the Confirm button B1 on the pre-selection screen G1, the terminal control unit 13 issues a card selection event using the function of the game application AP (step SD3). In response to the occurrence of the card selection event, the terminal control unit 13 executes a transition reproduction information recording process (step SD4). The symbol LG1 in FIG. 13 indicates the contents of a first log newly recorded in the log data LD in the process of step SD4. The first log LG1 includes event timing information indicating the timing when the cart selection event occurred in step SD3, information indicating that the type of the first log LG1 is an event, and event content information indicating the content of the event that occurred in step SD3.

[0064] Furthermore, in response to the occurrence of a card selection event, the terminal control unit 13 transitions the game state to a lottery node based on the transition rule J1 defined in the terminal-side node definition data NDd (step SD5). The terminal control unit 13 appropriately updates the terminal-side setting information in response to the transition to the lottery node. In response to the transition to the lottery node, the terminal control unit 13 executes a lottery process defined as a transition process for the lottery node (step SD6). The lottery process is a process in which the terminal control unit 13 determines the result of the card selection using a terminal-side random number generator and a random number seed included in the registered node-related information received in step SA2 of flowchart FA. The lottery process is described in detail below.

[0065] In the lottery process, the terminal control unit 13 inputs the random number seed received in step SA2 into the terminal-side random number generator and obtains an output value (random number). The terminal control unit 13 then determines the result of the card selection from the output value in accordance with predetermined rules (hereinafter referred to as "lottery rules"). As a very simplified example, the random number generator is configured to output one of four integers, 0, 1, 2, or 3, in response to the input of the random number seed. In this case, the lottery rules are such that if the output value is 0 or 1, the card selection result is a hit, and if the output value is 2 or 3, the card selection result is a miss.

[0066] After determining the result of the card selection, the terminal control unit 13 updates the values ​​of the necessary items in the terminal-side setting information. Specifically, the terminal control unit 13 increments the value of the number of selections <item>, updates the value of the point balance <item> based on the result of the card selection, and stores a value indicating the result of the card selection in the lottery result <item>. In this example, the result of the card selection is determined to be a winning combination. Therefore, in this example, the terminal control unit 13 sets the value of the number of selections <item> to "1 time," the value of the point balance <item> to "2000 points," and stores a value indicating a winning combination in the lottery result <item>. As described above, when the terminal control unit 13 executes a process that uses random numbers in response to node transitions, it executes the process using the random number seed received from the server 2 and the random number generator of the user terminal 3.

[0067] After step SD6, the terminal control unit 13 executes a terminal-side setting information recording process (step SD7). Reference symbol LG2 in Fig. 13 indicates the contents of the second log newly recorded in the log data LD by the process of step SD7. The second log LG2 records status acquisition timing information indicating the current time, information indicating that the type of log LG is terminal-side setting information, and a status hash value based on the values ​​of each item of the current terminal-side setting information.

[0068] After processing step SD7, the terminal control unit 13 issues a lottery completion event, defined as a completion-issue event, to the lottery node (step SD8). In response to the occurrence of the lottery completion event, the terminal control unit 13 executes a transition reproduction information recording process (step SD9). Reference symbol LG3 in FIG. 13 indicates the contents of a third log newly recorded in the log data LD in the processing of step SD9. In response to the occurrence of the lottery completion event, the terminal control unit 13 further transitions the game state to a standby node based on the transition rule J2 defined in the terminal-side node definition data NDd (step SD10). In response to the transition to the standby node, the terminal control unit 13 appropriately updates the terminal-side setting information. In response to the transition to the standby node, the terminal control unit 13 executes a terminal-side setting information recording process (step SD11). Reference symbol LG4 in FIG. 13 indicates the contents of a fourth log newly recorded in the log data LD in the processing of step SD11. In response to the transition to the standby node, the terminal control unit 13 further displays a post-selection screen G2 (see FIG. 4) on the terminal display unit 15 (step SD12). The terminal control unit 13 references the value of the terminal-side state variable "number of selections <item>" and recognizes that the number of card selections is one, and then displays the post-selection screen G2. The terminal control unit 13 also references the values ​​of the terminal-side state variables "point balance <item>" and "lottery result <item>" and sets the content of the post-selection screen G2 based on these values. After displaying the post-selection screen G2, the terminal control unit 13 monitors whether the end button B2 on that screen has been operated by the user of interest.

[0069] When the target user subsequently selects the end button B2 on the post-selection screen G2, the terminal control unit 13 issues an end event using the function of the game application AP (step SD13). In response to the occurrence of the end event, the terminal control unit 13 executes a transition reproduction information recording process (step SD14). LG5 in FIG. 13 indicates the contents of the fifth log newly recorded in the log data LD in the process of step SD14. In response to the occurrence of the end event, the terminal control unit 13 further transitions the game state to the end node based on the transition rule J3 defined in the terminal-side node definition data NDd (step SD15). In response to the transition to the standby node, the terminal control unit 13 appropriately updates the terminal-side setting information. In response to the transition to the standby node, the terminal control unit 13 executes a terminal-side setting information recording process (step SD16). Symbol LG6 in FIG. 13 indicates the contents of the sixth log newly recorded in the log data LD in the process of step SD16. The bonus game ends in response to the transition to the end node.

[0070] The game progression processing has been described above. As described above, the terminal control unit 13 executes the following processing in the game progression processing. That is, while the user is playing the game, the terminal control unit 13 automatically transitions the nodes based on the node definition data ND of the user terminal 3, and dynamically changes the value of the terminal-side setting information corresponding to the node definition data ND of the user terminal 3 in accordance with the node transition. Meanwhile, the terminal control unit 13 automatically records transition reproduction information capable of reproducing the node transition and the value of the terminal-side setting information that has changed in accordance with the node transition as a log LG in the log data LD. More specifically, the terminal control unit 13 executes the following processing. That is, while the user is playing the game, the terminal control unit 13 continuously monitors whether an event (trigger event) has occurred, and, in accordance with the occurrence of an event (trigger event), automatically transitions the nodes based on the transition rules of the node definition data ND of the user terminal 3, and dynamically changes the value of the terminal-side setting information in accordance with the node transition. On the other hand, the terminal control unit 13 automatically records transition reproduction information indicating the content of the event that occurred in the log data LD as a log LG, and also automatically records the value of the terminal side setting information that changed in accordance with the node transition in the log data LD as a log LG.

[0071] As described above, in this embodiment, node transitions for progressing the unit game and updates to the terminal-side setting information accompanying the node transitions are executed based on the terminal-side node definition data NDd by the terminal control unit 13, not the server control unit 10. In other words, the terminal control unit 13 does not execute processes involving communication with the server 2, such as "sending necessary information to the server 2 by communication and waiting for the processing results to be sent by communication from the server 2," with regard to node transitions and updates to the terminal-side setting information. Therefore, the occurrence of communication between the user terminal 3 and the server 2 with regard to the progress of the unit game is suppressed, and delays in the progress of the game due to the occurrence of such communication are suppressed.

[0072] However, in a configuration in which the terminal control unit 13 progresses a unit game based on the terminal-side node definition data NDd, the following problem may arise if no special measures are taken. That is, while a unit game is being played, the terminal control unit 13 transitions nodes, updates the terminal-side setting information, and progresses the unit game without requiring the server control unit 10 to make any decisions. In other words, the accuracy of the terminal-side setting information values ​​is not verified by the server control unit 10 during the progress of the unit game. Therefore, even if the terminal-side setting information values ​​are altered from their original correct values ​​due to fraudulent activity, the game may proceed with the terminal-side setting information values ​​remaining erroneous. For example, suppose that in the lottery process at step SD6 of flowchart FD, a fraudulently altered program function alters the value of the point balance <item> from 2,000 pt (the original correct value) to 100,000 pt. Even in this case, if no special measures are taken, the accuracy of the altered point balance <item> value is not verified by the server control unit 10. Therefore, if no compensation is given, the value of the point balance <item> will remain at 100,000 pts and the bonus game will proceed. As will be apparent later, in this embodiment, measures are taken against such fraudulent acts, and resistance to fraudulent acts is improved.

[0073] As shown in FIG. 8 , after starting the game progress processing in step SA4, the terminal control unit 13 monitors whether a log transmission condition related to the transmission of the log LG has been met (step SA5), while also monitoring whether the unit game has ended (step SA6). The processing in steps SA5 and SA6 is executed in parallel with the game progress processing started in step SA4. The log transmission condition refers to a condition for transmitting transmission log data DL (described below). In this embodiment, it is specified that the transmission log data DL is transmitted periodically at a predetermined interval (e.g., 1 second, 10 seconds, or 30 seconds). Based on this, the log transmission condition according to this embodiment is a condition that a periodically occurring timing has arrived. Hereinafter, the timing for transmitting the transmission log data DL will be referred to as the "log transmission timing."

[0074] If it is determined in step SA5 that the log transmission condition is met (step SA5: YES), the terminal control unit 13 executes a log transmission process (step SA7) and proceeds to step SA6. On the other hand, if it is determined in step SA5 that the log transmission condition is not met (step SA5: NO), the terminal control unit 13 proceeds to step SA6. If it is determined in step SA6 that the unit game has ended (step SA6: YES), the terminal control unit 13 proceeds to step SA8. If it is determined that the unit game has not ended (step SA6: NO), the terminal control unit 13 returns to step SA5. In step SA8, the terminal control unit 13 transmits end notification information indicating the end of the unit game to the server control unit 10. The end notification information includes at least the game ID of the corresponding unit game being executed. After processing step SA8, the processing of flowchart FA ends.

[0075] The log transmission process of step SA7 will be described in detail below. In the log transmission process, the terminal control unit 13 identifies logs LG recorded in the log data LD that have not yet been transmitted to the server 2, and generates transmission log data DL that includes each of the identified logs LG. The transmission log data DL records each log LG in chronological order. Next, the terminal control unit 13 transmits the transmission log data DL to the server control unit 10 together with the data ID corresponding to the unit game and the running game ID included in the registered node-related information received in step SA2. Hereinafter, the combination of the data ID, running game ID, and transmission log data DL transmitted by the log transmission process will be referred to as "log-related data."

[0076] For example, as shown in FIG. 16 , if the first log transmission timing arrives after the fourth log LG4 has been recorded but before the fifth log LG5 has been recorded, the terminal control unit 13 transmits transmission log data DL including the first to fourth logs LG1 to LG4. Then, if the second log transmission timing arrives after the sixth log LG6 has been recorded, the terminal control unit 13 transmits transmission log data DL including the fifth and sixth logs LG5 and LG6. Note that if there are no unsent logs LG when the log transmission timing arrives, the terminal control unit 13 does not transmit the transmission log data DL. However, for ease of explanation, hereinafter, it may be expressed as "the terminal control unit 13 periodically transmits the transmission log data DL."

[0077] As described above, in this embodiment, the terminal control unit 13 continuously monitors whether the log transmission condition is met while the user is playing the game. If the log transmission condition is met, the terminal control unit 13 automatically transmits the transmission log data DL, which includes the log G recorded in the log data LD, to the server 2.

[0078] As shown in the flowchart FB of FIG. 8 , the server control unit 10 executes the following process after processing step SB4. Specifically, the server control unit 10 monitors whether log-related data (transmission log data DL) has been received (step SB5), and then monitors whether end notification information has been received (step SB6). If it determines in step SB7 that log-related data has been received (step SB5: YES), the server control unit 10 executes a verification process (step SB7) and proceeds to step SB6. On the other hand, if it determines in step SB5 that the transmission log data DL has not been received (step SB5: NO), the server control unit 10 proceeds to step SB6. If it determines in step SB6 that end notification information has not been received (step SB6: NO), the server control unit 10 returns to step SB5. If it determines that end notification information has been received (step SB6: YES), the server control unit 10 executes server-side termination processing (step SB8). In the server-side termination processing, a process defined to be executed at the end of a unit game is executed. For example, the server control unit 10 appropriately updates the user management database and other databases based on the record corresponding to the running game ID included in the end notification information. After the processing of step SB8, the flowchart FB ends.

[0079] Note that the flowchart FB in FIG. 8 shows that a single server 2 executes all steps of the process. However, all processes do not necessarily have to be performed sequentially on a single server 2. For example, suppose the server 2 is composed of multiple server devices, and load balancing is achieved by a load balancer. Furthermore, suppose a unit game is started on a specific user terminal 3 (referred to as user terminal TX). In this configuration, the server 2 that receives start notification information from the user terminal TX, the server 2 that receives transmission log data DL from the user terminal TX, and the server device that receives end notification information from the user terminal TX may be different. Furthermore, when the user terminal TX transmits transmission log data DL multiple times, the server devices that receive the multiple pieces of transmission log data DL may be different from each other.

[0080] As described above, while a unit game is being played by a user, the server control unit 10 continuously monitors whether or not transmission log data DL has been received, and executes verification processing in response to reception of transmission log data DL. The verification processing will be described in detail below.

[0081] Flowchart FF in Figure 14 shows the details of the verification process. As shown in flow chart FF, the server control unit 10 acquires the received log-related data (step SF1). The log-related data includes a data ID and an active game ID corresponding to the unit game being played on the sending user terminal 3, and transmission log data DL. Next, the server control unit 10 acquires node definition data ND corresponding to the received data ID from the data management DB (step SF2). Next, the server control unit 10 acquires registered node-related information corresponding to the received active game ID from the game management DB (step SF3).

[0082] Next, the server control unit 10 executes server-side startup processing (step SF4). More specifically, the server control unit 10 generates an instance of the node definition data ND acquired in step SF2, enabling processing based on the server-side node definition data NDs. In response to the generation of the instance of the node definition data ND, values ​​can be stored in each field of the server-side node-related information. Next, the server control unit 10 initializes the values ​​of each field of the server-side node-related information with the values ​​of each field of the registered node-related information acquired in step SF3. As a result, the values ​​of the server-side node-related information match the values ​​of the corresponding registered node-related information currently registered in the game management DB. After generating an instance of the node definition data ND and initializing each field of the node-related information, the server control unit 10 transitions nodes based on the server-side node definition data NDs, thereby progressing a pseudo-unit game. Hereinafter, for ease of explanation, a pseudo-unit game progressed based on the server-side node definition data NDs will be referred to as a "pseudo-unit game." In particular, the pseudo bonus game is called a “pseudo bonus game.” The processing of steps SF1 to SF4 is called a “restart processing.”

[0083] After processing step SF4, the server control unit 10 determines whether the received log-related data is the first data transmitted since the start of the unit game (step SF5). As described above, the terminal control unit 13 periodically transmits log-related data (transmission log data DL) after the start of the unit game. Then, in step SF5, the server control unit 10 determines whether the received log-related data is data transmitted at the first log transmission timing. Whether the data is the first transmitted data is managed, for example, by a predetermined flag. Alternatively, for example, the log-related data may include information indicating whether the data is the first data. If the data is not the first data (step SF5: NO), the server control unit 10 proceeds to step SF7. If the data is the first data (step SF5: YES), the server control unit 10 executes initial node transition processing (step SF6). In the initial node transition processing, the server control unit 10 transitions the game state to the initial node, and if a transition processing is defined for the initial node, executes that processing. The value of the server-side setting information is appropriately updated in response to the transition to the initial node. After processing step SF6, the server control unit 10 proceeds to step SF7.

[0084] From step SF7 onwards, the server control unit 10 performs log handling processing for each log LG included in the transmission log data DL in chronological order of the log LG. That is, in step SF7, the server control unit 10 determines whether there are any unprocessed logs LG among the logs LG recorded in the transmission log data DL. If there are any unprocessed logs LG (step SF7: YES), the server control unit 10 determines the oldest log LG among the unprocessed logs LG as the log to be processed (step SF8). Next, the server control unit 10 performs log handling processing on the log to be processed (step SF9) and returns the processing procedure to step SF7.

[0085] On the other hand, if it is determined in step SF7 that there are no unprocessed logs LG (step SF7: NO), the server control unit 10 executes a server reflection process (step SF10). In the server reflection process of step SF10, the server control unit 10 updates the values ​​of each item of the registered setting information of the corresponding record in the game management DB (the record for which the registered node-related information was obtained in step SF3) with the values ​​of each item of the current server-side setting information. After processing step SF10, flowchart FF ends.

[0086] Thus, in this embodiment, if the log correspondence processing is completed for all logs LG recorded in the transmission log data DL without any status mismatch (described below), the values ​​of each item in the registered setting information of the corresponding record in the game management DB are updated with the values ​​of each item in the server-side setting information. As a result, when the restart processing is performed the next time new log-related data is received, the values ​​of each item in the server-side setting information will be the values ​​of each item at the time when processing for the previously received log-related data was completed. Note that, as will be apparent later, if a status mismatch (described below) occurs during the log correspondence processing and error processing is performed, the verification processing is interrupted. In this case, the server reflection processing of step SF10 is not performed.

[0087] Flowchart FG of FIG. 15 shows details of the log handling process. In the log handling process, the server control unit 10 determines whether the type of the log to be processed is an event or terminal-side setting information (step SG1). As described above, if the type of the log to be processed is an event, event content information is recorded in the log to be processed. If the type of the log to be processed is terminal-side setting information, a state hash value is recorded in the log to be processed. If the type of the log to be processed is an event (step SG1: "event"), the server control unit 10 issues an event indicated by the event content information of the log to be processed (step SG2). Note that if the event content information indicates an event with parameters, the server control unit 10 accurately reproduces the parameters and issues the event. Next, the server control unit 10 transitions the nodes of the simulated unit game in accordance with the transition rules in the server-side node definition data NDs (step SG3). The server control unit 10 updates the server-side setting information as necessary in response to the node transition. Next, the server control unit 10 determines whether transition processing is defined for the node after the transition (step SG4). If it is defined (step SG4: YES), the server control unit 10 executes transition processing (step SG5). The transition processing includes processing that changes the values ​​of state variables and other items of the server-side configuration information. Therefore, the processing of step SG5 may change the values ​​of one or more items of the server-side configuration information. Furthermore, if the transition processing is a processing that uses a random number, the server control unit 10 generates a random number using the random number seed stored in the random number seed <item> of the server-side configuration information and the server-side random number generator. The value of this random number seed matches the value of the random number seed generated by the server control unit 10 in step SB2 and transmitted to the user terminal 3 in step SB4.

[0088] As described above, the server 2 and the user terminal 3 can each use a common random number generator. The server control unit 10 generates a random number seed and transmits it to the user terminal 3, and when executing a process that uses random numbers in response to node transitions in the verification process, the server control unit 10 executes the process using the generated random number seed and the random number generator of the server 2. On the other hand, when executing a process that uses random numbers in response to node transitions, the terminal control unit 13 executes the process using the random number seed received from the server 2 and the random number generator of the terminal. This makes it possible to completely match the processing results of the server control unit 10 and the processing results of the terminal control unit 13 for processes performed using other random number generators.

[0089] In addition, even if a completion issue event is defined for the node after the transition during the verification process, the server control unit 10 does not issue the completion issue event and cancels the issuance of the completion issue event. After processing step SG5, the log response process ends. On the other hand, if a transition process is not defined for the log after the transition (step SG4: NO), the server control unit 10 ends the log response process.

[0090] If it is determined in step SG1 that the type of the log to be processed is terminal-side setting information (step SG1: "terminal-side state information"), the server control unit 10 derives a comparison hash value (step SG6). The server control unit 10 derives the comparison hash value using the same method as the terminal control unit 13 uses to derive the state hash value. That is, the server control unit 10 acquires the values ​​of each item in the server-side setting information. Next, the server control unit 10 generates array data based on the values ​​of each item using the same rules as those of the user terminal 3. Next, the server control unit 10 derives a hash value using the same hash function as that of the user terminal 3. The hash value derived here is the comparison hash value. If the values ​​of each item in the terminal-side setting information that formed the basis of the state hash value are the same as the values ​​of each item in the server-side setting information that formed the basis of the comparison hash value, then the state hash value and the comparison hash value will be completely identical.

[0091] Next, the server control unit 10 determines whether the comparison hash value and the state hash value included in the processing log are identical (step SG7). If these values ​​are not identical, it means that the values ​​of one or more items in the terminal-side setting information of the user terminal 3 have deviated from the correct values. Therefore, in this case, it is highly likely that some kind of fraudulent activity has occurred. Therefore, determining whether these values ​​are identical is equivalent to determining on the server 2 whether fraudulent activity has occurred on the user terminal 3. If the comparison hash value and the state hash value are identical (step SG7: YES), the server control unit 10 ends the log response process. On the other hand, if these values ​​are not identical (step SG7: NO), the server control unit 10 executes error processing (step SG8). Error processing will be described later. If error processing is executed, the verification process is interrupted.

[0092] In the following description, when the comparison target hash value and the state hash value are not identical in the log correspondence processing, this may be expressed as a “state mismatch.” Furthermore, the processing shown in steps SG6 and SG7 of deriving the comparison target hash value and comparing it with the state hash value is called a “state comparison processing.”

[0093] Next, the verification process executed by the server control unit 10 in this example will be described. Flowchart FE in FIG. 12 shows details of the verification process executed by the server control unit 10 in this example. In this example, the terminal control unit 13 transmits transmission log data DL including the first to fourth logs LG1 to LG4 (hereinafter referred to as "first transmission log data DL-1") at the first log transmission timing, and transmits transmission log data DL including the fifth and sixth logs LG5 and LG6 (hereinafter referred to as "second transmission log data DL-2") at the second log transmission timing. The first to sixth logs LG1 to LG6 are shown in FIG. 13. Flowchart FE in FIG. 12 shows the verification process in response to the reception of the first transmission log data DL-1 and the verification process in response to the reception of the second transmission log data DL-2.

[0094] As shown in flowchart FE, when the server control unit 10 receives log-related data including the first transmission log data DL-1 (step SE1), it executes a restart process (step SE2). This enables processing based on the server-side node definition data NDs to be executed, and the values ​​of each item in the server-side node-related information are initialized to the values ​​of each item in the currently registered node-related information of the corresponding record in the game management DB. Next, the server control unit 10 executes an initial node transition process to transition the game state of the pseudo bonus game to a standby node (step SE3). In response to the transition to the standby node, the server control unit 10 appropriately updates the values ​​of the server-side setting information.

[0095] Next, the server control unit 10 performs log response processing based on the first log LG1 and issues a card selection event (step SE4). The card selection event issued here corresponds to the card selection event recorded in the log data LD in the transition reproduction information recording processing of the flowchart FD. In response to the occurrence of the card selection event, the server control unit 10 transitions the game state of the pseudo bonus game to a lottery node based on the transition rule J1 of the server-side node definition data NDs (step SE5). In response to the transition to the lottery node, the server control unit 10 updates the value of the server-side setting information. In response to the occurrence of the card selection event, the server control unit 10 further executes a lottery process defined as a transition-time process for the lottery node (step SE6).

[0096] Regarding the lottery processing in step SE6, the server control unit 10 executes the following processing. Specifically, the server control unit 10 inputs the random number seed stored in the random number seed <item> of the server-side node-related information into the server-side random number generator and obtains its output value. The server control unit 10 then determines the card selection result based on the output value, following the same lottery rules as those used by the terminal control unit 13. The server control unit 10 then updates the values ​​of each item of the server-side state variables based on the determined result. The random number generator used by the terminal control unit 13 in the lottery processing in step SD6 of flowchart FD is the same as the random number generator used by the server control unit 10 in the lottery processing in step SE6 of flowchart FE. Furthermore, the random number seed value input by the terminal control unit 13 to the random number generator in the lottery processing is the same as the random number seed value input by the server control unit 10 to the random number generator in the lottery processing. Therefore, the processing result of the lottery processing by the server control unit 10 is always the same as the processing result of the lottery processing by the terminal control unit 13. Therefore, if no fraudulent activity is being committed on the user terminal 3, the value of the server-side state variable at the time when the lottery processing in step SE6 is completed will be the same as the value of the terminal-side state variable at the time when the lottery processing in step SD6 of flowchart FD is completed.

[0097] After processing step SE6, the server control unit 10 executes a state comparison process of the log response process based on the second log LG2 (step SE7). The state comparison process of step SE7 determines whether a comparison target hash value based on the values ​​of each item of the current server-side setting information is the same as the state hash value recorded in the log data LD in step SD7 of flowchart FD. If no fraudulent activity has been performed on the user terminal 3, these values ​​will match. If it is determined in step SE7 that the values ​​are not the same, the server control unit 10 interrupts the verification process and executes error processing.

[0098] After processing step SE7, the server control unit 10 performs log processing based on the third log LG3 and issues a lottery completion event (step SE8). This lottery completion event corresponds to the lottery completion event recorded in the transition reproduction information recording process of step SD9 of flowchart FD. In response to the occurrence of the lottery completion event, the server control unit 10 transitions the game state of the pseudo bonus game to a standby node based on the transition rule J2 of the server-side node definition data NDs (step SE9). In response to the transition of the standby node, the server control unit 10 updates the values ​​of each item of the server-side setting information.

[0099] After processing step SE9, the server control unit 10 executes a state comparison process based on the fourth log LG4 (step SE10). In the state comparison process, it is determined whether a comparison hash value based on the values ​​of each item in the current server-side setting information is identical to the state hash value recorded in the log data LD in step SD11 of flowchart FD. If it is determined in step SE10 that the values ​​are not identical, the server control unit 10 suspends the verification process and executes error processing. After processing step SE10, the server control unit 10 executes a server reflection process (step SE11). As a result of the processing of step SE11, the values ​​of each item in the registered node-related information of the corresponding record in the game management DB become the values ​​of each item in the current server-side node-related information. This completes the verification process based on the first transmission log data DL-1.

[0100] The server control unit 10 then receives log-related data including the second transmission log data DL-2 (step SE12). The server control unit 10 then executes a restart process (step SE13). The process of step SE13 enables processing based on the server-side node definition data NDs. Furthermore, the values ​​of each item in the server-side node-related information are initialized to the values ​​of each item in the currently registered node-related information of the corresponding record in the game management DB. Next, the server control unit 10 executes log-related processing based on the fifth log LG5 and issues an end event (step SE14). This end event corresponds to the end event recorded in the log data LD in step SD14 of the flowchart FD. In response to the occurrence of the end event, the server control unit 10 transitions the game state of the pseudo bonus game to the end node based on the transition rule J3 in the server-side node definition data NDs (step SE15). In response to the transition to the end node, the server control unit 10 updates the values ​​of the server-side setting information. After processing step SE15, the server control unit 10 executes a state comparison process based on the fifth log LG5 (step SE16). After processing step SE16, the server control unit 10 executes a server reflection process (step SE17). By processing step SE17, the values ​​of each item of the registered node related information of the corresponding record in the game management DB become the values ​​of each item of the current server-side node related information. This completes the verification process based on the second transmission log data DL-2.

[0101] As described above, the server control unit 10 reproduces node transitions based on the transition reproduction information in the transmission log data DL received from the user terminal 3 and the node definition data ND of the server 2. Furthermore, the server control unit 10 changes the value of the server-side setting information corresponding to the node definition data ND of the server 2 in response to the node transition, and executes a verification process in which the value of the server-side setting information is compared with the value of the corresponding terminal-side setting information recorded in the transmission log data DL. More specifically, in the verification process, the server control unit 10 generates trigger events in chronological order based on the transition reproduction information recorded in the transmission log data DL, and, in response to the occurrence of the trigger event, automatically transitions the node based on the node definition data of the server. The server control unit 10 dynamically changes the value of the server-side setting information in response to the node transition, and compares the changed value of the server-side setting information with the value of the corresponding terminal-side setting information recorded in the transmission log data. This configuration achieves the following effects. In other words, if the value of the server-side setting information and the value of the corresponding terminal-side setting information recorded in the transmission log data DL are not the same, it means that the value of the terminal-side setting information in the user terminal 3 has deviated from the correct value. Therefore, in this case, it is highly likely that some kind of fraudulent activity has occurred in the user terminal 3. Comparing these values ​​is therefore equivalent to the server 2 determining whether or not fraudulent activity has occurred in the user terminal 3. The above configuration makes it possible to detect fraudulent activity, and, upon detection of fraudulent activity, it is possible to perform processing to prevent or prevent fraudulent activity, or processing to suppress the adverse effects caused by fraudulent activity. This improves resistance to fraudulent activity.

[0102] Next, error processing will be described in detail. In error processing, processing that contributes to preventing / deterring fraudulent activities or processing that suppresses the adverse effects caused by fraudulent activities is executed. In this embodiment, the server control unit 10 executes rollback processing as error processing. In rollback processing, the server control unit 10 creates a state in which the game is resumed from before the stage at which a state hash value (a value of the terminal-side setting information) previously determined to be identical to a comparison hash value (a value of the server-side setting information) was recorded in the log data LD. An example of error processing will be described below using this example.

[0103] Referring to flowchart FE in Figure 12, for example, suppose a status mismatch occurs in the status comparison process of step SE16. In this case, no status mismatch occurs in the status comparison process of step SE10. In this case, it is assumed that the values ​​of one or more items of the terminal-side setting information have been altered by fraudulent activity between the time when the process of step SD11 of flowchart FD was performed and the time when the process of step SD16 was performed. In this case, the server control unit 10 interrupts the verification process and does not execute the server reflection process of step SE17.

[0104] If a status mismatch occurs in step SE16, the server control unit 10 references the corresponding record in the game management DB and acquires the current registered node-related information. The acquired registered node-related information is the information updated in the server reflection process of step SE11. Next, the server control unit 10 transmits the acquired registered node-related information and node definition data ND corresponding to the bonus game to the terminal control unit 13. Furthermore, the server control unit 10 instructs the terminal control unit 13 to resume the bonus game from the stage at which the terminal-side setting information recording process of step SD11 was performed.

[0105] In response to this instruction, the terminal control unit 13 generates an instance based on the received node definition data ND, and initializes the values ​​of each item of the terminal-side node-related information corresponding to the instance based on the received registered node-related information. This initialization updates the value of the current node <item>, and the game state of the bonus game transitions to the node indicated by the current node <item> in the terminal-side setting information (in this example, the standby node). Furthermore, the terminal control unit 13 executes processing corresponding to the value of each item of the terminal-side setting information. In this example, the terminal control unit 13 displays a post-selection screen G2 on the terminal display unit 15. As a result of the above processing, a state is established in which the bonus game is resumed from the stage at which the terminal-side setting information recording processing of step SD11 was performed.

[0106] After the bonus game is resumed, the terminal control unit 13 executes the game progress process in accordance with the process from step SC4 onward in the flowchart FC of Fig. 11, and periodically transmits log-related data. The server control unit 10 executes verification process in response to the receipt of the log-related data.

[0107] As described above, in this embodiment, if a status inconsistency occurs in the log response process, the bonus game is resumed from a point where there is no influence from the fraudulent behavior. With this configuration, even if a fraudulent behavior is performed, the adverse effects of the fraudulent behavior can be suppressed. Furthermore, a user who has performed a fraudulent behavior can be made aware that even if they perform a fraudulent behavior, they will not be able to enjoy the benefits of the fraudulent behavior, thereby discouraging users from performing fraudulent behavior. Note that for users who do not perform a fraudulent behavior, the rollback process is not performed while the bonus game is being performed, and the game progresses smoothly. Therefore, the satisfaction of users who do not perform a fraudulent behavior does not decrease.

[0108] <Modification> Next, a modification of the above embodiment will be described. In this modification, the management information includes an item of random number usage history information. FIG. 16 is a diagram schematically illustrating the contents of the random number usage history information. The random number usage history information includes a random number category ID (<item>) and a random number usage count (<item>) for each random number category that can be used in the unit game. Random number categories are described below. The random number category ID (<item>) stores the random number category ID, which is identification information for the random number category. The random number usage count (<item>) stores the random number usage count, which indicates the number of times a random number has been used in the corresponding random number category. The initial value of the random number usage count is 0. The first record in FIG. 16 indicates that a random number was used three times in the random number category with random number category ID: R01. The terminal-side setting information includes the number of times random numbers by category used by the terminal control unit 13 in the unit game. The server-side setting information includes the number of times random numbers by category used by the server control unit 10 in the verification process.

[0109] In this modified example, the terminal control unit 13 executes the following process in the game progression process. Flowchart FH in FIG. 17 illustrates the portion of the game progression process executed by the terminal control unit 13 that is related to the random number processing. In the following description, it is assumed that a unit game has a first stage, a second stage, and a third stage. Furthermore, it is assumed that the random number category ID "R01" is assigned to the first stage, "R02" is assigned to the second stage, and "R03" is assigned to the third stage. As mentioned above, the transition process includes a process that uses random numbers. Hereinafter, the process that uses random numbers is referred to as the "random number processing." Random number processing P1a to P1c is executed in the first stage, random number processing P2a and P2b is executed in the second stage, and random number processing P3a and P3b is executed in the third stage. In the description using FIG. 17, it is assumed that the random number generator outputs integers in the range of 0 to 3. Although not specifically described, the random number processing is executed in response to node transitions.

[0110] As shown in the flowchart FH of FIG. 17 , when the terminal control unit 13 executes the random number use process P1a in the first stage, it specifies the random number category ID: R01 (category) corresponding to the first stage. This specification is performed, for example, by passing the random number category ID: R01 as a parameter to a function that generates a random number. Next, the terminal control unit 13 changes the value of the random number seed according to the specified random number category ID (category). As described in the above embodiment, the random number seed is received from the server 2. The rule for changing the random number seed is that, when the random number seed is the same, if the category ID is different, the value of the changed random number seed will be different, and if the category ID is the same, the value of the changed random number seed will be the same. For example, this rule is that a value corresponding to the category ID is added to the value of the random number seed. Hereinafter, the changed random number seed will be referred to as the "changed random number seed."

[0111] Next, the terminal control unit 13 inputs the changed random number seed into the terminal-side random number generator and obtains its output. Figure 17 shows that the output of the terminal-side random number generator in the random number use process P1a was 3. Furthermore, the terminal control unit 13 increments the value of the random number usage count corresponding to the random number category ID: R01 in the random number usage history information of the terminal-side setting information. Thereafter, in the first stage, when the terminal control unit 13 executes the random number use process, it sequentially uses (consumes) the output values ​​consecutively output by the terminal random number generator, which inputs the changed random number seed corresponding to the category ID: R01. The terminal control unit 13 also increments the value of the corresponding random number usage count according to the use of the random number. As described above, the random number generator is a recurrence formula, and when a specific value is input, the pattern of consecutive output values ​​becomes a specific pattern. Figure 17 shows how random number: 0 is used in the random number use process P1b and random number: 1 is used in the random number use process P1c in the first stage.

[0112] After the random number usage process P1c, the terminal control unit 13 executes the first terminal side setting information recording process. At this point, the random number usage counts corresponding to the random number category IDs R01, R02, and R03 are 3, 0, and 0, respectively.

[0113] In the second stage following the first stage, the terminal control unit 13 executes the following process. Specifically, in the random number use process P2a, the terminal control unit 13 specifies the random number category ID: R02 and generates a changed random number seed according to the specified random number category ID. The terminal control unit 13 inputs the changed random number seed into the terminal-side random number generator and obtains an output value (random number). In the random number use process P2b following the random number use process P2a, the terminal control unit 13 obtains the next output value (random number) output by the terminal random number generator that receives the changed random number seed corresponding to the random number category ID: R02 as input. The terminal control unit 13 increments the value of the corresponding random number usage count according to the use of the random number. FIG. 17 illustrates the situation in which the random number: 1 is used in the random number use process P2a and the random number: 0 is used in the random number use process P2b in the second stage. After the random number use process P2b, the terminal control unit 13 executes the second-terminal-side setting information recording process. At this point, the number of times that random numbers have been used corresponding to the random number category IDs R01, R02, and R03 are 3, 2, and 0, respectively.

[0114] For the third stage following the second stage, the terminal control unit 13 executes the same processing as for the first and second stages. Figure 17 shows how random number: 3 is used in random number use process P3a and random number: 2 is used in random number use process P3b in the third stage. After random number use process P3b is executed, the terminal control unit 13 executes third terminal side setting information recording processing. At this point, the random number usage counts corresponding to random number category IDs: R01, R02, and R03 are 3, 2, and 2, respectively.

[0115] As described above, in this embodiment, when executing a process that uses random numbers in response to node transitions, the terminal control unit 13 specifies a category, changes the value of the random number seed in response to the specified category, and executes the process using the changed random number seed and the random number generator stored in the terminal. This provides the following advantages. Specifically, if output values ​​(random numbers) continuously output by the terminal-side random number generator based on a single random number seed are used in a unit game, the predictability of the random numbers increases and so-called random number adjustment becomes easier. On the other hand, by providing multiple categories in a unit game and using independent random number seeds for each category, the correlation between random numbers can be eliminated for each category in the unit game, reducing the predictability of random numbers and making random number adjustment easier.

[0116] Next, the operation of the server 2 in this modified example will be described. Flowchart FI in FIG. 17 shows an example of the operation of the server 2 when the user terminal 3 executes the process of flowchart FH. In particular, flowchart FI shows an example of the operation of the server 2 in the verification process. As shown in flowchart FI, the server control unit 10 executes random number processes Q1a, Q1b, and Q1c in response to node transitions during the verification process. These random number processes Q1a, Q1b, and Q1c correspond to the random number processes P1a, P1b, and P1c executed by the terminal control unit 13 in flowchart FH. In random number process Q1a, the terminal control unit 13 specifies random number category ID: R01 and generates a changed random number seed according to the random number category ID: R01, following the same rules as those of the user terminal 3. The terminal control unit 13 then inputs the changed random number seed into the server-side random number generator and obtains its output value (random number). Because the server-side random number generator and the terminal-side random number generator are the same, the random number value used in the random number-using process Q1a related to the server 2 always matches the random number value used in the random number-using process P1a related to the user terminal 3. Thereafter, the server control unit 10 sequentially uses (consumes) the output values ​​successively output by the server-side random number generator in the random number-using processes Q1b and Q1c based on the changed random number seed corresponding to category ID: R01. As a result, the random number value used in the random number-using processes Q1b and Q1c related to the server 2 and the random number value used in the random number-using processes P1b and P1c related to the user terminal 3 are the same.

[0117] Furthermore, the server control unit 10 executes a first state comparison process after the random number usage process Q1c. In this first state comparison process, the values ​​of the random number usage counts in the random number usage history information that forms the basis of the comparison target hash value are as follows: Random number category ID: R01 → 3 times, R02 → 0 times, R03 → 0 times. This matches the value of the random number usage counts in the random number usage history information that formed the basis of the state hash value in the first terminal side setting information recording process. Therefore, if no fraudulent activity is occurring, no state mismatch occurs in the first state comparison process.

[0118] The random number processes Q2a and Q2b in flowchart FI correspond to the random number processes P2a and P2b executed by the terminal control unit 13 in flowchart FH. For the random number processes Q2a and Q2b, the server control unit 10 sequentially uses (consumes) the output values ​​successively output by the server-side random number generator based on the changed random number seed corresponding to category ID: R02. After the random number process Q2b, the server control unit 10 executes a second state comparison process. In this second state comparison process, for the same reason as in the first state comparison process, a state mismatch does not occur if no fraudulent activity is occurring. Furthermore, the random number processes Q3a and Q3b in flowchart FI correspond to the random number processes P3a and P3b executed by the terminal control unit 13 in flowchart FH. For the random number processes Q3a and Q3b, the server control unit 10 sequentially uses (consumes) the output values ​​successively output by the server-side random number generator based on the changed random number seed corresponding to category ID: R03. As a result, the random number values ​​used in the random number processes Q3a and Q3b related to the server 2 are the same as the random number values ​​used in the random number processes P3a and P3b related to the user terminal 3. Furthermore, in the third state comparison process following the random number process Q3b, for the same reason as in the first state comparison process, no state mismatch occurs if no fraudulent activity is being performed.

[0119] As described above, when the server control unit 10 executes a process that uses random numbers in accordance with node transitions during verification processing, it specifies the same category as the category specified by the terminal control unit 13 in the corresponding processing performed on the user terminal 3, changes the value of the random number seed in accordance with the specified category, and executes the processing using the random number seed after the value has been changed and the random number generator of the server 2.

[0120] Although one embodiment of the present invention has been described above, the above embodiment is merely an example of a specific embodiment for carrying out the present invention, and the technical scope of the present invention should not be interpreted as being limited thereby. In other words, the present invention can be carried out in various forms without departing from the gist or main characteristics thereof.

[0121] For example, in the above embodiment, the log transmission condition is that a periodic timing has arrived. However, the content of the log transmission condition is not limited to the content exemplified in the above embodiment. As an example, the condition may be that a certain number of logs LG have been recorded in the log data LD. In this case, the certain number may be one, or two or more.

[0122] In the above embodiment, the terminal control unit 13 is configured to transmit transmission log data DL including untransmitted logs recorded in the log data LD when the log transmission condition is met. In this regard, the terminal control unit 13 may be configured to transmit transmission log data DL including all logs LG recorded in the log data LD. In this configuration, the server control unit 10 may extract unprocessed logs LG and perform log handling processing each time it receives transmission log data DL. Furthermore, the server control unit 10 may perform log handling processing for all logs LG each time it receives transmission log data DL.

[0123] In the above embodiment, the terminal control unit 13 recorded a state hash value, which is a hash value, in the log data LD. In this regard, the terminal control unit 13 may be configured to record the value of the terminal-side setting information (an unhashed value) in the log data LD according to a format, rather than the state hash value. In this case, the log LG of the transmission log data LS includes the value of the terminal-side setting information (an unhashed value) instead of the state hash value. In this configuration, the server control unit 10 determines whether the value of the server-side setting information in the server-side node definition data NDs and the value of the corresponding terminal-side setting information in the transmission log data DL are the same in the state comparison process, without deriving a comparison target hash value.

[0124] Furthermore, the error processing executed by the server control unit 10 is not limited to the processing exemplified in the above embodiment. For example, the server control unit 10 may be configured to execute the following processing. For example, the server control unit 10 may be configured to execute the error processing by establishing a state in which the unit game is restarted from the beginning. In this case, the server control unit 10 discards the game management DB record corresponding to the unit game to be restarted and executes the processing from step SB1 onward in the flowchart FB of FIG. 8 again. Furthermore, for example, the server control unit 10 may be configured to notify the user of a predetermined warning in cooperation with the terminal control unit 13. Furthermore, for example, the server control unit 10 may be configured to register a user who has engaged in fraudulent behavior in a list. In other words, the processing executed by the server control unit 10 when a status mismatch occurs may be processing that contributes to preventing or preventing fraudulent behavior or processing that suppresses the adverse effects caused by fraudulent behavior.

[0125] In the above embodiment, the server control unit 10 is configured to transmit the random number seed together with the node definition data ND to the terminal control unit 13. However, if random numbers are not used in the unit game, the terminal control unit 13 may be configured not to transmit the random number seed.

[0126] Furthermore, the contents of the log LG are not limited to the contents exemplified in the above embodiment. In particular, in the above embodiment, the transition reproduction information was information indicating the contents of an event (trigger event), but the contents of the transition reproduction information are not limited to the exemplified contents. For example, the transition reproduction information may be information identifying a transition rule referenced for node transition. Furthermore, for example, if a node transition is configured to be possible based on an event other than an event, the transition reproduction information may be information indicating an event that triggered the node transition. In other words, the transition reproduction information may be information that the server control unit 10 can use when reproducing the node transition in the verification process.

[0127] In the above embodiment, the transition rules are recorded in the node definition data. However, the transition rules may not be recorded in the node definition data. For example, the transition rules may be recorded in a file separate from the node definition data ND. In this case, the combination of the node definition data ND file and the file in which the transition rules are recorded may be considered to be "node definition data." Alternatively, the transition rules for a unit game may be defined in a program used by the server control unit 10 (a program separate from the program related to the node definition data), and the transition rules that are the same as the transition rules for the server 2 may be defined in a program used by the terminal control unit 13 (e.g., the game application AP). In other words, it is sufficient that the server control unit 10 and the terminal control unit 13 use the same transition rules for the unit game.

[0128] Furthermore, in this embodiment, before the provision of a unit game, a state (hereinafter referred to as a "shared state") is established in which the server 2 and the user terminal 3 can each use the common node definition data ND corresponding to the unit game. The method for establishing the shared state is not limited to the method exemplified in this embodiment. For example, a configuration may be adopted in which, for one unit game, the node definition data ND is uploaded to the server 2 and the node definition data ND is incorporated into the game application AP. In this configuration, the content of the node definition data ND on the user terminal 3 side may be modified (updated) by updating the game application AP. In this configuration, the node definition data ND may not be incorporated into the game application AP from the beginning, but may be incorporated later as additional data. Alternatively, for example, the node definition data ND stored on a CD-ROM, USB memory, or other physical medium may be downloaded to the user terminal 3, thereby establishing the shared state. In other words, any means for establishing the shared state may be used, as long as a state in which the server 2 and the user terminal 3 can each use the common node definition data ND corresponding to the unit game is established before the provision of the unit game. Note that "the node definition data ND used by the server 2 and the node definition data ND used by the user terminal 3 are common" does not mean that the node definition data ND related to the server 2 and the node definition data ND related to the user terminal 3 are completely identical, including in terms of format. In other words, these data being common means that when processing is executed based on the node definition data ND, nodes transition in the same manner, processing is performed in the same manner, and setting information is updated in the same manner, so long as no fraudulent activity is performed.

[0129] In the above embodiment, the game provided by the user terminal 3 and the server 2 is provided by a dedicated application downloaded to the user terminal 3. However, the game is not limited to the game exemplified in the above embodiment. For example, the game may be an online game played using a browser.

[0130] As described above, the node definition data ND may be data in which information is described using JSON or other description methods, rather than a program file. In other words, the node definition data ND may be data in which nodes are described in a format usable by the terminal control unit 13 and the server control unit 10. For example, the node definition data ND may be text data in which information is described according to a predetermined data format. Furthermore, for each item (or even some items) of the setting information in the node definition data ND, the item name and item value are associated and described in text in the text data constituting the node definition data ND. In this configuration, the terminal control unit 13 (and the server control unit 10 as well) appropriately references the text data constituting the node definition data ND and executes node transitions and processing associated with the node transitions. Furthermore, the terminal control unit 13 appropriately updates the item values ​​recorded in the text data to update the setting information values.

[0131] In the above embodiment, specific examples of terminal-side setting information are provided. Here, the terminal-side setting information refers to information to be compared with the terminal-side setting information in the state comparison process. In the above embodiment, the combination of items that form the basis of the state hash value corresponds to the terminal-side setting information. The form of the terminal-side setting information is not limited to the form exemplified in the above embodiment. For example, the terminal-side setting information may be configured to include some state variables of the terminal-side state variables or some items of the terminal-side management information. Furthermore, the terminal-side setting information may be configured to include either the setting information or the management information. In other words, the terminal-side setting information may be information whose value can change in response to node transitions as the unit game progresses. The items of the server-side setting information to be compared in the state comparison process are appropriately selected depending on the items of the terminal-side setting information.

[0132] The contents of the node-related information are not limited to those exemplified in the above embodiment. For example, the node-related information may include a user ID or the version of the node definition data ND.

[0133] In the above embodiment, some or all of the processing that is executed by the functions of the game application AP may be executed by a browser.

[0134] In the above embodiment, the server storage unit 12 may be configured to store the data management DB and the game management DB.

[0135] The functional blocks shown in the above embodiments can be realized by any hardware or by a combination of any hardware and any software, and are not limited to specific hardware.

[0136] Furthermore, the processing units in the flowcharts of the above embodiments are divided according to the main processing content in order to make the processing easier to understand. The method of dividing the processing units or the names of the processing units does not limit the present invention. The processing of each device can be divided into more processing units according to the processing content. Furthermore, one processing unit can be divided so that it includes even more processing. Furthermore, the processing order of the above flowcharts is not limited to the example shown in the figures, as long as similar processing can be performed.

[0137] Furthermore, for example, the provision of a program executed by a computer of the server 2 or the user terminal 3 can be included in the embodiments. Furthermore, the provision of a recording medium on which the program is recorded in a computer-readable manner can be included in the embodiments. Examples of the recording medium include a flexible disk, a hard disk drive (HDD), a compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a Blu-ray Disc (registered trademark), a magneto-optical disk, a flash memory, and a card-type recording medium.

[0138] REFERENCE SIGNS LIST 1 Control system 2 Server 3 User terminal (terminal) 10 Server control unit 13 Terminal control unit LD Log data LG Log ND Node definition data DL Transmission log data

Claims

1. A control system that includes a server and a terminal capable of communicating with the server and provides a game. Before providing the game, a state is constructed in which each of the server and the terminal can use common node definition data corresponding to the game. A plurality of nodes indicating the state of the game are defined in the node definition data. The terminal, while the game is being played by the user, transitions the nodes based on the node definition data of the terminal, changes the value of the terminal-side setting information corresponding to the node definition data of the terminal according to the transition of the nodes, and has a function of recording, as a log, the transition reproduction information capable of reproducing the transition of the nodes and the value of the terminal-side setting information changed according to the transition of the nodes in log data. The terminal control unit has a function of transmitting, to the server, the transmission log data including the log recorded in the log data when the log transmission condition regarding the transmission of the log is satisfied. The server, based on the transition reproduction information in the transmission log data received from the terminal and the node definition data of the server, reproduces the transition of the nodes, changes the value of the server-side setting information corresponding to the node definition data of the server according to the transition of the nodes, and has a server control unit having a function of executing a verification process of comparing the value of the server-side setting information with the corresponding value of the terminal-side setting information recorded in the transmission log data. A control system characterized by the above.

2. The node definition data further defines a transition rule in which a trigger event that triggers the transition of the node and a mode of the transition of the node when the trigger event occurs are defined. The terminal control unit, while the game is being played by the user, in response to the occurrence of the trigger event, transitions the node based on the transition rule of the node definition data of the terminal, and changes the value of the terminal-side setting information in response to the transition of the node. At the same time, the transition reproduction information indicating the content of the occurred trigger event is recorded in the log data as the log, and the value of the terminal-side setting information changed in response to the transition of the node is recorded in the log data as the log. The server control unit, in the verification process, based on the transition reproduction information recorded in the transmission log data, generates the trigger event in chronological order, and in response to the occurrence of the trigger event, transitions the node based on the node definition data of the server, and changes the value of the server-side setting information in response to the transition of the node. At the same time, the value of the server-side setting information after the change is compared with the corresponding value of the terminal-side setting information recorded in the transmission log data. The control system according to claim 1, characterized in that.

3. The node definition data can define a state variable indicating the state of a predetermined matter related to the game and a transition-time process that is a process executed when the self-node is transitioned. The transition-time process includes a process of changing the state variable. The terminal-side setting information includes the state variable defined in the node definition data of the terminal. The server-side setting information includes the state variable defined in the node definition data of the server. The control system according to claim 1, characterized in that.

4. The terminal control unit records, in the log data, a state hash value, which is a hash value of the value of the terminal-side setting information, as the value of the terminal-side setting information. The server control unit derives, in the verification process, a comparison target hash value, which is a hash value of the value of the server-side setting information, according to the transition of the node, and compares the comparison target hash value with the corresponding state hash value recorded in the transmission log data. The control system according to claim 1, characterized in that.

5. Each of the server and the terminal can use a common random number generator. The server control unit generates a random number seed and transmits it to the terminal. When executing a process that uses a random number according to the transition of the node in the verification process, the server control unit executes the process using the generated random number seed and the random number generator of the server. The terminal control unit, when executing a process that uses a random number according to the transition of the node, executes the process using the random number seed received from the server and the random number generator of the terminal. The control system according to claim 1, characterized in that.

6. When the terminal control unit executes a process that uses a random number according to the transition of the node, it designates a category, changes the value of the random number seed according to the designated category, and executes the process using the changed random number seed and the random number generator of the terminal. In the verification process, when the server control unit executes a process that uses a random number according to the transition of the node, it designates the same category as the category designated by the terminal control unit in the corresponding process performed on the terminal, changes the value of the random number seed according to the designated category, and executes the process using the changed random number seed and the random number generator of the server. The control system according to claim 5, characterized in that.

7. The terminal-side setting information includes the number of times of using random numbers by category by the terminal control unit in the game. The server-side setting information includes the number of times of using random numbers by category by the server control unit in the verification process. The control system according to claim 6, characterized in that.

8. In the verification process, when the server control unit determines that the values are not the same as a result of comparing each value according to the transition of the node, it constructs a state in which the game resumes from a point before the value of the terminal-side setting information determined to be the same as the value of the server-side setting information in the past was recorded in the log data, or constructs a state in which the game resumes from the beginning. The control system according to claim 1, characterized in that.

9. The log transmission condition is a condition that a timing that occurs regularly has arrived, or a condition that a certain number of the logs have been recorded in the log data. The control system according to claim 1, characterized in that.

10. A server that is communicable with a terminal and provides a game in cooperation with the terminal. Before providing the game, a state is constructed in which each of the server and the terminal can use common node definition data corresponding to the game. A plurality of nodes indicating the state of the game are defined in the node definition data. Receiving, from the terminal, transmission log data including a log indicating transition reproduction information capable of reproducing the transition of the node performed at the terminal and a log indicating a value of terminal-side setting information corresponding to the node definition data of the terminal that has changed according to the transition of the node, reproducing the transition of the node based on the transition reproduction information of the received transmission log data and the node definition data of the server, changing the value of server-side setting information corresponding to the node definition data of the server according to the transition of the node, and comparing the value of the server-side setting information with the corresponding value of the terminal-side setting information recorded in the transmission log data. The server is provided with a server control unit having a function of executing a verification process.

11. A control method by a control system that includes a server and a terminal capable of communicating with the server and provides a game. Before providing the game, a state is constructed in which each of the server and the terminal can use common node definition data corresponding to the game. A plurality of nodes indicating the state of the game are defined in the node definition data. While the game is being played by the user on the terminal, the terminal transitions the nodes based on the node definition data of the terminal, and changes the value of the terminal-side setting information corresponding to the node definition data of the terminal according to the transition of the nodes. At the same time, the terminal records, as a log, the transition reproduction information capable of reproducing the transition of the nodes and the value of the terminal-side setting information that has changed according to the transition of the nodes in log data. When the log transmission condition regarding the transmission of the log is satisfied by the terminal, the terminal transmits the transmission log data including the log recorded in the log data to the server. The server reproduces the transition of the nodes based on the transition reproduction information of the transmission log data received from the terminal and the node definition data of the server, changes the value of the server-side setting information corresponding to the node definition data of the server according to the transition of the nodes, and executes a verification process of comparing the value of the server-side setting information with the corresponding value of the terminal-side setting information recorded in the transmission log data. A control method characterized by the above.

Images