Token distribution method and computer

Abstract

To allow a user who desires to receive a token to receive the token in a blockchain with less burden even if the user does not have a blockchain address.SOLUTION: A server is configured to execute processing including: receiving a token request for transmission of a token in a blockchain, from a client terminal of a user; allocating, when receiving the token request, a receiving blockchain address for receiving a token to be transmitted in accordance with the token request, to the user; and operating the blockchain so that the token is transmitted to the receiving blockchain address allocated to the user, in accordance with the received token request.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates to a server, a token distribution system, and a computer-implemented method. [Background technology]

[0002] Patent Document 1 discloses sending non-fungible tokens in a blockchain to users. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-089640 Summary of the Invention

[0004] In order for a user to receive tokens sent on the blockchain, the user must have a blockchain address. If a user does not have a blockchain address, tokens cannot be sent to that user.

[0005] A company or organization may want to widely distribute blockchain tokens, such as non-fungible tokens, to users, such as customers, for a campaign, etc. However, if the users do not have a blockchain address, they cannot receive the tokens.

[0006] If users are required to undergo the procedural burden of obtaining a blockchain address in order to receive tokens, it will be difficult to widely distribute the tokens. Therefore, for example, if the purpose of a campaign is to widely distribute tokens, the purpose of the campaign will not be achieved.

[0007] Therefore, it is desirable to enable users who wish to receive tokens to receive tokens in the blockchain with minimal burden, even if they do not have a blockchain address.

[0008] One aspect of the present disclosure is a server configured to execute a process including: receiving a token request from a user's client terminal requesting transmission of a token in a blockchain; upon receiving the token request, assigning a receiving blockchain address to the user for receiving a token transmitted in response to the token request; and operating the blockchain so that the token is transmitted to the receiving blockchain address assigned to the user in response to the received token request.

[0009] Another aspect of the present disclosure is a token distribution system configured to execute a process comprising: receiving a token request from a user's client terminal requesting transmission of a token in a blockchain; upon receiving the token request, assigning a receiving blockchain address to the user for receiving a token transmitted in response to the token request; and transmitting the token to the receiving blockchain address assigned to the user in response to the received token request.

[0010] Another aspect of the present disclosure is a computer-implemented method for distributing tokens, the method comprising: receiving a token request from a user's client device requesting transmission of tokens in a blockchain; upon receiving the token request, assigning a receiving blockchain address to the user for receiving tokens transmitted in response to the token request; and transmitting the tokens to the receiving blockchain address assigned to the user in response to the received token request.

[0011] Further details will be described in the following embodiments. [Brief explanation of the drawings]

[0012] [Figure 1] Figure 1 is a diagram of the system configuration. [Figure 2] FIG. 2 is a diagram showing the configuration of the server. [Figure 3] Figure 3 shows a diagram of a blockchain smart contract and a blockchain address. [Figure 4] FIG. 4 is a diagram showing a token distribution procedure. [Figure 5] FIG. 5 is a flowchart of the token distribution process. [Figure 6] Figure 6 is a schematic diagram showing the allocation of blockchain addresses. [Figure 7] FIG. 7 is a flowchart of the first transmission process. [Figure 8] FIG. 8 is a schematic diagram of the first transmission process. [Figure 9] FIG. 9 is a flowchart of the second transmission process. DETAILED DESCRIPTION OF THE INVENTION

[0013] <1. Overview of the server, token distribution system, and computer implementation method>

[0014] (1) A server according to an embodiment is configured to execute a process comprising: receiving a token request from a user's client terminal requesting token transmission in a blockchain; assigning a receiving blockchain address to the user for receiving the token transmitted in response to the token request upon receiving the token request; and operating the blockchain so that the token is transmitted to the receiving blockchain address assigned to the user in response to the received token request. Since the server assigns a blockchain address to the user upon receiving the token request, the user can receive the token even if they do not have a blockchain address. This reduces the burden on the user.

[0015] (2) Preferably, the process further includes determining whether or not an assigned blockchain address has been assigned to the user who is the sender of the token request. The process of assigning the receiving blockchain address to the user is preferably executed when it is determined that the assigned blockchain address has not been assigned to the user. In this case, if the assigned blockchain address has not been assigned to the user who is the sender of the token request, a blockchain address is assigned. Therefore, if the assigned blockchain address has been assigned to the user, the assignment of the blockchain address can be omitted.

[0016] (3) The token request preferably includes a first code. The processing preferably further includes determining the validity of the token request using the first code. The step of assigning the receiving blockchain address to the user is preferably performed when the token request is determined to be valid. In this case, if the token request is valid, a blockchain address is assigned, and if the token request is not valid, the assignment of the blockchain address can be omitted.

[0017] (4) The token request preferably includes a first code. The processing preferably further includes determining the validity of the token request using the first code and determining whether or not an assigned blockchain address has been assigned to the user who is the sender of the token request. The assigning of the receiving blockchain address to the user is preferably performed when the token request is determined to be valid and when it is determined that the user does not have an assigned blockchain address. In this case, when the token request is valid and when an assigned blockchain address has not been assigned, a blockchain address is assigned; otherwise, the assignment of a blockchain address can be omitted.

[0018] (5) Preferably, assigning the receiving blockchain address to the user includes assigning the receiving blockchain address to the user's account on the server. In this case, the blockchain address is assigned to the user's account on the server.

[0019] (6) It is preferable that allocating the receiving blockchain address to the user includes creating an account for the user on the server and allocating the receiving blockchain address to the created account. In this case, since a user account is also created, the user can be assigned a blockchain address even if they do not have a user account on the server.

[0020] (7) It is preferable that allocating the receiving blockchain address to the user includes selecting an allocation blockchain address to be allocated to the user from a plurality of allocation candidate blockchain addresses issued in advance, and allocating the allocation blockchain address to the user as the receiving blockchain address. In this case, the allocation of blockchain addresses can be performed quickly.

[0021] (8) Preferably, manipulating the blockchain includes invoking a smart contract configured to transmit the tokens such that the tokens are transmitted to the receiving blockchain address assigned to the user, where the smart contract transmits the tokens.

[0022] (9) Preferably, operating the blockchain further includes generating a second code and transmitting the second code to the smart contract, wherein the second code is used by the smart contract to identify a token to transmit, a type of token to transmit, or a type of token to generate for transmission.

[0023] (10) A token distribution system according to an embodiment is configured to execute a process comprising: receiving a token request from a user's client terminal requesting transmission of a token in a blockchain; upon receiving the token request, assigning a receiving blockchain address to the user for receiving a token transmitted in response to the token request; and transmitting the token to the receiving blockchain address assigned to the user in response to the received token request.

[0024] (11) Preferably, the process performed by the token distribution system further comprises, after receiving the token request, generating the token for sending to the receiving blockchain address.

[0025] (12) Preferably, the process performed by the token distribution system further comprises determining the type of the token to be generated after receiving the token request.

[0026] (13) The type is preferably determined randomly. In this case, the user can receive an NFT of a randomly determined type.

[0027] (14) A method according to an embodiment is a computer-implemented method executed by a computer for distributing tokens, comprising: receiving a token request from a user's client terminal requesting transmission of a token in a blockchain; upon receiving the token request, assigning a receiving blockchain address to the user for receiving a token transmitted in response to the token request; and transmitting the token to the receiving blockchain address assigned to the user in response to the received token request.

[0028] (15) Preferably, the computer-implemented method further comprises, after receiving the token request, generating the token for sending to the receiving blockchain address.

[0029] 2. Examples of Server, Token Distribution System, and Computer Implementation Method

[0030] Hereinafter, an example of an embodiment of the present invention will be described in more detail with reference to the drawings.

[0031] FIG. 1 illustrates an example of a system 10 according to an embodiment. The system 10 is a system that uses a blockchain 20. The system 10 according to the embodiment may constitute a token distribution system. The token distribution system distributes tokens in a blockchain to users.

[0032] The system 10 according to the embodiment may include a server 51 connected to a network 15. The network 15 is, for example, the Internet. The server 51 may access the blockchain 20 via the network 15. The server 51 may be configured by one computer or may be configured by multiple computers. The server 51 may be managed by an administrator of the system 10. The administrator may be, for example, an administrator for token distribution. The administrator may also be an administrator of a smart contract 22, which will be described later.

[0033] As shown in FIG. 2, the server 51 may be configured by a computer including a processor 51A and a storage device 51B. The storage device 51B is connected to the processor 51A. The storage device 51B includes, for example, a primary storage device and a secondary storage device. The primary storage device is, for example, a RAM. The secondary storage device is, for example, a hard disk drive (HDD) or a solid state drive (SSD). The storage device 51B includes a computer program 51C executed by the processor 51A. The processor 51A reads and executes the computer program 51C stored in the storage device 51B. The computer program 51C has program code representing instructions for causing a computer to execute a token distribution process 51K. The token distribution process 51K will be described later.

[0034] The storage device 51B may store various data or information. For example, the storage device 51B may have a judgment condition 51D. The storage device 51B may also have a code list 51E. The storage device 51B may also have a blockchain address list 51F. The storage device 51B may also have an NFT list 51G. The storage device 51B may also have an NFT type list 51H. These pieces of data or information will be described later.

[0035] The server 51, together with the client terminal 31, constitutes a client-server system. The server 51 executes processing in response to a request from the client terminal 31. The processing executed by the server 51 is, for example, a token distribution processing 51K. The server 51 receives a token request from the client terminal 31 for token distribution. Hereinafter, the server 51 that receives the token request is also referred to as a token request receiving server 51. The processing executed by the server 51 may include an address setting processing (see step S55 in FIG. 5) that assigns a blockchain address to a user. In an embodiment, the address setting processing may constitute part of the token distribution processing 51K.

[0036] The client terminal 31 is a terminal of a user who receives a token. The client terminal 31 is, for example, a smartphone, a tablet, or a personal computer. A user who wishes to receive a token operates the client terminal 31 and sends a token request from the client terminal 31 to the server 51. A user who sends a valid token request can receive the token.

[0037] In an embodiment, a code is distributed to a user by an administrator or the like so that the user can obtain a token in the blockchain. Hereinafter, the code distributed to the user is referred to as a token code or a first code. The token code is used for token distribution by the system 10. Preferably, each of the multiple token codes distributed to the user is a different, unique code. The code is, for example, a multi-digit code consisting of numbers, letters, or symbols. The token code may be expressed in, for example, a machine-readable format. The machine-readable format may be, for example, a two-dimensional code 60 or a barcode. The token code is, for example, printed on a tangible medium 101 such as paper. The token code may be distributed in a state stored in a device capable of transmitting data to the client terminal 31. The data-transmitting device is, for example, an IC tag (wireless tag) capable of communicating with the client terminal 31. The tangible medium 101 or device having the token code is distributed to the user with or without payment. The token code may be distributed to the client terminal 31 as digital data.

[0038] In the embodiment, as an example, the token code (e.g., qC2oFsNKrHimID6u) is printed on the tangible medium 101 in the form of a two-dimensional code 60 representing a uniform resource identifier 120 (URI) including the token code. The URI 120 includes a scheme and an authority. As an example, the URI here is a uniform resource locator (URL). The scheme is, for example, https:. The authority is written after the scheme and indicates the location of the resource. Note that the URI 120 does not necessarily include a scheme. Note that the tangible medium 101 of FIG. 1 includes a code display section 101B representing the token code (qC2oFsNKrHimID6u) in a human-readable format.

[0039] In an embodiment, the authority may include a URI body 123A and a token code 123C, for example, as in the URI 120 shown in FIG. 1. The URI body 123A may include, for example, a host. The host indicates the name (domain name) of the server 51. The token code 123C may be, for example, a path written following the URI body 123A. The URI body 123A may also include a path. In the authority shown in FIG. 1, the URI body 123A is, for example, "aaa....com," and the token code 123C is, for example, "qC2oFsNKrHimID6u." If the client terminal 31 already knows the URI body 123A, the two-dimensional code 60 may include only the token code and other necessary data, without including the URI body 123A.

[0040] The client terminal 31 acquires the URI 120 by, for example, reading the two-dimensional code 60 with a camera (not shown) provided in the client terminal 31. That is, the client terminal 31 acquires the token code 123C by reading the two-dimensional code 60. Note that the client terminal 31 may acquire the token code 123C by manually inputting the token code 123C, which is attached to the tangible medium 101 in a human-readable manner, into the client terminal 31. The client terminal 31 may acquire the token code 123C as digital data from another device via the network 15 or other communication means.

[0041] The blockchain 20 used for token distribution is composed of a P2P (Peer to Peer) computer network system in which multiple computers are interconnected.

[0042] In the blockchain 20, transactions can be made between blockchain addresses. FIG. 3 illustrates a first blockchain address 25A, a second blockchain address 25B, and a third blockchain address 25C. As an example, the first blockchain address 25A is represented by 0x11111, the second blockchain address 25B is represented by 0x33333, and the third blockchain address 25C is represented by 0x55555. The blockchain addresses 25A, 25B, and 25C represent, for example, user accounts in the blockchain 20. Transactions of transactions in the blockchain addresses 25A, 25B, and 25C and the blockchain 20 are recorded in the distributed ledger of the blockchain 20.

[0043] In the blockchain 20, for example, tokens can be traded. Tokens that can be traded in the blockchain 20 include fungible tokens (FT) and non-fungible tokens (NFT). A fungible token is, for example, a cryptocurrency such as Ether in Ethereum. A fungible token may be a unique fungible token issued in a blockchain by a company or an individual.

[0044] A non-fungible token (NFT) is a token that is not fungible, unlike a fungible token (FT). To ensure non-fungibility, an NFT has a unique identifier that enables it to be distinguished from other NFTs in the blockchain 20. Hereinafter, this identifier will be referred to as an NFT identifier.

[0045] The system 10 according to the embodiment may distribute NFTs, may distribute FTs, or may distribute both NFTs and FTs.

[0046] In the blockchain 20, the NFTs or FTs owned by the user are recorded in association with the blockchain addresses 25A, 25B, and 25C held by the user.

[0047] The blockchain 20 includes a smart contract 22. The smart contract 22 may constitute the system 10 according to the embodiment. The smart contract 22 is configured by software (computer program) that is executable on the blockchain. The smart contract 22 automatically executes a predetermined protocol, such as automated trading.

[0048] The smart contract 22 may cooperate with the server 51 for token distribution. In the following, as an example, the server 51 receives a token request sent from a user for token distribution and invokes the smart contract 22, which then transmits the token to the user.

[0049] The aforementioned blockchain address may also refer to the contract address of the smart contract 22. The contract address is the blockchain address where the smart contract 22 is stored.

[0050] In the blockchain 20, the smart contract 22 can also own an NFT or FT. In the blockchain 20, an NFT or FT owned by the smart contract 22 for distribution to a user is recorded in association with the contract address of the smart contract 22.

[0051] The process executed by the smart contract 22 is, for example, a token operation. A token operation is, for example, a change of ownership of a token. The operation of changing the ownership of a token is also called sending a token. That is, changing the ownership of a token from the first blockchain address 25A to the second blockchain address 25B is also sending the token from the first blockchain address 25A to the second blockchain address 25B.

[0052] The transmission of tokens may be, for example, transmission of tokens from the contract address of the smart contract 22 to other blockchain addresses 25A, 25B, and 25C. In other words, the distributor of tokens to users may be the smart contract 22. Note that the distributor of tokens to users may also be the blockchain address of the administrator of the system 10.

[0053] The smart contract 22 is called, for example, by a call operation from outside the smart contract 22, and processes 23 and 24 in the smart contract 22 are executed. The smart contract 22 is called, for example, from the blockchain address of the administrator of the system 10 or the blockchain addresses 25A, 25B, and 25C of the users. The processes 23 and 24 executed by the smart contract 22 may include the first transmission process 23 or the second transmission process 24 shown in Fig. 3. It is sufficient that at least one of the first transmission process 23 and the second transmission process 24 is executed.

[0054] 4 shows an example of a general procedure for acquiring a token in the client terminal 31. First, token codes are distributed to a large number of users for a token distribution campaign or the like run by a company. Examples of methods for distributing token codes are as described above and are not particularly limited. The token codes acquired by each user may be unique codes.

[0055] The user's client terminal 31 acquires the distributed token code (step S41). The token code is acquired, for example, in the form of a URI 120 including the token code. The URI 120 is used to access the token distribution system 10. The client terminal 31 accesses the URI 120 using, for example, a web browser application program installed on the client terminal or a dedicated application program for accessing the system 10. The access is accepted, for example, by the server 51 of the system 10. Through this access, the system 10 can receive the token code acquired by the user.

[0056] Upon receiving the access, the system 10 provides the client terminal 31 with a first screen display 31A to be displayed on the display of the client terminal 31 (step S42). The first screen display 31A may be provided by, for example, the server 51. The first screen display 31A may have, for example, a display 301 of the token code acquired by the user. The first screen display 31A may have an operation unit 302 for confirming the user's intention as to whether or not to acquire the token. The operation unit 302 is, for example, a button or icon as a graphical user interface. The intention confirmation may also be a confirmation of the intention to assign a blockchain address to the user.

[0057] When a user who wishes to receive a token using a token code operates the operation unit 302, a first token request R1 is transmitted from the client terminal 31 to the token distribution system 10 (step S43). The first token request R1 is associated with the above-mentioned token code. The token code associated with the first token request R1 may be transmitted together with the first token request R1, or may be transmitted before or after the first token request R1. The first token request R1 is received by, for example, the server 51.

[0058] The token distribution system 10 transmits tokens such as NFTs to the blockchain address of the user who transmitted the first token request R1. The system 10 provides the client terminal 31 with a second screen display 31B that displays the tokens received by the user on the display of the client terminal 31 (step S44). The second screen display 31B is provided by, for example, the server 51. The user can view the acquired tokens by referring to the second screen display 31B. The user can transfer or sell the acquired tokens to others. The acquired tokens may be used to exchange for other tokens.

[0059] The second screen display 31B may, for example, display at least one or both of a list of NFTs owned by the user and a display of the number of NFTs owned by the user. The second screen display 31B in FIG. 4 shows a list of NFTs owned by the user. As an example, FIG. 4 shows NFT 501, which has Nft_id01 as its NFT identifier in the blockchain and serial number 012345.

[0060] FIG. 5 shows the steps of a token distribution process 51K executed by the server 51 of the system 10. First, the server 51 receives a first token request R1 from the client terminal 31 via the network 15 (step S51). The server 51 determines the validity of the first token request R1 using the token code associated with the received first token request R1 (step S52). For example, a code list 51E (see FIG. 2) may be used to determine the validity. The code list 51E indicates, for example, all distributed token codes. If the token code associated with the first token request R1 is included in the code list 51E, the first token request is determined to be valid. If the token code is not included in the code list 51E, the first token request is determined to be invalid. If the first token request R1 is determined to be invalid, the token distribution process 51K ends without distributing a token to the user.

[0061] In determining validity, a determination condition 51D may be used in addition to or instead of the code list 51E. If the determination condition 51D is satisfied, the first token request R1 is determined to be valid, and if the determination condition 51D is not satisfied, the first token request R1 is determined to be invalid. An example of the determination condition 51D is that "a token code included in the token list is unused." In this case, the use of one token code is limited to one time. Another determination condition 51D is, for example, that "there is no token request by the same user on the same day." In this case, one token code can be used repeatedly, but the use by the same user is limited to one time per day.

[0062] If it is determined in step S52 that the first token request R1 is valid, it is determined whether or not a blockchain address (allocated blockchain address) has been assigned to the user who sent the first token request R1 (step S53). If an assigned blockchain address has already been assigned to the user who sent the first token request R1, the server 51 executes step S54 to send a token to the user. If an assigned blockchain address does not exist, the server 51 performs address setting (step S55) to assign a blockchain address to the user, and then executes step S54.

[0063] In step S54, the server 51 operates the blockchain 20 so that the tokens are distributed to the blockchain address assigned to the user account. An example of the operation of the blockchain 20 here is calling the smart contract 22 to send the tokens. Note that the operation of the blockchain 20 may be operating the blockchain 20 so that the tokens are sent from the blockchain address of the administrator of the system 10 without using the smart contract 22.

[0064] Now, step S55 is executed, for example, when a user accesses the server 51 of the system 10 for the first time, or when the user has accessed the server 51 of the system 10 before but has not received any services related to the blockchain 20, such as obtaining a token.

[0065] In step S55, the server 51 generates a user account 500 for a user to log in to the server 51 (step S55A). The user account 500 is an account for online services provided by the server 51. The online services provided by the server 51 may include services related to blockchain, such as sending and receiving tokens and viewing tokens. The online services provided by the server 51 may also include services not directly related to blockchain. Services not directly related to blockchain include, for example, social networking services (SNS), online shopping services, online game services, online services providing music, videos, or electronic publications, online education services, and Metaverse services. By using the token distribution as an opportunity to generate user accounts 500 for these services for users, the number of users of these services can be increased.

[0066] To generate the user account 500, a user ID and password are set as necessary. The user ID and password may be determined by the server 51 or the user. The ID and password of the user account 500 may be a blockchain address and a private key, which will be described later. In this case, the blockchain address and the private key are also used as the ID and password of the user account 500, which improves user convenience.

[0067] The server 51 assigns a blockchain address for the user to the user account 500 (step S55B). The blockchain address assigned to the user account 500 is a receiving blockchain address for receiving tokens sent to the user by the token distribution process 51K in response to the first token request R1. When the receiving blockchain address is assigned to the user, it is treated as the aforementioned assigned blockchain address. Note that the receiving blockchain address assigned to the user may be used for other purposes, such as sending tokens.

[0068] In the embodiment, the server 51 assigns a blockchain address to the user, which relieves the user from the trouble of acquiring a blockchain address. In addition, the user can receive the assignment of a blockchain address without being particularly aware of acquiring the blockchain address.

[0069] It is also possible that the user who sent the first token request R1 already has a user account 500 on the server 51, but that a blockchain address has not yet been assigned to the user account 500. For example, this may be the case if the user is already using the aforementioned "service not directly related to blockchain" (such as the aforementioned social networking service (SNS)) and already has a user account 500 for that service. If token distribution is performed in that service, the user may send the first token request to the server 51 while logged in to the user account 500. In this case, the generation of the user account 500 (step S55A) may be omitted in the address setting (step S55).

[0070] As described above, in this embodiment, the first token request R1 may involve the allocation of a blockchain address. Therefore, the first token request R1 can be regarded as a user instruction such as an "allocation request" requesting that the server 51 assign a blockchain address to the user account 500, or an "allocation approval" approving the server 51 assigning a blockchain address. When the server 51 receives the user instruction R1 for assigning a blockchain address, the server 51 assigns the blockchain address to the user's existing user account 500 on the server 51. This allows the user to change the existing user account 500 that cannot use the blockchain 20 to a user account 500 that can use the blockchain 20. Note that the user instruction R1 for assigning a blockchain address does not need to be associated with a token code.

[0071] When an existing user account 500 is updated to a user account 500 that can also use the blockchain 20, the user can use blockchain-related services such as trading and viewing tokens in the blockchain 20 while logged in to the user account 500. For example, the user can use blockchain-related services such as trading and viewing tokens in the blockchain 20 while logged in to online services such as a social networking service (SNS), an online shopping service, an online game service, an online music, video, or digital publication service, an online education service, or a Metaverse service.

[0072] In the embodiment, the receiving blockchain address is selected by the server 51 from a plurality of allocation candidate blockchain addresses issued in advance, for example. The plurality of allocation candidate blockchain addresses issued in advance are stored, for example, in a blockchain address list 51F (see FIG. 2). The allocation candidate blockchain addresses stored in the blockchain address list 51F are addresses that have been issued in the blockchain 20 by an administrator of the system 10 or the like, but have not yet been assigned to a user. The blockchain address list 51F shown in FIG. 2 stores, as an example, the first to third blockchain addresses 25A, 25B, and 25C shown in FIG. 3. The server 51 can appropriately select one allocation blockchain address from the blockchain address list 51F, and assign the selected allocation blockchain address to the user as a receiving blockchain address.

[0073] The issuance of a blockchain address needs to be recorded in the blockchain 20, and recording in the blockchain 20 may take time. For this reason, issuing a blockchain address may take time. However, by issuing multiple blockchain addresses in advance for allocation, blockchain addresses can be quickly assigned when allocation becomes necessary. In particular, issuing blockchain addresses in advance is advantageous because it makes it easy to handle cases where a large number of allocations must be made in a short period of time.

[0074] The server 51 may execute processing for issuing a blockchain address (private key) after the need for allocation arises. For example, after it is determined in step S53 that there is no assigned blockchain address, the server 51 may issue an assignment blockchain address to be assigned to the user. In this case, there is no need to issue a blockchain address (private key) in advance, which is convenient.

[0075] The blockchain address list 51F shown in Figure 2 also stores private keys corresponding to the allocation candidate blockchain addresses. In the blockchain 20, private keys are required for transactions. As mentioned above, the blockchain address and private key may be used as an ID and password for a user account 500 on the server 51.

[0076] The private key corresponding to the allocation candidate blockchain address is preferably sent to the user when the allocation candidate blockchain address is assigned to the user and stored by the user, in which case the user can use the private key to trade tokens on the blockchain 20.

[0077] Furthermore, even after the allocation candidate blockchain address is allocated to the user, the private key corresponding to the allocation candidate blockchain address may continue to be stored in the server 51. In this case, the server 51 safely stores the private key for the user and allows the user to use the private key as needed.

[0078] FIG. 6 shows an example of assigning a first blockchain address 25A to a user account 500. In the state of step S61 shown in FIG. 6, a first blockchain address 25A (0x11111) has been issued in advance in the blockchain 20, and the server 51 has the first blockchain address 25A as a candidate blockchain address for assignment. The server 51 also has a private key corresponding to the first blockchain address. In the state of step S61 shown in FIG. 6, the server 51 receives a first token request R1. Note that step S61 in FIG. 6 corresponds to step S51 in FIG. 5.

[0079] When the server 51 receives the first token request R1, it creates a user account 500 and assigns a first blockchain address 25A to the user account 500 (step S62). Note that step S62 in FIG. 6 corresponds to step S55 in FIG. 5.

[0080] When the server 51 generates the user account 500, the server 51 treats the first token request R1 that has already been received as a request from the user account 500. In other words, the server 51 treats the first token request R1 that was received when the user account 500 did not exist as a request that was received in the user account 500 that was generated afterwards.

[0081] Because the first blockchain address 25A is assigned to the user account 500, the first token request R1 is associated with the first blockchain address 25A via the user account 500. In other words, the server 51 can recognize, via the user account 500 having the first token request R1, that the destination of the token in response to the first token request R1 is the first blockchain address 25A assigned to the user account 500.

[0082] As described above, when step S55B in FIG. 5 is executed, the receiving blockchain address 25A assigned to the user in step S55 is set as the destination address of the token to be sent in response to the first token request R1. That is, the server 51 operates the blockchain 20 so that the token is sent to the blockchain address 25A assigned to the user as the token destination. For example, the server 51 invokes the smart contract 22, specifying the blockchain address 25A assigned to the user as the token destination. When invoked, the smart contract 22 is configured to send the token to the specified destination, and therefore the token in response to the first token request R1 is sent to the specified destination, that is, the blockchain address 25A (0x11111).

[0083] As described above, when a token is sent to the blockchain address 25A assigned to the user, the user owns the token. The token owned by the user can be referenced or traded in the user account 500 of the server 51.

[0084] Figure 7 shows an example of the first transmission process 23 (see Figure 3) for token transmission executed by the smart contract 22. In the first transmission process 23, NFTs 501, 502, and 503 that have been issued in advance before receiving the first token request R1 are transmitted in response to the first token request R1. The smart contract 22 shown in Figure 3 has multiple NFTs 501, 502, and 503 that have been issued in advance. The smart contract 22 is configured to transmit one or more NFTs selected from the multiple NFTs 501, 502, and 503 to a specified destination.

[0085] 7, when the smart contract 22 is called by the server 51, it determines an NFT to be sent to the specified destination from among the NFTs it owns (step S71). The smart contract 22 then sends the determined NFT to the specified destination (step S72).

[0086] The determination in step S71 may be made randomly from among the NFTs owned by the smart contract 22, may be made based on predetermined rules, or may be determined based on the second code sent from the server 51. The server 51 can send the second code to the smart contract 22 as necessary (step S70). The second code indicates information that the smart contract 22 uses to identify the NFT to be sent. For example, the second code is an NFT identifier (e.g., Nft_id01) of the NFT to be sent, other data (identifier) ​​that can identify the NFT identifier of the NFT to be sent by the smart contract 22, or data indicating the type of NFT to be sent.

[0087] 8 shows an example in which the smart contract 22 receives the second code. The second code is transmitted from the server 51 to the smart contract 22, for example, when the server 51 invokes the smart contract 22 (step S81). Prior to transmitting the second code, the server 51 determines the second code to be transmitted to the smart contract 22. For example, when the server 51 receives a first token request R1, the server 51 determines the second code.

[0088] The second code may be determined based on the token code (first code), or may be determined independently of the token code (first code). When the second code is determined based on the first code, the token sent to the user is determined by the first code distributed to the user. To determine the second code based on the first code, for example, the server 51 may have a table in which the first code and the second code are associated with each other, and the server 51 may obtain the second code from the first code received by referring to the table. The second code may also be the same as the first code.

[0089] If the second code is determined independently of the first code, the first code is used solely to determine the validity of the first token request R1. If the first token request R1 is determined to be valid based on the first code, the server 51 can independently determine the second code.

[0090] If the second code is an NFT identifier, the server 51 can refer to an NFT list 51G (see FIG. 2) that has NFT identifiers of NFTs held by the smart contract 22 and determine the NFT identifier that will become the second code. The server 51 appropriately selects NFT identifiers included in the NFT list that have not yet been transmitted. One or more NFT identifiers may be selected. The NFT identifier here may be the NFT identifier in the blockchain 20 (e.g., Nft_id01), or may be another identifier that the smart contract 22 uses to identify the NFT identifier in the blockchain 20 (e.g., Nft_id01).

[0091] If the second code is data indicating the type of NFT, the server 51 can refer to an NFT type list 51H (see FIG. 2) that lists NFT types and determine the NFT type that will become the second code. The server 51 can determine the NFT type randomly or according to predetermined rules. The server 51 may also determine the NFT type that will become the second code based on the first code.

[0092] Here, "type" refers to the type of token. FT types can be distinguished by the name of the FT. NFT types can also be distinguished by properties shared by two or more NFTs. For example, if two or more NFTs have the same image in common, those NFTs can be of the same type. "Type" is not particularly limited as long as it can be identified by the smart contract 22. For example, when the smart contract 22 receives a second code indicating an NFT type, it can determine an NFT having the NFT type indicated by the second code as the NFT to be sent.

[0093] In the NFT type list 51H shown in Figure 2, three types are stored as an example: "Type A," "Type B," and "Type C." For example, Type A is a type of NFT that has an image of a certain athlete P1. Type B is a type of NFT that has an image of another athlete P2. Type C is a type of NFT that has an image of yet another athlete P3. Note that NFTs of the same type, such as those that have the same image, can be distinguished by the serial number (see Figure 4) attached to the NFT.

[0094] Upon receiving the second code, the smart contract 22 transmits the NFT determined based on the second code to the first blockchain address 25A, which is the specified destination (step S82). Note that the transmission of the second code to the smart contract 22 can also be considered a token request requesting the smart contract 22 to transmit a token. Therefore, the transmission of the second code can also be considered a transmission of a second token request.

[0095] If the second code is an NFT identifier, the smart contract 22 can uniquely determine the NFT to be sent based on the NFT identifier. If the second code is an NFT type, the smart contract 22 can determine one or more NFTs appropriately selected from multiple NFTs having the NFT type indicated by the second code as the NFT to be sent. Note that if the token to be sent is an FT, the smart contract 22 may determine the quantity of FTs to be sent according to the second code.

[0096] FIG. 9 illustrates the second transmission process 24 (see FIG. 3) for token transmission. In the first transmission process 23, a pre-issued NFT is transmitted, whereas in the second transmission process 24, an NFT is generated when the need for transmission arises, and the generated NFT is transmitted. In the first transmission process 23, the system 10 must hold a large number of NFTs in stock in advance in preparation for transmission. Holding NFTs as inventory complicates inventory management. For example, if there are few NFTs in stock, there is a risk of running out of stock. Conversely, to avoid running out of stock, the administrator of the system 10 must generate a huge number of NFTs in advance and store them in the smart contract 22, etc. If the system is to hold a large number of NFTs in stock, the administrator of the system 10 must bear the workload of generating a huge number of NFTs in advance. In contrast, in the second transmission process 24, an NFT is generated after a token request is received, and therefore, the administrator does not need to hold any NFTs before receiving the token request. In other words, the system 10 does not need to hold an inventory of NFTs to be transmitted.

[0097] If the system 10 is configured to distribute and provide multiple types of NFTs, it becomes necessary to prepare a large number of NFTs for each type of NFT in advance. However, in the second transmission process 24, the type of NFT to be generated is identified by the second code, so that an appropriate type of NFT can be generated and transmitted. Therefore, it is not necessary to prepare a large number of NFTs for each type of NFT in advance.

[0098] 9, when the smart contract 22 receives a second code indicating the type of NFT, it generates an NFT of the type indicated by the second code (step S91) and sends the generated NFT to a specified destination (step S92). Note that the generation of the NFT may be performed by an external device (for example, the server 51 or another server). The smart contract 22 may entrust the generation of the NFT to an external device and send the NFT generated by the external device.

[0099] The server 51 determines the second code to be sent in order to send the second code to the smart contract 22 (step S92). The server 51 can determine one or more NFT types to be the second code by referring to the NFT type list 51H (see FIG. 2) that lists NFT types. The server 51 can determine the NFT type from the NFT type list 51H randomly or according to predetermined rules. The server 51 may determine the NFT type to be the second code based on the first code.

[0100] Upon receiving the second code, the smart contract 22 identifies the type of NFT to be generated based on the received second code. To generate an NFT, data to be converted into an NFT is prepared in advance for each type. The data to be converted into an NFT is, for example, image data. The NFT is generated by converting data corresponding to the type identified based on the second code into an NFT. To distinguish NFTs of the same type or having the same data, a serial number (see FIG. 4) may be assigned to the NFT.

[0101] For NFT conversion, data corresponding to one type may be one, but preferably multiple. For example, if a certain athlete P1 is one type, it is preferable to prepare multiple different image data for that athlete. In this case, once the NFT type to be generated is identified as athlete P1 based on the received second code, the image data to be converted into an NFT is determined from the multiple different image data for that athlete P1. The image data to be converted into an NFT may be determined randomly or based on predetermined rules. Furthermore, the second code may indicate both the NFT type to be generated and the image data to be converted into an NFT, in which case the image data to be converted into an NFT is determined based on the second code.

[0102] The present invention is not limited to the above-described embodiment, and various modifications are possible.

[0103] <3. Notes> The present disclosure also includes the following:

[0104] [Section 1] A token request is received from the user's client device, Upon receiving the token request, the token is sent to the receiving blockchain address assigned to the user. 1. A token distribution system or method thereof configured to perform a process comprising:

[0105] According to the above paragraph 1, the token distribution system does not need to hold a stock of non-fungible tokens to be transmitted in advance.

[0106] [Section 2] A token request is received from the user's client device, determining the validity of the token request, and if the token request is determined to be valid, generating a non-fungible token; Send the generated non-fungible token to the user's blockchain address. 1. A token distribution system or method thereof configured to perform a process comprising:

[0107] According to Section 2 above, upon receiving a valid token request, a non-fungible token is generated and transmitted.

[0108] [Section 3] receiving the code from the user's client terminal; determining the validity of the code, and if the code is determined to be valid, generating a non-fungible token; Send the generated non-fungible token to the user's blockchain address. 1. A token distribution system or method thereof configured to perform a process comprising:

[0109] According to paragraph 3 above, upon receipt of a valid code, a non-fungible token is generated and transmitted.

[0110] [Section 4] Accept user operations from the user's client terminal to assign a blockchain address to an existing user account, When the user operation is accepted, a blockchain address is assigned to the existing user account. 1. A token distribution system or method configured to perform a process comprising:

[0111] According to Section 4 above, existing user accounts can be assigned blockchain addresses. [Explanation of symbols]

[0112] 10: Token distribution system 15: Network 20: Blockchain 22: Smart Contract 23: First transmission process 24: Second transmission process 25A: First Blockchain Address 25B: Second blockchain address 25C: Third Blockchain Address 31: Client terminal 31A: 1st screen display 31B: 2nd screen display 51: Token request reception server 51A: Processor 51B: Storage device 51C: Computer Program 51D: Judgment condition 51E: Code List 51F: Blockchain Address List 51G: NFT List 51H: NFT type list 51K: Token distribution process 60: 2D code 101:Tangible media 101B: Code display section 120: Uniform Resource Identifier 120 :URI 123A: URI body 123C: Token code 301 :Display 302:Operation unit 500: User account 501:NFT 502:NFT 503:NFT R1: First token request

Claims

1. Receive a token request from a user's client terminal requesting token transmission in a blockchain; Upon receiving the token request, assign a receiving blockchain address to the user for receiving the token transmitted in response to the token request; In response to the received token request, operate the blockchain so that the token is sent to the receiving blockchain address assigned to the user. a server configured to perform a process comprising:

2. The process further comprises determining whether or not there is an assigned blockchain address assigned to the user that is the sender of the token request; The assigning of the receiving blockchain address to the user is performed when it is determined that there is no assigned blockchain address assigned to the user. The server of claim 1 .

3. the token request includes a first code; The process further comprises determining validity of the token request using the first code; The assigning of the receiving blockchain address to the user is performed when the token request is determined to be valid. The server of claim 1 .

4. the token request includes a first code; The process comprises: determining the validity of the token request using the first code; Determine whether or not there is an assigned blockchain address assigned to the user who is the sender of the token request; Furthermore, assigning the receiving blockchain address to the user is performed when it is determined that the token request is valid and that the user does not have an assigned blockchain address; The server of claim 1 .

5. Allocating the receiving blockchain address to the user includes assigning the receiving blockchain address to an account of the user on the server. The server according to any one of claims 1 to 4.

6. assigning the receiving blockchain address to the user, creating an account for the user on the server; assigning the receiving blockchain address to the created account; Including, The server according to any one of claims 1 to 4.

7. assigning the receiving blockchain address to the user, Selecting an allocation blockchain address to be allocated to the user from a plurality of allocation candidate blockchain addresses issued in advance; The assigning blockchain address is assigned to the user as the receiving blockchain address. Including, The server according to any one of claims 1 to 6.

8. operating the blockchain includes invoking a smart contract configured to send the tokens such that the tokens are sent to the receiving blockchain address assigned to the user; The server according to any one of claims 1 to 7.

9. Operating the blockchain includes: generating a second code; Sending the second code to the smart contract; It further includes: The second code is for the smart contract to: To identify the token to send, To identify the type of token to send, or Used to identify the type of token to be generated for transmission, The server of claim 8.

10. Receive a token request from a user's client terminal requesting token transmission in a blockchain; Upon receiving the token request, assign a receiving blockchain address to the user for receiving the token transmitted in response to the token request; In response to the received token request, send the token to the receiving blockchain address assigned to the user.

1. A token distribution system configured to perform a process comprising:

11. the process further comprises, after receiving the token request, generating the token for sending to the receiving blockchain address.

11. The token distribution system of claim 10.

12. The process further comprises, after receiving the token request, determining a type of the token to be generated.

12. The token distribution system of claim 11.

13. The type is determined randomly.

13. The token distribution system of claim 12.

14. 1. A computer-implemented method for token distribution, the method comprising: Receive a token request from a user's client terminal requesting token transmission in a blockchain; Upon receiving the token request, assign a receiving blockchain address to the user for receiving the token transmitted in response to the token request; In response to the received token request, send the token to the receiving blockchain address assigned to the user. A computer-implemented method comprising:

15. and after receiving the token request, generating the token for sending to the receiving blockchain address.

15. The computer-implemented method of claim 14.

Images