JP2022130512A - computer system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To manage the result of a game played through a computer.

SOLUTION: A computer system that manages the result of a game played via a computer includes a recording unit for recording transaction information which is information that links game result information with information that identifies a player corresponding to the game result information, in a distributed ledger. The transaction information includes data indicating the right obtained in conjunction with the game result, and the right is related to replay data reproducing the progress of the game.

SELECTED DRAWING: Figure 11

COPYRIGHT: (C)2022,JPO&INPIT

Description

The present invention relates to computer systems.

A computer system that allows spectators to watch a game tournament is known (see Patent Document 1, for example). Patent Literature 1 discloses a video distribution service for distributing game video data in accordance with the progress of a game competition.

Japanese Patent No. 6522209

In the example of the patent document mentioned above, the game result is not managed, and it is difficult to track the game result after the end of the match.

An object of the present disclosure is to enable management of the results of games played via a computer.

A first aspect is a computer system that manages the results of a game played via a computer,
a recording unit for recording, in a distributed ledger, transaction information, which is information linking game result information of the game and information specifying a player corresponding to the game result information, in the transaction information; contains data indicating entitlements attached to game results;
The right is a right pertaining to replay data that reproduces the course of the game.

A second aspect is a computer system for managing the results of a game played via a computer,
a recording unit that records, in a distributed ledger, transaction information, which is information linking game result information of the game and information specifying a player corresponding to the game result information;
An authentication unit that authenticates the legitimacy of the game result,
The recording unit distributes, as the transaction information, information linking information of the game result authenticated by the authentication unit with information specifying a player corresponding to the information of the authenticated game result. Record in the type ledger,
The game result information is associated with information specifying a judge who made a judgment related to the game,
an information acquisition unit that acquires the profile information from a database containing the profile information of the judge;
The computer system is characterized in that the authentication unit uses the information of the profile obtained by the information acquisition unit for the judgment of validity.

In any of the above aspects,
The game result information includes information specifying the tournament in which the game was played.

According to the present invention, the results of games played via a computer can be managed.

1 is a block diagram showing the configuration of a game system according to Embodiment 1; FIG. It is a block diagram which shows the structure of a server apparatus. 1 is a block diagram showing the configuration of a game device; FIG. 3 is a block diagram showing the configuration of each terminal; FIG. An example of a game image is shown. The function of the control unit in the referee terminal is shown in a block diagram. The function of the control part in a player terminal is shown with a block diagram. The function of the control part in a purchaser terminal is shown with a block diagram. 4 shows a flow chart of a battle. FIG. 11 shows a flowchart for finalizing the result of a match. 4 shows a flowchart of match result tokenization. 3 shows a flow chart of token trading. FIG. 11 is a block diagram showing the configuration of a server device 2 according to Embodiment 2;

A computer system and a game result management method according to the present disclosure will be described below with reference to the drawings. A computer system of the present disclosure is implemented as a game system. The game result management method of the present disclosure is implemented as a function of the game system.

In the following description, the term "game" refers to an activity to achieve some purpose according to predetermined rules, which is carried out using a computer. Some of the games involve a plurality of participants (games that determine victory or defeat), while others are evaluated based on some index such as score or time for each participant. Participants here include both individuals and teams.

Also, in the following description, "game result" includes all information related to the game (which will be exemplified later).

In particular, in a competitive game in which participants compete, the participants are sometimes called "players". Also, the "game result" of a battle-type game may be called "match result".

[Embodiment 1]
《Overview of the game system》
FIG. 1 is a block diagram showing the configuration of a game system according to Embodiment 1. FIG. The game system 1 is used, for example, to manage an e-sports (Electric Sports) tournament. The game in the game system 1 is operated by the game player to make the player character act in a three-dimensional virtual game space (hereinafter simply referred to as virtual space) and to perform various actions on the companions of the player character. or

The game described in this embodiment is a battle-type action game in which a player character battles other player characters or non-player characters in a virtual space. More specifically, the game of 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 operates one character (player character). In a battle, for example, victory or defeat is determined when the physical strength value of one of the characters becomes 0.

In the e-sports tournament of this embodiment, the winner of the tournament is determined by, for example, a tournament system. In other words, in the e-sports tournament, the combination of players to compete is determined by the result of one competition. In the e-sports competition exemplified in the present embodiment, the presence or absence of dishonesty by a player is judged by a referee.

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

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

A player's terminal (hereinafter referred to as player terminal 3 ) may be connected to the game system 1 via a communication network 6 . Two player terminals 3 are connected to the game system 1 in the example of FIG. Hereinafter, constituent elements such as the player terminal 3 that have a plurality of components are distinguished by adding branch numbers to reference numerals as necessary (for example, 3-1, 3-2, etc., and the same applies hereinafter).

The player terminal 3 is used for a right transaction (to be described later), etc. related to the competition. The player terminal 3-1 is a terminal used by the player P1. The player terminal 3-2 is a terminal used by the player P2.

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

The game device 5 executes a game (here, a competitive action game) based on the operation of the game player. In this embodiment, one game device 5 receives operations from a set of players (two players in this example).

As the game device 5, commercially available devices such as personal computers, PlayStation (registered trademark), XBox (registered trademark), PlayStation Vita (registered trademark), and Nintendo Switch (registered trademark) can be used.

Game device 5 may receive (download) a game program and game data from server device 2 via communication network 6 . After receiving the game program or the like, the game device 5 installs the received game program or the like.

The game device 5 starts a battle in a battle-type action game based on the operation of each player (hereinafter referred to as players P1 and P2). The game device 5 advances the game while outputting game images and sounds to a display 61 and speakers 62 (each described later) based on the operations of each player.

When the battle ends, the game device 5 transmits result information indicating the result of the battle to the server device 2 . The result information includes, for example, the stage of the competition (information on the first round, finals, etc.), information specifying the winner of the competition, and other information.

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

The network interface 21 is communicably connected to the game device 5 and the like via a communication network 6 such as the Internet and LAN.

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

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

<Structure of game device 5>
FIG. 3 is a block diagram showing the configuration of the game device 5. As shown in FIG. As shown in FIG. 3, the game device 5 has a display 61, a speaker 62 and a controller 63 externally connected or built therein. This game device 5 is provided with two displays 61 (displays 61-1 and 61-2). The game device 5 is also provided with two controllers 63 (controllers 63-1 and 63-2).

The display 61-1 and controller 63-1 are used by player P1. The display 61-2 and controller 63-2 are used by player P2. Instead of the controller 63 that is standard equipment in the game system 1, there are cases where controllers prepared by the players P1 and P2 themselves are connected.

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

Network interface 51 is communicably connected to communication network 6 in order to transmit and receive various data between game device 5 and server device 2 .

The graphics processing unit 52 draws a game image 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 are liquid crystal displays, for example. A game image drawn in a moving image format is displayed on the display 61 as a game screen.

The audio processing section 53 is connected to the speaker 62 . The audio processing unit 53 reproduces and synthesizes the game sound according to the instruction of the control unit 56 and outputs it 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 regarding operation inputs to and from the controller 63 . The players P<b>1 and P<b>2 input operation signals to the game apparatus 5 by operating various operators such as buttons of the controller 63 .

The storage unit 55 is configured with an HDD, SSD, RAM, ROM, and the like. The storage unit 55 stores game data downloaded from the server device 2, various programs including part of the game program, and the like.

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

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

In this embodiment, each of the players P1 and P2 is distributed with a QR code (registered trademark) indicating that they are tournament participants (players) when they enter the tournament. As an example, the distribution of the QR code (registered trademark) can be realized by transmitting it to the player terminals 3 owned by the players P1 and P2 via the communication network 6 .

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

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

<Configuration of various terminals>
The game system 1 is provided with the referee terminal 4 as described above. A player terminal 3 and a purchaser terminal 10 are also connected to the game system 1 .

In this embodiment, for convenience of explanation, these terminals 3, 4, and 10 shall have the same hardware configuration. For example, each terminal 3, 4, 10 can be configured by installing predetermined software on a smart phone.

FIG. 4 is a block diagram showing the configuration of terminals 3, 4 and 10. As shown in FIG. As shown in FIG. 4, terminals 3, 4, and 10 incorporate displays 91, speakers 92, and touch pads 93. FIG.

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

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

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

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

The operation unit 84 is connected to the touch pad 93 . An operation signal from a user (for example, player P1) is input to the operation unit 84 via the touch pad 93 . The user can execute various programs stored in the storage unit 85 by operating the touch pad 93 . The user can input various information by operating the touch pad 93 .

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

The storage unit 85 is composed of an HDD, SSD, RAM, ROM, and the like. Various programs and the like 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 includes a CPU (microcomputer) and a semiconductor memory (not shown). The semiconductor memory stores programs and the like for operating the CPU.

<<Functional Configuration of Control Unit 23 in Server Device 2>>
The control unit 23 functions as a recording unit 231, a transfer unit 232, an intermediary 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 matters for which ownership is to be clarified as information that can be transmitted and received. In the present embodiment, items to be clarified for ownership include match results and accompanying rights.

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

An example of a distributed ledger implementation is the so-called blockchain. This embodiment also employs a blockchain mechanism as a distributed ledger.

Blockchains are implemented by recording data as blocks that are strung together and shared by each node. The server device 2 functions as a node of a distributed ledger. Assume that the first block (origin block) is registered in the distributed ledger as an initial value. The newly created block is connected to the origin block.

Blocks contain transaction information. The transaction information of the present embodiment includes information linking match result information and information specifying a player corresponding to the match result information.

In this embodiment, the information on the battle result includes the following information.
(1) Information specifying the tournament (for example, tournament name, date and time, venue, etc.).
(2) Competition stage (for example, information on the first round, finals, etc.).
(3) Contents of the rights that accompany the results of the match (4) Information that identifies the owner of the rights that accompany the results of the match Identifying information (referee ID information, etc.)
(6) Information identifying the opponent (for example, opponent's ID information (account), etc.)
An example of the 'rights acquired in association with the result of a match' is a right (copyright, neighboring rights, etc.) pertaining to replay data that reproduces the progress of the match. Player ID information (account) and the like can be exemplified as the information specifying the player. Also, the "venue" can be represented by an address or as GPS (Global Positioning System) information.

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

This connects the block to the blockchain. The information for specifying the transfer source and transfer destination can be constructed using encryption keys prepared by the transfer source and transfer destination, respectively, as in the general blockchain mechanism.

The intermediary unit 233 mediates between the transfer source and the transfer destination of transaction information (blocks). In this example, the intermediary unit 233 implements a market on the communication network 6 that users can access via the communication network 6 . Here, users are both those who want to sell the rights (hereinafter simply referred to as rights) that accompany the match results (hereinafter referred to as sellers) and those who wish to purchase the rights (hereinafter referred to as purchasers). including.

The intermediary unit 233 accepts an exhibit from an exhibitor who has logged into the market. Specifically, the intermediation 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 . The intermediary unit 233 registers the exhibited right in the database for exhibition management in accordance with the operation of the UI by the exhibitor.

The intermediary unit 233 displays a predetermined UI on the terminal (purchaser terminal 10) of the purchaser who has logged into the market. For example, the intermediary unit 233 causes the purchaser terminal 10 to display, as a UI, information about the rights put up for sale, for example, in the form of a list. In this case, it would be convenient if the list could be searched by tournament name, player name, team name, character used, or the like. It is convenient to make the list sortable. For sorting conditions, for example, it is possible to specify the result of the meeting (such as selecting only the winner), the name of the team to which the player belongs, and the type of right (replay right or trophy, etc.), which increases convenience.

In addition, the intermediation unit 233 also causes the purchaser terminal 10 to display a UI for receiving a purchase request. In this example, the intermediary unit 233 causes the purchaser terminal 10 to display a button (for example, a button labeled "Add to Cart") for inputting a purchase intention as a UI.

When there is a purchase request from a purchaser, the intermediary section 233 notifies the seller of the information via the communication network 6 (hereinafter referred to as transaction request notification). Examples of information to be included in the transaction request notification include the purchaser's ID, purchase conditions (for example, price), and the like.

When the exhibitor receives the transaction request notification and transfers the block corresponding to the exhibited right to the purchaser (to be described later), the transaction is completed. In other words, ownership of rights is transferred to the prospective purchaser. Since block chain technology is used in this embodiment, the purchaser is the sole owner (right holder) of the block.

The notification unit 234 notifies at least one of the transfer source (exhibitor) and the transfer destination (purchase applicant) of the payment request for the intermediation price when the transaction is established through the intermediation of the intermediation unit 233 . In this example, the notification unit 234 notifies both the transfer source and the transfer destination of the payment request.

<<Functional Configuration of Control Unit 56 in Game Device 5>>
The control unit 56 functions as a battle execution unit 561, a result storage unit 562, and a result transmission unit 563 by executing various programs by its CPU.

The battle execution unit 561 reads data such as objects and textures included in the game data and executes the game program according to the player's operation of the controller 63 . Two-dimensional or three-dimensional game image information is generated by executing the game program.

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

In particular, the battle executing section 561 starts a battle in the battle action game when a predetermined condition is satisfied (for example, when a predetermined operation is performed on the controller 63). The battle executing section 561 ends the battle when the victory or defeat of the battle is decided (for example, when the physical strength value of the character becomes 0).

The result storage unit 562 records the match result (win/loss, score, game time, etc.) in the storage unit 55 . The result storage unit 562 also records input history information (hereinafter referred to as input history information) by the controller 63 in the storage unit 55 . By using the input history information, it becomes possible to reproduce (replay) the battle.

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

<<Functional configuration of referee terminal>>
FIG. 6 is a block diagram showing functions of the control unit 86 in the referee terminal 4. As shown in FIG. The control unit 86 of the referee terminal 4 functions as a UI display unit 40, a result reception unit 41, a result verification unit 42, a result authentication unit 43, and an authentication result transmission unit 44 by executing various programs by its CPU. .

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

The result receiving unit 41 receives information about the result of the battle transmitted by the server device 2 . The result receiving unit 41 records the received match result in the storage unit 85 in the referee terminal 4 . The result receiving unit 41 also receives the input history information transmitted by the server device 2 . The result receiving section 41 records the received input history information in the storage section 85 in the referee terminal 4 .

The result verification unit 42 constructs replay data according to the operation of the verification start menu by the user (referee in this case). The result verification unit 42 constructs replay data based on the input history information. The result verification unit 42 displays the constructed replay data on the display 91 . As a result, the referee (judgment person) can judge the presence or absence of dishonesty 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 the battle result determination UI. The result authentication unit 43 authenticates the match result for which the referee clicked “OK” as a valid result, and sends it to the authentication result transmission unit 44 .

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

<<Functional Configuration of Player Terminal 3>>
FIG. 7 is a block diagram showing functions of the control unit 86 in the player terminal 3. As shown in FIG. The control unit 86 of the player terminal 3 functions as the UI display unit 30, the token management unit 31, the exhibition unit 32, the transaction request reception unit 33, and the transaction authorization 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, a 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 "exhibition menu", a "transaction request confirmation menu", and a "transaction permission UI". In the present embodiment, the UI display unit 30 displays "transaction approval" and "transaction refusal" buttons on the display 91 as the transaction permission UI.

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

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

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

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

The transaction request receiving unit 33 displays the contents of the transaction request (described later) on the display 91 when the user (right holder) operates the transaction request confirmation menu via the touch pad 93 . The user can confirm the rights (blocks) to be traded by looking at the display 91 .

The transaction permitting unit 34 functions when the user (right holder) operates the "transaction approval" button. The transaction authorization unit 34 transmits information indicating that the transaction has been approved (hereinafter referred to as permission notice) to the terminal of the prospective purchaser (purchaser terminal 10).

The transaction permitting unit 34 permits the token management unit 31 to transfer blocks (tokens) to be traded when conditions for transferring blocks (tokens) (hereinafter referred to as transaction conditions) are met. As a result, ownership of the token is transferred to the destination user (purchase applicant). An example of a transaction condition is payment of consideration.

<<Functional Configuration of Buyer Terminal>>
FIG. 8 is a block diagram showing functions of the control unit 86 in the purchaser terminal 10. As shown in FIG. 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 reception unit 104 by the CPU executing various programs.

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

The token management unit 102 causes the purchaser terminal 10 to function as a block chain node. The token management unit 102 receives blocks (transaction information) transferred from the player terminal 3 when a predetermined condition is satisfied (when a transaction is established).

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

The transaction request unit 103 functions when the user (purchaser) operates the purchase menu. The transaction requesting unit 103 requests login to the server device 2 and establishes connection with the intermediary unit 233 . When the connection is established, the listing list and the UI data (menu, etc.) for accepting purchases are sent to the purchaser terminal 10 by the intermediary section 233 .

The transaction requesting unit 103 displays the sent exhibition list and the like on the display 91 . Thereby, the purchaser can select the right (token) that he/she wishes to purchase. The transaction requesting unit 103 transmits to the intermediary unit 233 of the server device 2 information specifying the exhibition selected by the prospective purchaser (hereinafter referred to as transaction information).

The permission receiving unit 104 receives a permission notification from the exhibitor's terminal (player terminal 3). The purchaser pays, for example, a consideration in order to establish the terms of the transaction. For payment of consideration, for example, remittance by net banking, remittance by virtual currency, etc. can be used.

《Example of operation》
<Implementation of battle>
FIG. 9 shows a flow chart of the competition. In the present embodiment, it is assumed that each of the players P1 and P2 is distributed a QR code (registered trademark) for identity verification when entering the tournament in advance. When starting a match, each of the players P1 and P2 causes the authentication device 7 to read the QR code. Thereby, the 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 transmitted from the code reader 71 (information as to whether or not the player is legitimate) to the referee's terminal (referee's terminal 4). If there is no problem in the verification result sent to the referee terminal 4, the referee instructs the players P1 and P2 to start the match.

Each player P1, P2 operates the respective controller 63, so that the battle executing section 561 advances the battle (step S01). In a battle, for example, victory or defeat is once determined when the physical strength value of one of the characters becomes 0. Once the win or loss is determined, the result storage unit 562 stores the match result in the storage unit 55 (step S02). Also, the result transmission unit 563 transmits the match result to the server device 2 (step S03).

〈Confirmation of match results〉
FIG. 10 shows a flowchart for determination of the match result. In the e-sports tournament exemplified in the present embodiment, the presence or absence of dishonesty by the players P1 and P2 is determined by a referee. In this example, after the match is over, 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 battle results and the like sent (step S11). Here, when the referee operates the UI of the referee terminal 4, the result verification section 42 constructs replay data (step S12). The result verification unit 42 displays the constructed replay data on the display 91 . As a result, the referee (judgment person) can verify the presence or absence of dishonesty in the match based on the replay data. The referee can input the judgment result by operating the competition result judgment UI.

The result authentication unit 43 accepts the verification result input by the referee and authenticates it (step S13). This confirms the result of the battle. After the match result is determined, the authentication result transmission unit 44 transmits the authentication result to the server device 2 (step S14). Here, it is assumed that the competition has been authenticated as legitimate.

〈Battle result tokenization〉
If the match result sent from the authentication result transmitting unit 44 is not valid, the server device 2 does not tokenize the match result. On the other hand, when the match result is authenticated as valid, the server device 2 tokenizes the match result. FIG. 11 shows a flow chart of tokenization of the match result.

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

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

〈Token trading〉
A server device 2, a player terminal 3, and a purchaser terminal 10 are used for token transactions in this embodiment. FIG. 12 shows a flow chart of token trading. Token trading is based on the premise that any rights holder (for example, the winner of a match) has put up its rights (tokens). For example, the winner of the match can put his own player terminal 3 (exhibition unit 32 ) into operation and put his own token on the brokerage unit 233 of the server device 2 .

A person who wishes to purchase a token logs into the server device 2 from his own purchaser terminal 10 and selects a desired token (right) to purchase. When the would-be purchaser selects a token, the transaction request unit 103 of the purchaser terminal 10 transmits transaction information to the intermediary unit 233 (step S31).

The brokerage unit 233 transmits the transaction request notification to the right holder's player terminal 3 (step S32). Then, the player terminal 3 receives the transaction request notification (step S33), and the notification is issued to the user (right holder).

Here, when the right holder operates the "transaction approval" button, the transaction permission unit 34 transmits a permission notification to the purchaser terminal 10 (step S34). When the permission notice is transmitted, the permission reception unit 104 of the purchaser terminal 10 receives the permission notice (step S35).

When the transaction conditions are established, the transaction permitting unit 34 permits the token management unit 31 to transfer the blocks (tokens) to be traded. As a result, ownership of the token is transferred to the destination user (purchase applicant).

When the block (token) transaction is established as described above, in the server device 2, the notification unit 234 notifies both the transfer source (exhibitor) and the transfer destination (purchase applicant) of a request for payment of the brokerage consideration. (step S36). In the game system 1 , tokens are traded through the mediation of the server device 2 .

To summarize the above, the present invention is a computer system for managing the results of a competition (game) conducted via a computer, wherein information on the game results of the game and a player corresponding to the information on the game results are specified. A computer system (game system 1) characterized by comprising a recording unit 231 that records transaction information, which is information linked with information to be played, in a distributed ledger.

<<Effect of this embodiment>>
In this embodiment, the game result is tokenized and recorded in the 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, it is possible to clarify the attribution of rights that accompany the game. In addition, the rights can be safely traded. By extension, it leads to promotion of professionalization of amateur players and securing of income for professional players.

Further, in this embodiment, since a distributed ledger is adopted, the information of 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 according to the second embodiment. In this embodiment, the CPU of the control unit 23 functions as a recording unit 231, a transfer unit 232, an intermediary unit 233, a notification unit 234, an information acquisition unit 235, and an authentication unit 236 by executing various programs. The recording unit 231, the transfer unit 232, the intermediary unit 233, and the notification unit 234 exhibit functions similar to those described in the first embodiment.

The information acquisition unit 235 acquires profile information from a database (hereinafter referred to as a judge database) containing profile information of judges (referees). Profile information can include a variety of information.

In this embodiment, information for evaluating the reliability of decisions made by referees is collected in the judge database. Profiles used in this embodiment as indexes for reliability evaluation are exemplified below.
(1) A list of competitions that referees have held in the past (2) The name of the organization to which the referee belongs (3) The grade of the referee's qualifications (for example, grades issued by the organization to which the referee belongs, such as 1st or 2nd grade)
(4) Evaluation of past match evaluations (5) Feedback from tournament participants (6) Evaluations from tournament viewers via SNS (social networking services), etc. There are no restrictions on how the judge database is implemented. do not have. The judge database can be implemented, for example, as a relational database or as a distributed ledger such as a blockchain.

The authentication unit 236 confirms the referee's profile and determines the legitimacy of the result of the match played by the referee. This determination can be realized, for example, by quantifying the referee's profile and comparing the value with a threshold. The authentication unit 236 authenticates the competition result as valid when the referee's judgment is valid.

A match result authenticated as valid by the authentication unit 236 is tokenized in the same manner as in the first embodiment and recorded in the distributed ledger.

<<Effect of this embodiment>>
If the control unit 23 can function as the information acquisition unit 235 and the authentication unit 236, even if the game system 1 is not directly involved in the management of the game, it can be tokenized as long as it is a valid game result. become. As a result, in the present embodiment, it is further promoted to make amateur players professional and to secure income for professional players.

[Other embodiments]
The game system 1 may operate 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 they possess tokens (blocks). By doing so, participation in the game is promoted, and use of the game system 1 is activated.

Also, when a token is transferred, a virtual item such as a trophy may be placed in the transferee's virtual room.

Token rights are not limited to trophies. For example, token rights may include various game-related items and events other than trophies, such as exclusive costumes, equipment, stages, and lottery rights. Also, as a token-based right, it may be possible to distribute moving images of the inside of a virtual room via a communication network.

(2) Tokens may be purchased by tournament operators after the game. For example, it is conceivable to have a system in which the operator buys the game after a certain number of wins. This encourages participation in the game. As a result, the use of the game system 1 is activated.

Of course, token buyers are not limited to tournament operators. For example, the sponsor may purchase tokens after the game. A sponsor can be either a tournament sponsor or a player sponsor. Token purchases by sponsors, for example, can be funded by participation fees for tournaments with sponsors.

In this way, by exchanging funds via tokens, the flow of money can be clarified. For example, when operating this computer system in a country where it is legally required that "participation fees are not the source of prize money", exchanging funds via tokens makes it easier to comply with such laws. can handle.

In addition, the target of tokenization (target of transaction) is not limited to rights related to replay data. For example, the following matters can be exemplified.

Game save data (data that allows the game to be restarted from the middle) may be tokenized. By doing so, the use of the game system 1 is activated.

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

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

If you are participating in the game on a team-by-team basis, you may tokenize ownership of the team itself. As a result, for example, when opponents are tiered according to strength, it is possible to immediately play in the stronger tier.

Game outcome information may be tokenized if the game outcome is not valid. Blockchain holding this token can be used, for example, as a database of cheating players.

The type of game is not limited to the illustrated fighting game. The game system 1 (computer system) can be used for various game plays. For example, games are not limited to interpersonal battles. Also, the game may be a game played by a plurality of players in cooperation with each other, or may be a game played individually (for example, time attack). The game system 1 may be configured to tokenize these game results (for example, time of time attack).

If there is no problem with the verification result, the referee may return the result from the referee terminal 4 to the server device 2 as it is, or may cause the authentication device 7 for the next game to read the QR code.

Player and referee authentication is not limited to the illustrated flow. For example, the referee may transmit information accompanying the QR code of the legitimate player to the server device 2, and the authentication result may be transmitted from the server device 2 to the player terminal 3 of the player. Also, the referee and the player may transmit the information accompanying the QR code to the server apparatus 2, and if both QR codes are valid, the legitimacy may be authenticated.

Result information is not limited to what is illustrated. The game result information includes all information related to the game. For example, the game result information includes the character used, various times, the player ID and information associated with it, the type and number of techniques used, the number of combos (successive techniques), and the maximum damage combo. The game result information may also include information specifying the commentator, commentator, venue name, tournament name, and controller name used.

If the distributed ledger is configured with a blockchain, it may be possible to configure a cross-chain with another blockchain. For example, it is conceivable to configure a cross-chain with a virtual currency blockchain or a cross-chain with a game currency blockchain. Also, cross-chains with blockchains that manage other games (or competitions) may be configured.

A server (token management server) that keeps blocks (that is, tokens) may be constructed. The server device 2 of the game system 1 may be used as the token management server, or another server may be prepared as the token management server. By providing the token management server, the burden on the token owner (for example, security management) is reduced. Even in this case, for example, the player (token owner) can replay the game on his/her own game device 5 or display a virtual trophy in the virtual space based on the ownership of the token.

If the umpire is unreliable, another umpire may be asked to help with the decision, or joint evaluation may be carried out with AI (artificial intelligence). In addition, joint evaluation between humans (referees) and AI may always be performed.

A single player may be allowed to use multiple controllers. For example, it is conceivable that a mouse and a keyboard can be used together.

The type of controller is not limited as long as it can be used for input. For example, a device operated only by voice or line of sight may be employed as the controller.

There may be two or more game devices 5 for game play. Also, an online game by a plurality of game devices 5 or a game by short-distance communication may be used.

The installation location of the authentication device 7 is not limited. For example, the authentication device 7 may be installed at the venue of the tournament. The authentication device 7 may be composed of a portable terminal. For example, a smart phone may be adopted as the portable terminal, and an authentication application may be installed on it to perform the role of an authentication device.

The referee and player IDs may be common. For example, such an operation is conceivable when there is a referee who also serves as a player. In that case, the credibility as a referee (see Embodiment 2) may be evaluated according to the player's track record. For example, it is conceivable that a referee who is also active as a player may be less reliable as a referee. In addition, even though the ID can be shared, if it is found that the player's ID and the referee's ID are registered, a penalty may be imposed.

A video site dedicated to reproducing videos such as replays related to tokens may be constructed, or in-game content based on tokens may be provided.

A 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 predetermined terminal (for example, a portable terminal such as a smart phone) can be used for tokenization. In this case, the terminal may be configured to perform the following operations and processes.
(1) Enter the match results in the form displayed on the terminal.
(2) Next, tokenization (generation of blocks) is performed by the terminal based on the form input.
(3) Connect the block to the blockchain using a terminal.

The game system 1 (computer system) may be configured so that the match result is sent to the loser. The player terminal 3 of the loser can be exemplified as a transmission destination of the match result. The transmission of the battle result to the loser may be performed by the server device 2, or another device may be prepared.

Even when these other embodiments are employed, the effects of the present invention are exhibited. Further, it is also possible to appropriately combine this embodiment with other embodiments, and other embodiments with each other.

1 Game system (computer system)
5 game device (computer)
43 Result Authentication Section (Authentication Section)
236 authentication unit 231 recording unit 232 transfer unit 233 mediation unit 234 notification unit 235 information acquisition unit

Claims (3)

A computer system that manages the results of a game played via a computer,
a recording unit for recording, in a distributed ledger, transaction information, which is information linking game result information of the game and information specifying a player corresponding to the game result information, in the transaction information; contains data indicating entitlements attached to game results;
A computer system, wherein the right is a right pertaining to replay data that reproduces the progress of the game. A computer system that manages the results of a game played via a computer,
a recording unit that records, in a distributed ledger, transaction information, which is information linking game result information of the game and information specifying a player corresponding to the game result information;
An authentication unit that authenticates the legitimacy of the game result,
The recording unit distributes, as the transaction information, information linking information of the game result authenticated by the authentication unit with information specifying a player corresponding to the information of the authenticated game result. Record in the type ledger,
The game result information is associated with information specifying a judge who made a judgment related to the game,
an information acquisition unit that acquires the profile information from a database containing the profile information of the judge;
The computer system, wherein the authentication unit uses the information of the profile obtained by the information acquisition unit for the judgment of validity. In either claim 1 or claim 2,
A computer system, wherein the game result information includes information specifying a tournament in which the game was played.

Images