server device

Abstract

The present application provides a server device. When registration of use of a first application as a mini application of a wallet application is performed, if a user agrees to provide data to the first application, a main chain node of a management server updates agreement information of a main chain. The updated agreement information is shared with each service server in the main chain. A sub-chain node of the management server sends user information to a sub-chain node of a service server added to the agreement information according to the updated agreement information.

Description

Technical Field

[0001] This disclosure relates to server apparatus for forming a network using distributed ledger technology. Background Technology

[0002] Japanese Patent No. 6587370 discloses a document management system that uses blockchain technology to prevent tampering with documents shared among multiple PCs (Personal Computers). In this document management system, multiple PCs are connected via a network to form a PC cluster. The system includes a unit that, when a document is recorded on a particular PC, reflects that document's record on other PCs within the PC cluster. Furthermore, the system includes a unit that generates a hash value for the document and includes it in a block. Thus, documents are shared within the PC cluster, and document tampering is suppressed. Summary of the Invention

[0003] Data stored in distributed ledgers such as blockchains can be referenced by all nodes participating in the distributed ledger network. Depending on the content of the data, there are also scenarios where data may be shared only among specific nodes participating in the distributed ledger network. Previously, such scenarios could not be addressed.

[0004] This disclosure was made to address the aforementioned issues. The purpose of this disclosure is to suppress data tampering through distributed ledger technology while enabling data to be shared only among specific nodes participating in the distributed ledger network.

[0005] (1) In one aspect of this disclosure, the server apparatus is used in a data sharing system employing distributed ledger technology. The data sharing system includes multiple other server apparatuses. The server apparatus has a first distributed ledger configured to share permission information related to data sharing with the multiple other server apparatuses. The permission information includes information for limiting the other server apparatuses among the multiple other server apparatuses that share the aforementioned data. Furthermore, the server apparatus has a second distributed ledger configured to share the aforementioned data with other server apparatuses based on the permission information.

[0006] According to the above structure, the first distributed ledger can manage permission information used to limit the information shared by other server devices. Based on this permission information, the second distributed ledger shares the data only with other server devices. By managing the permission information with the first distributed ledger, the permission information is shared by devices (server devices and multiple other server devices) included in the data sharing system. Therefore, since all devices monitor the permission information, the tamper resistance of the permission information can be improved. Moreover, data can be shared only with other server devices based on the permission information.

[0007] (2) In one embodiment, the server device further includes a control device for updating the first distributed ledger and the second distributed ledger. The control device sends data stored in the second distributed ledger to other server devices according to authorization information.

[0008] Based on the above structure, data stored in the second distributed ledger can be sent to other server devices to share data with other server devices.

[0009] (3) In one embodiment, when the permission information is updated, the control device saves the updated permission information to the first distributed ledger.

[0010] Based on the above structure, the updated permission information is stored in the first distributed ledger, so the updated permission information can be shared with multiple other server devices included in the data sharing system. Therefore, by monitoring the permission information through all devices (server devices and multiple other server devices) included in the data sharing system, the tamper-resistance of the permission information can be improved.

[0011] (4) In one embodiment, the server device provides a first application for providing a predetermined service. The first application is installed on a user's terminal device. The terminal device provides the server device with user information related to the user entered during the installation of the first application. When the control device obtains the user information, it sets the server device in the permission information for the user information and saves the permission information to the first distributed ledger.

[0012] The user of the terminal device provides user information to the server device providing the first application. Based on the above structure, the server device's permission information is stored in the first distributed ledger, thus enabling multiple other server devices to share the permission granted to the server device to access user information.

[0013] (5) In one embodiment, the predetermined service includes a user verification service. User information includes the user's personal information. When the control device obtains user information, it performs a user verification service on the user information and saves the verified user information to the second distributed ledger.

[0014] Based on the above structure, user information that has been confirmed by the user is saved in the second distributed ledger, thus preventing the sharing of user information with other server devices that do not have the permission to access user information.

[0015] (6) In one embodiment, the control device saves information indicating the implementation result of the personal confirmation service to the first distributed ledger.

[0016] According to the above structure, information indicating the implementation result of the self-confirmation service is stored in the first distributed ledger, so the updated permission information can be shared with multiple other server devices. Therefore, by monitoring the information indicating the implementation result of the self-confirmation service through all devices included in the data sharing system, the tamper resistance of the information indicating the implementation result of the self-confirmation service can be improved.

[0017] (7) In one embodiment, the first application includes a second application. The second application is an application provided by a predetermined server device among a plurality of other server devices. When registering for the use of the second application, the first application requests the terminal device's consent regarding sharing user information with the second application. Upon obtaining consent, the control device adds the predetermined server device to the permission information.

[0018] According to the above structure, upon obtaining consent regarding the sharing of user information with the second application, a predetermined server device is appended to the permission information. This permission information is stored in the first distributed ledger. Therefore, the permission information of the pre-added server device can be shared with multiple other server devices.

[0019] (8) In one embodiment, the control device shares user information stored in the second distributed ledger with the predetermined server device based on the permission information of the predetermined server device that has been added.

[0020] According to the above structure, with the addition of a predetermined server device to the permission information, user information can be shared with the predetermined server device.

[0021] (9) In one embodiment, when the second application has applied for exit registration, the control device deletes the predetermined server device from the permission information.

[0022] Based on the above structure, upon the second application's request to exit registration, the designated server device providing the second application is removed from the permission information. This updated permission information is saved to the first distributed ledger, thus enabling the updated permission information to be shared with multiple other server devices.

[0023] (10) In one embodiment, a control device is also provided for updating the first distributed ledger and the second distributed ledger. When a server device is added to the authorization information, the control device obtains the data from another server device that has the data and saves it to the second distributed ledger.

[0024] Based on the above structure, when the permission information is appended to itself (the server device), it is possible to obtain data corresponding to the permission information from other server devices that have the data.

[0025] (11) In one embodiment, when the server device is removed from the permission information, the control device deletes the data corresponding to the permission information from the second distributed ledger.

[0026] Based on the above structure, if the permission to retain the data of itself (the server device) is lost, the data can be appropriately deleted from the second distributed ledger.

[0027] (12) In one embodiment, the server device provides a second application included in a first application provided by a predetermined server device, which is one of a plurality of other server devices. The first application is an application that provides a user verification service. Information indicating the implementation result of the user verification service performed by the predetermined server device is stored in a first distributed ledger. When registering for the use of the second application, the control device omits the user verification implementation by referring to the information indicating the implementation result of the user verification service.

[0028] According to the above structure, by utilizing the implementation results of the self-verification service implemented by the predetermined server device for providing the first application using the first distributed ledger share, the implementation of self-verification is omitted. This reduces the time spent on implementing self-verification.

[0029] The above and other objects, features, situations and advantages of the present invention will become more apparent from the following detailed description relating to the invention, as understood in conjunction with the accompanying drawings. Attached Figure Description

[0030] Figure 1 This is a diagram illustrating the general structure of the data sharing system involved in the implementation.

[0031] Figure 2 It is a diagram used to illustrate the hardware structure of the management server.

[0032] Figure 3 It is a diagram used to illustrate the hardware structure of the service server.

[0033] Figure 4 It is a diagram used to illustrate the hardware structure of the client device.

[0034] Figure 5 It is a diagram that roughly illustrates the system architecture of a data sharing system.

[0035] Figure 6 This is a diagram illustrating the flow of information during the processing performed when a wallet app is installed on a client device.

[0036] Figure 7 This is a diagram illustrating the flow of information during the process performed when registering the first app within the Wallet app.

[0037] Figure 8 This is a diagram schematically illustrating the flow of information during the process performed when the 1st APP exits registration.

[0038] Figure 9 This is a flowchart illustrating the process performed when installing a wallet app on a client device.

[0039] Figure 10 This is a flowchart illustrating the process performed during the registration of the first APP.

[0040] Figure 11 This is a flowchart illustrating the process performed when the first APP (first service) is deregistered.

[0041] Figure 12 This is a diagram schematically illustrating the flow of information during the processing performed when a wallet app is installed on a client device, as shown in a variant example. Detailed Implementation

[0042] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Furthermore, the same or equivalent parts in the drawings will be marked with the same reference numerals, and their descriptions will not be repeated.

[0043] [Implementation Method]

[0044] <Overall Structure of the Data Sharing System>

[0045] Figure 1 This is a diagram illustrating a schematic structure of the data sharing system 1 according to this embodiment. The data sharing system 1 according to this embodiment is a system for forming a consortium network (hereinafter also referred to as "network") NW among multiple enterprises and sharing data using distributed ledger technology.

[0046] The data sharing system 1 comprises a management server 2, four service servers 3-1 to 3-4, client devices 4, and an APP providing server 5. The four service servers 3-1 to 3-4 each belong to different companies (e.g., Company A, Company B, Company C, and Company D). For example, service server 3-1 belongs to Company A, service server 3-2 belongs to Company B, service server 3-3 belongs to Company C, and service server 3-4 belongs to Company D. Hereinafter, without specifically distinguishing between the individual service servers 3-1 to 3-4, they will be collectively referred to as "Service Server 3".

[0047] Management server 2 is a server belonging to the management enterprise operating network NW. Management server 2 manages network NW. Management server 2 accepts participation requests from each service server 3 to network NW. Management server 2 authorizes service servers 3 to participate in network NW (the function of gatekeeper nodes described below) based on the authorization operation made by the administrator of management server 2, or based on the determination result of predetermined conditions. In this embodiment, participation in network NW is authorized for the four service servers 3 belonging to enterprises A, B, C, and D respectively.

[0048] Additionally, management server 2 manages app provider server 5. App provider server 5 is the so-called app store. Management server 2 provides wallet app 50 within app provider server 5.

[0049] The APP providing server 5 is configured to communicate with the client device 4. The APP providing server 5 provides applications to the client device 4. The client device 4 can access the APP providing server 5 and install the applications provided on the APP providing server 5. In this embodiment, the APP providing server 5 provides a wallet APP 50. The client device 4 can install the wallet APP 50 from the APP providing server 5. Furthermore, this embodiment describes an example where the APP providing server 5 provides one application (wallet APP 50), but the APP providing server 5 can also provide multiple applications.

[0050] Wallet App50 is an application that provides KYC (Know Your Customer) services. In addition to KYC, Wallet App50 can also offer a variety of other services.

[0051] Wallet App 50 is a so-called super app, comprising App 1 51, App 2 52, App 3 53, and App 4 54 as so-called mini apps. App 1 51 is an application used to utilize the first service provided by Company A, which operates on management service server 3-1. Company A's service server 3-1 distributes and registers App 1 51 as a mini app to Wallet App 50. App 2 52 is an application used to utilize the second service provided by Company B, which operates on management service server 3-2. Company B's service server 3-2 distributes and registers App 2 52 as a mini app to Wallet App 50. App 3 53 is an application used to utilize the third service provided by Company C, which operates on management service server 3-3. Company C's service server 3-3 distributes and registers App 3 53 as a mini app to Wallet App 50. App 4 54 is an application used to utilize the fourth service provided by Company D, which operates on management service server 3-4. Company D's service server 3-4 distributes and registers App 4 54 as a mini app to Wallet App 50.

[0052] Apps 1 through 4 (51 through 54) are each developed using the architecture of wallet app 50. Each of Apps 1 through 54 can also operate within the browser of wallet app 50, collaborating with the API (Application Program Interface) 210 of management server 2 and the APIs 310-1 through 310-4 of service servers 3-1 through 3-4 to provide the services offered by service servers 3-1 through 3-4 (Service 1 through Service 4). Each of Services 1 through 4 can be, for example, any service such as car rental, car sharing, insurance, administrative services, car dealership services, or repair services.

[0053] Client device 4 is, for example, a smartphone, tablet, desktop PC (Personal Computer), laptop PC, or other information processing terminal with communication capabilities. Client device 4 can launch App 1 51, App 2 52, App 3 53, and App 4 54 from the installed Wallet App 50, utilizing the services provided by each enterprise (service servers 3-1 to 3-4). As explained in detail later, upon initial launch of each mini-app (during registration), consent is obtained regarding the provision of user information, including the personal information of the user of client device 4, to the service server 3, which is the source of the application.

[0054] Two distributed ledger-based software packages are imported into both management server 2 and service server 3. The first distributed ledger-based software package (hereinafter referred to as "the first software") includes smart contracts that function as nodes building a broadcast-type main chain. The second distributed ledger-based software package (hereinafter referred to as "the second software") includes smart contracts that function as nodes building a P2P (Peer-to-Peer) type sub-chain. For example, CORDA (registered trademark) can be used as the second distributed ledger-based software package. The imported first software enables functionality in the control device 21 contained in management server 2. Figure 2 ) and the control device 31 included in the service server 3 ( Figure 3 ) respectively serve as main chain node 200A ( Figure 2 ) and main chain node 300A ( Figure 3 The second software, which is imported, enables the control device 21 contained in the management server 2 to perform its functions. Figure 2 ) and the control device 31 included in the service server 3 ( Figure 3 ) respectively as child chain node 200B ( Figure 2 ) and sub-chain node 300B ( Figure 3 To fulfill its function.

[0055] Furthermore, the control device 21 included in the management server 2 ( Figure 2 ) and the control device 31 included in the service server 3 ( Figure 3 They also serve as off-chain nodes 200C for processing outside of network NW. Figure 2 ) and off-chain node 300C ( Figure 3 ) to perform its function. Figure 1 In the code, the main chain node 200A, the sub-chain node 200B, and the off-chain node 200C are collectively referred to as "node 200", and the main chain node 300A, the sub-chain node 300B, and the off-chain node 300C are collectively referred to as "node 300".

[0056] Management server 2 has distributed ledger group 270. Service server 3 has distributed ledger group 370. Distributed ledger group 270 and distributed ledger group 370 have the same data structure. Therefore, the following description focuses on distributed ledger group 270.

[0057] Distributed ledger group 270 includes: Distributed ledger 271 ( Figure 2 ), and the transaction data shared in the main chain; and the distributed ledger 272 ( Figure 2 ), which is the transaction data shared in the subchain.

[0058] Distributed ledger 271 is a distributed ledger that stores shared transaction data within a broadcast-type main chain and is publicly accessible to all main chain nodes participating in the network NW. Specifically, management server 2 possesses distributed ledger 271, and service server 3-1 possesses distributed ledger 371-1. Figure 3 ), server 3-2 has a distributed ledger 371-2 ( Figure 3 ), server 3-3 has a distributed ledger 371-3 ( Figure 3 ) and the distributed ledger 371-4 possessed by service servers 3-4 ( Figure 3 They retain the same transaction data.

[0059] Distributed ledger 272 is a distributed ledger that stores shared transaction data within a P2P sub-chain, with its public access limited to the parties involved. Details will be discussed later. Regarding distributed ledger 272, its public access is limited based on the permission information (consent information) stored in the main chain (distributed ledger 271). Therefore, the distributed ledger 272 possessed by management server 2 and the distributed ledger 372-1 possessed by service server 3-1 (… Figure 3 ), server 3-2 has a distributed ledger 372-2 ( Figure 3 ), server 3-3 has a distributed ledger 372-3 ( Figure 3 ) and the distributed ledger 372-4 possessed by service server 3-4 ( Figure 3 It can maintain different transaction data.

[0060] Furthermore, the control device 21 included in the management server 2 functions through software stored in ROM (Read Only Memory). Figure 2 The platform provider 60 functions as a platform provider. The platform provider 60 has the function of managing the network NW. The platform provider 60 includes a gatekeeper node 61, a network mapping node 63, and a notary node 65.

[0061] Gatekeeper node 61 approves the participation application from node 300, which wishes to join network NW. Additionally, gatekeeper node 61 issues a certificate to node 300. Node 300, upon joining network NW, creates a secret key and public key pair and sends a certificate request to gatekeeper node 61. Gatekeeper node 61 verifies pre-determined conditions and issues a certificate to node 300 that has requested it.

[0062] Network mapping node 63 stores information (e.g., IP addresses) of nodes 300 that have been granted certificates (i.e., permission to participate in the network NW) by gatekeeper node 61. Network mapping node 63 functions as a DNS (Domain Name System) within the network NW. Nodes 200 and 300, for example, identify the destination of transaction data based on information provided by network mapping node 63.

[0063] Notary node 65 provides finality for transaction data in the subchain. When nodes 200 (subchain node 200B) and 300 (subchain node 300B) generate transaction data, they send data including the hash value of the transaction data and the index of the output of the transaction data to notary node 65. Notary node 65 ensures the order of transaction data in the subchain by sequentially maintaining the aforementioned data received from node 200 or node 300.

[0064] Figure 2 This diagram illustrates the hardware structure of management server 2. Management server 2 includes a control device 21, ROM 22, RAM (Random Access Memory) 23, a communication device 24, an input device 25, a display device 26, and a storage device 27. The control device 21, ROM 22, RAM 23, communication device 24, input device 25, display device 26, and storage device 27 are connected to bus 29.

[0065] The control device 21 is, for example, composed of an integrated circuit including a CPU (Central Processing Unit). The control device 21 expands and executes various programs stored in the ROM 22 in the RAM 23. These programs include the operating system, etc. The RAM 23 functions as working memory, temporarily storing various data required for the execution of the various programs. As will be explained in detail later, the control device 21 includes a main chain node 200A functioning as the main chain, a sub-chain node 200B functioning as a sub-chain, and a sub-chain node 200C functioning as an off-chain node (outside the network NW). Furthermore, the control device 21 includes the aforementioned platform provider 60, which functions within the network NW.

[0066] The communication device 24 is configured to communicate with external machines. These external machines may include, for example, a service server 3, a client device 4, and an application providing server 5. Communication between the communication device 24 and the external machines utilizes the Internet, a wide area network (WAN), a local area network (LAN), an Ethernet network, a public network, a private network, a wired network, or a wireless network, or a combination thereof.

[0067] Input device 25 includes input devices. Input devices may be, for example, a mouse, keyboard, touch panel, and / or other devices capable of accepting user operations.

[0068] Display device 26 includes a display. Display device 26 displays various images on the display according to control signals from control device 21. The display may be, for example, a liquid crystal display (LCD), an organic EL (Electroluminescence) display, or other display equipment.

[0069] Storage device 27 is configured, for example, to include a storage medium such as a hard disk or flash memory. Storage device 27 stores a distributed ledger set 270, a secret key 275, and multiple public keys 277. Details regarding distributed ledger set 270 and distributed ledger set 370 (described later) will be explained later.

[0070] Secret key 275 is the secret key of the management enterprise that manages management server 2. For example, when management server 2 initially forms a network, control device 21 generates a secret key and a public key. Furthermore, control device 21 sends the generated public key to an authentication authority (not shown) for authentication. The authentication authority is a certification body that issues electronic certificates. The authentication authority issues electronic certificates that include information from the public key. Control device 21 stores the secret key 275 corresponding to the authenticated public key in storage device 27. Additionally, control device 21 sends the authenticated public key (electronic certificate) to service servers 3-1 to 3-4 participating in network NW.

[0071] Multiple public keys 277 include the public keys of Company A, Company B, Company C, and Company D. Control device 21 stores the public keys received from service server 3 into storage device 27. Additionally, storage device 27 can also store its own (managing company's) public keys.

[0072] When generating transaction data, the control device 21 uses the secret key 275 to create an electronic signature and includes the electronic signature in the transaction data. Furthermore, when receiving transaction data from the service server 3, the control device 21 uses the public key of the source that sent the transaction data, one of the multiple public keys 277, to verify the validity of the electronic signature.

[0073] Figure 3 This diagram illustrates the hardware structure of service server 3. Service servers 3-1 to 3-4 have essentially the same hardware structure. Figure 3 In the explanation, if it is determined which company's service server 3 belongs to, the example of service server 3-1 of company A will be used for explanation.

[0074] The service server 3 includes a control device 31, a ROM 32, a RAM 33, a communication device 34, an input device 35, a display device 36, and a storage device 37. The control device 31, ROM 32, RAM 33, communication device 34, input device 35, display device 36, and storage device 37 are connected to a bus 39.

[0075] The control device 31 is, for example, composed of an integrated circuit including a CPU. The control device 31 expands and executes various programs stored in the ROM 32 in the RAM 33. These programs include the operating system, etc. The RAM 33 functions as working memory, temporarily storing various data required for the execution of the various programs. The control device 31 includes a main chain node 300A functioning as the main chain, a sub-chain node 300B functioning as a sub-chain, and a sub-chain node 300C functioning as an off-chain node (outside the network NW).

[0076] The communication device 34, input device 35 and display device 36 have essentially the same structure as the communication device 24, input device 25 and display device 26 of the management server 2, so their descriptions will not be repeated.

[0077] Storage device 37 may be configured as a storage medium including, for example, a hard disk or a flash memory. Storage device 37 stores a distributed ledger set 370, a secret key 375, and multiple public keys 377.

[0078] Secret key 375-1 is the secret key of Company A, which manages service server 3-1. For example, when service server 3-1 of Company A initially joins network NW, control device 31-1 generates a secret key and a public key. Furthermore, control device 31-1 sends the generated public key to an authentication station (not shown) for authentication. Control device 31-1 stores the secret key 375-1 corresponding to the authenticated public key in storage device 37-1. Additionally, control device 31-1 sends the authenticated public key (electronic certificate) to gatekeeper node 61 for certificate granting. This certificate contains transaction data issued by service server 3-1. Furthermore, control device 31-1 sends the authenticated public key (electronic certificate) to management server 2 and service servers 3-2 to 3-4 that form network NW.

[0079] Multiple public keys 377-1 include the public key of the managing enterprise, the public key of enterprise B, the public key of enterprise C, and the public key of enterprise D. The control device 31-1 stores the public keys received from the management server 2 and the service servers 3-2 to 3-4 into the storage device 37-1. In addition, the storage device 37-1 can also store its own (enterprise A) public key.

[0080] When generating transaction data, control device 31-1 uses secret key 375-1 to create an electronic signature and includes the electronic signature in the transaction data. Additionally, when receiving transaction data from management server 2 or service servers 3-2 to 3-4, control device 31-1 uses the public key of the source sending the transaction data from among multiple public keys 377-1 to verify the validity of the electronic signature.

[0081] Figure 4 This diagram illustrates the hardware structure of client device 4. Client device 4 includes a control device 41, ROM 42, RAM 43, communication device 44, input device 45, display device 46, and storage device 47. The control device 41, ROM 42, RAM 43, communication device 44, input device 45, display device 46, and storage device 47 are connected to bus 49.

[0082] The control device 41 is, for example, composed of an integrated circuit including a CPU. The control device 41 expands and executes various programs stored in the ROM 42 in the RAM 43. These programs include the operating system, etc. The RAM 43 functions as working memory, temporarily storing various data required for the execution of the programs. The control device 41 has the function of installing applications from the APP provider server 5 or executing installed applications via the communication device 44.

[0083] The communication device 44 and the display device 46 have essentially the same structure as the communication device 24 and the display device 26 of the management server 2, so their description will not be repeated.

[0084] Input device 45 includes input devices. Input devices may be, for example, a mouse, keyboard, touch panel, and / or other devices capable of accepting user operations. Additionally, input device 45 may also include information acquisition devices such as a camera or scanner.

[0085] Storage device 47 is configured to include, for example, a storage medium such as a hard disk or flash memory. Storage device 47 stores applications installed from the APP providing server 5. In this embodiment, a wallet APP 50 is stored in storage device 47.

[0086] <Using Wallet Apps and Mini Apps>

[0087] In the data sharing system 1 with the structure described above, the wallet APP 50 (super APP) installed on the client device 4 can be used through user information registration and user identity verification (KYC). Furthermore, in order to use the mini-APPs (APP 1 to APP 4 54) of the wallet APP 50, user information is provided to the company providing the mini-APP (e.g., company A in APP 1 51), requiring that company to conduct KYC. For example, when a user registers to use APP 1 51, user information is requested to be provided to service server 3-1 (company A), while service servers 3-2 to 3-4 (company B, company C, and company D) do not require the provision of user information. Generally, in distributed ledger technologies such as blockchain, data is shared among all nodes participating in the network, so it is not possible to share data only between specific nodes. It is desirable to use distributed ledger technology to improve data tamper resistance while sharing data only between specific nodes. In addition, regarding KYC, the implementation practices of each service server 3 (each company) that provides the mini-app are troublesome for both the companies and the users, and countermeasures are required.

[0088] Therefore, in the data sharing system 1 of this embodiment, the KYC results conducted by the super app management company (management server 2) are saved to the main chain and shared with participants in the network NW. When a mini-app application is submitted, each company providing the mini-app can verify the KYC results on the main chain, thus confirming the user's identity and eliminating the need for its own KYC verification.

[0089] Furthermore, companies accepting applications to use the mini-app need user information in order to provide services. In the data sharing system 1 of this embodiment, the user information entered when registering user information with the wallet app 50 is saved to the distributed ledger 272 (sub-chain) of the management server 2 after KYC service is implemented. When the user of the client device 4 agrees to provide user information to the mini-app, the user information stored in the distributed ledger 272 is shared with the distributed ledger 372 of the service server 3 providing the mini-app through the sub-chain.

[0090] Figure 5 This is a diagram that roughly illustrates the system architecture of data sharing system 1. (Refer to...) Figure 5 And as will be discussed later Figures 6-8 This explains the series of processes from registering to deregistering for the Wallet App and Mini App.

[0091] <<Wallet App Installation: KYC>>

[0092] Figure 6This is a diagram schematically illustrating the flow of information during the processing performed when installing the wallet app 50 on client device 4. (See reference...) Figure 5 as well as Figure 6 When wallet app 50 is installed on client device 4, wallet app 50 (app provider server 5) requires client device 4 to register an account. Control device 41 of client device 4 generates a secret key and a public key according to the account registration requirements. Control device 41 can also send the generated public key to an authentication station (not shown) for authentication. Control device 41 stores the secret key corresponding to the authenticated public key in storage device 47. The authenticated public key is also used as the ID of client device 4 (user) in the main chain, as explained later.

[0093] Next, the wallet app 50 requests user information registration from the client device 4. The control device 41 of the client device 4, for example, displays the user information input field on the display screen of the display device 46. The user information includes, for example, name, date of birth, address, and age. The user inputs the name, date of birth, address, and age via the input device 45. Furthermore, the user information also includes information for self-verification. This information may be, for example, a driver's license, personal identification number card, or health insurance card. The user may, for example, photograph their driver's license using a camera included in the input device 45 and register the information as user information.

[0094] The registered user information is sent to the APP providing server 5 via the communication device 44 of the client device 4. The APP providing server 5 accesses the API 210 of the management server 2 that implements the KYC service and sends the KYC implementation request along with the user information to the management server 2. In addition, the public key information of the client device 4 is also sent from the client device 4 to the management server 2 via the APP providing server 5. Furthermore, the APP providing server 5 can also verify whether the user information input is missing, and / or whether the size of the image data such as the driver's license is within the range determined for implementing the KYC service.

[0095] Upon receiving a KYC request, management server 2 performs the KYC service. Furthermore, management server 2 saves the KYC-verified user information to distributed ledger 272 to update the subchain, and issues the user ID (hereinafter referred to as "user ID") of client device 4 to the main chain. The KYC result, associated with the user ID, is then saved to distributed ledger 271 to update the main chain.

[0096] Specifically, upon receiving a KYC (Know Your Customer) request, the off-chain node 200C of control device 21 functions. The off-chain node 200C uses the acquired user information to perform KYC. During the KYC process, the administrator of management server 2, sales personnel of the company operating management server 2, etc., can also participate. When the KYC result indicates that the individual has confirmed there are no issues, the off-chain node 200C outputs a message indicating the completion of KYC to the child node 200B.

[0097] When information indicating KYC completion is received, the sub-chain node 200B of control device 21 functions. Sub-chain node 200B generates transaction data for updating the sub-chain. At this point, the user of client device 4 agrees to provide user information to wallet APP 50, but disagrees to provide user information to the mini-app within wallet APP 50. Therefore, at this point, the user information is only saved to the distributed ledger 272 of management server 2, and not to the distributed ledgers 372-1 to 372-4 of service servers 3-1 to 3-4. Therefore, the transaction data includes user information, and the destination of the transaction data is specified as management server 2. Furthermore, the transaction data includes a hash value of the user information (hereinafter also referred to as "data hash"). Sub-chain node 200B processes this transaction data, saving the user information and the data hash to distributed ledger 272. Saving the data hash to distributed ledger 272 reduces the time required to generate the hash value of the user information each time the consent information (permission information) described later is updated. Figure 5 In this process, user information and data hashes are recorded as "DataA". As mentioned above, at this point in time, DataA is only saved to the distributed ledger 272 of management server 2.

[0098] When the subchain is updated, the main chain node 200A of control device 21 functions. Main chain node 200A generates transaction data for updating the main chain. Specifically, main chain node 200A generates transaction data including a data hash, consent information, and information indicating the KYC confirmation result. The destination of the transaction data is specified as all nodes forming the main chain (main chain node 200A and main chain nodes 300A-1 to 300A-4). Additionally, the information indicating the owner of the transaction data includes the hash value of the public key of client device 4. This transaction data is broadcast to network NW and processed by main chain node 200A of management server 2 and main chain node 300A of service server 3, thereby issuing the hash value of the public key of client device 4 as the ID of client device 4 (hereinafter also referred to as "user ID") to the main chain. Furthermore, the data hash, consent information, and information indicating the KYC confirmation result are saved to the main chain (distributed ledger 271 and distributed ledger 371) in association with the user ID.

[0099] Consent information (permission information) is used to determine the scope of sharing user information, including information on "who (From)," "to whom (To)," and "which data (Hash) is being consented to." Specifically, consent information includes information indicating the source of consent (From), the destination of consent (To), and the data that becomes the object (Hash). In the example above, the information indicating the source of consent is, for example, the user ID (the hash value of the public key of client device 4). The information indicating the destination of consent is, for example, the ID of management server 2 used to determine information about management server 2 (e.g., the hash value or address of the public key of management server 2). The information indicating the data that becomes the object is, for example, the hash value of the user information (data hash).

[0100] The KYC verification result information indicates the outcome of the KYC process, including information such as "Who (From)," "Whose (To)," and "Which data was verified (Hash)." Specifically, the KYC verification result information includes information indicating the KYC implementer (From), information indicating the KYC recipient (To), and information indicating the data that became the KYC recipient (Hash). In the example above, the information indicating the KYC implementer is, for example, the ID of management server 2 used to determine management server 2's information (e.g., the hash value or address of management server 2's public key). The information indicating the KYC recipient is, for example, the user ID (the hash value of client device 4's public key). The information indicating the data that became the KYC recipient is, for example, the hash value of the user information (data hash).

[0101] As described above, along with the installation of the wallet app 50 on the client device 4, the management server 2 (management enterprise) providing the wallet app 50 performs KYC on the user. Furthermore, the user information is stored in the distributed ledger 272 of the management server 2. Subsequently, a user ID is issued to the main chain, and the KYC result, the hash value of the user information (data hash), and consent information are stored in the main chain (distributed ledger 271 and distributed ledgers 371-1 to 371-4) in a form associated with the user ID.

[0102] <<Mini App Usage Registration: Omission of KYC>>

[0103] Figure 7 This is a diagram illustrating the flow of information during the processing performed when registering (first-time use) the first app 51 within the wallet app 50. Figure 7 In this example, we will use APP51, a mini-app, as an example. (See reference...) Figure 5 as well as Figure 7As a premise, Company A, which decides to provide the first service, will provide (distribute) APP51 as a mini-APP of Wallet APP50. Therefore, APP51 is provided as a mini-APP of Wallet APP50.

[0104] For example, a user of client device 4 launches wallet app 50 and selects app 51 displayed on display device 46. Upon initial use (activation) of app 51, wallet app 50 (app provider server 5) requests user registration for app 51 from the user of client device 4. Specifically, wallet app 50 requests user information from app 51 (service server 3-1 providing the first service) from the user of client device 4. In response to this request, control device 41 of client device 4 displays a screen requesting consent to provide user information to app 51 (service server 3-1 providing the first service) on display device 46. The user of client device 4 then operates input device 45 to consent to providing user information to app 51.

[0105] The control device 41 of the client device 4 sends information indicating the user's consent to provide user information (indicating consent) to the APP providing server 5 via the communication device 44. The APP providing server 5 then sends the consent information to the management server 2.

[0106] When management server 2 receives consent information, it updates the consent information on the main chain. Furthermore, based on the updated consent information, it sends user information to service server 3-1 in the sub-chain.

[0107] Specifically, upon receiving a message indicating consent, the off-chain node 200C of the control device 21 functions to notify the main chain node 200A that it has received the message indicating consent.

[0108] Upon receiving the aforementioned notification, main chain node 200A updates the consent information. Specifically, it generates transaction data that includes consent information appended to the information indicating the destination of consent, along with the ID of service server 3-1 (e.g., a hash of the public key or address of service server 3-1). That is, the information indicating the destination of consent included in this consent information includes the ID of management server 2 and the ID of service server 3-1. Main chain node 200A broadcasts the generated transaction data to network NW. This transaction data is processed by main chain nodes 200A and 300A, thereby updating distributed ledgers 271 and 371. Thus, the consent information stored on the main chain is updated.

[0109] When the consent information in the distributed ledger 271 (main chain) is updated, the child chain node 200B confirms the content of the updated consent information. Through this confirmation, the child chain node 200B identifies that it has acquired the right to access user information from the service server 3-1. As described above, the hash value is stored in the information (Hash) representing the data that constitutes the consent information. In this embodiment, the distributed ledger 272 stores not only user information but also data hashes. Therefore, when performing the above confirmation, the child chain node 200B does not need to re-hash the user information and can determine the user information shared by the child chain node 300B with the service server 3-1.

[0110] Sub-chain node 200B generates transaction data containing user information and data hashes. The destination of this transaction data is specified as sub-chain node 300B-1 of service server 3-1.

[0111] Furthermore, when sub-chain node 200B generates transaction data to be sent to sub-chain node 300B-1 of service server 3-1, it sends data including the hash value of the transaction data and the index of the output of the transaction data to notary node 65. This provides finality for the transaction data.

[0112] Service server 3-1's child node 300B-1 processes transaction data received from management server 2's child node 200B and saves user information to the distributed ledger 372-1. Thus, user information is synchronized (shared), and the child chain is updated. Furthermore, at this time, transaction data is not sent to service servers 3-2 to 3-4's child nodes 300B-2 to 300B-4. Figure 5 As shown, DataA is also saved to the distributed ledger 372-1 of the service server 3-1, resulting in the state where DataA is kept in the distributed ledger 272 of the management server 2 and the distributed ledger 372-1 of the service server 3-1.

[0113] When user information is synchronized to distributed ledger 372-1, the main chain node 300A-1 of service server 3-1, referencing the main chain (distributed ledger 371-1), confirms the hash value (data hash) and KYC result of the synchronized user information. Specifically, main chain node 300A-1 instructs distributed ledger 371-1 to query the hash value of the synchronized user information. The hash value of the user information can be generated by main chain node 300A-1 or can use the data hash stored in distributed ledger 372-1. Through the above query, main chain node 300A-1 determines the user ID associated with the data hash. Moreover, by referring to the consent information associated with the determined user ID, main chain node 300A-1 can confirm that the user information synchronized to distributed ledger 372-1 is authorized user information provided to management server 2 and service server 3-1. Thus, main chain node 300A-1 can recognize that the user information provided to it is appropriate. In addition, by referring to the KYC results associated with the determined user ID, the main chain node 300A-1 can confirm that the management server 2 (management enterprise) has carried out KYC for the user ID.

[0114] After the main chain node 300A-1 confirms that KYC has been implemented, the off-chain node 300C-1 completes the registration for the use of the first service. Thus, the user of client device 4 can use the first service via APP 51.

[0115] Furthermore, the above description uses the application registration of APP 151 as an example, but the same applies to the application registration of APP 252 to APP 454.

[0116] <<Mini App Logout>>

[0117] Figure 8 This is a diagram schematically illustrating the flow of information during the process performed when the user exits registration in APP51.

[0118] Reference Figure 5 as well as Figure 8 The user of client device 4 submits a request to exit the first app (first service) from wallet app 50. The exit request includes a request (deletion request) to delete user information from the first app 51 (service server 3-1). The user of client device 4 can submit the exit request, for example, by selecting the exit button displayed on display device 46 when using the first app 51. The exit request is sent to app providing server 5 via communication device 44 of client device 4.

[0119] The app provider server 5 decides to stop providing the first app 51 to the client device 4. Furthermore, the app provider server 5 sends a notification indicating the cessation of service to the management server 2.

[0120] When management server 2 receives a notification indicating the cessation of service provision, it updates the consent information of the main chain (distributed ledger 271). Specifically, upon receiving the notification from APP provider server 5, off-chain node 200C outputs the notification to main chain node 200A. Main chain node 200A removes the ID of service server 3-1 from the consent destination information (To) contained in the consent information, generating transaction data that includes this consent information. That is, the consent destination information contained in the updated consent information only includes the ID of management server 2. Main chain node 200A broadcasts the generated transaction data to the network NW. Through the processing of this transaction data by main chain nodes 200A and 300A, the consent information of the main chain (distributed ledgers 271, 371) is updated.

[0121] When service server 3-1's child node 300B-1 detects that the consent information has been updated and the permission to retain its own user information has disappeared, it deletes the user information (DataA) from the distributed ledger 372-1. Additionally, if the usage information associated with the user's first service usage is stored in the distributed ledger 372-1, child node 300B-1 also deletes that usage information.

[0122] Furthermore, if the off-chain node 200C receives a notification from the APP providing server 5 indicating a halt to service, it can also notify the service server 3-1 of its intention via the communication device 24. Thus, the service server 3-1 can also process the exit registration.

[0123] <Flowchart>

[0124] Figure 9 This is a flowchart illustrating the process performed when installing the wallet app 50 on the client device 4. Figure 9 The process shown in the flowchart begins when client device 4 accesses the APP providing server 5. Furthermore, it is explained... Figure 9 The steps in the flowchart shown (hereinafter referred to as "S") are implemented by software processing controlled by the control device 41 of the client device 4, the APP providing server 5, and the control device 21 of the management server 2. However, some or all of them can also be implemented by hardware (electronic circuits) made in the control device 41, the APP providing server 5, and the control device 21.

[0125] In S10, a user operation is performed on the client device 4 to install the wallet APP 50. In response to this user operation, the control device 41 of the client device 4 installs the wallet APP 50 from the APP providing server 5.

[0126] In S12, the control device 41 of client device 4 is requested to register an account from wallet APP 50 (APP provides server 5). In response to the account registration request, the control device 41 of client device 4 generates a secret key and a public key. The control device 41 can also send the generated public key to an authentication station (not shown) for authentication.

[0127] In S14, the control device 41 of the client device 4 is requested to register user information from the wallet APP 50. In response to the request, the control device 41 of the client device 4 displays the user information input field on the display screen of the display device 46. When the user enters information in the input field, the control device 41 of the client device 4 registers the entered information as user information.

[0128] In S16, the control device 41 of the client device 4 sends the user information and the public key information to the APP provider server 5.

[0129] In S20, the APP provides server 5 with information about user information and public keys obtained from client device 4.

[0130] In S22, in order to cooperate with the KYC service, the APP providing server 5 sends the user information and KYC implementation request obtained in S20 to the management server 2 that implements the KYC service. In addition, the APP providing server 5 also sends the public key information of the client device 4 to the management server 2.

[0131] In S30, the control device 21 of management server 2 responds to the KYC implementation request and implements the KYC service. During the KYC service implementation, the work of the administrator of management server 2, the salesperson of the company operating management server 2, etc., can also be involved. When the result of the KYC implementation determines that the person confirms there are no problems, the control device 21 of management server 2 causes the process to proceed to S32.

[0132] In S32, the control unit 21 of management server 2 generates transaction data for updating the sub-chain. The control unit 21 of management server 2 includes user information and data hashes in the transaction data. Furthermore, the control unit 21 of management server 2 specifies itself (sub-chain node 200B) in the destination of the transaction data. The control unit 21 of management server 2 processes the transaction data, saves the user information and data hashes to the distributed ledger 272, and updates the sub-chain.

[0133] In S34 and S36, the control device 21 of management server 2 generates transaction data for updating the main chain. The control device 21 of management server 2 includes data hash, consent information, and information indicating the KYC confirmation result in the transaction data. Furthermore, the control device 21 of management server 2 specifies all nodes forming the main chain (main chain node 200A and main chain nodes 300A-1 to 300A-4) in the destination of the transaction data. Additionally, the control device 21 of management server 2 includes the hash value of the public key of client device 4 as information indicating the owner of the transaction data. This transaction data is broadcast to network NW and processed by main chain node 200A of management server 2 and main chain node 300A of service server 3, thereby issuing a user ID on the main chain. The data hash, consent information, and information indicating the KYC confirmation result are then saved to the main chain (distributed ledger 271 and distributed ledger 371) in association with the user ID.

[0134] Figure 10 This is a flowchart illustrating the process performed during the registration of the first APP51. Figure 10 The process shown in the flowchart begins with a user action that initiates the first app 51 within the wallet app 50. Furthermore, it is explained... Figure 10 And as will be discussed later Figure 11 The steps in the flowchart shown are implemented through software processing controlled by the control device 41 of the client device 4, the APP providing server 5, the control device 21 of the management server 2, and the control device 31-1 of the service server 3-1. However, some or all of them can also be implemented through hardware (electronic circuits) made within the control device 41, the APP providing server 5, the control device 21, and the control device 31-1.

[0135] In S40, the control device 41 of the client device 4 responds to the user's operation and starts the first APP51 for the first time in the wallet APP50.

[0136] In S50, the APP providing server 5 (wallet APP 50) will return an instruction to the client device 4 to display a confirmation screen requesting consent regarding the provision of user information to service server 3-1, which provides the first APP 51 (first service). The user information referred to here is the user information provided to management server 2 during the installation of wallet APP 50 (e.g., in...). Figure 5 In the example DataA).

[0137] In S42, the control device 41 of the client device 4 displays a confirmation screen according to the instructions from the APP providing server 5 (wallet APP 50).

[0138] In step S44, the user of client device 4 agrees to the confirmation screen. The control device 41 of client device 4 then sends the agreement information to the APP provider server 5.

[0139] In S52, when the APP provides server 5 and confirms that it has obtained the consent information, it sends the consent information to management server 2.

[0140] In S60, when the control device 21 of management server 2 receives information indicating consent, it updates the consent information on the main chain. Specifically, the control device 21 of management server 2 (main chain node 200A) generates transaction data that includes consent information appended to the information indicating the destination of consent, along with the ID of service server 3-1. The control device 21 of management server 2 broadcasts the generated transaction data to the network NW.

[0141] In S70, the control device 31-1 (main chain node 300A-1) of service server 3-1 processes the transaction data obtained from management server 2. As a result, distributed ledger 371-1 is updated. Similarly, distributed ledgers 371-2 to 371-4 are updated by processing the transaction data sent in S60 in service servers 3-2 to 3-4 (main chain nodes 300A-2 to 300A-4). As a result, the consent information stored in the main chain is updated. The updated consent information indicates that the user of client device 4 agrees to provide user information to management server 2 (managing enterprise) and service server 3-1 (enterprise A).

[0142] In S62, the control device 21 of management server 2 identifies the permission to obtain user information from service server 3-1 by updating the consent information of the main chain (distributed ledger 271). The control device 21 (sub-chain node 200B) of management server 2 generates transaction data containing user information and a data hash. The control device 21 (sub-chain node 200B) of management server 2 specifies sub-chain node 300B-1 of service server 3-1 as the destination for sending this transaction data. Furthermore, the control device 21 (sub-chain node 200B) of management server 2 also sends data including the hash value of the transaction data and the index of the transaction data's output to notary node 65.

[0143] In S72, the control device 31-1 (sub-chain node 300B-1) of service server 3-1 processes the transaction data received from management server 2 and saves user information to distributed ledger 372-1. Thus, user information is synchronized and the sub-chain is updated.

[0144] In S74, when user information is synchronized to the distributed ledger 372-1, the control device 31-1 (main chain node 300A-1) of service server 3-1, refers to the main chain (distributed ledger 371-1) to confirm the hash value (data hash) and KYC result of the synchronized user information. Specifically, the control device 31-1 of service server 3-1 instructs the distributed ledger 371-1 to query the hash value of the synchronized user information. Through the query, the control device 31-1 of service server 3-1 determines the user ID associated with the data hash. Furthermore, by referring to the consent information associated with the determined user ID, the control device 31-1 of service server 3-1 can confirm that the user information synchronized to the distributed ledger 372-1 is authorized user information provided to management server 2 and service server 3-1. Thus, the control device 31-1 of service server 3-1 can recognize that the user information provided to it is appropriate. In addition, the control device 31-1 of the service server 3-1 can verify that the management server 2 (management enterprise) has implemented KYC for the user ID by referring to the KYC result associated with the determined user ID.

[0145] When the control device 31-1 of the service server 3-1 confirms that KYC has been implemented, it completes the registration for the use of the first service.

[0146] Figure 11 This is a flowchart illustrating the process performed during the logout registration of APP51 (Service 1). It begins with the user's action of requesting logout from APP51. Figure 11 The flowchart shown illustrates the processing.

[0147] In S80, the control device 41 of the client device 4 responds to the user operation and sends the application for the first APP 51 (first service) to the APP provider server 5 to exit registration.

[0148] In S90, the APP provides server 5 to process the application for deregistration when it receives the application for deregistration from client device 4.

[0149] In S92, the APP providing server 5 decides to stop providing the first APP 51 to the client device 4. Furthermore, the APP providing server 5 sends a notification indicating the cessation of service to the management server 2.

[0150] In S100, when the control device 21 (main chain node 200A) of management server 2 receives a notification indicating that the provision has been stopped, it updates the consent information of the main chain (distributed ledger 271). Specifically, the control device 21 of management server 2 deletes the ID of service server 3-1 from the information (To) indicating the destination of consent contained in the consent information, generates transaction data including the consent information, and broadcasts it to network NW.

[0151] In S110, the control device 31-1 (main chain node 300A-1) of service server 3-1 processes the transaction data obtained from management server 2. As a result, distributed ledger 371-1 is updated. Similarly, by processing the transaction data sent in S110 in service servers 3-2 to 3-4 (main chain nodes 300A-2 to 300A-4), distributed ledgers 371-2 to 371-4 are updated. As a result, the consent information stored on the main chain is updated. The updated consent information indicates that the user permission of client device 4 is only provided to management server 2 (management enterprise) for user information.

[0152] In S112, when the control device 31-1 (sub-chain node 300B-1) of service server 3-1 detects that the consent information has been updated and the permission to retain its own user information has disappeared, it deletes the user information from the distributed ledger 372-1. Additionally, if the usage information associated with the user's first service usage is stored in the distributed ledger 372-1, the control device 31-1 of service server 3-1 also deletes that usage information.

[0153] In S114, the control device 31-1 of the service server 3-1 completes the user's logout registration.

[0154] Furthermore, in S102, the control device 21 of the management server 2 can also notify the service server 3-1 that it has received a notification from the APP providing server 5 indicating that the service has stopped. In response, the control device 31-1 of the service server 3-1 can also process the exit registration.

[0155] As described above, in the data sharing system 1 of this embodiment, when the wallet APP 50 is installed on the client device 4, the management server 2 (management enterprise) performs KYC services. Information indicating the KYC result is saved on the main chain that shares data with all main chain nodes participating in the network NW. Therefore, the information indicating the KYC result is monitored by all main chain nodes participating in the network NW, thus improving tamper resistance.

[0156] Furthermore, during the registration of the mini-app (e.g., APP51) of wallet APP50, the service server 3 (enterprise) providing the mini-app does not perform KYC on the user, but instead confirms the KYC result performed by management server 2 with reference to the main chain. With this confirmation process, service server 3 (enterprise) completes the KYC process. Thus, by referring to the KYC result performed by management server 2, the implementation of KYC can be omitted.

[0157] The service server 3 (enterprise) that receives the application to use the mini-app needs to obtain user information in order to provide the service. In the data sharing system 1 according to this embodiment, based on the user's consent, the user information is synchronized with the service server 3, which has the authority to obtain user information from the management server 2, using a P2P-type sub-chain. By managing the consent information in the broadcast-type main chain, the consent information is monitored by the entire main chain, thus improving the tamper resistance of the consent information. Moreover, based on the consent information shared by the main chain, data synchronization can be performed only between specific sub-chain nodes using the P2P-type sub-chain. In this way, by combining the broadcast-type main chain with the P2P-type sub-chain, it is possible to improve the tamper resistance of the consent information while enabling data synchronization only between specific sub-chain nodes based on the consent information.

[0158] Furthermore, by combining a broadcast-type main chain with a P2P-type sub-chain, it is possible to improve the tamper resistance of consent information while enabling the deletion of data synchronized to specific sub-chain nodes based on the consent information shared by the main chain.

[0159] [Variation Example 1]

[0160] In implementation methods, for example, Figure 6 As shown, a user ID is issued to the main chain at a specific time when KYC results are saved to the main chain. However, the timing of issuing the user ID to the main chain can be different.

[0161] Figure 12 This is a diagram schematically illustrating the flow of information during the processing performed when the wallet app 50 is installed on the client device 4 in a modified example.

[0162] Reference Figure 12 When the wallet app 50 is installed on the client device 4, similarly to the previous implementation, the wallet app 50 (app providing server 5) requires the client device 4 to register an account. The control device 41 of the client device 4 generates a secret key and a public key according to the account registration requirements. The control device 21 may also send the generated public key to an authentication station (not shown) for authentication. The control device 41 stores the secret key corresponding to the authenticated public key in the storage device 47.

[0163] The control device 41 of the client device 4 sends the public key for authentication and the hash value of the public key to the APP provider server 5.

[0164] The APP provides server 5 with the public key and its hash value as the ID for user ID registration.

[0165] When a user's ID registration is complete, the APP provides server 5 with the hash value of the public key and the ID issuance request sent to management server 2.

[0166] When management server 2 receives the hash value of the public key and the ID issuance request, it uses the hash value as the ID to issue a user ID to the main chain. Specifically, when it receives the hash value of the public key and the ID issuance request from the APP providing server 5, the off-chain node 200C performs its function and outputs the hash value of the public key to the main chain node 200A.

[0167] Main chain node 200A generates transaction data for issuing user IDs and broadcasts the generated transaction data to the network NW. By processing this transaction data, the user ID is issued to the main chain.

[0168] The processing and implementation of user information after registration are the same. After implementing KYC services, when saving user information to the sub-chain (distributed ledger 272), the main chain node 200A generates transaction data including data hash, consent information, and information indicating the KYC confirmation result. In this transaction data, the user ID is specified in the information indicating the owner. By processing this transaction data, the data hash, consent information, and information indicating the KYC confirmation result are saved to the main chain (distributed ledger 271 and distributed ledger 371) in a form associated with the user ID.

[0169] Even using a structure that periodically issues user IDs to the main chain as described above, the same effect can be achieved as with the implementation method.

[0170] [Variation Example 2]

[0171] In the implementation method and variation 1, an example of providing APP 51 to APP 54 as mini-APPs as wallet APP 50 was described. However, APP 51 to APP 54 are not provided as mini-APPs but as standalone applications to APP providing server 5. Furthermore, in this case, companies A to D (service servers 3-1 to 3-4) can each set up a server equivalent to APP providing server 5 for providing APP 51 to APP 54.

[0172] Even with the structure described above, when each application (APP51 to APP54) is installed on the client device 4, each service server 3 (service server 3-1 to 3-4) refers to the KYC result implemented by the management server 2 stored in the main chain based on the user ID, thus eliminating the need for KYC implementation. The client device 4 shares the public key used in account registration for wallet APP50 and APP51 to APP54, thereby sharing the user ID (the hash value of the public key) issued to the main chain, allowing reference to the KYC result based on the user ID. Therefore, even with the structure described above, the same effect as the implementation method can be achieved.

[0173] [Variation Example 3]

[0174] In the implementation and variations 1 and 2, the management server 2 has the functions of managing the network NW and implementing KYC services. However, the functions of managing the network NW and implementing KYC services can also be possessed by different servers. In this case, the wallet APP 50 is provided by the service server that provides KYC services.

[0175] Embodiments of the present invention have been described, but the embodiments disclosed herein are merely illustrative in all respects and should not be construed as limiting. The scope of the invention is defined by the claims and is intended to include all modifications within the scope and equivalent meaning of the claims.

Claims

1. A server apparatus for a data sharing system using distributed ledger technology, wherein, The data sharing system includes the server device and multiple other server devices. The plurality of other server devices communicate with the server device respectively. Each of the server device and the plurality of other server devices includes: Storage device, storing a first distributed ledger and a second distributed ledger; and The control device updates the first distributed ledger and the second distributed ledger. The first distributed ledger is configured to share permission information related to data sharing with the plurality of other server devices. The permission information includes information used to limit the permissions of other server devices among the plurality of other server devices that share the data. The second distributed ledger is configured to share the data with the other server devices based on the permission information. The control device of the server device is configured such that: Based on the permission information, the data of the second distributed ledger stored on the server device is sent to the other server devices; and When the permission information is updated, the updated permission information is saved to the first distributed ledger of the server device. The server device is configured to request user information registration from a user's terminal device in order to install a wallet application on the terminal device. The wallet application is a super application used to provide identity verification services. The terminal device is configured to send user information related to the user to the server device via the wallet application, the user information including information for personal verification. The control device of the server device is configured such that: Use the user information to perform the personal confirmation service; The first transaction data, including the user information and the data hash, is saved to the second distributed ledger of the server device, wherein the data hash is the hash value of the user information; Sending second transaction data to the plurality of other server devices, the second transaction data including the data hash, the authorization information, and personal confirmation information indicating the result of the personal confirmation; and The data hash corresponding to the user information, the permission information, and the user confirmation information are saved to the first distributed ledger. The control device of the server device is further configured to: Accept a message sent from the user terminal indicating that the user has agreed to share the user information with the mini-app of the wallet application; The identification information of the first other server device corresponding to the mini-application is appended to the permission information of the first distributed ledger; and The third transaction data is sent to the plurality of other server devices, the third transaction including the permission information appended with the identification information of the first other server device. Each of the other server devices is configured to: update the first distributed ledger and update the permission information stored in the first distributed ledger based on the third transaction data; The control device of the server device is further configured to: send the first transaction data, including the user information and the data hash, to the first other server device according to the permission information for which the identification information of the first other server device has been appended; The first other server device is configured to: query the data hash in the first transaction data from the server device and the data hash stored in the first distributed ledger of the first other server device, determine the user information associated with the data hash, and complete the usage registration corresponding to the mini-application by referring to the user information associated with the data hash, the permission information associated with the user information, and the personal confirmation information stored in the first distributed ledger of the first other server device.

2. The server apparatus according to claim 1, wherein, When the user applies for the exit registration of the mini-application, the control device of the server device deletes the identification information of the first other server device from the permission information.

3. The server apparatus according to claim 1, wherein, When the server device is added to the permission information, the control device of the server device obtains the data from the other server device that has the data and saves it to the second distributed ledger.

4. The server apparatus according to claim 3, wherein, If the server device is removed from the permission information, the control device of the server device deletes the data from the second distributed ledger.

Images