Methods, systems, servers, and computer programs for short-range wireless communication.

Abstract

To make it possible to execute processing such as automatic transactions in a block chain, using short-range radio communication.SOLUTION: A disclosed method is a method for using short-range radio communication, and includes transmitting communication data from a first device that performs short-range radio communication to a second device used for calling a smart contract implemented in a block chain via the short-range radio communication. The communication data includes first data, and the first data is used for calling the smart contract.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure relates to a method of using, a system for, and a computer program for short-range wireless communication.

Background Art

[0002] Short-range wireless communication (Near Field Communication) can be performed in devices such as smartphones, for example, and is used for electronic payment and the like.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

[0004] Short-range wireless communication is performed, for example, by holding a device such as a smartphone over a device capable of performing short-range wireless communication such as an NFC tag. Thus, in order to perform short-range wireless communication, it is necessary to bring devices capable of performing short-range wireless communication close to each other. Conversely, when devices capable of performing short-range wireless communication are far apart, short-range wireless communication cannot be performed.

[0005] The characteristic of short-range wireless communication that devices need to be brought close to each other enables a person having a device such as a smartphone to be attracted near a short-range wireless communication device such as an NFC tag. Also, the characteristic of short-range wireless communication that devices need to be brought close to each other enables preventing data from being acquired from the short-range wireless communication device at a location away from the short-range wireless communication device.

[0006] Furthermore, short-range wireless communication is a type of wireless communication that uses electromagnetic waves, and wireless communication data is invisible. In addition, because short-range wireless communication is conducted over short distances, the possibility of communication data being leaked to a third party is low. Thus, short-range wireless communication also possesses the characteristic of excellent data confidentiality.

[0007] Here, the inventors conceived the idea of ​​initiating automated transaction processing on the blockchain based on the physical location of a person or object outside the blockchain.

[0008] Generally, automated transactions and other processes performed on a blockchain are executed by smart contracts once predetermined execution conditions are met. Since a blockchain is a computer network composed of multiple distributed computers, generally, the aforementioned execution conditions only need to be met on that computer network. In other words, the aforementioned execution conditions are independent of the physical location of people or objects outside the blockchain.

[0009] In contrast, if the execution of automated transactions and other processes on the blockchain can be constrained by the physical location of people or objects in the real world outside the blockchain, then the execution of automated transactions and other processes on the blockchain can be linked to the real world. If such a link to the real world becomes possible, further development of automated transactions and other processes on the blockchain can be expected.

[0010] As mentioned above, short-range wireless communication has the characteristic of requiring devices to be close together, making it suitable from the standpoint of addressing location constraints. Furthermore, if location constraints are broken against the intention of the person who imposed them, the location constraints become meaningless. However, short-range wireless communication also has the characteristic of excellent data confidentiality, making it suitable in that it is easy to maintain location constraints by utilizing data confidentiality.

[0011] Therefore, it is desirable to use short-range wireless communication to enable automated transactions and other processes on the blockchain.

[0012] One aspect of this disclosure is a method of using short-range wireless communication. The method of disclosure may include transmitting communication data from a first device performing short-range wireless communication to a second device used to invoke a smart contract implemented on a blockchain, via the short-range wireless communication. The communication data includes first data, which is used to invoke the smart contract.

[0013] Another aspect of this disclosure is a system using short-range wireless communication. The system of the disclosure may comprise a smart contract implemented on a blockchain and a short-range wireless communication device that transmits communication data via short-range wireless communication to a device used to invoke the smart contract. The communication data includes first data, which is used to invoke the smart contract.

[0014] Another aspect of this disclosure is a computer program. The computer program of the disclosure is a computer program that causes a device performing short-range wireless communication to perform processing, the processing includes an invocation process for calling a smart contract implemented on a blockchain, the invocation process being configured to be executed when it receives communication data via short-range wireless communication, the communication data including first data, the first data being used in the invocation process.

[0015] Further details will be described in the embodiments below. [Brief explanation of the drawing]

[0016] [Figure 1] Figure 1 is a schematic diagram of the system according to the embodiment. [Figure 2] Figure 2 is a schematic diagram showing the first example of how to invoke a smart contract. [Figure 3] Figure 3 is a schematic diagram showing a second example of a smart contract calling method. [Figure 4] Figure 4 is a schematic diagram showing a third example of a smart contract calling method. [Figure 5] Figure 5 is a schematic diagram of a smart contract. [Figure 6] Figure 6 is a diagram showing an example of a system. [Figure 7] Figure 7 is an explanatory diagram showing an example of obtaining first data. [Figure 8] Figure 8 is a flowchart showing a procedure for obtaining second data using first data to call a smart contract. [Figure 9] Figure 9 is a flowchart showing a procedure for calling a smart contract using a second URI. [Figure 10] Figure 10 is a configuration diagram of a first server. [Figure 11] Figure 11 is an explanatory diagram of a method for generating a second URI from a first URI. [Figure 12] Figure 12 is a configuration diagram of a second server. [Figure 13] Figure 13 is an explanatory diagram of a method for obtaining smart contract call data using a second URI. [Figure 14] Figure 14 is an explanatory diagram of data transmitted to a blockchain for calling a smart contract. [Figure 15] Figure 15 is an explanatory diagram of an example of token distribution by a smart contract. [Figure 16] Figure 16 is an explanatory diagram of a procedure for obtaining second data from first data. [Figure 17] Figure 17 is an explanatory diagram of another example of first data. [Figure 18] Figure 18 is a flowchart showing a preset procedure. [Figure 19] Figure 19 is a flowchart showing a preset procedure. [Figure 20]Figure 20 is an explanatory diagram of another example of the first data. [Figure 21] Figure 21 is an explanatory diagram of another example of the first data. [Modes for carrying out the invention]

[0017] <1. Overview of Method and System>

[0018] (1) The method according to the embodiment is a method for using short-range wireless communication, which may include transmitting communication data from a first device that performs short-range wireless communication to a second device used for calling a smart contract implemented on a blockchain via the short-range wireless communication. The communication data includes first data, and the first data is used for calling the smart contract.

[0019] (2) The method according to the embodiment preferably further comprises the following: the server receives an access from the second device using the first data; upon receiving the access using the first data, the server issues second data different from the first data and provides the second data to the second device. The second data preferably includes data that is sent to the blockchain for calling the smart contract.

[0020] (3) The second data preferably includes data provided to the smart contract.

[0021] (4) The second data preferably includes data relating to the tokens operated by the smart contract.

[0022] (5) The second data preferably includes data for identifying the smart contract to be invoked.

[0023] (6) The first data is preferably used to obtain the second data to be sent to the blockchain for the invocation of the smart contract.

[0024] (7) The first data preferably includes data that is sent to the blockchain for the invocation of the smart contract.

[0025] (8) The first data preferably includes data provided to the smart contract.

[0026] (9) The first data preferably includes data relating to the tokens operated by the smart contract.

[0027] (10) The first data preferably includes data for identifying the smart contract to be invoked.

[0028] (11) The first data preferably includes a private key for the blockchain account.

[0029] (12) The system according to the embodiment is a system using short-range wireless communication, which may include a smart contract implemented on a blockchain and a short-range wireless communication device that transmits communication data via short-range wireless communication to a device used to invoke the smart contract. The communication data includes first data, and the first data is used to invoke the smart contract.

[0030] (13) The computer program according to the embodiment is a computer program that causes a device that performs short-range wireless communication to perform processing, wherein the processing includes a call processing for calling a smart contract implemented on a blockchain, the call processing is configured to be executed when communication data is received via short-range wireless communication, the communication data includes first data, and the first data is used in the call processing.

[0031] <2. Examples of Methods and Systems>

[0032] Figure 1 shows an example of a system 10 according to an embodiment. This system 10 is a system that utilizes smart contracts 22 of a blockchain 20.

[0033] Blockchain 20 is composed of a P2P (Peer to Peer) computer network system in which multiple computers are interconnected.

[0034] In Blockchain 20, transactions are possible between blockchain addresses. Transaction records are recorded on the distributed ledger of Blockchain 20. Blockchain addresses represent, for example, user accounts 25A and 25B in Blockchain 20. For example, if a user U1 has account 25A in Blockchain 20, that account has a predetermined blockchain address.

[0035] In Blockchain 20, for example, tokens can be traded. Tokens tradable in Blockchain 20 include fungible tokens (FTs) and non-fungible tokens (NFTs). Fungible tokens are cryptocurrencies such as Ether in Ethereum. Fungible tokens may also be proprietary fungible tokens issued on the blockchain by companies or individuals.

[0036] Non-fungible tokens (NFTs), unlike fungible tokens (FTs), are tokens that do not possess fungibility. To ensure non-fungibility, NFTs have a unique identifier on the blockchain that allows them to be distinguished from other NFTs. Hereafter, this identifier will be referred to as the NFT identifier. The NFT identifier is recorded, for example, in the blockchain address (contract address) for the NFT.

[0037] In Blockchain 20, NFTs or fungible tokens owned by users U1 and U2 are recorded in association with user accounts 25A and 25B.

[0038] Blockchain 20 incorporates smart contracts 22. Smart contracts 22 consist of software (computer programs) implemented in a way that makes them executable on the blockchain. Smart contracts 22 automatically execute predetermined protocols, such as automated transactions.

[0039] The aforementioned blockchain address may also refer to the contract address of Smart Contract 22. The contract address is the blockchain address where Smart Contract 22 is stored.

[0040] In Blockchain 20, smart contracts 22 can also own NFTs or fungible tokens. In Blockchain 20, NFTs or fungible tokens owned by smart contracts 22 are recorded in association with the smart contract address of smart contract 22.

[0041] The operations performed by smart contracts 22 include, for example, token operations. Token operations include, for example, changing the ownership of tokens. The operation of changing token ownership is also called sending tokens. That is, changing the ownership of a token from a first blockchain address to a second blockchain address is also equivalent to sending tokens from the first blockchain address to the second blockchain address.

[0042] Sending a token, for example, means sending a token from the contract address of smart contract 22 to another blockchain address (for example, a user account).

[0043] Furthermore, token manipulation is not limited to changing (sending) the ownership of the token; any processing related to the token is sufficient.

[0044] The smart contract 22 is invoked, for example, by an operation from outside the smart contract 22, and the processing performed by the smart contract 22 is executed. The smart contract 22 is invoked, for example, from user accounts 25A and 25B.

[0045] The terminals 31 and 32 of users U1 and U2 can be used to invoke the smart contract 22. In other words, terminals 31 and 32 are devices used to invoke the smart contract 22 of the blockchain 20.

[0046] Terminals 31 and 32 are, for example, handheld devices such as smartphones. Users U1 and U2's terminals 31 and 32 invoke the smart contract 22, for example, by using an application program for invoking the smart contract 22. The application program for invoking the smart contract 22 may be a local application program running on terminals 31 and 32, or it may be a web application program provided by a web server.

[0047] In this embodiment, near-field communication (NFC) may be used to invoke the smart contract 22. The NFC communication is preferably NFC-compliant. NFC is, for example, wireless communication using the 13.56 MHz frequency band. The communication range of the NFC is preferably 10 cm or less.

[0048] Terminals 31 and 32 are equipped with short-range wireless communication modules 31D and 32D (NFC modules 31D and 32D). Terminals 31 and 32 can perform short-range wireless communication with other short-range wireless communication devices 40.

[0049] Other short-range wireless communication devices 40 include, for example, a short-range wireless communication tag 40 (NFC tag 40). The NFC tag 40 is an IC tag for short-range wireless communication and communicates in accordance with the NFC standard. The NFC tag 40 does not require a power supply.

[0050] As shown in Figure 1, the NFC tag 40 comprises an antenna 41, a wireless circuit 42 connected to the antenna 41, a controller 43 connected to the wireless circuit 42, and a memory 44 connected to the controller 43. The memory 44 stores communication data 46 transmitted by short-range wireless communication. The communication data 46 is written to the memory 44 by a writing device (not shown).

[0051] In this embodiment, communication data 46 is transmitted from the NFC tag 40 (a device that performs short-range wireless communication (first device)) to terminals 31 and 32 (devices used to call the smart contract 22 (second device)). For example, when users U1 and U2 hold terminals 31 and 32 over the NFC tag 40, communication data 46 is transmitted to terminals 31 and 32 via short-range wireless communication.

[0052] Terminals 31 and 32, having received the communication data 46, use the received communication data 46 to invoke the smart contract 22. In other words, in this embodiment, when terminals 31 and 32 receive the communication data 46 by performing short-range wireless communication (step S11), processing for invoking the smart contract 22 (step S12) begins. That is, in this embodiment, short-range wireless communication acts as a trigger for invoking the smart contract 22. The processing for invoking the smart contract 22 may include not only the invocation of the smart contract 22 itself, but also processing to prepare for the invocation of the smart contract 22.

[0053] The communication data 46 may include first data 110 used for calling the smart contract 22. In an embodiment, the first data 110 does not have to be data sent to the blockchain 20 for calling the smart contract 22; for example, the first data 110 may be data used to retrieve data sent to the blockchain 20 for calling the smart contract 22. That is, the first data may be data used in the process of preparing for calling the smart contract 22.

[0054] Multiple NFC tags 40 (near-field communication devices 40) may be used to transmit the communication data 46. Each of the multiple NFC tags 40 may transmit the same communication data 46. Alternatively, the communication data 46 transmitted by multiple NFC tags 40 may include the same first data 110.

[0055] Figures 2 to 4 show several examples of how to invoke a smart contract 22 using the first data 110. Figure 2 shows the first example of how to invoke it. In the first example shown in Figure 2, the first data 110 is first obtained by the first data acquirer 201 (step S21). The acquisition of the first data 110 is used as a trigger for invoking the smart contract 22, for example. The first data acquirer 201 is, for example, a computer equipped with an interface for acquiring the first data 110 from an external source. The first data acquirer 201 is, for example, terminals 31 and 32 shown in Figure 1.

[0056] The first data 110 acquired by the acquirer 201 may be used to issue the second data 120. The first data 110 may, for example, be used to access the second data issuer 202 which issues the second data 120, to acquire the second data associated with the first data 110, or to convert it to the second data 120.

[0057] The second data 120 may be issued by the second data issuer 202. The second data issuer 202 is, for example, a computer configured to issue the second data. The second data issuer 202 may be a different computer from the first data acquirer 201. The second data issuer 202 is, for example, the first server 51 (see Figure 6) described later.

[0058] The first data acquirer 201 can access the second data issuer 202 (step S22). The first data 110 may be used for that access. The first data 110 may be transmitted to the second data issuer 202 as a result of that access.

[0059] Upon receiving access using the first data 110, the second data issuer 202 can issue the second data 120. The second data 120 may include data to be sent to the blockchain 20 for the invocation of the smart contract 22. Since the data to be sent to the blockchain 20 for the invocation of the smart contract 22 is issued by the issuer 202, the first data 110 does not need to include data to be sent to the blockchain 20 for the invocation of the smart contract 22.

[0060] The second data issuer 202 may issue the second data 120 according to a pre-configured issuance protocol. The issuance protocol may include issuance conditions for the second data 120. The issuance protocol may include a step of issuing the second data 120 according to the issuance conditions. The second data issuer 202, upon receiving access using the first data 110, may not issue the second data 120 if the issuance conditions are not met, and may issue the second data 120 if the issuance conditions are met. By setting issuance conditions, it becomes possible to handle the situation by not issuing the second data 120 even if there is access to the second data issuer 202.

[0061] For example, if you want to limit the issuance of the second data 120 to the same user U1, U2 or the same terminal 31, 32 to once per day, you can set the issuance condition as no access to the second data issuer 202 by the same user U1, U2 or the same terminal 31, 32 on the same day.

[0062] The issuing protocol may include a step of identifying a second data 120 corresponding to a first data 110 used for access. In this case, the appropriate second data 120 can be issued according to the first data 110 used for access. For example, if there are multiple types of first data 110 that can be used for access, the appropriate second data 120 can be issued according to the type of first data 110 by identifying the second data 120 corresponding to the type of first data 110 used for access.

[0063] The issuance protocol may include a step of selecting the second data 120 to be issued from among a plurality of second data candidates. The selection may be made according to a predetermined rule or randomly. Preferably, the plurality of second data candidates are each different unique data. The second data issuer 202 may issue only one second data 120 at a time, or it may issue multiple second data 120 at a time.

[0064] For example, if multiple types of candidate second data are associated with one type of first data 110, the second data issuer 202 can select the second data 120 to be issued from among the multiple types of candidate second data associated with the first data 110 used for access. In this case, if there are multiple accesses using the same type of first data 110, a different type of second data 120 can be issued for each access. In other words, the second data can be issued as different unique data for each access using the first data 110.

[0065] The issued second data 120 is provided to the caller 203 (step S23). The caller 203 is, for example, a computer configured to make a call to the smart contract 22. The caller 203 may be the same computer that constitutes the first data acquirer 201, the same computer that constitutes the second data issuer 202, or a different computer. The function of the caller 203 may be realized by the coordinated operation of multiple computers. For example, the caller 203 may consist of a terminal 31 and another computer (e.g., a server 52) that the terminal 31 accesses.

[0066] The caller 203 is configured to send data to the blockchain 20 in order to invoke the smart contract 22. The caller 203 obtains the data to be sent to the blockchain 20 as the second data 120 from the second data issuer 202 (step S23). The caller 203 sends some or all of the data contained in the second data 120 to the blockchain 20 (step S24).

[0067] The data that the caller 203 sends to the blockchain 20 may be, for example, data provided to the smart contract 22 (data received by the smart contract 22). The data provided to the smart contract 22 may be, for example, the token code described later.

[0068] The data that the caller 203 sends to the blockchain 20 may be data relating to the tokens manipulated by the called smart contract 22. This data relating to the tokens manipulated by the smart contract 22 is, for example, the token code described later.

[0069] The data that the caller 203 sends to the blockchain 20 may be data that identifies the smart contract 22 to be invoked. The data that identifies the smart contract 22 to be invoked may be, for example, the contract address of the smart contract 22.

[0070] To facilitate the use of blockchain, it is desirable that data sent to blockchain 20 for calling smart contract 22 can be easily obtained. In particular, even if the data obtained by the device used to call smart contract 22 on blockchain 20 is not data sent to the blockchain for calling smart contract 22, it is desirable that the device can still obtain data sent to the blockchain for calling smart contracts.

[0071] In other words, according to the first example shown in Figure 2, even when the acquisition of the first data 110 is used as the trigger for calling the smart contract 22, the first data 110 does not necessarily have to contain data that is sent to the blockchain 20 for the purpose of calling the smart contract 22. Furthermore, according to the first example, even while the acquisition of the first data 110 is used as the trigger for calling the smart contract 22, the smart contract 22 can be called using second data 120 that is different from the first data 110.

[0072] Figure 3 shows a second example of how to make the call. The second example is the same as the first example shown in Figure 2, except that no further explanation is given. In the second example shown in Figure 3, unlike the first example, the first data 110 is used to send it to the blockchain 20.

[0073] In other words, in the second example, first data 110 is acquired by the first data acquirer 201 (step S31). Part or all of the acquired first data 110 is provided to the caller 203 (step S32).

[0074] The caller 203 obtains data to be sent to the blockchain 20 (part or all of the first data 110) from the first data retriever 201 (step S32). The caller 203 sends part or all of the obtained data to the blockchain 20 (step S33).

[0075] The data that the caller 203 sends to the blockchain 20 may be, for example, data provided to the smart contract 22 (data received by the smart contract 22). The data that the caller 203 sends to the blockchain 20 may be data relating to tokens manipulated by the called smart contract 22. The data that the caller 203 sends to the blockchain 20 may be data identifying the smart contract 22 to be called.

[0076] According to the second example shown in Figure 3, the first data acquired by the first data acquirer 201 can be used for transmission to the blockchain 20.

[0077] Figure 4 shows a third example of the calling method. The third example is the same as the first example shown in Figure 2 or the second example shown in Figure 3, except that it is not specifically explained. In the third example shown in Figure 4, both the first data 110 and the second data 120 are used to send to the blockchain 20.

[0078] In other words, in the third example, first data 110 is acquired by the first data acquisition device 201 (step S41).

[0079] The first data 110 acquired by the first acquirer 201 can be used to issue the second data 120 by the second data issuer 202. The first data 110 can also be provided to the caller 203.

[0080] The first data acquirer 201 can access the second data issuer 202 using the first data 110 (step S42). The first data 110 can be transmitted to the second data issuer 202 through this access.

[0081] Upon receiving an access request using the first data 110, the second data issuer 202 can issue the second data 120.

[0082] The issued second data 120 is given to the caller 203 (step S43). The caller 203 obtains the data to be sent to the blockchain 20 from the second data issuer 202 (step S43). The caller 203 can also obtain the data to be sent to the blockchain 20 from the first data retriever 201 (step S44).

[0083] The caller 203 transmits some or all of the data contained in the first data 110 and some or all of the data contained in the second data 120 to the blockchain 20 (step S45).

[0084] The data that the caller 203 sends to the blockchain 20 may be, for example, data provided to the smart contract 22 (data received by the smart contract 22). The data that the caller 203 sends to the blockchain 20 may be data relating to tokens manipulated by the called smart contract 22. The data that the caller 203 sends to the blockchain 20 may be data identifying the smart contract 22 to be called.

[0085] According to the second example shown in Figure 3, not only can the first data acquired by the first data acquirer 201 be used for transmission to the blockchain 20, but the second data 120 issued by the second data issuer 202 can also be used for transmission to the blockchain 20.

[0086] Figure 5 shows an example of the processing performed by the smart contract 22 that receives the call. The smart contract 22 shown in Figure 5 is configured to cause the computers constituting the blockchain 20 to execute the process of sending tokens from the contract address 21 of the smart contract 22 to the user accounts 25A and 25B that called the smart contract 22. Note that the contract address 21 of the smart contract 22 may be used to identify the smart contract 22 that is being called.

[0087] The smart contract 22 shown in Figure 5 is invoked, for example, from accounts 25A and 25B (step S51). When invoked, token codes C1 and C2 are sent from accounts 25A and 25B to the contract address 21 of the smart contract 22. When invoked, the contract address 21 of the smart contract 22 may also be sent from accounts 25A and 25B to identify the smart contract 22 to be invoked. The smart contract 22 shown in Figure 5 is configured to send tokens as a trigger when it receives token codes.

[0088] Here, the token code may be used to identify the object being manipulated by the smart contract 22. The token code may be used by the smart contract 22 to identify, for example, a non-fungible token (NFT) that is being manipulated by the smart contract 22. For example, the smart contract 22 can use the received token code C1 to identify the NFT to be sent and then send the identified NFT.

[0089] Furthermore, the token code can be used by smart contract 22 to identify the number of fungible tokens (FTs) to be manipulated by smart contract 22. For example, smart contract 22 can use the received token code C2 to identify the number of FTs (token count) to send and send the identified number of FTs.

[0090] The token code may be used to identify the type of token being manipulated by the smart contract 22. For example, the token code may be used to identify whether the token being manipulated by the smart contract 22 is a non-fungible token or a fungible token. Furthermore, if multiple types of fungible tokens exist, the token code may be used to identify the type of non-fungible token being manipulated.

[0091] The smart contract 22 may include a token table 310 for identification using the received token codes C1 and C2. The token table 310 is data that associates token codes with the identification content associated with those token codes. The identification content associated with the token codes may be, for example, a token identifier or the number of tokens, as shown in Figure 5.

[0092] The information identified by the token code in smart contract 22 (the information identified by the token code) could be, for example, the identifier of the non-fungible token to be sent (NFT identifier). Alternatively, the information identified by the token code could be, for example, the number of fungible tokens. Furthermore, the information identified by the token code could be the type of fungible token and the number of those fungible tokens.

[0093] In the token table 310 shown in Figure 5, for example, token code C1 is associated with the NFT identifier "NFT_id01". Also, token code C2 is associated with "10_tokens", where "10_tokens" indicates that there are 10 of a certain type of fungible token. Token code C3 is associated with "1_tokens", where "1_tokens" indicates that there is 1 of a certain type of fungible token.

[0094] Smart contract 22 already holds tokens 410, 420, 430, and 450, which are the targets (to be sent) identified by the token code. Upon receiving the token code, smart contract 22 identifies the target token (to be sent) from among its held tokens 410, 420, 430, and 450, and sends the identified token.

[0095] For example, smart contract 22 receives token code C1 from account 25A (step S51). Then, smart contract 22 refers to table 310 and identifies a non-fungible token 410 with the identifier "NFT_id01" as the target of operation corresponding to token code C1. Then, smart contract 22 sends the non-fungible token 410 to account 25A (step S52). Since there is only one non-fungible token 410 with the identifier "NFT_id01", if the target of operation (the target to be sent) is a non-fungible token, the target of operation (the target to be sent) can be identified by the NFT identifier.

[0096] Furthermore, smart contract 22 receives token code C2 from account 25B, for example (step S51). Smart contract 22 then refers to table 310 and identifies "10_tokens" as the target of the operation corresponding to token code C2. That is, smart contract 22 identifies that the number of non-fungible tokens to be sent is 10 units. Smart contract 22 then sends the identified number (10 units) of fungible tokens from its holdings of fungible tokens 450 to account 25B (step S52). Here, one fungible token is considered as one unit.

[0097] Fungible tokens are fungible, and each individual token does not have an identifier. Therefore, smart contract 22 identifies the number of tokens to be sent by token code C2, rather than identifying individual fungible tokens. If smart contract 22 can handle multiple types of fungible tokens, smart contract 22 may also identify the type of fungible token to be sent by token code C2.

[0098] It is preferable that token codes C1, C2, and C3 are data configured in such a way that they cannot identify the type or number of tokens being manipulated (sent) by anyone other than the smart contract 22. For example, it is preferable that token codes C1, C2, and C3 are data that represent values ​​that appear meaningless or random at first glance.

[0099] Furthermore, it is preferable that token codes C1, C2, and C3 are unique. It is preferable that the smart contract 22 is configured to accept the same token code C1, C2, and C3 only a predetermined number of times (for example, once). In other words, it is preferable that the number of times the token data can be used for calling the smart contract 22 is limited. In this case, the reuse of token codes C1, C2, and C3 is prevented.

[0100] The smart contract 22 shown in Figure 5 supports the sending of both non-fungible and fungible tokens, but it may also support the sending of only non-fungible tokens or only fungible tokens.

[0101] In this case, with regard to non-fungible tokens, token code C1 functions as an identifier for the non-fungible token being sent. However, the smart contract 22 shown in Figure 5 does not receive the non-fungible token identifier (e.g., "NFT_id01") recorded on blockchain 20 to identify the non-fungible token to be sent.

[0102] Here, smart contract 22 may be configured to send the non-fungible token indicated by the identifier ("NFT_id01") when it receives the identifier (e.g., "NFT_id01") of a non-fungible token recorded on the blockchain.

[0103] However, by using a token code that has a different identifier from the non-fungible token identifier recorded on the blockchain (for example, "NFT_id01"), it is possible to avoid unintentionally sending non-fungible tokens. In other words, if the non-fungible token identifier recorded on the blockchain ("NFT_id01") is used to send non-fungible tokens, and if the non-fungible token identifier recorded on the blockchain ("NFT_id01") is known to a third party, that third party can use that identifier ("NFT_id01") to illegally obtain non-fungible tokens from smart contract 22.

[0104] In contrast, when using a token code, even if the identifier of the non-fungible token ("NFT_id01") recorded on the blockchain is known to a third party, that third party will not be able to illegally acquire the non-fungible token.

[0105] Furthermore, regarding fungible tokens, token codes C2 and C3 function as identifiers for fungible tokens that do not have identifiers to distinguish each individual fungible token. For example, if we want smart contract 22 to send 10 units of fungible tokens, for example, 100 times, we only need to prepare 100 unique token codes. In this case, when smart contract 22 receives a token code, it will send 10 units of fungible tokens. In this case, the total number of fungible tokens sent is 1000 units, and each of these 1000 fungible tokens does not have an identifier. However, since the token codes function as identifiers for every 10 units of fungible tokens, it becomes easy to handle fungible tokens individually in units of 10.

[0106] Furthermore, it becomes possible to vary the number of fungible tokens sent for each token code, such as token codes C2 and C3.

[0107] Here, smart contract 22 may be configured to send the number of fungible tokens indicated in the received data (fungible token request) upon receiving data indicating the number of fungible tokens to be sent. However, in that case, there is no guarantee that the data indicating the number of fungible tokens to be sent (fungible token request) is appropriate. In other words, there is no guarantee that the fungible token request is appropriate.

[0108] Allowing inappropriate fungible token requests would enable third parties to fraudulently obtain non-fungible tokens from smart contract 22. In other words, there is a risk that fungible tokens could be unintentionally leaked from smart contract 22.

[0109] In contrast, when using token codes C2 and C3, those who do not possess token codes C2 and C3 cannot obtain fungible tokens from smart contract 22, thus preventing unintended outflow of fungible tokens. Furthermore, when using token codes C2 and C3, even if a third party learns the type of fungible token sent by smart contract 22, a third party who does not know the token code cannot illegally obtain the fungible tokens.

[0110] Although the smart contract 22 shown in Figure 5 already holds the non-fungible token to be sent, the smart contract 22 may generate the non-fungible token to be sent after receiving the token code (step S51). In other words, the token code associated with the NFT does not need to be pre-associated with a specific NFT identifier. The generated NFT may be generated based on predetermined generation rules or may be generated randomly.

[0111] Furthermore, the token code associated with the NF does not need to have a pre-associated number of tokens to be sent. The number of tokens to be sent may be determined by a predetermined rule or randomly.

[0112] Figure 6 shows an example of the elements constituting the system 10 according to the embodiment. The system 10 shown in Figure 6 may include servers 51 and 52 connected to a network 15. In Figure 6, a first server 51 and a second server 52 are provided as servers 51 and 52. The first server 51 and the second server 52 can access the blockchain via the network 15. Note that the first server 51 and the second server may be different computers or the same computer. Servers 51 and 52 may be managed by an administrator. The administrator may also be the installer of the short-range wireless communication device. The administrator may also be the administrator (creator) of the smart contract 22.

[0113] The user terminals 31 and 32 can access the first server 51 or the second server 52 via the network 15. The terminals 31 and 32 can access the blockchain via the network 15. System 10 may be equipped with NFC tags 40.

[0114] Terminal 31 is, for example, a mobile device such as a smartphone or tablet. The configuration of terminal 31 will be described below, but terminal 32 may have a similar configuration.

[0115] Terminal 31 is connectable to a network 15 such as the Internet. User terminal 31 may be composed of a computer comprising a processor 31A and a storage device 31B. The storage device 31B is connected to the processor 31A. The storage device 31B comprises, for example, a primary storage device and a secondary storage device. The primary storage device is, for example, RAM. The secondary storage device is, for example, a hard disk drive (HDD) or a solid-state drive (SSD). The storage device 31B contains a computer program 31C executed by the processor 31A. The processor 31A reads and executes the computer program 31C stored in the storage device 31B. The computer program 31C has program code that indicates instructions to be executed by the computer functioning as terminal 31.

[0116] The computer program 31C may be, for example, a wallet application program for displaying tokens stored in a user account on the blockchain 20 on the terminal 31. The application program 31C may provide functions for user operations for storing, sending, and receiving tokens. The application program 31C may also provide functions for calling the smart contract 22. That is, the processor 31A can execute the smart contract calling process 31F by executing the computer program 31C.

[0117] Furthermore, the application program 31C may provide a function for receiving communication data 46 from the NFC tag 40 via short-range wireless communication by the NFC module 31D.

[0118] The application program 31C may provide a function to store a private key 31E for an account on blockchain 20 in the storage device 31B of the terminal 31. The private key 31E is associated with user U1's account 25A. The private key 31E is used for digital signatures of transaction records on blockchain 20, etc. Since the private key 31E corresponds to an account on blockchain 20, the private key 31E corresponding to that account is required to call a smart contract 22 from the account and have tokens sent to that account.

[0119] Figure 7 shows an example of terminal 31 communicating via short-range wireless communication with NFC tag 40. In Figure 7, NFC tag 40 is attached to poster 500. The front surface 501 of poster 500 contains, for example, instructions on how a user can obtain a token using short-range wireless communication.

[0120] Surface 501, for example, displays "Step 1: Download the app" and a 2D code 501A for downloading the application program 31C. Furthermore, Surface 501 displays "Step 2: Tap the NFC on the app's home screen" and a diagram 501B showing the home screen of the application program 31C. Also, Surface 501 displays "Step 3: Hold your smartphone here" and a marker 510 indicating the position where terminals 31 and 32 should be held.

[0121] As shown in Figure 8, an NFC tag 40 is attached to the back surface 502 of the poster 500 at a position corresponding to the marker 510. The NFC tag 40 is attached to the poster 500, for example, by adhesive.

[0122] For example, user U1, upon viewing poster 500, downloads and installs application program 31C as needed, and then launches application program 31C. User U1 taps the NFC button displayed on the home screen of application program 31C to start short-range wireless communication by NFC module 31D. By holding terminal 31 near marker 510, terminal 31 comes into close proximity with NFC tag 40, and short-range wireless communication is performed. Through short-range wireless communication, communication data 46 stored in NFC tag 40 is transmitted to terminal 31 (step S71).

[0123] In this embodiment, a process for obtaining a token is triggered by the occurrence of short-range wireless communication (step S72). The process for obtaining the token is performed using a smart contract 22. The terminal 31 may execute a process for calling the smart contract in the application program 31C when triggered by the occurrence of short-range wireless communication. Upon execution of this process, user U1 can obtain a token (step S73).

[0124] The communication data 46 transmitted from the NFC tag 40 via short-range wireless communication may be the same each time. Alternatively, a short-range wireless communication device 40 capable of transmitting different communication data 46 for each communication may be used instead of the NFC tag 40.

[0125] In this embodiment, since a short-range wireless communication device 40 is attached to the poster 500, tokens can be distributed only to users U1 who come to the location where the poster 500 is displayed. Therefore, token distribution can be used to attract users to the location where the poster 500 is displayed.

[0126] In other words, when using short-range wireless communication, which offers excellent data confidentiality, the user needs to bring the terminal 31 close to the NFC tag in order to obtain a token. Therefore, since the user needs to approach the short-range wireless communication device 40 in order to obtain a token, the user can be lured to the location where the short-range wireless communication device 40 is located.

[0127] Short-range wireless communication offers excellent data confidentiality. For example, even if a short-range wireless communication device 40 is installed in a place easily visible to the public, it can prevent data from being disseminated to third parties. For instance, if data equivalent to communication data 46 is written on a poster 500, and the data written on the poster 500 is entered into a terminal 31, then if an image of the poster 500 is disseminated to a third party, that third party, who has not visited the location where the poster 500 was displayed, can also obtain the data. On the other hand, by using short-range wireless communication, it becomes possible to allow only users who approach the short-range wireless communication device 40 to acquire a token.

[0128] Furthermore, by installing the short-range wireless communication device 40 in locations frequented by many users, tokens can be distributed to users who approach the device 40. As a result, tokens can be distributed to many users, promoting their use.

[0129] Multiple posters 500 may be used for efficient token distribution. In this case, users can receive communication data 46 from the near-field wireless communication devices 40 of any of the posters 500 posted at any location. Multiple near-field wireless communication devices 40 only need to transmit the same communication data 46. Even if multiple near-field wireless communication devices 40 transmit communication data 46 containing different data from each other, the first data 110 may be common data. The different data may be, for example, the identifier of the near-field wireless communication device 40.

[0130] Furthermore, the short-range wireless communication device 40 does not need to be attached to the poster 500. The short-range wireless communication device 40 may be attached to other objects (mounting objects). The object to which the short-range wireless communication device 40 is attached does not need to be a stationary object; it may be a movable object such as a vehicle, or something that is attached to a movable object. In addition, the short-range wireless communication device 40 does not need to be attached to a mounting object; it may exist independently.

[0131] In Figure 7, the communication data 46 transmitted from the short-range wireless communication device 40 may include the first data 110 described above. Figure 8 shows an example of the first data 110 and an example of the procedure for issuing the second data 120 described above from the first data 110. Figure 8 also shows an example of the issued second data 120.

[0132] The first data 110 shown in Figure 8 is a Uniform Resource Identifier (URI). The URI is, for example, a Uniform Resource Locator, as shown in Figure 8. Hereafter, the URI as the first data 110 will be referred to as the first URI 110. The URI may also be a Uniform Resource Name.

[0133] The first URI 110 is used by the terminal 31 that has acquired the first data 110 to access the first server 51 via the network 15. As shown in Figure 8, the first URI 110 comprises a scheme 111 and an authority 113. The scheme 111 is at the beginning of the URI (URL) and represents the means for reaching the resource. For example, the scheme 111 is https:. The authority 113 is written following the scheme 111 and indicates the location of the resource, etc. Hereafter, the authority 113 of the first URI 110 will be referred to as the first authority 113.

[0134] The first authority 113 may comprise, for example, a first host 113A and specified data 113B. The first host 113A indicates the name (domain name) of the first server 51 to be accessed. The specified data 113B is, for example, a path described after the first host 113A. In the first authority 113 shown in Figure 8, the specified data 113B is, for example, "campaing / 1". "campaing / 1" may indicate, for example, a first campaign that distributes tokens to users.

[0135] Furthermore, the first data 110 only needs to be data used to access the first server 51. The first data 110 does not have to be written in URI (URL) format. For example, the first data 110 may consist only of the specified data 113B. If terminal 31 knows the name of the first server 51, the first URI 110 may be generated by terminal 31 using the specified data 113B obtained by terminal 31. In addition, the first data obtained by terminal 31 may be authentication data (for example, ID and password) for accessing and signing in to the first server 51 from terminal 31.

[0136] As shown in Figure 8, first, terminal 31 obtains the first URI 110 (step S81). Terminal 31 in Figure 8 may correspond to the first data acquirer 201 in Figure 2. Having read the first URI 110, terminal 31 uses the first URI 110 as a trigger to access the first server 51 (step S82).

[0137] Terminal 31 transmits data to the first server (step S82) that will be used in the issuance condition determination (step S84) described later. The data used in the issuance condition determination is, for example, information for identifying the user who has terminal 31 (user information), information for identifying terminal 31 (terminal information), time information, and location information of terminal 31, or at least one of two or more of these. User information is, for example, account 25A (blockchain address) of user U1 in blockchain 20. Terminal information is, for example, the MAC address of terminal 31. Access time information is, for example, the date and time when terminal 31 acquired the first data 110. Location information of terminal 31 is, for example, location information obtained by satellite positioning using the Global Navigation Satellite System (GNSS). For satellite measurement, terminals 31 and 32 may be equipped with GNSS receivers.

[0138] The location information of terminal 31 may be obtained from accessing network 15 by terminal 31, in addition to or instead of location information obtained by GNSS. The location information obtained from accessing network 15 may be, for example, the location information of a base station that is an access point to the mobile communication network. The location information obtained from accessing network 15 may also be location information obtained using the IP address assigned to terminal 31.

[0139] The data used for determining the issuance conditions may be added to the first URI 110. Alternatively, the data used for determining the issuance conditions may be sent from terminal 31 to the first server 51 after the connection between terminal 31 and the first server 51 is established by access using the first ULI 110.

[0140] Upon receiving an access request using the first data 110, the first server 51 executes the issuance process for the second data 120 (second URI issuance process; URI issuance process 51G in Figure 10). The first server 51 may correspond to the second data issuer 202 in Figure 2.

[0141] As shown in Figure 10, the first server 51 may be composed of a computer comprising a processor 51A and a storage device 51B. The storage device 51B is connected to the processor 51A. The storage device 51B comprises, for example, a primary storage device and a secondary storage device. The primary storage device is, for example, RAM. The secondary storage device is, for example, a hard disk drive (HDD) or a solid-state drive (SSD). The storage device 51B contains a computer program 51C executed by the processor 51A. The processor 51A reads and executes the computer program 51C stored in the storage device 51B. The computer program 51C has program code that indicates an instruction to cause the computer to execute a URI issuance process 51G.

[0142] Returning to Figure 8, in the issuance process 51G, the first server 51 first receives data used for determining the issuance conditions (user information or terminal information, etc.) and saves the received data (step S83). The data used for determining the issuance conditions may be saved along with the time the first server 51 received the data.

[0143] In the issuance process 51G, the first server 51 uses the received data to determine the issuance conditions (step S84). As shown in Figure 10, the first server 51 has pre-configured issuance conditions 51D for determining the issuance conditions. If the issuance conditions are not met, the first server 51 does not issue the second data 120 (step S89), and if the issuance conditions are met, it issues the second data 120 (steps S85-S87).

[0144] For example, issuance condition 51D could be, for instance, "Tokens can only be sent to the same user once a day," "Tokens can only be sent to the same device once a day," or "The device that acquired the first data must be located in a designated location."

[0145] If the issuance condition 51D is "only once per day is token sent to the same user", the first server 51 compares the received user information with past user information stored on the first server 51. If an access record based on the received user information already exists for the same day, the issuance condition is not met, and the first server 51 does not issue the second data 120 (step S89).

[0146] If there is no access record based on the received user information, or if there is an access record from the previous day or earlier, the first server 51 issues the second data 120 to satisfy the issuance conditions (steps S85-S87).

[0147] Similarly, if the issuance condition 51D is "only one token transmission per day to the same terminal", and there is no access record based on the received terminal information, or if there is an access record from the previous day or earlier, the issuance condition is met, and the first server 51 issues the second data 120 (steps S85-S87).

[0148] If the issuance condition 51D is "the terminal that acquired the first data is located at a predetermined location," then when the received location information matches the predetermined location set as the issuance condition 51D, the first server 51 issues the second data 120 to satisfy the issuance condition (steps S85-S87). Note that the location includes a broad range.

[0149] By setting the issuance condition that "the terminal that acquired the first data must be in a designated location," the second data 120 can only be issued when the terminal is in the designated location.

[0150] The use of the issuance condition "the terminal that acquired the first data must be located in a designated location," when combined with the use of short-range wireless communication, can more reliably restrict the location of the terminal that acquires the first data 110.

[0151] While the positional constraints imposed by short-range wireless communication are relative positional constraints, such as the proximity of the short-range wireless communication device 40 and the terminal 31, the use of the terminal 31's location information imposes absolute positional constraints on the terminal 31.

[0152] The absolute location constraint can be used, for example, to prevent theft of the short-range wireless communication device 40. For instance, if the absolute location of the terminal 31 is far from the original installation location of the short-range wireless communication device 40, the second data 120 will not be issued, thereby preventing the use of the stolen short-range wireless communication device 40, which is located in a different place than its original installation location.

[0153] In step S84, if it is determined that the issuance conditions are met, the first server 51 selects a token code. The token code may constitute the second data 120.

[0154] As shown in Figure 10, the storage device 51B of the first server 51 stores a token code list 51E. The token code list 51E has multiple token codes. Here, it is assumed that each of the multiple token codes is a different unique code. The multiple token codes are pre-generated and stored in the first server 51. The multiple token codes are associated one-to-one by code number.

[0155] The first server 51 refers to the token code list 51E and selects one or more token codes to issue (step S85). Preferably, each token code is issued only once. The first server 51 can issue the token codes, for example, in numerical order.

[0156] For example, if the first server 51 receives the first access using the first URI 110 and the access meets the issuance conditions, a token code "qC2oFsNKrHimID6u" with code number "1" is issued. Similarly, if the first server 51 receives the second access using the first URI 110 and the access meets the issuance conditions, a token code "FsNKrHimID67sj0" with code number "2" is issued. Likewise, if the first server 51 receives the third access using the first URI 110 and the access meets the issuance conditions, a token code "FsNKrHimID67sj0" with code number "3" is issued. The first server 51 can issue token codes a number of times corresponding to the number of token codes it possesses.

[0157] The first server 51 may have multiple token code lists 51E. For example, an administrator may plan a first campaign and a second campaign different from the first campaign for the purpose of distributing tokens. In this case, it may be desirable to distinguish between the tokens distributed in the first campaign and the tokens distributed in the second campaign. When distinguishing between tokens distributed in both campaigns, it is preferable that the token codes also be distinguished. To distinguish between token codes, the first server 51 may have a token code list for the first campaign and a token code list for the second campaign. In this case, the first server 51 may select a token code list prior to selecting a token code.

[0158] The designation data 113B (common code) included in the first data 110 may be used to select the token code list 51E. If the token code list 51E is, for example, a token code list for a first campaign, then when the first server 51 receives data indicating the first campaign (e.g., "campaign / 1") as the designation data 113B, it can select the token code list 51E for the first campaign and then select the token code to be issued from that token code list 51E.

[0159] The first server 51 issues the second data 120 using the selected token code (step S86). The second data 120 shown in Figure 8 is a Uniform Resource Identifier (URI). The URI is, for example, a Uniform Resource Locator as shown in Figure 8. Hereafter, the URI as the second data 120 will be referred to as the second URI 120. The URI may also be a Uniform Resource Name.

[0160] The second URI 120 is sent from the first server 51 to the terminal 31 (step S87). The terminal 31, having received the second URI 120, may use it to access the second server 52 via the network 15. If the conditions for issuing the second URI 120 are not met, the first server 51 sends an error message to the terminal 31 (step S89).

[0161] As shown in Figure 8, the second URI 120 comprises a scheme 121 and an authority 123. The scheme 121 is, for example, https:. The authority 123 is described following the scheme 121 and indicates the location of the resource, etc. Hereafter, the authority 123 of the second URI 120 will be referred to as the second authority 123.

[0162] The second authority 123 may comprise, for example, a second host 123A, contract information 123B, and a token code 123C. The second host 123A indicates the name (domain name) of the second server 52 to be accessed. The contract information 123B and token code 123C may be, for example, a path described after the second host 123A. In the second authority 123 shown in Figure 8, the contract information 123B is, for example, "receive-link / ", and the token code 123C is, for example, "qC2oFsNKrHimID6u". The token code 123C is sent to the blockchain 20 to invoke the smart contract 22.

[0163] Contract information 123B may be used to identify the caller. If the caller is a smart contract 22, contract information 123B may include the contract address 21 of the smart contract 22. If the smart contract 22 has one or more functions that are called, contract information 123B may further include the names of the functions that are called. In this embodiment, contract information 123B is converted by the second server 52 into data (such as the contract address of the smart contract 22) that is sent to the blockchain 20 to identify the caller.

[0164] Furthermore, the second data 120 only needs to contain data that is sent to the blockchain 20 in order to invoke the smart contract 22. The second data 120 does not have to be written in URI (URL) format. For example, the second data 120 may consist only of the token code 123C. If terminal 31 knows the name of the second server 52 and the contract information 123B, terminal 31, upon receiving the token code 123C, may generate the second URI 120. Also, the second data 120 may not have a second host 123A, but may contain contract information 123B and the token code 123C.

[0165] Furthermore, the second data 120 may include data that is converted into data sent to the blockchain 20 to invoke the smart contract 22, such as the contract information 123B. As described later, the contract information 123B is converted by the second server 52 into data (such as the contract address of the smart contract 22) that is sent to the blockchain 20 to identify the target of the invoke.

[0166] Figure 11 shows an example of the procedure for generating the second URI 120 from the first URI 110. The first server 51 (second data issuer 202), which functions as a second data issuer, generates the second URI body from the specified data 113B contained in the first URI 110. The first server 51 has a URI table 51F for generating the second URI body. As shown in Figure 10, the URI table 51F is configured by associating specified data with the URI body.

[0167] For example, in URI table 51F, the designated data "campaign / 1" representing the first campaign is associated with "bbb....com / receive-link / " as the body of the second URI. Similarly, the designated data "campaign / 2" representing the second campaign is associated with "bbb....com / receive_NFT-link / " as the body of the second URI. The designated data "campaign / 3" representing the third campaign is associated with "bbb....com / receive_FT-link / " as the body of the second URI.

[0168] The second URI body for the first campaign has "receive-link / " as contract information 123B for the first campaign. In other words, the specified data "campaign / 1" is associated with "receive-link / " for the first campaign as contract information 123B.

[0169] The second URI body for the second campaign contains "receive_NFT-link / " as contract information 123B for the second campaign. In other words, the specified data "campaign / 2" is associated with "receive_NFT-link / " for the second campaign as contract information 123B.

[0170] The second URI body for the third campaign contains "receive_FT-link / " as contract information 123B for the third campaign. In other words, the specified data "campaign / 3" is associated with "receive_FT-link / " for the third campaign as contract information 123B.

[0171] In this embodiment, as an example, the first campaign is one in which a user who has acquired the first data 110 can selectively acquire either a first type of non-fungible token (NFT) or a second type of fungible token (NF). The second campaign is one in which a user who has acquired the first data 110 can acquire a third type of non-fungible token (NFT) that is different from the first type. Furthermore, the third campaign is one in which a user who has acquired the first data 110 can acquire a fourth type of fungible token (FT) that is different from the second type.

[0172] Returning to Figure 11, the first server 51 refers to the URI table 51F and retrieves "bbb....com / receive-link" as the second URI body from the specified data "campaign / 1".

[0173] Furthermore, the first server 51 selects a token code from the token code list 51E associated with the specified data "campaign / 1" and determines a single token code. Here, as an example, the token code "qC2oFsNKrHimID6u" with code number 1 is selected.

[0174] The first server 51 generates the second URI 120 by combining the second URI body and the token code. For example, the first server 51 can add the token code to the second URI body as part of the path that follows the second URI body.

[0175] Furthermore, if there is only one campaign, and the second URL itself is determined to be unique regardless of the content of the first URI 110, then the determination of the second URI itself using URI table 51F and the selection of the token code list may be omitted.

[0176] Figure 9 shows an example of the procedure for calling smart contract 22 using the second URI 120. To call smart contract 22, terminal 31 accesses the second server 52 using the second URI 120 (step S91). Upon receiving access from terminal 31, the second server 52 calls smart contract 22 on behalf of the user of terminal 31 (step S93). The called smart contract 22 performs predetermined processing, such as sending a token (step S94). Here, terminal 31 and the second server 52 may correspond to the caller 203 in Figure 2.

[0177] The second server 52 can obtain the data necessary to invoke the smart contract 22 prior to invoking the smart contract 22 (step S93). The data necessary to invoke the smart contract 22 is, for example, the data to be sent to the blockchain 20 for invoking the smart contract 22.

[0178] The second server 52 can obtain the data to be sent to the blockchain 20 for calling the smart contract 22 using the contract table 52D shown in Figure 12.

[0179] As shown in Figure 12, the second server 52 may be composed of a computer comprising a processor 52A and a storage device 52B. The storage device 52B is connected to the processor 52A. The storage device 52B comprises, for example, a primary storage device and a secondary storage device. The primary storage device is, for example, RAM. The secondary storage device is, for example, a hard disk drive (HDD) or a solid-state drive (SSD). The storage device 52B contains a computer program 52C that is executed by the processor 52A. The processor 52A reads and executes the computer program 52C stored in the storage device 52B. The computer program 52C has program code that indicates an instruction that causes the computer to execute a call process 52F.

[0180] The aforementioned contract table 52D is stored in the storage device 52B. The contract table 52D is configured by associating contract information with contract invocation data that is sent to the blockchain 20 for invoking the smart contract 22. The contract invocation data includes, for example, the contract address of the smart contract 22 to be invoked. The contract invocation data may also include the function name of the smart contract 22 to be invoked.

[0181] In the contract table 52D shown in Figure 12, as an example, the contract information for the first campaign, "receive-link / ", is associated with the contract address "0x8888" and the function "F1". The contract address "0x888" is assumed to be the contract address of a smart contract configured to send tokens for the first campaign. The function "F1" is assumed to be a function called in the smart contract 22 stored at the contract address "0x8888" to send tokens for the first campaign.

[0182] Furthermore, in the contract table 52D shown in Figure 12, as an example, the contract information for the second campaign, "receive_NFT-link / ", is associated with the contract address "0x7777" and the function "F2". The contract address "0x7777" is assumed to be the contract address of a smart contract configured to send tokens for the second and third campaigns. The function "F2" is assumed to be a function called in the smart contract stored at the contract address "0x7777" to send non-fungible tokens (NFTs) for the second campaign.

[0183] Furthermore, in the contract table 52D shown in Figure 12, as an example, the contract information for the third campaign, "receive_FT-link / ", is associated with the contract address "0x7777" and the function "F3". Function "F3" is assumed to be a function called in the smart contract stored at the contract address "0x7777" to send fungible tokens (FT) for the second campaign.

[0184] Figure 13 shows an example of the procedure for generating data to be sent to the blockchain 20 for calling the smart contract 22 from the contract information 123B. The second server 52 refers to the contract table 52D and obtains the contract address and function name from the contract information 123B contained in the second URI 120 as data to be sent to the blockchain 20 for calling the smart contract 22.

[0185] In Figure 13, as an example, the contract address "0x8888" and function F1 are obtained from "receive-link / " as contract information 123B. The contract address "0x8888" and function F1 are sent to blockchain 20 as information indicating the call target.

[0186] Note that the call to the smart contract 22 by the second server 52 in Figure 9 may also be made by the terminal 31.

[0187] Figure 14 shows an example of data 125 sent to blockchain 20 for a smart contract invocation. The invocation is treated in blockchain 20 as having originated from the blockchain accounts 25A and 25B of users on terminals 31 and 32.

[0188] Data 125 can, for example, contain the contract address of the smart contract being called. For example, if the contract address of the smart contract 22A being called is 0x8888, then data 125 can contain 0x8888. If the contract address of the smart contract 22B being called is 0x7777, then data 125 can contain 0x7777.

[0189] Data 125 can, for example, contain the function names of the smart contracts 22A and 22B that are called. For example, if the function to be called is function F1 of smart contract 22A, then data 125 can contain F1 as the function name. If the function to be called is function F2 of smart contract 22B, then data 125 can contain F2 as the function name. If the function to be called is function F3 of smart contract 22B, then data 125 can contain F3 as the function name.

[0190] Data 125 may include, for example, a token code provided to smart contract 22. Smart contract 22 can identify the token to be manipulated by the token code.

[0191] Figure 15 illustrates how the smart contract 22A shown in Figure 14 identifies tokens by token code and sends the identified tokens. To identify the tokens to be sent, the smart contract 22 includes a token table 310. The token table 310 is stored in the memory of the computer (node ​​in the blockchain) that executes the smart contract 22 on the blockchain 20.

[0192] The token table 310 in Figure 15 can be the same as the token table 310 shown in Figure 5. More specifically, in the token table 310 of Figure 15, the token code "qC2oFsNKrHimID6u" is associated with the non-fungible token identifier "NFT_id04". Also, the token code "FsNKrHimID67sj0" is associated with "5_tokens" and the non-fungible token identifier "NFT_id05". Here, "5_tokens" indicates that the number of a certain type of fungible token is 5. The token code "Uwnvu7930s3hmvh" is associated with "5_tokens".

[0193] Furthermore, the token table 310 shown in Figure 15 is used to identify the tokens to be sent in the first campaign from the token code for the first campaign. That is, the token table 310 shown in Figure 15 is referenced by the first function F1 for the first campaign (the token sending function for the first campaign).

[0194] Furthermore, the contract address 0x8888 of smart contract 22A stores the tokens to be sent in the first campaign. In other words, smart contract 22A already owns the tokens to be sent in the first campaign.

[0195] The first function F1 of smart contract 22A may receive a token code at the same time it is called. For example, function F1 of smart contract 22A receives a call from user U1's blockchain account 0x9999 (step S151). At the time of this call, function F1 receives the token code "qC2oFsNKrHimID6u". Function F1 refers to the token table 310 and identifies that the token to be sent is a non-fungible token (NFT) with the NFT identifier "NFT_id04". Function F1 sends the NFT with the NFT identifier "NFT_id04" to the caller 0x9999 (step S152). As a result, user U1 can obtain the NFT with the NFT identifier "NFT_id04". The NFT obtained by user U1 may be displayed on user U1's terminal 31.

[0196] Furthermore, function F1 of smart contract 22A can receive a call from user U2's blockchain account 0x1111 (step S151). Upon receiving this call, function F1 receives the token code "FsNKrHimID67sj0". Function F1 refers to the token table 310 and identifies that the token to be sent is a fungible token (FT) with 5 units and a non-fungible token (NFT) with the NFT identifier "NFT_id05". Function F1 sends the NFT with 5 units of FT and the NFT identifier "NFT_id04" to the caller 0x1111. As a result, user U2 can obtain the NFT with 5 units of FT and the NFT identifier "NFT_id05". The NFT obtained by user U2 can be displayed on user U2's terminal 32.

[0197] Figure 16 shows an example of calling smart contract 22A using first data 110 and second data 120. Using the technology in this disclosure, even if the data (first data 110, specified data 113B) obtained from an external source by multiple terminals 31, 32, and 33 is the same, each of the multiple terminals 31, 32, and 33 can obtain different token codes C1, C2, and C3. Specifically, first, each terminal 31, 32, and 33 obtains the common data 113B (steps S161A, S161B, S161C). Then, terminal 31 uses the common data 113B to obtain a unique first token code C1 from the first server 51 (step S162A). Similarly, terminal 32 uses the common data 113B to obtain a unique second token code C2 from the first server 51 (step S162B). Terminal 33 obtains a unique token code C3 from the first server 51 using common data 113B (step S162C). Each terminal 31, 32, and 33 can call the smart contract 22 using the unique token codes C1, C2, and C3 (steps S163A, S163B, and S163C). As a result, users of each terminal 31, 32, and 33 can obtain tokens corresponding to token codes C1, C2, and C3.

[0198] Furthermore, even if multiple devices 40A and 40B capable of providing the first data 110 (specified data 113B) to terminals 31, 32, and 33 are installed, the first data 110 (specified data 113B) transmitted by these devices 40A and 40B to terminals 31, 32, and 33 may all be the same. By making the data common, it becomes easier to prepare many devices 40A and 40B. And, for example, by installing multiple devices 40A and 40B for the first campaign, tokens for the first campaign can be distributed efficiently.

[0199] Figure 17 shows another example of the first data. The first data 130 shown in Figure 17 is similar to the second URI 120 shown in Figure 8. In the example shown in Figure 17, terminal 31 obtains data corresponding to the second URI in Figure 8 as the first data 130 (step S171). Therefore, in the example shown in Figure 17, the issuance of the second data 120 by the first server 51 can be omitted. The second URI as the first data 130 can be used by terminal 31, which has obtained the second URI, to access the second server 52 via the network 15 (see Figure 9). Therefore, even in the example shown in Figure 17, the smart contract 22 can be invoked using the token code. Regarding the second URI as the first data 130, unless otherwise specified, it is the same as the second URI as the second data 120 (see Figure 8).

[0200] In the example shown in Figure 17, the first data 130 contains the token code 123C. Therefore, if you want to distribute multiple different token codes 123C, you can prepare multiple NFC tags 40 (near-field communication devices 40) that each transmit a different token code 123C.

[0201] Note that the terminal 31 shown in Figure 17 may call the smart contract 22 of the blockchain 20 without going through the second server 52.

[0202] Figure 18 shows the pre-configuration of system 10 when distributing tokens using the procedure shown in Figures 8 and 9. Note that the procedure shown in Figures 8 and 9 is for issuing the second data from the first data and corresponds to the procedure shown in Figure 3.

[0203] First, the computer generates multiple token codes for the tokens to be distributed (step S181). Each of the multiple token codes is generated as a unique code. For example, if you want to distribute 100 non-fungible tokens (NFTs), 100 token codes will be generated. Also, if you want to distribute a predetermined number of fungible tokens (FTs) 1000 times, 1000 token codes will be generated.

[0204] The tokens to be distributed are deposited into the contract address of the smart contract 22 that distributes the tokens (step S182). The deposited tokens may be non-fungible tokens (NFTs), fungible tokens (FTs), or a combination of NFTs and NTs. By receiving the tokens, smart contract 22 comes to own them. From the tokens it owns, smart contract 22 sends the token corresponding to the token code.

[0205] The administrator writes the token table 310 (see Figures 5 and 15) to the contract address of smart contract 22 (step S183). The token table 310 shows the correspondence between the token code generated in step S181 and the token deposited in step S182.

[0206] The administrator generates a first URI 110 (see Figure 8) as the first data 110 (step S184). The first URI 110 is a URI for accessing the first server 51. The generated first URI 110 is written to one or more NFC tags 40 using a writing device (not shown) (step S185). This allows the NFC tags 40 to transmit the first URI 110 via short-range wireless communication (see Figures 1, 2, 7, and 8). The NFC tags 40 are installed where they will be used.

[0207] The administrator saves the token code list 51E (see Figure 10) to the first server accessed using the first URI 110 generated in step S184 (step S186). The token code list 51E is a list of the token codes generated in step S181.

[0208] The administrator generates a second URI body containing contract information 123B (see Figures 8, 10, and 11) (step S187). The second URI body is part of the URI for accessing the second server 52.

[0209] The administrator saves the URI table 51F (see Figure 10) on the first server 51 accessed using the first URI 110 (step S188). The URI table 51F shows the correspondence between the specified data 113B included in the first URI 110 generated in step S184 and the second URI body generated in step S187.

[0210] The administrator saves the contract table 52D (see Figure 12) on the second server 52 accessed using the second URI (step S189). The contract table 52D shows the correspondence between the contract information 123B contained in the second URI body generated in step S187 and the smart contract invocation data 22.

[0211] Figure 19 shows the pre-configuration of system 10 when distributing tokens using the procedure shown in Figures 17 and 9. Note that the procedure shown in Figures 17 and 9 does not involve the issuance of second data and corresponds to the procedure shown in Figure 4. In Figure 19, for steps common to Figure 18, the explanations in Figure 18 are used for points that are not specifically explained.

[0212] First, the computer generates multiple token codes for the tokens to be distributed (step S191). This step S191 is the same as step S181 in Figure 18.

[0213] The distributed tokens are deposited into the contract address of the smart contract 22 that distributes the tokens (step S192). This step S192 is the same as step S182 in Figure 18.

[0214] The administrator writes the token table 310 (see Figures 5 and 15) to the contract address of smart contract 22 (step S193). This step S193 is the same as step S183 in Figure 18.

[0215] The administrator generates a second URI (see Figure 17) as the first data 130 (step S194). The second URI 130 is a URI for accessing the second server 52. The generated second URI 130 is written to one or more NFC tags 40 using a writing device (not shown) (step S195). This allows the NFC tags 40 to transmit the second URI 130 via short-range wireless communication (see Figure 17). The NFC tags 40 are installed where they will be used.

[0216] The administrator saves the contract table 52D (see Figure 12) to the second server 52 accessed using the second URI (step S196). This step S196 is the same as step S189 in Figure 18. The contract table 52D shows the correspondence between the contract information 123B contained in the second URI generated in step S194 and the smart contract invocation data 22.

[0217] Figure 20 shows another example of the first data. The first data 140 shown in Figure 20 is a private key 140. The private key 140 corresponds to an account on blockchain 20. The private key 31E shown in Figure 6 is stored in a terminal 31 for using blockchain 20, but in the example shown in Figure 20, the terminal 31 does not store the private key; instead, it is stored in an NFC tag 40 (Near Field Communication Device 40). In the example shown in Figure 20, as an example, the NFC tag 40 is assumed to store the private key 140 for account 25A of user U1 who has the terminal 31.

[0218] In the example shown in Figure 20, terminal 31 obtains the private key 140 as the first data 140 via short-range wireless communication (step S201). It is preferable that the transmitted private key 140 is encrypted. In addition, the other first data 110 and 130 besides the private key 140 may also be encrypted.

[0219] Terminal 31, having acquired the private key 140 via short-range wireless communication, will possess the private key, as shown in Figure 6. Since the private key 140 can generate the blockchain address of user U1's account 25A, terminal 31 can perform operations on blockchain 20. In other words, using terminal 31, which has acquired the private key 140 corresponding to user U1's account, it becomes possible to invoke the smart contract 22 from user U1's account 25A.

[0220] Here, it is assumed that all data except the private key 140 for calling the smart contract 22 on blockchain 20 is pre-configured on terminal 31. When terminal 31 obtains the private key 140, it retrieves the pre-configured call data (step S202) and calls the smart contract 22 (step S203). The called smart contract 22 performs a predetermined operation on blockchain 20, such as sending tokens to account 25A (step S204).

[0221] Figure 21 shows another example of the first data. The first data 150 shown in Figure 21 is user code 150. Here, the near-field communication device is configured as an IC card. Hereafter, this IC card will be referred to as NFC card 40A. As an example, NFC card 40A is used as a means of payment. Here, NFC card 40A may be used to use fungible tokens in blockchain 20 for payments in physical stores. Here, NFC card 40A is used as a prepaid card.

[0222] First, a predetermined number of fungible tokens (e.g., 1000 units) corresponding to the user code are deposited into the smart contract 22 on blockchain 20 (step S211). The number of deposited fungible tokens becomes the balance of fungible tokens in the user code. The user code is written to an NFC card 40A. The NFC card 40A is sold to user U4. User U4 can purchase the NFC card 40A, which is a prepaid card of fungible tokens, by paying with fiat currency, such as cash, credit card, or electronic money.

[0223] User U4, having obtained an NFC card 40A, can use the NFC card 40A for payment at stores that accept fungible tokens. First, the store's terminal 35 obtains the number of tokens to be used (step S212). The number of tokens to be used is the number of fungible tokens equivalent to the price (in legal tender) of the goods purchased by user U4. The number of tokens to be used is determined based on a predetermined exchange rate. The number of tokens to be used may be calculated by the terminal 35 or by another device.

[0224] User U4, who has agreed to pay for the number of tokens to be used, holds the NFC card 40A over the store's terminal 35. This causes the user code to be transmitted from the NFC card 40A to the terminal 35 via short-range wireless communication (step S213). The terminal 35, if necessary, uses the user code to obtain invocation data for the smart contract 22 (step S214). This invocation data is, for example, data identifying the smart contract 22 that will perform the payment processing (token transmission processing) for the user code received by the terminal 35. The invocation data can be obtained, for example, from an external server using the user code.

[0225] Terminal 35 can, for example, invoke smart contract 22 along with sending the number of tokens to be used and the user code (step S215). The invoked smart contract 22 sends fungible tokens corresponding to the number of tokens used from the fungible token balance indicated by the token code to the store account (step S216). The fungible token balance decreases by the amount of tokens used.

[0226] Based on the above, user U4 can use fungible tokens on blockchain 20 for payment without directly manipulating blockchain 20 at the time of payment.

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

[0228] <3. Addendum>

[0229] This disclosure includes the following:

[0230] [Item 1] A method or system comprising: a smart contract implemented on a blockchain receiving a token code; and the smart contract manipulating tokens held by the smart contract in accordance with the token code.

[0231] [Item 2] A method or system comprising a smart contract that receives a token code from an account on a blockchain, and then sends a token corresponding to the token code to the account.

[0232] [Item 3] A method or system comprising a smart contract that receives a token code and transmits a number of fungible tokens associated with the token code.

[0233] [Clause 4] A method or system comprising a smart contract that, upon receiving a token code, determines the number of fungible tokens to be sent and sends the determined number of fungible tokens.

[0234] [Clause 5] A method or system comprising a smart contract receiving a token code and transmitting a non-fungible token associated with the token code.

[0235] [Clause 6] A method or system comprising a smart contract that, upon receiving a token code, generates a nonfungible token to be sent, and sends the generated nonfungible token. [Explanation of Symbols]

[0236] 10: System 15: Network 20: Blockchain 21: Contract Address 22: Smart Contracts 22A: Smart Contracts 22B: Smart Contracts 25A: User Account 25B: User Account 31: Terminal 31A: Processor 31B: Storage device 31C: Computer program 31D: Short-range wireless communication module 31E: Private Key 31F: Call processing 32: Terminal 32D: Short-range wireless communication module 33: Terminal 35: Terminal 40: Near-field communication device (NFC tag) 40A: NFC card 40B: Equipment 41: Antenna 42: Radio circuit 43: Controller 44: Memory 46: Communication data 51: Server 1 51A: Processor 51B: Storage device 51C: Computer Program 51D: Issuance conditions 51E: Token Code List 51F: URI Table 51G: URI Issuance Process 52: Second Server 52A: Processor 52B: Storage device 52C: Computer Programs 52D: Contract Table 52F: Call processing 110: First data (first URI) 111: Scheme 113: First Authority 113A: First host 113B: Specified data 120: Second data (second URI) 121: Scheme 123: Second Authority 123A: Second host 123B: Contract Information 123C: Token code 125: Data 130: First data (second URI) 140: First data (private key) 150: First data (user code) 201: First data acquisition device 202: Second Data Generator 203: Calling device 310: Token Table 410: Non-fungible tokens 420: Token 430: Token 450: Fungible Token 500: Poster 501 :Surface 501A: 2D code 502: Back side 510: Landmark C1: First token code C2: Second token code C3: Token code F1: First function F2: Function F3: Function

Claims

1. A method of using short-range wireless communication, A first device performing short-range wireless communication transmits communication data, including common data (first data), to each of the terminals of multiple users via the short-range wireless communication. The server receives access from each of the multiple user terminals using the common data, the first data, and issues second data corresponding to the type of first data used for the access, which differs for each access from each of the multiple user terminals. The server sends each of the second data, which differs for each access, to the blockchain to invoke a smart contract, and the smart contract causes each of the multiple user terminals that have obtained the common data, the first data, to obtain a non-fungible token. Equipped with, Each of the aforementioned users has a blockchain address, The acquisition of the aforementioned non-fungible token is to have the aforementioned non-fungible token sent to the blockchain address of each of the aforementioned users, When the smart contract is invoked using the second data for each of the multiple users corresponding to the second data, it sends the non-fungible token to the blockchain address of the user to whom the invocation pertains. How to use short-range wireless communication.

2. The smart contract generates the non-fungible token when invoked. A method for using short-range wireless communication as described in claim 1.

3. The first data does not include data sent to the blockchain to invoke the smart contract. A method for using short-range wireless communication according to claim 1 or claim 2.

4. The issuance of the second data is performed when the pre-set issuance conditions are met. A method for using short-range wireless communication according to claim 1 or claim 2.

5. A system using short-range wireless communication, Smart contracts implemented on the blockchain, A short-range wireless communication device that transmits communication data, including common data (first data), to each of the terminals of multiple users via the short-range wireless communication, A server that invokes the aforementioned smart contract, Equipped with, The aforementioned server, The system receives access requests from each of the multiple users' terminals using the common data, the first data, and issues second data corresponding to the type of the common data, the first data, used for the access, with each access from each of the multiple users' terminals being different. Each of the second data, which differs with each access, is sent to the blockchain to invoke the smart contract, and the smart contract causes each of the multiple user terminals that have obtained the common data, the first data, to obtain a non-fungible token. Each of the aforementioned users has a blockchain address, The acquisition of the aforementioned non-fungible token is to have the aforementioned non-fungible token sent to the blockchain address of each of the aforementioned users, When the smart contract is invoked using the second data for each of the multiple users corresponding to the second data, it sends the non-fungible token to the blockchain address of the user to whom the invocation pertains. A system that uses short-range wireless communication.

6. The smart contract generates the non-fungible token when invoked. A system using short-range wireless communication as described in claim 5.

7. The first data does not include data sent to the blockchain to invoke the smart contract. A system using short-range wireless communication as described in claim 5 or claim 6.

8. The issuance of the second data is performed when the pre-set issuance conditions are met. A system using short-range wireless communication as described in claim 5 or claim 6.

9. The system accepts access requests from each of the multiple users' terminals using a common data, namely the first data, which is transmitted from a first device performing short-range wireless communication to each of the multiple users' terminals via the said short-range wireless communication. It then issues a second data, corresponding to the type of the first data used for the access, which differs for each of the multiple users' terminals that made the access. Each of the second data, which differs with each access, is sent to the blockchain to invoke a smart contract, and the smart contract causes each of the multiple user terminals that have obtained the common data, the first data, to obtain a non-fungible token. It is configured to perform the following: Each of the aforementioned users has a blockchain address, The acquisition of the aforementioned non-fungible token is to have the aforementioned non-fungible token sent to the blockchain address of each of the aforementioned users, Sending the non-fungible token means calling the smart contract using the second data for each of the multiple users corresponding to the second data, and sending the non-fungible token to the blockchain address of the user involved in the call. server.

10. The system accepts access requests from each of the multiple users' terminals using a common data, namely the first data, which is transmitted from a first device performing short-range wireless communication to each of the multiple users' terminals via the said short-range wireless communication. It then issues a second data, corresponding to the type of the first data used for the access, which differs for each of the multiple users' terminals that made the access. Each of the second data, which differs with each access, is sent to the blockchain to invoke a smart contract, and the smart contract causes each of the multiple user terminals that have obtained the common data, the first data, to obtain a non-fungible token. A computer program that causes a computer to perform an action that includes the following: Each of the aforementioned users has a blockchain address, The acquisition of the aforementioned non-fungible token is to have the aforementioned non-fungible token sent to the blockchain address of each of the aforementioned users, When the smart contract is invoked using the second data for each of the multiple users corresponding to the second data, it sends the non-fungible token to the blockchain address of the user to whom the invocation pertains. Computer program.

Images