Program, information processing apparatus, or information processing method

Abstract

To provide a mechanism for preventing transmission of a token (to a user) from a transmission source that is not desired by the user.SOLUTION: There is provided a program that causes a computer to execute a procedure for controlling, on the basis of setting information, at least one of transmission of a token from a specific transmission source to a user, and viewing of the token by a token holder or another person. There is provided an information processing apparatus that controls, on the basis of the setting information, at least one of transmission of the token from the specific transmission source to the user, and viewing of the token by the token holder or another person. There is provided an information processing method that includes a step of causing the computer to control, on the basis of the setting information, at least one of transmission of the token from the specific transmission source to the user, and viewing of the token by the token holder or another person.SELECTED DRAWING: Figure 1

Description

[Technical field]

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

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

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

[0004] At present, the technology known as NFTs is new, and their creation requires expert knowledge. In addition, businesses also have the challenge of finding it difficult to distribute tokens such as NFTs unless they understand how transactions are conducted on the blockchain.

[0005] However, it is expected that the number of opportunities to distribute (send) tokens to users will increase in the future. In this case, a mechanism that can prevent tokens from being sent (to the user) from sources that the user does not want will be useful.

[0006] Therefore, an object of the present disclosure is to provide a mechanism for preventing the transmission of tokens (to a user) from a transmission source that is not desired by the user. [Means for solving the problem]

[0007] In order to solve the above problem, the program disclosed herein causes a computer to execute a procedure for controlling, based on configuration information, at least one of the transmission of a token from a specific source to a user and the viewing of the token by the token holder or others. In addition, in order to solve the above problem, the information processing device disclosed herein controls at least one of the transmission of a token from a specific source to a user and the viewing of the token by the token holder or others, based on configuration information. In addition, in order to solve the above problem, the information processing method disclosed herein includes a step in which a computer controls at least one of the transmission of a token from a specific source to a user and the viewing of the token by the token holder or others based on configuration information. Effect of the Invention

[0008] According to the present disclosure, it is possible to provide a mechanism for preventing a token from being sent (to a user) from a sender that the user does not want. [Brief description of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram showing the entire system of the present embodiment. [Diagram 2] FIG. 13 is a diagram showing the entire system of another embodiment. [Diagram 3] FIG. 11 is an explanatory diagram of a process for issuing and transmitting a token. [Figure 4] FIG. 11 is an explanatory diagram of a method for restricting viewing of a Reject token. [Diagram 5] FIG. 11 is an explanatory diagram regarding a determination as to whether or not a token is issued and transmitted. [Figure 6] FIG. 11 is an explanatory diagram regarding a determination when a token is viewed. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0011] FIG. 1 is a diagram showing an entire system 1 of the present embodiment.

[0012] The system 1 of this embodiment includes an NFT Reject API server. The name of the NFT Reject API server is for explanatory purposes, and can be realized by any server computer that realizes the functions of an API (Application Programming Interface).

[0013] As shown in FIG. 1, the NFT Reject API server stores NFT metadata. NFT metadata is metadata associated with a specific token, the Reject token. A Reject token is an NFT that can be circulated on a blockchain network. The NFT Reject API server stores (manages) metadata corresponding to each Reject token. Note that a user in this embodiment is the owner of a Reject token and is a user who owns one or more wallets with wallet addresses associated with one or more Reject tokens.

[0014] The metadata of the Reject token includes information that identifies a sender from which a user rejects (rejects) receipt of an NFT. In this embodiment, as shown diagrammatically in FIG. 1, in addition to basic information such as the NFT name and data for displaying an image related to the NFT, the metadata includes, as reception availability information, permitted address information indicating the sender addresses of targets that are permitted to receive, and rejected address information indicating the sender addresses of targets that are rejected to receive. Note that, in this embodiment, the address information is an example of information that can identify a sender, but other identification information may be used, for example.

[0015] In addition, such metadata may be stored in any memory area of ​​any other server or terminal instead of or in addition to the NFT Reject API server.

[0016] In the example shown in Figure 1, the permitted address information is address information associated with accept, such as "0xaaa..." or "0xddd...". In this case, the sender of the address information associated with accept, such as "0xaaa..." or "0xddd...", (for example, a consortium member company) is able to send NFTs to the corresponding user.

[0017] In addition, rejected address information is address information associated with reject, such as "0xbbb...". In this case, the sender of address information associated with reject, such as "0xbbb..." or "0xccc...", (for example, a consortium member company) cannot send an NFT to the corresponding user. In this case, even if an NFT is sent to the corresponding user from the sender of "0xbbb..." or "0xccc...", it will be rejected by the user and will not be received.

[0018] In this embodiment, the metadata related to the NFT can be set based on input from the user. Therefore, in this embodiment, the user can set whether or not to receive various NFTs that may be distributed from the consortium participating company, which is the sender, in a desired manner by editing the metadata related to the Reject token owned by the user. For example, the default setting information (metadata of the Reject token), which allows the sending of NFTs to the user from all participating companies based on the address list of the consortium participating companies, can be edited in a manner desired by each user. The metadata edited by each user is updated and stored in the NFT Reject API server. When the metadata is edited, a Reject token is issued to the user based on the edited setting information. Then, based on the metadata of the Reject token edited by each user, each user can receive an NFT from a sender that he or she desires. In addition, each user can refuse to receive an NFT from a sender that he or she does not desire. Note that it is also possible to set the NFT to be hidden by editing.

[0019] The system 1 of this embodiment can be realized by combining a computer-readable program and a computer such as a server.

[0020] FIG. 1 shows the operation of a system 1 according to this embodiment.

[0021] In the example shown in FIG. 1, in step S1 (shown in circle 1), the user receives a Reject token. In step S2 (shown in circle 2), the user sets the contents of the metadata (sources that are permitted to send NFTs and sources that are rejected) corresponding to the received Reject token. In this state, when each participating company tries to send an NFT to the user, it inquires the NFT Reject API server about whether the NFT can be sent in step S2 (shown in circle 2). In place of the inquiry, the participating company may directly analyze the metadata. In this case, the metadata includes rejected address information of "0xbbb···" and "0xccc···", and includes permitted address information of "0xaaa···". In this case, a notification of "unsendable" is returned in response to an inquiry from a source related to "0xbbb···" and a source related to "0xccc···". On the other hand, a notification of "sendable" is returned in response to an inquiry from a source related to "0xaaa···". Based on such notifications (answers), each participating company can make a decision on whether or not to send an NFT to each user.

[0022] The reject tokens related to each user may be issued as one reject token for one transmission source, or may be issued as one reject token collectively for multiple transmission sources.

[0023] FIG. 2 is an explanatory diagram of a viewer mechanism as another function of the system 1 of this embodiment.

[0024] The tokens that can be received from each participating company may be made viewable by each user via a marketplace, an NFT viewer, etc. In this case, the user can easily distinguish between tokens that he or she wants to reject and tokens that he or she wants to allow by checking the tokens that can be received from each participating company. As a result, editing of metadata becomes easier. In addition, a UI that helps distinguish tokens that can be received from participating companies and tokens that can be displayed to participating companies may be provided as a function of the marketplace or NFT viewer used by each company to display NFTs. In this case, users can easily set up NFTs to be refused or hidden by editing metadata such as Reject tokens while looking at the NFT viewer. Information about hidden tokens may also be distributed from an NFT indexer with specifications that reflect information such as Reject tokens. NFT indexers are used as external APIs by marketplaces and NFT viewers, and are a system that organizes data on the blockchain and responds with a list of NFTs held by users.

[0025] FIG. 3 is an explanatory diagram of the process of issuing and transmitting a token. Tx in the figure indicates a transaction. The Tx reception determination unit performs the above-mentioned determination process. The function of the Tx reception determination unit may be realized on a blockchain.

[0026] Figure 4 is a supplement to the operation logic of the system in Figure 2 described above. The Tx reception availability determination unit responds with information on whether or not a token can be displayed based on inquiries from NFT marketplaces and NFT viewers regarding restrictions on token issuance and transmission, and methods for restricting the viewing of tokens by others via various viewing sites and applications. This may be an NFT indexer that responds with a list of displayable owned NFTs that organizes information on displayable NFTs as described above.

[0027] FIG. 5 is an explanatory diagram regarding the determination of whether or not a token is issued and transmitted.

[0028] The nine locations shown in Figure 5 can be the parts that decide whether or not to issue and transmit a token. Each location may refer to the following information to decide whether or not to issue and transmit a token. Also, it does not have to be implemented in one location, and checks may be made in multiple locations. Also, the setting information that each functional unit has in advance may be as follows. Information directly implemented in each functional section (such as information written in the source code) -Settings files stored in a memory area such as a storage that each functional unit can access Information on the network, such as external information servers and IPFS (InterPlanetary File System) (including information on servers that hold metadata corresponding to reject tokens. In addition, when accessing information outside of the blockchain, such as an external server, from a Smart Contract, it is acceptable to use Oracle, etc.) Instead of or in addition to the above, you may check directly with the recipient of the token. You may also have access to the recipient's information on whether or not the transaction is valid, or send a notification to the recipient via any route to have the recipient make the decision themselves. If the token issuer / sender can determine whether or not a transaction is valid on the route to the RPC (Remote Procedure Call) server, there is an advantage in that there is no need to send the transaction to the blockchain side, and no extra gas fees are incurred.

[0029] As shown in the speech bubble, the "Tx Reception Unit" in Figure 5 is a function that the Blockchain system itself has. As functions for creating new chains such as L2 are increasing, the Blockchain system itself may provide this function. Each Smart Contract may check by itself, or may request a check from another Smart Contract. For example, the Token Smart Contract may check with the Reject Token Smart Contract before issuing a new token. In this case, it is also possible to set the information required for confirmation (who is sending to whom, what kind of token it is, etc.) as an argument to the generation or transmission API.

[0030] FIG. 6 is an explanatory diagram regarding a determination when a token is viewed.

[0031] The number of checkpoints themselves will remain the same as the configuration shown in Figure 5, but for sites that browse tokens such as OpenSea and TofuNFT (such as "Token browsing sites / apps" in the figure), a NG list can be created "in advance" for each user (= address), and display only those that are OK (allowed) based on that list. Similar to Reject Token, there may be a "Hide Token". This can be used to hide a token that the user himself / herself has specified. Reject indicates the intention of "not receiving", while Hide expresses the intention of "not seeing, not wanting to see, not wanting to tell". In reality, anyone can check the tokens they own by looking at the data on the blockchain, but it is unlikely that ordinary people will see token information held by others in any way other than via a token viewing site. In addition, since it is difficult for ordinary people to control whether or not something can be displayed, this Hide Token allows users to control which tokens they want to see or be able to show. In addition, like the Reject Token, there may be a "Hide Token" and the Reject setting of the Reject Token may be processed as a request to not display it. In addition, since it is difficult for the general public to control whether or not a token can be displayed, it is possible to use the Hide Token or Reject Token to control which tokens users want to see or be able to see. In this case, adding information about this hidden setting as a function of the "NFT Indexer," a system that notifies marketplaces and NFT viewers of NFT holding information, is an effective way to promote the use of Reject Tokens and Hide Tokens.

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

[0033] 1 System

Claims

1. A program that causes a computer to execute a procedure for controlling, based on setting information, at least one of the transmission of a token from a specific transmission source to a user and the viewing of the token by the token holder or others.

2. The program according to claim 1 , wherein the setting information includes information for identifying a particular source.

3. The program according to claim 1 , wherein the setting information is managed as metadata of a specific token.

4. The program according to claim 3 , wherein the specific token is issued based on a user input related to the setting information.

5. The program of claim 3 , wherein the specific token is an NFT.

6. 2. The program according to claim 1, further comprising: referring to the setting information relating to a destination user based on a transmission request from a transmission source; and notifying the transmission source of whether or not a token can be transmitted to the destination user based on a result of the reference.

7. The program according to claim 1 , wherein NFT holding information reflecting the setting information of the NFT to be hidden is notified to an NFT viewer or an NFT marketplace via an NFT indexer.

8. The program according to claim 1 , wherein the setting information includes information indicating one or more companies among a plurality of companies as the specific senders.

9. The program of claim 8 , wherein the plurality of companies includes consortium participating companies.

10. An information processing device that controls at least one of the transmission of a token from a specific transmission source to a user and the viewing of the token by the token holder or others based on setting information.

11. An information processing method including a step of controlling, by a computer based on configuration information, at least one of the transmission of a token from a specific transmission source to a user and the viewing of the token by the token holder or another person.

Images