JP7680686B2 - COMPUTER SYSTEM AND METHOD FOR MANAGING GAME RESULTS - Patent application - Google Patents

Description

The present invention relates to a computer system and a method for managing game results.

A computer system that allows spectators to watch a game tournament is known (see, for example, Patent Document 1). Patent Document 1 discloses a video distribution service that distributes video data of games as the game tournament progresses.

Patent No. 6522209

In the example of the above patent document, the game results are not managed, and it is difficult to track the game results after the match has ended.

The purpose of this disclosure is to enable management of the results of games played via a computer.

A first aspect is a computer system for managing the results of a game played via a computer, comprising:
a recorder that records transaction information, which is information linking information on a game result of the game with information identifying a player corresponding to the information on the game result, in a distributed ledger ;
a selling unit for managing the sale by the player of the game results corresponding to the transaction information;
The game result is a win or loss in the game, or an evaluation based on an index in the game.
The present invention relates to a computer system.

A second aspect is a computer system for managing the results of a game played via a computer, comprising:
a recorder that records transaction information, which is information linking information on a game result of the game with information identifying a player corresponding to the information on the game result, in a distributed ledger;
an operation unit to which an operator that transmits a signal to the game device is connected;
The game result includes a win or loss in the game that occurs when the player operates a character with the controller, and information about the controller used in the game.
The present invention relates to a computer system.

A third aspect is a computer system for managing the results of a game played via a computer, comprising:
a recorder that records transaction information, which is information linking information on a game result of the game with information identifying a player corresponding to the information on the game result, in a distributed ledger;
an authentication unit that receives a result of an assessor's assessment of legitimacy of the game result determined by the game program;
the authentication unit certifies the game result whose legitimacy has been authenticated by the adjudicator as a legitimate result;
The recording unit records information linking information on the game result authenticated by the authentication unit as authentic with information identifying a player corresponding to the authenticated information on the game result in the distributed ledger as the transaction information.
The present invention relates to a computer system.

In the above aspect, a transfer unit is provided that transfers the transaction information before it is recorded in the distributed ledger to a predetermined transfer destination via a communication network,
The transfer unit may transfer the transaction information including information for identifying a transfer source and a transfer destination.

In the above aspect, the transaction information may include data indicating rights obtained in association with the game result .

In the above aspect, an intermediary unit may be provided that mediates between the transfer source and the transfer destination of the transaction information.

In the above aspect, a notification unit may be provided that notifies at least one of the transfer source and the transfer destination of a request for payment of a fee when the intermediation is established .

In the above aspect, the information on the game result may include information specifying the tournament in which the game was played.

A fourth aspect is a method for managing game results carried out via a computer, comprising:
a recording step of recording transaction information, which is information linking information on a game result of the game with information for identifying a player corresponding to the information on the game result, in a distributed ledger ;
a listing step for managing a sale by the player of a game result corresponding to the transaction information;
The game result is a win or loss in the game, or an evaluation based on an index in the game.
The method for managing game results is characterized by the above .

A fifth aspect is a method for managing game results carried out via a computer, comprising:
a recording step of recording transaction information, the transaction information being information linking information of a game result of the game with information identifying a player corresponding to the information of the game result, in a distributed ledger;
In the game, a controller is used to send a signal to a game device,
The game result includes a win or loss in the game that occurs when the player operates a character with the controller, and information about the controller used in the game.
The method for managing game results is characterized by the above.

A sixth aspect is a method for managing game results carried out via a computer, comprising:
a recording step of recording transaction information, the transaction information being information linking game result information of the game with information identifying a player corresponding to the game result information, in a distributed ledger;
The information on the game result includes a win or loss in the game or an evaluation result regarding the player,
an authentication step of accepting a judgment result by an assessor as to the legitimacy of the game result determined by the game program;
In the authentication step, the game result whose legitimacy has been authenticated by the adjudicator is authenticated as a legitimate result;
In the recording step, information that links information on the game result authenticated as valid in the authentication step with information that identifies a player corresponding to the authenticated information on the game result is recorded in the distributed ledger as the transaction information.
The method for managing game results is characterized by the above.

The present invention allows the results of games played via a computer to be managed.

1 is a block diagram showing a configuration of a game system according to a first embodiment. FIG. 2 is a block diagram showing a configuration of a server device. FIG. 2 is a block diagram showing the configuration of the game device. FIG. 2 is a block diagram showing the configuration of each terminal. An example of a game image is shown. 2 is a block diagram showing the functions of the control unit in the referee terminal. 2 is a block diagram showing the functions of a control unit in the player terminal. 2 is a block diagram showing the functions of a control unit in the purchaser terminal. The flowchart for conducting a match is shown below. 1 shows a flowchart for determining the result of a match. 13 shows a flowchart of match result tokenization. 1 shows a flowchart of a token transaction. FIG. 11 is a block diagram showing a configuration of a server device 2 in a second embodiment.

The computer system and the method for managing game results according to the present disclosure will be described below with reference to the drawings. The computer system according to the present disclosure is realized as a game system. The method for managing game results according to the present disclosure is implemented as a function of the game system.

In the following explanation, a "game" refers to an activity in which some objective is achieved according to certain rules, and which is carried out using a computer. The game may involve multiple participants competing against each other (where a winner is determined), or each participant may be evaluated based on some indicator, such as points or time. Participants here include both individuals and teams.

In addition, in the following explanation, "game results" includes all information related to the game (examples of which will be given later).

In particular, in competitive games in which participants compete against each other, the participants may be called "opponents." Also, the "game result" of a competitive game may be called the "match result."

[Embodiment 1]
Game System Overview
1 is a block diagram showing a configuration of a game system according to a first embodiment. The game system 1 is used, for example, to manage an e-sports (electric sports) tournament. In a game in the game system 1, a player character is operated by a game player to move in a three-dimensional virtual game space (hereinafter, simply referred to as a virtual space) and to perform various actions on the player character's companions.

The game described in this embodiment is a fighting action game in which a player character battles other player characters or non-player characters in a virtual space. More specifically, the game in this embodiment is a so-called fighting game.

In the fighting game of this embodiment, two game players compete one-on-one. In the battle, each game player selects and controls a character (player character). In the battle, the winner is determined when the vitality value of one of the characters reaches 0, for example.

In the e-sports tournament of this embodiment, the winner of the tournament is determined, for example, by a tournament format. In other words, in the e-sports tournament, the pairing of competing players is determined by the result of one match. In the e-sports tournament exemplified in this embodiment, a referee will determine whether or not a player has cheated.

Hardware Configuration
<overview>
The game system 1 includes a server device 2, a referee terminal 4, game devices 5, and an authentication device 7. The server device 2 is configured to be able to communicate with the referee terminal 4, the game devices 5, and the authentication device 7 via a communication network 6.

The purchaser terminal 10 in FIG. 1 is a terminal of a person who wishes to purchase rights to a match (described later). The game system 1 may communicate with the purchaser terminal 10 via the communication network 6.

A player's terminal (hereinafter, player terminal 3) may be connected to the game system 1 via a communication network 6. In the example of FIG. 1, two player terminals 3 are connected to the game system 1. In the following, components that exist in multiples, such as player terminals 3, will be distinguished by adding sub-numbers to their reference symbols as necessary (e.g., 3-1, 3-2, etc., hereinafter the same).

The player terminal 3 is used for trading rights for battles (described later), etc. The player terminal 3-1 is the terminal used by the player P1. The player terminal 3-2 is the terminal used by the player P2.

The server device 2 manages the so-called e-sports tournament. The server device 2 stores game programs and game data. The server device 2 manages the game data of the game device 5. The server device 2 stores various programs and data for managing the e-sports tournament.

The game device 5 executes a game (here, a competitive action game) based on operations by game players. In this embodiment, one game device 5 is configured to accept operations from a pair of players (two players in this example).

The game device 5 may be a commercially available device such as a personal computer, PlayStation (registered trademark), Xbox (registered trademark), PlayStation Vita (registered trademark), or Nintendo Switch (registered trademark).

The game device 5 may receive (download) a game program and game data from the server device 2 via the communication network 6. Upon receiving the game program, etc., the game device 5 installs the received game program, etc.

The game device 5 starts a battle in a competitive action game based on the operations of each player (hereinafter, players P1 and P2). The game device 5 progresses the game while outputting game images and sounds to a display 61 and a speaker 62 (both of which will be described later) based on the operations of each player.

When the match ends, the game device 5 transmits result information indicating the result of the match to the server device 2. The result information includes, for example, information about the stage of the match (information about the first round, the final round, etc.) and information identifying the winner of the match.

<Configuration of Server Device 2>
Fig. 2 is a block diagram showing the configuration of the server device 2. As shown in Fig. 2, the server device 2 includes a network interface 21, a storage unit 22, and a control unit 23. The network interface 21 and the storage unit 22 are electrically connected to the control unit 23 via a bus 29.

The network interface 21 is communicatively connected to the game device 5 etc. via a communication network 6 such as the Internet or a LAN.

The storage unit 22 is composed of a HDD, SSD, RAM, ROM, etc. The storage unit 22 stores game data and various programs including a part of the game program according to this embodiment. The storage unit 22 stores, for example, ID information of players P1 and P2 and ID information of the referee.

The control unit 23 controls the operation of the server device 2. The control unit 23 includes a CPU (microcomputer) and a semiconductor memory (not shown). The semiconductor memory stores programs for operating the CPU, etc.

<Configuration of Game Device 5>
Fig. 3 is a block diagram showing the configuration of the game device 5. As shown in Fig. 3, a display 61, a speaker 62, and a controller 63 are externally connected or built into the game device 5. The game device 5 is provided with two displays 61 (displays 61-1, 61-2). The game device 5 is also provided with two controllers 63 (controllers 63-1, 63-2).

Display 61-1 and controller 63-1 are used by player P1. Display 61-2 and controller 63-2 are used by player P2. Controller 63 may be prepared by players P1 and P2 themselves and connected instead of the controller provided as standard in game system 1.

The game device 5 has a network interface 51, a graphics processing unit 52, an audio processing unit 53, an operation unit 54, a memory unit 55, and a control unit 56. The network interface 51, the graphics processing unit 52, the audio processing unit 53, the operation unit 54, and the memory unit 55 are electrically connected to the control unit 56 via a bus 59.

The network interface 51 is communicatively connected to the communication network 6 to transmit and receive various data between the game device 5 and the server device 2.

The graphics processing unit 52 renders game images including various objects related to the virtual space in a moving image format according to the game image information output from the control unit 56. The graphics processing unit 52 is connected to displays 61 (61-1, 61-2), which may be, for example, liquid crystal displays. The game images rendered in a moving image format are displayed on the display 61 as a game screen.

The audio processing unit 53 is connected to the speaker 62. The audio processing unit 53 plays and synthesizes game sounds according to the instructions of the control unit 56, and outputs them from the speaker 62.

The operation unit 54 is connected to the controllers 63 (63-1, 63-2). The operation unit 54 transmits and receives data related to operation inputs to and from the controllers 63. The players P1 and P2 input operation signals to the game device 5 by operating various controls such as buttons on the controllers 63.

The storage unit 55 is composed of a HDD, SSD, RAM, ROM, etc. The storage unit 55 stores game data downloaded from the server device 2, various programs including parts of the game program, etc.

The control unit 56 controls the operation of the game device 5. The control unit 56 includes a CPU (microcomputer) and a semiconductor memory (not shown). The semiconductor memory stores programs for operating the CPU, etc.

<Configuration of authentication device 7>
The authentication device 7 performs identity authentication for the players P1 and P2. The authentication device 7 includes a code reader 71 (see FIG. 1). The code reader 71 includes a function for reading a QR code (registered trademark).

In this embodiment, when players P1 and P2 enter the tournament, they are each given a QR code (registered trademark) that indicates that they are a tournament participant (player). As an example, the QR code (registered trademark) can be distributed by transmitting it to the player terminal 3 owned by players P1 and P2 via the communication network 6.

The code reader 71 reads the QR code that the players P1 and P2 hold over the code reader 71. The authentication device 7 transmits information associated with the QR code read by the code reader 71 to the server device 2.

The server device 2 transfers the verification result of the information accompanying the QR code sent from the code reader 71 (information as to whether the player is a legitimate player or not) to the referee's terminal (referee terminal 4). This allows the referee to verify the identity of players P1 and P2.

<Configuration of various terminals>
As described above, the game system 1 is provided with the judge terminal 4. In addition, the game system 1 is connected with the player terminals 3 and the purchaser terminal 10.

In this embodiment, for ease of explanation, it is assumed that terminals 3, 4, and 10 have the same hardware configuration. For example, each terminal 3, 4, and 10 can be configured by installing specific software on a smartphone.

Figure 4 is a block diagram showing the configuration of terminals 3, 4, and 10. As shown in Figure 4, terminals 3, 4, and 10 each have a built-in display 91, speaker 92, and touch pad 93.

The terminals 3, 4, and 10 each have a network interface 81, a graphics processing unit 82, an audio processing unit 83, an operation unit 84, and a memory unit 85. The network interface 81, the graphics processing unit 82, the audio processing unit 83, the operation unit 84, and the memory unit 85 are electrically connected to the control unit 86 via a bus 87.

The network interface 81 is communicatively connected to the communication network 6 to transmit and receive various data. This enables each of the terminals 3, 4, and 10 to communicate with the server device 2.

The graphics processing unit 82 is connected to the display 91. The graphics processing unit 82 displays various images on the display 91 according to the image information output from the control unit 86.

The audio processing unit 83 is connected to the speaker 92. The audio processing unit 83 outputs (plays) audio from the speaker 92 according to the audio information output from the control unit 86.

The operation unit 84 is connected to the touchpad 93. An operation signal from a user (e.g., player P1) is input to the operation unit 84 via the touchpad 93. By operating the touchpad 93, the user can execute various programs stored in the storage unit 85. By operating the touchpad 93, the user can input various information.

In this example, the touchpad 93 is configured integrally with the display 91. The user can input operation signals by touching the display 91.

The storage unit 85 is composed of a HDD, SSD, RAM, ROM, etc. Various programs, etc. are stored in the storage unit 85.

The control unit 86 controls the terminals 3, 4, and 10 to which it belongs. The control unit 86 is equipped with a CPU (microcomputer) and a semiconductor memory (not shown). The semiconductor memory stores programs for operating the CPU, etc.

<Functional configuration of the control unit 23 in the server device 2>
The control unit 23 functions as a recording unit 231, a transfer unit 232, an intermediation unit 233, and a notification unit 234 as a result of the CPU executing various programs.

The recording unit 231 performs tokenization. Tokenization here means expressing the items for which ownership is to be clarified as information that can be transmitted and received. In this embodiment, the items for which ownership is to be clarified include the match results and the rights associated with them.

The recording unit 231 records the tokenized information (corresponding to the transaction information described below) in a distributed ledger. The distributed ledger is an electronic ledger (a type of database). The distributed ledger is shared by multiple nodes (generally computers).

One example of a distributed ledger implementation is the so-called blockchain. In this embodiment, the blockchain mechanism is also used as the distributed ledger.

In a blockchain, data is recorded as multiple blocks linked together, and each node is implemented to share these blocks. The server device 2 functions as a node of the distributed ledger. The first block (origin block) is registered in the distributed ledger as an initial value. Newly generated blocks are linked to the origin block.

The block contains transaction information. In this embodiment, the transaction information contains information that links match result information with information that identifies the player corresponding to the match result information.

In this embodiment, the information on the match result includes the following information:
(1) Information identifying the tournament (e.g., tournament name, date and time, location, etc.).
(2) The stage of the match (e.g., information on the first round, the final, etc.).
(3) Contents of the rights acquired in association with the results of the match; (4) Information for identifying the owner of the rights acquired in association with the results of the match; (5) Information for identifying the judge (e.g., the referee) who made the judgment regarding the match (e.g., the referee's ID information, etc.).
(6) Information identifying the opponent (for example, opponent's ID information (account), etc.)
An example of the "rights obtained in association with the results of a match" is the rights (copyright, neighboring rights, etc.) related to the replay data that reproduces the progress of the match. An example of information that identifies a player is the player's ID information (account). In addition, the "venue" can be represented by an address or GPS (Global Positioning System) information.

The transfer unit 232 transfers the block including the transaction information to a specified destination via a communication network (communication network 6). In this case, the transfer unit 232 transfers the block by including information for identifying the source and destination in the block to be transferred and recording the information in the distributed ledger.

This connects the block to the blockchain. Note that the information to identify the source and destination of the transfer can be constructed using cryptographic keys prepared by the source and destination, similar to the general blockchain mechanism.

The intermediary unit 233 mediates between the source and destination of transaction information (blocks). In this example, the intermediary unit 233 creates a market on the communication network 6 that users can access via the communication network 6. Here, users include both those who wish to sell rights (hereinafter simply referred to as rights) obtained as a result of a match (hereinafter sellers) and those who wish to purchase the rights (hereinafter intended buyers).

The intermediary unit 233 accepts listings from sellers who are logged in to the market. Specifically, the intermediary unit 233 transmits data for displaying a user interface (hereinafter also referred to as UI) such as a login screen, menus, and buttons to the player terminal 3. In response to the seller's operation of the UI, the intermediary unit 233 registers the listed rights in a database for managing listings.

The intermediary unit 233 displays a specified UI on the terminal (purchaser terminal 10) of the potential purchaser who has logged in to the market. For example, the intermediary unit 233 displays information on the put up rights, for example in list format, on the purchaser terminal 10 as the UI. In this case, it is convenient if the list can be searched by tournament name, player name, team name, used character, etc. It is convenient if the list can be sorted. Convenience can be enhanced if the sorting conditions can be specified, for example, by tournament results (e.g., selecting only the winners), team name, and type of right (e.g., replay right or trophy).

The intermediary unit 233 also displays a UI for accepting purchase requests on the purchaser terminal 10. In this example, the intermediary unit 233 displays a button for inputting purchase intentions (e.g., a button labeled "Add to cart") on the purchaser terminal 10 as the UI.

When a purchase request is received from a potential buyer, the intermediary unit 233 notifies the seller of that information via the communication network 6 (hereinafter, a transaction request notification). Examples of information to be included in the transaction request notification include the potential buyer's ID and purchase conditions (e.g., price).

The seller, who has received a transaction request notification, transfers the block corresponding to the listed rights to the prospective buyer (described below), and the transaction is completed. In other words, the ownership of the rights is transferred to the prospective buyer. Since this embodiment uses blockchain technology, the buyer becomes the sole owner (rights holder) of the block.

When a transaction is concluded through the mediation of the mediation unit 233, the notification unit 234 notifies at least one of the transfer source (seller) and transfer destination (potential buyer) of a request to pay the mediation fee. In this example, the notification unit 234 notifies both the transfer source and transfer destination of a request to pay the fee.

<Functional configuration of the control unit 56 in the game device 5>
The control unit 56 functions as a match execution unit 561, a result storage unit 562, and a result transmission unit 563 as a result of the CPU executing various programs.

The match execution unit 561 reads data such as objects and textures contained in the game data and executes the game program in accordance with the player's operation of the controller 63. The execution of the game program generates two-dimensional or three-dimensional game image information.

The game image information is processed by the graphics processing unit 52. Through processing by the graphics processing unit 52, the processed game image is displayed on the display 61. For example, a game image Sc as shown in FIG. 5 is displayed on the display 61.

In particular, the battle executing unit 561 starts a battle in a battle-type action game when a predetermined condition is met (for example, when a predetermined operation is performed on the controller 63). The battle executing unit 561 ends the battle when the outcome of the battle is decided (for example, when the vitality value of the character becomes 0).

The result storage unit 562 records the match results (win/lose, points, match time, etc.) in the storage unit 55. The result storage unit 562 also records history information of inputs made by the controller 63 (hereinafter, input history information) in the storage unit 55. Using the input history information makes it possible to replay the match.

The result transmission unit 563 transmits the match result, the information identifying the player (e.g., ID information), and the input history information recorded by the result storage unit 562 to the server device 2 via the communication network 6. The server device 2 transmits the match result, the information identifying the player, and the input history information to the referee terminal 4.

<Functional configuration of the referee terminal>
6 is a block diagram showing the functions of the control unit 86 in the referee terminal 4. The control unit 86 of the referee terminal 4 functions as a UI display unit 40, a result receiving unit 41, a result verifying unit 42, a result authenticating unit 43, and an authentication result transmitting unit 44 by the CPU executing various programs.

The UI display unit 40 displays UIs such as menus on the display 91. A user (here, the referee) can give various instructions to the referee terminal 4 by operating the UI with the touch pad 93 (display 91). In this example, the UIs include a "verification start menu" and a "match result judgment UI."

The result receiving unit 41 receives information on the match results sent by the server device 2. The result receiving unit 41 records the received match results in the memory unit 85 in the referee terminal 4. The result receiving unit 41 also receives input history information sent by the server device 2. The result receiving unit 41 records the received input history information in the memory unit 85 in the referee terminal 4.

The result verification unit 42 constructs replay data in response to the operation of a verification start menu by a user (here, the referee). The result verification unit 42 constructs replay data based on input history information. The result verification unit 42 displays the constructed replay data on the display 91. This allows the referee (judge) to determine whether or not cheating occurred in the match based on the replay data.

The result authentication unit 43 (authentication unit) accepts the judgment result by the referee. In this example, "OK" and "NG" buttons are displayed on the display 91 as a match result judgment UI. The result authentication unit 43 certifies the match result for which the referee clicks "OK" as a legitimate result and sends it to the authentication result transmission unit 44.

The authentication result transmission unit 44 transmits the authentication result, result information, and information identifying the player input from the result authentication unit 43 to the server device 2.

<Functional configuration of player terminal 3>
7 is a block diagram showing functions of the control unit 86 in the player terminal 3. The control unit 86 of the player terminal 3 functions as a UI display unit 30, a token management unit 31, an auction unit 32, a transaction request receiving unit 33, and a transaction permission unit 34 by the CPU executing various programs.

The UI display unit 30 displays a predetermined UI screen on the display 91. A user (here, the player) can give various instructions to the player terminal 3 by operating the UI with the touch pad 93 (display 91).

In this example, the UIs displayed by the UI display unit 30 include an "item listing menu," a "transaction request confirmation menu," and a "transaction permission UI." In this embodiment, the UI display unit 30 displays "transaction approval" and "transaction rejection" buttons on the display 91 as the transaction permission UI.

The token management unit 31 causes the player terminal 3 to function as a blockchain node. For example, the token management unit 31 receives blocks (transaction information) transferred from the server device 2.

When a predetermined condition is met (when a transaction is completed), the token management unit 31 transfers the block to the transaction partner (transfer destination). When transferring a block, the token management unit 31 executes the transfer using the same protocol as the transfer unit 232 of the server device 2.

The listing unit 32 functions when a user (here, the seller, for example a player) operates the listing menu. The listing unit 32 requests login to the server device 2 and establishes a connection with the intermediation unit 233. The listing unit 32 notifies the intermediation unit 233 via the communication network 6 of information on the block that the seller wishes to sell. As a result, the token to be sold is registered in a database for listing management.

The transaction request receiving unit 33 receives a transaction request (described later) sent to the player terminal 3. In this example, the transaction request is sent from the intermediary unit 233 of the server device 2 via the communication network 6. The transaction request can be sent and received by communication means such as e-mail or push communication.

When a user (right holder) operates the transaction request confirmation menu via the touch pad 93, the transaction request receiving unit 33 displays the contents of the transaction request (described below) on the display 91. The user can check the right (block) that is the subject of the transaction by looking at the display 91.

The transaction permission unit 34 functions when the user (right holder) operates the "transaction approval" button. The transaction permission unit 34 transmits information indicating that the transaction has been approved (hereinafter, approval notification) to the terminal of the potential purchaser (purchaser terminal 10).

When the conditions for transferring blocks (tokens) (hereinafter, transaction conditions) are met, the transaction permission unit 34 permits the token management unit 31 to transfer the blocks (tokens) to be traded. As a result, ownership of the tokens is transferred to the destination user (the person wishing to purchase). One example of a transaction condition is the payment of a price.

<Functional configuration of the purchaser's terminal>
8 is a block diagram showing the functions of the control unit 86 in the purchaser terminal 10. The control unit 86 of the purchaser terminal 10 functions as a UI display unit 101, a token management unit 102, a transaction request unit 103, and a permission receiving unit 104 by the CPU executing various programs.

The UI display unit 101 displays a predetermined UI screen on the display 91. A user (here, a potential purchaser) can give various instructions to the player terminal 3 by operating the UI with the touch pad 93 (display 91). In this example, the UI is a "purchase menu."

The token management unit 102 causes the purchaser terminal 10 to function as a blockchain node. When a predetermined condition is met (when a transaction is completed), the token management unit 102 receives a block (transaction information) transferred from the player terminal 3.

The token management unit 102 can also transfer blocks. When transferring blocks, the token management unit 102 executes the transfer using the same protocol as the transfer unit 232 of the server device 2.

The transaction request unit 103 functions when a user (purchaser) operates the purchase menu. The transaction request unit 103 requests login to the server device 2 and establishes a connection with the intermediation unit 233. Once the connection is established, the list of items being sold and UI data for purchase reception (menus, etc.) are sent to the purchaser terminal 10 by the intermediation unit 233.

The transaction request unit 103 displays the sent auction listing list, etc. on the display 91. This allows the potential purchaser to select the rights, etc. (tokens) that he or she wishes to purchase. The transaction request unit 103 transmits information identifying the auction selected by the potential purchaser (hereinafter, transaction information) to the intermediation unit 233 of the server device 2.

The permission receiving unit 104 receives a permission notification from the seller's terminal (player terminal 3). The purchaser, for example, makes a payment to establish the terms of the transaction. The payment can be made, for example, by remittance via online banking or by remittance of virtual currency.

Example of operation
<Conducting the match>
A flowchart of the match is shown in Fig. 9. In this embodiment, each player P1, P2 is assumed to have been given a QR code (registered trademark) for identity authentication when they entered the tournament in advance. When starting a match, each player P1, P2 has the authentication device 7 read the QR code. As a result, information associated with the QR code is transferred to the server device 2.

The server device 2 transfers the verification result of the information accompanying the QR code sent from the code reader 71 (information as to whether the player is a legitimate player or not) to the referee's terminal (referee terminal 4). If there are no problems with the verification result sent to the referee terminal 4, the referee instructs players P1 and P2 to start the match.

The match execution unit 561 progresses the match as each player P1, P2 operates their respective controllers 63 (step S01). In the match, the outcome is determined, for example, when the vitality value of one of the characters reaches 0. Once the outcome is determined, the result storage unit 562 stores the match result in the storage unit 55 (step S02). The result transmission unit 563 also transmits the match result to the server device 2 (step S03).

<Determining the match result>
A flowchart for determining the match result is shown in Fig. 10. In the e-sports tournament exemplified in this embodiment, a referee judges whether players P1 and P2 have committed any cheating, etc. In this example, when the match ends, information on the match result and input history information are sent from the server device 2 to the referee terminal 4.

The result receiving unit 41 of the referee terminal 4 receives the sent match results, etc. (step S11). When the referee operates the UI of the referee terminal 4, the result verifying unit 42 constructs replay data (step S12). The result verifying unit 42 displays the constructed replay data on the display 91. This allows the referee (judge) to verify whether or not there was cheating in the match based on the replay data. The referee can input the judgment result by operating the match result judgment UI.

The result authentication unit 43 accepts the verification result entered by the referee and authenticates it (step S13). This finalizes the match result. Once the match result has been finalized, the authentication result transmission unit 44 transmits the authentication result to the server device 2 (step S14). Here, it is assumed that the match has been authenticated as legitimate.

Match Result Tokenization
If the match result sent from the authentication result sending unit 44 is not valid, the server device 2 does not tokenize the match result. On the other hand, if the match result is authenticated as valid, the server device 2 tokenizes the match result. Figure 11 shows a flowchart of match result tokenization.

First, the server device 2 receives the verified match results from the referee terminal 4 (step S21). The recording unit 231 generates a block (token) based on the received match results and records it in the distributed ledger (step S22). That is, in this example, the server device 2 generates the block.

The transfer unit 232 transfers the block (token) to the player terminal 3 of the winner (the owner of the rights related to the match result) (step S23). The player terminal 3 functions as a blockchain node. As a result, the match result is recorded in the distributed ledger as belonging to the winner.

Token Trading
In the present embodiment, the server device 2, the player terminal 3, and the purchaser terminal 10 are used for token trading. A flowchart of token trading is shown in FIG. 12. Token trading is premised on a right holder (e.g., the winner of a match) putting up his/her rights (tokens). For example, the winner of a match can operate his/her player terminal 3 (the selling unit 32) to put up his/her own tokens to the intermediary unit 233 of the server device 2.

A person who wishes to purchase a token logs in to the server device 2 from his/her own purchaser terminal 10 and selects the token (right) he/she wishes to purchase. Once the purchaser has selected a token, the transaction request unit 103 of the purchaser terminal 10 transmits transaction information to the intermediary unit 233 (step S31).

The intermediary unit 233 transmits the transaction request notification to the player terminal 3 of the rights holder (step S32). The player terminal 3 then receives the transaction request notification (step S33), and a notification is issued to the user (rights holder).

When the rights holder operates the "transaction approval" button, the transaction permission unit 34 sends a permission notification to the purchaser terminal 10 (step S34). When the permission notification is sent, the permission receiving unit 104 in the purchaser terminal 10 receives the permission notification (step S35).

When the transaction conditions are met, the transaction permission unit 34 authorizes the token management unit 31 to transfer the block (token) to be traded. This transfers the ownership of the token to the destination user (the person wishing to purchase).

When the block (token) transaction is completed as described above, the notification unit 234 in the server device 2 notifies both the transfer source (seller) and the transfer destination (potential buyer) of a request to pay the intermediation fee (step S36). In the game system 1, tokens are traded through the intermediation of the server device 2.

In summary, the present invention is a computer system (game system 1) that manages the results of a match (game) played via a computer, and is characterized by having a recording unit 231 that records transaction information, which is information that links information on the game results of the game with information that identifies the player corresponding to the information on the game results, in a distributed ledger.

Effects of this embodiment
In this embodiment, game results are tokenized and recorded in a distributed ledger. According to this embodiment, the results of games played via a computer can be managed. In addition, in this embodiment, the results of games played via a computer can be easily tracked. In other words, in this embodiment, the attribution of rights arising from a game can be clarified. Furthermore, the rights can be traded safely. This will ultimately lead to the promotion of amateur players to become professionals and the securing of income for professional players.

In addition, this embodiment uses a distributed ledger, so information about the game results can be shared.

[Embodiment 2]
In the second embodiment, another configuration example of the control unit 23 in the server device 2 will be described. Fig. 13 is a block diagram showing the configuration of the server device 2 in the second embodiment. In this embodiment, the CPU of the control unit 23 executes various programs to function as a recording unit 231, a transfer unit 232, an intermediation unit 233, a notification unit 234, an information acquisition unit 235, and an authentication unit 236. The recording unit 231, the transfer unit 232, the intermediation unit 233, and the notification unit 234 perform the same functions as those described in the first embodiment.

The information acquisition unit 235 acquires the profile information of judges (umpires) from a database (hereinafter, judge database) that contains the profile information of the judges (umpires). The profile information can include various types of information.

In this embodiment, information for evaluating the reliability of the judgments made by the judges is collected in a judge database. The following is an example of a profile used in this embodiment as an index for reliability evaluation.
(1) A list of tournaments that the referee has refereed in the past; (2) The name of the organization to which the referee belongs; (3) The rank of the referee's qualification (for example, first class, second class, etc., issued by the organization to which the referee belongs).
(4) Evaluations of past matches (5) Feedback from tournament participants (6) Evaluations from tournament viewers via social networking services (SNS) etc. There is no limitation on the method of implementing the judge database. For example, the judge database can be implemented as a relational database or a distributed ledger such as a blockchain.

The authentication unit 236 checks the referee's profile and determines the legitimacy of the match results made by the referee. This determination can be made, for example, by converting the referee's profile into a numerical value and comparing that value with a threshold value. If the authentication unit 236 determines that the referee's decision is legitimate, it certifies the match results as legitimate.

Match results that are authenticated as valid by the authentication unit 236 are tokenized in the same manner as in embodiment 1 and recorded in the distributed ledger.

Effects of this embodiment
If the control unit 23 can function as the information acquisition unit 235 and the authentication unit 236, it becomes possible to tokenize legitimate game results even in games in which the game system 1 is not directly involved in the operation. This further promotes amateur players to become professionals and professional players to secure income.

[Other embodiments]
The game system 1 may be operated as follows.

(1) Players may be given the right to use a virtual room created by a computer, and may be allowed to place virtual items such as trophies in the virtual room, provided that they possess a token (block). This will promote participation in the game and increase utilization of the game system 1.

In addition, when a token is transferred, the transferee may be able to place a virtual item such as a trophy in their virtual room.

Rights granted by tokens are not limited to trophies. For example, rights granted by tokens could include various items and events related to the game, such as exclusive costumes, equipment, stages, and lottery rights, in addition to trophies. In addition, rights granted by tokens could include the right to stream video of the inside of a virtual room via a communication network.

(2) The tokens may be purchased by the tournament organizer after the game. For example, a system could be in place where the organizer purchases the tokens after a player has won a number of games. This would encourage participation in the game, and ultimately lead to increased use of the game system 1.

Of course, the buyer of tokens is not limited to the organizers of the tournament. For example, a sponsor may purchase tokens after the game. The sponsor may be either a sponsor of the tournament or a sponsor of the players. In a sponsored tournament, for example, sponsors can purchase tokens using the entry fees for the tournament as a source of funds.

In this way, by exchanging funds via tokens, the flow of money can be clarified. For example, if this computer system is operated in a country where it is legally required that "entry fees not be used to fund prize money," exchanging funds via tokens can easily comply with such legislation.

In addition, the subject of tokenization (subject of transaction) is not limited to rights related to replay data. For example, the following items can be given as examples:

Game save data (data that allows a game to be resumed from where it left off) may be tokenized. This will increase the use of the game system 1.

For example, the win/loss history associated with a player's account may be tokenized. This would make it possible, for example, to quickly play in a stronger tier when opponents are tiered according to strength.

The player's account itself may be tokenized, or the player's in-game name (succession rights) may be tokenized.

If players are participating in a game on a team basis, the ownership of the team itself can be tokenized. This makes it possible, for example, to play in a stronger tier immediately if opponents are tiered according to strength.

If the game result is not legitimate, the game result information may be tokenized. A blockchain that holds these tokens could be used, for example, as a database of cheating players.

The type of game is not limited to the fighting game shown as an example. Game system 1 (computer system) can be used for various game play. For example, the game is not limited to human-to-human battles. Furthermore, the game may be a game in which multiple players cooperate with each other to play, or a game played individually (such as a time attack). Game system 1 may be configured to tokenize the results of these games (for example, the time in a time attack).

If there are no problems with the verification results, the referee may return the results directly to the server device 2 from the referee terminal 4, or may have the authentication device 7 for the next game read the QR code.

The authentication of the player and the referee is not limited to the flow shown as an example. For example, the referee may send information associated with the QR code of a legitimate player to the server device 2, and the server device 2 may send the authentication result to the player terminal 3 of the player. Alternatively, the referee and the player may send information associated with the QR code to the server device 2, and if both QR codes are legitimate, the authenticity may be authenticated.

The result information is not limited to the examples given. Game result information includes all information related to the game. For example, game result information can include the character used, various times, player ID and information associated with it, type and number of techniques used, number of combos (continuous techniques), and the combo that inflicted the most damage. Game result information may also include information identifying the commentator, commentator, venue name, tournament name, and controller used.

When a distributed ledger is constructed using a blockchain, it may be possible to construct a cross-chain with other blockchains. For example, it is possible to construct a cross-chain with a blockchain for virtual currency, or a cross-chain with a blockchain for game currency. It may also be possible to construct a cross-chain with a blockchain that manages other games (or tournaments).

A server (token management server) that holds blocks (i.e., tokens) may be constructed. The server device 2 of the game system 1 may be used as the token management server, or a separate server may be prepared as the token management server. Providing a token management server reduces the burden on the token owner (e.g., security management). Even in this case, for example, a player (token owner) can replay games on his/her own game device 5 or display virtual trophies in the virtual space based on the ownership of the token.

If the referee's reliability is low, another referee may assist with the decision, or a joint evaluation may be conducted with AI (artificial intelligence). Also, joint evaluation between a human (referee) and AI may be conducted at all times.

A single player may be allowed to use multiple controllers. For example, it may be possible to use both a mouse and a keyboard.

There are no limitations on the type of controller, so long as it can be used for input. For example, a device that can be operated only by voice or gaze may be used as a controller.

There may be two or more game devices 5 for game play. In addition, online games using multiple game devices 5 or games using short-distance communication may also be possible.

There is no limit to the location where the authentication device 7 is installed. For example, the authentication device 7 may be installed at the venue of the tournament. The authentication device 7 may be configured as a portable terminal. The portable terminal may be, for example, a smartphone, and an authentication app may be installed on it to perform the role of the authentication device.

The referee and the player may share the same ID. For example, this type of operation may be considered when there is a referee who is also a player. In that case, the referee's credibility (see embodiment 2) may be evaluated based on the player's track record. For example, a referee who also acts as a player may have a lower credibility as a referee. Furthermore, if a player's ID and a referee's ID are found to be registered even though the IDs could be shared, penalties may be imposed.

It is also possible to create a video site that specializes in playing videos such as replays related to tokens, or to provide in-game content based on tokens.

The device that performs tokenization is not limited to the server device 2. For example, the game system 1 (computer system) may be configured so that a specific terminal (e.g., a portable terminal such as a smartphone) can be used for tokenization. In this case, the terminal may be configured to perform the following operations and processes.
(1) Enter the results of the match into the form displayed on the device.
(2) Next, tokenization (block generation) is performed by the terminal based on the form input.
(3) The block is connected to the blockchain via a terminal.

The game system 1 (computer system) may be configured to transmit the match result to the loser. An example of a destination of the match result is the player terminal 3 of the loser. The match result may be transmitted to the loser by the server device 2, or a separate device may be provided.

Even when these other embodiments are adopted, the effects of the present invention are achieved. In addition, this embodiment can be combined with other embodiments, and other embodiments can be combined with each other as appropriate.

1. Game system (computer system)
5. Game device (computer)
43 Result authentication unit (authentication unit)
236 Authentication unit 231 Recording unit 232 Transfer unit 233 Intermediation unit 234 Notification unit 235 Information acquisition unit

Claims (7)

A computer system for managing the results of a game played via a computer, comprising:
a recorder that records transaction information, which is information linking information on a game result of the game with information identifying a player corresponding to the information on the game result, in a distributed ledger;
a management unit for managing a sale of game results corresponding to the transaction information by the player,
The computer system according to claim 1, wherein the game result is a win or loss in the game, or an evaluation based on an index in the game. In claim 1 ,
A transfer unit that transfers the transaction information before it is recorded in the distributed ledger to a predetermined transfer destination via a communication network,
The computer system according to claim 1, wherein the transfer unit transfers the transaction information to be transferred while including information for identifying a transfer source and a transfer destination in the transaction information. In claim 1 or 2 ,
The computer system according to claim 1, wherein the transaction information includes data indicating a right that is obtained in association with the game result. In claim 2 ,
a transfer unit that transfers the transaction information to the transfer destination, and a transfer unit that transfers the transaction information to the transfer destination. In claim 4 ,
a notification unit that notifies at least one of the transfer source and the transfer destination of a request for payment of a consideration when the intermediation is established. In any one of claims 1 to 5 ,
The computer system according to claim 1, wherein the information on the game results includes information identifying the tournament in which the game was played. 1. A method for managing the results of a game played by a computer, comprising the steps of:
a recording step of recording transaction information, which is information linking information on a game result of the game with information for identifying a player corresponding to the information on the game result, in a distributed ledger;
a management step of managing a sale of game results corresponding to the transaction information by the player;
The game result management method according to claim 1, wherein the game result is a win or loss in the game, or an evaluation based on an index in the game.

Images