Security token management system, security token management method, and program

Abstract

To allow use of a security token while ensuring the security of a secret key.SOLUTION: A security token management system includes an information acquisition unit that acquires transactor information about a first user who desires to acquire a security token for a financial product and a financier who manages the financial product, a generation unit that generates a secret key and a wallet address of a transactor in order to issue a security token, an output unit that outputs information indicating the secret key to a printing device, an issuance request acquisition unit that acquires a request for issuance of the security token, a transmission unit that transmits, to the first user, financier's approval information about issuance of the security token to the first user, an input unit that, when the approval information is transmitted to the first user, accepts operation input concerning the secret key from a prescribed input person based on the information indicating the secret key, and an issuance unit that performs a process of issuing, on a block chain, the security token to the wallet address of the first user on the basis of the secret key accepted by the input unit.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a security token management system, a security token management method, and a program. [Background technology]

[0002] A system for issuing and transferring tokens based on financial products on a blockchain has been disclosed (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent Publication No. 2021-12460 Summary of the Invention [Problem to be solved by the invention]

[0004] The system described in Patent Document 1 uses blockchain to enable trading of tokens based on financial products, ensuring the liquidity of financial products. This system can provide a platform that allows many financial products to be handled as security tokens. By using blockchain based on distributed ledger technology, it is possible to raise funds from a diverse range of investors in addition to traditional fundraising methods (such as stocks).

[0005] A security token is a digitalized financial product based on securities, etc. The Financial Instruments and Exchange Act requires that security tokens be managed in a "secure and orderly manner" (Article 43-2 of the Financial Instruments and Exchange Act).

[0006] "Manage securely and orderly" includes recording and managing the information necessary to transfer financial value (security tokens) on electronic devices, electromagnetic recording media, or other recording media that are not constantly connected to the Internet (Article 136, Paragraph 1, Item 5 (b) of the Cabinet Office Ordinance on Financial Instruments and Exchange Business, etc.).

[0007] "Information necessary to transfer security tokens" includes the private key used to encrypt transactions when trading security tokens.

[0008] Recently, with the provision of systems that enable the trading of digital assets, ensuring information security is particularly important. In security token transactions, each user has a "wallet address" as their own account information on the blockchain. When trading digital assets using this wallet address, encryption technology (signature) using public key cryptography is used. The private key used for signing is used to manipulate the transaction information in the wallet address, so it must be kept strictly confidential and managed and protected.

[0009] This private key management method can be broadly divided into "hot wallets" and "cold wallets." A hot wallet is a method in which private keys are managed while connected to the Internet. A cold wallet is a method in which private keys are managed while isolated from the Internet.

[0010] In a hot wallet, the hardware that stores the private keys is always connected to the network. This makes it easy to retrieve the private keys required for transactions, allowing digital asset transactions to be carried out relatively quickly. However, because the hardware of a hot wallet is connected to the network, there is a relatively high risk that the private keys will be leaked due to external hacking.

[0011] A cold wallet is a method of storing private keys on media that is not connected to a network. Therefore, with a cold wallet, it is necessary to retrieve private key information from the storage location each time a transaction is made. On the other hand, because cold wallets are not connected to a network, the risk of private keys being leaked is relatively low.

[0012] As described above, it is desirable for systems that handle digital assets to provide a configuration and mechanism that enhances the security of private keys while employing an appropriate private key management method.

[0013] In this regard, the system described in Patent Document 1 ensures the liquidity of financial products by making tokens based on financial products tradable, but there is a risk that it may not be possible to ensure the security of private keys required for trading digital assets and conduct transactions safely.

[0014] Therefore, an object of the present invention is to provide a system that enables handling of security tokens while ensuring the security of private keys. [Means for solving the problem]

[0015] A security token management system according to one aspect of the present invention includes an information acquisition unit that acquires trader information from a trader who is a trader trading security tokens based on financial products and who wishes to acquire the security token, the trader information being information about a first user who wishes to acquire the security token, a financial institution that manages the financial product, or a system provider that enables trading of the security token; a generation unit that generates a private key and wallet address of the trader for issuing the security token based on the trader information; an output unit that outputs printing information to a printing device for printing information indicating the private key or displays the private key on a display unit; and a security token issuance request from the first user. a transmission unit that transmits to the first user consent information indicating that the financial service provider has consented to the issuance of the security token to the first user based on the issuance request; an input unit that, when the consent information is transmitted to the first user, accepts an operation input regarding the private key by a predetermined inputter based on information indicating the private key printed by the printing device or information indicating the private key displayed on the display unit and transcribed onto a paper medium by a human; and an issuing unit that executes a process to issue the security token to the wallet address of the first user on a blockchain based on the private key accepted by the input unit.

[0016] A security token management system according to one aspect of the present invention includes an information acquisition unit that acquires trader information from a trader who is a trader conducting a trade of a security token based on a financial product and who wishes to acquire the security token, the trader information being information about a first user who wishes to acquire the security token, a financial institution that manages the financial product, or a system provider of a system that enables trading of the security token; a generation unit that generates a wallet address of the trader based on the trader information; an issuance request acquisition unit that acquires an issuance request for the security token from the first user; a transmission unit that transmits to the first user consent information indicating that the financial institution has consented to the issuance of the security token to the first user based on the issuance request; The system includes an input unit that accepts operational input regarding the private key by a specified inputter based on information indicating the private key printed by a printing device based on a printing request to print information indicating the private key output from the private key generation device to a printing device in response to an operational input by the financial institution to a private key generation device that generates a private key for issuing the security token when sent to a first user, or information indicating the private key displayed on a display unit that has been transcribed onto a paper medium by a person based on information for displaying the private key output from the private key generation device to a display unit; and an issuance unit that executes a process to issue the security token to the wallet address of the first user on a blockchain based on the private key accepted by the input unit.

[0017] A security token management method according to one aspect of the present invention includes a computer that acquires trader information from a trader who is a trader of a security token based on a financial product and who wishes to acquire the security token, the trader being information about a first user who wishes to acquire the security token, a financial institution that manages the financial product, or a system provider that enables trading of the security token; generating a private key and wallet address for the trader based on the trader information in order to issue the security token; outputting print information to a printing device for printing information indicating the private key or displaying the private key on a display; and transmitting a request for issuance of the security token to the first user. and, when the consent information is sent to the first user, accepting operational input regarding the private key by a predetermined input person based on information indicating the private key printed by the printing device or information indicating the private key displayed on the display unit and transcribed onto a paper medium by a person, and executing a process to issue the security token to the wallet address of the first user on a blockchain based on the private key accepted by the operational input of the predetermined input person.

[0018] A program according to one aspect of the present invention causes a computer to acquire trader information from a trader who is a trader trading security tokens based on financial products and who wishes to acquire the security token, the trader being information about a first user who wishes to acquire the security token, a financial institution that manages the financial product, or a system provider of a system that enables trading of the security token; generate a private key and wallet address of the trader for issuing the security token based on the trader information; output print information to a printing device for printing information indicating the private key, or display the private key on a display unit; and acquire a request for issuance of the security token from the first user. sending to the first user consent information indicating that the financial service provider has consented to the issuance of the security token to the first user based on the issuance request; when the consent information has been sent to the first user, accepting operational input regarding the private key by a specified input person based on information indicating the private key printed by the printing device or information indicating the private key displayed on the display unit and transcribed onto a paper medium by a person; and executing a process to issue the security token to the wallet address of the first user on a blockchain based on the private key accepted by the operational input of the specified input person. [Effects of the Invention]

[0019] According to the present invention, it is possible to provide a system that enables handling of security tokens while ensuring the security of private keys. [Brief explanation of the drawings]

[0020] [Figure 1] FIG. 1 illustrates an example of the configuration of a security token management system. [Figure 2] 2 is a diagram illustrating an example of the functional configuration of each device included in the security token management system according to the first embodiment. FIG. [Figure 3]FIG. 10 is a diagram showing a trader information database D106. [Figure 4] FIG. 3 is a diagram showing a flow of security token issuing processing according to the first embodiment. [Figure 5] FIG. 10 is a diagram showing a flow of a forced transfer process of a security token according to the first embodiment. [Figure 6] FIG. 10 is a diagram illustrating an example of the functional configuration of each device included in a security token management system according to a second embodiment. [Figure 7] FIG. 10 is a diagram showing a flow of security token issuing processing according to the second embodiment. [Figure 8] FIG. 2 illustrates an example of a hardware configuration of a computer. DETAILED DESCRIPTION OF THE INVENTION

[0021] ===Security Token Management System 10 According to the First Embodiment=== <<System Overview>> An overview of a security token management system 10 according to the first embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the configuration of the security token management system 10 according to the first embodiment.

[0022] The security token management system 10 is a system that enables the handling of security tokens that have certain requirements, using the private key of the trader, which is managed so that it cannot be obtained through the network, in order to issue security tokens to users on the blockchain.

[0023] A security token is a digitized financial product based on securities, etc., which is displayed as a property value that can be transferred using an electronic data processing system (Article 1, Paragraph 4, Item 17 of the Cabinet Office Ordinance on Financial Instruments and Exchange Business, etc.). Security tokens are applicable to, for example, stocks, corporate bonds, promissory notes, checks, etc. Note that the security token in this embodiment is subject to acquirer requirements for handling, and refers to so-called "electronically recorded transfer rights" (Article 2, Paragraph 2, each item of the Financial Instruments and Exchange Act), such as trust beneficiary rights and collective investment scheme interests.

[0024] A trader is a person who trades security tokens based on financial products. A trader may be, for example, a user, a financial institution, or a system provider.

[0025] A user is, for example, an investor who wishes to acquire a security token. The security token management system 10 may issue a security token to a user who meets certain requirements for acquiring a security token (hereinafter referred to as "acquirer requirements").

[0026] Acquirer requirements refer to the conditions that users must meet in order to handle security tokens. Specifically, they refer to the acquirer restrictions (Article 29-5, Paragraph 3, etc. of the Financial Instruments and Exchange Act) for security tokens (electronically recorded transfer rights) that fall under the category of Paragraph 1 securities as defined in Article 2, Paragraph 1 of the Financial Instruments and Exchange Act.

[0027] The acquirer requirements are not limited to the above, and may be, for example, restrictions on the handling of tokens as stipulated in Article 9-2, Paragraph 1, Item 1 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act. Specifically, this means that no one other than those listed in Article 9-2, Paragraph 1, Item 1 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act can acquire the tokens (this falls under the category of so-called "exempt electronic record transfer rights").

[0028] A financial institution is an entity that issues security tokens, and includes, for example, a business company that raises funds, an investment management company (including an asset management company), and a financial instruments business operator (such as a securities company). Note that a financial institution may also manage the private keys required to issue security tokens.

[0029] A system provider is a business that provides or operates a system (here, security token management system 10) that enables the trading of security tokens, and is, for example, a business that builds the system and makes it available to users and financial institutions.

[0030] The private key is information required in the security token management system 10 to carry out each security token transaction (issuance process and forced transfer process, which will be described later) at a wallet address. In other words, the private key is the only information that enables security token transactions at a wallet address. Specifically, the private key is key information in the public key cryptography used in the blockchain BN. Note that the security token management system 10 may use "digital signatures," which are a type of public key cryptography, when conducting transactions using the blockchain.

[0031] A digital signature is a technology that certifies the creator of digital information. By using a private key to create a digital signature, it is possible to prove that "the data was created by the signer" and "the data has not been tampered with."

[0032] Here, the private key in the security token management system 10 is managed by a medium that is not connected to a network.

[0033] Specifically, the security token management system 10 may use a so-called paper wallet method among cold wallets to manage the private key. In this case, the security token management system 10, for example, outputs information for printing information indicating the private key (hereinafter referred to as "printed information") to a printing device, and stores a paper medium indicating the private key (hereinafter referred to as "private key paper medium") (information indicating the private key) printed out from the printing device. Note that the security token management system 10 may, for example, display the information indicating the private key on a display unit. In this case, the person in charge transcribes the information indicating the private key displayed on the display unit onto paper, thereby generating the private key paper medium.

[0034] The management of private keys is not limited to the paper wallet method. For example, private keys may be stored in the hardware of a device that is not connected to other devices for communication (a so-called hardware wallet).

[0035] In hardware wallets, private key information is stored on a USB (Universal Serial Bus) type storage medium or a card-type storage medium, for example. Hardware wallets have the advantage of being able to consolidate multiple pieces of information into a single compact storage medium.

[0036] In the following, as an example, the management of private keys will be described by adopting a paper wallet method in which private keys are managed on paper media.

[0037] The private key paper medium is managed in a storage area such as a safe of a financial institution, which is an area that cannot be accessed by anyone other than those with specific authority.

[0038] In this way, the security token management system 10 manages information related to the private key without storing it in hardware within the system. In the security token management system 10, when a request is made for the issuance of a security token that has an acquirer requirement, a financial institution employee retrieves a private key paper medium corresponding to the transaction from a storage area (such as a safe) and uses the private key. In addition, when a request is made for the issuance of a security token that has an acquirer requirement, a system provider employee may retrieve a private key paper medium corresponding to the transaction from the storage area and use the private key. In other words, the financial institution employee and the system provider employee may retrieve, for example, the user's private key, the financial institution employee's private key, or the system provider's private key from the storage area and use it.

[0039] As a result, the security token management system 10 can properly store the private key paper medium without the user having to store it themselves, thereby reducing the burden on the user of managing the private key and ensuring the convenience of security token transactions.

[0040] <<Configuration Overview>> First, an outline of the configuration of the security token management system 10 will be described.

[0041] 1, the security token management system 10 includes, for example, a token management device 100, a user terminal 200, a financial business operator terminal 300, and a system provider terminal 400. The security token management system 10 may also include a printing device, which will be described later.

[0042] The devices constituting the security token management system 10 are communicably connected to one another via a communication network N. The communication network N is a communication network or a wireless network. Although not shown, the security token management system 10 may be configured with multiple user terminals 200.

[0043] The token management device 100 is a device that generates a wallet address and private key of a trader who trades security tokens based on information about the trader (hereinafter referred to as "trader information"). Here, when the token management device 100 receives a request to issue a security token from a user who wishes to acquire a security token, it accepts information about the trader's private key from a financial institution or system provider. Then, based on the trader's private key, the token management device 100 executes a contract to issue a security token to the user's wallet address on the blockchain BN.

[0044] Specifically, the token management device 100 may generate a wallet address and a private key for a user based on, for example, information about the user who wishes to acquire a security token (hereinafter referred to as "user information"). In this case, the token management device 100 may execute a contract to issue a security token to the user's wallet address on the blockchain BN by, for example, accepting an operation input of the user's private key.

[0045] Specifically, the token management device 100 may generate a wallet address and a private key of a financial institution based on, for example, information about a financial institution that manages security token transactions (hereinafter referred to as "financial institution information"). In this case, the token management device 100 may execute a contract to issue a security token to a user's wallet address on the blockchain BN by accepting input of the financial institution's private key.

[0046] Specifically, the token management device 100 may generate a wallet address and a private key of the system provider based on information about the system provider (hereinafter referred to as "system provider information"). In this case, the token management device 100 may execute a contract to issue a security token to a user's wallet address on the blockchain BN, for example, by accepting input of the private key of the system provider.

[0047] A blockchain BN is a system used for trading encrypted currencies and security tokens. A blockchain BN is composed of multiple nodes (computers) and can manage ledger data in a distributed manner. The distributed ledger is managed in a way that makes it difficult to tamper with, using the so-called blockchain mechanism. Note that a detailed explanation of the distributed ledger management mechanism using blockchain will be omitted here, as it is a common system. For example, a blockchain BN can be built using Ethereum, etc.

[0048] The process for issuing a security token is a process for executing a transaction that transfers digital assets to a wallet address on the blockchain BN, and may use, for example, a mechanism that uses an electronic signature mechanism.

[0049] Specifically, the security token management system 10 may execute a verification process using a digital signature with a stored private key, and if the verification is successful, issue a security token to the wallet address.

[0050] The token management apparatus 100 may be, for example, a cloud computer, a server computer, a personal computer (e.g., a desktop, laptop, tablet, etc.), a media computing platform (e.g., a cable or satellite set-top box, a digital video recorder), a handheld computing device (e.g., a PDA, an email client, etc.), or any other type of computing or communications platform. Note that at least a portion of the processing in the token management apparatus 100 may or may not be implemented by one or more computers (e.g., cloud computing consisting of one or more computers).

[0051] The user terminal 200 is a terminal that receives an operational input from a user and transmits, for example, various information to the token management device 100 for receiving the issuance of a security token.

[0052] The financial institution terminal 300 is a terminal that receives operational inputs from a financial institution's personnel and transmits various information to the token management device 100.

[0053] The system provider terminal 400 is a terminal that receives operational input from a person in charge of the system provider and transmits various information to the token management device 100.

[0054] The user terminal 200, the financial business operator terminal 300, and the system provider terminal 400 may be, for example, a smartphone, a mobile phone (feature phone), a personal computer (e.g., a desktop, laptop, tablet, etc.), a media computer platform (e.g., a cable or satellite set-top box, a digital video recorder), a handheld computer device (e.g., a PDA (Personal Digital Assistant), an email client, etc.), a wearable device (e.g., a glasses-type device, a watch-type device, etc.), or another type of computer or communication platform.

[0055] <<Processing Overview>> Next, an overview of the processing of the security token management system 10 will be described. Hereinafter, as an example, the transactor will be described as a "user," but it is also possible to interpret "user" as a "financial institution" or a "system provider." In other words, the following will be described as using the user's private key when issuing a security token to the user's wallet address and when forcibly transferring a security token between users, but the private key of the financial institution or system provider may also be used at this time.

[0056] The token management device 100, for example, receives a request (hereinafter referred to as a "registration request") from the user terminal 200 of a user who wishes to be issued a security token that has acquirer requirements, to register the user information of that user.

[0057] The user information includes, for example, the investor's name, contact information, and the number of shares they wish to purchase.

[0058] If the financial institution determines that the user meets the acquirer requirements based on the user information, the token management device 100 generates, for example, identification information, a wallet address, and a private key.

[0059] The token management device 100 outputs information for printing information indicating the user's private key (hereinafter referred to as "print information") to a printing device. The printing device prints out a private key paper medium (information indicating the private key). A person in charge at the financial institution stores the printed private key paper medium in a safe, for example.

[0060] The token management device 100 acquires from the user terminal 200 a request for issuing a security token (hereinafter referred to as an “issuance request”).

[0061] When an issuance request is received, and if the token management device 100 obtains approval from the financial institution to issue a security token, it accepts input of the user's private key by the financial institution or system provider based on the private key paper medium, and executes a process (hereinafter referred to as the "issuance process") to issue the security token to the user's wallet address on the blockchain BN.

[0062] The issuance process is, for example, a process of executing a smart contract (hereinafter referred to as an "issuance contract") on the blockchain BN that issues a security token to the wallet address of a registered user.

[0063] Furthermore, the security token management system 10 may receive a request from a financial institution to forcibly transfer a security token between users (hereinafter referred to as a "forcible transfer request").

[0064] When a forced transfer request is received, the token management device 100 accepts input of the user's private key by the financial institution based on the private key paper medium, and executes a process (hereinafter referred to as the "forced transfer process") to transfer security tokens between users on the blockchain BN.

[0065] A forced transfer process is a process in which a smart contract (hereinafter referred to as a "forced transfer contract") is executed on the blockchain BN to forcibly transfer security tokens from a specified user's wallet address to another user's wallet address when circumstances arise, such as when a specified user is unable to possess the security token.

[0066] As described above, when performing issuance processing and forced transfer processing, the security token management system 10 accepts input of the user's private key by a financial institution or system provider who references the user's private key paper medium that has been properly stored.

[0067] This allows financial institutions to store and manage private keys on paper (or other hardware media not connected to a network) rather than leaving them on hardware, thereby increasing the security of private keys and improving user convenience.

[0068] ===Token Management Device 100=== The configuration of the token management device 100 will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of the functional configuration of each device included in the security token management system 10.

[0069] As shown in Figure 2, the token management device 100 includes functional units such as an acquisition unit 101, an input unit 102, a generation unit 103, an output unit 104, an erasure unit 105, a memory unit 106, a memory execution unit 107, a judgment unit 108, a transmission unit 109, and an issuance unit 110.

[0070] The acquisition unit 101 acquires various types of information from, for example, other devices.

[0071] Specifically, the acquisition unit 101 (information acquisition unit) acquires transactor information.

[0072] For example, the acquiring unit 101 may acquire, from the user terminal 200, user information (such as investor name, contact information, and number of shares desired to be purchased) of a user who desires to be issued a security token.

[0073] For example, the acquiring unit 101 may acquire financial institution information (financial institution name, contact information, etc.) from the financial business operator terminal 300.

[0074] For example, the acquisition unit 101 may acquire system provider information (system provider name, contact information, etc.) from the system provider terminal 400.

[0075] Specifically, the acquisition unit 101 (issuance request acquisition unit) may acquire, for example, from the user terminal 200, an issuance request for issuing a security token on the blockchain.

[0076] The issuance request may include, for example, user information of the user to whom the security token is to be issued and information on the financial product to be purchased.

[0077] Specifically, the acquisition unit 101 (forced transfer request acquisition unit) may acquire, for example, from the user terminal 200, a forced transfer request for forcibly transferring a security token on the blockchain.

[0078] The forced transfer request may include, for example, the wallet address of the transferring user and the wallet address of the transferring user.

[0079] The input unit 102 receives an operational input from, for example, a user, a financial institution, or a system provider, and acquires the result of the operational input (hereinafter referred to as the "input result").

[0080] The input unit 102 may, for example, acquire the input results of operational inputs made by a financial service provider, system provider representative, or user on an input screen displayed on the display unit of the token management device 100, the display unit (not shown) of the user terminal 200, the display unit (not shown) of the financial service provider terminal 300, or the display unit (not shown) of the system provider terminal 400.

[0081] Specifically, the input unit 102 may acquire the input results (acquirer requirements) entered by a financial institution's staff member on an input screen for inputting whether or not the user satisfies the acquirer requirements for acquiring a security token.

[0082] Specifically, the input unit 102 may also acquire the input result (approval) entered by a financial institution's staff member on an input screen for inputting the result of the financial institution's confirmation that user information is registered on the whitelist.

[0083] Specifically, the input unit 102 may also obtain an input result (private key) for the private key through operational input by a financial institution employee, a system provider employee, or a user on an input screen for inputting the private key that is displayed on the display unit of various devices, for example.

[0084] The generation unit 103 generates a private key and wallet address of the transactor based on the transactor information acquired by the acquisition unit 101.

[0085] For example, the generation unit 103 may generate the user's identification information, password, wallet address, and private key based on the user information.

[0086] For example, the generation unit 103 may generate identification information, a password, a wallet address, and a private key of a financial institution based on financial institution information.

[0087] For example, the generation unit 103 may generate identification information, a password, a wallet address, and a private key for the system provider based on the system provider information.

[0088] The identification information is, for example, a trader ID that identifies each trader who uses the security token management system 10.

[0089] The password is, for example, a character string that allows each trader to access the security token management system 10.

[0090] A wallet address is the account information of each transactor on the blockchain. A wallet address can be represented by, for example, a character string or an identification code (e.g., a one-dimensional code or a two-dimensional code).

[0091] Note that the generation unit 103 may generate the user's private key (and the identification information, password, and wallet address) when, for example, information indicating that the user satisfies the acquirer requirements is input by an operational input from the financial institution accepted by the input unit 102. That is, the generation unit 103 may generate the private key when, for example, the user satisfies the acquirer requirements.

[0092] The output unit 104 outputs, for example, print information (for example, a spool file or a print job) for printing information indicating the private key of the transactor (a private key paper medium) to a printing device.

[0093] The output unit 104 may output the print information based on an operation input by a person in charge of the financial institution, for example, or may automatically output the print information when a private key is generated.

[0094] Furthermore, for example, when the generation unit 103 generates a private key of a transactor, the output unit 104 may output information to the display unit for displaying the private key on the display unit. In this case, a person in charge of the financial institution may create a private key paper medium by transcribing information indicating the private key displayed on the display unit onto paper. This allows the token management device 100 to create a private key paper medium even in a configuration without a printing device, thereby reducing the risk of information related to the private key remaining in the memory area of ​​the printing device.

[0095] For example, when the print information is output to a printing device, the erasing unit 105 erases the private key of the transactor generated by the generating unit 103.

[0096] In addition, the erasure unit 105 may erase the trader's private key generated by the generation unit 103, for example, when information indicating the private key is displayed on the display unit and an operational input regarding the private key is received from a financial institution employee or a system provider employee.

[0097] Furthermore, the erasing unit 105 may erase the private key of the transactor generated by the generating unit 103 when a predetermined time has elapsed since the information indicating the private key was displayed on the display unit.

[0098] In other words, the erasing unit 105 is a functional unit that prevents the token management device 100 from storing the private key in the storage unit from the viewpoint of security.

[0099] This prevents the private key from being obtained by anyone who accesses the token management device 100, thereby improving the confidentiality of the private key.

[0100] The storage unit 106 includes, for example, at least a trader information database D106. The trader information database D106 will be described with reference to Fig. 3. Fig. 3 is a diagram showing the trader information database D106.

[0101] The trader information database D106 stores, for example, trader information acquired by the acquisition unit 101 and various information generated by the generation unit 103. Specifically, as shown in Fig. 3, the trader information database D106 includes, for example, items such as [trader ID], [trader name], [password], [wallet address], [trader attributes], and [issuer consent information].

[0102] [Transactor ID] stores, for example, an identification code that can uniquely identify the transactor.

[0103] [Transactor Name] stores, for example, information indicating the name of the transactor.

[0104] In the [Password], for example, character information for the trader to access the security token management system 10 is stored.

[0105] [Wallet Address] stores, for example, information indicating a wallet address in the blockchain BN.

[0106] [Trader Attributes] stores, for example, information about financial assets held by the trader, information indicating investment history, etc. Based on the information stored in [Trader Attributes], financial institutions can determine whether a user (investor) who wishes to acquire a security token meets the acquirer requirements.

[0107] [Issuer consent information] stores information indicating that a financial institution (issuer of the security token) has consented to the issuance of a security token to a user. Specifically, for example, if consent has been given, "1" is stored, and if consent has not been given, "0" is stored.

[0108] For example, when information indicating that a user who wishes to acquire a security token meets the acquirer requirements is input by an operational input from a financial institution accepted by the input unit 102, the storage execution unit 107 executes a contract to store the user information of the user on the blockchain BN. Here, a list containing the user information of each of multiple users who meet the acquirer requirements is generated on the blockchain BN. Hereinafter, the list on the blockchain BN is referred to as a "whitelist."

[0109] The determination unit 108 determines whether or not the user information of the user who desires to issue a security token is included in any of the multiple pieces of user information stored in the whitelist on the blockchain BN, for example, based on an issuance request transmitted from the user terminal 200. The determination unit 108 provides the determination result (hereinafter referred to as the "determination result") to the issuing unit 110.

[0110] Specifically, the determination unit 108 may determine whether the wallet address (user information) of the user desiring to issue a security token matches multiple wallet addresses included in the whitelist. That is, the determination unit 108 may determine whether the wallet address of the user desiring to issue a security token (or any other information related to the user) is included in the whitelist, which is virtually impossible to tamper with.

[0111] Furthermore, the determination unit 108 may determine, for example, based on a forced transfer request sent from the user terminal 200, whether or not at least the user information of the transfer destination user is included in any of the multiple pieces of user information included in the whitelist.

[0112] The transmitting unit 109 transmits, for example, various types of information to the user terminal 200.

[0113] Specifically, based on the determination result, the transmission unit 109 may transmit information indicating that the financial institution has approved the issuance of a security token to the user (hereinafter referred to as "approval information") to the user terminal 200. The approval information is, for example, information generated by an operation input based on an issuance request (user information) from the financial institution to the display unit.

[0114] Furthermore, the transmitting unit 109 may transmit consent information to the user terminal 200, for example, when it is determined that the user information is included in any of the plurality of pieces of user information on the whitelist BN.

[0115] For example, after the consent information is transmitted to the user terminal 200, the issuing unit 110 executes the issuing process based on the private key received by the input unit 102 through an operation input by the user or the financial institution. The issuing unit 110 may also execute the forced transfer process based on the private key.

[0116] This allows the token management device 100 to guarantee that security tokens are issued (or forcibly transferred) only to users who meet certain acquirer requirements. In other words, the token management device 100 has a mechanism for guaranteeing that users meet the acquirer requirements using a tamper-proof whitelist, which has the effect of providing a safer system for investors.

[0117] ===User terminal 200=== Returning to Fig. 2, the functional configuration of user terminal 200 will be described. As shown in Fig. 2, user terminal 200 includes, for example, a transmitter 201, an acquirer 202, and a memory 203. Note that financial business operator terminal 300 and system provider terminal 400 are assumed to have the same configuration as user terminal 200, and their description will be omitted.

[0118] The transmitting unit 201 transmits, for example, to the token management device 100, a registration request including user information based on an operational input by the user.

[0119] The acquisition unit 202 acquires, for example, from the token management device 100, the results of various processes such as security token issuance process or forced transfer process.

[0120] The storage unit 203 stores, for example, various types of information.

[0121] ===Processing Procedure=== The processing procedure of the security token management system 10 will be described with reference to Figures 4 and 5. Figure 4 is a diagram showing the flow of issuance processing in the security token management system 10. Figure 5 is a diagram showing the flow of forced transfer processing in the security token management system 10.

[0122] <<Issuance process>> First, with reference to FIG. 4, an issuance process for issuing a security token to a user in the security token management system 10 will be described.

[0123] As an example, the following describes the issuance process in which a security token is issued to a user (investor) who is determined to meet the acquirer requirements using a whitelist, based on a private key paper medium (information indicating the user's private key) printed on a printing device, to the user's wallet address.

[0124] In step S100, the user terminal 200 displays, for example, an input screen on the display unit for inputting user information. The user terminal 200 accepts user input on the input screen and transmits user information (registration request) of the user (hereinafter referred to as "User A") who desires to issue a security token to the token management device 100.

[0125] The user terminal 200 may transmit the user information to the token management device 100 through a financial institution (financial institution terminal 300). In this case, the financial institution, for example, operates and inputs information on a screen displayed on the display unit of the financial institution terminal 300, and the terminal device transmits the user information to the token management device 100.

[0126] In step S101, if the token management device 100 obtains a result that the user information meets the acquirer requirements, for example, through operational input from a financial institution, it executes a contract to register user A's user information in a whitelist on the blockchain BN.

[0127] In step S102, the token management device 100 generates identification information, a password, a wallet address, and a private key that can identify user A, for example, based on user information.

[0128] In step S103, the token management device 100 encrypts, for example, the user information, identification information, password, and wallet address, and stores them in the storage unit 106. That is, the token management device 100 stores, in the storage unit 106, all information generated based on the user information, excluding the private key. This prevents highly confidential information related to the private key from remaining in the hardware, thereby providing appropriate protection for the user.

[0129] In step S104, the token management device 100 outputs printing information (e.g., a spool file or a print job) to a printing device to print information indicating the private key (a private key paper medium). The printing device prints, for example, the private key paper medium. The financial institution stores the private key paper medium in a predetermined storage location. The predetermined storage location is a storage area accessible only to specific persons, such as a safe. The private key paper medium may be created, for example, by outputting the private key to a display unit and having a person who sees it (e.g., a financial institution employee) transcribe it onto paper medium, and then stored in a storage area.

[0130] In the above description, the financial institution has explained that the private key is stored in a storage location, but this is not limiting. For example, the financial institution may send the private key paper medium to user A by certified mail or the like. That is, the security token management system 10 may process so that user A stores and manages the private key paper medium. This allows the security token issuance process, which will be described later, to proceed based on user input, improving user convenience.

[0131] In step S105, the token management device 100 erases the private key from the storage unit 106. That is, the token management device 100 is configured to erase information about the private key from the memory 1002 and the storage device 1003, so that the private key cannot be obtained by anyone who illegally accesses the token management device 100.

[0132] This allows the security token management system 10 to manage information related to the private key without leaving it in the hardware, thereby improving the confidentiality of the private key.

[0133] In step S106, the user terminal 200 displays, for example, an operation screen for sending an issuance request on the display unit. The user terminal 200 accepts operation input from user A on the operation screen and sends the issuance request to the token management device 100. Note that the token management device 100 may also obtain the issuance request from user A through, for example, a financial institution.

[0134] In step S107, the token management device 100 determines, for example, whether the user information of user A is included in the whitelist on the blockchain BN. If the token management device 100 determines that the user information of user A is included in the whitelist, it transmits consent information (information indicating consent by the financial institution) indicating that the issuance of a security token to user A is approved to the user terminal 200.

[0135] In step S108, the user terminal 200, for example, accepts an operation input from user A and transmits a purchase request to the token management device 100 indicating user A's intention to purchase a security token.

[0136] Specifically, the user terminal 200 displays, for example, a screen indicating that the financial institution has approved the transaction (for example, a screen for indicating the intention to "decide to purchase") on the display unit. Then, when the user terminal 200 receives an operation input from the user on the screen indicating the intention to decide to purchase, the user terminal 200 may transmit a purchase request to the token management device 100.

[0137] In step S109, the token management device 100 displays, for example, a screen (not shown) for inputting a private key on the display unit in response to the purchase request.

[0138] At this time, a person in charge of the financial institution or the system provider retrieves the private key paper medium of User A from the storage location. At this time, it is preferable that the person in charge requires the presence of the person in charge's superior (a person different from the person in charge) to prevent human error in retrieving the private key (for example, retrieving the private key of a different user) and to prevent fraudulent acts (for example, retrieving the private key without the user's request).

[0139] In step S110, the token management device 100 receives an input from, for example, a person in charge of a financial institution or a system provider, and acquires the private key of user A. At this time, the token management device 100 may, for example, request the input of information indicating that the person in charge's superior has given consent when receiving the input of the private key. In this case, the security token management system 10 may be configured to transmit information indicating that the person in charge's superior has given consent from the operation terminal of the person in charge's superior to the token management device 100. This reduces the risk of the private key being input fraudulently.

[0140] In step S111, the token management device 100 executes a verification process using a digital signature with the input private key. For example, if the verification process is successful, the token management device 100 outputs an issuance instruction to issue a security token to the wallet address of user A. Based on the issuance instruction, an issuance contract on the blockchain BN is executed to issue the security token to the wallet address of user A.

[0141] Although it has been described that in step S108, the user terminal 200 transmits a purchase request to the token management device 100, step S108 does not have to be executed. In this case, if the token management device 100 determines in step S107 that the user information of user A is included in the whitelist on the blockchain BN, it may execute the processing in order from step S109. In this case, in step S111, the result of executing the issuance contract may be transmitted to the user terminal 200 as "approval information."

[0142] Although the above description assumes that the issuance process is performed using the private key of user A, this is not limiting. For example, the token management device 100 may execute the issuance process to issue a security token to the user's wallet address based on the private key of a financial institution or a system provider.

[0143] In this case, in step S102, the token management device 100 generates identifiable identification information, a password, a wallet address, and a private key based on, for example, financial institution information or system operator information, and then executes similar processes in steps S103 to S105.

[0144] Then, as shown in steps S106 to S108, when the token management device 100 receives a purchase request from the user terminal 200, in step S109, a person in charge of the financial institution or a person in charge of the system provider takes out the financial institution's private key paper medium or the system provider's private key paper medium from the storage location.

[0145] Then, in step S110, the token management device 100 receives an input from, for example, a financial institution employee or a system provider employee, and acquires the financial institution employee's private key or the system provider's private key. In step S111, the token management device 100 outputs an issuance instruction to issue a security token to user A's wallet address based on the input financial institution employee's private key or the system provider's private key.

[0146] <<Forced relocation process>> Next, with reference to Figure 5, we will explain the forced transfer process in which the security token of user A is forcibly transferred to another user (hereinafter referred to as "user B") in the security token management system 10. Note that "user B" may be a financial institution or a system provider.

[0147] In the following, as an example, it is assumed that the processes of steps S100 to S105 in Fig. 4 have already been executed for user A and user B, and the description thereof will be omitted. That is, in Fig. 5, it is assumed that registration on the whitelist, generation of wallet addresses and private keys, and storage of private key paper media have already been executed for user A and user B.

[0148] In step S200, the token management device 100 acquires a forced transfer request from a financial institution when the financial institution determines that a forced transfer is necessary. The token management device 100 may acquire the forced transfer request by accepting a direct operation input from a financial institution's staff member. Alternatively, the token management device 100 may acquire the forced transfer request through a financial institution's terminal 300 that has accepted an operation input from a financial institution's staff member.

[0149] In step S201, based on the forced transfer request, the token management device 100 obtains the wallet addresses of user A and user B, which are encrypted and stored in the storage unit 106, by decrypting them using, for example, a password.

[0150] At this point, a financial institution employee or a system provider employee retrieves the private key paper medium of User A from the storage location. At this time, it is preferable that the employee's superior be present to prevent human error in retrieving the private key (e.g., retrieving the private key of a different user) and fraudulent activity (e.g., retrieving the private key without the user's request).

[0151] In step S202, the token management device 100 acquires the private key of user A through the operation input of the person in charge based on the private key paper medium corresponding to the wallet address of user A, the transfer source.

[0152] In step S203, the token management device 100 executes a verification process using a digital signature with the input private key. For example, if the verification process is successful, the token management device 100 outputs a transfer instruction to transfer the security token from the wallet address of user A to the wallet address of user B. Based on the transfer instruction, a forced transfer contract on the blockchain BN is executed to transfer the security token from the wallet address of user A to the wallet address of user B.

[0153] In addition, before or after any of steps S201 to S203, the token management device 100 may determine whether or not the user information of at least user B, to whom the security token is to be transferred, is registered on a whitelist (for example, the token management device 100 may execute a contract on the blockchain BN to make the determination).

[0154] If it is determined that the user information of User B is registered on the whitelist, the token management device 100 sends an execution request to the blockchain BN to execute a forced transfer contract on the blockchain BN. The forced transfer contract transfers all security tokens of User A from User A's wallet to User B's wallet.

[0155] This allows the security token management system 10 to safely and appropriately transfer security tokens in the event of a situation in which a user is unable to obtain a security token, such as when a system failure occurs or when a user violates the system's terms of use.

[0156] Although the forced transfer process is described above as being executed using the private key of user A, this is not limiting. For example, the token management device 100 may execute the forced transfer process based on the private key of a financial institution or a system provider.

[0157] In this case, in step S202, the token management device 100 acquires the private key of the financial institution or system provider through an operation input by a designated person based on a private key medium corresponding to the financial institution or system provider. Then, in step S203, the token management device 100 executes a verification process based on the input private key of the financial institution or system provider, and executes the forced transfer contract based on the transfer instruction.

[0158] Security Token Management System 20 According to Second Embodiment A security token management system 20 according to the second embodiment will be described with reference to Fig. 6. Fig. 6 is a diagram showing an example of the configuration of the security token management system 20 according to the second embodiment. Note that, hereinafter, only the configuration that differs from the security token management system 10 will be described, and unless otherwise specified, it will be assumed that the configuration is the same as the security token management system 10.

[0159] As shown in FIG. 6, the security token management system 20 includes, for example, a token management device 100, a user terminal 200, and a private key generation device 500.

[0160] Unlike the security token management system 10 , the security token management system 20 includes a private key generation device 500 .

[0161] <<Private key generation device 500>> The private key generation device 500 is, for example, a device that generates a private key. The private key generation device 500 is not communicatively connected to the token management device 100 and the user terminal 200. This reduces the risk of other devices accessing the device and stealing private key information that is to be assigned to transactors. In other words, the confidentiality of the private key can be further improved.

[0162] As shown in FIG. 6, the private key generation device 500 includes, for example, an input unit 501, a private key generation unit 502, a storage unit 503, and an output unit 504.

[0163] The input unit 501 receives, for example, an operation input from a person in charge of a financial institution. The operation input from the person in charge may be, for example, an operation input to press an execution button to generate a private key.

[0164] The private key generation unit 502 generates, for example, a private key. The private key generation unit 502 may generate, for example, a plurality of private keys and store them in the storage unit 503 described below. Furthermore, the private key generation unit 502 may extract one private key from the plurality of private keys stored in the storage unit 503 when, for example, the input unit 501 receives an operation input from a financial institution employee or a system provider.

[0165] The storage unit 503 stores various types of information. For example, the storage unit 503 may store a plurality of private keys generated by the private key generation unit 502. The storage unit 503 deletes the private key output by the output unit 504, which will be described later. This can increase the security of the private key.

[0166] The output unit 504 outputs, for example, printing information to the printing device for causing the printing device to print the private key extracted by the private key generation unit 502. This causes the printing device to print a private key paper medium. The output unit 504 may also display the private key on a display unit, for example. This allows a financial institution employee or a system provider employee to create the private key paper medium by transcribing the displayed private key onto paper. Note that in Figure 6, the dashed line between the printing device and the financial institution terminal indicates that the financial institution employee will check the private key paper medium on which the private key is printed, and does not indicate a network connection.

[0167] As described above, in the security token management system 20, a private key is generated by the private key generation device 500. Therefore, the token management device 100 of the security token management system 20 does not need to generate a private key.

[0168] That is, the token management device 100 of the security token management system 20 does not generate a private key in the generation unit 103. Furthermore, the token management device 100 does not need to have the functional unit of the output unit 104.

[0169] In this way, in the security token management system 20, the token management device 100 does not generate the private key, so there is no need to erase information about the private key from the memory 1002 and the storage device 1003.

[0170] As a result, the security token management system 20 can improve the confidentiality of the private key by managing the private key without leaving it in hardware. That is, by generating the private key in a device other than the token management device 100, the step of deleting information about the private key from the token management device is unnecessary, and the risk of the private key being leaked can be further reduced.

[0171] Private key generation device 500 may be, for example, a cloud computer, a server computer, a personal computer (e.g., a desktop, laptop, tablet, etc.), a media computer platform (e.g., a cable or satellite set-top box, digital video recorder), a handheld computer device (e.g., a PDA, email client, etc.), or any other type of computer or communication platform. Note that at least a portion of the processing in private key generation device 500 may or may not be realized by one or more computers (e.g., cloud computing configured by one or more computers).

[0172] <<Processing Procedure>> Next, the processing procedure of the security token management system 20 according to the second embodiment will be described with reference to Fig. 7. Fig. 7 is a diagram showing the flow of the issuance processing in the security token management system 20.

[0173] 7, a process of issuing a security token by generating a private key using private key generating device 500 will be described. Note that steps S204 to S210 below are the same as steps S106 to S111 shown in FIG. 4, and therefore their description will be omitted.

[0174] In step S200, the user terminal 200 displays, for example, an input screen on the display unit for inputting user information. The user terminal 200 accepts user input on the input screen and transmits user information of user A, who desires to issue a security token, to the token management device 100.

[0175] In step S201, if the token management device 100 obtains a result that the user information meets the acquirer requirements, for example, through operational input from a financial institution, it executes a contract to register user A's user information on a whitelist on the blockchain.

[0176] In step S202, the token management device 100 generates, for example, identification information, a password, and a wallet address that can identify user A based on the user information.

[0177] In step S203, the token management device 100 encrypts, for example, the user information, the identification information, the password, and the wallet address, and stores them in the storage unit 106.

[0178] At this time, the private key generation device 500 generates a private key by, for example, accepting operational input from the financial institution. Also, the printing device prints the private key paper medium when it accepts printing information for printing the private key paper medium, which is sent from the private key generation device 500 by operational input from the financial institution. The financial institution stores the printed private key paper medium in a specified storage location.

[0179] ===Hardware Configuration=== 8, an example of a hardware configuration in which the token management device 100, the user terminal 200, and the private key generation device 500 are realized by a computer 1000 will be described. Note that the various functions of the token management device 100, the user terminal 200, and the private key generation device 500 can be realized by dividing them into multiple devices.

[0180] 8 is a diagram illustrating an example of a hardware configuration of a computer. As illustrated in FIG. 8, a computer 1000 includes, for example, a processor 1001, a memory 1002, a storage device 1003, an input I / F unit 1004, a data I / F unit 1005, a communication I / F unit 1006, and a display unit 1007.

[0181] The processor 1001 is a control unit that controls various processes in the computer 1000 by executing programs stored in the memory 1002 .

[0182] The memory 1002 is a storage medium such as a RAM (Random Access Memory), etc. The memory 1002 temporarily stores the program code of the program executed by the processor 1001 and data required when the program is executed.

[0183] The storage device 1003 is a non-volatile storage medium such as a hard disk drive (HDD), flash memory, etc. The storage device 1003 stores an operating system and various programs for realizing the above-mentioned components.

[0184] The input I / F unit 1004 is a device for receiving input from a user. Specific examples of the input I / F unit 1004 include a keyboard, a mouse, a touch panel, various sensors, and a wearable device. The input I / F unit 1004 may be connected to the computer 1000 via an interface such as a USB (Universal Serial Bus).

[0185] The data I / F unit 1005 is a device for inputting data from outside the computer 1000. A specific example of the data I / F unit 1005 is a drive device for reading data stored in various storage media. The data I / F unit 1005 may be provided outside the computer 1000. In this case, the data I / F unit 1005 is connected to the computer 1000 via an interface such as a USB.

[0186] The communication I / F unit 1006 is a device for performing data communication via the Internet N, either wired or wirelessly, with devices external to the computer 1000. The communication I / F unit 1006 may be provided outside the computer 1000. In this case, the communication I / F unit 1006 is connected to the computer 1000 via an interface such as a USB.

[0187] The display unit 1007 is a device for displaying various types of information. Specific examples of the display unit 1007 include a liquid crystal display, an organic EL (Electro-Luminescence) display, and a display of a wearable device. The display unit 1007 may be provided outside the computer 1000. In this case, the display unit 1007 is connected to the computer 1000 via, for example, a display cable. Furthermore, when a touch panel is adopted as the input I / F unit 1004, the display unit 1007 can be configured as an integral part of the input I / F unit 1004.

[0188] ===Summary=== The security token management system 10 in this embodiment includes an acquisition unit 101 (information acquisition unit) that acquires trader information from a trader, which is information about a first user who wishes to acquire a security token, a financial institution that manages financial instruments, or a system provider of a system that enables trading of security tokens, who is a trader that trades security tokens based on financial instruments; a generation unit 103 that generates a private key and a wallet address for issuing a security token based on the trader information; an output unit 104 that outputs print information to a printing device to print information indicating the private key or displays the private key on a display unit; The system includes: an acquisition unit 101 (issue request acquisition unit) that acquires a security token issuance request from a first user and a transmission unit 109 that transmits consent information to the first user indicating that the financial institution has consented to the issuance of the security token to the first user based on the issuance request; an input unit 102 that, when the consent information is transmitted to the first user, accepts operation input for the private key from a predetermined inputter based on information indicating the private key printed by the printing device; and an issuance unit 110 that executes a process to issue a security token to the first user's wallet address on the blockchain BN based on the private key accepted by the input unit 102. This allows the private key paper medium to be appropriately stored by the financial institution, reducing the user's private key management burden and ensuring the convenience of security token transactions. In other words, a system can be provided that satisfies the requirements of Article 43-2 of the Financial Instruments and Exchange Act and Article 136, Paragraph 1, Item 5 of the Cabinet Office Ordinance on Financial Instruments and Exchange Business, etc.

[0189] The security token management system 10 further includes a storage unit 106 that stores the wallet address among the private key and wallet addresses generated by the generation unit 103. This allows the security token management system 10 to use the wallet address information of the user as needed.

[0190] Furthermore, the security token management system 10 further includes an erasing unit 105 that erases the private key generated by the generating unit 103 when the print information is output to the printing device. This allows the security token management system 10 to increase the confidentiality of the private key because the private key is not stored in hardware.

[0191] The security token management system 10 also includes an erasing unit 105 that erases the private key generated by the generating unit 103 when the private key is displayed on the display unit, when an operational input regarding the private key is received from a predetermined input person, or when a predetermined time has elapsed since the private key was displayed on the display unit. This allows the security token management system 10 to increase the confidentiality of the private key because the private key is not stored in hardware.

[0192] Furthermore, in the security token management system 10, the input unit 102 receives operational input from a financial institution regarding whether first user information, which is information about a first user, satisfies acquirer requirements, which are user requirements for acquiring a security token, and the generation unit 103 generates a private key when information indicating that the first user information satisfies the acquirer requirements is input by the operational input from the financial institution received by the input unit 102. This enables financial institutions to issue security tokens only to users who satisfy the acquirer requirements of a security token, thereby providing a system that satisfies the requirements of Article 9-2, Paragraph 1, Item 1 of the Cabinet Office Ordinance on Definitions Provided for in Article 2 of the Financial Instruments and Exchange Act.

[0193] The security token management system 10 further includes a storage execution unit 107 that stores information about users who satisfy acquirer requirements, which are user requirements for acquiring a security token, on the blockchain, and a determination unit 108 that determines, based on an issuance request, whether first user information, which is information about the first user, is included in any of the information about multiple users who satisfy the acquirer requirements that is stored on the blockchain, and the transmission unit 109 transmits consent information to the first user when the determination unit 108 determines that the first user information is included in the whitelist (any of the information about multiple users who satisfy the acquirer requirements).As a result, the security token management system 10 uses a whitelist that cannot be tampered with, and can therefore appropriately issue security tokens to users who satisfy the acquirer requirements.

[0194] The security token management system 10 further includes a memory execution unit 107 that stores information about users who satisfy acquirer requirements, which are user requirements for acquiring a security token, on the blockchain BN, the acquisition unit 101 (information acquisition unit) acquires second user information, which is information about a second user to whom a security token is transferred from a first user, the generation unit 103 generates a wallet address of the second user based on the second user information, the storage unit 106 stores the wallet address of the second user, and the security token management system 10 executes a forced transfer to forcibly transfer the security token of the first user from the wallet address of the first user to the wallet address of the second user. The security token management system 10 further includes an acquisition unit 101 (forced transfer request acquisition unit) that acquires a forced transfer request from a financial institution, and a determination unit 108 that determines, based on the forced transfer request, whether the second user information is included in any of the information about users stored on the blockchain. When the determination unit 108 determines that the second user information is included in the whitelist (information about users), the issuance unit 110 transfers the security token of the first user from the wallet address of the first user to the wallet address of the second user on the blockchain based on the private key of the first user input by a predetermined input person and the wallet addresses of the first user and the second user stored in the storage unit 106. This allows the security token management system 10 to forcibly transfer security tokens as needed by financial institutions, thereby appropriately protecting users.

[0195] The security token management system 20 also includes an acquisition unit 101 (information acquisition unit) that acquires trader information from a trader, which is information about a first user who wishes to acquire a security token and is a trader who trades security tokens based on financial products, a financial institution that manages financial products, or a system provider of a system that enables trading of security tokens; a generation unit 103 that generates a wallet address of the trader based on the trader information; a transmission unit 109 that transmits to the first user consent information indicating that the financial institution has consented to the issuance of the security token to the first user based on the issuance request; and a transmission unit 109 that transmits to the first user consent information indicating that the financial institution has consented to the issuance of the security token to the first user based on the issuance request. and an input unit 102 that accepts an operational input regarding the private key by a predetermined inputter based on information indicating the private key printed by a printing device based on a print request for printing information indicating the private key output from the private key generation device 500 to a printing device, or information indicating the private key displayed on a display unit based on information for displaying the private key output from the private key generation device 500 to a display unit, which is sent to a user by an operational input from a financial business operator to a private key generation device 500 that generates a private key for issuing a security token, and an issuing unit 110 that executes a process of issuing a security token to a wallet address of the first user on the blockchain BN based on the private key accepted by the input unit 102. As a result, the security token management system 10 generates the private key in a device separate from the token management device 100, and can store the private key without leaving the private key information in the system hardware.

[0196] The above-described embodiments are intended to facilitate understanding of the present invention and are not intended to limit the present invention. The elements of the embodiments, as well as their arrangement, materials, conditions, shapes, sizes, etc., are not limited to those illustrated and can be modified as appropriate. Furthermore, configurations shown in different embodiments can be partially substituted or combined with each other. [Explanation of symbols]

[0197] 10, 20...security token management system, 100...token management device, 101...acquisition unit, 102...input unit, 103...generation unit, 104...output unit, 105...erasure unit, 106...storage unit, 107...storage execution unit, 108...determination unit, 109...transmission unit, 110...issuing unit, 200...user terminal, 300...financial business operator terminal, 400...system provider terminal, 500...private key generation device.

Claims

1. An information acquisition unit that acquires trader information from a trader who is a trader of a security token based on a financial product, the trader information being information about a first user who wishes to acquire the security token, a financial business operator who manages the financial product, or a system provider of a system that enables trading of the security token; A generation unit that generates a private key and a wallet address of the transactor for issuing the security token based on the transactor information; a storage unit that stores the private key; an output unit that outputs print information for printing information indicating the private key to a printing device, or displays the private key on a display unit; an issuance request acquisition unit that acquires an issuance request for the security token from the first user; A storage execution unit that stores information about users who satisfy acquirer requirements, which are user requirements for acquiring the security token, on a blockchain; a determination unit that determines, based on the issuance request, whether first user information, which is information about the first user, is included in any of information about a plurality of users that satisfy the acquirer requirements and that is stored on the blockchain; and a transmitting unit configured to transmit, to the first user, consent information indicating that issuance of the security token to the first user has been consented to, when the determining unit determines that the first user information is included in any of information relating to a plurality of users who satisfy the acquirer requirements; and an input unit that, when the consent information is transmitted to the first user, accepts an operation input for the private key from a predetermined input person based on information indicating the private key printed by the printing device or information indicating the private key displayed on the display unit and transcribed onto a paper medium by a person; an issuing unit that executes a process of issuing the security token to the wallet address of the first user on a blockchain based on the private key accepted by the input unit; an erasing unit that erases all of the private keys stored in the storage unit when the print information is output to the printing device, and erases all of the private keys stored in the storage unit when the private keys are displayed on the display unit, when an operation input for the private keys by the predetermined input person is received, or when a predetermined time has elapsed since the private keys were displayed on the display unit; A security token management system, including:

2. The storage unit further stores the private key and the wallet address of the wallet addresses. The security token management system of claim 1 .

3. The input unit receives, from the financial service provider, an operational input regarding whether first user information, which is information about the first user, satisfies acquirer requirements, which are user requirements for acquiring the security token; the generation unit generates the private key when information indicating that the first user information satisfies the acquirer requirements is input by the operation input of the financial institution accepted by the input unit. The security token management system of claim 1 .

4. The security token management system includes: The method further includes a forced transfer request acquisition unit that acquires, from the financial service provider, a forced transfer request for forcibly transferring the security token of the first user from the wallet address of the first user to the wallet address of a second user, the information acquisition unit acquires second user information, which is information about a second user to whom the security token is transferred from the first user; the generation unit generates a wallet address of the second user based on the second user information; The storage unit stores a wallet address of the second user, The determination unit determines, based on the forced transfer request, whether the second user information is included in any of the information about the user stored on the blockchain; and When the determination unit determines that the second user information is included in the information about the user, the issuing unit transfers the security token of the first user from the wallet address of the first user to the wallet address of the second user on the blockchain based on the private key input by the predetermined input person and the wallet addresses of the first user and the second user stored in the storage unit. The security token management system of claim 2 .

5. An information acquisition unit that acquires trader information from a trader who is a trader of a security token based on a financial product, the trader information being information about a first user who wishes to acquire the security token, a financial business operator who manages the financial product, or a system provider of a system that enables trading of the security token; a generation unit that generates a wallet address of the transactor based on the transactor information; an issuance request acquisition unit that acquires an issuance request for the security token from the first user; A storage execution unit that stores information about users who satisfy acquirer requirements, which are user requirements for acquiring the security token, on a blockchain; a determination unit that determines, based on the issuance request, whether first user information, which is information about the first user, is included in any of information about a plurality of users that satisfy the acquirer requirements and that is stored on the blockchain; and a transmitting unit configured to transmit, to the first user, consent information indicating that issuance of the security token to the first user has been consented to, when the determining unit determines that the first user information is included in any of information relating to a plurality of users who satisfy the acquirer requirements; and an input unit that accepts operational input regarding the private key by a predetermined input person based on information indicating the private key printed by the printing device based on a print request for printing information indicating the private key output from the private key generation device to a printing device in response to an operational input by the financial institution to a private key generation device that generates a private key for issuing the security token when the consent information is transmitted to the first user, or information indicating the private key displayed on a display unit that has been manually transcribed onto a paper medium based on information for displaying the private key output from the private key generation device to a display unit; an issuing unit that executes a process of issuing the security token to the wallet address of the first user on a blockchain based on the private key accepted by the input unit; Including, The generation unit does not generate the private key, A security token management system, wherein the private key generation device is not communicatively connected to any other device.

6. The computer Acquire trader information from the trader, which is information about a first user who wishes to acquire the security token, a financial business operator who manages the financial product, or a system provider of a system that enables trading of the security token, and is a trader who trades security tokens based on financial products; generating a private key and a wallet address of the trader for issuing the security token based on the trader information; storing said private key; outputting print information for printing information indicating the private key to a printing device, or displaying the private key on a display unit; obtaining a request for issuing the security token from the first user; Storing information on a blockchain about users who meet acquirer requirements, which are user requirements for acquiring the security token; Based on the issuance request, determining whether first user information, which is information about the first user, is included in any of information about a plurality of users who satisfy the acquirer requirements and is stored on the blockchain; and If it is determined in the determination that the first user information is included in any of information about a plurality of users who satisfy the acquirer requirements, sending consent information to the first user indicating that issuance of the security token to the first user has been consented to; When the consent information is transmitted to the first user, accepting an operation input for the private key by a predetermined input person based on information indicating the private key printed by the printing device or information indicating the private key displayed on the display unit and transcribed onto a paper medium by a person; Execute a process of issuing the security token to the wallet address of the first user on a blockchain based on the private key accepted by the operation input of the predetermined input person; When the print information is output to the printing device, all of the stored private keys are erased, and when the private keys are displayed on the display unit, when an operation input for the private keys by the predetermined input person is received, or when a predetermined time has elapsed since the private keys were displayed on the display unit, all of the stored private keys are erased. A security token management method comprising:

7. On the computer, Acquire trader information from the trader, which is information about a first user who wishes to acquire the security token, a financial business operator who manages the financial product, or a system provider of a system that enables trading of the security token, and is a trader who trades security tokens based on financial products; generating a private key and a wallet address of the trader for issuing the security token based on the trader information; storing said private key; outputting print information for printing information indicating the private key to a printing device, or displaying the private key on a display unit; obtaining a request for issuing the security token from the first user; Storing information on a blockchain about users who meet acquirer requirements, which are user requirements for acquiring the security token; Based on the issuance request, determining whether first user information, which is information about the first user, is included in any of information about a plurality of users who satisfy the acquirer requirements and is stored on the blockchain; and If it is determined in the determination that the first user information is included in any of information about a plurality of users who satisfy the acquirer requirements, sending consent information to the first user indicating that issuance of the security token to the first user has been consented to; When the consent information is transmitted to the first user, accepting an operation input for the private key by a predetermined input person based on information indicating the private key printed by the printing device or information indicating the private key displayed on the display unit and transcribed onto a paper medium by a person; Execute a process of issuing the security token to the wallet address of the first user on a blockchain based on the private key accepted by the operation input of the predetermined input person; When the print information is output to the printing device, all of the stored private keys are erased, and when the private keys are displayed on the display unit, when an operation input for the private keys by the predetermined input person is received, or when a predetermined time has elapsed since the private keys were displayed on the display unit, all of the stored private keys are erased. A program that executes the following.

Images