Program, information processing method, and information processing device

Abstract

To effectively assist a user in managing a token.SOLUTION: An application program causes a computer to execute a management function of enabling integral management of a plurality of wallet addresses. When receiving wallet address information with a signature from a user, the application program causes the computer to further execute a registration function of registering a corresponding wallet address. The registration function executed by the application program performs registration through possession confirmation processing based on the signature.SELECTED DRAWING: Figure 14

Description

[Technical field]

[0001] The present disclosure relates to a program, an information processing method, and an information processing device. [Background technology]

[0002] Regarding the method of issuing and controlling tokens managed on the blockchain, Bitcoin has appeared, which can express and transfer value without electronic and centralized mechanisms, and blockchain technology that realizes this has become widely used. As the concept of Bitcoin and blockchain technology are understood, various coins that express value electronically other than Bitcoin have appeared. Coins that have these values ​​are referred to as tokens below. Due to the characteristics of blockchain technology, issued tokens have the characteristic that they are very difficult to tamper with. Taking advantage of this characteristic, the use of recording the holders of various electronic data such as images, videos, and audio on the blockchain to guarantee and prove that they are the holders is becoming widespread. Tokens used for such purposes are called Non-Fungible Tokens (NFTs). The concept of NFTs itself has been around for a long time, but it has gradually begun to be recognized since around 2017, and some have been traded at high prices in 2021, attracting attention. Specific uses of NFTs include management of intangible assets (Patent Document 1) and contract and license management (Patent Document 2). By shifting from a system that was previously centrally managed by rights holders to a distributed system using blockchain, fault tolerance can be increased and recorded information can be used without problem even if the central administrator is unable to carry out their duties. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6640320 [Patent Document 2] JP 2020-68388 A Summary of the Invention [Problem to be solved by the invention]

[0004] At the moment, NFT technology itself is new, and even if users are able to acquire them out of curiosity, they face the challenge of having difficulty managing them.

[0005] Therefore, an object of the present disclosure is to effectively assist users in managing tokens. [Means for solving the problem]

[0006] According to the present disclosure, a program is provided that causes a computer to execute a management function that enables centralized management of multiple wallet addresses.

[0007] In addition, the present disclosure provides an information processing method having a management process that enables centralized management of multiple wallet addresses.

[0008] According to the present disclosure, an information processing device is provided that has a management function that enables centralized management of multiple wallet addresses. Effect of the Invention

[0009] According to the present disclosure, it is possible to effectively assist users in managing tokens. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram showing a basic configuration of an embodiment of the present invention. [Diagram 2] A diagram showing the configuration of each node, user terminal, and token control processing reception unit that make up the blockchain network. [Diagram 3] FIG. 13 illustrates a token generation process. [Figure 4] FIG. 13 is a diagram showing token control information to be set in a distribution means. [Diagram 5] FIG. 4 illustrates a received data storage unit. [Figure 6] FIG. 13 illustrates token management information for a smart contract. [Figure 7] FIG. 13 is a diagram illustrating token distribution number management. [Figure 8] 13 is a flowchart illustrating a token receiving process according to the third embodiment. [Figure 9] FIG. 13 is a diagram (part 1) showing a screen image for explaining a token receiving process according to the third embodiment. [Figure 10] FIG. 13 is a diagram (part 2) showing a screen image for explaining a token receiving process according to the third embodiment. [Figure 11] FIG. 13 is a diagram (part 3) showing a screen image for explaining a token receiving process according to the third embodiment. [Figure 12] FIG. 13 is a diagram showing a screen image when instructing to change the storage location of a held token. [Figure 13] FIG. 13 is a diagram showing a screen image for explaining options for token storage methods. [Figure 14] This is an explanatory diagram of the mechanism of a system that allows centralized management of NFTs, and is an explanatory diagram of the overall overview. [Figure 15] This is an explanatory diagram of the mechanism of a system that allows centralized management of NFTs, and is an explanatory diagram of the main parts. [Figure 16] A figure showing an example of a management screen that displays centrally managed NFTs. [Figure 17] FIG. 13 is a diagram showing an example of a screen displayed when one wallet is selected from a plurality of wallets. [Figure 18] 1 is a flow chart illustrating an example of a data acquisition process. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Each embodiment will be described in detail below with reference to the accompanying drawings.

[0012] [Embodiment 1] FIG. 1 is a diagram showing the overall configuration of a system for implementing an embodiment.

[0013] The blockchain network 100 is a network in which many computers are connected to each other, and each connected computer is called a node. Each node records processing requests notified to the blockchain network 100 from the outside, executes processing according to the processing requests from users, and records the results in the storage managed by the node. Processing requests are transmitted to each node, and each node executes the same processing for the processing request and records the output, thereby realizing each node to hold exactly the same information even in a distributed environment. The processing executed on this blockchain is called a smart contract.

[0014] A smart contract is a computer program executed by each node, and similar to a processing request, after the blockchain network 100 receives a program registration request, it distributes it to each node and registers it. The token processing unit 200 is a smart contract and controls tokens in response to requests from users. In this embodiment, the issuance of tokens will be described as an example.

[0015] The token control processing reception unit 300 is a server that performs interactions with the blockchain network 100, receives a request from the user terminal 400, makes a request to the token processing unit 200, and returns the response to the user terminal 400. The user terminal 400 is an information processing device used by the user, such as a smartphone or a PC. The distribution means A to C (500A to 500C) provide information about tokens (for example, a part or all of token control information described later) to the user. Specifically, they provide various data in cooperation with the user terminal 400, such as URL (Uniform Resource Locator), QR code (registered trademark, omitted hereinafter), NFC (Near Field Communication), Bluetooth (registered trademark), voice, image, beacon information, location information, and behavior of an external server (for example, API (Application Programming Interface) information of SNS (Social Networking Service)). When a user directly interacts with the blockchain network 100, software or hardware called a wallet that manages a private key used in the blockchain is used in the user terminal. If these are already installed in the user terminal 400, the user terminal 400 may directly issue a processing request to the token processing unit 200 without going through the token control processing reception unit 300. In this embodiment, it is assumed that many users do not have wallets, and an example using the token control processing reception unit 300 will be described.

[0016] FIG. 2 is a configuration diagram of each node that constructs the blockchain network 100. The node terminal 110 may be a normal computer, and may be configured with a CPU 120, a memory 130, a storage 140, a storage I / F 150 that is an interface for connecting the storage, an input / output I / F 160 for connecting to an external keyboard, mouse, or display, and a network I / F 170 for connecting to an external computer and constructing a network. Although not shown, some have a GPU or FPGA as other arithmetic processing units, and some offload processing required for blockchain operation such as mining to these functional units. Blockchain network information is stored in the storage 140 of the node terminal 110, and smart contract processing is read from the storage 140 to the memory 130 and executed by the CPU 120 (or GPU or FPGA in some cases). The token control processing acceptance unit 300 and the user terminal 400 are also normal computers, and have the same configuration as the node terminal 110.

[0017] When distributing tokens such as NFTs to users, it is necessary to prepare a mechanism to create tokens in advance or to create tokens in response to requests. Figure 3 shows the preparation process and the process up to when the user actually receives the token. Below, we will explain this process procedure with reference to Figure 3, assuming that an NFT is being newly distributed.

[0018] First, in order to distribute NFTs, it is necessary to develop a smart contract for managing and operating NFTs (step S1000). Once it is confirmed that the developed one has no bugs, the created smart contract is registered in the blockchain network 100 (step S1010. The blockchain network 100 and the smart contract are not shown in this flow). In parallel with this, content to be referenced as NFTs is created, and information to be registered in the smart contract is prepared (step S1020). Once the smart contract and content are prepared, the information is set in the smart contract, and the development work is completed (step S1030). In this embodiment, the smart contract is registered in the blockchain network 100 and then the content information is registered. However, instead of setting the content information after registering the smart contract, there may be cases where the procedure involves preparing all the information, finalizing the content information as a smart contract, and then registering it.

[0019] In this embodiment, it is possible to prepare the distribution means in parallel with the development and creation of smart contracts and content. This is realized by the setting information generation process (step S1100). Here, a random number with a sufficient range is used as the setting information. For example, a number in the range of 2 to the power of 256 is assigned by random numbers. The wider the space that can be set, the lower the possibility that the generated random numbers will match. Depending on the distribution means, work such as printing or writing data to a dedicated device may be required. If you try to make the information provided by the distribution means such as a QR code correspond one-to-one with the ID information managed by the NFT, you need to wait for the development on the NFT side to be completed, but once certain preparations and rules such as the URL of the site to be accessed are determined, you can freely generate the distribution means using random numbers. In this way, work can be carried out independently of development, and the work on the distribution means side can also be performed mechanically. Alternatively, a rule may be defined in which a numerical range to be used is assigned to each distribution means instead of a random number, and a serial number is assigned.

[0020] For example, numbers are assigned so that all are unique, such as 1 to 10000 for QR codes and 10001 to 20000 for NFC. The information generated in this way is set in the distribution means (step S1110) and distributed to users (step S1120). By being able to separate development and distribution, pre-sales can be realized and collaboration with other products can be made easier. The information provided from the distribution means to the user terminal is the token control information 600 in FIG. 4. Here, it is assumed that a random number or a predefined serial number used in issuing or distributing NFTs is set as the control information, and an access URL for acquiring NFTs is stored as additional information. The additional information may include things other than the access URL. For example, the type of distribution means, a management number, a sales start date and time, and the URL of the provider company.

[0021] In this way, for example, the user receives a printed QR code as a distribution means, and reads it with a smartphone or the like to obtain information about the access destination and a random number set for NFT exchange (step S1200). The user then notifies the obtained access destination of the read random number and requests to obtain the NFT (step S1210). When the user notifies the access destination of information, information for the user to receive the NFT (in the case of a public blockchain, this corresponds to the user's address. Hereinafter, this information will be described as the address) is also sent.

[0022] In this embodiment, the token control processing reception unit 300 is set as the access destination, and this receives requests from users (step S1300). FIG. 5 shows the received data storage unit 700 that stores information received by the token control processing reception unit. Note that the sender field stores the address of the user in the blockchain network 100, but if necessary, the user's IP address or the like may be stored to store information that reliably identifies an individual or an individual's user terminal 400. Also, if all or part of the additional information of the token control information is unnecessary, it may be deleted and then stored in the token control information field of the received data storage unit 700.

[0023] When storing the received data, the token control processing reception unit 300 checks whether there is anything with the same token control information, and if it has already been registered, informs the user that the content of the distribution means has already been used and ends the process. Alternatively, if the same user is allowed to have multiple tokens, such as "up to three per person," it checks whether the number has been exceeded, and ends the process if it has been exceeded. The upper limit number per user may be checked by a smart contract, not by the token control processing reception unit 300. If there is no problem after the check, the received information is stored as is, and the received information is used to request the smart contract to issue or set an NFT (step S1310) (the smart contract is not shown in this flow). The smart contract that receives the request for issuance or setting changes the holder of the target NFT to the user after confirming that there are no defects in the notification. Or, it issues a new NFT and sets the holder to the user. The smart contract that manages and operates the NFT holds the NFT ID and holder information. This is the token management information 800. FIG. 6 is a diagram showing an example of token management information 800 of a smart contract. The simplest method is to set the notified random number or serial number as an ID as it is, associate the notified user address with the ID, and store it in the token management information 800. Although there is an upper limit to the ID that can be taken due to the implementation constraints of the smart contract, this constraint can be avoided by defining the information to be set in the transmission information taking this into consideration when assigning the random number or serial number. In addition, in many cases, an upper limit is set for NFTs, such as 100 or 10,000. As an example of how to deal with this case, there is a method of calculating the remainder of the received random number. For example, if there are 100 NFTs to be distributed, the received random number is divided by 100 and the remainder is used as the ID. By using the remainder, it is possible to keep any value notified within a certain range. However, in this case, if the remainder of the notified random number is calculated later, it is possible that the value will be the same as the ID that has already been used. In this case, it is possible to deal with it by using a closed hash method in which the next value of the calculated value is used as the ID.If you have already anticipated a maximum number of serial numbers when allocating them, you can simply use that value as the ID.

[0024] Furthermore, there are efforts being made to restrict the number of NFTs issued and reduce the number in circulation to create scarcity. In this embodiment, this can be achieved by limiting the number provided by the distribution means.

[0025] Another way to achieve this is to express rarity by the range of IDs. For example, if you have 100 NFTs, but NFTs from 1 to 10 are more valuable (such as being associated with special content). This can also be achieved with a remainder, but when using closed hashing, it is possible that "the remainder is 10 but shifts to 11, meaning you cannot receive a highly valuable NFT." In such cases, rather than simply using closed hashing, you can deal with the problem by using closed hashing within the range of 1 to 10 for the remainder.

[0026] However, since the present embodiment assumes the use of multiple distribution means, there is a possibility that a large amount of valuable NFTs will be distributed by a certain distribution means. Depending on the distribution means, the number of users who can receive may be limited, so it is necessary to ensure the fairness of distribution. For example, a token distribution number management 900 as shown in FIG. 7 may be used to manage this. This is information that manages how many IDs are assigned to which distribution means that are assumed to be used, and is used to manage the maximum number of assignments and the number actually assigned after the start of distribution. When assigning users in a smart contract, this information is also referenced to assign IDs. When the surplus of transmitted information notified after the maximum number is assigned by a certain distribution means falls within that range, the developer will implement which ID to assign in the smart contract based on the concept and operation rules of the NFT. Here, only the ID range is simply defined, but time constraints such as within one month or within three months after the start of sales, statistics on the total number of receptions, etc. may be used, or rules combining these may be created.

[0027] In this embodiment, the case where "an NFT is acquired using information obtained from one of the distribution means" has been described. In reality, multiple distribution means may be used at the same location, such as a method in which NFT distribution information is provided by a QR code and a method in which it is provided by broadcast audio (sound output from a speaker, etc.). In this case, it is possible to consider applications such as distributing an NFT only when each token distribution information provided by multiple distribution means is acquired, or distributing a special NFT when token distribution information is acquired from each of the multiple distribution means. In addition, by combining multiple distribution means in this way, it is possible to realize NFT distribution according to location and time without adding additional information to the transmission information or additional information. In addition, it can also serve as a certain degree of security measure, such as "not distributing just by having a QR code". In addition, NFTs may be distributed so that the NFTs that can be acquired differ depending on which token distribution information is acquired from among the token distribution information provided by multiple distribution means.

[0028] In addition, this example has been described assuming the "issuance of NFTs" process, but this mechanism can be used to realize not only issuance but also the execution of processes for tokens on the blockchain network 100, including NFTs. For example, NFTs used in games can be used to build services that link the real world with NFT information, such as "if you go to a certain place on a certain date and time, your parameters will improve."

[0029] In this embodiment, an example is described in which a user requests processing from the token processing unit 200 via the token control processing reception unit 300, but when it becomes commonplace for a wallet to be installed in a user terminal 400, it is considered that in many cases, the user will directly notify the token processing unit 200 of the token control information 600 and request processing. In this case, the received data storage unit 700 managed by the token control processing reception unit 300 can be managed by the token processing unit 200, which is a smart contract, to realize this embodiment.

[0030] [Embodiment 2] According to the method of the first embodiment described above, distribution information can be created independently of content creation, and tokens such as NFTs can be distributed to users in advance by various distribution means. However, if distribution means are simply used to distribute tokens with limited number or high value, there is a risk of misuse. For example, when using a QR code, anyone can receive the QR code information itself and can easily check its contents. In other words, the user can easily know information such as the URL to be accessed and the random number or serial number used for ID assignment. In addition, since QR code creation tools are also published on the Web, when a QR code is received, the user can process the original information on the user's side and then request processing from the token control processing reception unit 300. For this reason, there are two major problems: "a token with an ID that the user wants can be obtained" and "an unlimited number of tokens can be obtained without obtaining information from the distribution means."

[0031] Regarding "tokens with any ID can be obtained," this can be addressed by processing the random numbers on the receiving side. When the token control processing reception unit 300 receives a request from a user (step S1300), a random number is generated and synthesized (XORed, etc.) to create new information, which is used as information for ID allocation. Instead of generating random numbers, a hash value may be obtained from salt (any variable information) and the notified information and used as the allocation information. This problem can be addressed by not using the information notified by the user as is. Note that, although an example of random number creation & synthesis or hash value creation in the token control processing reception unit 300 has been described here, a similar process may be performed in a smart contract. Normally, random numbers cannot be generated in a smart contract, but there is a mechanism called an oracle that provides reliable information from outside. Random numbers can be used in a smart contract by using this to obtain random numbers. Since the token control processing reception unit 300 is often under the management of the token provider, it is possible to implement it in a smart contract in order to present fairness by publishing information on the blockchain network 100, which is visible to users.

[0032] The latter, "users can obtain any number of tokens", is a bigger problem. Even if one user is allowed to issue or set multiple tokens, if only the address information of the blockchain network 100 is held as the sender information, the user can freely create multiple addresses, so the number limit cannot function as a constraint. One way to deal with this problem is to collect user information such as name, address, and email address when receiving token control information from the distribution means, and have the user enter the user information when using the token control information. However, it is not possible to obtain detailed information about users using distribution means such as QR codes and NFC alone, and a separate system is required, which makes operation difficult. In addition, users are forced to take time and effort, and some people may feel that they are providing personal information unnecessarily, which creates the problem of not receiving tokens.

[0033] In this embodiment, in order to deal with this problem, the token control information transmitted by the distribution means is encrypted and provided. The procedure itself is the same as in Fig. 3, but some processing is added. The details are explained below.

[0034] First, an encryption key is prepared to encrypt the control information to be stored in the token control information 600. Here, the case of using public key encryption will be described, but the same applies when using common key encryption such as AES. First, the token provider creates a public key pair before creating a token. The private key is managed by the token provider and set in the token control processing reception unit 300 in a form that can be used safely, and the public key is provided to the person who sets the information for the distribution means. The distribution means encrypts the control information using the public key received for random number or serial number generation (step S1100). Note that additional information of the token control information 600 stores information such as the URL of the access destination. If there is other information that needs to be kept secret for processing, that part may also be encrypted and stored. In addition, the public key used for information generation should be used only by the person who sets the token control information 600 in the distribution means, and should not be disclosed to other workers or to the outside. The subsequent processing is as shown in FIG. 3, however, in step S1300, the token control processing reception unit 300 receives the token control information 600 from the user and decrypts the transmitted information using the set private key to obtain the set random number, etc., and then performs the subsequent processing.

[0035] In this way, a mechanism is constructed in which the control information in the token control information 600 is encrypted and the key information required for encryption is not disclosed to the user.

[0036] The above describes a method for managing private keys in the token control processing reception unit 300. However, considering the possibility of insider theft, holding onto a private key may be a risk. Therefore, a method for making management easier by having the key held in a smart contract will be described.

[0037] Since a key is also data, it is easy to give a smart contract a key. However, since smart contracts are information that is made public to all those who access the blockchain network 100, it is not possible to give them the key as it is. Therefore, public key cryptography is used. Due to the technical characteristics of public key cryptography, it is easy to derive a public key from a private key, but deriving a private key from a public key is characterized by the fact that it takes an enormous amount of calculation time, making it practically impossible. Taking advantage of this characteristic, a "public key" is registered in the smart contract. The encryption process of the token control information 600 is the same as before. The token provider generates a public key pair and provides the "private key" to the person who performs the information setting work for the distribution means, and the generated token control information 600 is encrypted with this key. As before, the work must be done so that the private key is not leaked. Once all the token control information 600 has been created, the private key is no longer necessary, so it may be discarded. If there is a possibility that the same private key will be used in the future for adding content, etc., the token provider must strictly manage it. Furthermore, in this case, since the token control processing reception unit 300 cannot decrypt the data, the encrypted data and sender information are stored and managed in the received data storage unit 700. After the token control processing reception unit 300 requests the smart contract to issue or set the data (step S1310), the smart contract that receives this decrypts and uses the notified information with its own public key. In this way, by holding the public key pair in the opposite way to the normal way, it is possible to ensure that the key information registered in the smart contract can decrypt but not encrypt. In this way, the token control information 600 can be used safely even if key information is registered in the smart contract.

[0038] [Embodiment 3] When a user receives a token such as an NFT, information that uniquely identifies the user is required on the blockchain network 100. In a public blockchain such as Ethereum, this corresponds to an address generated from the public key of a public key pair managed by the user. However, in order to have an address, an app or hardware such as a wallet for managing the underlying public key pair is required, making it difficult for general users to use. Therefore, in this example, a method for solving this problem will be described.

[0039] Fig. 8 is an explanatory diagram of the token receiving process according to the embodiment 3. The token receiving process shown in Fig. 8 may be executed as the process of step S1200 in Fig. 3 before step S1210.

[0040] In step S1200 of FIG. 3, as described above, the user obtains information from the distribution means. To explain specifically the case of a QR code, the distribution means provides the QR code to the user. This provision method may be any form, such as a person handing over a piece of paper, posting a QR code at the entrance of a company, or distributing via the Internet. The user reads the QR code using a camera app or a scanner app on the smartphone (step S2100). Note that the app to be launched may change depending on the method provided by the distribution means. When the app reads this, it presents a URL and checks whether to access it, and after instructing "access", the smartphone launches a browser (step S2110) and accesses the URL destination specified in the token control information 600 (step S2200). Note that the instruction to "access" may be generated automatically. In other words, when the app reads the QR code, access to the URL destination specified in the token control information 600 may be automatically realized.

[0041] At this time, the token control processing reception unit 300 related to the distribution site to be accessed executes user side processing transmission (step S2300), and a program such as JavaScript (registered trademark) in a page prepared by the token control processing reception unit 300 generates a public key pair that is the basis for creating an address for the user (step S2210), and executes processing to store the public key pair and / or address information in the local storage of the browser (step S2220). In this way, the user can obtain address information that is unique in the blockchain network 100 without being aware of it. In addition, the user can directly obtain the public key pair and / or address information in a storage area (local storage of the browser) in his / her user terminal 400 without going through another wallet or another site (for example, a site for wallet creation), and as a result, can directly obtain a token. In addition, since the local storage can be used only by the user of the smartphone, it can be said to be relatively safe. In a variant example, the public key pair may be stored in the browser's session storage or other browser storage such as browser cookies instead of the browser's local storage, or may be stored in a memory area other than the browser's storage (for example, a memory area within the user terminal 400 or a memory area of ​​a server device accessible by the token control processing reception unit 300, etc.).

[0042] However, the local storage can be deleted by a user operation. If the public key pair (particularly the private key) is deleted, the tokens granted to the user cannot be transferred forever. In order to avoid this, the public key pair or the information used to generate them is converted into a QR code after it is created and displayed to the user (step S2230). That is, the user is notified of a restoration means (restoration information) that can restore the public key pair (particularly the private key) even if it is deleted from the local storage of the browser. This allows the user to capture the displayed screen and save it in a location other than the local storage of the browser (for example, a storage device in a smartphone or other cloud storage) (step S2120). With this information, the user can generate the public key pair generated at the time of access at any time, and the granted token will not be wasted. FIG. 9 shows an example of a UI (user interface screen) 990 that prompts the user to save the restoration means. In this case, the UI 990 includes a QR code C12 and a message that prompts the user to save the restoration means. In addition, instead of a QR code, any information that can restore the generated public key pair, such as multiple words, may be used. The public key pair stored in the browser's local storage can be said to be temporary information for receiving. For this reason, after the user obtains an address that is used permanently, the target token, the permanent use address, and restoration information, or the target token, the permanent use address, and information on the private key stored in the local storage are provided to the token control processing reception unit 300, thereby providing a function for sending the target token from the address stored in the user's local storage to the permanent use address. A UI image of this function is UI1000 shown in FIG. 12. Since "From" is an address stored in the local storage, it is set automatically, but it may also be set (input) manually. "To" is a field for inputting wallet information (hereinafter referred to as wallet information, etc.) that can identify the corresponding wallet, such as a permanent use address or the like (for example, an address for proxy processing when proxy processing is used), and is input by the user himself. "To" may be set by reading it from a QR code, etc.It is assumed here that the restoration information is stored as a separate file.

[0043] Next, in response to an instruction from the user, a process is executed to request acquisition of an NFT (step S1210 in FIG. 3) via a process of notifying generation information in the browser (step S2240). Note that token control information 600 is notified from the distribution means, and processing such as obtaining and encrypting the necessary information from there may be executed in the process related to notifying generation information (S2240). Note that a part or all of the token control information 600 may be incorporated in the corresponding URL, or may be included in a web page that is expanded based on the corresponding URL.

[0044] For example, in the example shown in FIG. 9, when the user operates the button BT990 labeled "Saved, proceed" on the smartphone, the process from step S1210 onward in FIG. 3 is executed via step S2240. In this case, the UI991 shown in FIG. 10 may be output on the user's smartphone via the UI990 shown in FIG. 9 (without operating the button BT990). In the example shown in FIG. 10, the UI991 is displayed, including an image G10 representing the token (NFT) to be acquired, a description G11 thereof, and a processing in progress display G12 visually indicating that acquisition is in progress. By looking at the UI991, the user can obtain information about the NFT being acquired. The description G11 may include advertising information related to the distributor. Also, the example shown in FIG. 11 is a screen when acquisition is completed, and a UI992 including a message "NFT saved!" is displayed. Note that "save" here means saving (storing) in the local storage of the browser, as described above. In the example shown in Fig. 11, a UI 992 is displayed that includes an image G10 representing a saved token (NFT) and its explanation G13. The explanation G13 may include a link to a more detailed explanation screen, a link to a site related to advertising information, etc.

[0045] In the example shown in Fig. 8, a process (step S2230) is executed to prompt the user to save the restoration means, but this process may be omitted or executed after the fact in a manner that notifies the user later. Also, in Fig. 8, the address creation process for the public blockchain is not shown explicitly, but since the address is generated from the public key, it may be created in the process related to the public key pair creation (S2210).

[0046] In addition, in this embodiment, the display information based on the URL destination specified in the token control information 600 (in this case, a WEB screen) may display a UI1200 that allows the user to select a storage destination of the token (NFT) to be acquired. For example, in the example shown in FIG. 13, a UI1200 including a button B21 that can be selected by a user who owns a wallet and a button B22 that is suitable for selection by a user who does not own a wallet is displayed. When a user operates the button B21, the target token is associated with wallet information, etc., making it possible to eliminate the need for the process described above with reference to FIG. 12. On the other hand, when a user operates the button B22, the various processes described above with reference to FIG. 8 are executed, making it possible to grant the target token to a user who does not own a wallet. In this way, by providing a UI that allows the user to select a storage destination of the token (NFT) to be acquired, a highly convenient service can be provided to a wide range of users.

[0047] In addition, when requesting processing from the blockchain network 100, a fee called a gas fee is incurred in many blockchains. This gas fee must be paid using the basic token in each blockchain, but it is difficult for general users to secure tokens to substitute for gas. Therefore, a method is provided in which a process for the blockchain network 100 is created using the user's public key pair, but the token control processing reception unit 300 bears the gas fee required for the request. The user terminal 400 uses the private key of the public key pair stored in the local storage to sign the token control information 600 received from the distribution means, and notifies the token control processing reception unit 300 that it will definitely use it, thereby requesting the burden of the gas fee. The token control processing reception unit 300 can reliably confirm the sender from the sender information and the signature, and allows the burden of the gas fee based on the confirmation. In addition, a smart contract that can execute this proxy request is prepared in the blockchain network 100, and the token control processing reception unit 300 requests the processing from the smart contract, thereby realizing proxy processing. In this way, by having the token control processing reception unit 300 act as a proxy for the processing on the blockchain network 100, the user can request processing from the blockchain network 100 without being aware of the gas fee. Although the method of sending a held token to a permanent address has been described above, this can also be achieved by proxy means without providing private key information or the like. There are two main ways. In one, the user creates a processing request to send the target token from the address of the public key pair stored in the local storage to a permanent use address prepared by the user, signs it with the private key of the local storage, and requests the token control processing reception unit 300 to execute it. In the other, a processing request that grants the token control processing reception unit 300 the authority to operate the target token is created, signed with the private key stored in the local storage, etc., and requested the token control processing reception unit 300 to execute it. In either case, the token control processing reception unit 300 that receives the request sets the gas fee and then requests the smart contract that realizes the proxy processing to perform the processing, thereby completing the processing.In addition, when changing the token storage location by these means, the UI 1000 in FIG. 12 does not need to include an item for restoration information, and two methods can be presented and selected, or the system can be implemented to use one of the two methods and the UI can be made optional. When actually performing proxy processing, the received data storage unit 700 in FIG. 5 is referenced to confirm whether the requester is correct, and then proxy processing is requested from the blockchain network 100. In addition, the information in the received data storage unit 700 can be referenced to determine whether or not proxy execution can be performed. For example, since QR codes are distributed in large numbers, gas fees are not subsidized, but those who obtain NFTs via voice are permitted, and those who obtain NFTs via NFC are given a small amount that can be used as gas fees in the future if they are performed within three days, and only gas fees are paid within one month, and no more than that is permitted. By performing such control, it is possible to weight specific distribution means and increase the variety of NFT distribution methods.

[0048] Next, another embodiment will be described with reference to FIG. 14 onwards.

[0049] Fig. 14 is an explanatory diagram of the mechanism of a system that allows for centralized management of NFTs, and is a schematic flowchart of the overall overview. Fig. 15 is an explanatory diagram of the mechanism of a system that allows for centralized management of NFTs, and is an explanatory diagram of the main parts. Figs. 16 and 17 are explanatory diagrams showing example screens that may be generated by an application that allows for centralized management of NFTs.

[0050] The features of this embodiment are as follows.

[0051] Assume that a user has various wallets. The types of wallets are arbitrary, and may include wallets associated with the above-mentioned permanent addresses, and wallets associated with addresses whose addresses are temporarily stored in the browser as described above. In addition, a wallet function may be provided in general software other than a browser.

[0052] This system will establish a mechanism for aggregating authentication, display, advertising, etc. of NFT holdings by connecting users' various wallets to a wallet aggregator function (application).

[0053] The application in which the wallet aggregator function is implemented (hereinafter also referred to as "this application") is illustrated as "My App" in Figures 14 and 15. This application (My App) may be downloaded to the user terminal 400, or may run on a browser.

[0054] With this mechanism, even if a user has multiple wallets, they can manage the state of each wallet in one dimension using a single application, improving convenience.

[0055] For example, as shown in FIG. 16, when the application is started, it outputs a management screen. When this management screen is displayed, the user can select one or more desired wallets from among one or more wallets registered in advance. The wallet may be selected in any manner, for example, via a pull-down menu, via a tag, or by direct input. In the case of a pull-down menu, the pull-down menu may display registered wallets in a selectable manner. In addition, a function for displaying information on all registered wallets in an integrated manner may be provided. FIG. 17 shows an example of a screen when a wallet with a wallet address of "0xDD···" is selected from among the three wallets shown in the pull-down menu in FIG. 16. When the wallet address "0xDD···" is selected from the pull-down menu on the screen shown in FIG. 16, various NFTs (held NFTs) associated with the wallet with the wallet address "0xDD···" can be displayed in a list as shown in FIG. 17. The displayed target may include additional information such as an explanation of the corresponding NFT.

[0056] Here, the features of the wallet registration method will be described with reference to FIG. 14 and FIG. 15. In FIG. 15, a situation is assumed in which user A registers three wallets A, B, and C. In this case, user A registers wallet A (wallet address A), wallet B (wallet address B), and wallet C (wallet address C) by signing each of wallets A, B, and C. For example, when user A registers wallet A, he signs the wallet address A of wallet A and transmits it to a predetermined server (for example, a server common to the token control processing reception unit 300). The predetermined server may be a server that runs this application on a browser. In addition, as a specific operation of the predetermined server, it may have a function of registering the signature sent from the wallet after confirming it in advance using a verification method corresponding to each wallet (electronic signature verification technology such as ECDSA, inquiry processing based on a signature verification interface for each contract wallet standardized as the ERC-1271 standard, a simple mode in which signature verification is skipped and the wallet is considered to have been verified, etc.).

[0057] The predetermined server acquires and confirms the wallet address of the user based on the signature. Then, when ownership is confirmed, the wallet name (wallet icon) and wallet address are registered in association with user identification information that can identify the user. The timing at which the user registers the wallet is arbitrary, but it is preferable to register the wallet at the time of NFT distribution, for example. In addition, in the case of a wallet associated with a wallet address whose wallet address is temporarily stored in the browser as described above, automatic registration may be realized in cooperation with this application. That is, in the case where the predetermined server is a server common to the token control processing reception unit 300, when the wallet address is temporarily stored in the browser as described above, automatic registration may be realized in cooperation with this application. In addition, the registration information may be stored in a local storage (for example, an index database) of the user terminal 400 instead of or in addition to the predetermined server.

[0058] The information related to the multiple wallets managed one-dimensionally in this manner may be used in a predetermined system. That is, the present application may cooperate with a predetermined system. For example, when cooperating with an NFT holder limited system, the user may display limited content based on the NFT information held in the user's address. Also, when cooperating with an NFT list display system, the user may display the NFTs in each wallet together. Also, when cooperating with an advertisement distribution system, a mechanism may be realized in which advertisements are displayed to web viewers for the NFTs held in each address by loading a plug-in that is embedded in a website, such as that used in an ad network.

[0059] In this way, once it has been confirmed based on the "signature" that a user's wallet address belongs to the user's own wallet, it can be put together like a key chain, making it easy to use in various systems.

[0060] Next, an example of a data acquisition process executed by the application when displaying the management screen shown in Fig. 16 will be described with reference to Fig. 18. Fig. 18 is a flowchart showing an example of the data acquisition process.

[0061] First, a list of NFT contract addresses is obtained from the API (step S1). Here, the list of NFT contract addresses is obtained from the API. Note that the list of NFT contract addresses is used to determine whether each NFT is included in a dynamic NFT in the process of step S6 described later.

[0062] Here, dynamic NFTs will be explained. Dynamic NFTs are different from normal NFTs in that the metadata content of the NFT changes (changes) depending on the establishment of a certain condition. The certain condition is a condition that can be established depending on the user's actions, such as scanning a certain code, viewing a certain advertisement, making a certain contract, going to a specified place, purchasing a certain product, receiving a certain service, viewing a specified site, capturing a specified landscape, etc. In this application, the user can always view the latest list of NFTs held by executing the following process. In addition, the user can check the information of NFTs whose metadata changes, such as dynamic NFTs, in almost real time.

[0063] Next, an NFT list for each chain is obtained from the API (step S2). Here, a list of NFTs held in a wallet connected to My Apps on the user terminal 400 is obtained from an external NFT indexer (hereinafter referred to as the indexer). The indexer is a device that stores information indicating what NFTs each user owns and information indicating the metadata of each NFT owned by each user in a database server, so that the information can be retrieved immediately without looking it up. Due to the structure of NFTs, it is difficult to determine who the owner of an NFT is and what the contents of the NFT are. By using the indexer, it is possible to check by querying the server without having to organize and look up these information.

[0064] Next, parallel processing is performed on each NFT item in the NFT list (step S3). From this point on, individual processing is performed in parallel on each NFT item included in the list of owned NFTs obtained from the indexer. By processing multiple NFT items simultaneously in this way, the overall processing time is reduced.

[0065] First, the processing of steps S4 to S10, which is one of the parallel processes, will be described. In one of the parallel processes, a function for each NFT item is called (step S4). Here, a function is called for each NFT item to perform processes such as obtaining metadata and saving it to a memory area of ​​the user terminal.

[0066] Next, the NFT metadata is fetched from the token URL (tokenURL) (step S5). Here, the NFT metadata is obtained from the token URL stored on the blockchain for each NFT in the acquired list of owned NFTs. Note that the NFT metadata includes detailed information such as the NFT content URL, name, and description.

[0067] Next, it is determined whether or not it is included in a dynamic NFT (step S6). Here, the metadata of the acquired NFT is compared with the list of contract addresses acquired in step 1 to determine whether or not it is included in the list of contract addresses designated as dynamic NFTs. Note that this determination is important because the metadata of dynamic NFTs may be updated periodically.

[0068] If it is determined that the NFT is not included in the dynamic NFT (step S6: NO), a cache of the metadata of the NFT (normal NFT) is stored in an index database (IndexeDB) in the storage area of ​​the user terminal 400 (step S7). By storing a cache of the metadata of the NFT in the index database in this way, it becomes possible to reduce external communication when displaying the management screen from the next time onwards. When this process ends, the data acquisition process ends.

[0069] If it is determined that the metadata is included in the dynamic NFT (step S6: YES), the latest metadata is obtained from the blockchain (step S8). Here, if an attempt is made to obtain the latest metadata from the indexer, there is a possibility that the indexer will not return the latest metadata, so the latest metadata is obtained directly from the blockchain.

[0070] Next, it is determined whether or not the dynamic NFT has already been stored in the index database (step S9). Here, it is determined whether or not the acquired dynamic NFT has already been stored in the index database of the user terminal 400.

[0071] If it is determined that the dynamic NFT has not been stored in the index database (step S9: NO), a cache of the metadata of the dynamic NFT is stored in the index database in the storage area of ​​the user terminal 400 (step S7).

[0072] If it is determined that the metadata has already been stored in the index database (step S9: YES), the index database is updated (step S10). Here, if the dynamic NFT is stored in the index database of the user terminal 400, it is updated to the latest metadata acquired from the blockchain. This keeps the metadata of the dynamic NFT up to date. When this process is completed, the data acquisition process is terminated.

[0073] Next, the other parallel process, that is, steps S11 to S12, will be described. In the other parallel process, a cache of metadata of the NFT is stored in the index database (step S11).

[0074] Next, items not included in the NFT list are deleted (step S12). Here, NFT items not included in the NFT list are determined to be not owned by the user, and are deleted from the index database of the user terminal 400. This ensures that the information in the user terminal 400 always reflects the latest status. When this process ends, the data acquisition process ends.

[0075] By executing the data acquisition process as described above, if a dynamic NFT is among the multiple NFTs held by a user, the NFT is displayed in the latest state based on the latest metadata on the management screens shown in Figures 16 and 17. Therefore, when a user acquires a dynamic NFT, the NFT (content of the NFT) that was in its initial form will be displayed in a different form of NFT (content of the NFT) when the user launches the management screen at a certain time. Note that the latest ancillary information, such as the latest explanation of the corresponding NFT, may also be included. This data acquisition process allows the NFT to be displayed in its latest state when the user checks the NFTs held by the user, which can increase the interest in collecting NFTs.

[0076] In this embodiment, various further modifications and improvements are possible, as described below.

[0077] For example, the place to record the signature and address may be the local storage of the browser running My Apps. It may also be a server system that requires login. As another method, the usage rights that are bundled together like a keychain may be implemented as an NFT (keychain NFT).

[0078] In addition, to prevent issues related to sharing private keys, a mechanism could be put in place that will not activate the wallet unless it contains assets of a certain value when determining whether or not an NFT is held.

[0079] In addition, it is also possible to increase the stability of the indexer by using multiple indexers as the source of NFT information. Also, a function that allows smooth wallet switching from the button at the top of the screen as shown in Figure 16 is also useful. In this case, the necessary information is retrieved in the background in advance, making switching smooth. Also, as mentioned above, it is useful to be able to connect multiple wallets (wallet aggregation function). Also, it is possible to smoothly register to this application from the NFT distribution path. For example, the wallet may be routed to this application at the end of the NFT distribution screen and registered.

[0080] [Other embodiments] Although each embodiment has been described above in detail, the present invention is not limited to the specific embodiment, and various modifications and changes are possible within the scope of the claims. In addition, it is also possible to combine all or a plurality of the components of the above-described embodiments.

[0081] The following supplementary notes are further disclosed regarding each of the above embodiments.

[0082] [Appendix 1] A system for controlling tokens circulating on a blockchain network consisting of multiple computers, a token processing unit that manages and processes the tokens; a token control processing reception unit that notifies the token processing unit of token control information in response to an instruction from a user terminal and transmits a result from the token processing unit to the user terminal; A distribution means for distributing information to the user terminal, the distribution means sets a random number or information set according to a predetermined rule as a part of the token control information to be distributed to the user terminal; The user terminal notifies the token processing unit of the token control information via or without the token control processing reception unit; The token control processing reception unit or the token processing unit stores the token control information received from the user terminal together with user information regarding the user terminal that transmitted the token control information, A token control system characterized in that the token processing unit refers to the random number or the information set in the rule set in the token control information by the distribution means, and uses the random number or the information set in the rule as specific information of the token managed by the token processing unit.

[0083] [Appendix 2] the token processing unit has an information processing unit that processes the random number stored in the token control information or information set by the rule to fit the information within a certain range, The token control system described in Appendix 1 is characterized in that, when the first processing information obtained by processing the random number or the information set according to a predetermined rule is the same as the existing information stored in the token control information, the processing unit further processes the first processing information into second processing information, thereby keeping the token control information within a certain range, and uses the first processing information or the second processing information as information for identifying a token managed by the token processing unit, and performs control on the identified token.

[0084] [Appendix 3] The token processing unit fits information into a certain range in the processing unit, further divides and weights the range, and when the information becomes the same as existing information in the processing unit, the processing unit reprocesses the information so that it fits within the divided range, uses the information that fits within the divided range as information for identifying a token, and performs control on the identified token. This is the token control system described in Appendix 2.

[0085] [Appendix 4] The token control system according to claim 2 or 3, characterized in that the token processing unit processes information taking into account additional information stored in the token control information when confining the information within a certain range in the processing unit.

[0086] [Appendix 5] The token control system according to any one of claims 2 to 4, wherein the token processing unit controls the allocation range and the number of allocations in the processing unit according to the distribution means.

[0087] [Appendix 6] The token control system according to any one of claims 3 to 5, characterized in that when the user terminal transmits the token control information, the token control processing unit or the token processing unit changes whether or not to accept processing, the processing method of the processing unit, and the weighting of the divided ranges of the range depending on the date and time of transmission and / or the combination of the distribution means, and then controls the identified token.

[0088] [Appendix 7] The token control system according to any one of claims 2 to 6, characterized in that, when constraining information within a certain range, the information processing unit generates a random number by calling a random number generation function operated on the blockchain network by the token processing reception unit or the token processing unit, combines the random number or information set according to a predetermined rule with the random number to generate third processed information, and uses the third processed information as input to the information processing unit.

[0089] [Appendix 8] The token control system according to any one of claims 1 to 7, characterized in that the distribution means encrypts information of the token control information to be used by the token processing unit to create information, the token control processing reception unit or the token processing unit holds a decryption encryption key and decrypts and uses the information using the decryption encryption key, and when the token processing unit decrypts the information, the public key of the public key pair is registered in the token processing unit.

[0090] [Appendix 9] The token control system described in Supplementary Notes 1 to 8, characterized in that when the user terminal transmits the token control information to the token control processing reception unit or the token processing unit, the user terminal automatically generates information necessary to uniquely identify the user in the blockchain network in a memory unit that can only be used by the user terminal, or, if the uniquely identifying information is stored in the memory unit, reads out the information, sets the generated uniquely identifying information, and then transmits the token control information.

[0091] [Appendix 10] The token control system described in Appendix 9 is characterized in that, when the user terminal generates the uniquely identifying information, it generates information for restoring the uniquely identified information that was generated uniquely, and presents the information to the user and notifies the user to store it.

[0092] [Appendix 11] The token control system described in Appendix 9 or Appendix 10, characterized in that when the user terminal obtains uniquely identifying information in the blockchain network that the user uses on a regular basis, it reads the generated uniquely identifying information managed in a memory unit that can only be used by the user terminal, provides a UI for instructing an update of user information from the generated uniquely identifying information for a token that the user has permission to use and is managed by the token processing unit to the uniquely identifying information used on a regular basis, and updates the user information in accordance with the instructions of the UI.

[0093] [Appendix 12] The token control system described in Supplementary Note 9 to Supplementary Note 11, characterized in that the user terminal signs a processing request to the blockchain network with a private key held in the user terminal and requests the token control processing reception unit to process on behalf of the user, and the token control processing reception unit pays the fee required when making a processing request to the blockchain network on behalf of the user and requests the processing from the blockchain network.

[0094] [Appendix 13] The token control system described in Appendix 12 is characterized in that when the token control processing reception unit performs proxy processing, the user terminal refers to the token control information stored in the token control information processing reception unit, determines whether or not to perform proxy processing based on the content of the token control information, or determines additional processing to be performed when performing proxy processing, and then requests processing from the blockchain network, and performs proxy processing including additional processing or does not perform proxy processing. [Explanation of symbols]

[0095] 100...blockchain network, 600...token control information, 700...received data storage unit, 800...token management information, 900...token distribution number management, 1000...token storage location change UI

Claims

1. A program that causes a computer to execute a management function that enables centralized management of multiple wallet addresses.

2. 2. The program of claim 1, further causing the computer to execute a registration function of registering a corresponding wallet address when signed wallet address information is received from a user.

3. The program according to claim 2 , wherein the registration function performs registration via a signature-based ownership verification process.

4. The program according to claim 1 , further causing the computer to execute a function of supplying information relating to the plurality of centrally managed wallet addresses to a predetermined system.

5. Further having an output function for outputting a predetermined screen, 2. The program according to claim 1, wherein the output function causes the computer to output predetermined information linked to one or more registered wallet addresses when the one or more wallet addresses are selected via the predetermined screen.

6. The program according to claim 5 , wherein the predetermined information includes an NFT.

7. The NFT includes a first NFT in which metadata of the NFT changes and a second NFT in which the metadata does not change; The program according to claim 6 , further comprising: when outputting the predetermined information, if the predetermined information is the first NFT, causing the computer to obtain the metadata of the first NFT.

8. An information processing method having a management process that enables centralized management of multiple wallet addresses.

9. An information processing device having a management function that enables centralized management of multiple wallet addresses.

Images