Computer-implemented method, system and computer program

Abstract

To facilitate transmission or reception of a token.SOLUTION: The disclosed method is a computer-implemented method executed by a computer, and may include receiving designation of a transmission destination identifier other than an address indicating a transmission destination of a token in a distributed network as the transmission destination of the token transmitted in the distributed network, acquiring the address corresponding to the designated transmission destination identifier on the basis of data in which correspondence between the transmission destination identifier and the address in the distributed network is set, and transmitting the token to the acquired address.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to computer-implemented methods, systems, and computer programs. [Background technology]

[0002] Patent Document 1 discloses a method for transmitting non-fungible tokens in a blockchain, which is a distributed network. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6710401 Summary of the Invention

[0004] Many people are unfamiliar with decentralized networks like blockchain, and sending tokens to such people in a decentralized network can pose various challenges for both the sender and receiver of the tokens.

[0005] Therefore, it is desirable to facilitate the sending or receiving of tokens.

[0006] One aspect of the present disclosure is a method. The disclosed method may be a computer-implemented method executed by a computer.

[0007] The disclosed method may include accepting a designation of a destination identifier other than an address indicating a destination of a token in a distributed network as a destination of the token to be sent in the distributed network, obtaining the address corresponding to the designated destination identifier based on data that sets a correspondence between the destination identifier and the address in the distributed network, and sending the token to the obtained address.

[0008] The disclosed method may include accepting a designation of an email address, obtaining a distributed network address corresponding to the designated email address based on data that sets a correspondence between email addresses and distributed network addresses, and sending a token to the obtained distributed network address.

[0009] The disclosed method may include, in a distributed network application that allows login using an email address as a login identifier, when a login is made using an email address set as a destination of a token sent on the distributed network as the login identifier, displaying a user interface on a screen after login for accepting user operation to request acquisition of the token.

[0010] Another aspect of the present disclosure is a system or a computer program. The disclosed system may be configured to execute a process including accepting a designation of a destination identifier other than an address indicating a destination of a token in a distributed network as a destination of the token to be transmitted in the distributed network, obtaining the address corresponding to the designated destination identifier based on data that sets a correspondence between the destination identifier and the address in the distributed network, and transmitting the token to the obtained address. The disclosed computer program may cause a computer to execute the process.

[0011] The disclosed system may be configured to execute a process including accepting a designation of an email address, obtaining a distributed network address corresponding to the designated email address based on data in which correspondence between the email address and the distributed network address is set, and sending a token to the obtained distributed network address. The disclosed computer program may cause a computer to execute the process.

[0012] The disclosed system may be configured to execute a process including, in a distributed network application that allows login using an email address as a login identifier, when login is performed using, as the login identifier, an email address set as a destination of a token transmitted over the distributed network, displaying, on a screen after login, a user interface for accepting a user operation requesting acquisition of the token. The disclosed computer program may cause a computer to execute the process.

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

[0014] [Figure 1] FIG. 1 is a configuration diagram of a system according to an embodiment. [Figure 2] FIG. 2 is a flowchart of the token transmission process. [Figure 3] FIG. 3 is an explanatory diagram of the token transmission process. [Figure 4] FIG. 4 is a configuration diagram of a system according to an embodiment. [Figure 5] FIG. 5 is a flowchart of the token transmission process. [Figure 6] FIG. 6 is a flowchart showing the procedure for logging in to an email wallet. [Figure 7] FIG. 7 shows a screen for setting destinations and the like. [Figure 8] FIG. 8 shows a confirmation screen for the destination and the like. [Figure 9] FIG. 9 shows a screen for completing the settings of the destination and the like. [Figure 10] FIG. 10 shows the screen transitions of the email wallet. DETAILED DESCRIPTION OF THE INVENTION

[0015] 1. Overview of Computer-Implemented Method, System, and Computer Program

[0016] (1) A method according to an embodiment may be a computer-implemented method executed by a computer. The method according to an embodiment may include: receiving, by a computer, a designation of a destination identifier other than an address indicating the destination of a token in a distributed network as a destination of a token to be transmitted in the distributed network; obtaining the address corresponding to the designated destination identifier based on data that sets a correspondence between the destination identifier and the address in the distributed network; and transmitting the token to the obtained address. In this case, it is preferable that the destination of a token can be designated using a destination identifier other than an address indicating the destination of the token in the distributed network.

[0017] (2) The destination identifier may be an email address.

[0018] (3) Accepting the designation of the destination identifier includes accepting the designation of an unaddressed identifier that does not correspond to the address, and acquiring the address can be performed after the correspondence between the unaddressed identifier and the address is established. In this case, it is preferable that the address does not need to correspond to the destination identifier at the time of designation of the destination identifier.

[0019] (4) The sending of the token may be performed by accepting an operation requesting acquisition of the token in an application for displaying the token.

[0020] (5) Sending the token may include accepting an operation requesting acquisition of a token in an application that allows login using the destination identifier as a login identifier, and, upon accepting the operation, sending the token to the address corresponding to the destination identifier used for login.

[0021] (6) The data may be set when a user logs in to an application that allows login using the destination identifier as a login identifier, using the destination identifier as the login identifier.

[0022] (7) A method according to an embodiment may include a computer receiving a specified email address, obtaining a distributed network address corresponding to the specified email address based on data that sets the correspondence between the email address and the distributed network address, and sending a token to the obtained distributed network address.

[0023] (8) A method according to an embodiment may include a computer that, in a distributed network application that allows users to log in using an email address as a login identifier, displays a user interface on a screen after login for accepting user operations to request acquisition of the token when a user logs in using an email address set as a destination of a token sent over the distributed network as a login identifier.

[0024] (9) The system according to the embodiment may be configured to perform processing including accepting a destination identifier other than an address indicating the destination of a token in a distributed network as the destination of the token to be sent in the distributed network, obtaining the address corresponding to the specified destination identifier based on data that sets the correspondence between the destination identifier and the address in the distributed network, and sending the token to the obtained address.

[0025] (8) A system according to an embodiment may be configured to perform processing including accepting a specified email address, obtaining a distributed network address corresponding to the specified email address based on data that sets the correspondence between the email address and the distributed network address, and sending a token to the obtained distributed network address.

[0026] (9) In a distributed network application that allows users to log in using an email address as a login identifier, the system according to the embodiment may be configured to execute a process that includes displaying a user interface on a screen after login for accepting user operations requesting acquisition of the token when a user logs in using an email address set as a login identifier for a token sent over the distributed network.

[0027] (10) A computer program according to an embodiment may cause a computer to perform processing including accepting a destination identifier other than an address indicating the destination of a token in a distributed network as the destination of the token to be sent in the distributed network, obtaining the address corresponding to the specified destination identifier based on data that sets the correspondence between the destination identifier and the address in the distributed network, and sending the token to the obtained address.

[0028] (11) A computer program according to an embodiment may cause a computer to perform processing including accepting a specified email address, obtaining a distributed network address corresponding to the specified email address based on data that sets the correspondence between the email address and the distributed network address, and sending a token to the obtained distributed network address.

[0029] (12) In a distributed network application that allows users to log in using an email address as a login identifier, a computer program according to an embodiment may cause a computer to perform processing including, when a user logs in using an email address set as a destination for a token sent over the distributed network as a login identifier, displaying a user interface on a screen after login for accepting user operations requesting acquisition of the token.

[0030] 2. Computer-Implemented Methods, Systems, and Computer Program Examples

[0031] Hereinafter, the embodiments will be described in more detail with reference to the drawings.

[0032] 1 shows a system 10 according to an embodiment. The system 10 may be configured by one or more computers.

[0033] The system 10 may be configured as a token transmission system 51. The token transmission system 51 manages the transmission of tokens. The token transmission system 51 may be configured by one or more computers. The token transmission system 51 may be configured by one or more server computers connected to a network such as the Internet.

[0034] As shown in FIG. 3, the token transmission system 51 may be configured by a computer including a processor 51A and a memory 51B. The processor 51A may be a CPU, a GPU, or any other type of processor. The memory 51B is connected to the processor 51A. The memory 51B may include, for example, a primary storage device and a secondary storage device. The primary storage device may be, for example, a RAM. The secondary storage device may be, for example, a hard disk drive (HDD) or a solid-state drive (SSD). The memory 51B may include a computer program 51C executed by the processor 51A. The processor 51A reads and executes the computer program 51C stored in the memory 51B. The computer program 51C has program code representing instructions for causing the computer to execute various processes, such as the token transmission process 51E.

[0035] Correspondence data 51D is stored in memory 51B. As an example, correspondence data 51D indicates the correspondence between destination identifiers such as electronic mail (E-mail) addresses and wallet addresses, as shown in Fig. 1. Correspondence data 51D will be described later.

[0036] The token transmission system 51 is capable of communicating via a network such as the Internet with one or more terminals 31, 32, and 33. The terminals 31, 32, and 33 are, for example, computers such as personal computers, smartphones, and tablets.

[0037] The token transmission system 51 may be used, for example, in an airdrop. An airdrop is a token distribution event. An airdrop is also called a token airdrop. In an airdrop, tokens are distributed, often for free, by an airdrop organizer, such as a company.

[0038] The token here refers to a token in a decentralized network. A decentralized network is a network that is managed in a decentralized manner by multiple computers, unlike a centralized network. A decentralized network is also called a decentralized Internet or WEB 3.0. An example of a decentralized network is a blockchain 20 (see Figure 1).

[0039] The blockchain 20 is a network that uses distributed ledger technology. The blockchain 20 is configured as a P2P (Peer to Peer) computer network system in which multiple computers are interconnected. The token transmission system 51 of the embodiment, as an example, manages the transmission of tokens in the blockchain 20.

[0040] Tokens are transmitted over a decentralized network, such as a blockchain, and their owners are recorded in that network. Tokens are also known as cryptocurrencies.

[0041] The token may be, for example, a fungible token (FT) or a non-fungible token (NFT).

[0042] A fungible token is, for example, a cryptocurrency (native token) such as Ether in Ethereum. A fungible token may also be a unique fungible token issued on a blockchain by a specific issuer such as a company or an individual.

[0043] Non-fungible tokens (NFTs) are tokens that are not fungible, unlike fungible tokens (FTs).

[0044] In a distributed network such as a blockchain, tokens are sent and received, and token ownership can change. In a distributed network such as a blockchain, an address is used to indicate the owner of a token. An address is an account in a distributed network such as a blockchain. In a distributed network, a token is recorded in association with the blockchain address of its owner. An address is also called a distributed network address or a blockchain address. An address used by a user of a distributed network to own a token is also called a wallet address or a wallet account.

[0045] A wallet is an application (software) used by a user to manage tokens, such as displaying, sending, or receiving tokens. The wallet here is a type of distributed network application, and a user who logs in to the wallet can display tokens owned in the distributed network. In other words, the wallet can display tokens recorded in association with the wallet address of the user who logs in to the wallet. A user can use the wallet to send or receive tokens.

[0046] A distributed network application is an application (software) for using a distributed network. For example, an application for using a blockchain is called a blockchain application.

[0047] Sending a token means changing the owner recorded in association with the token from the sender to the receiver. In other words, the history of token transmissions, i.e., changes in token owner, is also recorded in a decentralized network such as a blockchain. When sending a token in a decentralized network, a digital signature is performed using a private key. The address corresponds to the private key. The private key is stored, for example, in a wallet. The private key must be strictly managed to prevent token theft.

[0048] The aforementioned airdrop is a form of token transmission. The airdrop organizer is the sender of the tokens. The airdrop organizer sends the tokens to one or more users. In an airdrop, tokens are often distributed for free as part of a campaign. Therefore, users can obtain tokens for free through an airdrop.

[0049] However, various difficulties can arise when sending tokens like an airdrop.

[0050] One of the difficulties is that tokens cannot be sent to those who do not have a decentralized network address. Currently, many people are unfamiliar with decentralized networks such as blockchain and do not have a decentralized network address.

[0051] In order to send tokens in an airdrop, the sender of the token (e.g., the airdrop organizer) needs to know the address of the recipient (token receiver). However, tokens cannot be sent to someone who does not have an address.

[0052] Furthermore, those who are not familiar with decentralized networks may not be able to properly grasp their own addresses, even if they have them. Tokens cannot be sent to those who do not properly grasp their own addresses.

[0053] For example, a distributed network address (blockchain address) is generally composed of a combination of alphanumeric characters, has a large number of characters, and appears to humans as a long string of meaningless alphanumeric characters. For example, the address of Ethereum, a type of blockchain, begins with "0x" and is followed by hexadecimal characters 0-9 or AF, and consists of a string of alphanumeric characters of up to 40 characters.

[0054] For this reason, it is not realistic to expect people to remember their decentralized network addresses. Therefore, in order for people to understand their own addresses, they need to refer to the addresses recorded in a managed location (for example, a wallet application for the decentralized network). However, people who are not familiar with decentralized networks often do not know what to refer to in order to understand their addresses. Also, addresses may appear as meaningless strings of characters, and it may not be clear that they are addresses. For this reason, people who are not familiar with decentralized networks often cannot properly understand their own addresses, even if they have them.

[0055] As a result, it is often difficult for the sender of the token (e.g., the airdrop organizer) to grasp the address of the recipient of the token (the recipient of the token), and they are unable to send the token.

[0056] As a result, token senders (e.g., airdrop organizers) can only send tokens to those who are familiar with decentralized networks. Campaigns such as airdrops are expected to promote the use of decentralized networks by those who are not familiar with them. However, if tokens can only be sent to those who are familiar with decentralized networks, the effect of promoting usage will not be achieved.

[0057] Moreover, another difficulty in token transmission arises for those who wish to obtain the token (token receivers).

[0058] In other words, before attempting to acquire a token, a person who wishes to acquire a token must, as a preliminary step, install a wallet application on their device, obtain a wallet address using the wallet application, and strictly manage the private key corresponding to that wallet address.

[0059] However, the terms "wallet application," "wallet address," and "private key" are unfamiliar to many people, so the sender of the token needs to provide detailed explanations to those who wish to acquire the token about the preparations they should make in advance.

[0060] However, for those who are not familiar with decentralized networks, such preparations are difficult. As a result, even if they try to acquire tokens through airdrops, etc., they may give up on acquiring tokens due to the difficulty of the preparations.

[0061] To facilitate token transmission, the token transmission system 51 of the embodiment is configured to transmit a token even if a distributed network address is not specified as the destination. Therefore, the token sender can transmit a token even if they do not know the address of the token destination.

[0062] Specifically, the token transmitting system 51 can accept the specification of a destination identifier (destination ID) other than a distributed network address as the destination of the token. The token transmitting system 51 obtains a distributed network address from the specified destination identifier and transmits the token to the obtained address. Therefore, even if the token sender does not know the address of the token destination, it can specify the destination using a destination identifier other than a distributed network address.

[0063] Hereinafter, a "destination identifier other than a distributed network address" will be simply referred to as a "destination identifier." A destination identifier is information that can identify a destination other than a distributed network address. A destination identifier is, for example, an email address, a phone number, a user ID (account) for a social networking service (SNS), a user ID (account) for other network services (such as web services), or other information that can identify a destination.

[0064] An email address is preferable as a transmission identifier because many people have it. For example, a company or the like that keeps track of many people's email addresses in a mailing list can use the mailing list to specify the email addresses included in the mailing list as the destination of tokens in an airdrop or the like. In this case, existing information such as a mailing list can be used as the destination of tokens, making it possible to conduct campaigns such as airdrops to existing customers of the company or the like.

[0065] Furthermore, an email address is suitable as a destination identifier from the viewpoint that it may be used as an account for an SNS or other network services.

[0066] Furthermore, an email address is also suitable because it allows for personal authentication through email authentication. An SNS account is also suitable because it allows for personal authentication through SNS authentication.

[0067] The token transmission system 51 grasps the correspondence between a destination identifier such as an email address and an address of a distributed network, and based on that correspondence, can obtain the address of a distributed network from a destination identifier such as an email address.

[0068] Therefore, when using the token transmission system 51, the sender does not need to know the address of the destination when transmitting a token, which improves convenience.

[0069] 2 and 3 show a procedure for transmitting a token using an email address as an example of the token transmission process 51E by the token transmission system 51.

[0070] 2 and 3, the token transmission system 51 accepts the designation of one or more email addresses as destination identifiers for the token. The designation may be made, for example, from a device external to the system 51 (such as the terminal 31) or may be made within the system 51.

[0071] As an example, the email address is specified using the sender terminal 31 shown in Fig. 1. The sender terminal 31 is a terminal operated by a token sender. The token sender is, for example, a host of a token sending event such as an airdrop.

[0072] The token sender accesses the token transmission system 51 using the sender terminal 31 and performs an operation to specify one or more email addresses as destination identifiers. The operation to specify an email address is, for example, inputting an email address from the terminal 31. Since email addresses are often stored in an address book on a computer such as the terminal 31, it is easy to know the email addresses of destinations. The operation to specify an email address may be uploading a file (e.g., a CSV file) containing multiple email addresses from the terminal 31 to the token transmission system 51. In this case, multiple destinations can be specified at once. Specifying by uploading a file is preferable when, for example, specifying multiple email addresses included in a mailing list as destinations.

[0073] The token sender can specify the destination as well as the type and quantity of tokens to send. If multiple destinations are specified, the token sender can specify the type and quantity of tokens for each destination or group of destinations.

[0074] The destination identifier, such as an email address, may be designated by the recipient of the token. In this case, a person who wants to obtain a token (the recipient) simply operates the recipient terminal 32, 33 and inputs their own email address as the destination of the token. Since most people remember their own email addresses, inputting an email address is easy. The destination identifier may also be designated by an administrator of the system 51, etc.

[0075] After receiving the email address, the token transmission system 51 acquires an address (wallet address) corresponding to the specified email address based on the correspondence data 51D (step S202). As shown in Figures 1 and 3, the correspondence data 51D indicates the correspondence between a destination identifier such as an email address and an address (wallet address) in a distributed network. In Figures 1 and 3, as an example, the email address john@example.com is associated with the wallet address 0x2222222222.

[0076] In this case, in step S202, the token transmission system 51 references the correspondence data 51D and obtains the wallet address associated with the specified email address in the correspondence data 51D. For example, if john@example.com is specified as the destination identifier, the token transmission system 51 obtains the wallet address 0x2222222222 based on the correspondence data 51D.

[0077] The token transmission system 51 then executes processing to transmit the token to the acquired address (step S303). In this way, the token transmission system 51 can accept a destination identifier such as an email address and transmit the token to the address (e.g., 0x2222222222) corresponding to the destination identifier.

[0078] Furthermore, the fact that the token transmission system 51 can accept the specification of an email address or the like as a destination identifier has the advantage that the destination distributed network address does not need to exist at the time the destination specification is accepted (see FIG. 2). The destination distributed network address does not need to exist at the time the destination is specified, as long as it exists immediately before the token is transmitted (see FIG. 2).

[0079] Furthermore, if the destination address of the distributed network does not need to exist at the time of receiving the destination specification, the token sender does not need to worry about whether the designated destination has a distributed network address. The distributed network address may be determined after the destination identifier is specified.

[0080] In other words, the correspondence between a destination identifier such as an email address and an address may be established after the destination identifier is specified. Once the correspondence between a destination identifier such as an email address and an address is established, the token transmission system 51 can obtain and store correspondence data 51D indicating the correspondence. The token transmission system 51 can obtain the address corresponding to the specified destination identifier by referencing the correspondence data 51D indicating the correspondence established after the destination identifier is specified.

[0081] For example, suppose a mailing list contains an email address EA of user A who has an address on a distributed network, and an email address EB of user B who does not have an address on a distributed network. Even if user B does not have an address on a distributed network, he or she can simply obtain an address corresponding to the email address EB later.

[0082] Therefore, anyone who wishes to designate an email address included in this mailing list as a token destination can do so without worrying about whether users A and B each have a distributed network address. In other words, even if the designated destination identifier, such as an email address, is an identifier that is not associated with an address in the distributed network (an unassigned address identifier), the token transmission system 51 can accept the designation of the unassigned address identifier as the destination identifier. After the correspondence between the unassigned address identifier and the distributed network address is established, the token transmission system 51 can execute a process to obtain an address corresponding to the designated destination identifier.

[0083] Therefore, a mailing list owner can use the mailing list as a token destination list without worrying whether the owners of multiple email addresses included in the mailing list have addresses on a decentralized network. Therefore, it is suitable for using existing mailing lists for token distribution campaigns such as airdrops.

[0084] 4 shows a system 50 that uses the above-described token transmission system 51. As an example, the system 50 is configured as a token management system 50 that manages token transmission and other token-related operations. The system 50 may be configured by one or more computers.

[0085] The system 50 may include a wallet system 52 in addition to the token transmission system 51. The wallet system 52 is, for example, an email wallet system that provides users with email wallets. The email wallet is a wallet application that users can log in to using their email addresses. The user here is a person who can acquire tokens (recipient). A person who wishes to acquire tokens can easily use the wallet by simply logging in to the wallet using their own email address.

[0086] An email wallet allows you to log in to an account indicated by a decentralized network address (wallet address) using an email address associated with that decentralized network address (email address login).In addition, an email wallet allows you to associate a decentralized network address with an email address that is not associated with a decentralized network address, and create a new account indicated by that decentralized network address (new account creation).

[0087] Therefore, anyone who has an email address can easily use an email wallet by creating a new account using their email address, even if they do not have a decentralized network address such as a blockchain address.

[0088] The wallet application provided by the wallet system 52 is, for example, Software as a Service (SaaS). The wallet application here may be a native application that is installed and used on the terminals 32 and 33, but in the following, as an example, it is assumed to be a web application that runs on a web browser. If the wallet application is a web application, the user does not need to install the application in advance, and can simply access the application from the browser, making it easy to use.

[0089] In this way, if the wallet is a web application and can be logged in with an email address, the user can easily use the wallet without having to make prior preparations such as installing a wallet application and obtaining a wallet address and private key. In other words, users can easily use the wallet even if they have never used a distributed network such as a blockchain before.

[0090] As mentioned above, a wallet application is a type of distributed network application, and in this case, it is a blockchain wallet application. A user can use the wallet application to manage tokens on the blockchain, such as viewing, sending, or receiving tokens.

[0091] Login to the wallet system 52 may be managed by the wallet management system 53. The wallet management system 53 may perform login authentication and related processes for a wallet that allows login using a destination identifier that can be specified as a token destination as a login identifier (login ID). For example, the wallet management system 53 may perform email login authentication and related processes for an email wallet that allows login using an email address as a login ID.

[0092] The token transmission system 51 and the wallet system 52 may be managed by the same administrator. The wallet management system 53 may also be managed by the same administrator as the token transmission system 51 and the wallet system 52, but the wallet management system 53 may be an external system (external service) from the perspective of the token transmission system 51 and the wallet system 52. In this case, the wallet management system 53 can manage login authentication for various wallet systems 52, thereby increasing versatility. Furthermore, if the wallet management system 53 is an external service from the perspective of the administrator of the token transmission system 51 and the wallet system 52, the administrator does not need to manage information for login authentication, which is advantageous.

[0093] The token transmission system 51 shown in Figure 4 transmits tokens using a smart contract 22. The smart contract 22 is implemented in the blockchain 20. The smart contract 22 is composed of software (computer program) that is implemented in an executable manner in the blockchain 20. The smart contract 22 automatically executes a predetermined protocol such as automated trading.

[0094] In the example of FIG. 4, the smart contract 22 holds the token to be transmitted from the token sender in advance, and transmits the token at the timing when the token should be transmitted. For example, after receiving the specification of a token transmission destination using a transmission destination identifier, the token transmission system 51 transmits the token to be transmitted to the destination to the smart contract 22 and stores it in the smart contract 22. After receiving the token, the smart contract 22 transmits the token to the destination at an appropriate timing. Specifically, in order to transmit the token at an appropriate timing, the token transmission system 51 calls the smart contract 22 and causes the smart contract 22 to automatically execute the token transmission process. Furthermore, the token transmission system 51 sets the token transmission timing in the smart contract 22, and causes the smart contract 22 to automatically execute the token transmission process at the set timing.

[0095] In this way, the token transmission system 51 can transmit a token immediately upon receiving a destination specification, but can also transmit a token at a necessary timing after a destination specification, rather than immediately upon receiving a destination specification.

[0096] Furthermore, by using the smart contract 22 in token transmission, it is easy to deal with erroneous token destination designations. For example, even if a token sender designates an incorrect destination and deposits the token in the smart contract 22, the token sender can recover the token until the smart contract 22 transmits the deposited token to the user. Generally, in a distributed network such as a blockchain, there is no centralized administrator, so if a token is sent to an incorrect destination, it is almost impossible to recover the token. However, because the smart contract 22 can be operated by the same administrator as the token transmission system 51, even if an incorrect destination is designated, the token can be recovered as long as it has simply been deposited in the smart contract 22.

[0097] Figure 5 shows an example of a token transmission process using the system 50 of Figure 4. Also, Figure 6 shows an example of a process for logging in to an email wallet using the system 50 of Figure 4. Note that Figure 4 also shows a process corresponding to the process shown in Figures 5 and 6.

[0098] In step S501 shown in FIG. 5 (and FIG. 4), the token transmission system 51 receives input such as an email address of a person who will be the recipient (destination) of the token. This input is made, for example, by the token sender (see FIG. 4). The token sender accesses the token transmission system 51 using a terminal 31. For example, a screen 700 shown in FIG. 7 is displayed on the display of the terminal 31 that has accessed the token transmission system 51. For example, the screen 700 shown in FIG. 7 may be provided to the terminal 31 by the token transmission system 51.

[0099] The screen 700 shown in FIG. 7 includes a selection section 710 for selecting a blockchain, and a setting section 720 for setting transmission information for the selected blockchain.

[0100] The selection unit 710 allows a user to select a blockchain for token transmission from among multiple blockchains supported by the system 51. Examples of multiple blockchains supported by the system 51 include Ethereum, Arbitrum, Optimism, Binance Chain, Polygon, and Avalanche. The blockchain is selected, for example, by operating a pull-down menu that displays multiple blockchains.

[0101] The setting unit 720 includes an email address designation unit 721 and a token designation unit 722 .

[0102] The email address specification unit 721 includes an input unit 721A for manually inputting the email address of the token recipient (token destination), and a CSV file upload unit 721B. The input unit 721A is suitable for specifying one email address as the destination, while the upload unit 721B is suitable for specifying multiple email addresses as destinations.

[0103] The token sender can input the email address to which the token will be sent in the input section 721A. The token sender can also operate the upload section 721B to upload a file (CSV file) containing one or more email addresses to the system 51. The file contains, for example, email addresses included in a mailing list.

[0104] The token designation unit 722 is used to designate the number, type, etc. of tokens to be transmitted to a token transmission destination. The token designation unit 722 includes, for example, a first designation unit 722A and a second designation unit 722B.

[0105] The token sender can input the number of tokens they wish to send in the first designation section 722A, and can select the type of token they wish to send in the second designation section 722B. The second designation section 722B is used by the token sender to select the type of token they wish to send from among the multiple tokens in the blockchain selected in the selection section 710. The token type is selected, for example, by operating a pull-down menu that displays multiple token types.

[0106] The setting unit 720 includes an input unit 723 for inputting the name of the token sender. The name input in the input unit 723 is displayed in an email or wallet, which will be described later, to inform the user of the token sender.

[0107] The token transmission system 51 can transmit the type of token specified in the second specification unit 722B in the blockchain selected in the selection unit 710 to the address corresponding to the email address specified in the input unit 721A, in the quantity specified in the first specification unit 722A.

[0108] However, at the time of inputting on screen 700, an address corresponding to the email address specified in input section 721A does not necessarily have to exist (see FIG. 5).

[0109] When the input on screen 700 is completed, the system 51 provides the terminal 31 with a confirmation screen 800 shown in Fig. 8. The confirmation screen 800 is a screen for confirming the input content 810 on screen 700. Screen 800 in Fig. 8 shows that the input content 810 indicates that the "AAA" blockchain has been selected (CHAIN:AAA), that approximately 10 units of "BBB" tokens (fungible tokens) are to be sent (REQUIRED NUMBER OF TOKENS: 10@BBB), and that john@example.com has been specified as the recipient email address (RECEIVER EMAIL: john@example.com).

[0110] 8, "CONTRACT ADDRESS" indicates the address of the smart contract 22 (see FIG. 4) in the selected blockchain AAA. As will be described later, tokens sent to the recipient are temporarily deposited in the smart contract 22, so "CONTRACT ADDRESS" indicates the address where the tokens are deposited.

[0111] Also, "REQUIRED FEE: 0.2@AAA" indicates the amount of the token sending fee (so-called "gas fee") on the blockchain. Here, the gas fee is paid by the token sender, and the token receiver does not have to pay it. Therefore, the token receiver can obtain the token for free.

[0112] Once the token sender has confirmed the input content 810, the system 51 executes a setting process for token transmission in accordance with the input content 810 (step S502 in FIG. 5). The system 51 also executes a process for sending an email to the email address specified in the input section 721A (step S503).

[0113] As shown in FIG. 4, in step S502, the system 51 deposits tokens of the type and quantity according to the input content 810 into the smart contract 22 of the selected blockchain. To deposit the tokens into the smart contract 22, the system 51 executes a transmission process to transmit the tokens owned by the token sender to the smart contract 22 in the blockchain selected by the selection unit 710. Through the transmission process, for example, the tokens are transmitted from the sender's address 0x1111111111 to the contract address 0x3333333333 of the smart contract 22. As a result, the smart contract 22 temporarily holds the tokens to be transmitted to the receiver.

[0114] 4, in step S502, an email is sent from the system 51 to the user. The email to be sent includes, for example, a message indicating that tokens will be sent by airdrop or the like, or a message urging the user to obtain tokens by airdrop or the like. The email to be sent also includes a link (URL) for accessing the wallet provided by the wallet system 52. The email to be sent may include a message urging the user to access the wallet.

[0115] When steps S502 and S503 are completed, the system 51 provides the terminal 31 with a screen 900 of Fig. 9 indicating that the settings for token transmission have been completed. This completes the operation of the token sender.

[0116] As shown in Fig. 6, the user receives an email sent from the system 51 (S503A). The user operates the terminal 31 to open the email, selects the link contained in the email, accesses the wallet (step S503B), and can log in to the wallet (step S511 in Figs. 4 and 5).

[0117] Fig. 6 shows the procedure of processing executed by the wallet system 52 and the wallet management system 53 for logging in to the email wallet. Fig. 10 shows the transition of the email wallet screen displayed on the user's terminal 32. The screen shown in Fig. 10 is provided to the user's terminal 32 by the wallet system 52.

[0118] When the user accesses the wallet from terminal 32, a login start screen shown in Fig. 10(A) is displayed. When the user selects button 110 (login or account creation button) on this login start screen, an email address input screen shown in Fig. 10(B) is displayed. The user inputs their own email address into input section 120 of this email address input screen (step S601 in Fig. 6). The email address to be input is the email address that is the email wallet login identifier (login ID; email wallet account) (in the case of logging in), or the email address to be set as a new email wallet login identifier (in the case of creating a new account).

[0119] When the wallet system 52 accepts input of an email address (step S601), the email address is authenticated by the wallet management system 53 (step S602). In this authentication, in order to confirm that the email address belongs to the user, the wallet management system 53 performs email authentication by sending an email to the email address. For email authentication, the email contains, for example, a one-time password. The user who receives the email enters the one-time password into the one-time password input screen shown in FIG. 10(C). This completes email authentication (step S603).

[0120] If the email authentication is successful, the wallet management system 53 determines whether a distributed network address (blockchain address) corresponding to the successfully authenticated email address is registered in the wallet management system 53 (step S604). That is, it determines whether correspondence data 53A (see FIG. 4) indicating the distributed network address corresponding to the successfully authenticated email address exists. Note that the correspondence data 53A may include not only the distributed network address corresponding to the email address but also a private key corresponding to the distributed network address. A user who has the successfully authenticated email address can use the private key to sign an electronic signature in the wallet.

[0121] If a distributed network address (blockchain address) corresponding to the successfully authenticated email address is registered in the wallet management system 53 ("Yes" in step S604 of FIG. 6), the wallet management system 53 provides an address corresponding to that email address to the wallet system 52. Therefore, the wallet system 52 obtains an address (wallet address) corresponding to the email address input in step S601.

[0122] The wallet system 52 completes the user's login by treating the login using an email address as a login identifier as a login using the wallet address corresponding to that email address as a login identifier (step S606). When the login is complete, the wallet screen of FIGS. 10(D1) and 10(D2) is displayed on the user's terminal 32. The wallet screen has a display unit 150 for tokens (e.g., both non-fungible tokens and fungible tokens) at the wallet address corresponding to the email address. The display unit 150 displays the tokens at the wallet address. To display this wallet screen, the wallet system 52 accesses the blockchain 20, obtains information about tokens recorded in association with the wallet address corresponding to the email address, and provides the obtained information to the terminal 32.

[0123] If the distributed network address (blockchain address) corresponding to the successfully authenticated email address is not registered in the wallet management system 53 ("Not present" in step S604 of Figure 6), the wallet management system 53 creates a new email wallet account and associates the successfully authenticated email address with the wallet address indicating the new account (step S605).

[0124] To associate a new wallet address with an email address, the wallet management system 53 generates a new private key and generates a new wallet address (email wallet account) from the private key. The wallet management system 53 associates the successfully authenticated email address with the wallet address and private key, and stores the association data 53A (see FIG. 4). The association data 53A indicates the association between the email address, wallet address, and private key. The stored association data 53A is referenced for email authentication the next time a user logs in using the email address.

[0125] Furthermore, the wallet management system 53 provides the wallet address associated with the email address to the wallet system 52. Therefore, the wallet system 52 can acquire the address (wallet address) associated with the email address entered in step S601 (step S605). As a result, the wallet system 52 grasps the new association between the email address and the wallet address.

[0126] Furthermore, in step S605, the wallet system 52 transmits correspondence data 51D indicating the correspondence between the email address and the wallet address to the token transmission system 51 (see FIG. 4). The token transmission system 51 stores the received correspondence data 51D. This allows the token transmission system 51 to grasp the new correspondence between the email address and the wallet address.

[0127] When step S605 is completed, the wallet system 52 treats the login using the email address as the login identifier as a login using the wallet address corresponding to the email address as the login identifier, and completes the login by the user (step S606).

[0128] Returning to Figure 5, when the user logs in to the email wallet (step S511), the wallet screen of Figure 10 (D1) is displayed (step S512). Since the correspondence between the email address and the wallet address is established in step S605 of Figure 6, even if the user designated as the token recipient does not have a wallet address at the time of step S501 of Figure 5, the token transmission system 51 can later determine the wallet address corresponding to the email address and can transmit tokens.

[0129] The token transmission system 51 may send the token as soon as it knows the wallet address corresponding to the email address, but in this case, it will have the user perform the operation to acquire the token, which leaves it up to the user to decide whether or not to acquire the token.

[0130] The token transmission system 51 displays an airdrop banner 140 (a user interface (UI) for token acquisition operations) on the screen of the email wallet as shown in Fig. 10 (D1) to allow the user to perform operations to acquire tokens in the email wallet to which the user has logged in (step S512). The airdrop banner may include a sentence informing the user of the airdrop, such as "YOU HAVE AN AIRDROP."

[0131] To display a UI such as the airdrop banner 140, the token transmission system 51 refers to the correspondence data 51D and acquires a wallet address corresponding to the email address specified as the token transmission destination. Then, the token transmission system 51 transmits an instruction to the wallet system 52 to display a UI such as the airdrop banner 140 in the wallet of the acquired wallet address (step S512). Upon receiving this instruction, the wallet system 52 displays a UI such as the airdrop banner 140 on the wallet screen of the wallet address (see FIG. 10(D1)). Upon seeing the airdrop banner, the user performs a token acquisition operation, such as tapping the airdrop banner 140 on the wallet screen (step S513). When the token acquisition operation is performed, the wallet system 52 notifies the token transmission system 51 that the token acquisition operation has been performed (step S513). The token transmission system 51 receives a notification indicating that the token acquisition operation has been performed.

[0132] Note that even if a user logs in to a wallet address other than the wallet address corresponding to the email address designated as the token destination (a user account not eligible for airdrop), the airdrop banner 140 will not be displayed, as shown in FIG. 10(D2). In this way, the airdrop banner 140 and other UIs can be displayed only to users designated as targets for token distribution such as airdrop.

[0133] When the user performs a token acquisition operation in step S513, the token transmission system 51 transmits the specified token to the user's wallet address (the wallet address corresponding to the user's email address) (step S504). The transmitted token is displayed on the display unit 150 of the wallet screen shown in Fig. 10 (D1) (step S514). This allows the user to confirm the acquired token.

[0134] To transmit the token, the token transmission system 51 calls the smart contract 22 (see step S504 in FIG. 4). For example, when the token transmission system 51 is called, it instructs the smart contract 22 to transmit the token specified in step S501 to the blockchain address (e.g., 0x2222222222) of the user who performed the token acquisition operation. The called smart contract 22 then executes a transmission process to transmit the token to the user. Through this transmission process, for example, the token is transmitted from the contract address 0x3333333333 of the smart contract 22 to the user's address 0x222222222. As a result, the token previously held by the smart contract 22 is transmitted to the user.

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

[0136] 10: System 20: Blockchain 22: Smart Contract 31: Sender terminal 32: Recipient terminal 33: Recipient terminal 50: Token Management System 51: Token sending system 51A: Processor 51B: Memory 51C: Computer Program 51D: Compatible data 51E: Token sending process 52: Wallet System 53: Wallet Management System 53A: Compatible data 110: Button 120: Input section 140: Airdrop banner 150:Display section 700:screen 710: Selection section 720: Setting section 721: Email address specification section 721A: Input section 721B: Upload section 722: Token specification part 722A: 1st designated part 722B :Second designated part 723: Input section 800: Confirmation screen 810: Input content 900:screen

Claims

1. 1. A computer-implemented method performed by a computer, comprising: Accepting a destination identifier other than an address indicating a destination of a token in a distributed network as a destination of the token to be transmitted in the distributed network; acquiring the address corresponding to the designated destination identifier based on data that sets the correspondence between the destination identifier and the address in the distributed network; Sending the token to the acquired address. A computer-implemented method comprising:

2. The destination identifier is an email address. The computer-implemented method of claim 1 .

3. Receiving the designation of the destination identifier includes receiving the designation of an unaddressed identifier that does not correspond to the address, acquiring the address is executed after the correspondence between the address-unset identifier and the address is set. The computer-implemented method of claim 1 .

4. transmitting the token is executed by accepting an operation requesting acquisition of the token in an application for displaying the token; The computer-implemented method of claim 1 .

5. Transmitting the token comprises: receiving an operation to request acquisition of a token in an application that allows login using the destination identifier as a login identifier; When the operation is accepted, the token is sent to the address corresponding to the destination identifier used for login. Including, The computer-implemented method of claim 1 .

6. the data is set when a user logs in to an application that allows login using the destination identifier as a login identifier, using the destination identifier as the login identifier; The computer-implemented method of claim 1 .

7. 1. A computer-implemented method performed by a computer, comprising: Accept the email address specification, acquiring a distributed network address corresponding to the specified email address based on data in which correspondence between email addresses and distributed network addresses is set; Sending the token to the obtained decentralized network address; A computer-implemented method comprising:

8. In a distributed network application that allows users to log in using an email address as a login identifier, when a user logs in using an email address set as a destination of a token transmitted on the distributed network as the login identifier, a user interface for accepting a user operation to request acquisition of the token is displayed on a screen after login. A computer-implemented method comprising:

9. Accepting a destination identifier other than an address indicating a destination of a token in a distributed network as a destination of the token to be transmitted in the distributed network; acquiring the address corresponding to the designated destination identifier based on data that sets the correspondence between the destination identifier and the address in the distributed network; Sending the token to the acquired address. A system configured to perform processing including:

10. Accept the email address specification, acquiring a distributed network address corresponding to the specified email address based on data in which correspondence between email addresses and distributed network addresses is set; Sending the token to the obtained decentralized network address; A system configured to perform processing including:

11. In a distributed network application that allows users to log in using an email address as a login identifier, when a user logs in using an email address set as a destination of a token transmitted on the distributed network as the login identifier, a user interface for accepting a user operation to request acquisition of the token is displayed on a screen after login. A system configured to perform processing including:

12. Accepting a destination identifier other than an address indicating a destination of a token in a distributed network as a destination of the token to be transmitted in the distributed network; acquiring the address corresponding to the designated destination identifier based on data that sets the correspondence between the destination identifier and the address in the distributed network; Sending the token to the acquired address. A computer program for causing a computer to execute a process including the steps of:

13. Accept the email address specification, acquiring a distributed network address corresponding to the specified email address based on data in which correspondence between email addresses and distributed network addresses is set; Sending the token to the obtained decentralized network address; A computer program for causing a computer to execute a process including the steps of:

14. In a distributed network application that allows users to log in using an email address as a login identifier, when a user logs in using an email address set as a destination of a token transmitted on the distributed network as the login identifier, a user interface for accepting a user operation to request acquisition of the token is displayed on a screen after login. A computer program for causing a computer to execute a process including the steps of:

Images