Information processing system and program

Abstract

To provide an information processing device, an information processing system and a program in a digital asset management system.SOLUTION: An NFT management system 1600 includes a secret key generation part for generating a secret key to be associated with a non-fungible token (NFT), a storage information acquisition part for acquiring storage information about a storage place of the non-fungible token from an issue device for issuing the non-fungible token through a communication network, and a connection information generation part for generating connection information being information obtained by connecting the secret key and the storage information. The storage information includes, for example, ledger type information showing a type of a distributed ledger for storing the non-fungible token, ledger identification information for uniquely identifying the distributed ledger, and token identification information for uniquely identifying the non-fungible token in the distributed ledger.SELECTED DRAWING: Figure 16

Description

[Technical Field]

[0001] The present invention relates to an information processing system and a program. [Background technology]

[0002] Non-Patent Document 1 discloses a hot wallet that uses a browser extension. Non-Patent Document 2 discloses a method of printing and storing data on paper. Non-Patent Document 3 discloses a method of storing data in highly confidential hardware. Non-Patent Documents 4 and 5 disclose methods of managing NFTs using a wallet. (Prior art document) (Non-patent literature) (Non-Patent Document 1) MetaMask, "The crypto wallet for Defi, Web3 Dapps and NFTs", [online], [Retrieved March 7, 2023], Internet <URL:https: / / metamask.io / > (Non-Patent Document 2) The bitaddress.org, "bitaddress.org", [online], [searched March 7, 2023], Internet <URL:https: / / github.com / pointbiz / bitaddress.org / > (Non-Patent Document 3) LEDGER, "Hardware Wallet & Cold Wallet Security for Crypto", [online], [Retrieved March 7, 2023], Internet <URL:https: / / www.ledger.com / > (Non-Patent Document 4) SUSHITOPMARKETING, "NFT Issuance Experience", [online], [Retrieved July 19, 2023], Internet <URL:https: / / www.sushitopmarketing.com / service / nft-publish> (Non-Patent Document 5) E. Glen Weyl et.al, "Decentralized Society: Finding Web3's Soul" [online], [searched on July 19, 2023], Internet <https: / / papers.ssrn.com / sol3 / papers.cfm?abstract_id=<4105763>

Summary of the Invention

Means for Solving the Problems

[0003] In a first aspect of the present invention, an information processing apparatus is provided. The above information processing apparatus includes, for example, a secret key generation unit that generates a secret key associated with a non-fungible token (NFT). The above information processing apparatus includes, for example, a storage information acquisition unit that acquires, from an issuing apparatus that issues a non-fungible token, via a communication network, storage information that is information regarding a storage location of the non-fungible token. The above information processing apparatus includes, for example, a combined information generation unit that generates combined information that is information in which the secret key and the storage information are combined.

[0004] In any of the above information processing apparatuses, the storage information may include ledger type information indicating the type of a distributed ledger that stores non-fungible tokens. The storage information may include ledger identification information for uniquely identifying the distributed ledger. The storage information may include token identification information for uniquely identifying a non-fungible token in the distributed ledger.

[0005] In any of the above information processing apparatuses, the combined information generation unit may output a single electronic file including the combined information. Any of the above information processing apparatuses may include a screen generation unit that generates a screen having an object in which a URL including the combined information is embedded as a part of the URL parameters.

[0006] Any of the above information processing devices may include an address acquisition unit that acquires an address of a user of the information processing device. Any of the above information processing devices may include a signature generation unit that generates an electronic signature related to the user's address using a private key. Any of the above information processing devices may include a transmission unit that associates the electronic signature and storage information and transmits them to a verification device that verifies whether the user is a legitimate owner or holder of the non-fungible token. In any of the above information processing devices, the address may be generated based on a public key that corresponds to the private key.

[0007] A second aspect of the present invention provides an information processing device. The information processing device includes, for example, an access control unit configured to be able to access a distributed ledger that stores one or more non-fungible tokens (NFTs) in association with the addresses of owners or holders of each non-fungible token. The information processing device includes, for example, a verification unit that verifies whether a first user is a legitimate owner or holder of the first non-fungible token. In the information processing device, the verification unit includes, for example, a verification target acquisition unit that acquires, from a communication terminal used by the first user, first storage information, which is information regarding a storage location of the first non-fungible token, and a digital signature related to the first user's address. The verification unit includes, for example, a ledger information acquisition unit that accesses the distributed ledger and acquires address information indicating an address associated with the first non-fungible token in the distributed ledger. The verification unit includes, for example, a determination unit that compares the address indicated by the digital signature with the address indicated by the address information to determine whether the first user is a legitimate owner or holder of the first non-fungible token.

[0008] In a third aspect of the present invention, there is provided a token management system. The token management system includes a first device that is, for example, any of the information processing devices according to the first aspect. The token management system includes a second device that is, for example, any of the information processing devices according to the second aspect.

[0009] In a fourth aspect of the present invention, a program is provided. A computer-readable medium storing the program may be provided. The computer-readable medium may be a non-transitory computer-readable medium or a computer-readable recording medium. The program may be a program for causing a computer to function as the information processing device according to the first or second aspect. The program may be a program for causing a computer to execute various information processing methods in the information processing device according to the first or second aspect.

[0010] The above summary of the invention does not list all of the necessary features of the present invention, and subcombinations of these features may also constitute inventions. [Brief explanation of the drawings]

[0011] [Figure 1] 1 shows an example of a system configuration of a digital asset management system 100. [Figure 2] 1 shows an example of information processing in the digital asset management system 100. [Figure 3] 1 shows an example of the internal configuration of a wallet providing server 120. [Figure 4] 10 shows an example of the internal configuration of the wallet audit server 130. [Figure 5] 10 shows an example of information processing in the wallet audit server 130. [Figure 6] 2 shows an example of the internal configuration of a user terminal 150. [Figure 7] 10 shows an example of information processing in the user terminal 150. [Figure 8] 8 shows an example of a screen 800 output from the input / output unit 624. [Figure 9] 9 shows an example of a screen 900 output from the input / output unit 624. [Figure 10] 10 shows an example of a screen 1000 output from the input / output unit 624. [Figure 11] 10 is a diagram illustrating an example of a security verification process of a wallet application. [Figure 12] 10 shows an example of a process for preparing to generate a wallet. [Figure 13] 10 shows an example of a wallet generation process. [Figure 14] An example of information processing in step 1330 is shown in outline. [Figure 15] 10 illustrates an example of a wallet activation process. [Figure 16] An example of the system configuration of an NFT management system 1600 is shown schematically. [Figure 17] 16 shows an example of information processing in the NFT management system 1600. [Figure 18] 16 shows an example of information processing in the NFT management system 1600. [Figure 19] An example of an electronic file 1900 is shown schematically. [Figure 20] 2 shows a schematic diagram of an example of an electronic file 2000. [Figure 21] 16 shows an example of the internal configuration of a wallet providing server 1620. [Figure 22] An example of the internal configuration of the NFT verification unit 1644 is shown schematically. [Figure 23] 1 shows an example of a wallet generator 642 and a wallet executor 644. [Figure 24] 24 shows an example of a screen 2400 output from the input / output unit 624. [Figure 25] 3 shows an example of a system configuration of a computer 3000. DETAILED DESCRIPTION OF THE INVENTION

[0012] The present invention will be described below through embodiments of the invention, but the following embodiments do not limit the scope of the invention. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention. In the drawings, the same reference numerals are used to designate the same or similar parts, and redundant explanations may be omitted.

[0013] (Overview of Digital Asset Management System 100) 1 schematically illustrates an example of the system configuration of a digital asset management system 100. In this embodiment, the digital asset management system 100 manages encrypted or encoded data (sometimes referred to as digital assets) such as crypto assets and non-fungible tokens (NFTs). In this embodiment, the details of the digital asset management system 100 will be described using as an example a case in which the digital asset management system 100 manages digital assets using a pair of a private key and a public key that is valid on a blockchain.

[0014] In this embodiment, the digital asset management system 100 comprises one or more wallet providing servers 120, one or more wallet auditing servers 130, one or more audit result databases 140, and one or more user terminals 150. In this embodiment, each part of the digital asset management system 100 is realized by various types of computers.

[0015] In this embodiment, each unit of the digital asset management system 100 is configured to be connectable to the blockchain network 12. In addition, in this embodiment, the audit result database 140 is constructed by a distributed ledger system that uses the blockchain network 12.

[0016] In one embodiment, each of the one or more computers constituting each part of the digital asset management system 100 participates as a node of the blockchain network 12 via a P2P (Peer to Peer) connection. In another embodiment, a specific node that constitutes the blockchain network 12 functions as a proxy server, and each of the one or more computers constituting each part of the digital asset management system 100 connects to the proxy server via RPC (Remote Procedure Call) to perform registration processing to the blockchain and / or blockchain reference processing.

[0017] In this embodiment, each unit of the digital asset management system 100 is configured to be able to send and receive information to and from each other via the communication network 14. For example, the user terminal 150 accesses the wallet providing server 120 via the communication network 14 to obtain wallet application data (sometimes referred to as content) provided by the wallet providing server 120.

[0018] In this embodiment, the wallet audit server 130 and the audit result database 140 transmit and receive information to and from other information processing devices that may constitute the digital asset management system 100 via the blockchain network 12. This prevents tampering with wallet application data, wallet application audit results, etc., and also ensures the transparency of this information.

[0019] In other embodiments, the wallet audit server 130 may transmit and receive information to and from other information processing devices via the communication network 14. The audit result database 140 may transmit and receive information to and from other information processing devices via the communication network 14.

[0020] In digital asset transactions, for example, blockchain, a type of decentralized distributed ledger, is used. The legitimacy of each transaction is guaranteed by attaching the participant's digital signature to the transaction information (transaction). Here, a participant is a node that can send transactions to the blockchain network 12 and possesses a private key for signing transactions.

[0021] In the digital asset management system 100, private keys linked to the above digital assets are managed using wallets. A wallet is, for example, some kind of object for holding, manipulating, and managing private keys, and is provided in various forms such as a physical device, a software program, an online service, or a data object. Examples of wallets include wallets connected to the Internet (sometimes referred to as hot wallets) and wallets that manage stored keys separately from the Internet (sometimes referred to as cold wallets).

[0022] In recent years, various applications (sometimes referred to as wallet applications) have been developed to enable users 20 to manage the above-mentioned private keys using their own terminals. Wallet applications generate pairs of a private key associated with a digital asset and a public key corresponding to the private key, for example, using any public key cryptography method. As described above, a data object including at least a private key generated on a wallet application may be referred to as a wallet. A wallet application may have functions for operating and / or managing a wallet.

[0023] The form of the wallet application is not particularly limited. The wallet application may be provided in the form of a mobile application (sometimes referred to as a mobile app) designed and created to run on a mobile terminal, or in the form of a web application (sometimes referred to as a web app) that can be operated on the web in an internet environment. The wallet application may also be provided in the form of a cloud application (sometimes referred to as a cloud app) that uses a cloud or virtual server. A cloud app may be a type of web app.

[0024] A user 20 who wishes to use digital assets first operates his / her user terminal 150 to generate a wallet. For example, the user terminal 150 generates a pair of a private key and a public key, enabling calculation of a valid address on the blockchain, thereby generating a wallet. A remittance address for the digital assets on the blockchain is uniquely derived from the public key. Therefore, the public key can function as a destination for the digital assets. This allows the user 20 to cryptographically store the digital assets using the wallet.

[0025] However, it is not easy for an average user 20 to verify whether a wallet application is operating in accordance with a trustworthy protocol. Users 20 who use wallet applications have no choice but to trust the developers of the wallet applications, and this issue of trust is hindering the widespread use of wallet applications.

[0026] In this regard, according to the digital asset management system 100 of this embodiment, various items related to the security of the wallet application provided by the wallet providing server 120 are inspected in advance by the wallet audit server 130. At least some of the inspections are performed automatically according to a predetermined algorithm. The wallet audit server 130 registers the results of the inspections (sometimes referred to as inspection results) in the audit result database 140 built on the blockchain network 12.

[0027] Specifically, the wallet audit server 130 registers the URI of a wallet application whose safety has been confirmed by inspection as the inspection result of that wallet application in the audit result database 140. That is, in this embodiment, a wallet application whose URI is registered in the audit result database 140 is a relatively safe wallet application whose predetermined items have been inspected. As will be described later, the audit result database 140 may store data in which at least a portion of the wallet application that has been inspected is encoded (sometimes referred to as encoded data).

[0028] In this embodiment, the user terminal 150 generates a wallet on the user terminal 150 using a wallet application provided by the wallet providing server 120. In this case, before executing the wallet generation process, the user terminal 150 accesses the audit result database 140 to check whether the URI of the wallet application is registered in the audit result database 140.

[0029] If the URI of the wallet application is registered in the audit result database 140, the wallet generation process is executed. On the other hand, if the URI of the wallet application is not registered in the audit result database 140, the wallet generation process is not executed.

[0030] As a result, the digital asset management system 100 according to this embodiment ensures the reliability of the wallet application or wallet operating on the user terminal 150 used by each user 20. As a result, the user 20 can safely use the wallet application and / or digital assets.

[0031] (Overview of each part related to the digital asset management system 100) In this embodiment, the blockchain network 12 is constructed by a plurality of computers (sometimes referred to as nodes). The details of the blockchain network 12 are not particularly limited, but for example, a blockchain network capable of Turing-completely executing smart contracts is used as the blockchain network 12. For example, Ethereum is used as the blockchain infrastructure in the above network. Communication paths between nodes are encrypted using encryption technology such as SSL / TLS.

[0032] In this embodiment, the communication network 14 transmits information between multiple devices. The communication network 14 may be a wired communication transmission path, a wireless communication transmission path, or a combination thereof. The communication network 14 may be the Internet, a dedicated line, a wireless communication network, or a combination thereof. The communication network 14 may include a P2P network such as an ad hoc network.

[0033] The communication method in the wireless communication network may be a mobile communication method or a wireless data communication method. Examples of the mobile communication method include the 3G method, the LTE method, the 4G method, and the 5G method. Examples of the wireless data communication method include the wireless PAN method, the wireless LAN method, the wireless MAN method, and the wireless WAN method. The communication method in the wireless communication network may be any of various short-range wireless communication methods.

[0034] In this embodiment, the wallet providing server 120 provides a wallet application to each of one or more users 20. The wallet application is, for example, a program that causes a computer to function as a private key management device that manages private keys used to encrypt digital data. For example, by executing the wallet application on the user terminal 150, a wallet for managing private keys that may be linked to digital assets is generated. This allows the user 20 to safely use the digital assets using the user terminal 150. Details of the wallet providing server 120 will be described later.

[0035] In this embodiment, the wallet audit server 130 provides a service (sometimes referred to as an audit service) for auditing a system implemented by a wallet application. The audit service provides, for example, the results of an audit of a wallet application. Details of the wallet audit server 130 will be described later.

[0036] The auditor who provides audit services using the wallet audit server 130 may be an individual, an organization, or a corporation. The auditor has authority independent of the provider of the wallet application being audited. The provider of the wallet application may be an individual, an organization, or a corporation.

[0037] Specifically, wallet audit server 130 inspects the security of wallet applications. Wallet audit server 130 registers the inspection results in audit result database 140. Wallet audit server 130 may associate information indicating the inspection results of wallet applications (sometimes referred to as inspection information) with encoded data of the wallet applications that were inspected, and store the information in audit result database 140. An example of the encoded data is a hash value of at least a part of the code of the wallet application.

[0038] In this embodiment, the audit result database 140 stores the inspection information output by the wallet audit server 130. The audit result database 140 may store the inspection information and the encoded data in association with each other.

[0039] In this embodiment, the user terminal 150 is used by each of one or more users 20. The user terminal 150 may be any device that can send and receive information to and from other information processing devices, and the details thereof are not particularly limited.

[0040] The user terminal 150 may support multiple communication methods. For example, the communication terminal supports both mobile communication methods such as 3G, LTE, 4G, and 5G, and wireless communication methods such as wireless LAN and wireless MAN. The user terminal 150 may be a mobile terminal. Examples of mobile terminals include mobile phones, smartphones, PDAs (registered trademarks), tablets, notebook or laptop computers, and wearable computers. Details of the user terminal 150 will be described later.

[0041] (Specific configuration of each part of the digital asset management system 100) Each unit of the digital asset management system 100 may be realized by hardware, software, or a combination of hardware and software. At least a portion of each unit of the digital asset management system 100 may be realized by a personal computer or a mobile terminal. For example, a personal computer or a mobile terminal may be used as a user interface for the digital asset management system 100. Examples of mobile terminals include mobile phones, smartphones, PDAs, tablets, notebook or laptop computers, and wearable computers.

[0042] When at least some of the components constituting the digital asset management system 100 are implemented by software, the software-implemented components may be implemented by running a program that defines the operations of the components in an information processing device with a general configuration. The information processing device may, for example, include (i) a data processing device having various processors (examples of processors include a CPU, a GPU, etc.), a ROM, a RAM, a communication interface, etc., and (ii) a storage device (including an external storage device) such as memory and a HDD. The information processing device may also include (iii) input devices such as a keyboard, a touch panel, a camera, a microphone, various sensors, a GPS receiver, etc., and (iv) output devices such as a display device, a speaker, a vibration device, etc.

[0043] In the information processing device, the data processing device or storage device may store a program. For example, when the program is loaded into a computer, the information processing described in the program functions as a specific means in which software related to the program and various hardware resources constituting at least a part of the digital asset management system 100 work together. The specific means then performs calculations or processing of information according to the intended use of the computer in this embodiment, thereby constructing the digital asset management system 100 or a part thereof according to the intended use.

[0044] The above program may be stored in a computer-readable medium. The above program may be stored in a non-transitory computer-readable recording medium. The above program may be stored in a computer-readable medium such as a CD-ROM, a DVD-ROM, a memory, or a hard disk, or may be stored in a storage device connected to a network. The above program may be installed on a computer constituting at least a part of the digital asset management system 100 from the computer-readable medium or the storage device connected to the network.

[0045] By executing the above program, the computer may function as at least a part of each unit of the digital asset management system 100. By executing the above program, the computer may execute an information processing method in at least a part of the digital asset management system 100.

[0046] A program for causing a computer to function as at least a part of the digital asset management system 100 includes, for example, a module that defines the operation of at least a part of the digital asset management system 100. When the program or module is executed, the program or module acts on a data processing device, an input device, an output device, a storage device, etc., to cause the computer to function as at least a part of the digital asset management system 100 or to execute an information processing method in at least a part of the digital asset management system 100.

[0047] The information processing method includes, for example, an execution control step of controlling an execution device that executes a management program. The management program is, for example, a program that causes a computer to function as a private key management device that manages private keys used to encrypt digital data. The information processing method includes, for example, an inspection information acquisition step of accessing an inspection information storage device that stores inspection information indicating the results of a third-party inspection of the security of the management program or the private key management device, and acquiring the inspection information. In the information processing method, the execution control step includes, for example, a step of determining whether to permit or not restrict execution of the management program when inspection information indicating that security has been confirmed by inspection is acquired in the inspection information acquisition step. The execution control step includes, for example, a step of determining whether to prohibit or restrict execution of the management program when inspection information indicating that security has been confirmed by inspection is not acquired in the inspection information acquisition step.

[0048] The digital asset management system 100 may be an example of an information processing system. The wallet audit server 130 may be an example of an inspection unit, an encoded data generation unit, or a registration unit. The operator of the wallet audit server 130 may be an example of a third party. The audit result database 140 may be an example of an inspection information storage device. The user terminal 150 may be an example of an execution device, a determination device, or an information processing system.

[0049] Digital asset data may be an example of digital data. A wallet may be an example of a private key management device. A wallet application may be an example of a management program.

[0050] 2 shows an example of information processing in the digital asset management system 100. In this embodiment, the details of information processing in the digital asset management system 100 will be explained using as an example a case where a wallet application is provided as a Web application in the wallet providing server 120, and a wallet is generated within the Web application in the user terminal 150 via a Web browser (sometimes simply referred to as a browser).

[0051] According to this embodiment, first, in step 222 (step may be abbreviated as S), wallet providing server 120 provides a wallet application. Wallet providing server 120 transmits a signal (sometimes referred to as an audit request) to wallet audit server 130 requesting inspection (sometimes referred to as an audit) of the wallet application provided by wallet providing server 120.

[0052] Next, in S224, the wallet audit server 130 inspects the security of the wallet application for which inspection has been requested, and registers the inspection results in the audit result database 140.

[0053] Next, in S232, the user terminal 150 acquires wallet application data (sometimes referred to as content) from the wallet providing server 120. The content includes, for example, HTML data and JavaScript (registered trademark).

[0054] In this embodiment, the user terminal 150 obtains the contents of the wallet application from the wallet providing server 120, for example, via a web browser running on the user terminal 150. The user terminal 150 executes the wallet application within the web application via the web browser and generates a wallet.

[0055] (browser extension) In this embodiment, an extension function for controlling the wallet generation process is implemented in the web browser. The extension function verifies the security of the wallet application that is the target of the wallet generation process before the wallet generation process is executed. Specifically, the security of the wallet application is verified based on the inspection results of the wallet application stored in the audit result database 140.

[0056] For example, the above-mentioned extended functions are implemented in the web browser by installing a program (sometimes referred to as an extension program) for implementing the above-mentioned extended functions in the web browser in the user terminal 150. The extension program is installed in the user terminal 150 based on an instruction from the user 20, for example.

[0057] The extension program and wallet application may be distributed independently. For example, the extension program is distributed from a domain different from the provider of the wallet application. This ensures that even if the wallet providing server 120 is hacked and an unauthorized wallet application is distributed, the extension program will not be affected by the hack. This ensures the security and reliability of the wallet.

[0058] Furthermore, because the extension operates as part of the browser, it can access elements and / or JavaScript included in content loaded into the browser. This allows the extension and the wallet application to operate in cooperation. As a result, the extension can verify the operation of the wallet application running within the web application and, if any abnormal or suspicious behavior is detected, stop the execution of the wallet application.

[0059] (Controlling wallet generation process by extension) If information indicating that the security of the wallet application to be generated has been confirmed is obtained from audit result database 140, the extended function determines to permit execution of the wallet application. In this case, it may also determine not to restrict the execution of the wallet application.

[0060] If it is determined whether to permit or not restrict the execution of the wallet application, the user terminal 150 executes the wallet application within a web browser. The wallet application is executed, for example, using the basic functions of the browser. This generates a private key and public key pair, and as a result, a wallet is created.

[0061] On the other hand, if information indicating that the security of the wallet application to be generated has been confirmed is not obtained from audit result database 140, the extended function determines not to permit execution of the wallet application. In this case, it may decide to restrict execution of the wallet application. For example, it may decide to prohibit execution of the wallet application.

[0062] If it is determined that execution of the wallet application is not permitted, user terminal 150 does not execute the wallet application. Similarly, if it is determined that execution of the wallet application is restricted, user terminal 150 does not execute at least a part of the wallet application. As a result, a wallet is not generated.

[0063] Furthermore, according to this embodiment, when a wallet is generated, a process is executed to validate (sometimes referred to as activation) the wallet. For example, an authentication process for the user 20 is executed. According to the above authentication process, for example, the wallet is validated when it is authenticated that the user 20 has legitimate authority to use the wallet.

[0064] Next, in S234, the user terminal 150 executes a wallet application to manage transactions of digital assets, thereby enabling management of the use of digital assets by the user 20.

[0065] A web browser may be an example of an execution device, and an extension may be an example of an execution control unit.

[0066] (An example of another embodiment) In this embodiment, the details of information processing in the digital asset management system 100 have been described using as an example a case where the user terminal 150 accesses the wallet providing server 120 via a web browser and a wallet is generated within a web application. However, the information processing in the digital asset management system 100 is not limited to this embodiment.

[0067] In other embodiments, user terminal 150 may access wallet providing server 120 by any known method and obtain the contents of the wallet application from wallet providing server 120. User terminal 150 may execute the wallet application on user terminal 150 by any known method.

[0068] In this embodiment, for the purpose of facilitating understanding of information processing in the digital asset management system 100, the inspection of the wallet application in the wallet audit server 130, the creation and activation of the wallet in the user terminal 150, and the operation of the wallet and management of digital assets in the user terminal 150 are described as a series of processes. However, the information processing in the digital asset management system 100 is not limited to this embodiment.

[0069] In another embodiment, the verification of the wallet application at wallet audit server 130, the creation and / or activation of the wallet at user terminal 150, and the operation of the wallet and / or management of digital assets at user terminal 150 are performed separately. For example, once the verification of the wallet application is completed at a first point in time, the creation and / or activation of the wallet at user terminal 150 can be performed at a second point in time, which is any point in time after the first point in time. Similarly, once the wallet is created at a second point in time, the operation of the wallet and / or management of digital assets at user terminal 150 can be performed at a third point in time, which is any point in time after the second point in time.

[0070] 3 shows an example of the internal configuration of the wallet providing server 120. In this embodiment, the wallet providing server 120 includes an application providing unit 320 and a wallet authenticating unit 330.

[0071] In this embodiment, the application providing unit 320 provides a wallet application. As described above, the wallet application includes a program for causing a computer to function as a private key management device that manages private keys used to encrypt digital data. The wallet application may also include a program for causing a computer to execute procedures for causing the computer to function as a private key management device. The above computer may be a computer installed in the user terminal 150.

[0072] In one embodiment, the procedure for causing a computer to function as a private key management device includes, for example, a disconnection procedure for disconnecting the computer from an external network. The disconnection procedure includes procedures for causing the computer to execute various commands. Examples of the commands include (i) a command for causing the computer to disconnect the computer from the external network, (ii) a command for causing the computer to present information to the user of the computer prompting the user to disconnect the computer from the external network, (iii) a command for causing the computer to start a network disconnection program pre-installed on the computer, and / or (iv) a command for causing the computer to request disconnection from the external network.

[0073] In another embodiment, the procedure for causing a computer to function as a private key management device may include, for example, a generation procedure for generating a private key and a public key corresponding to the private key after a disconnection process has been executed. In yet another embodiment, the procedure for causing a computer to function as a private key management device may include, for example, a confirmation procedure for confirming that the computer has been disconnected from the external network before the generation procedure. The confirmation procedure is executed, for example, after the disconnection process and before the generation procedure. The generation procedure is executed, for example, after the confirmation procedure.

[0074] The encoded data described above may include first encoded data in which code, script, or program corresponding to at least a portion of a cutting procedure is encoded. The encoded data described above may include second encoded data in which code, script, or program corresponding to at least a portion of a generation procedure is encoded. The encoded data described above may include second encoded data in which code, script, or program corresponding to at least a portion of a verification procedure is encoded. As described above, an example of the encoding process is a process of deriving a hash value using an arbitrary hash function. An example of at least a portion of each procedure is some or all of the multiple procedures or steps included in each procedure.

[0075] The application providing unit 320 makes each of the one or more wallet applications accessible to an external information processing device, thereby enabling the user terminal 150 to access the wallet providing server 120 and obtain the contents of the wallet application.

[0076] The wallet application may be provided as a web application. This allows user terminal 150 to view the wallet application using a web browser, which executes the wallet application using the web browser's basic functions. Furthermore, as described above, execution of the wallet application may be controlled or restricted by extensions built into the web browser.

[0077] In this embodiment, the wallet authentication unit 330 performs authentication processing (sometimes referred to as validation processing) of the created wallet. The wallet is authenticated, for example, by a challenge-response method. The wallet authentication processing will be described in detail later.

[0078] The second coded data may be an example of generation procedure coded data.

[0079] 4 shows an example of the internal configuration of the wallet audit server 130. In this embodiment, the wallet audit server 130 includes an audit request acquisition unit 420, an application acquisition unit 430, an audit unit 440, and an audit result registration unit 450.

[0080] In this embodiment, the audit request acquisition unit 420 acquires an audit request from the wallet providing server 120. In this embodiment, the application acquisition unit 430 acquires the contents of the wallet application that is the target of the audit request. For example, when the audit request acquisition unit 420 acquires an audit request, the application acquisition unit 430 acquires the contents of the wallet application that is the target of the audit request. The application acquisition unit 430 may acquire the URI of the wallet application.

[0081] The method by which the application acquisition unit 430 acquires the contents and URI of a wallet application is not particularly limited. In one embodiment, the application acquisition unit 430 acquires the contents by reading the contents stored in any storage device of the wallet audit server 130. For example, the above contents are uploaded from the wallet providing server 120 to the wallet audit server 130 at any timing and stored in the above storage device. The application acquisition unit 430 may access the wallet providing server 120 at any timing, acquire the above contents from the wallet providing server 120, and store the content in the above storage device. In another embodiment, the application acquisition unit 430 may acquire pre-deployed content that is published in a repository.

[0082] In this embodiment, the auditing unit 440 inspects the security of the wallet application. The auditing unit 440 may inspect the security of the wallet application in accordance with a predetermined algorithm. The auditing unit 440 may inspect predetermined items related to the security of the wallet application.

[0083] In one embodiment, the auditing unit 440 extracts, for example, all scripts used by content resources of a wallet application. The auditing unit 440 inspects the extracted scripts according to a predetermined algorithm. In another embodiment, the auditing unit 440 extracts, for example, a portion of content resources of a wallet application. For example, the auditing unit 440 extracts scripts for implementing functions related to wallet operation.

[0084] For example, if an identifier indicating a wallet function is inserted in a script tag of a content source, the auditing unit 440 extracts the script in accordance with the tag. The auditing unit 440 may extract the script in accordance with a procedure shared with the provider of the wallet application.

[0085] The auditing unit 440 checks the extracted script to verify that the wallet application functions are implemented in accordance with a predetermined protocol, such as ensuring that the computer is disconnected from external networks before the private / public key pair generation process is executed, that a secure public key cryptosystem is used, and that the generated private key is not sent to an external server.

[0086] The auditing unit 440 may determine whether manual inspection is necessary. If it is determined that manual inspection is necessary, the auditing unit 440 may output information indicating the items that require manual inspection and information indicating the parts of the content that will be subject to the inspection.

[0087] In this embodiment, the auditing unit 440 encodes at least a portion of the wallet application to generate data in which at least a portion of the wallet application is encoded (as described above, this may be referred to as encoded data). An example of the encoding process is a process of deriving a hash value using an arbitrary hash function. The auditing unit 440 may execute the encoding process when the security of the wallet application is confirmed.

[0088] As described above, the wallet application includes a program for generating a wallet, which may include, for example, (i) code, script, or program corresponding to the disconnection procedure described above, (ii) code, script, or program corresponding to the generation procedure described above, (iii) code, script, or program corresponding to the verification procedure described above, and / or (iv) code, script, or program related to the wallet to be generated.

[0089] Examples of encoded data include data obtained by encoding the above-mentioned codes, scripts, or programs, or any combination thereof. For example, if scripts Sa and Sb are included in the contents of a wallet application, the auditing unit 440 applies a hash function H to the scripts Sa and Sb to obtain a unique script hash H(Sa, Sb). The auditing unit 440 may obtain the script hash H(Sa) and / or the script hash H(Sb), or may obtain a hash value of the entire contents of the wallet application.

[0090] The audit result registration unit 450 registers information indicating the results of the inspection by the audit unit 440 (as described above, this may be referred to as inspection information) in the audit result database 140. The audit result registration unit 450 may register the inspection information in the audit result database 140 when the security of the wallet application is confirmed.

[0091] For example, if the audit result database 140 is implemented using the Ethereum blockchain, the audit result registration unit 450 registers the inspection information in a smart contract on the blockchain. For example, the audit result registration unit 450 creates a transaction indicating the URI of a wallet application that has been confirmed to be safe, and issues the transaction to the blockchain network 12. As a result, evidence indicating that the wallet application has been inspected is registered on the blockchain. As described above, the creation and / or registration of the above transaction may be performed by the proxy server described above. As a result, inspection information for each of one or more wallet applications is stored in the audit result database 140.

[0092] The inspection information may include the URI of the wallet application. For example, if inspection results of wallet applications whose safety has been confirmed are registered in audit result database 140, and inspection results of wallet applications whose safety has not been confirmed are not registered, the information indicating the inspection results of the wallet application may be the URI of the wallet application.

[0093] The auditing unit 440 may associate information indicating the inspection results of a wallet application with the encoded data of the wallet application and register the associated information in the audit result database 140. As a result, the inspection information for each of one or more wallet applications and the encoded data of the wallet application are associated and stored in the audit result database 140. For example, the audit result registration unit 450 creates a transaction indicating the association between the URI of a wallet application that has been confirmed to be safe and the encoded data, and issues the transaction to the blockchain network 12.

[0094] The auditing unit 440 may be an example of an inspection unit or an encoded data generating unit. The audit result registering unit 450 may be an example of a registering unit.

[0095] 5 shows an example of information processing in the wallet audit server 130. According to this embodiment, first, in S520, the application acquisition unit 430 receives an audit request from the wallet providing server 120. The audit request includes, for example, the URL of the wallet application that is the subject of the audit request. The wallet application URL may be an example of a URI for the wallet application. The application acquisition unit 430 accesses the URL included in the audit request to acquire the contents of the wallet application. Note that the procedure for acquiring the contents and URI of the wallet application is not limited to this embodiment. The application acquisition unit 430 outputs the contents and URI of the wallet application to the audit unit 440.

[0096] Next, in S532, the auditing unit 440 inspects the wallet application. Next, in S534, the auditing unit 440 determines whether or not the security of the wallet application has been confirmed by the above inspection.

[0097] If the security of the wallet application is confirmed in the above inspection (Yes in S534), in S536 the auditing unit 440 derives a hash value for each JavaScript deployed in the contents of the wallet application. Then, in S540, the audit result registration unit 450 registers the inspection results and the above hash values ​​in the audit result database 140. On the other hand, if the security of the wallet application is not confirmed in the above inspection (No in S534), the inspection results are not registered in the audit result database 140, and the series of processes ends.

[0098] 6 schematically illustrates an example of the internal configuration of the user terminal 150. In this embodiment, the user terminal 150 includes, for example, a communication unit 622, an input / output unit 624, a storage unit 626, and a control unit 630. In this embodiment, the control unit 630 includes, for example, a browser execution unit 640, an input / output control unit 650, and a communication control unit 660. In this embodiment, the browser execution unit 640 includes, for example, a wallet generation unit 642, a wallet execution unit 644, and a restriction unit 646.

[0099] In this embodiment, the communication unit 622 transmits and receives information to and from each unit of the digital asset management system 100 via the blockchain network 12 and / or the communication network 14. The communication unit 622 transmits and receives information between the user terminal 150 and each unit of the digital asset management system 100, for example, based on instructions from the control unit 630.

[0100] In this embodiment, the input / output unit 624 functions as, for example, an interface with the user 20. In one embodiment, the input / output unit 624 accepts various inputs from the user 20. The input / output unit 624 may detect a human operation by the user 20. The input / output unit 624 may output information indicating the content of the input or instruction from the user 20 to the control unit 630. In another embodiment, the input / output unit 624 presents various information to the user 20. The input / output unit 624 may present a screen for accepting input or instructions from the user 20. The input / output unit 624 may present information to the user 20 based on an instruction from the control unit 630.

[0101] The input / output unit 624 may include various input devices. Examples of the input devices include a keyboard, a pointing device, a touch panel, a microphone, a voice input device, and a gesture input device. The input / output unit 624 may include various output devices. Examples of the output devices include a display, a projector, and a speaker.

[0102] In this embodiment, the storage unit 626 stores various types of information. In one embodiment, the storage unit 626 stores various types of information used in information processing in the user terminal 150. In another embodiment, the storage unit 626 stores various types of information generated by information processing in the user terminal 150.

[0103] The storage unit 626 may store various types of information related to the wallet. Examples of the information related to the wallet include an ID assigned to the wallet, a private key of the wallet, a public key corresponding to the private key, and information used to activate the wallet or authenticate the user 20. The private key may be encrypted. In this embodiment, the storage unit 626 stores, for example, the private key together with metadata as a data file.

[0104] Various storage media are exemplified as the storage unit 626. Examples of the storage media include storage or hardware devices such as a hard disk drive (HDD) and a solid state drive (SSD).

[0105] In this embodiment, the control unit 630 controls the operation of the user terminal 150. The control unit 630 controls, for example, the execution of various programs in the user terminal 150. The control unit 630 may determine whether to execute a program, or may determine whether to stop or interrupt the execution of a program.

[0106] In this embodiment, the browser execution unit 640 executes a web browser. In one embodiment, the browser execution unit 640 uses the basic functions of the web browser to cause the computer of the user terminal 150 to execute various processes. In another embodiment, the browser execution unit 640 uses extended functions implemented in the web browser to cause the computer of the user terminal 150 to execute various processes. The basic functions and extended functions of the web browser may operate in cooperation with each other.

[0107] In this embodiment, the details of each unit of the browser execution unit 640 will be described using as an example a case where the wallet generation unit 642 and the wallet execution unit 644 are realized by the basic functions of a web browser, and the restriction unit 646 is realized by an extended function built into the web browser. However, the combination of elements realized by the basic functions of a web browser and elements realized by an extended function built into the web browser is not limited to this embodiment. In other embodiments, the restriction unit 646 may be realized by the basic functions of a web browser.

[0108] In this embodiment, the wallet generator 642 executes a wallet application, which generates a private / public key pair that can be linked to a digital asset, thereby creating a wallet that functions on the user terminal 150.

[0109] Specifically, the wallet generation unit 642 accesses the wallet providing server 120 and acquires a wallet application (sometimes referred to as a wallet application to be executed). The wallet generation unit 642 determines whether to execute the wallet application in accordance with an instruction from the restriction unit 646. For example, the wallet generation unit 642 acquires a signal (sometimes referred to as a control signal) for controlling the execution of the wallet application from the restriction unit 646. The wallet generation unit 642 executes the wallet application in accordance with the control signal.

[0110] For example, wallet generation unit 642 executes a wallet application when it receives a signal instructing execution of the wallet application (sometimes referred to as an execution instruction signal) from restriction unit 646. Wallet generation unit 642 may start execution of the wallet application in response to receiving the execution instruction signal from restriction unit 646.

[0111] In one embodiment, if the restrictor 646 determines whether to permit or not restrict the execution of the wallet application, the wallet generator 642 executes the wallet application. In another embodiment, if the restrictor 646 determines not to permit the execution of the wallet application, the wallet generator 642 does not execute the wallet application. In yet another embodiment, if the restrictor 646 determines to restrict the execution of the wallet application, the wallet generator 642 does not execute at least a portion of the wallet application. For example, the wallet generator 642 does not execute the generation procedure described above.

[0112] After acquiring the wallet application to be executed, the wallet generation unit 642 may encode at least a portion of the wallet application to generate data (sometimes referred to as verification data) to be used in the verification process by the restriction unit 646. The encoding process may be the same as the encoding process by the wallet audit server 130. The encoding process by the wallet generation unit 642 may be a process of deriving a hash value using the same hash function as the hash function used by the wallet audit server 130. The wallet generation unit 642 may output the verification data to the restriction unit 646.

[0113] In this embodiment, the wallet execution unit 644 executes processing for using digital assets using the wallet generated by the wallet generation unit 642. For example, the wallet execution unit 644 executes processing for validating the wallet.

[0114] In this embodiment, the restriction unit 646 controls the wallet generation unit 642. The restriction unit 646 determines, for example, whether to restrict execution of at least a part of the wallet generation process in the wallet generation unit 642. The restriction unit 646 determines, for example, by referring to the inspection information stored in the audit result database 140, whether the safety of the wallet application to be executed has been confirmed. If it is determined that the safety of the wallet application has been confirmed, the restriction unit 646 outputs a control signal to the wallet generation unit 642 indicating that execution of the wallet application is permitted or not restricted.

[0115] Specifically, the restriction unit 646 first acquires the inspection information of the wallet application by accessing the audit result database 140. In this case, the restriction unit 646 may acquire the inspection information and encoded data of the wallet application.

[0116] Next, when the restriction unit 646 acquires inspection information indicating that the security of the wallet application has been confirmed by the inspection, the restriction unit 646 decides whether to permit or not restrict execution of the wallet application. When the restriction unit 646 acquires the inspection information and the verification data output by the wallet executor 644 matches the encoded data, the restriction unit 646 may decide whether to permit or not restrict execution of the wallet application.

[0117] On the other hand, if the restriction unit 646 cannot obtain inspection information indicating that the security of the wallet application has been confirmed by inspection, the restriction unit 646 decides to not permit or restrict execution of the wallet application. For example, if the URI of the wallet application is not registered in the audit result database 140, the restriction unit 646 decides to not permit or restrict execution of the wallet application. If the restriction unit 646 cannot obtain the above inspection information, or if the verification data output by the wallet executor 644 does not match the above encoded data, the restriction unit 646 may decide to not permit or restrict execution of the wallet application.

[0118] In this embodiment, the input / output control unit 650 controls the input / output unit 624. The input / output control unit 650 generates, for example, various screens to be displayed on a display device of the input / output unit 624. The input / output control unit 650 may generate a screen for receiving input or instructions from a user, or may generate a screen for presenting information to a user. The input / output control unit 650 may control the input / output unit 624 to display the above-mentioned screens on the display device of the input / output unit 624. In this embodiment, the communication control unit 660 controls the communication unit 622.

[0119] The control unit 630 may be an example of an execution device, a determination device, or an information processing system. The browser execution unit 640 may be an example of an execution device, a determination device, or an information processing system. The wallet generation unit 642 may be an example of a program acquisition unit, a verification data acquisition unit, a program output unit, a control information acquisition unit, a program execution unit, an execution device, or an information processing system. The restriction unit 646 may be an example of a determination device or an information processing system. The input / output control unit 650 may be an example of a screen generation unit. The control signal may be an example of control information. The execution instruction signal may be an example of control information.

[0120] (An example of another embodiment) In this embodiment, the details of the digital asset management system 100 have been described using as an example a case where the private key of the wallet is stored in the storage unit 626 arranged in the user terminal 150. However, the digital asset management system 100 is not limited to this embodiment. In other embodiments, the private key of the wallet may be stored in a storage medium external to the user terminal 150, or in a virtual storage medium provided by an online storage service or a cloud storage service.

[0121] In this embodiment, an example of the details of the digital asset management system 100 has been described using as an example a case where the input / output control unit 650 of the user terminal 150 generates various screens to be displayed on the display device of the input / output unit 624 and causes the above screens to be displayed on the display device of the input / output unit 624. However, the digital asset management system 100 is not limited to this embodiment. In other embodiments, the input / output control unit 650 may receive screen data generated by an external information processing device via the blockchain network 12 or the communication network 14, and control the input / output unit 624 to cause the above screens to be displayed on the display device of the input / output unit 624.

[0122] 7 shows an example of information processing in the user terminal 150. According to this embodiment, first, in S722, the wallet generation unit 642 acquires the contents of the wallet application. Next, in S724, the restriction unit 646 confirms the security of the wallet application. If the security of the wallet application is confirmed, in S732, the wallet generation unit 642 executes the wallet application. When the wallet application is executed, first, preparation processing for wallet generation is executed. If it is confirmed that the above preparation processing is completed, in S734, wallet generation processing is executed. Thereafter, in S742, wallet authentication processing or validation processing is executed.

[0123] 8 shows an example of a screen 800 output from the input / output unit 624. The screen 800 is displayed on the display device of the input / output unit 624, for example, when the browser execution unit 640 accesses the wallet providing server 120 to obtain a wallet application.

[0124] In this embodiment, screen 800 includes a browser display area 820 in which the execution results of the web browser are displayed. As described above, in this embodiment, the wallet application is executed via a web browser. Therefore, in this embodiment, browser display area 820 includes a wallet display area 840 in which the execution results of the wallet application are displayed.

[0125] In this embodiment, for example, an object 842 for displaying various messages and an object 844 in which a command for causing a computer to execute processing for acquiring a wallet application are arranged in the wallet display area 840. Also, as described above, in this embodiment, an extended function is implemented in the web browser. Therefore, an object 862 indicating that the extended function is enabled and an object 864 displaying various messages presented to user 20 from the extended function are arranged in the wallet display area 840.

[0126] 9 schematically illustrates an example of a screen 900 output from the input / output unit 624. The screen 900 is displayed on the display device of the input / output unit 624, for example, when the restriction unit 646 determines to permit execution of a wallet application and the wallet generation unit 642 determines to execute the wallet application.

[0127] In this embodiment, for example, object 864 has object 966, which contains an embedded command for causing a computer to execute a wallet application, disposed inside it. When user 20 operates user terminal 150 to click object 966, wallet generation unit 642 starts the wallet application execution process. When the wallet application execution process starts, preparations for wallet generation are first performed. When the preparations are completed, the wallet application execution process is temporarily suspended.

[0128] 10 is a schematic diagram showing an example of a screen 1000 output from the input / output unit 624. The screen 1000 is displayed on the display device of the input / output unit 624 when the preparation process for creating a wallet is completed.

[0129] In this embodiment, for example, object 864 contains object 1066, which contains an embedded command for causing a computer to continue execution of the wallet application. When user 20 operates user terminal 150 to click object 1066, wallet generation unit 642 continues execution of the wallet application. This causes wallet generation processing to be executed. Specifically, processing to confirm that user terminal 150 has been disconnected from the external network and processing to generate a private key and public key pair are executed.

[0130] 11 shows an example of a wallet application (sometimes abbreviated as wallet app in the figure) safety confirmation process. According to this embodiment, first, in S1122, the user 20 operates the user terminal 150 to instruct access to a website where the wallet application is provided (sometimes referred to as an application providing site). The application providing site is provided by, for example, the wallet providing server 120.

[0131] When the user terminal 150 accepts an access instruction from the user 20, the browser execution unit 640 launches a web browser and accesses the wallet providing server 120. When the web browser accesses the wallet providing server 120, in S1124, the wallet generation unit 642 requests the wallet providing server 120 to transmit the content of the above-mentioned application providing site. In addition, in S1126, the wallet providing server 120 responds to the request by transmitting the content of the above-mentioned application providing site to the user terminal 150. The wallet generation unit 642 processes the content and presents a screen of the application providing site on the display device of the input / output unit 624. The input / output unit 624 presents, for example, the above-mentioned screen 800 to the user 20. As described above, an object 844 having an embedded command for starting the download of a wallet application is arranged on the screen 800.

[0132] Next, in S1132, the user 20 views the screen 800 and operates the user terminal 150 to click on the object 844 arranged on the screen 800. When the object 844 is clicked, in S1134 the wallet generation unit 642 requests the wallet providing server 120 to transmit the contents of the wallet application. In response to the request, in S1136 the wallet providing server 120 transmits the contents of the wallet application to the user terminal 150.

[0133] Next, when the wallet generation unit 642 acquires the contents of the wallet application, a hash value of each JavaScript deployed in the contents of the wallet application is derived in S1140. As described above, the hash value may be an example of encoded data.

[0134] In this embodiment, in order to facilitate understanding of the wallet application security verification process, the details of the wallet application security verification process will be described using as an example a case in which hash values ​​are derived for all JavaScript deployed in the wallet application content. However, the wallet application security verification process is not limited to this embodiment. According to other embodiments, for example, hash values ​​are derived for some of the multiple JavaScript deployed in the wallet application content.

[0135] (An example of a procedure for deriving a hash value) According to one embodiment, first, the wallet generation unit 642 sends the wallet application content or each JavaScript deployed within the content to the restriction unit 646. Next, the restriction unit 646 generates a verification code by deriving a hash value of each JavaScript using a predetermined hash function. This allows the restriction unit 646 to obtain the hash value (i.e., the verification code) of each JavaScript deployed within the wallet application content.

[0136] According to this embodiment, transmission of fraudulent data or inaccurate verification data from the wallet generation unit 642 to the restriction unit 646 is suppressed. Examples of fraudulent data include data that differs from the hash values ​​derived from each JavaScript deployed in the content of the wallet application provided by the wallet providing server 120, malware, etc.

[0137] (Another example of a hash value derivation procedure) According to another embodiment, first, the wallet generation unit 642 uses a predetermined hash function to derive a hash value for each JavaScript deployed in the wallet application content. This generates the above-described verification code. The wallet generation unit 642 outputs the generated verification code to the restriction unit 646. This allows the restriction unit 646 to obtain the hash value (i.e., the verification code) for each JavaScript deployed in the wallet application content.

[0138] Next, in S1152, the restriction unit 646 refers to the inspection information stored in the audit result database 140 and determines whether the security of the wallet application acquired by the wallet generation unit 642 has been confirmed. If it is determined that the security of the wallet application has been confirmed, in S1154 the restriction unit 646 presents, for example, a screen on the display device of the input / output unit 624 for presenting to the user 20 the inspection results and that the wallet application is executable. The input / output unit 624 presents, for example, the above-mentioned screen 900 to the user 20. As described above, the screen 900 has an object 966 with an embedded command for starting execution of the wallet application arranged thereon. This completes the wallet application security confirmation process.

[0139] The contents of the wallet application may be an example of at least a part of the management program. Each JavaScript deployed in the contents of the wallet application may be an example of a part of the management program.

[0140] 12 shows an example of a wallet generation preparation process. According to this embodiment, first, in S1222, the user 20 views the screen 900 and operates the user terminal 150 to click on an object 966 arranged on the screen 900. When the object 966 is clicked, the restriction unit 646 accepts an instruction from the user and determines to permit execution of the wallet application.

[0141] Next, in S1224, the restriction unit 646 generates a control signal indicating that execution of the wallet application is permitted, and outputs the control signal to the wallet generation unit 642. The control signal may be or may include an instruction to cause the wallet generation unit 642 to execute a script for executing preparatory processing for generating a wallet. Thus, when the wallet generation unit 642 receives the control signal, the wallet generation unit 642 executes preparatory processing for generating a wallet.

[0142] Specifically, first, at S1232, the wallet generation unit 642 requests the wallet providing server 120 to generate and transmit a challenge C. Next, at S1234, the wallet providing server 120 generates the challenge C. The wallet providing server 120 associates the identification information of the user 20 with the challenge C and stores them in an appropriate storage medium. The wallet providing server 120 transmits the challenge C to the user terminal 150 in response to the request from the wallet generation unit 642. As a result, at S1236, the wallet generation unit 642 acquires the challenge C.

[0143] Challenge C may be random data that is changed or generated for each request. In the process of storing the identification information of user 20 and challenge C in association with each other, identification that the payout destination of challenge C is user 20 is performed, for example, by login authentication when using a wallet application. During the login authentication, user 20 inputs, for example, identification information assigned to user 20 in advance. An example of the identification information is a membership number.

[0144] Next, in S1242, the wallet generation unit 642 causes a user interface that prompts the user to disconnect from the network to be displayed on the display device of the input / output unit 624. The wallet generation unit 642 may cause the display device to display the user interface in accordance with an instruction from the restriction unit 646. The instruction is included in, for example, the control signal sent by the restriction unit 646 to the wallet generation unit 642 in S1224.

[0145] In S1244, the user 20 operates the user terminal 150, for example, to place the user terminal 150 in an offline environment. For example, the user terminal 150 goes offline by disabling the network function of the user terminal 150. This allows the private key to be securely generated in the wallet generation process described below.

[0146] The procedure for placing the user terminal 150 in an offline environment is not limited to the above embodiment. In another embodiment, the wallet generation unit 642 or the restriction unit 646 forcibly disables the network function of the user terminal 150.

[0147] Next, in S1242, the wallet generation unit 642 detects a network disconnection. After that, in S1252, the wallet generation unit 642 notifies the restriction unit 646 that the above-described preparation process has been completed.

[0148] The restriction unit 646, for example, causes the display device of the input / output unit 624 to present a screen for notifying the user 20 that preparations for wallet generation have been completed and that the wallet generation process can begin. The input / output unit 624 presents, for example, the above-described screen 1000 to the user 20. As described above, the screen 900 contains an object 1066 embedded with a command for continuing execution of the wallet application. This completes the above-described preparation process.

[0149] The preparation process for generating a wallet may be an example of a procedure for causing a computer to function as a private key management device. The user interface that prompts disconnection from the network may be an example of information that prompts disconnection of the computer from the external network.

[0150] 13 shows an example of a wallet generation process. According to this embodiment, first, in S1322, the user 20 views the screen 1000 and operates the user terminal 150 to click on the object 1066 arranged on the screen 1000. When the object 1066 is clicked, the restriction unit 646 accepts an instruction from the user and determines to continue execution of the wallet application.

[0151] Next, in S1324, the restriction unit 646 first confirms that the connection between the user terminal 150 and the external network has been disconnected. When the network disconnection is confirmed, in S1326 the restriction unit 646 controls the wallet generation unit 642 to execute wallet generation processing. Thereafter, in S1330, the wallet generation unit 642 executes wallet generation processing. Details of the wallet generation processing will be described later. When the wallet is generated, in S1332 the wallet generation unit 642 notifies the restriction unit 646 that the wallet has been generated.

[0152] Next, in S1342, the restriction unit 646 causes a user interface for prompting the export of wallet-related data to be presented on the display device of the input / output unit 624. Examples of wallet-related data include an encrypted private key, a public key, a challenge C, and a signature value. In S1344, when the user 20 operates the user terminal 150 to instruct the restriction unit 646 to export wallet-related data, the restriction unit 646 instructs the wallet generation unit 642 to export the above-mentioned data.

[0153] Next, in S1348, the wallet generation unit 642 controls the above-described web application to download the above data to the user terminal 150. As a result, the above data is stored in the storage unit 626 of the user terminal 150. In one embodiment, each downloaded data is stored as a separate file. In another embodiment, each downloaded data is stored as a single file. The above data is stored in a consolidated state in a single file, for example, as a compressed file.

[0154] Next, in S1352, a user interface for prompting the user to close the browser is displayed on the display device of input / output unit 624. This ends the execution process of the wallet application.

[0155] 14 shows an example of the information processing in step 1330. As described above, step S1330 is executed in an offline environment.

[0156] According to this embodiment, first, in S1422, the wallet generation unit 642 generates a private key / public key pair as a wallet. At this time, the user terminal 150 is disconnected from the network, and the key generation is performed on the client side, not the server side. In this case, for example, the Web Crypto API implemented as a standard specification in web browsers is used for the cryptographic processing.

[0157] Next, in S1424, the wallet generation unit 642 digitally signs the challenge C acquired by the wallet generation unit 642 in S1236 using the private key generated in S1422, and stores the obtained signature value. The signature value includes, for example, the public key and the challenge C encrypted with the private key.

[0158] Next, in S1426, user 20 operates user terminal 150 to set a password for encrypting the private key. Thereafter, in S1428, wallet generation unit 642 encrypts the private key with the password. This completes the processing of step 1330.

[0159] (An example of another embodiment) In this embodiment, the details of the information processing in step 1330 have been described using as an example a case where S1422 is executed, followed by S1424, S1426, and S1428. However, the information processing in step 1330 is not limited to this embodiment. In other embodiments, at least one of S1424, S1426, and S1428 may not be executed.

[0160] 15 shows an example of a wallet activation process. In this embodiment, in S1522, the user 20 operates the user terminal 150 to instruct access to a website (sometimes referred to as an activation site) that provides a wallet activation service. The activation site is provided by, for example, the wallet providing server 120.

[0161] For example, the wallet providing server 120 executes a process to authenticate that the user 20 has legitimate authority to use the wallet, and upon completion of the authentication, the wallet is activated. This indicates that the user 20 is the owner of the wallet, that the user 20 possesses the private key, and that the user 20 possesses an address on the blockchain. As a result, various wallet management functions are realized. For example, the wallet providing server 120 can track deposits to the address of the user 20 and stop fraudulent deposit and withdrawal transactions.

[0162] When the user terminal 150 accepts an access instruction from the user 20, the browser execution unit 640 launches a web browser and accesses the wallet providing server 120. When the web browser accesses the wallet providing server 120, at S1524 the wallet execution unit 644 requests the wallet providing server 120 to transmit the content of the activation site. In response to the request, at S1526 the wallet providing server 120 transmits the content of the activation site to the user terminal 150. The wallet execution unit 644 processes the content and displays the screen of the activation site on the display device of the input / output unit 624.

[0163] Next, in S1532, a signature value submission process is executed. Specifically, first, the wallet providing server 120 identifies that the user 20 is accessing the activation site. In one embodiment, the user 20 is identified by login authentication using an ID and password. In another embodiment, the user 20 is identified by inputting the membership number assigned to the user 20.

[0164] Next, the user 20 operates the user terminal 150 to submit the signature value created in the wallet generation process to the activation site. As described above, the signature value is a digital signature for the challenge C issued by the wallet providing server 120. For example, a signature value based on an ECDSA (Elliptic Curve Digital Signature Algorithm) signature can be used as the signature value.

[0165] Next, in S1534, the wallet providing server 120 obtains a public key corresponding to the private key. For example, if the signature format of the digital signature is the ECDSA signature format of Ethereum, the public key can be restored from the signature value. If the signature format of the digital signature is a signature method that does not allow the public key to be restored from the signature value, the wallet providing server 120 may obtain the public key from the user 20 separately from the signature value.

[0166] Next, in S1536, the wallet providing server 120 uses the public key to verify whether the signature value submitted by the user 20 is a digital signature for challenge C. If it is verified that the signature value is a digital signature for challenge C, the wallet providing server 120 authenticates that the user 20 is the owner of the wallet linked to the public key. This completes the wallet validation process.

[0167] (Outline of NFT Management System 1600) 16 schematically illustrates an example of the system configuration of an NFT management system 1600. In this embodiment, the NFT management system 1600 manages the issuance, transfer, assignment, deletion, etc. of one or more non-fungible tokens (sometimes referred to as NFTs).

[0168] A non-fungible token is a unique, non-fungible unit of data recorded on a distributed ledger such as a blockchain. An NFT, for example, can be associated with any type of digital data (including electronic files). This allows the NFT to be used to authenticate or prove the authenticity of the digital data associated with the NFT and / or to authenticate or prove the rightful owner or holder of the digital data.

[0169] Examples of data associated with an NFT include data indicating the status of the owner or holder of the NFT, data indicating the qualifications or rights held by the owner or holder of the NFT, and data proving specific actions of the owner or holder of the NFT. Examples of the above-mentioned status include status as a member of a group or organization, and position within the group or organization. Examples of the above-mentioned qualifications include various national qualifications, various private qualifications, and qualifications to obtain or assume various positions. Examples of the above-mentioned rights include real rights, debts, status rights, and intellectual property rights. Examples of the above-mentioned specific actions include attending or participating in a specific event, purchasing or applying for a specific product or service, paying taxes, making donations, etc.

[0170] The right possessed by the owner or holder of the NFT described above may be the right to receive a benefit or novelty awarded in connection with a specific action. An NFT may be issued as the benefit or novelty. Examples of specific actions include attending or participating in a specific event, purchasing or applying for a specific product or service, paying taxes, making a donation, etc.

[0171] As mentioned above, NFTs are often managed using wallets and wallet applications. As mentioned above, a wallet is a data object that includes, for example, at least a private key, and a wallet application is an application for managing a wallet.

[0172] In recent years, technologies have been developed that allow users who do not have a pre-prepared wallet to easily distribute NFTs. For example, even if a user does not have a wallet prepared in advance to receive an NFT, a wallet is generated for the user to receive the NFT when the NFT is issued or transferred.

[0173] For example, Non-Patent Document 4 discloses a system in which a system for distributing NFTs generates a wallet associated with the NFT when issuing the NFT, stores the wallet in the cache area of ​​the browser of the user's communication terminal, and uses the browser as a wallet application for the NFT. However, the system described in Non-Patent Document 4 requires a very complicated procedure for transferring an NFT stored in a wallet application provided by the system to another wallet application managed independently by the user. As mentioned above, a wallet is a data object that includes a private key. Therefore, a wallet associated with an NFT is sometimes referred to as a private key associated with the NFT.

[0174] Generally, transfers of NFTs between wallet applications are realized by generating a transfer transaction using the private key of the sending user and then having that transaction approved on the distributed ledger network. When the transfer transaction is generated, the user must identify the recipient's wallet address and set that recipient's wallet address (e.g., represented by several dozen random alphanumeric characters) in the sending wallet application. Furthermore, in order for the user who received the NFT to view the NFT on the recipient's wallet application, the user must identify storage information related to the NFT and set that storage information as token configuration information within the wallet application. Examples of the storage information include the identification information of the issued distributed ledger and the identification information of the token.

[0175] Therefore, if users involved in transferring NFTs do not have sufficient knowledge and experience regarding cryptocurrency transactions and distributed ledger mechanisms, it becomes difficult for the sending user to determine the recipient's wallet address, set the wallet address in the sender's wallet application, and perform the procedures for the receiving user to determine storage information for the NFT, and / or set storage information for the NFT in the receiving user's wallet application. In particular, if the above-mentioned NFTs are generated based on a token standard that does not have a transfer function, transferring NFTs between wallet applications becomes even more difficult. An example of an NFT generated based on a token standard that does not have a transfer function is a non-transferable, non-fungible token (sometimes referred to as an SBT).

[0176] Specifically, SBT does not have a transfer function. Therefore, even if a transfer transaction is sent to the distributed ledger network, the transaction will not be confirmed on the distributed ledger network. Thus, if an NFT is generated based on SBT, users cannot transfer the token via a transaction.

[0177] (NFT issuance process in the NFT management system 1600) In contrast, according to the NFT management system 1600, an NFT is transferred from one wallet application to another wallet application without a transaction. Specifically, an NFT is transferred between two wallet applications by transferring a wallet associated with the NFT between the two wallet applications.

[0178] In this embodiment, among the ways in which NFTs are transferred, a way in which NFTs are transferred from one wallet application to another wallet application via a transaction may be referred to as a "transfer." Also, a way in which NFTs are transferred from one wallet application to another wallet application without a transaction may be simply referred to as a "transfer."

[0179] (Export Combined Data) According to this embodiment, when an NFT is issued to a user 20 of the NFT management system 1600, first, a private key associated with the NFT is generated in the user terminal 150 used by the user 20. As a result, a wallet containing the private key is provided. At this time, data (sometimes referred to as combined data) that combines data related to the wallet (sometimes referred to as wallet data) and data related to the storage location of the NFT (sometimes referred to as storage destination data) is generated in the user terminal 150 used by the user 20. The process of generating the combined data will be described in detail below.

[0180] In this embodiment, the combined data is stored in a storage device of the user terminal 150 where the wallet was created (this may be referred to as exporting the combined data). The combined data may also be stored in a cache area of ​​a browser running on the user terminal 150.

[0181] The storage destination data for a specific NFT includes, for example, at least one of (i) ledger type information indicating the type of distributed ledger that stores the NFT, (ii) ledger identification information for uniquely identifying the distributed ledger, and (iii) token identification information for uniquely identifying the NFT in the distributed ledger. The storage destination data for an NFT may include the ledger type information, ledger identification information, and token identification information described above.

[0182] Examples of ledger type information include the name or identification information of the distributed ledger, and information for obtaining the distributed ledger information. An example of the name of the distributed ledger is Ethereum. An example of information for obtaining the distributed ledger information is the URL of the connection destination to the distributed ledger node. This allows the distributed ledger to be indirectly identified.

[0183] Examples of ledger identification information include parameters for identifying ledgers with the same specifications in transactions within a distributed ledger. Examples of transactions within a distributed ledger include ChainID and NetworkID. Examples of parameters for identifying ledgers with the same specifications include parameters for identifying mainnet, testnet, etc.

[0184] The token identification information may be any parameter that can uniquely identify a token, and the details thereof are not particularly limited. Examples of token identification information include the address of the smart contract that issues the NFT, a Token ID, etc.

[0185] The combined data may be included in a single electronic file or may be output as a single electronic file. The format of the electronic file is not particularly limited, but examples of the format of the electronic file include image, JSON, and PDF (registered trademark).

[0186] (NFT transfer process in NFT management system 1600) As described above, according to the NFT management system 1600, an NFT managed by a wallet application (sometimes referred to as the wallet application of the user terminal 150) running on the user terminal 150 used by the user 20 can be transferred to another wallet application without going through a transaction. As described above, the memory device of the user terminal 150 used by the user 20 stores combined data related to the above NFT. The user terminal 150 can transfer the above NFT to another wallet application (sometimes referred to as the recipient wallet application) using the storage destination data included in the above combined data.

[0187] In one embodiment, when user 20 transfers an NFT that is the subject of a transfer process from the wallet application of user terminal 150 to a recipient's wallet application, user 20 first operates user terminal 150 to cause the computer of user terminal 150 to execute a process for importing the combined data of the NFT into the recipient's wallet application. The process for importing the combined data of the NFT that is the subject of a transfer process into the recipient's wallet application may include a procedure for transferring the combined data as electronic data, or may include a procedure for transferring the combined data as part of a URL parameter.

[0188] (An example of an embodiment in which the combined data is delivered as electronic data) For example, first, the computer of the user terminal 150 executes a process to output a screen for receiving input of an instruction to start the execution of the NFT transfer process from the user 20 to the display device of the computer of the user terminal 150. The above screen is generated, for example, by the input / output control unit 650 described above.

[0189] The above screen includes, for example, an object (sometimes referred to as an NFT transfer object) in which instructions are embedded for executing a process to transfer the combined data of the NFTs to be transferred as electronic data to the recipient's wallet application. The NFT transfer object may be a button-type object. The above screen may also include an object (sometimes referred to as an NFT-specific object) for receiving input to identify the NFTs to be transferred. The NFT-specific object may be a pull-down object, a checkbox object, a text box object, or a combination thereof.

[0190] When user 20 operates user terminal 150 and, for example, clicks on an NFT transfer object on a screen displayed on the display device of user terminal 150, the computer of user terminal 150 executes processing to transfer the combined data of the NFT to be transferred as electronic data to the recipient's wallet application. This imports the combined data of the NFT into the recipient's wallet application. When the combined data of the NFT is imported into the recipient's wallet application, the recipient's wallet application automatically configures token setting information based on the storage destination data for the NFT contained in the imported combined data. This allows the NFT to be transferred from the wallet application of user terminal 150 to the recipient's wallet application without a transaction.

[0191] According to this embodiment, at the stage of setting the recipient address in the wallet application of the sender, the procedure for the sender user to know the recipient's wallet address and / or the procedure for the sender user to set the wallet address in the wallet application of the sender can be omitted. As a result, the process for transferring the NFT described above can be executed without the user 20 having to manually know the recipient's wallet address or set the wallet address in the wallet application of the sender.

[0192] Similarly, according to this embodiment, at the stage of setting storage information for the NFT in the recipient's wallet application, the procedure for the user who received the NFT to understand the storage information for the NFT and / or the procedure for the user who received the NFT to set the storage information for the NFT in the recipient's wallet application can be omitted. This allows the above-mentioned process for transferring the NFT to be executed without the user 20 having to manually obtain the storage information from the website that distributed the NFT or a blockchain explorer, or manually input the storage information into the recipient's wallet application.

[0193] This significantly reduces the effort required for user 20 to transfer NFTs. Furthermore, according to this embodiment, NFTs can be transferred between wallet applications without going through a transaction, which can reduce the transaction fees borne by the sender when transferring NFTs.

[0194] (An example of an embodiment where the binding data is passed as part of a URL parameter) For example, first, the computer of the user terminal 150 executes a process to output a screen for receiving input of an instruction to start the execution of the NFT transfer process from the user 20 to the display device of the computer of the user terminal 150. The above screen is generated, for example, by the input / output control unit 650 described above.

[0195] The above screen includes, for example, an object (sometimes referred to as an NFT transfer object) in which instructions are embedded to execute a process for transferring the combined data of the NFT to be transferred to the recipient's wallet application as part of a URL parameter. The NFT transfer object may be a button-type object. The above screen may also include an object (sometimes referred to as an NFT-specific object) for receiving input to identify the NFT to be transferred. The NFT-specific object may be a pull-down type object, a checkbox type object, a text box type object, or a combination thereof.

[0196] In this embodiment, the combined data is embedded as a parameter in the URL of the link of the NFT transfer object. The combined data is embedded, for example, in the query string of the URL. For example, a URL with the combined data embedded as part of the URL parameter is expressed as, for example, "https: / / abcwallet123.com / ?chainType=Ethereum&networkId=1&contractAddress=0x16...&tokenId=9&encryptedWallet=0x14...". The above URL indicates, for example, that the ledger type (chainType) is Ethereum, the ledger identifier (networkId) is 1 (1 indicates the mainnet), the address of the smart contract issuing the NFT (contractAddress) is 0x16... (omitted), the token identifier (tokenId) is 9, and the wallet data (encryptedWallet) is 0x16... (omitted).

[0197] When the user 20 operates the user terminal 150 and, for example, clicks on an NFT transfer object on the screen displayed on the display device of the user terminal 150, the computer of the user terminal 150 executes processing to launch a mobile app that is the recipient's wallet application, or processing to transition to a web app that is the recipient's wallet application. This executes processing to transition to the recipient's wallet application.

[0198] Once the transition process to the recipient's wallet application is complete, the mobile app or web app causes the computer of user terminal 150 to acquire the combined data embedded in the URL as part of the URL parameters and execute a process to import the combined data into the recipient's wallet application. This imports the combined data of the NFT into the recipient's wallet application. Once the combined data of the NFT is imported into the recipient's wallet application, the wallet application automatically configures token setting information based on the storage destination data for the NFT included in the imported combined data. This allows the NFT to be transferred from the wallet of user terminal 150 to the recipient's wallet without a transaction.

[0199] According to this embodiment, at the stage of setting a recipient address in the wallet application of the sender, the procedure of the sender user ascertaining the recipient's wallet address and / or the procedure of the sender user setting a wallet address in the wallet application of the sender can be omitted. Similarly, according to this embodiment, at the stage of setting storage information related to an NFT in the wallet application of the recipient, the procedure of the user who received the NFT ascertaining storage information related to the NFT and / or the procedure of the user who received the NFT setting storage information related to the NFT in the wallet application of the recipient can be omitted.

[0200] This significantly reduces the effort required for user 20 to transfer NFTs. Furthermore, according to this embodiment, NFTs can be transferred between wallet applications without going through a transaction, which can reduce the transaction fees borne by the sender when transferring NFTs.

[0201] In particular, according to this embodiment, the combined data is delivered to the recipient's wallet application without the need for an electronic file, which further reduces the effort required for the user 20 to transfer the NFT.

[0202] In yet another embodiment, when a user 20 uses a specific NFT to prove or authenticate that he or she is the legitimate owner or holder of digital data associated with the NFT, the user 20 operates the user terminal 150 to cause the computer of the user terminal 150 to execute processing to output the combined data of the NFT. An information processing device that receives the combined data can access the distributed ledger that stores the NFT and confirm the address of the user of the NFT by analyzing the storage destination data included in the combined data.

[0203] This allows, for example, verification of qualifications or rights using NFTs and authentication of members using NFTs to be realized in servers that provide various matching services, servers that provide various services based on credit information, servers that provide services for members, etc. For example, even if the blockchain platform that issued each NFT that is the subject of verification or authentication processing is different, by having the server obtain the combined data from each user, the server can easily access the distributed ledger that stores the NFT that proves each user's qualifications or rights. This facilitates verification or authentication processing by the server.

[0204] (Configuration of NFT management system 1600) In this embodiment, the NFT management system 1600 includes, for example, one or more user terminals 150, one or more wallet providing servers 1620, one or more blockchain operation nodes 1630, and one or more service providing servers 1640. The NFT management system 1600 may include, for example, at least two selected from the group consisting of the user terminal 150, the wallet providing server 1620, the blockchain operation node 1630, and the service providing server 1640.

[0205] In this embodiment, each of the one or more blockchain operation nodes 1630 has, for example, one or more NFT databases 1632. In this embodiment, each of the one or more service providing servers 1640 has, for example, a communication control unit 1642 and an NFT verification unit 1644.

[0206] In this embodiment, the details of the NFT management system 1600 are described using as an example a case where the user terminal 150, wallet providing server 1620, and service providing server 1640 are configured to be able to access one or more NFT databases 1632 via the blockchain network 12. Furthermore, in this embodiment, the details of the NFT management system 1600 are described using as an example a case where the user terminal 150, wallet providing server 1620, and service providing server 1640 are configured to be able to send and receive information to and from each other via the communication network 14.

[0207] In this embodiment, the blockchain network 12 may have a configuration similar to that of the blockchain network 12 described in connection with the digital asset management system 100. In this embodiment, the communication network 14 may have a configuration similar to that of the communication network 14 described in connection with the digital asset management system 100.

[0208] In this embodiment, the user terminal 150 may have the same features as the user terminal 150 described in relation to the digital asset management system 100, in addition to the features described below, unless a technical inconsistency occurs. In this embodiment, the wallet providing server 1620 may have the same features as the wallet providing server 120 described in relation to the digital asset management system 100, in addition to the features described below, unless a technical inconsistency occurs.

[0209] (Outline of each part of the NFT Management System 1600) In this embodiment, the user terminal 150 differs from the user terminal 150 described in relation to the digital asset management system 100 in that the user terminal 150 generates the above-mentioned combined data in the wallet generation process of step 232 described in relation to Fig. 2. Except for the above differences, the user terminal 150 according to this embodiment may have the same configuration as the user terminal 150 described in relation to the digital asset management system 100. Details of the user terminal 150 according to this embodiment will be described later.

[0210] In this embodiment, the wallet providing server 1620 differs from the wallet providing server 120 described in relation to the digital asset management system 100 in that the wallet providing server 1620 has a function to issue NFTs. Except for the above differences, the wallet providing server 1620 may have a similar configuration to the wallet providing server 120 described in relation to the digital asset management system 100. Details of the wallet providing server 1620 will be described later.

[0211] In this embodiment, the blockchain operation node 1630 constitutes part of the blockchain network 12. As described above, the blockchain operation node 1630 stores the NFT database 1632. The blockchain operation node 1630 stores information in the NFT database 1632 and extracts information from the NFT database 1632 in response to an external request, for example.

[0212] In this embodiment, the NFT database 1632 stores one or more NFTs in association with the address of the owner or holder of each NFT. The NFT database 1632 may store, for each of the one or more NFTs, metadata of each NFT in association with the address of the owner or holder of each NFT. The NFT database 1632 may be a distributed ledger built using distributed ledger technology. Examples of NFT metadata include digital information such as a unique character string for the NFT and a URL for an image of the NFT.

[0213] In this embodiment, the service providing server 1640 provides various services. Examples of the above services include various matching services, intermediary or brokerage services, services provided based on credit information, services for members, and marketing services. Examples of services provided based on credit information include financial services and recruitment services. When authentication by NFT is performed using the NFT management system 1600, the provider of the above services may, for example, (i) provide services such as matching and marketing to users who are authenticated as owning a specific NFT, and (ii) not provide services such as matching and marketing to users who are not authenticated as owning the NFT. The provider of the above services may provide services such that the content, quality, quantity, etc. of the services provided to each user differ between users who are authenticated as owning a specific NFT and users who are not authenticated as owning the NFT.

[0214] The service providing server 1640 may verify whether or not a specific user 20 is the legitimate owner or holder of a specific NFT. The service providing server 1640 may decide whether or not to provide the above service based on the results of the above verification. For example, if the above verification determines that the specific user 20 is the legitimate owner or holder of a specific NFT, the service providing server 1640 may decide to provide the above service. On the other hand, if the above verification does not determine that the specific user 20 is the legitimate owner or holder of a specific NFT, the service providing server 1640 may decide not to provide the above service.

[0215] In this embodiment, the communication control unit 1642 controls, for example, communication between the service providing server 1640 and other information processing devices. In one embodiment, the communication control unit 1642 controls communication between the service providing server 1640 and the blockchain operation node 1630 via the blockchain network 12. In another embodiment, the communication control unit 1642 controls communication between the service providing server 1640 and the user terminal 150 and / or the wallet providing server 1620 via the communication network 14, for example.

[0216] The communication control unit 1642 may be configured to be able to access the NFT database 1632. For example, in response to a request from the NFT verification unit 1644, the communication control unit 1642 accesses the NFT database 1632 and extracts information that matches the request from the information stored in the NFT database 1632. The communication control unit 1642 may output the information extracted from the NFT database 1632 to the NFT verification unit 1644.

[0217] In this embodiment, the NFT verification unit 1644 verifies, for example, whether a specific user 20 is the legitimate owner or holder of a specific NFT. Based on the above verification result, the NFT verification unit 1644 may decide whether to provide the above-mentioned service. If it is decided to provide the above-mentioned service, the NFT verification unit 1644 may execute processing to provide the service. Details of the NFT verification unit 1644 will be described later.

[0218] (Specific configuration of each part of the NFT management system 1600) Each unit of the NFT management system 1600 may be realized by hardware, software, or both hardware and software. At least a portion of each unit of the NFT management system 1600 may be realized by a personal computer or a mobile terminal. The personal computer or mobile terminal may be used as a user interface for the NFT management system 1600. Examples of mobile terminals include mobile phones, smartphones, PDAs (registered trademarks), tablets, notebook computers or laptop computers, and wearable computers.

[0219] When at least some of the components constituting the NFT management system 1600 are realized by software, the components realized by the software may be realized by starting a program that defines the operations of the components in an information processing device with a general configuration. The information processing device may, for example, include (i) a data processing device having various processors (examples of the processor include a CPU, a GPU, etc.), a ROM, a RAM, a communication interface, etc., and (ii) a storage device (including an external storage device) such as a memory or HDD. The information processing device may also include (iii) input devices such as a keyboard, a touch panel, a camera, a microphone, various sensors, a GPS receiver, etc., and (iv) output devices such as a display device, a speaker, a vibration device, etc.

[0220] In the information processing device, the data processing device or storage device may store a program. For example, when the program is loaded into a computer, the information processing described in the program functions as a specific means in which software related to the program and various hardware resources that constitute at least a part of the NFT management system 1600 work together. Then, the specific means performs calculations or processing of information according to the intended use of the computer in this embodiment, thereby constructing the NFT management system 1600 or a part thereof according to the intended use.

[0221] The above program may be stored in a computer-readable medium. The above program may be stored in a non-transitory computer-readable recording medium. The above program may be stored in a computer-readable medium such as a CD-ROM, a DVD-ROM, a memory, or a hard disk, or may be stored in a storage device connected to a network. The above program may be installed in a computer that constitutes at least a part of the NFT management system 1600 from the computer-readable medium or the storage device connected to a network.

[0222] By executing the above program, the computer may function as at least a part of each unit of the NFT management system 1600. By executing the above program, the computer may execute an information processing method in at least a part of the NFT management system 1600.

[0223] A program for causing a computer to function as at least a part of the NFT management system 1600 includes, for example, a module that defines the operation of at least a part of the NFT management system 1600. When the above program or module is executed, the above program or module acts on a data processing device, an input device, an output device, a storage device, etc., to cause the computer to function as at least a part of the NFT management system 1600 or to execute an information processing method in at least a part of the NFT management system 1600.

[0224] The above information processing method, for example, includes a private key generation step of generating a private key associated with a non-fungible token (NFT). The above information processing method, for example, includes a storage information acquisition step of acquiring storage information, which is information regarding a storage location of the non-fungible token, from an issuing device that issues the non-fungible token via a communication network. The above information processing method, for example, includes a combined information generation step of generating combined information, which is information combining the private key and the storage information. Each step of the above information processing method is executed, for example, by a computer.

[0225] The NFT management system 1600 may be an example of a token management system. The user terminal 150 may be an example of an information processing device or a first device. The wallet providing server 1620 may be an example of an issuing device. The NFT database 1632 may be an example of a distributed ledger. The service providing server 1640 may be an example of a verification unit, verification device, information processing device, or second device. The communication control unit 1642 may be an example of an access control unit. The NFT verification unit 1644 may be an example of a verification unit, verification device, or information processing device.

[0226] The user terminal 150 may be an example of a communication terminal. The specific user 20 may be an example of a user or a first user. The specific NFT may be an example of a non-fungible token or a first non-fungible token.

[0227] (An example of another embodiment) In this embodiment, an example of the details of the NFT management system 1600 has been described using as an example a case where the input / output control unit 650 of the user terminal 150 generates various screens to be displayed on the display device of the input / output unit 624 and causes the above screens to be displayed on the display device of the input / output unit 624. However, the NFT management system 1600 is not limited to this embodiment. In other embodiments, the input / output control unit 650 may receive screen data generated by an external information processing device via the blockchain network 12 or the communication network 14, and control the input / output unit 624 to cause the above screens to be displayed on the display device of the input / output unit 624.

[0228] In this embodiment, the details of the NFT management system 1600 have been described using as an example a case where the NFT management system 1600 includes one or more wallet providing servers 1620, one or more blockchain operation nodes 1630, and one or more service providing servers 1640. However, the NFT management system 1600 is not limited to this embodiment. In other embodiments, the NFT management system 1600 may further include at least some of the functions or components of the digital asset management system 100. Similarly, the digital asset management system 100 may further include at least some of the functions or components of the NFT management system 1600.

[0229] 17 is a schematic diagram illustrating an example of information processing in the NFT management system 1600. Using FIG. 17, an example of processing in which a private key associated with an NFT is generated and the above-described combined data is output will be described.

[0230] According to this embodiment, first, in step 1720 (step may be abbreviated as S), the user terminal 150 sends information requesting the issuance of an NFT (sometimes referred to as an NFT issuance request) to the wallet providing server 1620. This initiates processing to receive the NFT issued by the wallet providing server 1620, using a wallet created in the memory area of ​​a browser running on the user terminal 150.

[0231] More specifically, first, the user 20 operates the user terminal 150 to log in to the digital asset management system 100. User authentication at the time of login is performed using, for example, the ID and password of the user 20.

[0232] If the above user authentication is successful, a screen prompting the user 20 to issue an NFT is presented on the user interface of the user terminal 150. The above screen displays, for example, information about the NFT to be issued, information about data associated with the NFT, and objects for causing the user terminal 150 to execute various processes. In this embodiment, the user 20 operates the user terminal 150 via the above screen to cause the user terminal 150 to execute a process for issuing an NFT.

[0233] Next, in S1730, a wallet is generated and activated to receive the NFT designated by user 20. This generates various data related to the wallet (sometimes referred to as wallet data). Examples of wallet data include a set of private and public keys, an address, etc.

[0234] Specifically, a private key associated with the NFT is generated. At this time, a public key corresponding to the private key is generated. In addition, an address of the user 20 in the blockchain network 12 is generated. The address is identification information associated with the private key and public key pair, and functions, for example, as a destination for digital assets in the blockchain network 12. After the wallet is generated, an activation process for the wallet may be executed, for example, using a procedure similar to that described in relation to FIG. 15. Through the activation process, the wallet providing server 1620 authenticates that the user 20 is the owner of the wallet linked to the public key.

[0235] The wallet generation process and activation process are performed, for example, according to the same procedures as those described in relation to Figures 2 and 7. While the wallet generation process and activation process are being performed, information indicating that the wallet data generation process is being performed may be presented on the user interface of user terminal 150.

[0236] In the wallet generation process, an input screen for a password or passphrase for encrypting part or all of the wallet data may be presented on the user interface of the user terminal 150. When a password or passphrase is input on the input screen, part or all of the wallet data may be encrypted.

[0237] Next, in S1742, S1744, and S1746, processing is executed to set ownership of the NFT to the address of the user 20. Specifically, in S1742, the wallet providing server 1620 derives the address of the user 20 from the public key authenticated by the validation processing. In addition, the wallet providing server 1620 associates a user ID for identifying the user 20 with the address of the user 20 and stores them in an appropriate storage device.

[0238] In S1744, the user 20 is notified that preparations for setting the user 20 as the holder of the NFT have been completed. Specifically, in S1744, the wallet providing server 1620 transmits a message indicating that preparations for setting the user 20 as the holder of the NFT have been completed to the user terminal 150 used by the user 20. The wallet providing server 1620 may also transmit a message indicating that the process of setting the user 20 as the holder of the NFT is progressing to the user terminal 150 used by the user 20.

[0239] When the computer of user terminal 150 receives the above message, the computer of user terminal 150 executes, for example, processing to generate a screen for presenting the above message and processing to display the screen on the display device of user terminal 150. As a result, for example, the screen displayed on the display device of user terminal 150 transitions from a screen indicating that wallet data is being created to a screen indicating that preparations for setting user 20 as an NFT holder are complete, or a screen indicating that processing to set user 20 as an NFT holder is in progress.

[0240] In S1746, various setting information related to the owner or holder of the NFT is updated. Specifically, a transaction is generated indicating that the address of user 20 is set to a value indicating the owner or holder of the NFT distributed to user 20. In addition, the transaction is issued from the wallet providing server 120 to the blockchain network 12. More specifically, the transaction is issued from the wallet providing server 120 to the blockchain network 12 via the blockchain operation server. The above process is sometimes referred to as Mint or Transfer.

[0241] Next, in S1748, the token storage destination data for the NFT is notified to the wallet. Specifically, the wallet providing server 1620 transmits the token storage destination data to the user terminal 150.

[0242] Next, in S1750, the browser of the user terminal 150 combines the wallet data and token storage destination data related to the NFT to generate combined data. The browser of the user terminal 150 may export the combined data to the wallet providing server 1620. This completes the process.

[0243] 18 schematically illustrates an example of information processing in the NFT management system 1600. Using FIG. 13, an example of processing for verifying whether a particular user 20 is the legitimate owner or holder of a particular NFT will be described.

[0244] According to this embodiment, first, in S1820, the user 20 determines at least one NFT (sometimes referred to as a target NFT) from among one or more NFTs owned or held by the user 20, for which the user 20 wishes to verify that the user 20 is the legitimate owner or holder of the NFT. The user 20 operates the user terminal 150 to send information (sometimes referred to as an NFT verification request) to the service providing server 1640 indicating a request for the above-mentioned verification of the target NFT.

[0245] Next, in S1830, the service providing server 1640 requests the user terminal 150 to transmit the data necessary for the above verification. In S1840, the user terminal 150 generates a digital signature using the private key included in the wallet data of the target NFT. The user terminal 150 provides the digital signature and the storage destination data included in the wallet data of the target NFT to the service providing server 1640.

[0246] Next, in S1850, the NFT verification unit 1644 of the service providing server 1640 accesses the NFT database 1632 according to the storage destination data acquired from the user terminal 150. The NFT verification unit 1644, for example, refers to the NFT database 1632 to acquire the address of the legitimate owner or holder of the target NFT.

[0247] This allows the NFT verification unit 1644 to confirm the setting information related to the legitimate owner or holder of the target NFT. Specifically, the NFT verification unit 1644 verifies the digital signature of the target NFT and restores the public key from the digital signature. The NFT verification unit 1644 also derives an address from the public key. The NFT verification unit 1644 compares the address obtained by referring to the NFT database 1632 with the address derived from the public key.

[0248] If the two match, the NFT verification unit 1644 determines that the user 20 is the legitimate owner or holder of the target NFT. If the two do not match, the NFT verification unit 1644 determines that the user 20 is not the legitimate owner or holder of the target NFT. This ends the process.

[0249] FIG. 19 schematically illustrates an example of an electronic file 1900. In this embodiment, the electronic file 1900 includes storage destination data 1920 and wallet data 1940. In this embodiment, the storage destination data 1920 includes ledger type information indicating the type of distributed ledger that stores the NFT, ledger identification information for uniquely identifying the distributed ledger, and token identification information for uniquely identifying the NFT in the distributed ledger. In this embodiment, a contract address and a token ID are used as the token identification information. The electronic file 1900 may be an example of combined data.

[0250] FIG. 20 schematically illustrates an example of an electronic file 2000. In this embodiment, the electronic file 2000 includes authentication target data 2020 and encoded data 2040. The authentication target data 2020 indicates the content of data associated with the NFT. The encoded data 2040 may be encoded data indicating combined data of the NFT. Examples of types of encoded data include a barcode and a QR code (registered trademark). The electronic file 2000 may be an example of combined data.

[0251] 21 schematically illustrates an example of the internal configuration of the wallet providing server 1620. In this embodiment, the wallet providing server 1620 includes, for example, an application providing unit 320, a wallet authenticating unit 330, a token distributing unit 2120, and a user database 2130.

[0252] The application providing unit 320 may have a configuration similar to that of the application providing unit 320 described in relation to the digital asset management system 100. The wallet authenticating unit 330 may have a configuration similar to that of the wallet authenticating unit 330 described in relation to the digital asset management system 100.

[0253] In this embodiment, the token distributor 2120 issues an NFT. In this embodiment, the user database 2130 stores a user ID and an address for each of one or more users 20 in association with each other.

[0254] 22 schematically illustrates an example of the internal configuration of the NFT verification unit 1644. In this embodiment, the NFT verification unit 1644 includes, for example, a verification target acquisition unit 2220, a ledger information acquisition unit 2230, and a determination unit 2240.

[0255] In this embodiment, the verification target acquisition unit 2220 acquires various pieces of information to be verified. For example, the verification target acquisition unit 2220 acquires storage destination data for the target NFT and a digital signature related to the address of the user 20 from the user terminal 150 of the user 20. In this embodiment, the ledger information acquisition unit 2230 accesses the NFT database 1632 and acquires information indicating the address associated with the target NFT in the NFT database 1632 (sometimes referred to as address information).

[0256] In this embodiment, the determination unit 2240 compares the address indicated by the digital signature with the address indicated by the address information. Based on the comparison result, the determination unit 2240 determines whether the user 20 is the legitimate owner or holder of the target NFT.

[0257] 23 schematically illustrates an example of the wallet generation unit 642 and wallet execution unit 644. In the case where the user terminal 150 constitutes part of the NFT management system 1600, the wallet generation unit 642 includes, for example, a private key generation unit 2322, a storage destination data acquisition unit 2324, and a combined data generation unit 2326. Similarly, the wallet execution unit 644 includes, for example, an address acquisition unit 2342, a signature generation unit 2344, and a verification request unit 2346.

[0258] In this embodiment, the private key generation unit 2322 generates a private key associated with the NFT. The NFT may be a non-transferable non-fungible token (SBT). In this embodiment, the storage location data acquisition unit 2324 acquires storage location data for the NFT from the service providing server 1640 via the communication network 14. In this embodiment, the combined data generation unit 2326 combines the private key and the storage location data to generate combined data. The combined data generation unit 2326 may output a single electronic file including the combined data.

[0259] In this embodiment, the address acquisition unit 2342 acquires the address of the user 20 related to the target NFT. As described above, the address is generated based on a public key corresponding to a private key. In this embodiment, the signature generation unit 2344 uses the private key to generate a digital signature related to the address of the user 20.

[0260] In this embodiment, the verification request unit 2346, for example, transmits the above-described NFT verification request to the service providing server 1640. The verification request unit 2346, for example, transmits the electronic signature and storage location data of the target NFT in association with each other to the service providing server 1640, which verifies whether the user 20 is the legitimate owner or holder of the target NFT.

[0261] The storage destination data acquisition unit 2324 may be an example of a storage information acquisition unit, the combined data generation unit 2326 may be an example of a combined information generation unit, and the verification request unit 2346 may be an example of a transmission unit.

[0262] 24 schematically shows an example of a screen 2400 output from the input / output unit 624. The screen 2400 is used, for example, by the control unit 630 or the browser execution unit 640 to receive an instruction input from the user 20 to start the execution of the NFT transfer process. For example, in the above-described S1750, when the browser of the user terminal 150 generates the combined data, the control unit 630 or the browser execution unit 640 determines that the screen 2400 is to be displayed on the display device of the input / output unit 624. The screen 2400 is generated, for example, by the input / output control unit 650 and displayed on the display device of the input / output unit 624.

[0263] In this embodiment, the screen 2400 includes an object 2420. The combined data of the NFT to be transferred is embedded as a parameter in the URL of the link of the object 2420. The object 2420 may be an example of the NFT transfer object described above.

[0264] As described above, the combined data is embedded as a parameter in the URL of the link to the NFT transfer object. The combined data is embedded, for example, in the query string of the URL. As described above, for example, a URL in which the combined data indicating that the ledger type (chainType) is Ethereum, the ledger identifier (networkId) is 1 (1 indicates the mainnet), the address of the smart contract issuing the NFT (contractAddress) is 0x16... (omitted), the token identifier (tokenId) is 9, and the wallet data (encryptedWallet) is 0x16... (omitted) is embedded as part of the URL parameters is represented as, for example, "https: / / abcwallet123.com / ?chainType=Ethereum&networkId=1&contractAddress=0x16...&tokenId=9&encryptedWallet=0x14...".

[0265] According to this embodiment, when user 20 operates user terminal 150 and clicks object 2420 on screen 2400, for example, browser execution unit 640 launches the wallet application of user terminal 150. When the wallet application of user terminal 150 launches, the wallet application causes the computer of user terminal 150 to execute processing to transfer the combined data of the NFTs that are the subject of the transfer process as electronic data to the recipient's wallet application.

[0266] Specifically, the wallet application of user terminal 150 (i) causes the computer of user terminal 150 to execute processing to analyze the URL of the link to object 2420 and obtain the combined data embedded in the URL, and (ii) processing to import the combined data into the recipient's wallet application. The recipient's wallet application automatically sets token configuration information based on the NFT storage destination data included in the imported combined data. As a result, the NFT managed by the wallet application of user terminal 150 is transferred from the wallet application of user terminal 150 to the wallet application of the recipient without going through a transaction.

[0267] 25 shows an example of a computer 3000 in which multiple aspects of the present invention may be embodied in whole or in part. At least a portion of the digital asset management system 100 may be realized by the computer 3000. For example, at least a portion of the wallet providing server 120 is realized by the computer 3000. For example, at least a portion of the wallet audit server 130 is realized by the computer 3000. For example, at least a portion of the audit result database 140 is realized by the computer 3000. For example, at least a portion of the user terminal 150 is realized by the computer 3000.

[0268] A program installed on the computer 3000 can cause the computer 3000 to function as or perform operations associated with an apparatus according to an embodiment of the present invention or one or more "parts" of the apparatus, and / or to perform a process or steps of the process according to an embodiment of the present invention. Such a program can be executed by the CPU 3012 to cause the computer 3000 to perform specific operations associated with some or all of the blocks of the flowcharts and block diagrams described herein.

[0269] A computer 3000 according to this embodiment includes a CPU 3012, a RAM 3014, a graphics controller 3016, and a display device 3018, which are interconnected by a host controller 3010. The computer 3000 also includes input / output units such as a communication interface 3022, a hard disk drive 3024, a DVD-ROM drive 3026, and an IC card drive, which are connected to the host controller 3010 via an input / output controller 3020. The computer also includes legacy input / output units such as a ROM 3030 and a keyboard 3042, which are connected to the input / output controller 3020 via an input / output chip 3040.

[0270] The CPU 3012 operates according to programs stored in the ROM 3030 and RAM 3014, thereby controlling each unit. The graphics controller 3016 acquires image data generated by the CPU 3012 into a frame buffer or the like provided in the RAM 3014 or into the graphics controller 3016 itself, and causes the image data to be displayed on the display device 3018.

[0271] The communication interface 3022 communicates with other electronic devices via a network. The hard disk drive 3024 stores programs and data used by the CPU 3012 in the computer 3000. The DVD-ROM drive 3026 reads programs or data from the DVD-ROM 3001 and provides the programs or data to the hard disk drive 3024 via the RAM 3014. The IC card drive reads programs and data from an IC card and / or writes programs and data to an IC card.

[0272] The ROM 3030 stores therein a boot program or the like that is executed by the computer 3000 upon activation, and / or programs that depend on the hardware of the computer 3000. The input / output chip 3040 may also connect various input / output units to the input / output controller 3020 via a parallel port, a serial port, a keyboard port, a mouse port, etc.

[0273] The programs are provided by a computer-readable storage medium such as a DVD-ROM 3001 or an IC card. The programs are read from the computer-readable storage medium, installed in the hard disk drive 3024, RAM 3014, or ROM 3030, which are also examples of computer-readable storage media, and executed by the CPU 3012. The information processing described in these programs is read by the computer 3000, and brings about cooperation between the programs and the various types of hardware resources described above. An apparatus or method may be configured by implementing operations or processing of information in accordance with the use of the computer 3000.

[0274] For example, when communication is performed between computer 3000 and an external device, CPU 3012 may execute a communication program loaded into RAM 3014 and instruct communication interface 3022 to perform communication processing based on the processing described in the communication program. Under the control of CPU 3012, communication interface 3022 reads transmission data stored in a transmission buffer area provided in RAM 3014, hard disk drive 3024, DVD-ROM 3001, or a recording medium such as an IC card, and transmits the read transmission data to the network, or writes received data received from the network to a reception buffer area or the like provided on the recording medium.

[0275] Furthermore, CPU 3012 may cause all or a necessary portion of a file or database stored on an external recording medium such as hard disk drive 3024, DVD-ROM drive 3026 (DVD-ROM 3001), IC card, etc. to be read into RAM 3014, and may perform various types of processing on the data on RAM 3014. CPU 3012 may then write back the processed data to the external recording medium.

[0276] Various types of information, such as various types of programs, data, tables, and databases, may be stored on the recording medium and subjected to information processing. The CPU 3012 may perform various types of processing on data read from the RAM 3014, including various types of operations, information processing, conditional judgment, conditional branching, unconditional branching, information search / replacement, etc., as described throughout this disclosure and specified by the instruction sequences of the programs, and write the results back to the RAM 3014. The CPU 3012 may also search for information in a file, database, etc. on the recording medium. For example, if multiple entries, each having an attribute value of a first attribute associated with an attribute value of a second attribute, are stored on the recording medium, the CPU 3012 may search for an entry whose attribute value of the first attribute matches a specified condition from among the multiple entries, read the attribute value of the second attribute stored in the entry, and thereby obtain the attribute value of the second attribute associated with the first attribute that satisfies a predetermined condition.

[0277] The above-described programs or software modules may be stored in a computer-readable storage medium on or near the computer 3000. A recording medium such as a hard disk or RAM provided in a server system connected to a dedicated communication network or the Internet can also be used as a computer-readable storage medium, thereby providing the above-described programs to the computer 3000 via the network.

[0278] The blocks in the flowcharts and block diagrams in the above embodiments may represent stages of a process in which an operation is performed or "parts" of an apparatus responsible for performing the operation. Particular stages and "parts" may be implemented by dedicated circuitry, programmable circuitry provided with computer-readable instructions stored on a computer-readable storage medium, and / or a processor provided with computer-readable instructions stored on a computer-readable storage medium. The dedicated circuitry may include digital and / or analog hardware circuits, including integrated circuits (ICs) and / or discrete circuits. The programmable circuitry may include reconfigurable hardware circuits, such as field programmable gate arrays (FPGAs) and programmable logic arrays (PLAs), including AND, OR, XOR, NAND, NOR, and other logical operations, flip-flops, registers, and memory elements.

[0279] A computer-readable storage medium may include any tangible device capable of storing instructions that are executed by an appropriate device, such that a computer-readable storage medium having instructions stored thereon comprises an article of manufacture, including instructions that can be executed to create means for performing the operations specified in the flowcharts or block diagrams. Examples of computer-readable storage media may include electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, etc. More specific examples of computer-readable storage media may include floppy disks, diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc, memory stick, integrated circuit card, etc.

[0280] The computer readable instructions may include either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, JAVA®, C++, etc., and conventional procedural programming languages ​​such as the “C” programming language or similar programming languages.

[0281] Computer-readable instructions may be provided locally or over a wide area network (WAN) such as a local area network (LAN), the Internet, etc. to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, or programmable circuitry, such that the processor or programmable circuitry executes the computer-readable instructions to generate means for performing the operations specified in the flowcharts or block diagrams. Examples of processors include computer processors, processing units, microprocessors, digital signal processors, controllers, microcontrollers, etc.

[0282] Although the present invention has been described above using embodiments, the technical scope of the present invention is not limited to the scope described in the above embodiments. It will be apparent to those skilled in the art that various modifications and improvements can be made to the above embodiments. Furthermore, the details described for a particular embodiment can be applied to other embodiments to the extent that they are not technically inconsistent. Furthermore, each component may have the same features as other components with the same name but different reference numerals. It is apparent from the claims that such modifications and improvements can also be included within the technical scope of the present invention.

[0283] It should be noted that the execution order of each process, such as operations, procedures, steps, and stages, in the devices, systems, programs, and methods shown in the claims, specifications, and drawings is not specifically stated as "before," "prior to," etc., and that the processes can be performed in any order unless the output of a previous process is used in a subsequent process. Even if the operational flow in the claims, specifications, and drawings is described using "first," "next," etc. for convenience, this does not mean that the processes must be performed in this order.

[0284] For example, the present specification discloses the following: (Item 1) an execution control unit that controls an execution device that executes a management program that is a program for causing a computer to function as a private key management device that manages private keys used in encrypting digital data; an inspection information acquisition unit that accesses an inspection information storage device that stores inspection information indicating the results of inspections by a third party regarding the security of the management program or the private key management device, and acquires the inspection information; Equipped with The execution control unit When the inspection information acquisition unit acquires the inspection information indicating that safety has been confirmed by the inspection, it determines whether to permit or not restrict execution of the management program; When the inspection information acquisition unit does not acquire the inspection information indicating that safety has been confirmed by the inspection, it determines not to permit or to restrict execution of the management program. Information processing system. (Item 2) the inspection information storage device stores the inspection information in association with encoded data in which at least a part of the management program that was the subject of the inspection is encoded; the inspection information acquisition unit acquires the inspection information and the encoded data, The execution control unit acquiring verification data obtained by encoding at least a portion of the management program to be executed by the execution device; the inspection information acquisition unit acquires the inspection information indicating that safety has been confirmed by the inspection, and when the verification data matches the encoded data acquired by the inspection information acquisition unit, determines whether to permit or not restrict execution of the management program; If the inspection information acquisition unit does not acquire the inspection information indicating that safety has been confirmed by the inspection, or if the verification data does not match the encoded data acquired by the inspection information acquisition unit, determining not to permit or to restrict execution of the management program. Item 1. An information processing system according to item 1. (Item 3) the procedure for causing the computer to function as the private key management device includes a generation procedure for generating the private key and a public key corresponding to the private key; The encoded data includes generation procedure encoded data in which a code, script, or program corresponding to at least a part of the generation procedure is encoded. Item 2. An information processing system according to item 2. (Item 4) The execution device a program acquisition unit that acquires the management program that is to be executed; a program output unit that outputs, to the execution control unit, at least a portion of the management program acquired by the program acquisition unit or the verification data obtained by encoding at least a portion of the management program; Equipped with Item 2. An information processing system according to item 2. (Item 5) an inspection unit that inspects the safety of the management program; an encoded data generation unit that encodes at least the part of the management program inspected by the inspection unit to generate the encoded data; a registration unit that associates the identification information and / or URI of the management program with the encoded data and registers the association information and / or URI of the management program in the examination information storage device; Further provided with Item 2. An information processing system according to item 2. (Item 6) The execution device further includes: The execution device If the execution control unit permits or does not restrict the execution of the management program, the execution control unit executes the management program, If the execution control unit does not permit the execution of the management program, the management program is not executed, When the execution control unit restricts the execution of the management program, at least a part of the management program is not executed. Item 1. An information processing system according to item 1. (Item 7) a program acquisition unit that acquires a management program that causes a computer to function as a private key management device that manages private keys used in encrypting digital data; a control information acquisition unit that acquires the control information from a determination device that determines whether the safety of the management program or the private key management device has been confirmed by referring to inspection information that indicates the results of an inspection by a third party regarding the safety of the management program or the private key management device, and outputs control information that indicates whether execution of the management program is permitted or not restricted if the safety has been confirmed; a program execution unit that executes the management program in accordance with the control information; An information processing system comprising: (Item 8) A program for causing a computer to function as the information processing system according to any one of items 1 to 7. [Explanation of symbols]

[0285] 12 Blockchain Network 14. Communication Networks 20 users 100 Digital Asset Management Systems 120 Wallet provider server 130 Wallet Audit Server 140 Audit Results Database 150 user terminals 320 Application Provider 330 Wallet Authentication Unit 420 Audit Request Acquisition Unit 430 Application Acquisition Department 440 Audit Department 450 Audit Results Registration Department 622 Communications Department 624 Input / output section 626 Storage Unit 630 Control Unit 640 Browser execution unit 642 Wallet Generation Unit 644 Wallet Execution Department 646 Restricted Section 650 Input / Output Control Unit 660 Communication Control Unit 800 screens 820 Browser display area 840 Wallet display area 842 objects 844 objects 862 objects 864 objects 900 screens 966 objects 1000 screens 1066 objects 1600 NFT Management Systems 1620 Wallet provider server 1630 Blockchain Operation Nodes 1632 NFT database 1640 Service provider server 1642 Communication control section 1644 NFT Verification Department 1900 Electronic Files 2000 Electronic File 1920 Storage Data 1940 Wallet Data 2020 Certified Data 2040 encoded data 2120 Token Distribution Department 2130 User Database 2220 Verification target acquisition unit 2230 Ledger Information Acquisition Unit 2240 Judgment section 2322 Private key generation section 2324 Storage Data Acquisition Department 2326 Combined Data Generation Unit 2342 Address Acquisition Unit 2344 Signature generator 2346 Verification Request Section 2400 screen 2420 Objects 3000 computers 3001 DVD-ROM 3010 host controller 3012 CPU 3014 RAM 3016 Graphics Controller 3018 Display Device 3020 Input / Output Controller 3022 Communication Interface 3024 hard disk drive 3026 DVD-ROM drive 3030 ROM 3040 I / O chip 3042 keyboard

Claims

1. A private key generation unit that generates a private key associated with a non-fungible token (NFT); A storage information acquisition unit that acquires storage information, which is information regarding a storage location of the non-fungible token, from an issuing device that issues the non-fungible token via a communication network; a combined information generating unit that generates combined information that is information in which the private key and the storage information are combined; An information processing device comprising:

2. The storage information is Ledger type information indicating the type of distributed ledger that stores the non-fungible token; Ledger identification information for uniquely identifying the distributed ledger; and Token identification information for uniquely identifying the non-fungible token in the distributed ledger; and Including, The information processing device according to claim 1 .

3. The combination information generating unit outputs a single electronic file including the combination information. The information processing device according to claim 1 .

4. a screen generating unit configured to generate a screen having an object in which a URL including the binding information is embedded as a part of a URL parameter; The information processing device according to claim 1 .

5. an address acquisition unit that acquires an address of a user of the information processing device; a signature generation unit that generates an electronic signature for the address of the user using the private key; A transmission unit that transmits the electronic signature and the storage information in association with each other to a verification device that verifies whether the user is a legitimate owner or holder of the non-fungible token; Further equipped with The address is generated based on a public key corresponding to the private key. The information processing device according to claim 1 .

6. An access control unit configured to be able to access a distributed ledger that stores one or more non-fungible tokens (NFTs) in association with the addresses of owners or holders of each non-fungible token; a verification unit that verifies whether the first user is a legitimate owner or holder of the first non-fungible token; Equipped with The verification unit is A verification target acquisition unit that acquires, from a communication terminal used by the first user, first storage information, which is information regarding a storage location of the first non-fungible token, and an electronic signature regarding the address of the first user; A ledger information acquisition unit that accesses the distributed ledger and acquires address information indicating an address associated with the first non-fungible token in the distributed ledger; A determination unit that compares the address indicated by the electronic signature with the address indicated by the address information to determine whether the first user is a legitimate owner or holder of the first non-fungible token; having Information processing device.

7. A first device which is the information processing device according to any one of claims 1 to 6; A second device which is the information processing device according to claim 6; A token management system comprising:

8. A program for causing a computer to function as the information processing device according to any one of claims 1 to 6.

Images