Program and information processing device

Abstract

To enhance the convenience of a service use in the case that different wallet addresses are used for login among web services.SOLUTION: According to the present invention, a program is a program that functions as a smart contract on a distributed ledger system, and causes a computer to execute a transmission procedure for transmitting each of contract addresses of smart contracts to each of provision devices for providing respective different web services, a reception procedure for receiving from a user a creation request for an address group for subscribing mutually different wallet addresses to be used for login in the respective different web services by the user; a creation procedure for creating the address group in response to the creation request; a joining control procedure for causing a wallet address designated by the user to join the address group; and a provision procedure for providing the provision device with the wallet address having joined the address group in response to operation of the user.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to a control program. [Background technology]

[0002] In recent years, systems that record transactions in distributed ledgers such as blockchains have become widespread. In addition, smart contract-type blockchains have been proposed, in which a transaction with a program code is registered in the blockchain, a contract address is registered, and a transaction is issued to the contract address to execute the program.

[0003] For example, Patent Document 1 discloses a technology for granting tokens to contract subscribers in a system that uses a smart contract type blockchain. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2023-97087 A Summary of the Invention [Problem to be solved by the invention]

[0005] However, the above-mentioned conventional technology does not necessarily improve the convenience of using services when different wallet addresses are used to log in to different web services.

[0006] For example, in the above-mentioned conventional technology, when a token is transferred to a subscriber, the wallet address specified in the token issuance request is used, but no consideration is given to the function of using a wallet address for web service authentication (login ID) or the function of linking different wallet addresses used between different web services.

[0007] For this reason, the above-mentioned conventional technology does not necessarily improve the convenience of using services when different wallet addresses are used to log in to different web services.

[0008] Therefore, the present invention proposes a program and an information processing device that can improve the convenience of using services when different wallet addresses are used to log in to different web services. [Means for solving the problem]

[0009] In order to solve the above problems, one form of a program according to the present invention is a program that functions as a smart contract on a distributed ledger system, and is characterized in that it causes a computer to execute the following steps: a transmission step of transmitting a contract address of the smart contract to a providing device that provides each different web service; a reception step of receiving from the user a creation request for an address group to which different wallet addresses used by the user to log in to each different web service are added; a creation step of creating the address group in response to the creation request; a joining control step of joining a wallet address specified by the user to the address group; and a providing step of providing the providing device with the wallet addresses joined to the address group in response to the user's operation. Effect of the Invention

[0010] According to the present invention, it is possible to improve the convenience of using services when different wallet addresses are used to log in to different web services. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is an explanatory diagram for explaining a problem that is addressed in the present invention. [Diagram 2] FIG. 2 is a diagram illustrating an example of a system according to the embodiment. [Diagram 3]FIG. 3 is a diagram illustrating an example of the configuration of a providing device according to the embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of the configuration of the association device according to the embodiment. [Diagram 5] FIG. 5 is a diagram for explaining the linking process (formal subscription) according to the embodiment. [Figure 6] FIG. 6 is a diagram illustrating the information acquisition process according to the embodiment. [Figure 7] FIG. 7 is a diagram illustrating the service control process according to the embodiment. [Figure 8] FIG. 8 is a diagram for explaining the association process (temporary joining) according to the embodiment. [Figure 9] FIG. 9 is a block diagram showing an example of the hardware configuration of each device included in the system according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In this specification and the drawings, components having substantially the same functional configurations are denoted by the same reference numerals, and redundant description will be omitted.

[0013] One or more embodiments (including examples, modifications, and application examples) described below can be implemented independently. Meanwhile, at least a part of the embodiments described below may be implemented in appropriate combination with at least a part of another embodiment. These embodiments may include novel features different from each other. Thus, these embodiments may contribute to solving different purposes or problems and may provide different effects.

[0014] (Embodiment) 1. Introduction In recent years, Web3 has been attracting attention. Web3 is a new form of the next generation Internet, and is called a decentralized Internet. In other words, Web3 is an Internet concept that aims to distribute data using distributed ledger system (blockchain network) technology.

[0015] Another feature of Web3 is that blockchain technology makes it possible to prevent data tampering or falsification digitally, and it is mainly used in the art market, music market, game market, anime and manga market, etc. Examples of services that utilize Web3 (Web3 services) include web browsers, NFT marketplaces, NFT apps, and decentralized social graphs.

[0016] For example, when a user wants to buy or sell NFTs on an NFT marketplace or use an NFT app, the user needs to create a wallet (a place to store crypto assets). A wallet address is information that identifies a wallet, and is registered in a wallet created by a user. In addition to the wallet address, a public key and a private key are also registered in the wallet. For example, a wallet first creates a private key, and then a public key and a wallet address are generated from the private key.

[0017] The public key is information that indicates the sender of the cryptocurrency, and for example, when a cryptocurrency transaction is made between a sender and a receiver, data (transaction) indicating the transaction is recorded on the blockchain network. In addition, since a wallet address can be determined from the public key, for example, it is possible to obtain deposit and withdrawal information from a transaction corresponding to a specific account using the wallet address. This makes it possible to check for fraud, such as whether an attempt is being made to pay an amount of cryptocurrency that is greater than the amount the user actually holds. For these reasons, Web3 makes it possible to build a state that is difficult to tamper with and highly transparent.

[0018] On the other hand, with only a public key, there is a risk that a third party may be able to use someone else's cryptocurrency without permission. Therefore, a signature on digital data using a private key is adopted as a mechanism for verifying that the sender of the cryptocurrency is the actual holder of the cryptocurrency. The signature data is created by calculation using the private key, which only the sender knows, and the sender's transaction. The signature data is then verified to be correct through verification calculations using the sender's public key, so that it becomes possible to determine from the calculation results whether the transmission of the cryptocurrency is indeed an event carried out by the actual person.

[0019] Now, the problems that the inventors of the present invention have noticed regarding Web3 services will be described.

[0020] As mentioned above, there are a wide variety of Web3 services, and some of them have a function that allows users to use wallet addresses for login authentication. For example, wallet addresses are increasingly being used as self-managed accounts instead of centralized accounts such as free email addresses.

[0021] In such a situation, for example, a user familiar with Web3 often uses one wallet address as a login ID between multiple different Web3 services. In such a case, this one wallet address can link multiple different Web3 services, so that, for example, a user can check information of other wallet addresses while logged in to a certain Web3 service.

[0022] On the other hand, since Web3 is the next generation of the Internet, many users are not familiar with it. Users who are not familiar with Web3 may end up using different wallet addresses as login IDs for multiple different Web3 services. In such cases, it is impossible to link multiple different Web3 services, which results in a problem of reduced convenience compared to when multiple different Web3 services are linked.

[0023] Such a problem will be described in more detail with reference to Fig. 1. Fig. 1 is an explanatory diagram for explaining the problem focused on in the present invention. Fig. 1 shows a web service SA1, a web service SA2, and a web service SA3. The web service SA1, the web service SA2, and the web service SA3 are each a different Web3 service.

[0024] Here, FIG. 1(a) shows a case where one wallet address is used as a login ID among web service SA1, web service SA2, and web service SA3. Specifically, in FIG. 1(a), a user Ux who is familiar with Web3 uses a wallet address A (OxAAAA...) registered in his / her wallet WL1 as a common login ID for each service for web service SA1, web service SA2, and web service SA3. In this case, the wallet address A enables cooperation between web service SA1, web service SA2, and web service SA3, so that user Ux can, for example, check his / her own information in web service SA2 and web service SA3 while logged in to web service SA1.

[0025] Also, for example, suppose that the operator of web service SA1 has a need to provide a specific service to user Ux according to the token contract of user Ux in web service SA2 or web service SA3. In the state of FIG. 1(a), in web service SA1, the token held by user Ux in web service SA1 is linked one-to-one with wallet address A. In web service SA2, the token held by user Ux in web service SA2 is linked one-to-one with wallet address A. In web service SA3, the token held by user Ux in web service SA3 is linked one-to-one with wallet address A.

[0026] As a result, it becomes possible to link the token contract of user Ux managed by web service SA1, the token contract of user Ux managed by web service SA2, and the token contract of user Ux managed by web service SA3 using wallet address A. Therefore, the operator of web service SA1 can refer to the token contract of user Ux in web service SA2 or web service SA3 via wallet address A, and can provide a specific service according to the token contract.

[0027] Figure 1(a) is an ideal form that can be established when users familiar with Web3 are widespread, but in the current situation where many users are not familiar with Web3, the state of Figure 1(b) has been reached. Figure 1(b) shows a case in which different wallet addresses are used as login IDs for web service SA1, web service SA2, and web service SA3. Specifically, in Figure 1(b), a user U1 who is not familiar with Web3 uses wallet address A (OxAAAA...) registered in his / her wallet WL1 as a login ID for web service SA1, wallet address B (OxBBBB...) registered in his / her wallet WL2 as a login ID for web service SA2, and wallet address C (OxCCCC...) registered in his / her wallet WL3 as a login ID for web service SA3. In such a case, regardless of whether wallet address A, wallet address B, or wallet address C is used, it is not possible to link web service SA1, web service SA2, and web service SA3, and user U1, for example, while logged in to web service SA1, is not able to check his or her own information in web service SA2 or web service SA3.

[0028] Similarly, consider a case where an operator of a web service SA1 wants to provide a particular service to a user U1 according to the token contract of the user U1 in a web service SA2 or a web service SA3.

[0029] In the state of Fig. 1(b), in web service SA1, the token held by user U1 in web service SA1 is linked one-to-one with wallet address A. In web service SA2, the token held by user U1 in web service SA2 is linked one-to-one with wallet address B. In web service SA3, the token held by user U1 in web service SA3 is linked one-to-one with wallet address C.

[0030] In this way, in a state where a token can only be linked to each wallet address individually, it is impossible to link the token contract of user U1 managed by web service SA1, the token contract of user U1 managed by web service SA2, and the token contract of user U1 managed by web service SA3. In that case, the operator of web service SA1 cannot refer to the token contract of user Ux in web service SA2 or web service SA3 via wallet address A, and therefore cannot provide a specific service according to the token contract.

[0031] Furthermore, if user U1 wishes to receive a specific service from the operator of web service SA1 (for example, distribution of a token that can be used as a coupon), he or she is required to perform the time-consuming task of moving his or her own token contract managed by web service SA2 or web service SA3 to the web service SA1 side. In addition, there are cases where moving a token contract to web service SA1 is impossible in the first place.

[0032] In view of the above problems, the inventors of the present invention have focused on the fact that if different wallet addresses are used as login IDs in multiple different Web3 services, the operability of using the services would be improved if the different wallet addresses could be linked to each other. Specifically, the proposed technology according to the present invention provides users with a platform that can link different wallet addresses when different wallet addresses are used as login IDs between multiple different web services. Such a platform can be implemented as a program that functions as a smart contract on a distributed ledger system (blockchain network).

[0033] 2. System Configuration Fig. 2 is a diagram showing an example of a system according to an embodiment. Fig. 2 shows a system 1 as an example of a system according to an embodiment. Information processing according to the embodiment is realized in the system 1.

[0034] 2, the system 1 includes a user device 10, a provisioning device 30-1 to 30-n, and a distributed ledger system 50. When there is no need to distinguish between the provisioning devices 30-1 to 30-n, they will be simply referred to as the provisioning device 30.

[0035] The user device 10 and the providing device 30 are connected via a network (e.g., the Internet or an intranet) N. The user device 10 and the distributed ledger system 50 are connected via the network N. The providing device 30 and the distributed ledger system 50 are connected via the network N.

[0036] The user device 10 is an example of an information processing terminal that transmits a request to the providing device 30. The user device 10 may be, for example, a smartphone, a tablet terminal, or a personal computer. A user of the user device 10 is a person who performs a transaction, for example, regarding the transfer of crypto assets, in a predetermined payment system realized by the distributed ledger system 50. Here, the term "crypto assets" is used to include unique crypto assets (so-called tokens) issued using existing blockchain technology, and is not limited to crypto assets issued on a unique blockchain (crypto assets in the narrow sense, also called platform tokens).

[0037] There are two types of tokens: fungible tokens and non-fungible tokens (hereinafter referred to as "NFTs"). For example, fungible tokens may be tokens whose rights are handled, such as transfer, according to ERC20, which is a smart contract standard in Ethereum (registered trademark). Furthermore, NFTs may be tokens whose rights are handled, such as transfer, according to ERC721, which is a smart contract standard in Ethereum. In this embodiment, the user's crypto asset will be described as an NFT.

[0038] In addition, the user has a wallet in which a wallet address, a public key, and a private key are registered in order to carry out a transaction. For this reason, a wallet (not shown) for carrying out NFT transactions and an execution environment (not shown) for sending transactions are installed in the user device 10.

[0039] In this embodiment, the user of the user device 10 is assumed to be a user U1 who is not familiar with Web3 described in Fig. 1. The user U1 may use different wallet addresses as login IDs for each of a plurality of different Web3 services.

[0040] The providing device 30 accesses the distributed ledger system 50 in response to a request sent from the user device 10. Then, the providing device 30 provides a predetermined service to the user U1 in response to a response obtained from the distributed ledger system 50. The providing device 30 is an example of an information processing device that provides Web3 services, and is a server computer.

[0041] Also, for example, the providing device 30-1 to the providing device 30-n each provide a different Web3 service. For example, the providing device 30-1 provides a first web service, the providing device 30-2 provides a second web service, and the providing device 30-3 provides a third web service. These are different Web3 services, such as the first web service being a web browser, the second web service being an NFT marketplace, and the third web service being an NFT app.

[0042] The distributed ledger system 50 manages a distributed ledger. As an example, the distributed ledger system 50 manages a transaction history regarding the transfer of NFTs. The distributed ledger is, for example, a blockchain. The blockchain here may be an Ethereum blockchain, and may be either a public or private type. The distributed ledger system 50 includes multiple computers (which may include the user device 10 or the providing device 30) that are interconnected.

[0043] The distributed ledger system 50 also includes a plurality of node computers 51 connected to each other via a P2P network (Peer to Peer).

[0044] The node computer 51 manages the distributed ledger using, for example, blockchain technology. Specifically, one of the node computers 51 acquires data related to cryptocurrency or NFT transactions to be recorded. The node computer 51 creates a block including the acquired data and adds it to the blockchain. The node computer 51 transmits information about the added block to the other node computers 51. The other node computers 51 verify the correctness of the received block, and if the verification is successful, add the block to the blockchain. The node computer 51 finalizes the blockchain according to, for example, the number of linked blocks (the number of approvals). As a result, the same distributed ledger is stored across the multiple node computers 51 that make up the distributed ledger system 50. The stored data is encrypted as appropriate.

[0045] In addition, the distributed ledger system 50 stores a smart contract 60 for implementing each function of the payment system. The smart contract 60 corresponds to a program according to the embodiment, and is a program that runs on a blockchain. The smart contract 60 can hold variables such as integers, character strings, and arrays, and has functions defined for calling from the outside. For example, the smart contract 60 is executed in response to a request from the user device 10. The smart contract 60 is also executed in response to a request from the providing device 30.

[0046] Here, the smart contract 60 may be stored in any of the node computers 51 constituting the distributed ledger system 50. The information processing device according to the embodiment is a node computer 51 that executes the smart contract 60 on the distributed ledger system 50 by storing the smart contract 60. The node computer 51 that executes the smart contract 60 may be specified in advance, or may be newly introduced to the distributed ledger system 50 in order to realize the platform according to the embodiment.

[0047] In addition, the node computer 51 executing the smart contract 60 may transmit the contract address of the smart contract 60 to the user device 10 and the providing device 30. As a result, the user device 10 and the providing device 30 become able to call and execute the smart contract 60.

[0048] In the following embodiment, the node computer 51 that executes the smart contract 60 may be referred to as the "linking device 51." The linking device 51 performs wallet address linking processing (grouping) in accordance with the smart contract 60. The smart contract 60 used in the wallet address linking processing can be called a linking contract.

[0049] Although not shown in FIG. 2, the system 1 may further include an external device that transmits the smart contract 60 to the node computer 51 and stores the smart contract 60 in the destination node computer 51. In this case, the contract address of the smart contract 60 may be transmitted by the external device to the user device 10 or the providing device 30. As another example, the external device may transmit a smart contract creation request to the node computer 51, and the node computer 51 that receives the creation request may create a smart contract and deploy it in the distributed ledger system 50. For example, the external device may be the user device 10.

[0050] 3. Configuration of the providing device The providing device 30 according to the embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the configuration of the providing device 30 according to the embodiment. As shown in Fig. 3, the providing device 30 includes a communication unit 31, a storage unit 32, and a control unit 33.

[0051] (Communications Department 31) The communication unit 31 is realized by, for example, a network interface card (NIC) etc. For example, the communication unit 31 is connected to the network N by wire or wirelessly, and transmits and receives information between the user device 10 and the matching device 51.

[0052] (Storage unit 32) The storage unit 32 is realized by, for example, a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 32 may include a service information storage unit 32a and an acquired information storage unit 32b.

[0053] The service information storage unit 32a stores, for example, a wallet address used to log in to the own device and the content of the service provided to the user U1 identified by the wallet address in association with each other. The acquired information storage unit 32b stores the linking information (grouping information) acquired from the linking device 51.

[0054] (Control unit 33) The control unit 33 is realized by a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or the like executing various programs stored in a storage device inside the providing device 30 using a RAM as a working area. For example, some or all of the functions of the control unit 33 are realized by a smart contract 60. The control unit 33 is also realized by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

[0055] As shown in Fig. 3, the control unit 33 has a calling unit 33a, a receiving unit 33b, an acquiring unit 33c, and a service control unit 33d, and realizes or executes the functions and actions of information processing described below. Note that the internal configuration of the control unit 33 is not limited to the configuration shown in Fig. 3, and may be other configurations as long as they perform information processing described below. Also, the connection relationship between the processing units of the control unit 33 is not limited to the connection relationship shown in Fig. 3, and may be other connection relationships.

[0056] (Calling unit 33a) The calling unit 33a calls the smart contract 60. For example, the calling unit 33a accesses the contract address of the smart contract 60 and causes its own device to execute the smart contract 60.

[0057] (Reception unit 33b) The reception unit 33b receives a request to acquire a wallet address from the user device 10. For example, the reception unit 33b receives an acquisition request from the user device 10 in which a specific wallet address is designated by the user U1.

[0058] (Acquisition part 33c) When the acquisition request is accepted by the acceptance unit 33b, the acquisition unit 33c acquires, from the association device 51, association information corresponding to the wallet address designated by the user U1 in the acquisition request. For example, the acquisition unit 33c acquires, from the association device 51, identification information of an address group to which another wallet address used by the user U1 for authentication of a web service provided by another providing device 30 different from the own device is subscribed, and identification information of an address group to which the wallet address used by the user U1 for authentication of a web service provided by the own device is subscribed.

[0059] (Service control unit 33d) The service control unit 33d executes a predetermined service for the user U1 based on the association information acquired by the acquisition unit 33c.

[0060] 4. Configuration of the providing device The correlating device 51 according to the embodiment will be described with reference to Fig. 4. Fig. 4 is a diagram showing a configuration example of the correlating device 51 according to the embodiment. As shown in Fig. 4, the correlating device 51 has a communication unit 52, a storage unit 53, and a control unit 54.

[0061] (Communication section 52) The communication unit 52 is realized by, for example, a NIC etc. For example, the communication unit 52 is connected to the network N by wire or wirelessly, and transmits and receives information between the user device 10 and the providing device 30.

[0062] (Storage unit 53) The storage unit 53 is realized by, for example, a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 53 may include a blockchain information storage unit 52a and a linking information storage unit 52b.

[0063] The blockchain information storage unit 52a stores the smart contract 60, transactions, etc. as information related to the blockchain. The linking information storage unit 52b stores, as linking information, information on the address group created in response to a creation request from the user U1.

[0064] (Control unit 54) The control unit 54 is realized by a CPU, an MPU, or the like executing various programs stored in a storage device inside the tying device 51 using a RAM as a working area. For example, some or all of the functions of the control unit 54 are realized by a smart contract 60. The control unit 54 is also realized by an integrated circuit such as an ASIC or an FPGA.

[0065] As shown in Fig. 4, the control unit 54 has a transmission unit 54a, a reception unit 54b, a creation unit 54c, an authentication unit 54d, a subscription control unit 54e, and a provision unit 54f, and realizes or executes the functions and actions of information processing described below. The internal configuration of the control unit 54 is not limited to the configuration shown in Fig. 4, and may be other configurations as long as they perform the information processing described below. Furthermore, the connection relationship between the processing units of the control unit 54 is not limited to the connection relationship shown in Fig. 4, and may be other connection relationships.

[0066] (Transmitter 54a) The transmission unit 54a transmits the contract address of the smart contract 60 to the providing devices 30 that provide different web services. According to the example of FIG. 1(b), the transmission unit 54a may transmit the contract address of the smart contract 60 to the providing devices 30-1 to 30-n.

[0067] (Reception unit 54b) The reception unit 54b receives from the user U1 a request to create an address group to which different wallet addresses used by the user U1 to log in to different web services (Web3 services) are added. For example, the reception unit 54b receives from the user U1 a creation request including a first wallet address used by the user U1 for authentication of a first web service. Specifically, the reception unit 54b creates an address group of the first wallet address by receiving the first wallet address to which first signature data generated based on a private key is attached.

[0068] The accepting unit 54b also accepts a second wallet address used by the user U1 for authentication of a second web service different from the first web service as a wallet address to be added to the address group of the first wallet address. The second wallet address may or may not have second signature data generated based on a private key attached thereto.

[0069] (Creation Section 54c) When a creation request is accepted by the accepting unit 54b, the creating unit 54c creates an address group according to the creation request. For example, when a creation request including a first wallet address is accepted, the creating unit 54c creates an address group of the first wallet address. That is, the creating unit 54c creates an address group with the first wallet address as the main address.

[0070] (Authentication section 54d) When second signature data is attached to a second wallet address accepted as a wallet address to be added to the address group of the first wallet address, the authentication unit 54d authenticates the identity of the user U1 based on the first signature data and the second signature data.

[0071] (Joining control unit 54e) The joining control unit 54e joins the wallet address to be joined, designated by the user U1, to the address group. For example, when a creation request including the first wallet address is accepted and a second wallet address is designated as the wallet address to be joined, the joining control unit 54e joins the second wallet address to the address group of the first wallet address. At this time, if the identity of the user U1 is authenticated based on the first signature data and the second signature data, the joining control unit 54e officially joins the second wallet address to the address group of the first wallet address.

[0072] (Provider part 54f) The providing unit 54f provides the providing device 30 with a wallet address that is a member of an address group in response to an operation by the user U1. For example, the providing unit 54f provides, to the access source providing device 30 that has accessed in response to an operation by the user U1, identification information of an address group to which another wallet address that the user U1 uses for authentication of a web service provided by another providing device 30 different from the access source providing device 30 is subscribed. The providing unit 54f may also provide, to the access source providing device 30, identification information of an address group to which a wallet address that the user U1 uses for authentication of a web service provided by the access source providing device 30 is subscribed.

[0073] In addition, the providing unit 54f may further provide, to the accessing providing device 30, a wallet address used by the user U1 to authenticate the web service provided by the accessing providing device 30, and another wallet address used by the user U1 to authenticate the web service provided by the other providing device 30.

[0074] [5. Information Processing Procedure (Pattern with Signature Data)] From now on, a method of association processing according to the embodiment and a method of service control that can be realized as a result of the association processing will be described with reference to Fig. 5 to Fig. 7. The association processing will be mainly described in Fig. 5, and the processing related to service control will be described in Fig. 6 and Fig. 7.

[0075] 5 to 7 illustrate a system 1 including a user device 10, a providing device 30-1, a providing device 30-2, and a linking device 51 (distributed ledger system 50). In this example, the providing device 30-1 provides a web service SA1, and the providing device 30-2 provides a web service SA2. Furthermore, assume a situation in which the operator of the web service SA1 intends to realize a service of distributing coupon NFTs that can be used as coupons according to the number of NFTs of the user U1 in the web service SA2 (for example, when the user U1 holds n or more NFTs in the web service SA2).

[0076] [5-1. Linking processing method] First, in the linking process according to the embodiment, a method for creating an address group in response to a creation request from user U1 and a method for adding a wallet address to this group will be described. Figure 5 is a diagram for explaining the linking process (formal addition) according to the embodiment. In Figure 5, a processing method when well-known data is added to a wallet address will be described.

[0077] Assume that user U1 wishes to receive coupon NFTs from the providing device 30-1 according to the number of NFTs he owns in web service SA2. In this case, user U1 sends a creation request using his / her wallet address A (OxAAAA...) that he / she uses as the login ID for web service SA1.

[0078] 5, in response to an operation by user U1, user device 10 transmits a creation request including a wallet address A to the associating device 51 (step S501). Specifically, user device 10 transmits a creation request including a wallet address A to which signature data DA1 is attached to the associating device 51. The signature data DA1 is generated from a private key registered in wallet WL1 of user U1.

[0079] The reception unit 54b of the linking device 51 receives the creation request including the wallet address A from the user device 10 (step S502).

[0080] In response to the creation request including the wallet address A, the creation unit 54c creates an address group G1 for the wallet address A, as shown in FIG. 5 (step S503).

[0081] Here, since user U1 wants to receive coupon NFTs from providing device 30-1 according to the number of NFTs he owns in web service SA2, he needs to link his wallet address B (OxBBBB...) that he uses as a login ID for web service SA2 with wallet address A. In other words, he needs to add wallet address B to address group G1 of wallet address A. Therefore, user U1 sends wallet address B as the wallet address to be added to address group G1.

[0082] 5, in response to an operation by user U1, user device 10 transmits wallet address B as a wallet address to be added to the linking device 51 (step S504). Specifically, user device 10 transmits wallet address B with signature data DA2 attached to it to the linking device 51. The signature data DA2 is generated from a private key registered in wallet WL2 of user U1.

[0083] The accepting unit 54b accepts the wallet address to be added (wallet address B) from the user device 10 (step S505).

[0084] Next, the authentication unit 54d executes an authentication process to authenticate the identity of the user U1 based on the first signature data and the second signature data (step S506). If the authentication unit 54d is unable to authenticate the identity of the user U1, the authentication unit 54d may control the user device 10 to output an authentication error.

[0085] On the other hand, if the identity of user U1 is authenticated, the joining control unit 54e joins wallet address B to address group G1 (step S507). In this way, the state in which wallet address A and wallet address B are joined in address group G1 means that the association between wallet address A and wallet address B is complete.

[0086] [5-2. Information acquisition and processing methods] Next, a method in which the providing device 30-1 acquires information on wallet addresses subscribed to the address group G1 from the linking device 51 in response to an operation by the user U1 will be described with reference to Fig. 6. Fig. 6 is a diagram for explaining the information acquisition process according to the embodiment.

[0087] Since user U1 wants to receive coupon NFTs from providing device 30-1 according to the number of NFTs he owns in web service SA2, providing device 30-1 needs to be able to access the database of user U1 (e.g., service information storage unit 32a) held by providing device 30-2. In other words, providing device 30-1 needs to refer to the status of NFTs of user U1 held by providing device 30-2. Therefore, user U1 sends an acquisition request using his own wallet address B used as a login ID for web service SA2.

[0088] That is, as shown in FIG. 6, the user device 10 transmits an acquisition request including a wallet address B to the providing device 30-1 in response to an operation by the user U1 (step S601).

[0089] The receiving unit 33b of the providing device 30-1 receives the acquisition request including the wallet address B from the user device 10 (step S602).

[0090] If the user who sent the acquisition request is user U1, the acquisition unit 33c accesses the linking device 51 using the login ID, i.e., wallet address A, registered by user U1 on its own device and the wallet address B included in the acquisition request (step S603).

[0091] In response to the access including wallet address A and wallet address B, providing unit 51f of linking device 51 transmits (provides) group information (information of the address group) corresponding to the access to providing device 30-1 (step S604). As a result, obtaining unit 33c obtains the group information from linking device 51.

[0092] The acquisition process performed in steps S603 to S606 will now be described in more detail.

[0093] The acquiring unit 33c accesses the associating device 51 using the wallet address A, and requests the associating device 51 to provide identification information (group ID) of the address group to which the wallet address A belongs. In response to the request, the providing unit 51f transmits the group ID of the address group to which the wallet address A belongs to the providing device 30-1. According to the examples so far, the providing unit 51f transmits the group ID "G1" as the group ID of the address group to which the wallet address A belongs. As a result, the acquiring unit 33c can acquire the group ID "G1" as group information corresponding to the wallet address A.

[0094] Furthermore, the acquiring unit 33c accesses the associating device 51 using the wallet address B, and requests the associating device 51 to provide the group ID of the address group to which wallet address B belongs. In response to the request, the providing unit 51f transmits the group ID of the address group to which wallet address B belongs to the providing device 30-1. According to the examples so far, the providing unit 51f transmits the group ID "G1" as the group ID of the address group to which wallet address B belongs. As a result, the acquiring unit 33c can acquire the group ID "G1" as group information corresponding to wallet address B.

[0095] [5-3. Service control methods] Next, a service control method performed by the providing device 30-1 using the group information acquired from the associating device 51 will be described with reference to Fig. 7. Fig. 7 is a diagram illustrating a service control process according to the embodiment.

[0096] 7 illustrates an example of service control for realizing a service of distributing coupon NFTs according to the number of NFTs of user U1 in web service SA2. However, the content of the service that the operator of the providing device 30 intends to realize is not limited to the distribution of coupon NFTs. Therefore, the content of the service control process may be changed as appropriate according to the content of the service.

[0097] The service control unit 33d of the providing device 30-1 determines whether or not the wallet address A and the wallet address B belong to the same address group based on the group information acquired in steps S603 to S606 (step S701). Specifically, if the group ID of the address group to which the wallet address A belongs is the same as the group ID of the address group to which the wallet address B belongs, the service control unit 33d determines that the wallet address A and the wallet address B belong to the same address group. On the other hand, if the group ID of the address group to which the wallet address A belongs is different from the group ID of the address group to which the wallet address B belongs, the service control unit 33d determines that the wallet address A and the wallet address B do not belong to the same address group.

[0098] If wallet address A and wallet address B do not belong to the same address group (step S701; No), the service control unit 33d notifies the user device 10 that the coupon NFT cannot be distributed (step S702).

[0099] If wallet address A and wallet address B belong to the same address group (step S701; Yes), the service control unit 33d recognizes that wallet address A and wallet address B are linked by user U1 himself.

[0100] Then, the service control unit 33d accesses the providing device 30-2 using the wallet address B, and refers to the status of the NFT of the user U1 held on the providing device 30-2 side (step S703). For example, if the status of the NFT of the user U1 held on the providing device 30-2 side satisfies the coupon distribution condition (having n or more NFTs in the web service SA2), the service control unit 33d distributes a coupon NFT to the user U1 (step S704). For example, the service control unit 33d may deposit the coupon NFT into the wallet WL1 in which the wallet address A is registered.

[0101] [6. Information Processing Procedure (Pattern without Signature Data)] In FIG. 5, a method of linking processing in a case where signature data is attached to a wallet address has been described. As described in FIG. 5, when signature data DA2 of a wallet address B to be added to the address group G1 is attached, the linking device 51 formally adds the wallet address B to link it with the wallet address A. However, when signature data DA2 is not attached to the wallet address B, the linking device 51 may trust the declaration that the creator of the wallet address A and the creator of the wallet address B are the user U1 himself / herself and may provisionally add the wallet address B to the address group G1. This point will be described with reference to FIG. 8. FIG. 8 is a diagram for explaining the linking processing (provisional addition) according to the embodiment.

[0102] When wallet address B is provisionally added to address group G1, some processing is different from the formal addition in Fig. 5. Therefore, the explanation of the same processing steps (steps S501 to S503) as those in the formal addition in Fig. 5 will be omitted, and the processing steps (steps S804 onwards) that are performed only in the case of provisional addition will be explained.

[0103] 8 illustrates a system 1 including a user device 10, a providing device 30-1, a providing device 30-3, and a linking device 51 (distributed ledger system 50). In this example, the providing device 30-1 provides a web service SA1, and the providing device 30-3 provides a web service SA3. Furthermore, assume a situation in which the operator of the web service SA1 intends to realize a service of distributing coupon NFTs that can be used as coupons according to the number of NFTs of the user U1 in the web service SA3 (for example, when the user U1 holds n or more NFTs in the web service SA3).

[0104] Since user U1 wants to receive coupon NFTs from providing device 30-1 according to the number of NFTs he owns in web service SA2, he needs to link his wallet address C (OxCCCC...) that he uses as a login ID for web service SA3 with wallet address A. In other words, he needs to add wallet address C to address group G1 of wallet address A.

[0105] However, if the web service SA3 is a service that temporarily issues a temporary wallet address like a browser wallet, the user U1 can create a wallet WL3 and be issued a wallet address C by the web service SA3, but cannot obtain the private key. Specifically, it is the web service SA3 that has the private key, and the user U1 cannot obtain it. As a result, the signature data cannot be added to the wallet address C.

[0106] In this way, when there is no signature data for wallet address C to be added to address group G1, user U1 sends wallet address C as a wallet address to be provisionally added to address group G1. Specifically, user U1 sends wallet address C together with a declaration that the creator of wallet address A and the creator of wallet address C are user U1 himself.

[0107] That is, as shown in FIG. 8, in response to the operation of user U1, user device 10 transmits wallet address C to be temporarily joined and declaration information that the creator of wallet address A is user U1 to the linking device 51 (step S804).

[0108] The accepting unit 54b accepts the wallet address (wallet address C) to which the declaration information is attached and which is to be temporarily joined, from the user device 10 (step S805).

[0109] The joining control unit 54e temporarily and provisionally joins wallet address C to address group G1 in response to the declaration information being added to wallet address C (step S806). In this manner, the state in which wallet address A and wallet address C are joined in address group G1 means that the association between wallet address A and wallet address C is complete.

[0110] Thereafter, providing device 30-1 can obtain group information in the flow described in Fig. 6, but in the example of Fig. 8, it can obtain not only the group ID of the address group to which wallet address A belongs and the group ID of the address group to which wallet address C belongs, but also the declaration information. As a result, providing device 30-1 can recognize that wallet address C is not officially joined, but is provisionally joined.

[0111] Here, for example, if the operator of web service SA1 has a policy of widely distributing NFT coupons regardless of whether the wallet address used in the login ID for web service SA3 is for a formal or provisional membership, then the providing device 30-1 can perform service control processing to distribute the NFT coupon to user U1.

[0112] On the other hand, if the operator of web service SA1 has a policy that the wallet addresses used in the login ID for web service SA3 must be those of officially registered users, the providing device 30-1 will not perform service control processing to distribute an NFT coupon to user U1.

[0113] 7. Modifications From here on, other embodiments of the linking device 51 will be described. The linking device 51 may be implemented in various different aspects other than the above-described embodiment. Therefore, other modified examples of the linking device 51 will be described below.

[0114] In the above embodiment, an example was shown in which the linking device 51 executes a group creation function, a wallet address official joining function to the group, a wallet address provisional joining function to the group, and an information provision function to the providing device 30 in accordance with the smart contract 60.

[0115] However, the linking device 51 may further execute the following functions in accordance with the smart contract 60. For example, the linking device 51 may further execute a withdrawal function to withdraw a designated wallet address from a designated address group in response to a wallet address withdrawal request from the user U1.

[0116] Furthermore, the linking device 51 may further execute a function of clearing the designated address group itself in response to a group deletion request from the user U1.

[0117] [8. Hardware Configuration] Next, a hardware configuration example of each device (user device 10, providing device 30, and linking device 51) included in the system 1 according to the embodiment will be described. FIG. 9 is a block diagram showing a hardware configuration example of each device included in the system 1 according to the embodiment. Referring to FIG. 9, each device includes, for example, a processor 801, a ROM 802, a RAM 803, a host bus 804, a bridge 805, an external bus 806, an interface 807, an input device 808, an output device 809, a storage 810, a drive 811, a connection port 812, and a communication device 813. Note that the hardware configuration shown here is an example, and some of the components may be omitted. Also, components other than those shown here may be further included.

[0118] (Processor 801) The processor 801 functions, for example, as an arithmetic processing device or control device, and controls all or part of the operation of each component based on various programs recorded in the ROM 802, the RAM 803, the storage 810, or the removable recording medium 901.

[0119] (ROM802, RAM803) The ROM 802 is a means for storing the programs to be read into the processor 801, data to be used for calculations, etc. The RAM 803 temporarily or permanently stores, for example, the programs to be read into the processor 801, various parameters that change appropriately when the programs are executed, etc.

[0120] (host bus 804, bridge 805, external bus 806, interface 807) The processor 801, ROM 802, and RAM 803 are connected to each other via, for example, a host bus 804 capable of high-speed data transmission. On the other hand, the host bus 804 is connected to an external bus 806 having a relatively low data transmission speed via, for example, a bridge 805. In addition, the external bus 806 is connected to various components via an interface 807.

[0121] (Input device 808) Examples of the input device 808 include a mouse, a keyboard, a touch panel, a button, a switch, and a lever. Furthermore, a remote controller capable of transmitting control signals using infrared rays or other radio waves may be used as the input device 808. The input device 808 also includes an audio input device such as a microphone.

[0122] (Output Device 809) The output device 809 is a device capable of visually or audibly notifying the user of acquired information, such as a display device such as a CRT (Cathode Ray Tube), LCD, or organic EL, an audio output device such as a speaker or a headphone, a printer, a mobile phone, or a facsimile. The output device 809 according to this embodiment also includes various vibration devices capable of outputting tactile stimulation. The output device 809 may also include an AI speaker or a wearable device.

[0123] (Storage 810) The storage 810 is a device for storing various types of data. For example, a magnetic storage device such as a hard disk drive (HDD), a semiconductor storage device, an optical storage device, or a magneto-optical storage device may be used as the storage 810.

[0124] (Drive 811) The drive 811 is a device that reads information recorded on a removable recording medium 901 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, and writes information to the removable recording medium 901.

[0125] (Connection port 812) The connection port 812 is a port for connecting an external device 902, such as a Universal Serial Bus (USB) port, an IEEE1394 port, a Small Computer System Interface (SCSI), an RS-232C port, or an optical audio terminal.

[0126] (Communication device 813) The communication device 813 is a communication device for connecting to a network, such as a communication card for wired or wireless LAN, Bluetooth (registered trademark), or WUSB (Wireless USB), a router for optical communications, a router for ADSL (Asymmetric Digital Subscriber Line), or a modem for various types of communications.

[0127] (Removable recording media 901) The removable recording medium 901 is, for example, a DVD medium, a Blu-ray (registered trademark) medium, an HD DVD medium, various semiconductor storage media, etc. Of course, the removable recording medium 901 may be, for example, an IC card equipped with a non-contact type IC chip, or an electronic device.

[0128] (External connection device 902) The external connection device 902 is, for example, a printer, a portable music player, a digital camera, a digital video camera, or an IC recorder.

[0129] [9. Others] Among the above-mentioned processes, all or part of the processes described as being performed automatically may be performed manually. Also, all or part of the processes described as being performed manually may be performed automatically by a known method. In addition, the information including the processing procedures, specific names, various data and parameters shown in the above documents and drawings may be changed arbitrarily unless otherwise specified. For example, the various information shown in each drawing is not limited to the illustrated information.

[0130] In addition, each component of each device shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure. In other words, the specific form of distribution and integration of each device is not limited to that shown in the figure. Furthermore, each component may be configured by distributing and integrating functionally or physically in any unit, in whole or in part, depending on various loads and usage conditions. Furthermore, each process described above may be executed in appropriate combination within a range that does not contradict.

[0131] The above describes the embodiments of the present application in detail with reference to several drawings. However, these are merely examples, and the present invention can be embodied in other forms that incorporate various modifications and improvements based on the knowledge of those skilled in the art, including the aspects described in the Disclosure of the Invention section.

[0132] 1 System 10 User Device 30 Providing device 33a Calling section 33b Reception 33c acquisition part 33d Service Control Section 50 Distributed Ledger System 51 Binding device (node ​​computer) 54a Transmitter 54b Reception 54c Creation Department 54d Authentication Section 54e Joining control section 54f supply department 60 Smart Contracts

Claims

1. A program that functions as a smart contract on a distributed ledger system, A transmission step of transmitting the contract addresses of the smart contracts to providing devices that provide different web services; A receiving step of receiving, from the user, a request to create an address group to which different wallet addresses used by the user to log in to different web services are added; a creation step of creating the address group in response to the creation request; a subscription control procedure for subscribing a wallet address designated by the user to the address group; a provision step of providing, to the providing device, a wallet address subscribed to the address group in response to an operation by the user; A program characterized by causing a computer to execute the above.

2. The receiving step includes receiving, from the user, a creation request including a first wallet address used by the user for authentication of a first web service; the creating step includes creating an address group of the first wallet address in response to the creation request; The joining control procedure joins a second wallet address used by the user for authentication of a second web service different from the first web service to an address group of the first wallet address.

2. The program according to claim 1 .

3. The receiving step generates an address group for the first wallet address by receiving the first wallet address to which first signature data generated based on a private key corresponding to the first wallet address is added.

3. The program according to claim 2 .

4. When second signature data generated based on a private key corresponding to the second wallet address is attached to the second wallet address, an authentication procedure for authenticating the identity of the user based on the first signature data and the second signature data is performed, Run it again, The joining control procedure includes, when the identity of the user is authenticated, officially joining the second wallet address to the address group of the first wallet address.

4. The program according to claim 3.

5. The joining control procedure includes provisionally joining the second wallet address to the address group of the first wallet address when second signature data generated based on a private key corresponding to the second wallet address is not attached to the second wallet address.

4. The program according to claim 3.

6. The receiving step includes receiving a declaration from the user that a creator of the first wallet address and a creator of the second wallet address are the user himself / herself; The joining control procedure provisionally joins a second wallet address to an address group of the first wallet address based on the declaration.

6. The program according to claim 5 .

7. The providing step provides, to an access source providing device that has accessed in response to an operation by the user, identification information of an address group to which another wallet address used by the user for authentication of a web service provided by another providing device different from the access source providing device among the providing devices, and identification information of an address group to which the wallet address used by the user for authentication of the web service provided by the access source providing device 2. The program according to claim 1 .

8. The web service is a Web3 service.

2. The program according to claim 1 .

9. An information processing device that executes a program that functions as a smart contract on a distributed ledger system, A transmission unit that transmits the contract address of the smart contract to a providing device that provides a different web service; A reception unit that receives, from a user, a request to create an address group to which different wallet addresses used by the user to log in to different web services are added; a creation unit that creates the address group in response to the creation request; a subscription control unit that subscribes the wallet address designated by the user to the address group; a providing unit that provides, in response to an operation by the user, a wallet address subscribed to the address group to the providing device; An information processing device comprising:

Images