JP2023094491A - Server, token distribution system, and computer implementation method - Google Patents

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

The present disclosure relates to servers, token distribution systems, and computer-implemented methods.

Patent Literature 1 discloses transmitting a non-fungible token in a blockchain to a user.

Japanese Patent Application Laid-Open No. 2021-089640

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.

A company, an organization, or the like may want to widely distribute tokens in the blockchain, such as non-fungible tokens, to users such as customers of the company for a campaign or the like. However, if the user does not have a blockchain address, the user cannot receive the token.

Imposing the burden on users to obtain a blockchain address in order to receive tokens makes it difficult to distribute tokens widely. Therefore, for example, if the purpose of the campaign is to distribute tokens widely, the purpose of the campaign cannot be achieved.

Therefore, even if a user who wishes to receive a token does not have a blockchain address, it is desirable to enable the user to receive the token in the blockchain with less burden.

One aspect of the present disclosure is a server. The disclosed server receives a token request requesting token transmission in the blockchain from the user's client terminal, and upon receiving the token request, a reception block for receiving the token transmitted in response to the token request. assigning a chain address to the user; and manipulating the blockchain such that, in response to the received token request, the token is sent to the receiving blockchain address assigned to the user. is configured to run

Another aspect of this disclosure is a token distribution system. The disclosed token distribution system receives a token request requesting token transmission in a blockchain from a user's client terminal, and upon receiving the token request, a reception for receiving the token transmitted in response to the token request. assigning a receiving blockchain address to the user, and transmitting the token to the receiving blockchain address assigned to the user in response to the received token request. .

Another aspect of the disclosure is a computer-implemented method. The disclosed method is a computer-executed computer-implemented method for token distribution, wherein a token request requesting token transmission on a blockchain is received from a user's client terminal, and upon receiving the token request, the token Assigning a receiving blockchain address to the user for receiving a token transmitted in response to a request, and transmitting the token to the receiving blockchain address assigned to the user in response to the received token request. prepare to do

Further details are described as embodiments below.

FIG. 1 is a configuration diagram of the system. FIG. 2 is a configuration diagram of the server. FIG. 3 is a diagram showing a blockchain smart contract and a blockchain address. FIG. 4 is a diagram showing a token distribution procedure. FIG. 5 is a flowchart of token distribution processing. FIG. 6 is a schematic diagram showing allocation of blockchain addresses. FIG. 7 is a flowchart of the first transmission process. FIG. 8 is a schematic diagram of the first transmission process. FIG. 9 is a flowchart of the second transmission process.

<1. Overview of Server, Token Distribution System, and Computer Implementation Method>

(1) A server according to an embodiment receives a token request requesting token transmission in a blockchain from a user's client terminal, and upon receiving the token request, receives a token transmitted in response to the token request. assigning a receiving blockchain address to the user, and operating the blockchain such that, in response to the received token request, the token is sent to the receiving blockchain address assigned to the user , is configured to perform a process comprising: When the server receives a token request, it assigns the user a blockchain address so that the user can receive the token even if he or she does not have a blockchain address. Therefore, the burden on the user is small.

(2) Preferably, the processing further comprises determining whether there is an assigned blockchain address assigned to the user from which the token request was sent. Preferably, 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. In this case, if there is no assigned blockchain address assigned to the user from which the token request was sent, a blockchain address is assigned. Therefore, if there is an assigned blockchain address assigned to the user, assignment of the blockchain address can be omitted.

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

(4) Preferably, the token request includes a first code. Further, the process determines validity of the token request using the first code and determines whether there is an assigned blockchain address assigned to the user from which the token request originated. It is preferable to have Assigning the receiving blockchain address to the user is performed when it is determined that the token request is valid and that there is no assigned blockchain address assigned to the user. is preferred. In this case, if the token request is valid and there is no assigned blockchain address, then the assignment of the blockchain address is performed; otherwise, the assignment of the blockchain address can be omitted.

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

(6) Preferably, assigning the receiving blockchain address to the user includes creating an account for the user on the server and assigning the receiving blockchain address to the created account. . In this case, a user account is also created, so the user can be assigned a blockchain address without having a user account on the server.

(7) 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, to the user as the receiving blockchain address. In this case, blockchain address allocation can be done quickly.

(8) manipulating the blockchain includes invoking a smart contract configured to transmit the token such that the token is transmitted to the receiving blockchain address assigned to the user; is preferred. In this case, the token is sent by the smart contract.

(9) operating the blockchain further includes generating a second code and transmitting the second code to the smart contract, the second code being transmitted by the smart contract; It is preferably used to identify the token, to identify the type of token to be transmitted, or to identify the type of token to be generated for transmission.

(10) The token distribution system according to the embodiment receives a token request requesting token transmission in the blockchain from the user's client terminal, and upon receiving the token request, transmits the token transmitted in response to the token request. assigning a receiving blockchain address for receiving to the user; and transmitting the token to the receiving blockchain address assigned to the user in response to the received token request. is configured as follows.

(11) Preferably, said processing performed by the token distribution system further comprises, after receiving said token request, generating said token for transmission to said receiving blockchain address.

(12) Preferably, said processing performed by the token distribution system further comprises determining the type of said token to be generated after receiving said token request.

(13) Preferably, the type is randomly determined. In this case, the user can receive a randomly determined type of NFT.

(14) A method according to an embodiment is a computer-executed computer-implemented method for token distribution, in which a token request requesting token transmission in a blockchain is received from a user's client terminal, and the token request is Upon receipt, assigning the user a receiving blockchain address for receiving a token transmitted in response to the token request, and assigning the receiving blockchain address assigned to the user in response to the received token request. sending said token to.

(15) Preferably, the computer-implemented method further comprises, after receiving said token request, generating said token for transmission to said receiving blockchain address.

<2. Examples of servers, token distribution systems, and computer-implemented methods>

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

FIG. 1 shows an example of a system 10 according to an embodiment. This system 10 is a system using a block chain 20 . The system 10 according to embodiments may constitute a token distribution system. The token distribution system distributes tokens on the blockchain to users.

System 10 according to embodiments may comprise a server 51 connected to network 15 . Network 15 is, for example, the Internet. Server 51 may access blockchain 20 via network 15 . The server 51 may be configured by one computer, or may be configured by a plurality of computers. Server 51 may be managed by an administrator of system 10 . An administrator is, for example, an administrator for token distribution. The administrator may also be the administrator of the smart contract 22 described below.

As shown in FIG. 2, the server 51 can be configured by a computer having 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. A primary storage device is, for example, a RAM. The secondary storage device is, for example, a hard disk drive (HDD) or solid state drive (SSD). The storage device 51B comprises a computer program 51C executed by the processor 51A. The processor 51A reads and executes a computer program 51C stored in the storage device 51B. The computer program 51C has program code indicating instructions for causing the computer to execute the token distribution process 51K. Token distribution processing 51K will be described later.

Storage device 51B may store various data or information. For example, storage device 51B may have determination 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. Also, the storage device 51B may have an NFT list 51G. Also, the storage device 51B may have an NFT type list 51H. These data or information will be described later.

The server 51 constitutes a client/server system together with the client terminal 31 . The server 51 executes processing according to requests from the client terminal 31 . The processing executed by the server 51 is, for example, token distribution processing 51K. The server 51 receives a token request from the client terminal 31 for token distribution. The server 51 that receives the token request is hereinafter also referred to as the token request reception server 51 . The processing performed by the server 51 may include an address setting process (see step S55 of FIG. 5) that assigns a blockchain address to the user. In embodiments, the address setting process may form part of the token distribution process 51K.

The client terminal 31 is the terminal of the user who receives the token. The client terminal 31 is, for example, a smart phone, tablet, or personal computer. A user who wishes to receive a token operates the client terminal 31 and transmits a token request from the client terminal 31 to the server 51 . A user who submits a valid token request can receive a token.

In embodiments, codes are distributed to users, such as by administrators, for users to obtain tokens on the blockchain. Codes distributed to users are hereinafter referred to as token codes or first codes. The tokencode is used for token distribution by system 10 . The multiple token codes distributed to users are preferably different and unique codes. The code is, for example, a multi-digit code made up of numbers, letters, or symbols. A tokencode may, for example, be represented in a machine-readable format. The machine-readable form is, for example, the form of a two-dimensional code 60 or the form of a bar code. The token code is printed on a tangible medium 101 such as paper, for example. The token code may be distributed while being stored in a device capable of data transmission to the client terminal 31 . A device that can transmit data is, for example, an IC tag (wireless tag) that can communicate with the client terminal 31 . A tangible medium 101 or device having a token code is distributed to users for a fee or free of charge. The token code may be distributed to the client terminal 31 as digital data.

In one embodiment, the tokencode (eg, qC2oFsNKrHimID6u) is printed onto the tangible medium 101 in the form of a two-dimensional code 60 representing the uniform resource identifier 120 (URI) containing the tokencode. URI 120 comprises a scheme and an authority. A URI here is, as an example, a uniform resource locator (URL). A scheme is, for example, https:. The authority is described after the scheme and indicates the location of the resource. Note that the URI 120 does not have to include the scheme. Note that the tangible medium 101 of FIG. 1 has a code display portion 101B representing the talk code (qC2oFsNKrHimID6u) in a human-readable format.

In embodiments, an authority may comprise a URI body 123A and a token code 123C, such as URI 120 shown in FIG. The URI body 123A includes, for example, the host. Host indicates the name (domain name) of the server 51 . The token code 123C can be, for example, a path written after the URI body 123A. Note that the URI body 123A may also include a path. In the authority shown in FIG. 1, the URI body 123A is "aaa...com" as an example, and the token code 123C is "qC2oFsNKrHimID6u" as an example. If the client terminal 31 already knows the URI body 123A, the two-dimensional code 60 may not include the URI body 123A and may include only the token code and other necessary data.

The client terminal 31 acquires the URI 120 by reading the two-dimensional code 60 with a camera (not shown) included in the client terminal 31, for example. That is, the client terminal 31 acquires the token code 123C by reading the two-dimensional code 60. FIG. Acquisition of the token code by the client terminal 31 may be performed by the user manually inputting the token code 123C attached to the tangible medium 101 to the client terminal 31 in a human-readable manner. The client terminal 31 may acquire the token code 123C as digital data from another device via the network 15 or other communication means.

The blockchain 20 used for token distribution is configured by a P2P (Peer to Peer) computer network system in which a plurality of computers are interconnected.

In blockchain 20, transactions are possible between blockchain addresses. In FIG. 3, a first blockchain address 25A, a second blockchain address 25B, and a third blockchain address 25C are illustrated. 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. Blockchain addresses 25A, 25B, 25C indicate user accounts in blockchain 20, for example. Blockchain addresses 25A, 25B, 25C and transactions of transactions on the blockchain 20 are recorded in the blockchain 20 distributed ledger.

For example, token transactions are possible on the blockchain 20 . Tokens that can be traded in the blockchain 20 include fungible tokens (Fungible Tokens: FT) and non-fungible tokens (Non-Fungible Tokens: NFTs). A fungible token is a cryptocurrency such as, for example, Ether in Ethereum. A fungible token may be a proprietary fungible token issued on the blockchain by a company or individual.

A non-fungible token (NFT) is a token that does not have fungibility, unlike a fungible token (FT). To ensure non-fungibility, an NFT has a unique identifier in the blockchain 20 to allow it to be distinguished from other NFTs. This identifier is hereinafter referred to as the NFT identifier.

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

In the blockchain 20, NFTs or FTs owned by users are recorded in association with blockchain addresses 25A, 25B, and 25C owned by users.

Blockchain 20 comprises a smart contract 22 . Smart contract 22 may constitute system 10 according to an embodiment. The smart contract 22 is composed of software (computer program) that is executable on the blockchain. Smart contracts 22 automatically execute predetermined protocols such as automated trading.

Smart contract 22 may cooperate with server 51 for token distribution. In the following, as an example, for token distribution, the server 51 that received the token request sent from the user calls the smart contract 22, and the called smart contract 22 sends the token to the user.

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

In blockchain 20, smart contracts 22 can also own NFTs or FTs. In the blockchain 20, the NFT or FT owned by the smart contract 22 for distribution to the user is recorded in association with the contract address of the smart contract 22.

The processing performed by the smart contract 22 is, for example, manipulation of tokens. A token operation is, for example, a token owner change. The operation of changing ownership of a token is also called sending the token. That is, changing the owner of the token from the first blockchain address 25A to the second blockchain address 25B also means sending the token from the first blockchain address 25A to the second blockchain address 25B.

Sending a token can be, for example, sending a token from the contract address of the smart contract 22 to other blockchain addresses 25A, 25B, 25C. That is, the smart contract 22 may be the source of token distribution to the user. Note that the token distribution source for the user may be the blockchain address of the administrator of the system 10 .

The smart contract 22 is called, for example, by a calling operation from outside the smart contract 22, and processes 23 and 24 in the smart contract 22 are executed. The smart contract 22 is invoked from, for example, the administrator's blockchain address or the users' blockchain addresses 25A, 25B, 25C of the system 10 . The processes 23, 24 performed by the smart contract 22 may include the first transmission process 23 or the second transmission process 24 shown in FIG. It is sufficient if at least one of the first transmission process 23 and the second transmission process 24 is executed.

FIG. 4 shows an example of a rough procedure for token acquisition in the client terminal 31. As shown in FIG. First, a token code is distributed to a large number of users for a company's token distribution campaign or the like. Examples of token code distribution methods are as described above, and are not particularly limited. The token code acquired by each user can be a different unique code.

The user's client terminal 31 acquires the distributed token code (step S41). The tokencode is obtained, for example, in the form of a URI 120 containing the tokencode. URI 120 is used to access token distribution system 10 . The client terminal 31 accesses the URI 120 using, for example, a web browser application program installed in the client terminal or a dedicated application program for accessing the system 10 . Access is received, for example, by server 51 of system 10 . With this access, system 10 may receive the tokencode obtained by the user.

The system 10 that has received the access provides the client terminal 31 with the first screen display 31A displayed on the display of the client terminal 31 (step S42). The first screen display 31A may be provided by the server 51, for example. The first screen display 31A may, for example, have a display 301 of the tokencode obtained by the user. The first screen display 31A can have an operation unit 302 for confirming the user's intention whether to acquire a token. The operation unit 302 is, for example, buttons or icons as a graphical user interface. Confirmation of intention can also be confirmation of intention to assign a blockchain address to the user.

When a user who wishes to receive a token using a token code operates the operation unit 302, the client terminal 31 transmits a first token request R1 to the token distribution system 10 (step S43). The aforementioned token code is associated with the first token request R1. The tokencode 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 the server 51, for example.

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

The second screen display 31B can have, for example, at least one or both of a display of a list of NFTs owned by the user and a display of the quantity of FTs owned by the user. A second screen display 31B in FIG. 4 shows a list of NFTs owned by the user. In FIG. 4, as an example, an NFT 501 having Nft_id01 as the NFT identifier in the blockchain and serial number 012345 is shown.

FIG. 5 shows the token distribution process 51K executed by the server 51 of the system 10. As shown in FIG. First, the server 51 receives the first token request R1 from the client terminal 31 via the network 15 (step S51). The server 51 uses the received token code associated with the first token request R1 to determine the validity of the first token request R1 (step S52). A code list 51E (see FIG. 2), for example, can be used to determine validity. The code list 51E shows, for example, all distributed tokencodes. 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, and if 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 the token to the user.

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

If it is determined in step S52 that the first token request R1 is valid, it is determined whether or not there is a blockchain address (assigned blockchain address) assigned to the user who sent the first token request R1. (Step S53). If there is already an assigned blockchain address assigned to the source user of the first token request R1, the server 51 executes step S54 for token transmission to the user. If there is no allocated blockchain address, the server 51 performs address setting (step S55) for allocating a blockchain address to the user, and then executes step S54.

At step S54, server 51 operates blockchain 20 such that tokens are distributed to the blockchain address assigned to the user account. An example of a blockchain 20 operation here is the invocation of a smart contract 22 to send a token. It should be noted that the operation of the blockchain 20 may be the operation of the blockchain 20 to which the token is sent from the blockchain address of the administrator of the system 10 without using the smart contract 22 .

Now, step S55 is executed, for example, when the 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 but is blocked from acquiring a token. This is the case when the service related to the chain 20 has never been provided.

At step S55, the server 51 generates a user account 500 for the user to log into the server 51 (step S55A). A user account 500 is an account for online services provided by the server 51 . Online services provided by the server 51 can include, for example, blockchain-related services such as sending and receiving tokens and viewing tokens. Online services provided by server 51 may include services not directly related to blockchain. Services not directly related to blockchain are, for example, social network services (SNS), online shopping services, online game services, online provision of music, videos or electronic publications, online education services, and Metaverse services. or User accounts 500 for these services are created for users in the wake of token distribution, thereby increasing the number of users of these services.

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

The server 51 assigns the user account 500 a blockchain address for the user (step S55B). The blockchain address assigned to the user account 500 is the 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 a receiving blockchain address is assigned to a user, it is treated as the assigned blockchain address described above. Note that the receiving blockchain address assigned to the user may be used for other purposes such as token transmission.

In the embodiment, since the server 51 assigns the blockchain address to the user, the user is freed from the trouble of acquiring the blockchain address. In addition, the user can be assigned a blockchain address without being particularly conscious of obtaining a blockchain address.

It is possible that the user who sent the first token request R1 already has a user account 500 in the server 51, but the user account 500 has not yet been assigned a blockchain address. For example, the user already uses the above-mentioned "service not directly related to blockchain" (such as the above-mentioned social network service (SNS)) and already has a user account 500 for that service. If the service involves token distribution, the user may send a first token request to the server 51 while logged into the user account 500 . In this case, the generation of the user account 500 (step S55A) can be omitted in the address setting (step S55).

As described above, in this embodiment, the first token request R1 may be accompanied by allocation of a blockchain address. Therefore, the first token request R1 is a user instruction such as "assignment request" requesting that server 51 assign a blockchain address to user account 500 or "assignment approval" approving server 51 to assign a blockchain address. can be taken as When the server 51 receives a user instruction R1 for allocating a blockchain address, it allocates a blockchain address to the user's existing user account 500 on the server 51 . Thereby, the user can 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 allocating a blockchain address does not have to be associated with a token code.

When the 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 on the blockchain 20 while logged in to the user account 500. can be used. For example, the user is logged into an online service such as a social network service (SNS), an online shopping service, an online game service, an online provision service of music, videos or electronic publications, an online education service, or a Metaverse service. , it is possible to use blockchain-related services such as trading and viewing of tokens in the blockchain 20.

In the embodiment, the receiving blockchain address is selected by the server 51 from a plurality of pre-issued allocation candidate blockchain addresses, as an example. A plurality of pre-issued allocation candidate blockchain addresses are stored, for example, in the blockchain address list 51F (see FIG. 2). Allocation candidate block chain addresses stored in the block chain address list 51F are addresses that have been issued in the block chain 20 by the administrator or the like of the system 10, but have not been allocated to users. The block chain address list 51F shown in FIG. 2 stores, as an example, the first to third block chain addresses 25A, 25B, and 25C shown in FIG. The server 51 can appropriately select one allocation block chain address from the block chain address list 51F and allocate the selected allocation block chain address to the user as a reception block chain address.

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, it may take time to issue a blockchain address. However, by issuing a plurality of blockchain addresses for allocation in advance, it is possible to quickly allocate blockchain addresses when allocation becomes necessary. In particular, by issuing blockchain addresses in advance, it is advantageous to be able to easily deal with cases where many assignments must be made in a short period of time.

Note that 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 that there is no allocated blockchain address in step S53, an allocation blockchain address to be allocated to the user may be issued. In this case, there is no need to issue a blockchain address (private key) in advance, which is convenient.

Private keys corresponding to allocation candidate block chain addresses are also stored in the block chain address list 51F shown in FIG. In blockchain 20, private keys are required for transactions. As previously mentioned, the blockchain address and private may be used as the ID and password for the user account 500 on server 51 .

The private key corresponding to the allocation candidate blockchain address is preferably transmitted to and stored at the user when the allocation candidate blockchain address is assigned to the user. In this case, the user can trade tokens on the blockchain 20 using the private key.

Also, the private key corresponding to the allocation candidate blockchain address may continue to be stored in the server 51 even after the allocation candidate blockchain address is allocated to the user. In this case, the server 51 can securely store the private key for the user and allow the user to use the private key according to the user's needs.

FIG. 6 shows an example of assigning a first blockchain address 25A to a user account 500. As shown in FIG. In the state of step S61 shown in FIG. 6, the first block chain address 25A (0x11111) is issued in advance in the block chain 20, and the server 51 has the first block chain address 25A as an allocation candidate block chain address. ing. 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 the first token request R1. Note that step S61 in FIG. 6 corresponds to step S51 in FIG.

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

After generating the user account 500 , the server 51 treats the already received first token request R<b>1 as a request from the user account 500 . That is, the server 51 treats the first token request R1 received when the user account 500 does not exist as a request received in the user account 500 generated after the fact.

Since the user account 500 is assigned the first blockchain address 25A, the first token request R1 is associated via the user account 500 with the first blockchain address 25A. That is, the server 51 recognizes from the user account 500 having the first token request R1 that the destination of the token corresponding to the first token request R1 is the first blockchain address 25A assigned to the user account 500. can do.

As described above, when step S55B in FIG. 5 is executed, the receiving block chain address 25A assigned to the user in step S55 is set as the destination address of the token transmitted in response to the first token request R1. be done. That is, the server 51 operates the blockchain 20 so that the token is transmitted with the blockchain address 25A assigned to the user as the token transmission destination. For example, the server 51 designates the blockchain address 25A assigned to the user as the token transmission destination and calls the smart contract 22 . Since the smart contract 22 is configured to send the token to the specified destination when invoked, the token corresponding to the first token request R1 is sent to the specified destination, the blockchain address 25A (0x11111). is sent.

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

FIG. 7 shows an example of the first transmission process 23 (see FIG. 3) for token transmission executed by the smart contract 22. As shown in FIG. In the first transmission process 23, the NFTs 501, 502, 503 issued in advance before receiving the first token request R1 are transmitted according to the first token request R1. The smart contract 22 shown in FIG. 3 has a plurality of NFTs 501, 502, 503 issued in advance. Smart contract 22 is configured to transmit one or more NFTs selected from multiple NFTs 501, 502, 503 to a specified destination.

In the first transmission process 23 shown in FIG. 7, the smart contract 22, when called by the server 51, determines the NFT to be transmitted to the specified destination from among the owned NFTs (step S71). The smart contract 22 transmits the determined NFT to the designated destination (step S72).

The determination in step S71 may be made randomly from among the NFTs owned by the smart contract 22, may be made based on a predetermined rule, or may be made based on the second code transmitted from the server 51. may be determined. The server 51 can send the second code to the smart contract 22 as needed (step S70). The second code indicates information for smart contract 22 to identify the NFT to be transmitted. For example, the second code may be the NFT identifier of the NFT to be transmitted (eg, Nft_id01), other data (identifier) that smart contract 22 may identify the NFT identifier of the NFT to be transmitted, or the type of NFT to be transmitted. data indicating

FIG. 8 shows an example of smart contract 22 receiving a second code. The second code is transmitted from the server 51 to the smart contract 22 when the server 51 calls the smart contract 22, for example (step S81). Prior to sending the second code, server 51 determines the second code to send to smart contract 22 . For example, the server 51 determines the second code upon receiving the first token request R1.

The second code may be determined based on the token code (first code), or may be determined independently of the token code (first code). If the second code is determined based on the first code, the token sent to the user will be determined by the first code distributed to the user. To determine the second code based on the first code, for example, the server 51 has a table in which the first code and the second code are associated, and by referring to the table, the server The second code can be obtained from the first code received by 51 . Also, the second code may be the same as the first code.

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

When the second code is the NFT identifier, the server 51 refers to the NFT list 51G (see FIG. 2) having the NFT identifier of the NFT that the smart contract 22 has, and can determine the NFT identifier that will be the second code. . The server 51 appropriately selects an untransmitted NFT from among the NFT identifiers included in the NFT list. One or more NFT identifiers may be selected. The NFT identifier here may be the NFT identifier (for example, Nft_id01) in the blockchain 20, or another identifier for the smart contract 22 to identify the NFT identifier (for example, Nft_id01) in the blockchain 20. There may be.

If the second code is data indicating the type of NFT, the server 51 can refer to the NFT type list 51H (see FIG. 2) showing a list of NFT types to determine the NFT type that will be the second code. can. The server 51 can determine the type of NFT randomly or according to predetermined rules. The server 51 may determine the NFT type to be the second code based on the first code.

Here, "type" refers to the kind of token. FT types can be distinguished by FT designations. NFT types can be distinguished by properties that two or more NFTs have in common. For example, two or more NFTs can be of the same type if they have the same image in common. A “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 the second code indicating the NFT type, the smart contract 22 can determine the NFT having the NFT type indicated by the second code as the NFT to be transmitted.

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

The smart contract 22 that has received the second code transmits the NFT determined based on the second code to the designated first blockchain address 25A (step S82). The transmission of the second code to the smart contract 22 can be said to be a token request requesting the smart contract 22 to transmit the token. Therefore, the transmission of the second code can also be said to be the transmission of the second token request.

If the second code is an NFT identifier, smart contract 22 can uniquely determine the NFT to send based on the NFT identifier. When the second code is the NFT type, the smart contract 22 can determine one or more NFTs appropriately selected from among a plurality of NFTs having the NFT type indicated by the second code as NFTs to be transmitted. can. Note that if the token to be sent is FT, the smart contract 22 may determine the quantity of FT to be sent according to the second code.

FIG. 9 shows the second transmission process 24 (see FIG. 3) for token transmission. In the first transmission process 23, an NFT issued in advance is transmitted, but in the second transmission process 24, the NFT is generated after the need for transmission arises, and the generated NFT is transmitted. In the first transmission process 23, it is necessary for the system 10 to have a large number of NFTs in stock in advance in preparation for transmission. Inventory management becomes complicated when holding NFTs as inventory. For example, if there are few NFTs in stock, there is a risk of stockout. Conversely, if an attempt is made 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 or the like. If the system were to have a large inventory of NFTs, the administrator of system 10 would be burdened with pre-generating a large number of NFTs. On the other hand, in the second transmission process 24, since the NFT is generated after receiving the token request, the NFT may not be held before the token request is received. That is, system 10 need not keep an inventory of NFTs to transmit.

If the system 10 is configured to distribute/provide multiple types of NFTs, it will be necessary to prepare multiple NFTs in advance for each NFT type. However, in the second transmission process 24, the second code identifies the type of NFT to be generated so that the appropriate type of NFT can be generated and transmitted. Therefore, there is no need to prepare a large number of NFTs in advance for each type of NFT.

In the second transmission process 24 shown in FIG. 9, when the smart contract 22 receives the second code indicating the type of NFT, it generates an NFT of the type indicated by the second code (step S91), and the generated NFT is specified. is sent to the specified destination (step S92). Note that NFT generation may be performed by an external device (eg, server 51 or another server). The smart contract 22 may delegate NFT generation to an external device and transmit the NFT generated by the external device.

The server 51 determines the second code to be transmitted in order to transmit the second code to the smart contract 22 (step S92). The server 51 can refer to an NFT type list 51H (see FIG. 2) showing a list of NFT types to determine one or more NFT types to be the second code. The server 51 can randomly or according to a predetermined rule determine the NFT type from the NFT type list 51H. The server 51 may determine the NFT type to be the second code based on the first code.

Upon receiving the second code, smart contract 22 identifies the NFT type to generate based on the received second code. For generation of NFT, data to be converted into NFT is prepared in advance for each type. Data to be NFTized is, for example, image data. NFT generation is performed by NFTizing data corresponding to the type identified based on the second code. To distinguish between NFTs of the same type or having the same data, the NFTs may be given serial numbers (see FIG. 4).

For NFTization, the number of data corresponding to one type may be one, but preferably plural. For example, if one athlete P1 is of one type, it is preferable to prepare a plurality of different image data of the athlete. In this case, when the NFT type to be generated is identified as the athlete P1 based on the received second code, an image to be NFT-ized from among a plurality of different image data of the athlete P1. data is determined. The image data to be NFTized may be determined randomly or based on a predetermined rule. Also, the second code may indicate both the NFT type to be generated and the image data to be NFTized, in which case the image data to be NFTized is determined based on the second code.

The present invention is not limited to the above embodiments, and various modifications are possible.

<3. Note>
This disclosure also includes:

[Section 1]
Receive a token request from the user's client terminal,
upon receiving the token request, sending the token to the receiving blockchain address assigned to the user;
A token distribution system or method configured to perform a process comprising:

According to item 1 above, the talk distribution system does not need to stock non-fungible tokens to be transmitted in advance.

[Section 2]
Receive a token request from the user's client terminal,
determining the validity of the token request and generating a non-fungible token if the token request is determined to be valid;
A token distribution system or method configured to perform a process comprising sending said generated non-fungible token to said user's blockchain address.

According to Section 2 above, upon receipt of a valid token request, a non-fungible token is generated and transmitted.

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

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

[Section 4]
Receiving a user operation from the user's client terminal to assign a blockchain address to an existing user account,
A token distribution system or method configured to, upon receiving said user operation, perform a process comprising: assigning a blockchain address to said existing user account.

According to item 4 above, a blockchain address can be assigned to an existing user account.

10: token distribution system 15: network 20: block chain 22: smart contract 23: first transmission process 24: second transmission process 25A: first block chain address 25B: second block chain address 25C: third block chain address 31 : Client terminal 31A : First screen display 31B : Second 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 processing 60: two-dimensional code 101: tangible medium 101B: code display unit 120: uniform resource identifier 120: URI
123A: URI body 123C: token code 301: display 302: operation unit 500: user account 501: NFT
502: NFTs
503: NFTs
R1: 1st token request

Claims (15)

Receive a token request from the user's client terminal requesting token transmission in the blockchain,
upon receiving the token request, assigning the user a receiving blockchain address for receiving the token transmitted in response to the token request;
operating the blockchain such that, in response to the received token request, the token is sent to the receiving blockchain address assigned to the user;
A server configured to perform a process comprising: The process further comprises determining whether there is an assigned blockchain address assigned to the user from which the token request originated;
assigning the receiving blockchain address to the user is performed when it is determined that there is no assigned blockchain address assigned to the user;
A server according to claim 1 . the token request includes a first code;
the processing further comprises determining validity of the token request using the first code;
assigning the receiving blockchain address to the user is performed if the token request is determined to be valid;
A server according to claim 1 . the token request includes a first code;
The processing is
determining validity of the token request using the first code;
determining whether there is an assigned blockchain address assigned to the user from which the token request was sent;
furthermore,
Assigning the receiving blockchain address to the user is performed when it is determined that the token request is valid and that there is no assigned blockchain address assigned to the user. ,
A server according to claim 1 . assigning the receiving blockchain address to the user includes assigning the receiving blockchain address to the user's account at the server;
A server according to any one of claims 1 to 4. Assigning the receiving blockchain address to the user includes:
create an account for the user on the server;
assigning the receiving blockchain address to the generated account;
including
A server according to any one of claims 1 to 4. Assigning the receiving blockchain address to the user includes:
selecting an allocation block chain address to be allocated to the user from a plurality of allocation candidate block chain addresses issued in advance;
assigning the allocation blockchain address to the user as the reception blockchain address;
including
A server according to any one of claims 1 to 6. operating the blockchain includes invoking a smart contract configured to transmit the token such that the token is transmitted to the receiving blockchain address assigned to the user;
A server according to any one of claims 1 to 7. Operating the blockchain includes:
generate a second code,
sending the second code to the smart contract;
further comprising
The second code is such that the smart contract:
To identify the token to send,
used to identify the type of token to be transmitted or to identify the type of token to be generated for transmission;
A server according to claim 8 . Receive a token request from the user's client terminal requesting token transmission in the blockchain,
upon receiving the token request, assigning the user a receiving blockchain address for receiving the token transmitted in response to the token request;
Sending the token to the receiving blockchain address assigned to the user in response to the received token request;
A token distribution system configured to perform a process comprising: The process further comprises generating the token for transmission to the receiving blockchain address after receiving the token request.
11. Token distribution system according to claim 10. The process further comprises determining the type of the token to be generated after receiving the token request.
12. Token distribution system according to claim 11. 13. The token distribution system of Claim 12, wherein the type is randomly determined. 1. A computer-implemented computer-implemented method for token distribution, comprising:
Receive a token request from the user's client terminal requesting token transmission in the blockchain,
upon receiving the token request, assigning the user a receiving blockchain address for receiving the token transmitted in response to the token request;
Sending the token to the receiving blockchain address assigned to the user in response to the received token request;
A computer-implemented method comprising: further comprising generating the token for transmission to the receiving blockchain address after receiving the token request;
15. The computer-implemented method of claim 14.

Images