Method for purchasing replay animation, game providing system, and computer program

Abstract

To propose a purchasing method of a replay animation capable of purchasing a replay animation that satisfies a purchasing condition by reducing time and trouble.SOLUTION: With a purchasing method of a replay animation, a replay animation in a game providing system is purchased. In the purchasing method of a replay animation, a processor of a game providing system determines whether a purchasing condition in which a game history is prescribed is satisfied, and transmits information regarding a replay animation of a game based on the game history to a purchasing server (S34) when the game history satisfies the purchasing conditions (S32, S33).SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] The present disclosure relates to a method for purchasing replay videos, a game providing system, and a computer program. [Background technology]

[0002] For example, a system for editing a replay video of a game is known, as disclosed in Japanese Patent Application Laid-Open No. 2022-002705 (hereinafter referred to as Patent Document 1). The replay video is generated based on a play video of a game played in response to a user's operation. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2022-002705 Summary of the Invention

[0004] Replay videos may be provided to a requester for a fee. Therefore, when purchasing replay videos from a user who is a player, high skill and entertainment value are desired. However, when purchasing, it is cumbersome for an operator to judge whether the game play satisfies the purchase conditions such as high skill and entertainment value. Furthermore, when a user who is a player is asked to provide a replay video that satisfies the purchase conditions, there is a variation in judgment, and it may not be possible to purchase a replay video that satisfies the purchase conditions. Furthermore, when a user is asked to provide a replay video that satisfies the purchase conditions, the user's efforts at the time of purchase become cumbersome. Therefore, there is a demand for a replay video purchasing method, a game providing system, and a computer program that can purchase a replay video that satisfies the purchase conditions with reduced efforts.

[0005] According to one embodiment, a method for purchasing replay videos is a method for purchasing replay videos in a game providing system, the method being implemented in a management server of the game providing system, the method comprising: a processor of the management server determining whether a game history satisfies a specified purchasing condition, and, if the game history satisfies the purchasing condition, transmitting information on the game replay videos based on the game history to a purchasing server.

[0006] Further details will be described in the following embodiments. [Brief description of the drawings]

[0007] [Figure 1] FIG. 1 is a diagram showing an overview of services provided by a game providing system according to an embodiment. [Diagram 2] FIG. 2 is a schematic diagram of the game providing system. [Diagram 3] FIG. 3 is a diagram showing a specific example of the configuration of a database stored in a management server included in the game providing system. [Figure 4] FIG. 4 is a diagram showing an example of the flow of a service providing method in the game providing system. [Diagram 5] FIG. 5 is a flowchart showing an example of the flow of processing in the management server. [Figure 6] FIG. 6 is a flowchart showing an example of the flow of processing in the management server. [Figure 7] FIG. 7 is a diagram showing an example of the flow of a method for purchasing replay videos. [Figure 8] FIG. 8 is a flowchart showing an example of the flow of the purchase process in the management server. [Figure 9] FIG. 9 is a diagram showing an example of a display screen of a terminal device when a user registers in the game providing system. [Figure 10] FIG. 10 is a flowchart illustrating an example of a wallet generation process in the management server. [Figure 11]FIG. 11 is a diagram showing an example of a method for managing digital assets in a game providing system. [Figure 12] FIG. 12 is a flowchart showing an example of a digital asset management process in the management server. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] <1. Overview of the replay video purchasing method, game provision system, and computer program> (1) A method for purchasing replay videos according to an embodiment is a method for purchasing replay videos in a game providing system. The method for purchasing replay videos includes a processor of the game providing system determining whether a game history satisfies a specified purchase condition, and if the game history satisfies the purchase condition, transmitting information about the game replay video based on the game history to a purchasing server.

[0009] The purchase conditions are conditions that the replay video purchased by the purchasing server must satisfy. The purchase conditions are, for example, that the player has achieved a high ranking, that the player has played at a level of difficulty or above a predetermined level, that the number of times of such playing is greater than or equal to a predetermined number, and that at least two of these conditions are satisfied. In the replay video purchasing method according to the embodiment, the processor determines whether the game history satisfies the specified purchase conditions. This reduces the effort required for the operator or player to make a judgment. In addition, the variation in judgment is reduced compared to when the operator or player makes the judgment, and replay videos that satisfy the purchase conditions can be purchased.

[0010] (2) In the method for purchasing replay videos described in (1), preferably, the game history includes a key log, and the information on the replay video includes a key log. This makes it possible to reduce the amount of communication traffic required for purchasing a reply video compared to the case of transmitting the video.

[0011] (3) In the method for purchasing replay videos according to (1) or (2), the sending of the replay video to the purchasing server preferably includes reading out a part of the game history to be sent to the purchasing server, thereby making it possible to purchase information on the replay video within the required range.

[0012] (4) The replay video purchasing method according to (1) to (3) preferably further includes a processor that determines a reward to be paid for purchasing the replay video based on the game history. In this way, when purchasing the replay video, a reward based on the game history is paid. This provides a sense of fairness to the player and increases the player's motivation to play the game.

[0013] (5) A game providing system according to an embodiment is a game providing system that provides a game to a user, and includes a management server and a user's terminal device. The management server is configured to receive game operation information from the terminal device, determine whether the game history based on the operation information satisfies a specified purchase condition, and transmit information about a game replay video based on the game history to a purchase server if the game history satisfies the purchase condition. In the game providing system according to an embodiment, a processor determines whether the game history satisfies the specified purchase condition. This reduces the effort required for an operator or player to make a decision. In addition, the variation in judgment is reduced compared to when the operator or player makes the decision, and a replay video that satisfies the purchase condition can be purchased.

[0014] (6) A computer program according to an embodiment is a computer program that causes a computer included in a game providing system to execute a process for purchasing replay videos in the game providing system. The computer program causes the computer to determine whether or not a game history satisfies a specified purchase condition, and, if the game history satisfies the purchase condition, transmit information about the game replay video based on the game history to a purchase server. The computer program according to an embodiment causes a processor to determine whether or not a game history satisfies a specified purchase condition. This reduces the effort required for an operator or player to make a judgment. In addition, it is possible to purchase replay videos that satisfy the purchase condition with less variation in judgment than when an operator or player makes a judgment.

[0015] <2. Examples of methods for managing digital assets, game provision systems, and computer programs> [Service Overview] Fig. 1 is a diagram showing an overview of services provided by a game providing system 100 (Fig. 2) according to an embodiment. A user 6, who is a player, accesses the game providing system 100 using a terminal device 5 such as a smartphone or a personal computer, and plays a game provided by the game providing system 100. Playing a game includes the user 6 performing touch operations while viewing the display screen of the terminal device 5. Information capable of identifying an operation performed by the user 6 (hereinafter, operation information) is transmitted from the terminal device 5 to the game providing system 100.

[0016] The game providing system 100 provides the user 6 with the opportunity to play the first game in accordance with operation information from the terminal device 5 (step S1). The game providing system 100 provides the first game to anyone in exchange for payment of a predetermined fee (charge). In other words, anyone can play the first game by paying a fee.

[0017] When the user 6 meets (clears) a predetermined condition in the first game, the game providing system 100 pays out a ticket to the user 6 (step S2). The predetermined condition is a condition that indicates that the user 6 has made a high contribution to the first game, and is also referred to as a "ticket acquisition condition" in the following description. The ticket acquisition condition is, for example, that the user 6 has achieved a predetermined or higher result in the first game, played the first game for a predetermined or longer time, paid a predetermined or higher amount, or achieved a combination of two or more of these.

[0018] The ticket may be used as a payment that the user 6 pays to play the subsequent second game. The ticket may be, for example, digital data (e.g., a digital ticket). Issuing a ticket refers to the game providing system 100 issuing the ticket to the user 6. Here, the game providing system 100 performs a process of converting the ticket into an NFT (Non-Fungible Token) (step S7). As a result, the ticket issued to the user 6 may become a subject of buying and selling in a third-party market.

[0019] When the user 6 pays a predetermined number of tickets as a fee, the game providing system 100 provides the user 6 with the opportunity to play the second game in accordance with the operation information from the terminal device 5 (step S3). In other words, the right to challenge the second game is only obtained after the user pays a predetermined number of tickets obtained by satisfying a predetermined condition in the first game.

[0020] It is assumed that the first game and the second game are different games, and the second game is more popular than the first game. For example, the first game and the second game are slot games with different levels of difficulty, and the first game is a slot game that does not require careful timing, and the second game is a slot game that requires careful timing. A slot game that requires careful timing requires the user to have operation skills.

[0021] If the result of the second game satisfies a predetermined condition, the game providing system 100 permits the user 6 to participate in the final (third game) (step S4). The predetermined condition is that the result is above a predetermined level, for example, that the score is above a threshold, that the ranking is within a predetermined high-ranking range, that the score reaches a predetermined number of points within a predetermined time, and so on, and will be referred to as "conditions for advancing to the higher ranks" in the following description. The game in the final may be the same game as the second game, or it may be a different game, or it may be the same game with different rules. Here, it is assumed to be the same game. In other words, it is assumed to be the second game.

[0022] When the user 6 meets (clears) a predetermined award condition in the final game, the game providing system 100 provides the user 6 with a prize provided by the sponsor server 2 described later (step S5). The award condition may be, for example, that the user 6 achieves a high ranking in the final game, that the user 6 performs a play of a predetermined difficulty level or higher, which is called a super play, and that the number of such plays is a predetermined number or more, and that two or more of the above conditions are satisfied. As an example, the prize provided by the sponsor server 2 is provided to the user 6 in the form of points in the game providing system 100. The points may be used for charging for the first game. The points may also be used for items required for playing the game or for charging during the game. The prize may also be converted into digital assets such as cryptocurrency, as described later.

[0023] Furthermore, when the user 6 satisfies a predetermined purchase condition in the final game, the game providing system 100 performs a process for purchasing the replay video by the replay video acquisition server 4, which will be described later (step S6). The purchase condition is a condition that the replay video purchased by the replay video acquisition server 4 must satisfy, and may be the same as or different from the award condition. In other words, the purchase condition may be, for example, that the user 6 achieves a high ranking in the final game, plays at a level of difficulty or above, the number of times of such playing is a predetermined number or more, and at least two of such conditions are satisfied.

[0024] The game providing system 100 may obtain the replay video purchased by the replay video acquisition server 4 from the replay video acquisition server 4 and distribute it (step S7). Distribution here refers to providing the replay video to the requester for a fee. The replay video refers to a video that reproduces the play video based on the play video, which is the screen transition displayed on the terminal device 5 while the user 6 is playing in the final match. This allows the requester to view the state of the user 6's play in the final match.

[0025] [System Configuration] Fig. 2 is a schematic diagram of the game providing system 100. The game providing system 100 includes a management server 1. Fig. 3 is a diagram showing a specific example of the configuration of a database (DB) stored in the management server 1.

[0026] The management server 1 is, for example, configured by a computer having a processor 11, which is a controller, and a memory 12, or by one computer and its peripheral devices. The management server 1 may also be realized by a plurality of computers working together.

[0027] The processor 11 is, for example, a CPU (Central Processing Unit). The memory 12 includes, for example, a ROM (Read Only Memory), a RAM (Random Access Memory), etc. The memory 12 stores a program 121 to be executed by the processor 11.

[0028] The processor 11 executes the program 121 to execute the first game processing 111. The first game processing 111 includes providing the user 6 with a play of the first game (step S1 in FIG. 1), paying out a ticket (step S2), and converting the ticket into an NFT (step S7). The processor 11 executes the program 121 to execute the second game processing 112. The second game processing 112 includes providing the user 6 with a play of the second game (step S3), providing a prize (step S5), and purchasing a replay video (step S6). The processor 11 executes the program 121 to execute the management processing 113. The management processing 113 includes registering the user 6 in the game providing system 100, managing digital assets stored in the wallet of the user 6, and the like. Each process will be described later.

[0029] The memory 12 has a user information DB 122 which is a storage area for storing user information. Fig. 3 is a diagram showing a specific example of the configuration of the user information DB 122. As shown in Fig. 3, user information 220-1 to 220-n (collectively referred to as user information 220) for each user 6 is registered in the user information DB 122. In the example of Fig. 3, n pieces of user information 220 are registered in the user information DB 122. The user information 220 includes identification information (ID) 221 of the user 6, a wallet code 222, owned tickets 223, a key log 224, game information 225, and owned points 226.

[0030] The ID 221 indicates identification information of the user 6 in the game providing system 100. The ID 221 may be used as login information for the game providing system 100. The wallet code 222 indicates authentication information in the wallet server 8 described below, and includes, for example, a password.

[0031] The owned tickets 223 include information indicating the number of tickets owned by the user 6. The number of tickets owned by each user 6 is registered in the user information 220. The owned points 226 is a so-called wallet inside the game providing system 100, and includes information indicating the points owned by the user 6.

[0032] The key log 224 is an operation history of the user 6 while playing a game, and is collected by a key logger (not shown). The game information 225 refers to information on the game played by the user 6. By registering the key log 224 and the game information 225 in the user information 220, a history of what was played in which game for each user 6 is recorded, and the state at the end of play is also recorded.

[0033] A replay video of the user 6 is generated from the key log 224 and the game information 225. There are various known methods for generating a replay video from a key log, and the method is not limited to a specific method here. Instead of or in addition to the key log 224 and the game information 225, a play video may be registered in the user information 220.

[0034] The game providing system 100 includes a terminal device 5 used by a user 6. The terminal device 5 is capable of communicating with the management server 1 via a network 7 such as the Internet. The terminal device 5 is an example of an interface (i.e., an input device and an output device) for the user 6 who uses the game providing system 100.

[0035] The terminal device 5 is configured as a computer having a processor 51, which is a controller, and a memory 52, or a single computer and its peripheral devices. The terminal device 5 is, for example, a smartphone, a tablet, a personal computer, etc. The terminal device 5 may be realized by a plurality of computers working together. The processor 51 is, for example, a CPU. The memory 52 includes, for example, a ROM, a RAM, etc. The memory 52 stores a program 521 executed by the processor 51.

[0036] The terminal device 5 includes a touch panel 53. The touch panel 53 is an example of an input device that accepts input from the user 6, and is also an example of a playback device for the first game and the second game.

[0037] The management server 1 is capable of communicating with the sponsor server 2, the replay video acquisition server 4, and the wallet server 8 via the network 7. The sponsor server 2, the replay video acquisition server 4, and the wallet server 8 are each configured as a computer different from the management server 1, or a computer different from the management server 1 and its peripheral devices.

[0038] The sponsor server 2 provides prize money to players in the final game. The sponsor server 2 is, for example, a server device operated by a sponsor of the game providing system 100.

[0039] The replay video acquisition server 4 purchases the replay video from the user 6 in the final match. When purchasing the replay video from the user 6, the replay video acquisition server 4 may provide a reward to the user 6.

[0040] The wallet server 8 has a storage area called a wallet for storing digital assets such as crypto assets and NFTs. The wallet server 8 connects to external devices such as NFT markets and crypto asset exchanges to transfer digital assets. The wallet server 8 has multiple wallets, for example, one for each user. Digital assets in the wallet are managed by authentication using a wallet code 222.

[0041] The management server 1 can access the ticket DB 9 via the network 7. The ticket DB 9 is, for example, configured by one or more computers. The ticket DB 9 stores tickets (hereinafter also referred to as NFT tickets) that the management server 1 has converted into NFTs in the first game process 111. Converting a ticket (digital ticket) into an NFT means associating the ticket with an NFT. The ticket DB 9 stores the correspondence between each of the tickets 91A, ... 91N (represented by ticket 91) and the NFT IDs 92A, ... 92N (represented by ID 92).

[0042] The blockchain 3 is configured by a network system in which multiple computers are interconnected. The management server 1 can access the blockchain 3 via the network 7.

[0043] The multiple computers that make up blockchain 3 store in a distributed manner the correspondence between each of the multiple NFTs 31A, 3...31N (collectively referred to as NFT 31) and the IDs 32A, ...32N (collectively referred to as ID 32) of the users who own them.

[0044] A smart contract 33 is implemented in the blockchain 3. The smart contract 33 is software (computer program) implemented in the blockchain 3, and is automatically executed according to predetermined conditions. The smart contract 33 performs processes such as recording the owner of the NFT 31 in the blockchain 3, rewriting the owner, and updating the transaction history. In this way, transactions of the NFT 31 are realized.

[0045] [System configuration variations] 2 is an example of the system configuration of the game providing system 100. As another example, the ticket DB 9 may be included in the management server 1. Furthermore, the user information DB 122 may be stored in a device outside the management server 1.

[0046] [Service provision method] Fig. 4 is a diagram showing an example of the flow of a service providing method in the game providing system 100. Fig. 4 shows the operations of each device included in the game providing system 100 and the relationships between them.

[0047] 4, when the terminal device 5 receives an operation related to playing the first game from the user 6 (steps S11, S17), it transmits a play request to the management server 1 in accordance with the operation of the user 6 (steps S12, S18). The request includes the ID of the user 6 and operation information indicating the operation of the user 6. When the management server 1 receives the request from the terminal device 5, it executes processing related to the game (steps S13, S19).

[0048] In detail, when the terminal device 5 receives an operation to start playing the first game from the user 6 in step S11, the terminal device 5 transmits operation information indicating an instruction to start playing the first game together with the ID of the user 6 to the management server 1 in step S12. In step S11, the terminal device 5 further receives an operation to pay a fee. In step S12, the terminal device 5 transmits payment information indicating the payment of the fee to the management server 1. If the paid fee is a specified fee, in step S13, the management server 1 causes the user 6 to start playing the first game in response to the request from the terminal device 5.

[0049] During the play of the first game, the terminal device 5 receives an operation from the user 6 instructing play actions for the first game in step S11. In step S12, the terminal device 5 transmits operation information indicating the content of the play action instructions to the management server 1. In step S13, the management server 1 progresses the first game in accordance with the operation information from the terminal device 5. This allows the user 6 to play the first game using the terminal device 5.

[0050] When the play of the first game by the user 6 satisfies the ticket acquisition condition, the management server 1 pays out a ticket to the user 6 (step S16). Specifically, the management server 1 converts the ticket in the ticket database 9 into an NFT by storing a correspondence between the ticket and the NFT (step S14). In addition, the management server 1 causes the smart contract 33 of the blockchain 3 to record the ID of the user 6 as the owner of the NFT in the blockchain 3 (step S15).

[0051] Upon receiving an operation from the user 6 to start playing the second game in step S17, the terminal device 5 transmits operation information indicating an instruction to start playing the second game together with the ID of the user 6 to the management server 1 in step S18. In step S17, the terminal device 5 further receives an operation to pay a predetermined number of tickets as payment. In step S18, the terminal device 5 transmits ticket information indicating the payment of the predetermined number of tickets to the management server 1. When the predetermined number of tickets has been paid, in step S19-1, the management server 1 causes the user 6 to start playing the second game in response to the request from the terminal device 5.

[0052] During the play of the second game, the terminal device 5 receives an operation from the user 6 instructing play actions for the second game in step S17. In step S18, the terminal device 5 transmits operation information indicating the contents of the play action instructions to the management server 1. In step S19-1, the management server 1 progresses the second game in accordance with the operation information from the terminal device 5. This allows the user 6 to play the second game using the terminal device 5. At this time, the management server 1 also registers the key log 224 and game information 225 in the user information 220 of the user 6.

[0053] When the play of the second game by the user 6 satisfies the conditions for advancing to a higher rank, in step S19-2 the management server 1 starts the play of the final match of the second game with the user 6. During the play of the final match, in step S17 the terminal device 5 receives an operation from the user 6 instructing the play action of the second game. In step S18, the terminal device 5 transmits operation information indicating the content of the instruction for the play action to the management server 1. In step S19-2, the management server 1 proceeds with the final match according to the operation information from the terminal device 5. This allows the user 6 to play the second game in the final match using the terminal device 5. At this time, the management server 1 also registers the key log 224 and the game information 225 in the user information 220 of the user 6.

[0054] If the play by the user 6 in the final game satisfies the conditions for winning the prize, the management server 1 receives the prize money from the sponsor server 2 (step S20) and transmits it to the terminal device 5 of the user 6 (step S21).

[0055] When the play by user 6 in the final game satisfies the purchase condition, the management server 1 executes a process for the replay video acquisition server 4 to purchase the replay video of user 6 (step S22). The management server 1 receives a reward from the replay video acquisition server 4 (step S23) and transmits it to the terminal device 5 of user 6 (step S24).

[0056] [Variations in service provision methods] 4 is one example of the process flow between the management server 1 and the terminal device 5 for realizing the service providing method in the game providing system 100. As another example, at least a part of the process in the management server 1 described below may be performed by the terminal device 5, or at least a part of the process in the terminal device 5 may be performed by the management server 1.

[0057] [Administration Server Processing] 5 and 6 are flowcharts showing an example of a processing flow in management server 1. As shown in Fig. 5, when an operation to start playing the first game is received from user 6 in step S11 in Fig. 4 (YES in step S101), processor 11 of management server 1 executes first game processing 111.

[0058] In detail, processor 11 determines whether the fee paid by user 6 satisfies the charging condition for providing the first game, based on the information sent from terminal device 5 in step S12. If the charging condition is satisfied, that is, if the specified fee has been received from user 6 (YES in step S103), processor 11 starts the first game (step S105). In step S105, processor 11 plays the first game from the beginning, as an example, and transmits information for screen display to terminal device 5. This allows user 6 to play the first game using terminal device 5.

[0059] As another example, the processor 11 may transmit information from the end of the most recent first game to the terminal device 5 based on the key log 224 and the game information 225 registered in the user information 220 of the user 6. This allows the user 6 to continue playing the first game from where it was most recently ended.

[0060] When processor 11 receives operation information indicating an operation of the first game from terminal device 5 (YES in step S107), it progresses the first game in accordance with the operation of user 6 and updates the screen displayed on terminal device 5 (step S109), and registers key log 224 and game information 225 based on the user operation in user information 220 of user 6. If processor 11 does not receive operation information from terminal device 5 for a predetermined time (NO in step S107), it may end the process or may notify an error.

[0061] The processor 11 determines whether or not the ticket acquisition condition is satisfied based on the operation information from the terminal device 5. If the operation information from the terminal device 5 satisfies the ticket acquisition condition (YES in step S111), the processor 11 issues the ticket 91 (step S113). In step S113, the processor 11 generates the ticket 91 and converts it into an NFT.

[0062] In detail, in step S113, the processor 11 registers the correspondence between the generated ticket (digital ticket) 91 and the ID 92 of the NFT 31 in the ticket DB 9. Furthermore, in step S113, the processor 11 passes the correspondence between the NFT 31 and the ID 32 of the user 6 to the smart contract 33 of the blockchain 3, and causes the blockchain 3 to record the ID 32 of the user 6 as the owner of the NFT 31.

[0063] Processor 11 repeats the above process until an operation to end the game or an operation to start playing the second game is received from terminal device 5 (NO in step S115, NO in step S117). When an operation to end the game is received from terminal device 5 (YES in step S115), processor 11 ends the process.

[0064] When processor 11 receives an operation to start playing the second game from user 6 in step S17 of Fig. 4 (YES in step S117), processor 11 executes second game process 112. In detail, processor 11 determines whether or not a predetermined number of tickets have been paid. When processor 11 determines that a predetermined number of tickets have been paid (YES in step S119), processor 11 starts the second game (step S121).

[0065] 6, when processor 11 receives operation information indicating an operation of the second game from terminal device 5 (YES in step S205), processor 11 progresses the second game in accordance with the operation of user 6, updates the screen displayed on terminal device 5 (step S207), and registers key log 224 and game information 225 based on the user operation in user information 220 of user 6. If processor 11 does not receive operation information from terminal device 5 for a predetermined time (NO in step S205), processor 11 may end the process or may notify an error.

[0066] Processor 11 determines whether or not the performance of user 6 in the second game satisfies the condition for advancing to the higher ranks based on the operation information from terminal device 5. If the operation information from terminal device 5 satisfies the condition for advancing to the higher ranks (YES in step S209), processor 11 switches the second game provided to terminal device 5 to the game of the final match (step S211). This allows user 6 to participate in the final match (higher rank game). In step S211, processor 11 notifies terminal device 5 that it has acquired the right to participate in the final match, and may switch the second game provided to terminal device 5 to the game of the final match when instructed by terminal device 5 to participate.

[0067] Similarly, in the final match, when processor 11 receives operation information indicating game operation from terminal device 5 (YES in step S213), it progresses the game of the final match in accordance with the operation of user 6, updates the screen displayed on terminal device 5 (step S215), and registers key log 224 and game information 225 based on the user operation in user information 220 of user 6 (step S217).

[0068] In the above explanation, the key log 224 and the game information 225 are registered in the user information 220 of the user 6 for both the first game and the second game, but the key log 224 and the game information 225 may be registered only for the final game, as shown in Figures 5 and 6.

[0069] Processor 11 repeats the above process until an operation to end the game is received from terminal device 5 (NO in step S219). When an operation to end the game is received from terminal device 5 (YES in step S219), processor 11 executes a process for allowing replay video acquisition server 4 to purchase the replay video of the final match by user 6 (step S221). The purchase method in step S221 will be described later.

[0070] The processor 11 further determines whether or not the play by the user 6 in the final game satisfies the award condition based on the key log 224 and the game information 225. If the play by the user 6 satisfies the award condition (YES in step S223), the processor 11 executes a process for the sponsor server 2 to pay the prize money (step S225) and ends the process. If not (NO in step S223), the processor 11 skips step S225 and ends the process.

[0071] Specifically, in step S225, the processor 11 adds the prize money received from the sponsor server 2 as points to the owned points 226 in the user information 220 of the user 6. The processor 11 may also notify the terminal device 5 that the prize money has been provided by the sponsor server 2, and cause it to output a notification screen or a notification sound. The processor 11 may also notify the terminal devices 5 of the other users participating in the final round that the prize money has been provided to the user 6 by the sponsor server 2, and cause it to output a notification screen or a notification sound.

[0072] [How to purchase replay videos] 7 is a diagram showing an example of the flow of a replay video purchasing method. FIG. 8 is a flowchart showing an example of the flow of a purchasing process in the management server 1.

[0073] As shown in Fig. 7, when providing the second game (higher game) in the final round to the user 6, the game providing system 100 allows the user 6 to compete for points by comparing the scores of the other users in the final round (step S31). When the user 6 is ranked among the top performers and satisfies the purchase condition (step S32), a screen for purchasing the replay video is displayed on the game screen of the terminal device 5 (step S33). As an example, as shown in Fig. 7, the purchase screen includes a button 331 for instructing whether or not to purchase the replay video, and accepts an input of an instruction from the user 6 as to whether or not to purchase the replay video.

[0074] When the user 6 issues an instruction to purchase a replay video from the terminal device 5, the replay video is uploaded (purchased) in the replay video acquisition server 4. The game providing system 100 also gives the reward received from the replay video acquisition server 4 to the user 6 as points (step S34).

[0075] In steps S31 and S32, a plurality of users including the user 6 may play the same game (final match) at the same time and compete with each other for points. In this case, the game providing system 100 determines the top performers by comparing the scores of the plurality of users at the end of the game. That is, in this case, the game providing system 100 determines whether the purchase conditions are satisfied at the end of the final match.

[0076] In steps S31 and S32, as another example, each user may play the game (final match) individually, and the score of each user may be stored in the game providing system 100. In this case, the game providing system 100 may compare the stored scores of each user at a predetermined timing to determine the top performers. That is, in this case, the game providing system 100 determines whether or not each user satisfies the purchase condition at a predetermined timing after the end of the final match.

[0077] As shown in Fig. 8, when the final match ends, the processor 11 of the management server 1 determines whether the above-mentioned purchase conditions are satisfied based on the key log 224 and game information 225 of the user information 220 of the user 6. If it is determined that the purchase conditions are satisfied (YES in step S301), the processor 11 causes the terminal device 5 to display the purchase screen of step S33 in Fig. 7 (step S305). This allows the user 6 to instruct whether or not to allow the replay video acquisition server 4 to purchase the replay video.

[0078] When a signal indicating that a user operation has been performed to instruct purchase on the purchase screen is input from the terminal device 5 (YES in step S307), the processor 11 reads out a key log from the user information 220 of the user 6 (step S309) and transmits it to the replay video acquisition server 4 (step S311). The processor 11 also pays the reward received from the replay video acquisition server 4 to the user 6 (step S313). Specifically, in step S313, the processor 11 adds points corresponding to the received reward to the owned points 226 in the user information 220 of the user 6. This increases the points held by the user 6 by the amount of the reward.

[0079] In step S309, the processor 11 reads, as an example, a key log from the start to the end of the final match from the key log 224 and the game information 225 of the user information 220 of the user 6. As another example, in step S309, the processor 11 may read a key log of a specified range from the key log 224 and the game information 225 of the user information 220 of the user 6. The range may be specified, as an example, by an elapsed time, or may be specified by an operation of the user 6, such as an operation interval. The range may also be specified by at least one component constituting the replay video, such as the characters appearing, the number of characters, a scene, a sound volume, or a combination thereof. The range may be specified in advance, or may be specified or changed by the user 6, the replay video acquisition server 4, or the like.

[0080] In step S309, as one example, the processor 11 transmits the key log read in step S309 to the replay video acquisition server 4. This allows a replay video to be generated in the replay video acquisition server 4. Also, the amount of communication during purchase can be reduced. In another example, in step S309, the processor 11 may generate a replay video from the key log read in step S309 and transmit the video data to the replay video acquisition server 4. This allows the processing load on the replay video acquisition server 4 to be reduced. Also, when a play video is recorded in the user information 220 instead of or in addition to the key log 224 and the game information 225, in another example, the processor 11 may transmit the play video to the replay video acquisition server 4 in step S309.

[0081] When it is determined that the play of the user 6 satisfies the purchase condition, the processor 11 may determine a reward and make a request to the replay video acquisition server 4 (step S303). That is, the reward for purchase may be variable. In this case, in step S305, the processor 11 may present the reward on the purchase screen. This allows the user 6 to consider whether or not to purchase the game while taking the reward into account.

[0082] For example, the reward may be determined according to the possibility of earning revenue by distributing the replay video in step S7 of FIG. 1. The revenue by distributing the replay video may be, for example, revenue based on the number of views by displaying advertisements, or support money from viewers called tips. Therefore, for example, the reward for purchasing may be higher for videos that are likely to be viewed many times and that are likely to earn tips, and lower for those that are not. Specifically, the reward may be determined according to the presence or absence of plays by the user 6 that are at a difficulty level equal to or higher than a specified difficulty level, called super plays, the number of super plays, the play time, the popularity (rank) of the user 6 himself, and the like.

[0083] The processor 11 has, for example, a model M (FIG. 2) for determining the remuneration for buying. The model M is, for example, an arithmetic expression for calculating the remuneration using parameters such as the presence or absence of super plays, the number of times of super plays, the play time, the rank of the user 6 himself, etc. In this case, in step S303, the processor 11 calculates the remuneration by substituting the above parameters obtained from the key log 224 and the game information 225, and / or other information of the user information 220, into the model M.

[0084] As another example, the model M may be a learning model that is machine-learned to use the key log 224, the game information 225, the replay video, and / or the user's information as input values ​​and output a reward for purchasing the replay video. In this case, the processor 11 inputs the key log 224 and the game information 225 of the user 6, the replay video, and / or the rank of the user 6 himself / herself, etc., to the model M, and obtains a reward as an output from the model M.

[0085] As another example, the remuneration may be determined according to the revenue from distributing the replay video in step S7 of Fig. 1. In this case, the ratio of the remuneration to the revenue from distribution may be predefined. Also, the ratio of the remuneration to the revenue from distribution may be predefined in stages according to the revenue.

[0086] Alternatively, in step S303, the processor 11 may determine the proportion of the reward to the revenue from the distribution. As an example, the proportion of the reward to the revenue from the distribution may be higher for those that are likely to be played many times and those that are likely to receive tips, and lower for those that are not. Or the opposite may be true. Specifically, the proportion of the reward to the revenue from the distribution may be determined based on the presence or absence of plays of a difficulty level equal to or higher than a specified difficulty level, called super plays, during the play by the user 6, the number of super plays, the play time, the popularity (rank) of the user 6 himself, and the like. The method of determination here may be the same as the method using the model M described above.

[0087] In this case, the payment of the reward in step S313 is made after the replay video is distributed, whereby a reward corresponding to the profit from the distribution is paid to the user 6.

[0088] In the game providing system 100, the replay video acquisition server 4 performs a process for purchasing replay videos, thereby reducing the effort required of the user 6 when the replay video acquisition server 4 purchases the replay videos of the user 6. Furthermore, in the game providing system 100, replay videos that are available for purchase by the replay video acquisition server 4 are appropriately extracted based on the purchase conditions. Therefore, the desired replay videos can be provided to the replay video acquisition server 4.

[0089] [How to manage digital assets] Fig. 9 is a diagram showing an example of a display screen of the terminal device 5 when a user registers in the game providing system 100. Fig. 10 is a flowchart showing an example of a wallet generation process in the management server 1. Fig. 11 is a diagram showing an example of a method for managing digital assets in the game providing system 100. Fig. 12 is a flowchart showing an example of a digital asset management process in the management server 1.

[0090] 9, when the user 6 registers in the game providing system 100, a registration screen 300 is displayed on the touch panel 53 of the terminal device 5. The registration screen 300 has fields for inputting the date of birth, email address, password, etc. as the ID of the user 6. When an instruction is given on user registration using the input information on the registration screen 300, the user information 220 for the user 6 is registered in the user information DB 122. Thus, the user registration is performed.

[0091] When the user information 220 for the user 6 is registered using the registration screen 300, the registration screen 300 transitions to a wallet generation screen 301 as shown in FIG. 9. The wallet generation screen 301 is a screen for inputting a wallet code for generating a wallet for managing the digital assets of the user 6 in the wallet server 8. As an example, the wallet generation screen 301 in FIG. 9 has an input field for a password to be used as the wallet code. When an instruction is given on the wallet generation screen 301 to generate a wallet using the input password, the wallet code 222 is registered in the user information 220. In this case, the user ID inputted through the registration screen 300 may be used as the wallet code, or the wallet generation screen 301 may further include a field for inputting an ID.

[0092] When a user 6 accesses the game providing system 100 using a terminal device 5 and requests new registration, the processor 11 of the management server 1 executes a management process 113 in accordance with a program 121. The process in Fig. 10 is realized by the processor 11 executing the program 121, and represents another example of the process when the result in step S101 in Fig. 5 is NO.

[0093] 10, if the operation received from user 6 is not an operation to start playing the first game (NO in step S101) but an operation to request new user registration (YES in step S401), processor 11 executes the processes from step S403 in FIG. 10 onward. That is, processor 11 transmits information for displaying registration screen 300 to terminal device 5, and causes registration screen 300 (FIG. 9) to be displayed (step S403). When information is input on registration screen 300 and a user operation to instruct registration is performed, the information input on registration screen 300 is transmitted from terminal device 5 (YES in step S405).

[0094] The processor 11 uses the information from the terminal device 5 to register the user 6 (step S407). Specifically, the processor 11 generates user information 220 for the user 6 and registers it in the user information DB 122. Note that the process for user registration in step S407 may be a registration process performed in a general game system.

[0095] In the management server 1 according to the embodiment, the processor 11 executes the program 121 to transmit information for displaying the wallet generation screen 301 to the terminal device 5, and causes the terminal device 5 to display the wallet generation screen 301 (step S409). When information is input on the wallet generation screen 301 and a user operation is performed to instruct registration, the information input on the wallet generation screen 301 is transmitted from the terminal device 5 (YES in step S411).

[0096] The processor 11 generates a wallet for the user 6 using the information from the terminal device 5 (step S413). Specifically, in step S413, the processor 11 registers the information input to the wallet code 222 of the user information 220 of the user 6, and also registers the owned tickets 223 as 0 and the owned points 226 as 0 points when a new wallet is created.

[0097] Furthermore, processor 11 requests wallet server 8 to generate a wallet for user 6 according to program 121 (step S415). The method of the request in step S415 is not limited and may be a method appropriate to wallet server 8. As one example, processor 11 transmits a wallet code together with the ID of user 6 to wallet server 8 to request generation of a wallet.

[0098] The above-described management method in the game providing system 100 allows the user 6 to create an external wallet in the same operational sequence as when registering as a user in the game providing system 100, without the need to connect to the wallet server 8 and input a wallet code such as an ID or password. This significantly reduces the user's workload. In addition, since the wallet server 8 obtains the wallet code from the game providing system 100, it is expected that the obtained wallet code will be more reliable than a wallet code input by the user 6 himself / herself.

[0099] When the management server 1 issues a ticket to the user 6 during game processing, it updates the owned ticket 223 of the user information 220 of the user 6. This allows the management server 1 to manage the NFT ticket, which is a digital asset. In other words, the management server 1 can be used as an internal wallet to manage the digital assets of the user 6.

[0100] On the other hand, NFT tickets can be bought and sold on external markets. In that case, the NFT ticket needs to be moved to a wallet of the user 6 on a wallet server 8 that is accessible from the external market.

[0101] 11 is an example of a user information screen 302 displayed on the terminal device 5 of the user 6 who has logged in to the game providing system 100. The user information screen 302 has the number of owned tickets as an example of digital assets that can be transferred to the wallet of the user 6 in the wallet server 8, and a button 21 for instructing the transfer to the wallet of the user 6 in the wallet server 8. When the button 21 is pressed on the user information screen 302, the screen transitions to a ticket transfer screen 303 as shown in FIG. 11. The ticket transfer screen 303 has a field 22 for specifying the number of tickets to be transferred to the wallet of the user 6 in the wallet server 8, and a button 23 for instructing the transfer.

[0102] When the number of tickets to be moved is specified on the ticket movement screen 303 and the button 23 is pressed, the processor 11 of the management server 1 executes the management process 113 in accordance with the program 121. The process in Fig. 12 is realized by the processor 11 executing the program 121, and represents another example of the process when the result in step S401 in Fig. 10 is NO.

[0103] In detail, as shown in Fig. 12, when the operation received from user 6 is not an operation to start playing the first game (NO in step S101), nor an operation to request new user registration (NO in step S401), but an operation to support display of a user information screen (YES in step S501), processor 11 executes the processing from step S503 in Fig. 12. That is, processor 11 reads user information 202 of user 6 from user information DB 122, and causes terminal device 5 to display user information screen 302 in Fig. 11 (step S503).

[0104] When a user specifies the number of tickets to be moved in field 22 on the user information screen 302 and presses button 23 to instruct the movement of the NFT tickets to the wallet (YES in step S509), the processor 11 reads the wallet code 222 from the user information 220 of the user 6 (step S511). The processor 11 transmits the wallet code 222 together with the ID of the user 6 to the wallet server 8 to authenticate the wallet of the user 6. The processor 11 then instructs the wallet server 8 to move the number of NFT tickets instructed by the terminal device 5 to the wallet of the user 6 (step S513). The processor 11 also updates the held tickets 223 in the user information 220 of the user 6 to reduce the number of tickets moved to the wallet server 8 (step S515).

[0105] The above management method in the game providing system 100 allows the user 6, who is a player logged in to the game providing system 100, to easily transfer digital assets to an external wallet server 8 by operating on a screen provided by the game providing system 100. Therefore, when exhibiting an NFT ticket on an external market, the NFT ticket can be smoothly transferred to the wallet server 8 without performing an authentication operation on the wallet server 8. This significantly reduces the user's effort. Furthermore, since the wallet server 8 performs authentication using the wallet code from the game providing system 100, a higher level of authentication can be expected than if the user 6 inputs the wallet code themselves.

[0106] <3. Notes> The present invention is not limited to the above-described embodiment, and various modifications are possible. [Explanation of symbols]

[0107] 1: Management server, 4: Server for acquiring replay video, 5: Terminal device, 6: User, 8: Wallet server, 11, 51: Processor, 100: Game providing system, 121: Program, 222: Wallet code, 223: Owned ticket, 224: Key log, 225: Game information, 226: Owned points, 300: Registration screen, 301: Wallet generation screen, 302: User information screen, 303: Ticket transfer screen.

Claims

1. A method for purchasing replay videos in a game providing system, comprising: A processor of the game providing system, Determine whether the game history meets the specified purchase conditions, If the game history satisfies the purchase condition, information regarding a replay video of the game based on the game history is transmitted to a purchase server. How to buy replay videos.

2. the game history includes a keylog; The information regarding the replay video includes the key log. The replay video purchasing method according to claim 1.

3. The transmitting to the purchase server includes reading a part of the game history to be transmitted to the purchase server. The replay video purchasing method according to claim 1.

4. The processor further comprises determining a compensation to be paid for purchasing the replay video based on a history of the game. The replay video purchasing method according to claim 1.

5. A game providing system for providing a game to a user, comprising: A management server; a terminal device of the user, The management server includes: receiving operation information of the game from the terminal device; determining whether the game history based on the operation information satisfies a specified purchase condition; and transmitting information about a replay video of the game based on the game history to a purchasing server when the game history satisfies the purchasing condition. Game provision system.

6. A computer program for causing a computer included in a game providing system to execute a process for purchasing a replay video in the game providing system, Determine whether the game history meets the specified purchase conditions, and transmitting information about a replay video of the game based on the game history to a purchasing server when the game history satisfies the purchasing condition. Computer program.

Images