WO2022168192A1 - データ移行装置、データ移行方法、及び、データ移行プログラム - Google Patents

データ移行装置、データ移行方法、及び、データ移行プログラム Download PDF

Info

Publication number
WO2022168192A1
WO2022168192A1 PCT/JP2021/003833 JP2021003833W WO2022168192A1 WO 2022168192 A1 WO2022168192 A1 WO 2022168192A1 JP 2021003833 W JP2021003833 W JP 2021003833W WO 2022168192 A1 WO2022168192 A1 WO 2022168192A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
migration
transaction
unit
distributed ledger
Prior art date
Application number
PCT/JP2021/003833
Other languages
English (en)
French (fr)
Inventor
将也 本庄
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to CN202180092049.2A priority Critical patent/CN116802622A/zh
Priority to DE112021006204.2T priority patent/DE112021006204T5/de
Priority to PCT/JP2021/003833 priority patent/WO2022168192A1/ja
Priority to JP2022572731A priority patent/JPWO2022168192A1/ja
Publication of WO2022168192A1 publication Critical patent/WO2022168192A1/ja
Priority to US18/205,838 priority patent/US20230315719A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2379Updates performed during online database operations; commit processing

Definitions

  • the present disclosure relates to a data migration device, data migration method, and data migration program.
  • a distributed ledger is a technology that shares transactions, which are ledger operation requests, among stakeholders and realizes a shared ledger among stakeholders.
  • a node which is a distributed ledger server owned by each stakeholder, holds at least all past transactions of the node and stakeholders related to the node. can verify shared data, including data from For this reason, distributed ledgers are effective as a means of ensuring the verifiability of shared data.
  • the distributed ledger in operation due to system update or migration, the distributed ledger in operation (source distributed ledger) is replaced with a distributed ledger in the new environment (destination distributed ledger).
  • Patent Document 1 discloses a device that performs data migration by registering data recorded in a source distributed ledger in a destination distributed ledger in response to a transaction for an asset recorded in the ledger.
  • Patent Document 1 migrates only the latest data values recorded in the ledger to the migration destination distributed ledger, and does not migrate the transactions in the migration source distributed ledger. Therefore, according to the method of Patent Literature 1, there is a problem that the migration source distributed ledger must continue to be operated when past transactions are retained.
  • this disclosure provides not only the latest data value recorded in the migration source distributed ledger, but also the data recorded in the migration source distributed ledger.
  • the purpose is to migrate past transactions to the destination distributed ledger.
  • the data migration device is Data corresponding to each creation element created as each element of the migration data, which is data containing one or more elements, based on the migration request to migrate electronic data from the migration source distributed ledger to the migration destination distributed ledger a data acquisition unit that acquires acquired data including from the migration source distributed ledger; a data selection unit that selects and extracts data corresponding to the creation element from the acquired data; a migration order creation unit that creates a migration order for migrating data corresponding to each of the creation elements to the migration destination distributed ledger using data corresponding to the creation elements, the migration data is data corresponding to the migration request; Each said authoring element corresponds to at least a portion of said electronic data.
  • the data acquisition unit acquires acquired data from the migration source distributed ledger
  • the data selection unit extracts data corresponding to the creation elements from the acquired data
  • the migration order creation unit creates each element of the migration data. Determines the transition order of elements. Therefore, when the data corresponding to the creation element includes past transactions recorded in the source distributed ledger, the migration order creating unit determines the order of migrating the data including the transactions.
  • the acquired data may also include the latest data values recorded by the source distributed ledger. Therefore, according to the present disclosure, when migrating electronic data from the migration source distributed ledger to the migration destination distributed ledger, not only the latest data value recorded in the migration source distributed ledger but also the migration source distributed ledger Past transactions recorded by can also be migrated to the destination distributed ledger.
  • FIG. 1 is a diagram showing a configuration example of a data migration system 90 according to Embodiment 1;
  • FIG. 4 is a diagram showing a hardware configuration example of each device included in the data migration system 90 according to the first embodiment;
  • FIG. FIG. 4 is a diagram showing a software configuration example of each device included in the data migration system 90 according to the first embodiment;
  • 4 is a flowchart showing the operation of the data migration system 90 according to Embodiment 1; 4 shows a specific example of a source data acquisition request 501 according to the first embodiment;
  • FIG. FIG. 4 shows a specific example of sorted transaction data 502 according to the first embodiment;
  • FIG. FIG. 5 is a diagram showing a specific example of supplemental data 503 according to the first embodiment;
  • FIG. 5A and 5B show specific examples of a transaction relation graph 504, vertex data 505, and edge data 506 according to the first embodiment;
  • FIG. FIG. 5 shows specific examples of a primary key update history table 507 and a smart contract update history table 508 according to the first embodiment;
  • 4 is a flowchart showing the operation of the transaction-related data creation unit 121 according to Embodiment 1;
  • 4 is a flowchart showing the operation of the transaction-related data creation unit 121 according to Embodiment 1;
  • FIG. 11 shows a specific example of a migration destination data registration request 509 according to the first embodiment;
  • FIG. 4 shows a specific example of migration data 510 according to the first embodiment;
  • FIG. 4 is a flowchart showing the operation of a data creation unit 132 according to Embodiment 1; 4 is a flowchart showing the operation of a data transmission unit 133 according to Embodiment 1;
  • FIG. 2 is a diagram showing a hardware configuration example of a data migration device 1 according to a modification of the first embodiment;
  • FIG. FIG. 10 is a diagram showing a configuration example of a data migration system 90 according to a second embodiment;
  • FIG. FIG. 10 is a diagram showing a hardware configuration example of each device included in the data migration system 90 according to the second embodiment;
  • FIG. 10 is a diagram showing a software configuration example of each device included in the data migration system 90 according to the second embodiment; 9 is a flow chart showing the operation of the data migration system 90 according to the second embodiment; FIG. 11 shows a specific example of a migration destination data registration request 509b according to the second embodiment; FIG. 8 is a flowchart showing the operation of a data creation unit 132 according to Embodiment 2; 8 is a flowchart showing the operation of a data creation unit 132 according to Embodiment 2; 9 is a flowchart showing the operation of a data transmission unit 133 according to Embodiment 2; FIG. 10 is a diagram showing a configuration example of a data migration system 90 according to a third embodiment; FIG. FIG. FIG.
  • FIG. 10 is a diagram showing an example of software configuration of each device included in the data migration system 90 according to the third embodiment; 10 is a flowchart showing the operation of the data migration system 90 according to Embodiment 3; FIG. 11 shows a specific example of a data verification request 511 according to the third embodiment; FIG. 11 is a flowchart showing the operation of a verification unit 163 according to Embodiment 3; 11 is a flowchart showing the operation of a verification unit 163 according to Embodiment 3; The figure which shows the structural example of the data migration system 90 which concerns on Embodiment 4. FIG. FIG. 11 is a diagram showing a hardware configuration example of each device included in the data migration system 90 according to the fourth embodiment; FIG.
  • 11 is a diagram showing an example of software configuration of each device included in the data migration system 90 according to the fourth embodiment; 13 is a flowchart showing the operation of a data acquisition unit 112 according to Embodiment 4; 13 is a flowchart showing the operation of a data transmission unit 133 according to Embodiment 4;
  • FIG. 1 shows a configuration example of a data migration system 90 according to this embodiment.
  • the data migration system 90 includes a data migration device 1, a management device 2, a migration source ledger network 3, and a migration destination ledger network 4, as shown in the figure.
  • the data migration device 1 is also called a data extraction/migration device.
  • the migration source ledger network 3 is also called a migration source distributed ledger network.
  • the destination ledger network 4 is also called a destination distributed ledger network.
  • the data migration device 1 receives a migration request from the management device 2, based on the migration request, appropriately extracts the transaction and the supplementary data 503 from the migration source ledger network 3, and transfers the extracted transaction and the supplementary data 503 to the migration destination ledger. Move to network 4.
  • a migration request is a request to migrate electronic data from a migration source distributed ledger to a migration destination distributed ledger.
  • the term request may also refer to information containing instructions.
  • the data migration device 1 may be an application. An application is also called an application program.
  • the term device is sometimes used as a generic term for devices and applications. Devices are not limited to physical devices, but may be virtual devices generated by virtualization technology.
  • the data migration device 1 can mutually communicate with the management device 2 , at least one migration source node 31 of the migration source ledger network 3 , and at least one migration destination node 41 of the migration destination ledger network 4 .
  • the management device 2 is a device or application that has a function of transmitting a migration request and supplementary data 503 to the data migration device 1 .
  • the management device 2 is also called a management application.
  • the supplementary data 503 is data used when the data migration device 1 creates a transaction for the migration destination ledger network 4 .
  • the migration source ledger network 3 is an active distributed ledger network that records migration transactions.
  • a migration transaction is a transaction to be migrated.
  • the migration source ledger network 3 is composed of one or more migration source nodes 31 .
  • the migration source node 31 is a device or application that records the migration source distributed ledger.
  • the migration destination ledger network 4 is a distributed ledger network that is the migration destination of the migration transaction.
  • the migration destination ledger network 4 is composed of one or more migration destination nodes 41 .
  • the migration destination node 41 is a device or application that records the migration destination distributed ledger.
  • FIG. 2 shows a hardware configuration example of each device included in the data migration system 90.
  • FIG. This figure shows a specific example in which the data migration device 1, the management device 2, the migration source node 31, and the migration destination node 41 each operate in independent devices.
  • Each device is a computer comprising hardware such as a processor 81, a memory 82, an auxiliary storage device 84, a communication interface 83, and the like. These pieces of hardware are appropriately connected via signal lines.
  • Each device is connected via one network. Note that the number of networks included in the data migration system 90 does not have to be one. 31 and between the data migration device 1 and at least one destination node 41 of the destination ledger network 4, respectively, the data migration system 90 may comprise multiple networks. . At least part of the data migration device 1, the management device 2, the migration source node 31, and the migration destination node 41 may be composed of the same device.
  • Each device included in the data migration system 90 may consist of multiple computers.
  • a node is also a device.
  • the processor 81 is an IC (Integrated Circuit) that performs arithmetic processing and controls hardware included in the computer.
  • the processor 81 is, for example, a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or a GPU (Graphics Processing Unit).
  • Each device included in the data migration system 90 may include multiple processors in place of the processor 81 .
  • a plurality of processors share the role of processor 81 .
  • the memory 82 is typically a volatile storage device.
  • the memory 82 is also called main storage or main memory.
  • the memory 82 is, as a specific example, a RAM (Random Access Memory).
  • the data stored in memory 82 is saved in auxiliary storage device 84 as needed.
  • the communication interface 83 is a receiver and transmitter.
  • the communication interface 83 is, as a specific example, a communication chip or a NIC (Network Interface Card).
  • NIC Network Interface Card
  • Auxiliary storage device 84 is typically a non-volatile storage device.
  • the auxiliary storage device 84 is, for example, a ROM (Read Only Memory), an HDD (Hard Disk Drive), or a flash memory. Data stored in the auxiliary storage device 84 is loaded into the memory 82 as needed.
  • Auxiliary storage device 84 stores a data migration program.
  • the data migration program is a program that causes a computer to implement the functions of the units of the data migration device 1 .
  • the data migration program is loaded into memory 82 and executed by processor 81 .
  • the function of each part of each device included in the data migration system is implemented by software.
  • Each part of each device included in the data migration system 90 uses a storage device as appropriate.
  • the storage device comprises at least one of memory 82 , auxiliary storage device 84 , registers within processor 81 , and cache memory within processor 81 as a specific example. Note that data and information may have the same meaning.
  • the storage device may be independent of computer 10 .
  • the functions of memory 82 and auxiliary storage device 84 may be realized by other storage devices.
  • a program that operates on any device described in this specification may be recorded on a computer-readable non-volatile recording medium.
  • a nonvolatile recording medium is, for example, an optical disk or a flash memory.
  • a program that runs on any of the devices described herein may be provided as a program product.
  • FIG. 3 shows an example of the software configuration of each device included in the data migration system 90.
  • a representative who has access authority to at least one migration source node 31 and at least one migration destination node 41 migrates all data.
  • the representative may be a computer or the like.
  • the data migration device 1 includes a data extraction unit 11, a migration order creation unit 12, a data registration unit 13, and a supplementary data management unit 14.
  • the data extraction unit 11 includes an acquisition request reception unit 111 , a data acquisition unit 112 , and a data selection unit 113 .
  • the acquisition request reception unit 111 receives an acquisition request from the management device 2 to acquire the transaction of the source ledger network 3 and the supplementary data 503 related to the transaction from the source distributed ledger.
  • the data acquisition unit 112 acquires data including the transaction and the supplementary data 503 related to the transaction from the migration source ledger network 3 as acquired data.
  • the data acquisition unit 112 acquires the acquisition data from the migration source distributed ledger based on the migration request.
  • Acquiring data from the source distributed ledger is achieved by receiving the data from the source node 31 that records the source distributed ledger.
  • Acquired data includes data corresponding to each created element created as each element of migration data 510 described later.
  • the expression “created element” is an expression for describing an element that has not yet been created as an element of the migration data 510 .
  • the migration data 510 is data including one or more elements, data corresponding to the migration request, and data indicating at least part of the electronic data recorded in the migration source distributed ledger.
  • Each element of the migration data 510 is, as a specific example, data representing vertex data 505, which will be described later.
  • the data corresponding to the creation element is the selected transaction data 502 corresponding to the transaction ID indicated by the vertex data 505 corresponding to the vertex ID that is the creation element. That is, each creation element corresponds to at least a portion of the electronic data migrated from the source distributed ledger to the destination distributed ledger.
  • Supplementary data 503 is at least one piece of data that corresponds one-to-one to at least one piece of data corresponding to the creation element, and assists in migrating the data corresponding to each creation element to the destination distributed ledger. It is the data to
  • the data selection unit 113 selects the acquired data to extract data corresponding to the data that should be included in the migration data 510, and if the acquired data includes the data that should be included in the supplemental data 503, the supplemental data 503 includes the data. Extract the power data.
  • the data selection unit 113 selects and extracts data corresponding to creation elements from the acquired data.
  • the data selection unit 113 may extract data corresponding to the creation element from the acquired data as the selected transaction data 502 .
  • the data selection unit 113 sends data corresponding to the data to be included in the migration data 510 to the transaction-related data creation unit 121 and sends the supplementary data 503 to the supplementary data reception unit 141 .
  • the migration order creating unit 12 includes a transaction-related data creating unit 121 and a transaction-related data recording unit 122, and is also called a transaction order organizing unit.
  • the migration order creation unit 12 uses creation elements to create a migration order for migrating data corresponding to each creation element to a migration destination distributed ledger. If there is supplementary data 503, the migration order creating unit 12 creates the migration order using the data corresponding to the creation element and the supplementary data 503.
  • the data corresponding to the creation element is, as a specific example, the screened transaction data 502 or a set of the screened transaction data 502 and the supplementary data 503 corresponding to the screened transaction data 502 .
  • the transaction-related data creation unit 121 efficiently registers transactions in the migration destination ledger network 4 based on the data extracted by the data selection unit 113 that should be included in the data to be migrated to the migration destination distributed ledger. Transaction-related data that assists in deriving the order is created, and the created transaction-related data is recorded in the transaction-related data recording unit 122 .
  • the transaction relation data creating unit 121 uses the screened transaction data 502 to create transaction relation data based on the relationship between the screened transaction data 502 .
  • Transaction-related data is data that defines the migration order.
  • transaction-related data creation unit 121 creates transaction-related data using selected transaction data 502 and supplementary data 503 .
  • the transaction relationship data creating unit 121 may create a transaction relationship graph 504 as the transaction relationship data.
  • the transaction relationship graph 504 expresses the transition order and transition conditions in a graph structure.
  • the migration condition is a condition for migrating the sorted transaction data 502 to the destination distributed ledger.
  • the data registration unit 13 includes a registration request reception unit 131 , a data creation unit 132 and a data transmission unit 133 .
  • the registration request reception unit 131 receives from the management device 2 a registration request requesting that the data to be migrated be registered in the migration destination distributed ledger.
  • the data creation unit 132 acquires the transaction-related data recorded by the transaction-related data recording unit 122, and uses data that can be registered in the destination distributed ledger at the time of starting transaction generation. Generate transactions for the type ledger.
  • the data creation unit 132 may create each creation element according to the format of each creation element using data corresponding to the creation element.
  • the data creating unit 132 when creating data, if it is necessary to combine the data read from the transaction-related data recording unit 122 and the supplementary data 503 corresponding to the data into one transaction, the supplemental data recording unit 132
  • the corresponding supplementary data 503 is referenced from the unit 142, and the data read from the transaction-related data recording unit 122 and the corresponding supplementary data 503 are combined to generate one transaction.
  • the data creating unit 132 also performs some kind of processing when the data to be migrated read out from the transaction-related data recording unit 122 at the time of data creation registers transactions generated from the data to be migrated in the migration destination ledger network 4. If the data needs to be applied to the migration destination ledger network 4, refer to the corresponding supplementary data 503 from the supplementary data recording unit 142, and transmit the transaction generated from the data to be migrated and the supplementary data 503. It is registered in the migration destination ledger network 4 through the unit 133 and operated.
  • the data creation unit 132 creates data including data representing the screened transaction data 502 or data representing both the screened transaction data 502 and the supplementary data 503 corresponding to the screened transaction data 502 as respective creation elements. , may be created using transaction-related data.
  • the data creation unit 132 may use the graph structure of the transaction relationship graph 504 to extract data corresponding to each creation element that can be registered in the destination distributed ledger as registrable data.
  • the data transmission unit 133 transmits the transaction to the migration destination ledger network 4.
  • the data transmission unit 133 transmits data corresponding to each created element to the migration destination distributed ledger based on the migration order.
  • the data transmission unit 133 may transmit data including registrable data to the destination distributed ledger. Sending data to the destination distributed ledger is realized by sending the data to the destination node 41 that records the destination distributed ledger.
  • the supplemental data management unit 14 includes a supplemental data receiving unit 141 and a supplemental data recording unit 142.
  • the supplemental data receiving unit 141 receives a supplemental data registration request from at least one of the management device 2 and the data selection unit 113, and records the supplemental data 503 in the supplemental data recording unit 142 when the supplemental data registration request is received.
  • the management device 2 includes a migration request unit 21 and a supplemental data registration request unit 22.
  • the migration request unit 21 includes an acquisition request unit 211 and a registration request unit 212.
  • the acquisition request unit 211 requests the data migration device 1 to acquire the transaction and the supplementary data 503 related to the transaction from the migration source ledger network 3, and to create transaction-related data.
  • the registration request unit 212 requests the data migration device 1 to register the data to be migrated to the migration destination ledger network 4 using the created transaction-related data and the supplementary data 503 .
  • the supplemental data registration requesting unit 22 requests the data migration device 1 to register the supplemental data 503 corresponding to the data to be migrated.
  • the migration source node 31 has a function of transmitting data including a transaction and supplementary data 503 related to the transaction to the data migration device 1 in response to a data acquisition request from the data migration device 1 .
  • the migration destination node 41 has a function of registering transaction data in a shared ledger in the migration destination ledger network 4 in response to a transaction registration request from the data migration device 1 .
  • the migration destination node 41 acts with a function of registering the supplementary data 503 in the migration destination node 41 or the migration destination ledger network 4 in response to a request to register the supplementary data 503 from the data migration device 1 or a request to act. and at least one of
  • the operation procedure of the data migration device 1 corresponds to the data migration method.
  • a program that implements the operation of the data migration device 1 corresponds to a data migration program.
  • An operation procedure of the management device 2 corresponds to a management method.
  • a program that implements the operation of the management device 2 corresponds to a management program.
  • the operation procedure of the migration source node 31 corresponds to the migration source control method.
  • a program that realizes the operation of the migration source node 31 corresponds to the migration source control program.
  • the operation procedure of the migration destination node 41 corresponds to the migration destination control method.
  • a program that implements the operation of the migration destination node 41 corresponds to a migration destination control program.
  • FIG. 4 is a flow chart showing an example of the operation of the data migration system 90.
  • FIG. The operation of the data migration system 90 will be described with reference to this figure.
  • Step S101 Data Acquisition Request Processing
  • the acquisition request unit 211 transmits a migration source data acquisition request 501 to the data migration device 1 .
  • FIG. 5 shows an example of the migration source data acquisition request 501 .
  • the “acquisition target ledger ID (Identification)” is an identifier that uniquely represents the ledger that is the data acquisition target.
  • the data acquisition target records the migration source data.
  • the “acquisition target ledger name” is the name set for the ledger that is the data acquisition target.
  • the “connected migration source node” is information representing the location of the migration source node 31 to which the data acquisition unit 112 connects to acquire data.
  • the connection migration source node is the migration source node 31 that records the data to be migrated.
  • the value of the “connection source node” is, for example, the IP (Internet Protocol) address of the source node 31 or a combination of the IP address and port number of the source node 31 .
  • Connection migration source node credential information is information used when authentication is required when connecting to a connection migration source node. There may be no “connection source node credential information”. The value of the "connection source node credential information" is, for example, a set of an ID and password for logging in to the migration source node 31, a set of data signed by a public key and a private key, or an access token. be.
  • Step S102 Data request processing
  • the acquisition request reception unit 111 receives the source data acquisition request 501 .
  • the data acquisition unit 112 uses the migration source data acquisition request 501 to request the transaction recorded in the ledger indicated by the acquisition target ledger name and the supplementary data 503 related to the transaction from the connection migration source node.
  • Step S103 Request data transmission process
  • the connection migration source node transmits the transaction requested by the data acquisition unit 112 and the supplementary data 503 to the data acquisition unit 112 .
  • Step S104 Sorting process
  • the data acquisition unit 112 acquires the transaction and the supplementary data 503 as acquired data.
  • the data selection unit 113 selects only data necessary for migration processing from the acquired data.
  • the migration source distributed ledger is a block chain
  • a plurality of transactions are managed in units called blocks in the migration source ledger network 3 .
  • the data acquisition unit 112 may acquire blocks from the migration source node 31 and the data selection unit 113 may extract each transaction from the blocks acquired by the data acquisition unit 112 .
  • FIG. 6 shows an example of screened transaction data 502 .
  • the screened transaction data 502 is transaction data screened by the data screening unit 113 .
  • the “acquisition target ledger ID” is an identifier that uniquely represents the ledger from which data is to be acquired.
  • the value of the “acquisition target ledger ID” is the same value as the acquisition target ledger ID set by the migration source data acquisition request 501 .
  • “Transaction ID” is an identifier that uniquely represents a transaction included in the acquisition target ledger. In the following description of this figure, unless otherwise specified, the transaction is the transaction indicated by the transaction ID.
  • "Execution order information” is information representing the timing at which a transaction was applied to the ledger.
  • the value of "execution order information" can be obtained by combining the block number and the information indicating where in the block the transaction was applied. It is made. Execution order information may also be generated using a list of transactions to be processed before executing a certain transaction. “Type” represents the type of processing executed by the transaction. As a specific example, the type of processing is one of distributed ledger embedded function execution, smart contract execution, smart contract deployment, and smart contract update. "Execution target" indicates the place where the processing to be executed by the transaction is defined. The target of execution may be information pointing to the location where the function embedded in the distributed ledger is stored, or information pointing to the smart contract, which is the logic that operates on the blockchain.
  • Executecution processing indicates specific processing executed by a transaction.
  • the value of “execution processing” is one of the function built into the distributed ledger, the deployment or update of the smart contract, and the processing defined in the smart contract.
  • a "process argument list” is a list in which a data group required by a process indicated by an execution process is set.
  • the “executor information” is information indicating the executor of the transaction.
  • the “execution result” indicates the execution result of the transaction when the process indicated by the execution process is executed for the target indicated by the execution target using the argument indicated by the process argument list.
  • the value of the "execution result" consists of two types: reference information indicating data referenced and write information indicating written data in the execution of the process.
  • a state DB (Database), which is a storage area for processing execution inside the migration source node 31, stores reference information and write information.
  • the reference information is the primary key of all state DBs referenced during execution of the process.
  • the written information is the primary key of all state DBs written during execution of the process.
  • the execution result uses a distributed ledger that is not included in the transaction.
  • the distributed ledger supports a function of storing arbitrary data in a storage area that can track transactions during execution of processing or can track relationships with transactions
  • the data selection unit 113 may use this function. Specifically, by recording the primary key of the data referenced when executing the smart contract and the primary key of the written data in a transaction or a storage area where the relationship with the transaction can be tracked, the data selector 113 An execution result can be obtained when data is obtained from the data obtaining unit 112 .
  • the data selection unit 113 may combine the execution result obtained by this procedure with the transaction, and may manage the execution result as supplementary data 503 .
  • the data selection unit 113 obtains the execution result by emulating the execution of the transaction by any means without using the function described above, and uses the obtained execution result as the supplementary data 503 to send the supplemental data registration request unit 22. It may be registered in the supplemental data management unit 14 by using it.
  • the screened transaction data 502 illustrated in FIG. 6 are transactions that execute smart contracts deployed on a distributed ledger.
  • the screened transaction data 502 can also represent transactions related to smart contract deployment or update.
  • the smart contract name to be deployed or updated is set as the execution target value.
  • FIG. 7 shows an example of supplemental data 503 .
  • the supplemental data 503 is selected by the data selection unit 113 .
  • “Supplemental data ID” is an identifier that uniquely represents the supplemental data 503 .
  • the “acquisition target ledger ID” is an identifier that uniquely represents the ledger that is the data acquisition target.
  • the value of the “acquisition target ledger ID” is the same as the value indicated by the acquisition target ledger ID of the source data acquisition request 501 .
  • the ledger is the ledger indicated by the acquisition target ledger ID.
  • Transaction ID is an identifier that uniquely represents a transaction included in the ledger.
  • the “transaction ID” value is the identifier of the transaction associated with supplemental data 503 .
  • “Data type” represents the type of supplemental data 503 . Specific examples of the type of the supplementary data 503 include "smart contract” indicating that the supplemental data 503 represents the data of the main body of the smart contract, and " “secret data” or “execution result” used when using a distributed ledger where the execution result is not included in the transaction. “Data” is the main body of supplemental data 503 . As a specific example, if the supplementary data 503 is a smart contract, the value of "data” is data of the smart contract body used when deploying the smart contract to the node.
  • Step S105 Selection data transmission process
  • the data selection unit 113 transmits the selected transaction data 502 of the finally selected data to the migration order creation unit 12 and transmits the supplementary data 503 to the supplementary data management unit 14 .
  • Step S106 Supplementary data reading process
  • the transaction-related data creation unit 121 reads the supplementary data 503 related to the sorted transaction data 502 received from the data sorting unit 113 from the supplemental data recording unit 142 .
  • the “acquisition target ledger ID” is an identifier that uniquely represents the ledger that is the data acquisition target.
  • the ledger is the ledger indicated by the acquisition target ledger ID.
  • a “vertex set” is a list of vertex IDs of the vertex data 505 that make up the transaction relation graph.
  • Edge set is a list of edge IDs of the edge data 506 that make up the transaction relation graph.
  • Each of the vertex set and the edge set should hold information on each of the vertices and edges that make up the transaction relation graph.
  • a vertex set may be a list of vertex data 505 and an edge set may be a list of edge data 506 .
  • vertex ID is an identifier that uniquely represents a vertex.
  • the vertex refers to the vertex indicated by the vertex ID.
  • Transaction ID is an identifier that uniquely represents a transaction included in the ledger.
  • Supplementary data ID is a list of supplementary data IDs related to the transaction indicated by the transaction ID.
  • Reference is a list of pairs of the primary key of the state DB referred to when executing the transaction corresponding to the vertex and the version of the primary key. The primary key version is information indicating the number of times or when the primary key value was updated in the state DB.
  • Side ID is an identifier that uniquely represents a side.
  • the side is the side indicated by the side ID.
  • “Output side vertex ID” represents the vertex ID of the vertex from which the edge is output.
  • "Input side vertex ID” represents the vertex ID of the vertex to which the side is input.
  • the edge e1 represents a constraint that the transaction corresponding to the vertex v2 must be registered after the transaction corresponding to the vertex v1 is registered at the time of data migration to the destination distributed ledger.
  • FIG. 9 shows an example of the primary key update history table 507 and an example of the smart contract update history table 508.
  • the primary key update history table 507 is data used in the process of creating the transaction relationship graph 504, and is the latest version of each primary key recorded in the state DB at a certain point in time in the source distributed ledger. This data indicates the latest version and the previous version. In this example, information indicating the execution order of transactions in the blockchain is used as the version. In the first row of data in this example, the primary key "user A's deposit data" was last updated by executing the third transaction of block 5, and the first transaction of block 4 was executed. This indicates that the penultimate update has been performed by execution.
  • the smart contract update history table 508 is data used in the process of creating the transaction relationship graph 504.
  • the smart contract update history table 508 includes "smart contract name” indicating the name of the smart contract to be executed at a certain point in time and the latest version of the smart contract deployed on the migration source distributed ledger. "Transaction ID of transaction that deployed/updated the latest version” indicating the transaction ID of the transaction that deployed or updated.
  • the transaction-related data creation unit 121 stores the screened transaction data 502 to be graphed in a list.
  • Step S123 The transaction-related data creation unit 121 creates vertex data 505 using the screened transaction data 502 and supplementary data 503 related to the screened transaction data 502 .
  • the "created vertex data 505" refers to the vertex data 505 created here until the transaction relation data creation unit 121 next executes the process of this step. . That is, each time the transaction-related data creating unit 121 executes the process of this step, the vertex data 505 pointed to by the "created vertex data 505" is updated.
  • a specific example of a technique for creating the vertex data 505 will be described.
  • the transaction-related data creation unit 121 generates a new value so as not to overlap with the vertex ID created from the time the transaction-related data creation unit 121 starts the processing shown in this flowchart until it executes the processing of this step,
  • the generated value is set as the "vertex ID”
  • the transaction ID of the sorted transaction data 502 is set as the "transaction ID”
  • the ID of the supplementary data 503 is set as the "supplementary data ID”. If there is no supplementary data 503 related to the screened transaction data 502, the transaction-related data creation unit 121 sets an empty list as the supplementary data ID.
  • the transaction-related data creation unit 121 uses the reference data indicated by the execution result of the screened transaction data 502 or the execution result of the supplementary data 503 related to the screened transaction data 502 and the primary key update history table 507 to generate the primary key and the primary key version pair to "reference". Specifically, for each primary key in the reference data of the execution result, the latest version is read from the primary key update history table 507, and the primary key and the latest version are set as a pair. Note that when the reference data of the execution result is 0, the transaction relation data creation unit 121 does not set "reference".
  • the transaction-related data creation unit 121 creates the write data indicated by the execution result of the screened transaction data 502 or the execution result of the related supplementary data 503, the execution order information of the screened transaction data 502, or the primary key update history table 507, etc. and set the primary key and primary key version pair to "write".
  • the transaction relation data creating unit 121 sets the pair of the primary key and the execution order information of the screened transaction data 502 to "reference" and "write”.
  • the transaction relation data creation unit 121 A combination with the version derived from the update history table 507 may be set to "reference” and "write".
  • the version information is managed by natural numbers such as 1, 2, 3, .
  • the transaction-related data creating unit 121 does not set "write”.
  • Step S124 The transaction-related data creation unit 121 updates the primary key update history table 507.
  • FIG. As a specific example, for each primary key set to "write" in the created vertex data 505, the version set as the latest version in the primary key update history table 507 is set as the previous version, and then , set the version set to "Write” as the latest version. Note that if the created vertex data 505 is not set to “write”, the transaction relation data creating unit 121 skips the processing of this step.
  • Step S125 The transaction relation data creating unit 121 confirms whether or not the transaction relation graph 504 has been created. When the transaction relationship graph 504 is created, the transaction relationship data creating unit 121 proceeds to step S128. Otherwise, the transaction-related data creating unit 121 proceeds to step S126.
  • Step S126 The transaction relation data creating unit 121 creates an empty transaction relation graph 504 .
  • transaction relationship graph 504 refers to the transaction relationship graph 504 created in this step.
  • the transaction-related data creation unit 121 sets the "acquisition target ledger ID" to the "acquisition target ledger ID” indicated by the "acquisition target ledger ID” of the screened transaction data 502. Set the values, and set an empty list for each of 'vertex set' and 'edge set'.
  • Step S128) The transaction-related data creation unit 121 confirms whether or not the “type” of the screened transaction data 502 is smart contract deploy. If the “type” is smart contract deploy, the transaction relation data creation unit 121 proceeds to step S129. Otherwise, the transaction-related data creation unit 121 proceeds to step S132.
  • Step S129 The transaction relationship data creation unit 121 creates edge data 506 for vertices corresponding to all vertices indicated by the “vertex set” of the transaction relationship graph 504 .
  • Step S130 The transaction-related data creation unit 121 records a set of the deployed or updated smart contract name and the transaction ID of the screened transaction data 502 in the smart contract update history table 508 . Note that the transaction-related data creation unit 121 sets the “smart contract name” to be the same as the “execution target” of the screened transaction data 502 .
  • Step S131 The transaction relationship data creating unit 121 adds the created edge data 506 to the “edge set” of the transaction relationship graph 504 .
  • Step S132 The transaction-related data creation unit 121 confirms whether or not the “type” of the screened transaction data 502 is smart contract update. If the “type” is smart contract update, the transaction-related data creating unit 121 proceeds to step S133. Otherwise, the transaction-related data creating unit 121 proceeds to step S134.
  • the transaction relation data creation unit 121 creates vertex data using all vertex data 505 corresponding to transactions registered after the time indicated by the transaction that deployed or updated the current latest version of the smart contract to be updated. Create side data 506 for 505 .
  • the transaction-related data creation unit 121 acquires the smart contract name set in the "execution target" of the selected transaction data 502, and deploys the latest version of the smart contract corresponding to the acquired smart contract name.
  • the transaction ID of the updated transaction is acquired from the smart contract update history table 508 .
  • the transaction-related data creating unit 121 acquires the screened transaction data 502 corresponding to the acquired transaction ID, and extracts the “execution order information” of the acquired screened transaction data 502 .
  • the transaction relation data creation unit 121 searches for the selected transaction data 502 registered after the time indicated by the extracted "execution order information", and vertex data 505 corresponding to each of the selected transaction data 502 registered after that time. to get After that, the transaction relation data creating unit 121 creates each side data 506 having the acquired vertex data 505 and the created vertex data 505 as both ends.
  • the smart contract name is the same as the “execution target” of the screened transaction data 502 .
  • the transaction relation data creation unit 121 creates vertex data 505 and vertex data 505 that includes a set of a primary key and a version of the primary key included in the "reference" of the created vertex data 505 as an element of "write". side data 506 having both ends are created.
  • Step S135) The transaction relation data creating unit 121 creates the vertex data 505, the primary key that is one version before the primary key included in the "write” of the created vertex data 505, and the version of the primary key that is one version before. and edge data 506 having both ends as vertex data 505 including a pair of as a “reference” or “write” element.
  • the transaction-related data creation unit 121 combines the transaction ID of the transaction that deployed or updated the latest version of the smart contract indicated by the "execution target" of the screened transaction data 502 with the smart contract "execution target” of the screened transaction data 502.
  • the vertex data 505 obtained by using the update history table 508 and the vertex data 505 corresponding to the transaction of the obtained transaction ID are used as both ends to create the edge data 506 .
  • Step S137 The transaction-related data creating unit 121 deletes the transaction data extracted in step S122 from the list.
  • Step S138 The transaction-related data creation unit 121 confirms whether the list is empty. If the list is empty, the transaction-related data creation unit 121 terminates the processing of this flowchart. If the list is not empty, the transaction relation data creation unit 121 proceeds to step S121.
  • Step S139 The processing in this step is the same as the processing in step S128.
  • Step S140 The processing in this step is the same as the processing in step S130.
  • Step S108 data recording process
  • the transaction-related data creation unit 121 records the generated transaction-related data and the selected transaction data 502 received from the data selection unit 113 in the transaction-related data recording unit 122 .
  • As the transaction relation data recorded in the transaction relation data recording unit 122 when the transaction relation data is the transaction relation graph 504, the transaction relation graph 504, and the vertex data 505 and the edge data 506 constituting the transaction relation graph 504 are stored. mentioned.
  • Step S109 Supplementary data transmission process
  • the supplemental data registration request unit 22 transmits the supplementary data 503 to the data migration apparatus 1 .
  • the timing of transmitting the supplementary data 503 may be before or during the processing of the data extraction unit 11 or the migration order creation unit 12 described above.
  • the data migration device 1 receives the supplemental data 503 using the supplemental data receiving unit 141 and records the received supplemental data 503 in the supplemental data recording unit 142 .
  • Step S110 Registration request transmission process
  • the registration request unit 212 transmits a migration destination data registration request 509 to the data migration apparatus 1 .
  • FIG. 12 shows an example of the migration destination data registration request 509 .
  • the “migration destination ledger ID” is an identifier that uniquely represents the ledger that is the migration destination.
  • “Ledger name” is the name set in the ledger that is the migration destination.
  • the “acquisition target ledger ID” is an identifier that uniquely represents the ledger that is the migration source.
  • the “connection migration destination node” is the same as the “connection migration source node”, and is information representing the location of the connected migration destination node 41 to which the data transmission unit 133 migrates data.
  • the “connection migration destination node qualification information” is the same as the “connection migration source node qualification information”, and is information used when authentication is required when connecting to the migration destination node 41 .
  • Step S111 migration data creation process
  • the data migration apparatus 1 receives the migration destination data registration request 509 using the registration request reception unit 131 and calls the data creation unit 132 .
  • the data creation unit 132 stores the migration destination data registration request 509 received by the registration request reception unit 131, the transaction-related data recorded by the transaction-related data recording unit 122, and the supplementary data recorded by the supplementary data recording unit 142. 503 are used to create migration data 510, and the created migration data 510 is transmitted to the data transmission unit 133 as appropriate.
  • FIG. 13 shows an example of migration data 510 .
  • “Order data” is a setting value representing the order of applying the migration data 510 to the migration destination ledger network 4 .
  • “Ledger name” is the name set in the ledger that is the migration destination.
  • the “connection migration destination node” is the same as the “connection migration source node” and is information representing the location of the migration destination node 41 to which the data transmission unit 133 connects.
  • connection migration destination node qualification information is the same as the “connection migration source node qualification information”, and is information used when authentication is required when connecting to the migration destination node 41 .
  • a “vertex data list” is a list containing elements corresponding to the vertex data 505 to be migrated. Each element included in the "vertex data list” is a creation element and corresponds to at least part of the electronic data to be migrated from the source distributed ledger to the destination distributed ledger. Since the vertex data 505 corresponding to the elements included in the "vertex data list” indicates data that can be registered at the timing of generating the migration data 510, in what order the data migration device 1 transfers to the migration destination ledger network 4 Data indicated by the vertex data 505 may be registered. However, when a plurality of migration data 510 exist, the data migration device 1 needs to register the vertex data 505 in order from the migration data 510 whose order is indicated in the "order data”.
  • a specific example of creating and transmitting migration data 510 when the data migration device 1 adopts the transaction relationship graph 504 as the transaction relationship data is shown below.
  • FIG. 14 is a flow chart showing an example of the process of creating the migration data 510 and the process of transmitting the created migration data 510 to the data transmission section 133 by the data creating section 132 .
  • the processing of the data creation unit 132 and the data transmission unit 133 will be described with reference to this figure.
  • Step S141 The data creation unit 132 acquires the vertex data 505 for which the data registration condition is not set in the transaction relationship graph 504 of the migration source distributed ledger, and registers the acquired vertex data 505 in the list.
  • the data creation unit 132 uses the “acquisition target ledger ID” of the migration destination data registration request 509 to acquire the transaction relationship graph 504 corresponding to the migration source distributed ledger from the transaction relationship data recording unit 122 .
  • the vertex data 505 for which data registration conditions are not set correspond to the edges included in the "edge set” of the transaction relationship graph 504 among the vertex data 505 corresponding to the vertices included in the "vertex set” of the transaction relationship graph 504.
  • the vertex data 505 is not set as the “input side vertex ID” of the side data 506 to be connected.
  • the data creation unit 132 refers to each vertex data 505 in the list, extracts the vertex data 505 based on the migration rule, and creates migration data 510 using the extracted vertex data 505 .
  • a specific example of the migration rule is a rule that includes all the vertex data 505 included in the list in the migration data 510 .
  • the case of using a blockchain as a distributed ledger will be described. In this case, if a plurality of vertex data 505 included in the list are grouped into one block data, the consensus building time per transaction can be reduced, so the time required for data migration can be shortened.
  • Other migration rules include rules that preferentially use vertex data 505 corresponding to transactions that constitute a precondition for registering more transactions to generate migration data 510 .
  • the data creation unit 132 preferentially uses the vertex data 505 corresponding to the transactions that constitute the prerequisites for registering more transactions to generate the transition data 510,
  • the generated migration data 510 is registered in the migration destination ledger network 4 .
  • the data migration apparatus 1 can register many transactions whose registration preconditions that the priority migration data 510 be registered. If a group of transactions that can be registered by registering transactions that are prerequisites for many transactions are grouped together as one block data, the time required for consensus building per transaction can be reduced, making it easier to migrate data. The time required can be shortened.
  • the data creation unit 132 generates the “order data” from the previously created migration data 510 to be applied to the migration destination ledger network 4 so that the values of the “order data” of the migration data 510 do not overlap during the iterative process of the flowchart. set the value of The data creation unit 132 sets the values indicated in the migration destination data registration request 509 to the “ledger name”, “connection migration destination node”, and “connection migration destination node qualification information” of the migration data 510 .
  • the data creation unit 132 sets values corresponding to the vertex data 505 included in the list in the "vertex data list”.
  • the data creation unit 132 may set the vertex data 505 itself in the “vertex data list”, or may store information for referencing the vertex data 505 such as registering the “vertex ID” of the vertex data 505 in the “vertex list”. data list”.
  • Step S143 The data creation unit 132 transmits the created migration data 510 to the data transmission unit 133 .
  • Step S145 The data creation unit 132 registers the vertex data 505 corresponding to the input side vertex ID of each extracted edge data 506 in the candidate list. Note that the data creation unit 132 does not redundantly register the vertex data 505 already registered in the candidate list in the candidate list.
  • the candidate list is a list of vertex data 505 that satisfies at least part of the data registration conditions at the time of processing the elements included in the candidate list.
  • the data registration condition for certain vertex data 505 is that the edge data 506 having the "input vertex ID" of the certain vertex data 505 is processed in step S144 in the iteration by the time this step is executed. are all extracted by Iteration refers to repeated processing in this flowchart.
  • Step S146 The data creation unit 132 sets the data registration condition for each vertex data 505 included in the candidate list based on each edge data 506 extracted from the time the data creation unit 132 starts the process of this flowchart until the process of this step is executed. It confirms whether or not the registration conditions are satisfied, and registers the vertex data 505 satisfying the registration conditions in the next list.
  • the next list is a list whose elements are the vertex data 505 for which all the data registration conditions have been satisfied in the course of the iteration process. Data corresponding to the vertex data 505 satisfying the registration condition is registerable data.
  • the edge data 506 having the vertex data 505 hereafter, vertex v2) whose "vertex ID” is v2 as the "input side vertex ID” is edge e1 (v1, v2) and edge e2 (v3 , v2) and an edge e3 (v4, v2).
  • the side e1 (v1, v2) represents the side data 506 whose "side ID” is e1, "output side vertex ID” is v1, and "input side vertex ID” is v2. It is assumed that edge e1 (v1, v2) is extracted from this transaction relation graph 504 in step S144 of a certain iteration.
  • step S145 of the certain iteration if the vertex v2 set as the “input side vertex ID” of the side e1 is not already registered in the candidate list, the data creation unit 132 adds the vertex v2 to the candidate list. to register.
  • step S146 of the certain iteration since edge e1 (v1, v2) has already been extracted among the data registration conditions for vertex v2, edge e2 (v3, v2) and edge e3 (v4, v2) are is further extracted, it is determined that the vertex v2 can be registered.
  • the data creation unit 132 checks whether the data registration condition is satisfied for each vertex in this way, and registers the vertex data 505 satisfying the data registration condition in the next list in the process of step S146.
  • Step S147 The data creation unit 132 checks whether the list and next list are empty. If the list and the next list are empty, the data creating unit 132 proceeds to step S149. Otherwise, ie, if at least one of the list and the next list is not empty, the data creating unit 132 proceeds to step S148.
  • Step S148 The data creation unit 132 deletes the vertex data 505 included in the migration data 510 from the list, adds the vertex data 505 of the next list to the list, and empties the next list.
  • Step S149 The data creation unit 132 transmits a transmission completion notification indicating that transmission of the migration data 510 has been completed to the data transmission unit 133, and ends the processing of this flowchart.
  • Step S112 Migration data transmission process
  • the data transmission unit 133 transmits data to the migration destination node 41 based on the migration data 510 received from the data creation unit 132 .
  • FIG. 15 is a flow chart showing an example of a process in which the data transmission unit 133 transmits data to the migration destination node 41.
  • FIG. The processing of the data transmission unit 133 will be described with reference to this figure. In the description of this figure, numerical values are set in the "order data" of the migration data 510, and the data transmission unit 133 processes the migration data 510 in order from the "order data" having the smallest value.
  • Step S161 The data transmission unit 133 waits to receive the migration data 510 or the transmission completion notification from the data generation unit 132, and adds the received data to the list when the data is received.
  • the number of data received at one time is not limited to one. Also, the data transmission unit 133 may execute the process of this step in the background. Also at this time, the data received from the data creation unit 132 is added to the list each time.
  • Step S162 The data transmission unit 133 acquires one item of data having the smallest “order data” from the list, and deletes the acquired data from the list. Note that the data transmission unit 133 treats the transmission completion notification as data having the largest “order data”.
  • Step S163 The data transmission unit 133 confirms whether the acquired data is a transmission completion notification. If the acquired data is a transmission completion notification, the data transmission unit 133 terminates the processing of this flowchart. Otherwise, that is, if the acquired data is the migration data 510, the data transmission unit 133 proceeds to step S164.
  • the data transmission unit 133 transmits data to the migration destination node 41 according to the vertex data 505 corresponding to the elements included in the “vertex data list” of the acquired migration data 510 .
  • the data transmission unit 133 uses at least one of the “ledger name”, the “connection destination node”, and the “connection destination node qualification information” of the migration data 510 to 41.
  • the data transmission unit 133 refers to at least one of the selected transaction data 502 and the supplementary data 503 corresponding to each vertex data 505 corresponding to the elements included in the “vertex data list”, and Then, the data transmission to the migration destination node 41 is completed by transmitting the transaction to the migration destination node 41 or by calling the function of the migration destination node 41 .
  • Step S165 The data transmission unit 133 confirms whether the list is empty. If the list is not empty, the data transmission unit 133 proceeds to step S162. If the list is empty, the data transmission unit 133 proceeds to step S161.
  • the data migration target is all the transactions included in the ledger that is the migration target of the migration source ledger network 3 .
  • the data migration target may be some transactions included in the ledger that is the migration target of the migration source ledger network 3 .
  • the registration request unit 212 transmits the migration destination data registration request 509 to the data migration apparatus 1 .
  • the registration request unit 212 adds information indicating the transaction to be migrated to the migration destination data registration request 509 .
  • the data creation unit 132 converts only the information indicating the specified transaction to be migrated into the migration data 510 .
  • the data migration device 1 can migrate only some of the transactions included in the ledger to be migrated. At this time, the data migration device 1 confirms whether or not the information indicating the specified transaction to be migrated is sufficient, and if the information is insufficient, automatically replaces the missing transaction. may be added. As a specific example, when the transaction relationship graph 504 is used, transactions that must be registered in advance in order to register a certain transaction are recorded as edge data 506 . Therefore, the data migration device 1 can find the missing transaction at the time of specification by recursively tracing the related vertex data 505 from the edge data 506 .
  • the data generation unit 132 acquires the edge data 506 having the vertex data 505 corresponding to the information indicating the specified transaction to be migrated as the "input side vertex ID”, Acquire the vertex data 505 set in the “output side vertex ID” of the side data 506 . Furthermore, the data creation unit 132 acquires the edge data 506 having the acquired vertex data 505 as the “input side vertex ID”, Recursively repeat the acquisition.
  • the vertex data 505 group obtained by removing duplication with the vertex data 505 group corresponding to the information indicating the transaction that is the first specified migration target from the vertex data 505 group obtained in the process of the recursive search is insufficient. transaction.
  • a union of the vertex data 505 group obtained in the process of recursive search and the vertex data 505 group corresponding to the information indicating the transaction that is the first specified migration target is the specified migration target transaction.
  • This transaction is necessary when migrating data corresponding to information indicating
  • the data migration device 1 may migrate a plurality of source distributed ledgers to a single destination distributed ledger under the condition that transactions of the same content are not included among a plurality of source distributed ledgers. . Therefore, the data migration device 1 organizes transactions in a plurality of source distributed ledgers that do not include duplicate transactions of the same content, and distributes the data to a plurality of destination distributed ledgers to migrate the data. There may be.
  • the selected transaction data 502 and supplementary Data 503 and externally input supplemental data 503 can be used to create transaction relationship data that assists in guiding the order in which transactions are registered in destination ledger network 4 in a relatively efficient manner.
  • the data registration unit 13 can relatively efficiently register the migration data 510 in the migration destination ledger network 4 by using the created transaction-related data. Therefore, according to the present embodiment, transaction data can be migrated relatively efficiently to the migration destination ledger network 4 whose environment is different from that of the migration source ledger network 3 .
  • the oldest transaction stored in the source distributed ledger will be transferred to the destination distributed ledger one by one.
  • a method of registering transactions hereinafter referred to as a sequential method.
  • transactions are registered one by one in the destination distributed ledger in order to ensure that the order of the transactions registered in the destination distributed ledger matches the transaction registration order in the source distributed ledger.
  • multiple nodes perform consensus building. Therefore, there is a problem that it takes time from the transaction registration request to the completion of registration, and the time required for data migration becomes long.
  • a blockchain which is a type of distributed ledger
  • multiple transactions are grouped together and data is registered in units called blocks. Since consensus building is performed in units of blocks, the time required for consensus building per transaction can be shortened by including a plurality of transactions in one block.
  • the method of simply grouping multiple transactions into a block cannot be used.
  • a plurality of transactions that can be registered in the migration destination distributed ledger can be collectively migrated to the migration destination distributed ledger. Therefore, according to the present embodiment, electronic data can be migrated from the migration source distributed ledger to the migration destination distributed ledger more efficiently than when the sequential method is adopted.
  • FIG. 16 shows a hardware configuration example of the data migration device 1 according to this modification.
  • the data migration device 1 includes a processing circuit 88 in place of at least one of the processor 81, memory 82, and auxiliary storage device 84, as shown in the figure.
  • the processing circuit 88 is hardware that implements at least part of each unit included in the data migration device 1 .
  • Processing circuitry 88 may be dedicated hardware or may be a processor that executes programs stored in memory 82 .
  • processing circuit 88 When processing circuit 88 is dedicated hardware, processing circuit 88 may be, by way of example, a single circuit, multiple circuits, a programmed processor, a parallel programmed processor, an ASIC (ASIC is an Application Specific Integrated Circuit), an FPGA. (Field Programmable Gate Array) or a combination thereof.
  • the data migration device 1 may include a plurality of processing circuits that substitute for the processing circuit 88. FIG. A plurality of processing circuits share the role of processing circuit 88 .
  • the processing circuit 88 is implemented by hardware, software, firmware, or a combination thereof, as a specific example.
  • the processor 81, memory 82, auxiliary storage device 84, and processing circuit 88 are collectively referred to as "processing circuitry.”
  • processing circuitry the function of each functional component of the data migration device 1 is realized by the processing circuitry.
  • Other devices included in the data migration system 90 and each device included in the data migration system 90 according to another embodiment may also have the same configuration as the present modification.
  • Embodiment 1 it is possible to connect to the migration source ledger network 3 and the migration destination ledger network 4, and to register the transaction that is the migration target included in the migration source ledger network 3 to the migration destination ledger network 4
  • the acquisition authority for the transaction to be migrated included in the migration source ledger network 3 is set, or when the transaction registration authority for the migration destination ledger network 4 is set, multiple participants migrate data by a plurality of data migration apparatuses 1 while cooperating with each other.
  • a participant is a user of the data migration device 1 or the data migration device 1 .
  • the user may be a computer or the like.
  • FIG. 17 shows a configuration example of a data migration system 90 according to this embodiment.
  • the data migration system 90 comprises a plurality of data migration devices 1 and that each data migration device 1 comprises a ledger update monitoring unit 15.
  • a communication path from the data registration unit 13 of each data migration device 1 to the ledger update monitoring unit 15 of each other data migration device 1 to be linked is added.
  • a data migration system 90 comprising another data migration device 1 having the same function as the data migration device 1 comprises the data migration device 1 .
  • Each data migration device 1 is connected to a migration source ledger network 3 and a migration destination ledger network 4 . Note that "-1" or the like is used to distinguish between a plurality of data migration apparatuses 1.
  • FIG. By configuring the data migration system 90 as described above, each of the plurality of data migration devices 1 migrates appropriate transactions at appropriate timing while checking the progress of data migration by means of the ledger update monitoring unit 15. be able to.
  • This figure shows a case where the data migration device 1 directly communicates with another data migration device 1 .
  • the data migration device 1 may communicate with another data migration device 1 via some device or means.
  • the data migration system 90 uses a data store such as a DB or data lake, a message delivery system such as a message queue, or a differential ledger system as an intermediary means that each data migration device 1 can access.
  • both data migration apparatuses 1 may exchange data via intermediary means.
  • communication between a plurality of data migration devices 1 may be realized via the migration destination node 41 when the migration destination node 41 can add arbitrary data related to the transaction.
  • FIG. 18 shows a hardware configuration example of each device included in the data migration system 90 .
  • the main difference between the present embodiment and the first embodiment is that each data migration device 1 communicates with another data migration device 1, so both participate in the same network.
  • the hardware configuration may be the same as that of the first embodiment.
  • FIG. 19 shows a software configuration example of each device included in the data migration system 90.
  • the data migration device 1 includes a ledger update monitoring unit 15 .
  • the ledger update monitoring unit 15 receives from the registration request receiving unit 131 at least one of the migration destination node 41, the migration destination distributed ledger, and the ledger ID of the migration destination distributed ledger, and performs the transaction in the target migration destination distributed ledger. Monitor registration status.
  • the ledger update monitoring unit 15 receives from the data transmission unit 133 of the other data migration device 1 the transaction ID in the transfer source of the transaction and the transaction ID newly set when the transaction is registered in the transfer destination. Information indicating the correspondence is received, and the received information and the transaction registration status are notified to the data creation unit 132 as appropriate.
  • the ledger update monitoring unit 15 acquires other device registration information indicating data received by the destination distributed ledger from another data migration device 1 and registered in the destination distributed ledger.
  • the data creation unit 132 while migrating the electronic data, based on the data received by the destination distributed ledger from the data transmission unit 133 and registered in the destination distributed ledger and the other device registration information You may create a creation element for
  • the data transmission unit 133 may transmit the data corresponding to each creation element to the migration destination distributed ledger based on the other device registration information.
  • the data transmission unit 133 transmits information indicating data registered in the destination distributed ledger by the data transmission unit 133 transmitting data corresponding to each creation element to another data migration device. 1 may be sent.
  • the data migration device 1 uses the transaction relationship graph 504 as the transaction relationship data
  • a transaction registerable condition to be registered in the migration destination distributed ledger by a certain participant is configured. Even if it is not possible to directly obtain the information about the transaction from the migration source node 31, the certain participant can obtain the information obtained by the other participants who can obtain the information as the supplementary data 503. can do and use. As a result, the certain participant can create a valid transaction relationship graph 504 .
  • a procedure for the data migration device 1 to migrate data to the migration destination ledger network 4 using the transaction-related data and the supplementary data 503 will be described below.
  • a certain data migration device 1 is simply referred to as the data migration device 1
  • data migration devices 1 other than the certain data migration device 1 are referred to as other data migration devices 1 .
  • Other data migration device 1 is not limited to one data migration device 1 . Also, when the name of an element provided in the data migration device 1 is simply written, it indicates the element provided in the data migration device 1 .
  • FIG. 20 is a flow chart showing an example of the operation of the data migration system 90 according to this embodiment. The operation of the data migration system 90 will be described with reference to this figure.
  • Step S201 Registration request transmission process
  • the registration request unit 212 transmits a migration destination data registration request 509b to the data migration apparatus 1 .
  • FIG. 21 shows an example of the destination data registration request 509b in this embodiment.
  • the main difference between the migration destination data registration request 509b and the migration destination data registration request 509 is that "linked data migration device information" is added.
  • "Linked data migration device information” consists of connection information of each other data migration device 1 with which the data migration device 1 having the migration destination data registration request 509b is linked, and is also called linked data extraction/migration device information. Specific examples of the connection information include location information such as IP addresses, IDs and passwords, or qualification information such as encryption keys or tokens of other data migration apparatuses 1 to be linked.
  • information that is necessary to "Apparatus 2" and the like are the names of the other data migration apparatuses 1 that cooperate with each other.
  • Step S202 Registration request reception process
  • the registration request accepting unit 131 receives the migration destination data registration request 509 b and sends the received migration destination data registration request 509 b to the ledger update monitoring unit 15 and the data creation unit 132 .
  • Step S203 connection processing
  • the ledger update monitoring unit 15 connects to the migration destination node 41 based on the information indicated by the received migration destination data registration request 509b, and monitors the transaction registration status of the migration destination distributed ledger in the connected migration destination node 41. Also, the ledger update monitoring unit 15 connects to the data transmission unit 133 of the other data migration device 1 based on the information indicated by the received migration destination data registration request 509b, and responds to the migration source transaction transmitted by the data transmission unit 133. Information indicating the correspondence between the corresponding transaction ID and the transaction ID newly set when the transaction is registered in the migration destination distributed ledger is started to be received from the data transmission unit 133 of the other data migration device 1 .
  • Step S204 migration data creation process
  • the data creation unit 132 stores the migration destination data registration request 509b received by the registration request reception unit 131, the transaction-related data recorded by the transaction-related data recording unit 122, and the supplementary data recorded by the supplementary data recording unit 142. 503 are used to create migration data 510, and the created migration data 510 is transmitted to the data transmission unit 133 as appropriate.
  • the creation and transmission of the migration data 510 when the data migration device 1 adopts the transaction relationship graph 504 as the transaction relationship data will be described below.
  • FIGS. 22 and 23 are flowcharts showing an example of the process of creating the migration data 510 and the process of transmitting the created migration data 510 to the data transmission section 133 by the data creation section 132.
  • FIG. The processing of the data creation unit 132 will be described with reference to these figures.
  • One flowchart is divided into FIGS. 22 and 23.
  • Step S221) The data creation unit 132 selects, among the vertex data 505 corresponding to the elements included in the “vertex set” of the transaction relationship graph 504 related to the source distributed ledger, which the data migration device 1 can register and the data registration condition is The vertex data 505 not set is acquired, and the acquired vertex data 505 is registered in the list.
  • the data creation unit 132 acquires the transaction relationship graph 504 corresponding to the migration source distributed ledger from the transaction relationship data recording unit 122 using the “acquisition target ledger ID” of the migration destination data registration request 509b.
  • the data creation unit 132 determines whether or not the data migration device 1 can register certain vertex data 505 when the “executor information” of the screened transaction data 502 corresponding to the certain vertex data 505 is A determination is made based on whether or not the owner of the data migration device 1 matches.
  • the data creation unit 132 considers that the vertex data 505 can be registered when the "executor information" and the owner match.
  • the data creation unit 132 can determine the "executor It may be determined that the data migration device 1 can register the vertex data 505 even if the "information" and the owner do not match. Further, the data migration device 1 may set the owner of the data migration device 1 who can be registered for each transaction as the supplementary data 503 .
  • the vertex data 505 for which the data registration condition is not set is the "input This is the vertex data 505 that is not set as "side vertex ID".
  • Step S222 The data creation unit 132 acquires the vertex data 505 corresponding to the transaction registered in the migration destination distributed ledger by the other data migration device 1 .
  • the data creation unit 132 may acquire the vertex data 505 using the other device registration information.
  • the data creation unit 132 inquires of the ledger update monitoring unit 15 so that the migration destination distributed ledger Check if there are any registered transactions. If there is such a transaction, the data creation unit 132 has the ledger update monitoring unit 15 return the vertex data 505 corresponding to the transaction. If there is no such transaction, the data creating unit 132 may wait until the transaction is registered, or may continue the processing assuming that the transaction could not be acquired. When continuing the process as it is, the data creation unit 132 skips the process from step S223 to step S225 and executes the process of step S226.
  • Step S223 The data creation unit 132 extracts the edge data 506 having the "output side vertex ID" as the "vertex ID" of each vertex data 505 acquired in the process of step S222.
  • Step S224 The data creation unit 132 registers the vertex data 505 corresponding to the “input side vertex ID” of each extracted side data 506 in the candidate list.
  • the data creation unit 132 does not redundantly register the certain vertex data 505 in the candidate list.
  • a candidate list is a list of vertex data 505 that satisfies at least part of the data registration condition at the time of processing the elements included in the candidate list.
  • the data registration condition for certain vertex data 505 is that the side data 506 having the "input side vertex ID" of the certain vertex data 505 is processed until step S223 and step All are extracted by the process of S228.
  • Step S225 The data creation unit 132 performs data registration for each vertex data 505 included in the candidate list using each side data 506 extracted from the time the data creation unit 132 starts the process shown in this flowchart until the process of this step is executed. It confirms whether or not the conditions are satisfied, and registers the vertex data 505 satisfying the data registration conditions in the list.
  • Step S226) The data creation unit 132 refers to each vertex data 505 in the list, extracts the vertex data 505 based on the migration rule, and creates migration data 510 using the extracted vertex data 505 .
  • the transition rule is the same as the transition rule according to the first embodiment.
  • the method of creating migration data 510 is the same as the method of creating migration data 510 according to the first embodiment. Note that if the list is empty, the data creation unit 132 skips the processes from step S226 to step S230 and performs the process of step S231.
  • Step S227) The data creation unit 132 transmits the created migration data 510 to the data transmission unit 133 .
  • Step S2278 The data creation unit 132 extracts the side data 506 having the "vertex ID" of each vertex data 505 in the list as the "output side vertex ID".
  • the processing of this step is the same as the processing of step S223.
  • Step S229) The data creation unit 132 registers the vertex data 505 corresponding to the “input side vertex ID” of each extracted side data 506 in the candidate list.
  • the processing of this step is the same as the processing of step S224.
  • Step S230 The data creation unit 132 sets the data registration condition for each vertex data 505 included in the candidate list based on the edge data 506 extracted from the time the data creation unit 132 starts the process of this flowchart until the process of this step is executed. It confirms whether or not the registration conditions are satisfied, and registers the vertex data 505 satisfying the registration conditions in the next list.
  • the next list is the same as the next list according to the first embodiment.
  • Step S231 The data creation unit 132 checks whether the list and next list are empty. If the list and the next list are empty, the data creating unit 132 proceeds to step S233. Otherwise, the data creation unit 132 proceeds to step S232.
  • Step S232 The data creation unit 132 deletes the vertex data 505 included in the migration data 510 from the list, adds the vertex data 505 included in the next list to the list, and empties the next list. After that, the data creation unit 132 proceeds to step S226.
  • Step S233 The data creation unit 132 confirms whether or not there are transactions to be registered. Transactions to be registered are all transactions that can be registered by the data migration device 1 . Transactions that can be registered are as described in step S221. If transactions to be registered remain, the data creation unit 132 executes the process of step S222 and checks with other data migration apparatuses 1 whether there is any transaction that satisfies the data registration conditions. Otherwise, the data creation unit 132 proceeds to step S234.
  • Step S234 The data creation unit 132 transmits a transmission completion notification to the data transmission unit 133, and terminates the processing of this flowchart.
  • Step S205 data transmission process
  • the data transmission unit 133 transmits data to the migration destination node 41 based on the migration data 510 received from the data creation unit 132 .
  • the data transmission unit 133 also transmits the result of data registration in the migration destination node 41 to the ledger update monitoring unit 15 of the other data migration device 1 .
  • FIG. 24 is a flow chart showing an example of the operation of the data transmission unit 133 transmitting data to the migration destination node 41 and the ledger update monitoring unit 15 of the other data migration device 1 .
  • the operation of the data transmission unit 133 will be described with reference to this figure. In this example, it is assumed that a numerical value is set as the "order data" of the migration data 510, and the data transmission unit 133 processes the migration data 510 in order from the "order data" having the smallest value.
  • Step S241 The data transmission unit 133 adds the data received from the data creation unit 132 to the list.
  • the processing of this step is the same as the processing of step S161.
  • Step S242 The data transmission unit 133 acquires data from the list.
  • the processing of this step is the same as the processing of step S162.
  • Step S243 The data transmission unit 133 confirms whether or not the acquired data is a transmission completion notification. If the acquired data is a transmission completion notification, the data transmission unit 133 terminates the processing of this flowchart. Otherwise, ie, if the acquired data is the migration data 510, the data transmission unit 133 proceeds to step S244.
  • the data transmission unit 133 corresponds to the vertex data 505 corresponding to the data not yet registered in the migration destination distributed ledger among the vertex data 505 corresponding to the elements included in the "vertex data list" of the acquired migration data 510.
  • the migration data 510 is transmitted to the migration destination node 41 .
  • the data transmission unit 133 can investigate whether data corresponding to certain vertex data 505 is registered in the destination distributed ledger by using the ledger update monitoring unit 15. Specifically, the data transmission unit 133 determines that the “transaction ID” of the vertex data 505 corresponding to the elements included in the “vertex data list” of the acquired migration data 510 is the status of transaction registration managed by the ledger update monitoring unit 15 .
  • the data transmission unit 133 inquires of the migration destination node 41 whether or not the transaction corresponding to the vertex data 505 can be executed.
  • the smart contract of the ledger that is the target of data migration determines whether or not the data with the same content is being registered twice, and rejects the transaction if it is about to be registered twice.
  • the data transmission unit 133 first transmits data corresponding to the vertex data 505 to the migration destination node 41 .
  • the migration destination node 41 determines whether or not the data corresponding to the vertex data 505 can be registered using the smart contract.
  • the data transmission unit 133 determines that the data corresponding to the vertex data 505 is not registered in the destination distributed ledger.
  • the data transmission unit 133 may employ a method of registering data in the migration destination node 41 instead of the method of inquiring the migration destination node 41 .
  • the data transmission unit 133 may employ a method of registering data in the migration destination node 41 instead of the method of inquiring the migration destination node 41 .
  • the data transmission unit 133 if the data transmission unit 133 can safely register the data corresponding to the vertex data 505 in the migration destination node 41, the data will be transferred to the migration destination distributed type.
  • the data transmission unit 133 connects to the migration destination node 41 using at least one of the “ledger name”, “connection destination node”, and “connection destination node qualification information” of the migration data 510 .
  • the data transmission unit 133 refers to at least one of the screened transaction data 502 and supplementary data 503 corresponding to the vertex data 505 corresponding to each element included in the "vertex data list”.
  • the data transmission unit 133 may transmit a transaction to the migration destination node 41 or call a function of the migration destination node 41 according to the referenced data. This completes the data transmission to the destination distributed ledger.
  • Step S245 The data transmission unit 133 confirms whether the list is empty. If the list is empty, the data transmission unit 133 proceeds to step S241. Otherwise, the data transmission unit 133 proceeds to step S242.
  • the data migration target is all transactions included in the migration target ledger of the migration source ledger network 3.
  • the data migration target may be some transactions included in the ledger that is the migration target of the migration source ledger network 3 . Since the processing of the data migration device 1 at this time is the same as that of the first embodiment, the explanation of the processing is omitted.
  • the data migration device 1 includes the ledger update monitoring unit 15, and a plurality of data migration devices 1 operate in cooperation. Therefore, the data migration device 1 according to the present embodiment has the characteristics of the first embodiment, and when the acquisition authority of the transaction to be migrated included in the migration source ledger network 3 is set, or when the migration Data can be migrated even when transaction registration authority for the previous ledger network 4 is set.
  • the data migration device 1 has a function of confirming whether or not the migration destination distributed ledger created according to the above-described embodiments is the same as the migration source distributed ledger.
  • this function may be combined with any other embodiment, for convenience of explanation, a specific example in which this function is added to the first embodiment will be described.
  • the processing according to the present embodiment can be performed after at least part of the electronic data recorded in the source distributed ledger is migrated to the destination distributed ledger.
  • FIG. 25 shows a configuration example of a data migration system 90 according to this embodiment.
  • the main difference between this embodiment and the first embodiment is that the data migration device 1 has a data verification unit 16 and the management device 2 has a data verification requesting unit 23 .
  • the data acquisition unit 112 acquires from the destination distributed ledger the destination acquisition data including the destination data, which is the data corresponding to each element of the destination migration data.
  • the data verification request 511 is a request to verify the identity of the migration source distributed ledger and the migration destination distributed ledger.
  • the destination migration data is the same as the migration data 510 .
  • the destination acquired data is the same as the acquired data.
  • the destination data is similar to the data corresponding to the creation element.
  • the destination migration data is data corresponding to at least part of the migration data 510 .
  • the data selection unit 113 selects and extracts the migration destination data from the migration destination acquired data.
  • the transaction-related data creating unit 121 may use the destination data to create the destination transaction-related data as necessary.
  • the transaction-related data creation unit 121 creates data corresponding to at least one of the destination data and the data to be migrated as necessary.
  • Supplementary data 503 may be used to create migration destination transaction relation data.
  • the destination transaction-related data corresponds to comparison-related data that is at least part of the transaction-related data.
  • the relational data for comparison corresponds to the electronic data migrated to the destination distributed ledger so far. When all the electronic data to be migrated has been migrated to the destination distributed ledger, the comparison relational data is the transactional data.
  • the data verification unit 16 verifies whether there is a difference between the source distributed ledger and the destination distributed ledger.
  • the data verification unit 16 receives the data verification request 511 from the management device 2, and the source distributed ledger and the destination distributed ledger targeted for migration by the data migration device 1 including the data verification unit 16 are are compared using the transaction relation data and supplementary data 503 of the source distributed ledger and the destination distributed ledger.
  • the data verification unit 16 uses the data managed by the migration order creation unit 12 and the supplementary data management unit 14 as the ledger transaction relation data and the supplementary data 503, respectively.
  • the data verification unit 16 appropriately transmits an acquisition request to the data extraction unit 11 to acquire the necessary data from the ledger. demand.
  • the data verification unit 16 verifies the identity of the source distributed ledger and the destination distributed ledger by comparing the comparison relation data and the destination transaction relation data.
  • the data verification request unit 23 transmits a data verification request 511 to the data migration device 1 .
  • FIG. 26 shows a software configuration example of each device included in the data migration system 90 according to this embodiment.
  • the main difference between this embodiment and the first embodiment is that the data migration device 1 has a data verification unit 16 and the management device 2 has a data verification requesting unit 23 .
  • the data verification unit 16 includes a verification request reception unit 161 , a verification data acquisition request unit 162 , and a verification unit 163 .
  • the verification request reception unit 161 receives the data verification request 511 from the data verification request unit 23.
  • the verification data acquisition requesting unit 162 receives the data verification request 511 from the verification request receiving unit 161 and confirms the contents of the received data verification request 511 .
  • the verification data acquisition request unit 162 requests the acquisition request reception unit 111 to hold the ledger when at least one of the transaction relation data of the ledger to be compared and the related supplementary data 503 has not been created. Obtaining data from the nodes and using the obtained data to create transaction relationship data and/or associated supplemental data 503 .
  • the verification unit 163 compares each ledger to be compared indicated by the data verification request 511 according to the comparison method indicated by the data verification request 511 using the supplementary data 503 related to the transaction-related data of each ledger. Verify if the ledgers match.
  • FIG. 27 is a flow chart showing an example of the operation of the data migration system 90 according to this embodiment. The operation of the data migration system 90 will be described with reference to this figure.
  • Step S301 Verification request transmission process
  • the data verification request unit 23 transmits a data verification request 511 to the data migration device 1 .
  • FIG. 28 shows a specific example of the data verification request 511.
  • the data verification request 511 includes "comparison method”, “data correspondence”, and “comparison target ledger information” indicating information of each ledger to be compared.
  • each "comparison target ledger information” includes “comparison target ledger ID”, “comparison target ledger name”, "connection node”, and “connection node qualification information”.
  • “Comparison target ledger ID” is a generic term for "migration source ledger ID” and “migration destination ledger ID”.
  • “Comparison target ledger name” is a generic term for "source ledger name” and "destination ledger name”.
  • connection node is a generic term for "source connection node” and “destination connection node”.
  • Connection node qualification information is a generic term for "migration source connection node qualification information” and "migration destination connection node qualification information”.
  • the “comparison method” is information indicating a rule that defines a method for comparing ledgers to be compared.
  • An example of a rule is comparing transaction related data. In this example, when the transaction data extracted from each of the ledgers to be compared and the transaction relation data representing the relationship between the transaction data are logically the same, the ledgers to be compared are the same. It is a rule that is considered to be consistent.
  • the "data correspondence relationship” is a concrete summary of cases in which the contents expressed by the values of a certain item match when the values of a certain item differ between the ledgers to be compared.
  • the executor of data registration may be changed in the destination distributed ledger.
  • the data registration executor value is used, depending on the "comparison method"
  • the data verification unit 16 can consider that these executors match, and are therefore objects of comparison. It can be considered that the contents are consistent between the ledgers.
  • the "data correspondence relationship" include information representing users such as information indicating that user A in ledger 1 and user B in ledger 2 are the same user, or information indicating the order of execution.
  • the transaction ID is also information that typically has different values between the source distributed ledger and the destination distributed ledger.
  • the data transmission unit 133, the ledger update monitoring unit 15, or the like may hold the correspondence between the transaction IDs before and after the data migration, and the data verification unit 16 checks the correspondence of the stored transaction IDs. relationship can be used.
  • “Ledger ID” is an identifier that uniquely represents each ledger to be compared.
  • “Comparison target ledger name” is the name set for the ledger to be compared.
  • connection node is information representing the location of the node to be connected when acquiring data from the ledger, and is similar to the “connection source node” and the like.
  • connection node qualification information is information used when authentication is required when connecting to the "connection node”, and is similar to the “connection migration source node qualification information” and the like.
  • comparison target ledger information "comparison target ledger name”, "connection node”, and “connection node qualification information” represent the ledger indicated by the corresponding "comparison target ledger ID" If the transaction-related data is stored in the transaction-related data recording unit 122, it is not necessary.
  • Step S302 Verification request reception process
  • the verification request reception unit 161 receives the data verification request 511 from the management device 2 and sends the received data verification request 511 to the verification data acquisition request unit 162 .
  • Step S303 Verification request confirmation process
  • the verification data acquisition request unit 162 receives the data verification request 511 from the verification request reception unit 161 and confirms the content of the received data verification request 511 .
  • the verification data acquisition request unit 162 extracts each “comparison target ledger ID” of the data verification request 511, and the transaction relation data representing the ledger indicated by each extracted “comparison target ledger ID” is stored in the transaction relation data record. It confirms whether or not it is saved in the unit 122 .
  • the verification data acquisition request unit 162 obtains the "acquisition target ledger ID is saved.
  • the verification data acquisition request unit 162 sends a data verification request 511 to the verification unit 163 .
  • the data extraction unit 11 and the migration order creation unit 12 create transaction relationship data corresponding to the comparison target ledger.
  • the verification data acquisition request unit 162 is data included in the data verification request 511, and corresponds to the comparison target ledger, which is the comparison target ledger to be acquired.
  • a migration source data acquisition request 501 is created using data indicating each of "name", "connection node", and "connection node qualification information".
  • the verification data acquisition request unit 162 sends the created migration source data acquisition request 501 to the acquisition request reception unit 111, thereby allowing the data extraction unit 11 and the migration order creation unit 12 to correspond to the comparison target ledger to be acquired. create transaction-related data.
  • the created transaction-related data is destination transaction-related data.
  • the verification data acquisition request unit 162 confirms that the transaction relation data corresponding to the “comparison target ledger information” included in the data verification request 511 has been created, and sends the data verification request 511 to the verification unit 163 .
  • FIG. 29 shows that when the data migration device 1 uses the transaction relationship graph 504 as the transaction relationship data and the verification method is matching of the transaction relationship graph 504, the verification unit 163 10 is a flow chart showing an example of a process of comparing with a model ledger; The operation of the verification unit 163 will be described with reference to this figure.
  • Step S321 The verification unit 163 organizes the correspondence of the vertex data 505 corresponding to the elements included in the "vertex set" of the transaction relationship graphs 504 of the source distributed ledger and the destination distributed ledger.
  • FIG. 30 is a flowchart showing an example of detailed processing in step S321. Detailed processing of step S321 will be described with reference to this figure.
  • the verification unit 163 creates a transaction ID correspondence table that indicates the correspondence between the transaction IDs in the migration source distributed ledger and the transaction IDs in the migration destination distributed ledger.
  • the ledger update monitoring unit 15 determines the correspondence between the transaction ID of the migration source transaction and the transaction ID newly set when the migration source transaction is registered in the migration destination. We store information that indicates Therefore, the verification unit 163 may create a transaction ID correspondence table by using information stored by the ledger update monitoring unit 15 .
  • the data transmission unit 133 acquires the transaction ID of the migration destination transaction registered in the migration destination distributed ledger, and associates the acquired transaction ID with the transaction ID of the migration source transaction. information may be stored. At this time, the verification unit 163 may create a transaction ID correspondence table by using information stored by the data transmission unit 133 .
  • Step S342 The verification unit 163 registers in the list the vertex data 505 corresponding to the elements included in the “vertex set” of the transaction relationship graph 504 corresponding to the migration source distributed ledger.
  • Step S343 The verification unit 163 acquires one vertex data 505 from the list and deletes the acquired vertex data 505 from the list.
  • the verification unit 163 refers to the transaction ID correspondence table and acquires the transaction ID of the migration destination distributed ledger corresponding to the “transaction ID” of the acquired vertex data 505 .
  • Step S345) The verification unit 163 checks the selected transaction data 502 corresponding to the “transaction ID” of the acquired vertex data 505, the supplementary data 503 related to the selected transaction data 502, and the transaction ID in the acquired migration destination distributed ledger.
  • the corresponding screened transaction data 502 and the supplementary data 503 related to the screened transaction data 502 are compared according to the “comparison method” and “data correspondence” of the data verification request 511 .
  • Step S346 As a result of the comparison in step S345, the verification unit 163 confirms whether or not the content of the source transaction matches the content of the destination transaction corresponding to the source transaction. If the contents of both match, the verification unit 163 proceeds to step S348. Otherwise, the verification unit 163 proceeds to step S347.
  • Step S347 The verification unit 163 concludes the process of this flowchart by assuming that it is confirmed that there is no corresponding relationship between the vertices of the ledgers to be compared.
  • Step S348 Verification unit 163 checks whether the list is empty. If the list is empty, the verification unit 163 proceeds to step S349. Otherwise, the verification unit 163 returns to step S343.
  • Step S349) The verification unit 163 concludes the processing of this flowchart assuming that it has been confirmed that the correspondence relationship is established between the ledgers to be compared at the vertices.
  • Step S322 The verification unit 163 receives the result of the processing in step S321 and checks whether or not there is correspondence between the vertices of the source distributed ledger and the destination distributed ledger. If the correspondence relationship is established between the vertices, the verification unit 163 proceeds to step S324. Otherwise, the verification unit 163 proceeds to step S323.
  • Step S323 The verification unit 163 notifies that the transaction relationship graphs 504 corresponding to the migration source distributed ledger and the migration destination distributed ledger do not match, and ends the processing of this flowchart.
  • Step S324 Based on the correspondence relationship of the vertex data 505, the verification unit 163 determines the correspondence of the edge data 506 corresponding to the elements of the “edge set” included in the transaction relationship graph 504 of each of the source distributed ledger and the destination distributed ledger. Organize relationships.
  • the transaction relationship graph 504 corresponding to the migration source distributed ledger is G ((v1 (1234), v2 (2345)), (e1 (v1, v2))) and corresponds to the migration destination distributed ledger The transaction relationship graph 504 to )).
  • v1 (1234) indicates the vertex data 505 whose “transaction ID” is 1234 and whose “vertex ID” is v1.
  • e1(v1, v2) indicates the side data 506 whose "side ID” is e1, whose "output side vertex ID” is v1, and whose "input side vertex ID” is v2.
  • G(V,E) denotes a transactional relationship graph 504 consisting of a vertex set V and an edge set E; (1234->9876) indicates that the transaction with the transaction ID of 1234 in the source distributed ledger corresponds to the transaction with the transaction ID of 9876 in the destination distributed ledger.
  • e9 (v9, v8) can be read as e9 (v1, v2) in consideration of the correspondence between transactions. It can be seen that the edge is established. In this way, the verification unit 163 applies the Organize whether or not the correspondence relationship is established.
  • Step S326 The verification unit 163 notifies that the transaction relationship graphs 504 match between the migration source distributed ledger and the migration destination distributed ledger, and ends the processing of this flowchart.
  • the data migration device 1 is provided with the data verification unit 16, so that the migrated data in the destination distributed ledger can be migrated while maintaining the characteristics of the above-described embodiments. It can be verified whether it matches the original data in the original distributed ledger.
  • Embodiment 4 Differences from the above-described embodiment will be mainly described below with reference to the drawings.
  • the data extraction unit 11 and the data registration unit 13 may extract and migrate data from a data store other than the distributed ledger.
  • the data store shall be able to register and/or reference forms of transactional data on the distributed ledger.
  • a data store is also a generic term for the migration source data store 5 and the migration destination data store 6 .
  • a data store may be added to the configuration of any other embodiment, but for convenience of explanation, a specific example in which a data store is added to the first embodiment will be described below.
  • FIG. 31 shows a configuration example of a data migration system 90 according to this embodiment.
  • the main difference between the present embodiment and the first embodiment is that the data extraction unit 11 is connected not only to the migration source ledger network 3 but also to the migration source data store 5, and the data registration unit 13 It is connected not only to the migration destination ledger network 4 but also to the migration destination data store 6 .
  • the source data store 5 is also called a source transactional data store.
  • the destination data store 6 is also called a destination transactional data store.
  • FIG. 32 shows a hardware configuration example of each device included in the data migration system 90 according to this embodiment.
  • the data migration system 90 comprises a migration source data store 5 and a migration destination data store 6 .
  • the data acquisition unit 112 uses at least one of the “acquisition target ledger ID”, “acquisition target ledger name”, “connection migration source node”, and “connection migration source node qualification information” of the migration source data acquisition request 501. and can be connected to the migration source data store 5. Based on the migration request, the data acquisition unit 112 acquires data including the acquired data from the data store that records the same data as the data recorded in the source distributed ledger instead of the source distributed ledger. may
  • the source data store 5 includes a transaction format reference section 51 and a source data storage section 52 .
  • the transaction format reference unit 51 receives a data acquisition request based on the source data acquisition request 501 transmitted by the data acquisition unit 112, appropriately refers to the data stored in the source data storage unit 52, and converts data as appropriate. Then, it refers to the data acquisition unit 112 as appropriate, and transmits the converted data as appropriate.
  • the migration source data store 5 may adopt a centralized ledger system. At this time, as a specific example, the same smart contract as the migration source distributed ledger is operating in the transaction format reference unit 51, and the migration source data storage unit 52 stores the transaction corresponding to the operating smart contract and the supplementary data 503. record.
  • the data transmission unit 133 can connect to the migration destination data store 6 using at least one of the “ledger name”, “connection migration destination node”, and “connection migration destination node qualification information” of the migration data 510 . It shall be possible.
  • the data transmission unit 133 may transmit data corresponding to each creation element to a data store capable of processing data corresponding to each creation element instead of the destination distributed ledger.
  • the migration destination data store 6 comprises a transaction format registration unit 61 and a migration destination data storage unit 62.
  • the transaction format registration unit 61 receives data based on the migration data 510 transmitted by the data transmission unit 133, interprets the received data, and appropriately transmits data to be registered in the migration destination data storage unit 62.
  • transaction format registration unit 61 has an application capable of executing processing equivalent to the specified smart contract.
  • the migration destination data storage unit 62 registers data as appropriate when there is a data registration or data reference request from the transaction format registration unit 61, and also refers to the data as appropriate.
  • the migration destination data store 6 may adopt a centralized ledger system.
  • the same smart contract as the migration destination distributed ledger is running, and the migration destination data storage unit 62 stores the transaction corresponding to the running smart contract and the supplementary data 503. record.
  • FIG. 34 is a flow chart showing an example of the operation of the data acquisition unit 112 according to this embodiment. The operation of the data acquisition unit 112 will be described with reference to this figure.
  • Step S401 data acquisition request transmission process
  • the data acquisition unit 112 connects to the migration source node 31 or the migration source data store 5 using the “connection migration source node” and the “connection migration source node qualification information” of the migration source data acquisition request 501 . Since the processing when the data acquisition unit 112 connects to the migration source node 31 is the same as the processing in the first embodiment, the description is omitted.
  • the data acquisition unit 112 sends the “acquisition target ledger ID” and “acquisition target ledger name” of the migration source data acquisition request 501 to the migration source data store 5. Send a data retrieval request containing
  • the application that registered data in the source data storage unit 52 is regarded as a smart contract, and a data processing request from the application to the source data storage unit 52 is regarded as one transaction, thereby
  • the processing of the data store 5 can be considered to be roughly equivalent to the operation of the distributed ledger.
  • the processing for the data processing request from the application to the source data storage unit 52 uses the transaction function or the like of the source data store 5 to refer to a set of data, register data, or update data. It is assumed that the processing is performed consistently.
  • a transaction for deploying a smart contract in a distributed ledger is event data when an application is built and the application cooperates with the migration source data storage unit 52 .
  • a transaction for updating a smart contract in a distributed ledger corresponds to event data when application logic is modified.
  • the transaction format reference unit 51 uses a unique value assigned to each application as the “acquisition target ledger ID” of the screened transaction data 502, and saves the migration source data from the application as the “transaction ID” of the screened transaction data 502.
  • the ID of the data processing request to the unit 52 is used.
  • the transaction format reference unit 51 uses the execution order information indicated by the data processing request from the application to the migration source data storage unit 52 as the “execution order information” of the screened transaction data 502 .
  • the execution order information of the data processing requests from the application to the source data storage unit 52 includes, in advance, a log of data processing requests from the application to the source data storage unit 52, an application construction and linkage event, and an application By confirming the update event, numbers are assigned in order from the data processing request and event with the earliest application order.
  • the transaction format reference unit 51 sets the “type” of the screened transaction data 502 to “smart contract execution” and uses the name of the application as the “execution target” of the screened transaction data 502 .
  • the transaction format reference unit 51 uses, as the “execution process” of the screened transaction data 502 , the process name in the application when the application issues a data processing request to the migration source data storage unit 52 .
  • the transaction format reference unit 51 uses the argument data passed to the source data storage unit 52 when the application makes a data processing request to the source data storage unit 52 as the “processing argument list” of the selected transaction data 502. use.
  • the transaction type reference unit 51 uses the owner or executor information of the application as the "executor information" of the screened transaction data 502, and the data performed during the data processing request as the "execution result” of the screened transaction data 502. Sets reference and write information to the store.
  • the transaction format reference unit 51 uses a unique value assigned to each application as the “acquisition target ledger ID” of the screened transaction data 502, and uses the “transaction ID” of the screened transaction data 502 as a transaction ID.
  • An ID that does not overlap is set as the ID of the event data when the application is built and linked with the migration source data storage unit 52 .
  • the transaction format reference unit 51 uses the name of the application as the “execution target”, builds the application as the “execution process”, and uses the event data or the application when linking with the migration source data storage unit 52. Using the event name, etc. of the event data whose logic has been modified, the event data or the body of the event data whose logic of the application has been modified when an application is constructed as a "processing argument list" and linked with the migration source data storage unit 52, etc. take advantage of The transaction type reference unit 51 uses the information indicating the owner of the application or the executor of building the application as the "executor information" of the screened transaction data 502, and the initial data as the "execution result" of the screened transaction data 502.
  • transaction format reference unit 51 sets a value that does not overlap with other supplementary data IDs in “supplementary data ID”, and sets “acquisition target ledger ID” and “transaction Set the same values as the acquisition target ledger ID and transaction ID set in the screened transaction data 502 related to "ID”, set “smart contract” in "data type”, and save the migration source data in "data” Set the main body of the smart contract stored in the unit 52 and having the same function as the application in which the data was registered.
  • the transaction format reference unit 51 sets the "type" of the screened transaction data 502 to "smart contract update”, and sets the "execution target", “execution process”, and "process argument list” of the screened transaction data 502 to When the existing data needs to be converted due to an application update, etc., the corresponding relationship between the application execution data and the selected transaction data 502 is appropriately set in the same manner as the processing described above.
  • the transaction format reference unit 51 appropriately sets information indicating reference to and writing to the migration source data store 5 in the "execution result" of the screened transaction data 502 when the existing data is converted by updating the application. do.
  • the transaction format reference unit 51 can convert the general application and the execution record of the migration source data store 5 into the same data format as that of the migration source node 31 .
  • the transaction format reference unit 51 transmits the data converted into the same data format as that of the migration source node 31 to the data acquisition unit 112 .
  • FIG. 35 is a flowchart showing an example of the operation of the data transmission section 133 according to this embodiment. The operation of the data transmission unit 133 will be described with reference to this figure.
  • Step S421 data transmission processing
  • the data transmission unit 133 receives the migration data 510 created by the data creation unit 132, uses the “connection migration destination node” and the “connection migration destination node qualification information” of the received migration data 510, 41 or the destination data store 6.
  • the processing when the data transmission unit 133 connects to the migration destination node 41 is the same as the processing in the first embodiment, so the description is omitted.
  • the data transmission unit 133 transmits data based on the migration data 510 to the migration destination data store 6 .
  • Step S422 Execution processing
  • the transaction format registration unit 61 receives data from the data transmission unit 133 , appropriately executes processing included in the received data, and records the processing result in the migration destination data storage unit 62 .
  • the "vertex data list" of the migration data 510, each vertex data 505 corresponding to the elements included in the "vertex data list", the selected transaction data 502 corresponding to each vertex data 505, and , and supplemental data 503 associated with screened transaction data 502 have been sent.
  • the transaction format registration unit 61 acquires the smart contract main body of the supplementary data 503 related to the selected transaction data 502, creates an application capable of processing equivalent to the acquired smart contract main body, and creates Register the build or update record of the application in the migration destination data storage unit 62 .
  • the “type” of the screened transaction data 502 corresponding to the vertex data 505 corresponding to an element included in the vertex data list is “smart contract execution”.
  • the transaction format registration unit 61 executes an application capable of executing processing equivalent to the smart contract specified in the "execution target" according to the contents of the screened transaction data 502, and executes the application.
  • the processing result at the time is recorded in the migration destination data storage unit 62 .
  • the transaction format registration unit 61 does not convert the smart contract body into an application and uses the smart contract body as it is. good.
  • the target is a data store that can at least either register or refer to the transaction data format of the distributed ledger.
  • data can be extracted and/or migrated.
  • data extracted from one or more distributed ledgers and data stores by one data migration device 1 can be relatively easily transferred to one or more separate distributed ledgers and data stores. Data can be migrated.
  • the embodiments also represent one or more distributed ledgers and data stores as transaction-related data, and migrate data corresponding to the transaction-related data to one or more separate distributed ledgers and data stores.
  • Embodiments are not limited to those shown in Embodiments 1 to 4, and various modifications are possible as necessary.
  • the procedures described using flowcharts and the like may be changed as appropriate.
  • 1 data migration device 11 data extraction unit, 111 acquisition request reception unit, 112 data acquisition unit, 113 data selection unit, 12 migration order creation unit, 121 transaction-related data creation unit, 122 transaction-related data recording unit, 13 data registration unit , 131 Registration request reception unit, 132 Data creation unit, 133 Data transmission unit, 14 Supplementary data management unit, 141 Supplementary data reception unit, 142 Supplementary data recording unit, 15 Ledger update monitoring unit, 16 Data verification unit, 161 Verification request reception 162 verification data acquisition request unit 163 verification unit 2 management device 21 migration request unit 211 acquisition request unit 212 registration request unit 22 supplementary data registration request unit 23 data verification request unit 3 migration ledger network , 31 Source node, 4 Destination ledger network, 41 Destination node, 5 Source data store, 51 Transaction format reference part, 52 Source data storage part, 6 Destination data store, 61 Transaction format registration part, 62 Migration Destination data storage unit, 501 Source data acquisition request, 502 Selected transaction data, 503 Supplementary data, 504 Transaction relationship graph, 505 Vertex data

Abstract

データ移行装置(1)は、データ取得部(112)と、データ選別部(113)と、移行順序作成部(12)とを備える。データ取得部(112)は、移行元分散型台帳から移行先分散型台帳に電子データを移行する移行要求に基づいて、移行要求に対応するデータであって、1つ以上の要素を含むデータである移行データの各要素として作成されるそれぞれの作成要素に対応するデータを含む取得データを移行元分散型台帳から取得する。データ選別部(113)は、取得データから作成要素に対応するデータを選別して抽出する。移行順序作成部(12)は、それぞれの作成要素に対応するデータを移行先分散型台帳に移行する移行順序を、作成要素に対応するデータを用いて作成する。

Description

データ移行装置、データ移行方法、及び、データ移行プログラム
 本開示は、データ移行装置、データ移行方法、及び、データ移行プログラムに関する。
 ブロックチェーンに代表される分散型台帳を活用するシステムが増えている。分散型台帳は、台帳の操作要求であるトランザクションをステークホルダー間で共有し、ステークホルダー間の共有台帳を実現する技術である。一般的な分散型台帳では、各ステークホルダーが保有する分散型台帳サーバであるノードは、少なくとも当該ノードと当該ノードに関係のあるステークホルダーの過去の全てのトランザクションを保有しているため、ステークホルダー間で過去のデータを含む共有データの検証をすることができる。このため、分散型台帳は共有データの検証可能性を担保する手段として有効である。
 分散型台帳を活用したシステムにおいて、システムの更新又は移行等の理由により、運用中である分散型台帳(移行元分散型台帳)を新環境である分散型台帳(移行先分散型台帳)に置き換える際には、移行元分散型台帳に登録済みのデータの少なくとも一部を、必要に応じて移行先分散型台帳に移行する必要がある。
 特許文献1は、台帳に記録されている資産に対するトランザクションに応答して、移行元分散型台帳が記録しているデータを移行先分散型台帳に登録することによりデータ移行を行う装置を開示している。
特開2020-042671号公報
 特許文献1の方法は、台帳が記録している最新データ値のみを移行先分散型台帳に移行する方法であり、移行元分散型台帳にあるトランザクションは移行されない。そのため、特許文献1の方法によれば、過去のトランザクションを保持する場合、移行元分散型台帳を運用し続けなければならないという課題がある。
 本開示は、移行元分散型台帳から移行先分散型台帳に電子データを移行する場合において、移行元分散型台帳が記録している最新データ値だけでなく、移行元分散型台帳が記録している過去のトランザクションも移行先分散型台帳に移行することを目的とする。
 本開示に係るデータ移行装置は、
 移行元分散型台帳から移行先分散型台帳に電子データを移行する移行要求に基づいて、1つ以上の要素を含むデータである移行データの各要素として作成されるそれぞれの作成要素に対応するデータを含む取得データを前記移行元分散型台帳から取得するデータ取得部と、
 前記取得データから前記作成要素に対応するデータを選別して抽出するデータ選別部と、
 それぞれの前記作成要素に対応するデータを前記移行先分散型台帳に移行する移行順序を、前記作成要素に対応するデータを用いて作成する移行順序作成部と
を備え、
 前記移行データは、前記移行要求に対応するデータであり、
 それぞれの前記作成要素は、前記電子データの少なくとも一部に対応する。
 データ取得部が移行元分散型台帳から取得データを取得し、データ選別部が取得データから作成要素に対応するデータを抽出し、移行順序作成部が移行データの各要素として作成されるそれぞれの作成要素の移行順序を決める。そのため、移行元分散型台帳が記録している過去のトランザクションを作成要素に対応するデータが含む場合において、移行順序作成部がトランザクションを含むデータを移行する順序を決める。また、取得データは移行元分散型台帳が記録している最新データ値を含んでもよい。
 従って、本開示によれば、移行元分散型台帳から移行先分散型台帳に電子データを移行する場合において、移行元分散型台帳が記録している最新データ値だけでなく、移行元分散型台帳が記録している過去のトランザクションも移行先分散型台帳に移行することができる。
実施の形態1に係るデータ移行システム90の構成例を示す図。 実施の形態1に係るデータ移行システム90が備える各装置のハードウェア構成例を示す図。 実施の形態1に係るデータ移行システム90が備える各装置のソフトウェア構成例を示す図。 実施の形態1に係るデータ移行システム90の動作を示すフローチャート。 実施の形態1に係る移行元データ取得要求501の具体例を示す図。 実施の形態1に係る選別済みトランザクションデータ502の具体例を示す図。 実施の形態1に係る補足データ503の具体例を示す図。 実施の形態1に係るトランザクション関係グラフ504と頂点データ505と辺データ506との具体例を示す図。 実施の形態1に係る主キー更新履歴表507とスマートコントラクト更新履歴表508との具体例を示す図。 実施の形態1に係るトランザクション関係データ作成部121の動作を示すフローチャート。 実施の形態1に係るトランザクション関係データ作成部121の動作を示すフローチャート。 実施の形態1に係る移行先データ登録要求509の具体例を示す図。 実施の形態1に係る移行データ510の具体例を示す図。 実施の形態1に係るデータ作成部132の動作を示すフローチャート。 実施の形態1に係るデータ送信部133の動作を示すフローチャート。 実施の形態1の変形例に係るデータ移行装置1のハードウェア構成例を示す図。 実施の形態2に係るデータ移行システム90の構成例を示す図。 実施の形態2に係るデータ移行システム90が備える各装置のハードウェア構成例を示す図。 実施の形態2に係るデータ移行システム90が備える各装置のソフトウェア構成例を示す図。 実施の形態2に係るデータ移行システム90の動作を示すフローチャート。 実施の形態2に係る移行先データ登録要求509bの具体例を示す図。 実施の形態2に係るデータ作成部132の動作を示すフローチャート。 実施の形態2に係るデータ作成部132の動作を示すフローチャート。 実施の形態2に係るデータ送信部133の動作を示すフローチャート。 実施の形態3に係るデータ移行システム90の構成例を示す図。 実施の形態3に係るデータ移行システム90が備える各装置のソフトウェア構成例を示す図。 実施の形態3に係るデータ移行システム90の動作を示すフローチャート。 実施の形態3に係るデータ検証要求511の具体例を示す図。 実施の形態3に係る検証部163の動作を示すフローチャート。 実施の形態3に係る検証部163の動作を示すフローチャート。 実施の形態4に係るデータ移行システム90の構成例を示す図。 実施の形態4に係るデータ移行システム90が備える各装置のハードウェア構成例を示す図。 実施の形態4に係るデータ移行システム90が備える各装置のソフトウェア構成例を示す図。 実施の形態4に係るデータ取得部112の動作を示すフローチャート。 実施の形態4に係るデータ送信部133の動作を示すフローチャート。
 実施の形態の説明及び図面において、同じ要素及び対応する要素には同じ符号を付している。同じ符号が付された要素の説明は、適宜に省略又は簡略化する。図中の矢印はデータの流れ又は処理の流れを主に示している。また、「部」を、「回路」、「工程」、「手順」、「処理」又は「サーキットリー」に適宜読み替えてもよい。
 実施の形態1.
 以下、本実施の形態について、図面を参照しながら詳細に説明する。
***構成の説明***
 図1は、本実施の形態に係るデータ移行システム90の構成例を示している。データ移行システム90は、本図に示すように、データ移行装置1と、管理装置2と、移行元台帳ネットワーク3と、移行先台帳ネットワーク4とを備える。データ移行装置1はデータ抽出・移行装置とも呼ばれる。移行元台帳ネットワーク3は移行元分散型台帳ネットワークとも呼ばれる。移行先台帳ネットワーク4は移行先分散型台帳ネットワークとも呼ばれる。
 データ移行装置1は、管理装置2から移行要求を受け、移行要求に基づいて、移行元台帳ネットワーク3からトランザクションと補足データ503とを適宜抽出し、抽出したトランザクションと補足データ503とを移行先台帳ネットワーク4に移行する。移行要求は、電子データを移行元分散型台帳から移行先分散型台帳に移行する要求である。要求という用語は指示内容を含む情報を指すこともある。データ移行装置1は、アプリケーションであってもよい。アプリケーションは、アプリケーションプログラムとも呼ばれる。装置という用語を装置とアプリケーションの総称として用いることもある。装置は、物理的なものに限られず、仮想化技術によって生成された仮想的なものであってもよい。
 データ移行装置1は、管理装置2と、移行元台帳ネットワーク3の少なくとも1つの移行元ノード31と、移行先台帳ネットワーク4の少なくとも1つの移行先ノード41と相互に通信することができる。
 管理装置2は、データ移行装置1に移行要求と補足データ503とを送信する機能を持つ装置またはアプリケーションである。管理装置2は管理アプリケーションとも呼ばれる。補足データ503は、データ移行装置1が移行先台帳ネットワーク4に対するトランザクションを作成する際に用いるデータである。
 移行元台帳ネットワーク3は、移行トランザクションを記録している稼働中の分散型台帳ネットワークである。移行トランザクションは移行対象のトランザクションである。移行元台帳ネットワーク3は1つ以上の移行元ノード31から構成される。移行元ノード31は、移行元分散型台帳を記録する装置又はアプリケーションである。
 移行先台帳ネットワーク4は、移行トランザクションの移行先である分散型台帳ネットワークである。移行先台帳ネットワーク4は1つ以上の移行先ノード41から構成される。移行先ノード41は、移行先分散型台帳を記録する装置又はアプリケーションである。
 図2は、データ移行システム90が備える各装置のハードウェア構成例を示している。本図は、データ移行装置1と、管理装置2と、移行元ノード31と、移行先ノード41とのそれぞれが独立した装置において動作する場合における具体例を示している。各装置は、プロセッサ81と、メモリ82と、補助記憶装置84と、通信インタフェース83等のハードウェアを備えるコンピュータである。これらのハードウェアは、信号線を介して適宜接続されている。各装置は1つのネットワークを介して接続される。なお、データ移行システム90が備えるネットワークの数は1つでなくてもよく、データ移行装置1と管理装置2との間と、データ移行装置1と移行元台帳ネットワーク3の少なくとも1つの移行元ノード31との間と、データ移行装置1と移行先台帳ネットワーク4の少なくとも1つの移行先ノード41との間とのそれぞれにおいて通信することができれば、データ移行システム90は複数のネットワークを備えてもよい。また、データ移行装置1と、管理装置2と、移行元ノード31と、移行先ノード41との少なくとも一部は、同一の装置から構成されていてもよい。データ移行システム90が備える各装置は、複数のコンピュータから成ってもよい。なお、ノードは装置でもある。
 プロセッサ81は、演算処理を行うIC(Integrated Circuit)であり、かつ、コンピュータが備えるハードウェアを制御する。プロセッサ81は、具体例として、CPU(Central Processing Unit)、DSP(Digital Signal Processor)、又はGPU(Graphics Processing Unit)である。
 データ移行システム90が備える各装置は、プロセッサ81を代替する複数のプロセッサを備えてもよい。複数のプロセッサは、プロセッサ81の役割を分担する。
 メモリ82は、典型的には、揮発性の記憶装置である。メモリ82は、主記憶装置又はメインメモリとも呼ばれる。メモリ82は、具体例として、RAM(Random Access Memory)である。メモリ82に記憶されたデータは、必要に応じて補助記憶装置84に保存される。
 通信インタフェース83は、レシーバ及びトランスミッタである。通信インタフェース83は、具体例として、通信チップ又はNIC(Network Interface Card)である。データ移行システム90が備える各装置の各部は、他の装置等と通信する際に、通信インタフェース83を適宜用いる。
 補助記憶装置84は、典型的には、不揮発性の記憶装置である。補助記憶装置84は、具体例として、ROM(Read Only Memory)、HDD(Hard Disk Drive)、又はフラッシュメモリである。補助記憶装置84に記憶されたデータは、必要に応じてメモリ82にロードされる。
 補助記憶装置84は、データ移行プログラムを記憶している。データ移行プログラムは、データ移行装置1が備える各部の機能をコンピュータに実現させるプログラムである。データ移行プログラムは、メモリ82にロードされて、プロセッサ81によって実行される。データ移行システムが備える各装置の各部の機能は、ソフトウェアにより実現される。
 データ移行システム90が備える各装置の各部は、適宜記憶装置を利用する。記憶装置は、具体例として、メモリ82と、補助記憶装置84と、プロセッサ81内のレジスタと、プロセッサ81内のキャッシュメモリとの少なくとも1つから成る。なお、データと、情報とは、同等の意味を有することもある。記憶装置は、コンピュータ10と独立したものであってもよい。
 メモリ82及び補助記憶装置84の機能は、他の記憶装置によって実現されてもよい。
 本明細書に記載されているいずれの装置において動作するプログラムも、コンピュータが読み取り可能な不揮発性の記録媒体に記録されていてもよい。不揮発性の記録媒体は、具体例として、光ディスク又はフラッシュメモリである。本明細書に記載されているいずれの装置において動作するプログラムも、プログラムプロダクトとして提供されてもよい。
 図3は、データ移行システム90が備える各装置のソフトウェア構成例を示している。本例において、少なくとも1つの移行元ノード31と少なくとも1つの移行先ノード41とへのアクセス権限を持つ代表者が全てのデータを移行することを想定している。代表者はコンピュータ等であってもよい。
 データ移行装置1は、データ抽出部11と、移行順序作成部12と、データ登録部13と、補足データ管理部14とを備える。
 データ抽出部11は、取得要求受付部111と、データ取得部112と、データ選別部113とを備える。
 取得要求受付部111は、移行元台帳ネットワーク3のトランザクションとトランザクションに関係する補足データ503とを移行元分散型台帳から取得するよう要求する取得要求を管理装置2から受け取る。
 データ取得部112は、移行元台帳ネットワーク3からトランザクションとトランザクションに関係する補足データ503とを含むデータを取得データとして取得する。データ取得部112は、移行要求に基づいて取得データを移行元分散型台帳から取得する。移行元分散型台帳からデータを取得することは、当該移行元分散型台帳を記録している移行元ノード31から当該データを受信することによって実現される。取得データは、後述の移行データ510の各要素として作成されるそれぞれの作成要素に対応するデータを含む。なお、作成要素という表現は、移行データ510の要素としてまだ作成されていない要素も説明するための表現である。移行データ510は、1つ以上の要素を含むデータであり、移行要求に対応するデータであり、かつ、移行元分散型台帳が記録している電子データの少なくとも一部を示すデータである。移行データ510の各要素は、具体例として、後述の頂点データ505を示すデータである。作成要素に対応するデータは、具体例として、作成要素である頂点IDに対応する頂点データ505が示すトランザクションIDに対応する選別済みトランザクションデータ502である。即ち、各作成要素は、移行元分散型台帳から移行先分散型台帳に移行する電子データの少なくとも一部に対応する。補足データ503は、作成要素に対応するデータの少なくとも1つに1対1で対応する少なくとも1つのデータであって、それぞれの作成要素に対応するデータを移行先分散型台帳に移行することを補助するデータである。
 データ選別部113は、取得データを選別することにより、移行データ510が含むべきデータに対応するデータを抽出し、また、補足データ503が含むべきデータを取得データが含む場合に補足データ503が含むべきデータを抽出する。データ選別部113は、取得データから作成要素に対応するデータを選別して抽出する。データ選別部113は、取得データから作成要素に対応するデータを選別済みトランザクションデータ502として抽出してもよい。
 データ選別部113は、移行データ510が含むべきデータに対応するデータをトランザクション関係データ作成部121に送り、補足データ503を補足データ受付部141に送る。
 移行順序作成部12は、トランザクション関係データ作成部121と、トランザクション関係データ記録部122とを備え、トランザクション順序整理部とも呼ばれる。移行順序作成部12は、それぞれの作成要素に対応するデータを移行先分散型台帳に移行する移行順序を、作成要素を用いて作成する。移行順序作成部12は、補足データ503がある場合に、作成要素に対応するデータと補足データ503とを用いて移行順序を作成する。作成要素に対応するデータは、具体例として、選別済みトランザクションデータ502、又は、選別済みトランザクションデータ502と当該選別済みトランザクションデータ502に対応する補足データ503との組である。
 トランザクション関係データ作成部121は、データ選別部113が抽出したデータであって、移行先分散型台帳に移行するデータが含むべきデータを元に、移行先台帳ネットワーク4への効率の良いトランザクションの登録順序を導くことを補助するトランザクション関係データを作成し、作成したトランザクション関係データをトランザクション関係データ記録部122に記録する。トランザクション関係データ作成部121は、補足データ503がない場合に、選別済みトランザクションデータ502を用いて、選別済みトランザクションデータ502間の関係に基づいてトランザクション関係データを作成する。トランザクション関係データは、移行順序を規定するデータである。また、トランザクション関係データ作成部121は、補足データ503がある場合に、選別済みトランザクションデータ502と、補足データ503とを用いてトランザクション関係データを作成する。トランザクション関係データ作成部121は、トランザクション関係データとして、トランザクション関係グラフ504を作成してもよい。トランザクション関係グラフ504は、移行順序と移行条件とをグラフ構造により表す。移行条件は、選別済みトランザクションデータ502を移行先分散型台帳に移行する条件である。
 データ登録部13は、登録要求受付部131と、データ作成部132と、データ送信部133とを備える。
 登録要求受付部131は、移行するデータを移行先分散型台帳に登録するよう要求する登録要求を管理装置2から受け取る。
 データ作成部132は、トランザクション関係データ記録部122が記録しているトランザクション関係データを取得し、トランザクションの生成を開始した時点において移行先分散型台帳に登録することができるデータを用いて移行先分散型台帳向けのトランザクションを生成する。データ作成部132は、作成要素に対応するデータを用いて、それぞれの作成要素の形式に従ってそれぞれの作成要素を作成してもよい。
 データ作成部132は、データ作成時に、トランザクション関係データ記録部122から読み出したデータと当該データに対応する補足データ503とを組み合わせて1つのトランザクションとする必要があるものである場合に、補足データ記録部142から対応する補足データ503を参照し、トランザクション関係データ記録部122から読み出したデータと対応する補足データ503とを組み合わせて1つのトランザクションを生成する。
 また、データ作成部132は、データ作成時に、トランザクション関係データ記録部122から読み出した移行するデータが、移行するデータから生成したトランザクションを移行先台帳ネットワーク4に登録する際に、合わせて何かのデータを移行先台帳ネットワーク4に対して作用させる必要があるものである場合、補足データ記録部142から対応する補足データ503を参照し、移行するデータから生成したトランザクションと補足データ503とをデータ送信部133を通じて移行先台帳ネットワーク4に登録させ、かつ、作用させる。
 データ作成部132は、それぞれの作成要素として、選別済みトランザクションデータ502を示すデータ、又は、選別済みトランザクションデータ502と選別済みトランザクションデータ502に対応する補足データ503とのそれぞれを示すデータを含むデータを、トランザクション関係データを利用して作成してもよい。データ作成部132は、トランザクション関係グラフ504のグラフ構造を利用して、移行先分散型台帳に登録することができるそれぞれの作成要素に対応するデータを登録可能データとして抽出してもよい。
 データ送信部133は、移行先台帳ネットワーク4にトランザクションを送信する。データ送信部133は、それぞれの作成要素に対応するデータを、移行順序に基づいて移行先分散型台帳に送信する。データ送信部133は、登録可能データを含むデータを移行先分散型台帳に送信してもよい。移行先分散型台帳にデータを送信することは、当該移行先分散型台帳を記録する移行先ノード41に当該データを送信することによって実現される。
 補足データ管理部14は、補足データ受付部141と、補足データ記録部142とを備える。
 補足データ受付部141は、管理装置2とデータ選別部113との少なくともいずれかから補足データ登録要求を受け取り、補足データ登録要求を受け取った場合に補足データ503を補足データ記録部142に記録する。
 管理装置2は、移行要求部21と、補足データ登録要求部22とを備える。
 移行要求部21は、取得要求部211と、登録要求部212とを備える。
 取得要求部211は、データ移行装置1に対して、トランザクション及びトランザクションに関係する補足データ503を移行元台帳ネットワーク3から取得することと、トランザクション関係データを作成することとを要求する。
 登録要求部212は、データ移行装置1に対して、作成したトランザクション関係データと補足データ503とを利用して、移行先台帳ネットワーク4に移行するデータを登録することを要求する。
 補足データ登録要求部22は、データ移行装置1に対して、移行するデータに対応する補足データ503を登録することを要求する。
 移行元ノード31は、データ移行装置1からのデータ取得要求に応じて、トランザクションとトランザクションに関係する補足データ503とを含むデータをデータ移行装置1に送信する機能を備える。
 移行先ノード41は、データ移行装置1からのトランザクション登録要求に応じて、トランザクションデータを移行先台帳ネットワーク4において共有している台帳に登録する機能を備える。また、移行先ノード41は、データ移行装置1からの補足データ503を登録する要求又は作用する要求に応じて、移行先ノード41又は移行先台帳ネットワーク4に補足データ503を登録する機能と作用する機能との少なくともいずれかを備える。
***動作の説明***
 データ移行装置1の動作手順はデータ移行方法に相当する。データ移行装置1の動作を実現するプログラムはデータ移行プログラムに相当する。管理装置2の動作手順は管理方法に相当する。管理装置2の動作を実現するプログラムは管理プログラムに相当する。移行元ノード31の動作手順は移行元制御方法に相当する。移行元ノード31の動作を実現するプログラムは移行元制御プログラムに相当する。移行先ノード41の動作手順は移行先制御方法に相当する。移行先ノード41の動作を実現するプログラムは移行先制御プログラムに相当する。
 図4は、データ移行システム90の動作の一例を示すフローチャートである。本図を参照してデータ移行システム90の動作を説明する。
(ステップS101:データ取得要求処理)
 取得要求部211は、データ移行装置1に移行元データ取得要求501を送信する。
 図5は、移行元データ取得要求501の一例を示している。
 「取得対象台帳ID(Identification)」は、データ取得対象である台帳を一意に表す識別子である。データ取得対象は移行元データを記録している。
 「取得対象台帳名」は、データ取得対象である台帳に設定された名前である。
 「接続移行元ノード」は、データ取得部112がデータを取得するために接続する移行元ノード31の所在を表す情報である。接続移行元ノードは、移行するデータを記録している移行元ノード31である。「接続移行元ノード」の値は、具体例として、移行元ノード31のIP(Internet Protocol)アドレス、又は、移行元ノード31のIPアドレスとポート番号との組み合わせである。
 「接続移行元ノード資格情報」は、接続移行元ノードへ接続する際に認証が必要である場合に利用される情報である。「接続移行元ノード資格情報」はなくてもよい。「接続移行元ノード資格情報」の値は、具体例として、移行元ノード31へログインするためのIDとパスワードとの組、公開鍵と秘密鍵により署名したデータとの組、又は、アクセストークンである。
(ステップS102:データ要求処理)
 取得要求受付部111は、移行元データ取得要求501を受け取る。データ取得部112は、移行元データ取得要求501を利用し、接続移行元ノードに対して取得対象台帳名が示す台帳に記録されているトランザクションとトランザクションに関連する補足データ503とを要求する。
(ステップS103:要求データ送信処理)
 接続移行元ノードは、データ取得部112に要求されたトランザクションと補足データ503とをデータ取得部112に送信する。
(ステップS104:選別処理)
 データ取得部112は、トランザクションと補足データ503とを取得データとして取得する。データ選別部113は、取得データから移行処理において必要であるデータのみを選別する。
 具体例として、移行元分散型台帳がブロックチェーンである場合、移行元台帳ネットワーク3において複数のトランザクションがブロックと呼ばれるまとまりで管理されている。この場合において、データ取得部112は移行元ノード31からブロックを取得し、データ選別部113はデータ取得部112が取得したブロックの中から各トランザクションを抽出してもよい。
 図6は、選別済みトランザクションデータ502の一例を示している。選別済みトランザクションデータ502は、データ選別部113によって選別されたトランザクションデータである。
 「取得対象台帳ID」は、データを取得する対象である台帳を一意に表す識別子である。「取得対象台帳ID」の値は、移行元データ取得要求501が設定した取得対象台帳IDと同じ値である。
 「トランザクションID」は、取得対象台帳が含むトランザクションを一意に表す識別子である。以下、本図の説明において、特に断りがない限りトランザクションはトランザクションIDが示すトランザクションである。
 「実行順序情報」は、トランザクションが台帳に適用されたタイミングを表す情報である。「実行順序情報」の値は、具体例として、移行元分散型台帳がブロックチェーンである場合、ブロック番号と、トランザクションがブロックの中で何番目に適用されたかを示す情報とを組み合わせることによりを作られたものである。また、実行順序情報は、あるトランザクションを実行する前に処理すべきトランザクションのリストを用いて生成されてもよい。
 「種別」は、トランザクションが実行する処理の種類を表す。処理の種類は、具体例として、分散型台帳組み込み機能実行と、スマートコントラクト実行と、スマートコントラクトデプロイと、スマートコントラクト更新とのいずれかである。
 「実行対象」は、トランザクションによって実行される処理が定義されている場所を示す。実行対象は、分散型台帳に組み込まれている機能が格納されている場所を指す情報であってもよく、ブロックチェーンにおいて動作するロジックであるスマートコントラクトを指す情報であってもよい。
 「実行処理」は、トランザクションによって実行される具体的な処理を示す。「実行処理」の値は、具体例として、分散型台帳に組み込まれている機能と、スマートコントラクトのデプロイ又は更新と、スマートコントラクトに定義されている処理とのいずれかである。
 「処理引数リスト」は、実行処理が示す処理が必要とするデータ群が設定されたリストである。
 「実行者情報」は、トランザクションの実行者を示す情報である。
 「実行結果」は、実行対象が示す対象について実行処理が示す処理を処理引数リストが示す引数を用いて実行したときのトランザクションの実行結果を表す。「実行結果」の値は、具体例として、当該処理の実行において、参照されたデータを示す参照情報と、書き込まれたデータを示す書込情報との二種類から成る。なお、典型的には、移行元ノード31内部の処理実行用の保存領域である状態DB(Database)が、参照情報と書込情報とを記憶している。参照情報は、具体例として、処理実行時に参照された全ての状態DBの主キーである。書込情報は、具体例として、処理実行時に書き込まれた全ての状態DBの主キーである。
 実行結果がトランザクションに含まれない分散型台帳を利用するものである場合を考える。この場合において、具体例として、分散型台帳が処理の実行時にトランザクションを追うこと又はトランザクションとの関係性を追うことができる保存領域に任意のデータを格納する機能をサポートするとき、データ選別部113は当該機能を利用してもよい。具体的には、スマートコントラクト実行時に参照したデータの主キーと書き込んだデータの主キーとを、トランザクション又はトランザクションとの関係性を追うことができる保存領域に記録することにより、データ選別部113はデータ取得部112からデータを取得したときに実行結果を取得することができる。データ選別部113は、この手順により取得した実行結果をトランザクションに結合してもよく、また、当該実行結果を補足データ503として管理してもよい。
 また、データ選別部113は、前述の機能を利用せず、任意の手段によりトランザクションの実行をエミュレートすることにより実行結果を求め、求めた実行結果を補足データ503として補足データ登録要求部22を利用して補足データ管理部14に登録してもよい。
 図6に例示する選別済みトランザクションデータ502は、分散型台帳にデプロイされているスマートコントラクトを実行するトランザクションである。ここで、種別をスマートコントラクトデプロイ又はスマートコントラクト更新とすることにより、選別済みトランザクションデータ502はスマートコントラクトのデプロイ又は更新に関するトランザクションを表現することもできる。このとき、実行対象の値として、デプロイ又は更新するスマートコントラクト名が設定されることが想定される。
 図7は、補足データ503の一例を示している。当該補足データ503は、データ選別部113によって選別されたものである。
 「補足データID」は、補足データ503を一意に表す識別子である。
 「取得対象台帳ID」は、データ取得対象である台帳を一意に表す識別子である。「取得対象台帳ID」の値は、移行元データ取得要求501の取得対象台帳IDが示す値と同じ値である。以下、本図の説明において、特に断りがない限り台帳は取得対象台帳IDが示す台帳である。
 「トランザクションID」は、台帳に含まれるトランザクションを一意に表す識別子である。「トランザクションID」の値は、補足データ503に関連するトランザクションの識別子である。
 「データ種別」は、補足データ503の種別を表す。補足データ503の種別は、具体例として、補足データ503がスマートコントラクト本体のデータを表すことを示す「スマートコントラクト」と、補足データ503が台帳上には直接記録されない秘密データであることを表す「秘密データ」と、実行結果がトランザクションに含まれない分散型台帳を利用する場合に使用される「実行結果」とのいずれかである。
 「データ」は、補足データ503の本体である。「データ」の値は、具体例として、補足データ503がスマートコントラクトである場合、ノードにスマートコントラクトをデプロイする際に用いられるスマートコントラクト本体のデータである。補足データ503が秘密データである場合、「データ」の値は、具体例として、秘密データ本体のデータである。補足データ503が実行結果である場合、「データ」の値は、具体例として、図6の「実行結果」と同様の値である。
(ステップS105:選別データ送信処理)
 データ選別部113は、最終的に選別したデータの内、選別済みトランザクションデータ502を移行順序作成部12に送信し、補足データ503を補足データ管理部14に送信する。
(ステップS106:補足データ読み出し処理)
 トランザクション関係データ作成部121は、データ選別部113から受信した選別済みトランザクションデータ502に関係する補足データ503を補足データ記録部142から読み出す。
(ステップS107:トランザクション関係データ作成処理)
 トランザクション関係データ作成部121は、選別済みトランザクションデータ502と補足データ503とを用いてトランザクション関係データを作成する。トランザクション関係データは、移行先台帳ネットワーク4に効率良くトランザクションを登録する順序を導くことを補助するデータである。
 図8は、トランザクション関係グラフ504の一例と、トランザクション関係グラフ504の構成要素である頂点データ505及び辺データ506それぞれの一例とを示している。トランザクション関係グラフ504は、トランザクション関係データの一例であり、グラフ構造のデータ形式を利用したものである。トランザクション関係グラフ504の1つの頂点は1つの頂点データ505に対応する。トランザクション関係グラフ504の1つの辺は1つの辺データ506に対応する。
 図8に示すトランザクション関係グラフ504の各項目を説明する。
 「取得対象台帳ID」は、データ取得対象である台帳を一意に表す識別子である。以下、本図の説明において、特に断りがない限り台帳は取得対象台帳IDが示す台帳である。
 「頂点集合」は、トランザクション関係グラフを構成する頂点データ505の頂点IDのリストである。
 「辺集合」はトランザクション関係グラフを構成する辺データ506の辺IDのリストである。頂点集合と辺集合とのそれぞれは、トランザクション関係グラフを構成する頂点と辺とのそれぞれの情報を保持するものであればよい。このため、頂点集合は頂点データ505のリストであってもよく、辺集合は辺データ506のリストであってもよい。
 図8に示す頂点データ505の各項目を説明する。
 「頂点ID」は、頂点を一意に表す識別子である。以下、頂点データ505の説明において頂点は頂点IDが示す頂点を指す。
 「トランザクションID」は、台帳に含まれるトランザクションを一意に表す識別子である。
 「補足データID」は、トランザクションIDが示すトランザクションに関連する補足データIDのリストである。
 「参照」は、頂点に対応するトランザクションを実行する際に参照した状態DBの主キーと、主キーのバージョンとのペアのリストである。主キーのバージョンは、状態DBにおいてその主キーの値が更新された回数又は更新された時期を示す情報である。具体例として、その主キーの値を更新したトランザクションの実行順序を示す情報、又は、状態DBに内蔵されているバージョン管理機能が管理しているバージョン値を利用することができる。
 「書込」は、頂点に対応するトランザクションの実行の際に書き込んだ状態DBの主キーと、主キーのバージョンとのペアのリストである。
 図8に示す辺データ506の各項目を説明する。
 「辺ID」は、辺を一意に表す識別子である。以下、辺データ506の説明において、特に断りがない限り辺は辺IDが示す辺である。
 「出力側頂点ID」は、辺が出力されている頂点の頂点IDを表す。
 「入力側頂点ID」は、辺が入力されている頂点の頂点IDを表す。
 具体例として、辺IDがe1であり、出力側頂点IDがv1であり、入力側頂点IDがv2である場合を考える。この場合において、辺e1は、移行先分散型台帳に対して、データ移行時に、頂点v1に対応するトランザクションを登録した後に頂点v2に対応するトランザクションを登録しなければならないという制約を表している。
 図9は、主キー更新履歴表507の一例とスマートコントラクト更新履歴表508の一例とを示している。
 主キー更新履歴表507は、トランザクション関係グラフ504を作成する過程で使用されるデータであり、移行元分散型台帳のある時点における状態DBにおいて、状態DBに記録される各主キーの最新バージョンと当該最新バージョンの1つ前のバージョンとを示すデータである。
 本例において、バージョンとしてブロックチェーンにおけるトランザクションの実行順序を示す情報が利用されている。本例の1行目のデータは、主キーである「ユーザAの預金データ」が、ブロック5の3番目のトランザクションを実行することによって最後に更新され、また、ブロック4の1番目のトランザクションを実行することによって最後から2番目に更新されたことを表している。
 スマートコントラクト更新履歴表508は、トランザクション関係グラフ504を作成する過程で使用されるデータである。本例において、スマートコントラクト更新履歴表508は、ある時点における、実行対象であるスマートコントラクトの名称を示す「スマートコントラクト名」と、移行元分散型台帳にデプロイされているスマートコントラクトの最新版をデプロイした又は更新したトランザクションのトランザクションIDを示す「最新版をデプロイ/更新したトランザクションのトランザクションID」とから成る。
 図10及び図11は、トランザクション関係データ作成部121がトランザクション関係グラフを作成する動作の一例を示すフローチャートである。これらの図を参照してトランザクション関係データ作成部121の処理を説明する。なお、1つのフローチャートが図10及び図11に分割されている。TXはトランザクションの略記である。SCはスマートコントラクトの略記である。
(ステップS121)
 トランザクション関係データ作成部121は、グラフ化対象である選別済みトランザクションデータ502をリストに格納する。
(ステップS122)
 トランザクション関係データ作成部121は、リスト内の選別済みトランザクションデータ502の内、実行順序情報が示す実行順序が最も古いものを1件抽出する。本フローチャートの以下のステップにおいて、選別済みトランザクションデータ502は、本ステップにおいて抽出された選別済みトランザクションデータ502を指す。
(ステップS123)
 トランザクション関係データ作成部121は、選別済みトランザクションデータ502と選別済みトランザクションデータ502に関連する補足データ503とを用いて頂点データ505を作成する。以下、本フローチャートの説明において、トランザクション関係データ作成部121が次に本ステップの処理を実行するまで、「作成した頂点データ505」は、特に断りがない限りここで作成された頂点データ505を指す。即ち、トランザクション関係データ作成部121が本ステップの処理を実行する度に、「作成した頂点データ505」が指す頂点データ505が更新される。
 頂点データ505を作成する手法の具体例を説明する。トランザクション関係データ作成部121は、トランザクション関係データ作成部121が本フローチャートに示す処理を開始して以降本ステップの処理を実行するまでに作成した頂点IDと重複しないように値を新規に生成し、生成した値を「頂点ID」に設定し、「トランザクションID」に選別済みトランザクションデータ502のトランザクションIDを設定し、「補足データID」に補足データ503のIDを設定する。選別済みトランザクションデータ502に関連する補足データ503がない場合、トランザクション関係データ作成部121は、補足データIDに空のリストを設定する。トランザクション関係データ作成部121は、選別済みトランザクションデータ502の実行結果又は選別済みトランザクションデータ502に関連する補足データ503の実行結果が示す参照データと、主キー更新履歴表507とを利用し、主キーと主キーのバージョンとの組を「参照」に設定する。具体的には、実行結果の参照データにある各主キーについて、それぞれの最新バージョンを主キー更新履歴表507から読み取り、主キーと最新バージョンとを組として設定する。なお、実行結果の参照データが0件である場合、トランザクション関係データ作成部121は「参照」を設定しない。トランザクション関係データ作成部121は、選別済みトランザクションデータ502の実行結果又は関連する補足データ503の実行結果が示す書込データと、選別済みトランザクションデータ502の実行順序情報又は主キー更新履歴表507等とを利用し、主キーと主キーのバージョンとの組を「書込」に設定する。トランザクション関係データ作成部121は、主キーのバージョンとして実行順序情報を利用する場合に、主キーと選別済みトランザクションデータ502の実行順序情報との組を「参照」及び「書込」に設定する。他にも、トランザクション関係データ作成部121は、抽出した選別済みトランザクションデータ502によって状態DBに書き込まれる主キーのバージョンを主キー更新履歴表507から導出することができる場合に、主キーと主キー更新履歴表507から導出したバージョンとの組を「参照」及び「書込」に設定してもよい。この場合の具体例として、バージョン情報を1,2,3,…のように自然数により管理し、新しいバージョンの値を主キー更新履歴表507が示す最新バージョンの値に1を足した値とするというルールを利用する方法がある。なお、実行結果の書込データが0件である場合、トランザクション関係データ作成部121は「書込」を設定しない。
(ステップS124)
 トランザクション関係データ作成部121は、主キー更新履歴表507を更新する。具体例として、作成した頂点データ505の「書込」に設定されている各主キーについて、主キー更新履歴表507に最新バージョンとして設定されているバージョンを1つ前のバージョンとして設定し、その後、「書込」に設定されているバージョンを最新バージョンとして設定する。なお、作成した頂点データ505の「書込」が設定されていない場合、トランザクション関係データ作成部121は本ステップの処理をスキップする。
(ステップS125)
 トランザクション関係データ作成部121は、トランザクション関係グラフ504が作成されたか否かを確認する。
 トランザクション関係グラフ504が作成された場合、トランザクション関係データ作成部121はステップS128に進む。それ以外の場合、トランザクション関係データ作成部121はステップS126に進む。
(ステップS126)
 トランザクション関係データ作成部121は、空のトランザクション関係グラフ504を作成する。本フローチャートの以下のステップにおいて、トランザクション関係グラフ504は本ステップにおいて作成されたトランザクション関係グラフ504を指す。
 具体例として、選別済みトランザクションデータ502が最初に読み出したトランザクションデータである場合に、トランザクション関係データ作成部121は、「取得対象台帳ID」に選別済みトランザクションデータ502の「取得対象台帳ID」が示す値を設定し、「頂点集合」と「辺集合」とのそれぞれに空のリストを設定する。
(ステップS127)
 トランザクション関係データ作成部121は、トランザクション関係グラフ504の「頂点集合」にステップS123において作成した頂点データ505を追加する。
(ステップS128)
 トランザクション関係データ作成部121は、選別済みトランザクションデータ502の「種別」がスマートコントラクトデプロイであるか否かを確認する。
 「種別」がスマートコントラクトデプロイである場合、トランザクション関係データ作成部121はステップS129に進む。それ以外の場合、トランザクション関係データ作成部121はステップS132に進む。
(ステップS129)
 トランザクション関係データ作成部121は、トランザクション関係グラフ504の「頂点集合」が示す全ての頂点それぞれに対応する頂点について、頂点に対する辺データ506を作成する。
(ステップS130)
 トランザクション関係データ作成部121は、デプロイした又は更新したスマートコントラクトの名称と、選別済みトランザクションデータ502のトランザクションIDとの組をスマートコントラクト更新履歴表508に記録する。なお、トランザクション関係データ作成部121は、「スマートコントラクト名」を選別済みトランザクションデータ502の「実行対象」と同じものとする。
(ステップS131)
 トランザクション関係データ作成部121は、作成した辺データ506をトランザクション関係グラフ504の「辺集合」に追加する。
(ステップS132)
 トランザクション関係データ作成部121は、選別済みトランザクションデータ502の「種別」がスマートコントラクト更新であるか否かを確認する。
 「種別」がスマートコントラクト更新である場合、トランザクション関係データ作成部121はステップS133に進む。それ以外の場合、トランザクション関係データ作成部121はステップS134に進む。
(ステップS133)
 トランザクション関係データ作成部121は、更新するスマートコントラクトの現在の最新版をデプロイした又は更新したトランザクションが示す時点以降に登録されたトランザクションに対応する全ての頂点データ505それぞれを用いて、作成した頂点データ505に対する辺データ506を作成する。
 トランザクション関係データ作成部121は、具体例として、選別済みトランザクションデータ502の「実行対象」に設定されているスマートコントラクト名を取得し、取得したスマートコントラクト名に対応するスマートコントラクトの最新版をデプロイした又は更新したトランザクションのトランザクションIDをスマートコントラクト更新履歴表508から取得する。さらに、トランザクション関係データ作成部121は、取得したトランザクションIDに対応する選別済みトランザクションデータ502を取得し、取得した選別済みトランザクションデータ502の「実行順序情報」を抽出する。トランザクション関係データ作成部121は、抽出した「実行順序情報」が示す時点以降に登録された選別済みトランザクションデータ502を探し、当該時点以降に登録された選別済みトランザクションデータ502それぞれに対応する頂点データ505を取得する。その後、トランザクション関係データ作成部121は、取得した各頂点データ505と作成した頂点データ505とを両端とする各辺データ506を作成する。なお、スマートコントラクト名は、選別済みトランザクションデータ502の「実行対象」と同じものとする。
(ステップS134)
 トランザクション関係データ作成部121は、作成した頂点データ505と、作成した頂点データ505の「参照」に含まれる主キーと主キーのバージョンとの組を「書込」の要素として含む頂点データ505とを両端とする辺データ506を作成する。
(ステップS135)
 トランザクション関係データ作成部121は、作成した頂点データ505と、作成した頂点データ505の「書込」に含まれる主キーの1つ前のバージョンの主キーと1つ前のバージョンの主キーのバージョンとの組を「参照」又は「書込」の要素として含む頂点データ505とを両端とする辺データ506を作成する。
(ステップS136)
 トランザクション関係データ作成部121は、選別済みトランザクションデータ502の「実行対象」が示すスマートコントラクトの最新版をデプロイした又は更新したトランザクションのトランザクションIDを、選別済みトランザクションデータ502の「実行対象」とスマートコントラクト更新履歴表508とを利用して取得し、作成した頂点データ505と、取得したトランザクションIDのトランザクションに対応する頂点データ505とを両端とする辺データ506を作成する。
(ステップS137)
 トランザクション関係データ作成部121は、リストからステップS122において抽出したトランザクションデータを削除する。
(ステップS138)
 トランザクション関係データ作成部121は、リストが空であるか否かを確認する。
 リストが空である場合、トランザクション関係データ作成部121は本フローチャートの処理を終了する。リストが空でない場合、トランザクション関係データ作成部121はステップS121に進む。
(ステップS139)
 本ステップにおける処理は、ステップS128における処理と同様である。
(ステップS140)
 本ステップにおける処理は、ステップS130における処理と同様である。
(ステップS108:データ記録処理)
 トランザクション関係データ作成部121は、生成したトランザクション関係データと、データ選別部113から受信した選別済みトランザクションデータ502とをトランザクション関係データ記録部122に記録する。
 トランザクション関係データ記録部122に記録されるトランザクション関係データとしては、トランザクション関係データがトランザクション関係グラフ504である場合、トランザクション関係グラフ504と、トランザクション関係グラフ504を構成する頂点データ505と辺データ506とが挙げられる。
(ステップS109:補足データ送信処理)
 外部にある補足データ503が必要である場合、補足データ登録要求部22は、データ移行装置1に補足データ503を送信する。
 補足データ503を送信するタイミングは、前述のデータ抽出部11又は移行順序作成部12の処理の前又は途中であってもよい。データ移行装置1は、補足データ受付部141を用いて補足データ503を受け取り、受け取った補足データ503を補足データ記録部142に記録する。
(ステップS110:登録要求送信処理)
 登録要求部212は、データ移行装置1に移行先データ登録要求509を送信する。
 図12は、移行先データ登録要求509の一例を示している。
 「移行先台帳ID」は、移行先である台帳を一意に表す識別子である。
 「台帳名」は、移行先である台帳に設定された名前である。
 「取得対象台帳ID」は、移行元である台帳を一意に表す識別子である。
 「接続移行先ノード」は、「接続移行元ノード」と同様であり、データ送信部133がデータを移行する接続する移行先ノード41の所在を表す情報である。
 「接続移行先ノード資格情報」は、「接続移行元ノード資格情報」と同様であり、移行先ノード41へ接続する際に認証が必要である場合に利用される情報である。
(ステップS111:移行データ作成処理)
 データ移行装置1は、登録要求受付部131を用いて移行先データ登録要求509を受け取り、データ作成部132を呼び出す。
 データ作成部132は、登録要求受付部131が受信した移行先データ登録要求509と、トランザクション関係データ記録部122が記録しているトランザクション関係データと、補足データ記録部142が記録している補足データ503とを利用して移行データ510を作成し、適宜、作成した移行データ510をデータ送信部133に送信する。
 図13は、移行データ510の一例を示している。
 「順序データ」は、移行データ510を移行先台帳ネットワーク4に適用する順序を表す設定値である。複数の移行データ510が存在する場合、各移行データ510の「順序データ」に互いに異なる値を設定することにより、移行データ510の適用順序を一意に特定することができるようにする。
 「台帳名」は、移行先である台帳に設定された名前である。
 「接続移行先ノード」は、「接続移行元ノード」と同様であり、データ送信部133が接続する移行先ノード41の所在を表す情報である。
 「接続移行先ノード資格情報」は、「接続移行元ノード資格情報」と同様であり、移行先ノード41へ接続する際に認証が必要である場合に利用される情報である。
 「頂点データリスト」は、移行する頂点データ505に対応する要素が含まれるリストである。「頂点データリスト」に含まれる各要素は、作成要素に当たり、移行元分散型台帳から移行先分散型台帳に移行する電子データの少なくとも一部に対応する。「頂点データリスト」に含まれる要素に対応する頂点データ505は移行データ510を生成するタイミングにおいて登録することができるデータを示すため、データ移行装置1はどのような順序で移行先台帳ネットワーク4に頂点データ505が示すデータを登録しても構わない。ただし、複数の移行データ510が存在する場合、データ移行装置1は「順序データ」に示される順序が先である移行データ510から順番に頂点データ505の登録をする必要がある。
 以下では、データ移行装置1がトランザクション関係データとしてトランザクション関係グラフ504を採用する場合における、移行データ510の作成と送信の具体例を示す。
 図14は、データ作成部132が、移行データ510を作成する処理と、作成した移行データ510をデータ送信部133へ送信する処理との一例を示すフローチャートである。本図を参照してデータ作成部132とデータ送信部133との処理を説明する。
(ステップS141)
 データ作成部132は、移行元分散型台帳のトランザクション関係グラフ504の内、データ登録条件が設定されていない頂点データ505を取得し、取得した頂点データ505をリストに登録する。データ作成部132は、移行先データ登録要求509の「取得対象台帳ID」を利用し、トランザクション関係データ記録部122から移行元分散型台帳に対応するトランザクション関係グラフ504を取得する。データ登録条件が設定されていない頂点データ505は、トランザクション関係グラフ504の「頂点集合」に含まれる頂点に対応する頂点データ505の内、トランザクション関係グラフ504の「辺集合」に含まれる辺に対応する辺データ506の「入力側頂点ID」として設定されていない頂点データ505である。
(ステップS142)
 データ作成部132は、リスト内の各頂点データ505を参照し、移行ルールに基づいて頂点データ505を抽出し、抽出した頂点データ505を用いて移行データ510を作成する。
 移行ルールは、具体例として、リストに含まれる全ての頂点データ505を移行データ510に含めるルールが挙げられる。具体例として、分散型台帳としてブロックチェーンを利用する場合を説明する。この場合において、リストに含まれる複数の頂点データ505を1つのブロックデータとしてまとめれば、1トランザクション当たりの合意形成時間を削減することができるため、データ移行に要する時間を短期化することができる。他の移行ルールとして、より多くのトランザクションを登録する前提条件を構成するトランザクションに対応する頂点データ505をより優先して用いて移行データ510を生成するルールも挙げられる。ブロックチェーン利用時にこのルールが適用された場合、データ作成部132はより多くのトランザクションの登録の前提条件を構成するトランザクションに対応する頂点データ505をより優先して用いて移行データ510を生成し、生成された移行データ510が移行先台帳ネットワーク4に登録される。これにより、データ移行装置1は、優先される移行データ510が登録されることを登録の前提条件としている多くのトランザクションを登録することができる。多くのトランザクションの前提条件となるトランザクションを登録することによって登録することができるようになるトランザクション群を1つのブロックデータとしてまとめれば、1トランザクション当たりの合意形成に要する時間を削減できるため、データ移行に要する時間を短期化することができる。ここで、商品のトレーサビリティを管理する分散型台帳活用システムがあり、Nを自然数とし、当該システムにおいて、N個の商品が詰められた1つの段ボールを開封する処理である「段ボールの開封」と、段ボールに詰められている各商品を使用する部署に各商品を配布する処理である「N個の商品の配布」とを管理するものとする。このとき、「段ボールの開封」と「N個の商品の配布」とをトレーサビリティデータとして記録する場合、「段ボールの開封」が実施されていなければ、「N個の商品の配布」を実施することができない。よって、「段ボールの開封」は「多くのトランザクションの前提条件となるトランザクション」に当たり、「段ボールの開封」が登録された場合において「N個の商品の配布」は前述の「トランザクション群」に当たる。
 移行ルールとしては様々なものが考えられ、データ作成部132がトランザクション関係データに応じて適切に移行ルールを切り替えたり組み合わせたりすることにより、データ移行装置1は効率良くデータを移行することができる。
 データ作成部132が、抽出した頂点データ505を用いて移行データ510を作成する具体的な方法を説明する。データ作成部132は、移行データ510の「順序データ」の値がフローチャートの繰り返し処理中に重複しないよう、先に作成した移行データ510から移行先台帳ネットワーク4に適用されるように「順序データ」の値を設定する。データ作成部132は、移行データ510の「台帳名」と「接続移行先ノード」と「接続移行先ノード資格情報」とに移行先データ登録要求509に示される値を設定する。データ作成部132は、リストに含まれる頂点データ505に対応する値を「頂点データリスト」に設定する。データ作成部132は、頂点データ505そのものを「頂点データリスト」に設定してもよく、また、頂点データ505の「頂点ID」を登録する等、頂点データ505を参照するための情報を「頂点データリスト」に設定してもよい。
(ステップS143)
 データ作成部132は、作成した移行データ510をデータ送信部133へ送信する。
(ステップS144)
 データ作成部132は、リスト内の各頂点データ505の「頂点ID」の値を「出力側頂点ID」の値として持つ辺データ506を抽出する。
(ステップS145)
 データ作成部132は、抽出した各辺データ506の入力側頂点IDに対応する頂点データ505を候補リストに登録する。なお、データ作成部132は既に候補リストに登録されている頂点データ505を重複して候補リストに登録しない。候補リストは、候補リストが含む要素に対する処理の時点において、データ登録条件の少なくとも一部が満たされている頂点データ505のリストである。ある頂点データ505のデータ登録条件は、当該ある頂点データ505の「頂点ID」を「入力側頂点ID」として持つ辺データ506が、本ステップの処理を実行するまでに、イテレーションにおけるステップS144の処理によって全て抽出されていることである。イテレーションは本フローチャートにおける繰り返し処理のことである。
(ステップS146)
 データ作成部132は、候補リストが含む各頂点データ505について、データ作成部132が本フローチャートの処理を開始して以降本ステップの処理を実行するまでに抽出した各辺データ506によってデータ登録条件が満たされたか否かを確認し、登録条件が満たされた頂点データ505を次期リストに登録する。次期リストは、イテレーション処理の過程においてデータ登録条件が全て満たされた頂点データ505を要素とするリストである。登録条件が満たされた頂点データ505に対応するデータは、登録可能データである。
 ステップS144からステップS146の処理の具体例を示す。トランザクション関係グラフ504において、「頂点ID」がv2である頂点データ505(以降、頂点v2)を「入力側頂点ID」として持つ辺データ506として、辺e1(v1,v2)と、辺e2(v3,v2)と、辺e3(v4,v2)とが存在するものとする。ここで、辺e1(v1,v2)は「辺ID」がe1、「出力側頂点ID」がv1、「入力側頂点ID」がv2である辺データ506を表す。
 あるイテレーションのステップS144において、このトランザクション関係グラフ504から辺e1(v1,v2)が抽出されたものとする。このとき、当該あるイテレーションのステップS145において、データ作成部132は、辺e1の「入力側頂点ID」に設定されている頂点v2が既に候補リストに登録されていない場合に、頂点v2を候補リストに登録する。当該あるイテレーションのステップS146において、頂点v2に関しては、データ登録条件の内、辺e1(v1,v2)が抽出済みであるため、辺e2(v3,v2)と、辺e3(v4,v2)とがさらに抽出されれば頂点v2が登録可能と判断される。データ作成部132は、このように各頂点に対してデータ登録条件が満たされたかを確認していき、ステップS146の処理において、データ登録条件を満たした頂点データ505を次期リストに登録する。
(ステップS147)
 データ作成部132は、リストと次期リストとが空であるか否かを確認する。
 リストと次期リストとが空である場合、データ作成部132はステップS149に進む。それ以外の場合、即ちリストと次期リストとの少なくとも一方が空ではない場合、データ作成部132はステップS148に進む。
(ステップS148)
 データ作成部132は、リストから移行データ510に含めた頂点データ505を削除し、次期リストの頂点データ505をリストに追加し、次期リストを空にする。
(ステップS149)
 データ作成部132は、データ送信部133に移行データ510の送信が完了したことを示す送信完了通知を送信し、本フローチャートの処理を終了する。
(ステップS112:移行データ送信処理)
 データ送信部133は、データ作成部132から受信した移行データ510に基づき、移行先ノード41にデータを送信する。
 図15は、データ送信部133が移行先ノード41へデータを送信する処理の一例を示すフローチャートである。本図を参照してデータ送信部133の処理を説明する。なお、本図の説明において、移行データ510の「順序データ」には数値が設定されており、データ送信部133は値が小さい「順序データ」を有する移行データ510から順に処理するものとする。
(ステップS161)
 データ送信部133は、データ作成部132から移行データ510又は送信完了通知を受信することを待ち、データを受信した場合に受信したデータをリストに追加する。1度に受信するデータは1件に限られない。また、データ送信部133は本ステップの処理をバックグラウンドで実行してもよい。この際にも、データ作成部132から受信したデータを都度リストに追加する。
(ステップS162)
 データ送信部133は、リストから最も小さい「順序データ」を有するデータを1件取得し、取得したデータをリストから削除する。なお、データ送信部133は、送信完了通知を、最も大きい「順序データ」を有するデータとして扱う。
(ステップS163)
 データ送信部133は、取得したデータが送信完了通知であるか確認する。
 取得したデータが送信完了通知である場合、データ送信部133は本フローチャートの処理を終了する。それ以外の場合、つまり、取得したデータが移行データ510である場合、データ送信部133はステップS164に進む。
(ステップS164)
 データ送信部133は、取得した移行データ510の「頂点データリスト」が含む要素に対応する頂点データ505に従い、移行先ノード41にデータを送信する。
 具体例として、まず、データ送信部133は、移行データ510の「台帳名」と、「接続移行先ノード」と、「接続先ノード資格情報」との少なくともいずれか等を利用して移行先ノード41に接続する。次に、データ送信部133は、「頂点データリスト」が含む要素に対応する各頂点データ505に対応する選別済みトランザクションデータ502と補足データ503との少なくともいずれかを参照し、参照したデータに合わせて、移行先ノード41にトランザクションを送信し、又は、移行先ノード41の機能を呼び出すことにより、移行先ノード41へのデータ送信を完了する。
(ステップS165)
 データ送信部133は、リストが空であるか否かを確認する。
 リストが空ではない場合、データ送信部133はステップS162に進む。リストが空である場合、データ送信部133はステップS161に進む。
 ここまでの動作の説明において、データ移行対象は移行元台帳ネットワーク3の移行対象である台帳に含まれる全てのトランザクションである。しかしながら、データ移行対象は移行元台帳ネットワーク3の移行対象である台帳に含まれる一部のトランザクションであってもよい。
 具体例として、まず、登録要求部212は、データ移行装置1に移行先データ登録要求509を送信する際に、移行先データ登録要求509に移行対象であるトランザクションを示す情報を追加する。次に、データ作成部132は、移行データ510を生成する際に、指定された移行対象であるトランザクションを示す情報のみを移行データ510に変換する。これにより、データ移行装置1は、移行対象である台帳に含まれる一部のトランザクションのみを移行することができる。この際に、データ移行装置1は、指定された移行対象であるトランザクションを示す情報が必要十分であるか否かを確認し、情報が不足している場合に不足しているトランザクションを自動的に追加してもよい。具体例として、トランザクション関係グラフ504を使用した場合を説明すると、あるトランザクションを登録するために事前に登録しておく必要があるトランザクションは辺データ506として記録されている。そのため、データ移行装置1は、当該辺データ506から再帰的に関連する頂点データ505を追っていくことにより、指定時に不足していたトランザクションを発見することができる。具体的な手順としては、まず、データ作成部132は、指定された移行対象であるトランザクションを示す情報に対応する頂点データ505を「入力側頂点ID」として持つ辺データ506を取得し、これらの辺データ506の「出力側頂点ID」に設定されている頂点データ505を取得する。さらに、データ作成部132は、取得した頂点データ505を「入力側頂点ID」として持つ辺データ506を取得し、取得した辺データ506の「出力側頂点ID」に設定されている頂点データ505を取得することを再帰的に繰り返す。再帰的な探索の過程において得られた頂点データ505群から、最初に指定された移行対象であるトランザクションを示す情報に対応する頂点データ505群との重複を取り除いた頂点データ505群が不足しているトランザクションを表している。再帰的な探索の過程において得られた頂点データ505群と、最初に指定された移行対象であるトランザクションを示す情報に対応する頂点データ505群との和集合が、指定された移行対象であるトランザクションを示す情報に対応するデータを移行する際に必要であるトランザクションである。
 ここまでの動作の説明において、データ移行装置1が1つの移行元分散型台帳を1つの移行先分散型台帳に移行する際の動作について示した。しかしながら、データ移行装置1は、複数の移行元分散型台帳間で同じ内容のトランザクションを含まないことを条件とし、複数の移行元分散型台帳を1つの移行先分散型台帳に移行してもよい。従って、データ移行装置1は、同じ内容のトランザクションを重複して含まない複数の移行元分散型台帳のトランザクションを整理し、複数の移行先分散型台帳にデータを振り分けることによってデータを移行する構成であってもよい。
***実施の形態1の効果の説明***
 以上のように、本実施の形態によれば、データ抽出部11と移行順序作成部12と補足データ管理部14とにより、移行元台帳ネットワーク3から取得しかつ加工した選別済みトランザクションデータ502及び補足データ503と、外部から入力した補足データ503とを用いて、移行先台帳ネットワーク4にトランザクションを比較的効率良く登録する順序を導くことを補助するトランザクション関係データを作成することができる。さらに、データ登録部13は、作成されたトランザクション関係データを利用することによって移行先台帳ネットワーク4に対して比較的効率良く移行データ510を登録するができる。そのため、本実施の形態によれば、移行元台帳ネットワーク3とは環境が異なる移行先台帳ネットワーク4に対して、比較的効率良く、トランザクションのデータを移行することができる。
 また、移行元分散型台帳から移行先分散型台帳へのデータ移行を実現する手段として、移行元分散型台帳に保存されている最も古いトランザクションから1件ずつ、移行先分散型台帳に同じ内容のトランザクションを登録する方法(以降、逐次法と表記する)がある。
 逐次法は、移行先分散型台帳に登録するトランザクションの順序を移行元分散型台帳におけるトランザクションの登録順序と確実に合わせるために移行先分散型台帳にトランザクションを1件ずつ登録する。しかしながら、分散型台帳では複数ノードが合意形成を行う。そのため、トランザクションの登録要求から登録完了までに時間を要し、データ移行に要する時間が長くなってしまうという課題がある。なお、分散型台帳の一種であるブロックチェーンにおいては、トランザクションは複数まとめられ、ブロックという単位でデータが登録される。合意形成はブロック単位で行われるため、1つのブロックに複数のトランザクションを含めることにより1トランザクション当たりの合意形成に要する時間を短くすることができる。しかしながら、この際にトランザクションの適用順序を指定する既存技術はなく、移行元分散型台帳におけるトランザクションの登録順序と移行先分散型台帳におけるトランザクションの登録順序とが一致しなくなる可能性がある。そのため、単にブロックに複数のトランザクションをまとめる方法は利用することができない。しかしながら、本実施の形態によれば、移行先分散型台帳に登録することができる複数のトランザクションをまとめて移行先分散型台帳に移行することができる。そのため、本実施の形態によれば、逐次法を採用した場合と比較して効率的に電子データを移行元分散型台帳から移行先分散型台帳に移行することができる。
***他の構成***
<変形例1>
 図16は、本変形例に係るデータ移行装置1のハードウェア構成例を示している。
 データ移行装置1は、本図に示すように、プロセッサ81とメモリ82と補助記憶装置84との少なくとも1つに代えて、処理回路88を備える。
 処理回路88は、データ移行装置1が備える各部の少なくとも一部を実現するハードウェアである。
 処理回路88は、専用のハードウェアであってもよく、また、メモリ82に格納されるプログラムを実行するプロセッサであってもよい。
 処理回路88が専用のハードウェアである場合、処理回路88は、具体例として、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ASIC(ASICはApplication Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)又はこれらの組み合わせである。
 データ移行装置1は、処理回路88を代替する複数の処理回路を備えてもよい。複数の処理回路は、処理回路88の役割を分担する。
 データ移行装置1において、一部の機能が専用のハードウェアによって実現されて、残りの機能がソフトウェア又はファームウェアによって実現されてもよい。
 処理回路88は、具体例として、ハードウェア、ソフトウェア、ファームウェア、又はこれらの組み合わせにより実現される。
 プロセッサ81とメモリ82と補助記憶装置84と処理回路88とを、総称して「プロセッシングサーキットリー」という。つまり、データ移行装置1の各機能構成要素の機能は、プロセッシングサーキットリーにより実現される。
 データ移行システム90が備える他の各装置と、他の実施の形態に係るデータ移行システム90が備える各装置とについても、本変形例と同様の構成であってもよい。
 実施の形態2.
 以下、主に前述した実施の形態と異なる点について、図面を参照しながら説明する。
***構成の説明***
 実施の形態1では、移行元台帳ネットワーク3と移行先台帳ネットワーク4とに接続することができ、かつ、移行元台帳ネットワーク3が含む移行対象であるトランザクションを移行先台帳ネットワーク4に対して登録することができる代表者が1つのデータ移行装置1を利用してデータを移行するケースを説明した。
 本実施の形態において、移行元台帳ネットワーク3が含む移行対象であるトランザクションの取得権限が設定されている場合、又は、移行先台帳ネットワーク4に対するトランザクションの登録権限が設定されている場合等に、複数の参加者が連携しながら複数のデータ移行装置1によってデータを移行する。参加者はデータ移行装置1の利用者又はデータ移行装置1である。利用者はコンピュータ等であってもよい。
 図17は、本実施の形態に係るデータ移行システム90の構成例を示している。本実施の形態と実施の形態1との主な差分は、データ移行システム90が複数のデータ移行装置1を備えている点と、各データ移行装置1が台帳更新監視部15を備えている点と、各データ移行装置1のデータ登録部13から連携対象である他の各データ移行装置1の台帳更新監視部15への通信経路が追加されている点である。本実施の形態において、データ移行装置1と同じ機能を有する他のデータ移行装置1を備えるデータ移行システム90がデータ移行装置1を備える。いずれのデータ移行装置1も、移行元台帳ネットワーク3と移行先台帳ネットワーク4とに接続している。なお、複数のデータ移行装置1を区別するために“-1”等を用いている。データ移行システム90をこのような構成にすることにより、複数のデータ移行装置1それぞれは、台帳更新監視部15により、データ移行の進捗状況を確認しながら、適切なタイミングにおいて適切なトランザクションを移行することができる。
 本図では、データ移行装置1が他のデータ移行装置1と直接通信する場合を示している。しかしながら、データ移行装置1は、何らかの装置又は手段等を媒介して他のデータ移行装置1と通信してもよい。具体例として、各データ移行装置1がアクセスすることができる媒介手段として、DB若しくはデータレイク等のデータストア、メッセージキュー等のメッセージ配信システム、又は、分差型台帳システム等をデータ移行システム90が備え、双方のデータ移行装置1が媒介手段を経由してデータを交換してもよい。また、移行先ノード41がトランザクションに関連する任意のデータを付加することができる場合において、複数のデータ移行装置1間の通信は、移行先ノード41を介して実現されてもよい。
 図18は、データ移行システム90が備える各装置のハードウェア構成例を示している。本実施の形態と実施の形態1との主な差分は、各データ移行装置1が他のデータ移行装置1と通信するために、双方が同じネットワークに参加する構成である点である。ただし、データ移行装置1間の通信が移行先ノード41を介して実現される場合に、ハードウェア構成は実施の形態1と同様のハードウェア構成であってもよい。
 図19は、データ移行システム90が備える各装置のソフトウェア構成例を示している。本実施の形態と実施の形態1との主な差分は、データ移行装置1が台帳更新監視部15を備える点である。
 台帳更新監視部15は、移行先ノード41と移行先分散型台帳と移行先分散型台帳の台帳IDとの少なくともいずれか等を登録要求受付部131から受け取り、対象の移行先分散型台帳におけるトランザクション登録の状況を監視する。また、台帳更新監視部15は、他のデータ移行装置1のデータ送信部133から、トランザクションの移行元におけるトランザクションIDと、当該トランザクションを移行先に登録した際に新たに設定されるトランザクションIDとの対応を示す情報を受信し、受信した情報と、トランザクション登録の状況とを、データ作成部132に対して適宜通知する。台帳更新監視部15は、移行先分散型台帳が他のデータ移行装置1から受信して移行先分散型台帳に登録したデータを示す他装置登録情報を取得する。
 データ作成部132は、電子データを移行している途中において、移行先分散型台帳がデータ送信部133から受信して移行先分散型台帳に登録したデータと、他装置登録情報とに基づいてそれぞれの作成要素を作成してもよい。
 データ送信部133は、それぞれの作成要素に対応するデータを他装置登録情報に基づいて移行先分散型台帳に送信してもよい。また、データ送信部133は、データ送信部133がそれぞれの作成要素に対応するデータを移行先分散型台帳に送信することによって移行先分散型台帳が登録したデータを示す情報を他のデータ移行装置1に向けて送信してもよい。
***動作の説明***
 トランザクション関係データを作成する手順までについては実施の形態1と同様であるため省略する。なお、あるデータ移行装置1のデータ取得部112は、移行元ノード31から「取得対象台帳名」に設定されている台帳に記録されているトランザクションとトランザクションに関連する補足データ503とを取得する際に、アクセス権限が設定されている等の理由により、トランザクションと補足データ503との少なくとも一部を取得することができない場合がある。この場合において、当該あるデータ移行装置1は、アクセス権限を有する他の参加者が取得したトランザクションと補足データ503との少なくとも一部を何らかの手段を用いて共有し、共有したデータを補足データ503として登録してもよい。このようにすることにより、具体例として、データ移行装置1がトランザクション関係データとしてトランザクション関係グラフ504を利用する際に、ある参加者が移行先分散型台帳に登録すべきトランザクションの登録可能条件を構成するトランザクションに関する情報を移行元ノード31から直接取得することができなかったとしても、当該ある参加者は、当該情報を取得することができる他の参加者が取得した情報を、補足データ503として入手すること及び利用することができる。その結果、当該ある参加者は有効なトランザクション関係グラフ504を作成することができる。
 以下、データ移行装置1がトランザクション関係データと補足データ503とを利用して移行先台帳ネットワーク4にデータを移行する手順を説明する。
 なお、あるデータ移行装置1を単にデータ移行装置1と表記し、当該あるデータ移行装置1以外のデータ移行装置1を他のデータ移行装置1と表記する。他のデータ移行装置1は1つのデータ移行装置1に限られない。また、データ移行装置1が備える要素の名称が単に表記されている場合、当該あるデータ移行装置1が備える要素を指す。
 図20は、本実施の形態に係るデータ移行システム90の動作の一例を示すフローチャートである。本図を参照してデータ移行システム90の動作を説明する。
(ステップS201:登録要求送信処理)
 登録要求部212は、データ移行装置1に移行先データ登録要求509bを送信する。
 図21は、本実施の形態における移行先データ登録要求509bの一例を示している。移行先データ登録要求509bと移行先データ登録要求509との主な差分は、「連携データ移行装置情報」が加えられている点である。
 「連携データ移行装置情報」は、移行先データ登録要求509bを有するデータ移行装置1が連携する他の各データ移行装置1の接続情報から成り、連携データ抽出・移行装置情報とも呼ばれる。接続情報は、具体例として、連携する他の各データ移行装置1のIPアドレス等の所在情報、ID及びパスワード、又は、暗号鍵若しくはトークン等の資格情報等の、他のデータ移行装置1に接続するために必要である情報である。「装置2」等は、連携する他の各データ移行装置1の名称である。
(ステップS202:登録要求受信処理)
 登録要求受付部131は、移行先データ登録要求509bを受信し、受信した移行先データ登録要求509bを、台帳更新監視部15と、データ作成部132とに送る。
(ステップS203:接続処理)
 台帳更新監視部15は、受け取った移行先データ登録要求509bが示す情報を元に移行先ノード41に接続し、接続した移行先ノード41における移行先分散型台帳のトランザクション登録の状況を監視する。
 また、台帳更新監視部15は、受け取った移行先データ登録要求509bが示す情報を元に他のデータ移行装置1のデータ送信部133に接続し、当該データ送信部133が送信する移行元トランザクションに対応するトランザクションIDと、当該トランザクションを移行先分散型台帳に登録した際に新たに設定されるトランザクションIDとの対応を示す情報を当該他のデータ移行装置1のデータ送信部133から受信し始める。
(ステップS204:移行データ作成処理)
 データ作成部132は、登録要求受付部131が受信した移行先データ登録要求509bと、トランザクション関係データ記録部122が記録しているトランザクション関係データと、補足データ記録部142が記録している補足データ503とを利用して移行データ510を作成し、作成した移行データ510をデータ送信部133に適宜送信する。
 以下、データ移行装置1がトランザクション関係データとしてトランザクション関係グラフ504を採用する場合における、移行データ510の作成と送信について説明する。
 図22及び図23は、データ作成部132が、移行データ510を作成する処理と、作成した移行データ510をデータ送信部133に送信する処理との一例を示すフローチャートである。これらの図を参照してデータ作成部132の処理を説明する。なお、1つのフローチャートが図22及び図23に分割されている。
(ステップS221)
 データ作成部132は、移行元分散型台帳に関するトランザクション関係グラフ504の「頂点集合」が含む要素に対応する頂点データ505の内、データ移行装置1が登録することができ、かつ、データ登録条件が設定されていない頂点データ505を取得し、取得した頂点データ505をリストに登録する。データ作成部132は、移行元分散型台帳に対応するトランザクション関係グラフ504を、移行先データ登録要求509bの「取得対象台帳ID」を利用してトランザクション関係データ記録部122から取得する。
 データ作成部132は、具体例として、データ移行装置1がある頂点データ505を登録することができるか否かを、当該ある頂点データ505に対応する選別済みトランザクションデータ502の「実行者情報」がデータ移行装置1の保有者と一致しているか否かに基づいて判定する。ここで、データ作成部132は、「実行者情報」と保有者とが一致している場合に頂点データ505を登録することができるものとみなす。他の判定手法として、選別済みトランザクションデータ502の「実行者情報」とデータ移行装置1の保有者との対応関係を補足データ503として設定しておくことにより、データ作成部132は、「実行者情報」と保有者とが一致しない場合であっても、データ移行装置1が頂点データ505を登録することができると判定してもよい。また、データ移行装置1は、トランザクションごとに登録することができる保有者であってデータ移行装置1の保有者を補足データ503として設定してもよい。
 データ登録条件が設定されていない頂点データ505は、トランザクション関係グラフ504の「頂点集合」が含む頂点に対応する頂点データ505の内、「辺集合」が含む辺に対応する辺データ506の「入力側頂点ID」として設定されていない頂点データ505である。
(ステップS222)
 データ作成部132は、他のデータ移行装置1によって移行先分散型台帳に登録されたトランザクションに対応する頂点データ505を取得する。データ作成部132は、他装置登録情報を利用して当該頂点データ505を取得してもよい。
 具体例として、データ作成部132は、台帳更新監視部15に問合わせることにより、台帳更新監視部15に前回問合せたときから台帳更新監視部15に今回問合せるまでの間に移行先分散型台帳に登録されたトランザクションがあるか否かを確認する。当該トランザクションがある場合、データ作成部132は当該トランザクションに対応する頂点データ505を台帳更新監視部15に返却してもらう。当該トランザクションがない場合、データ作成部132は、トランザクションの登録があるまで待機してもよく、トランザクションを取得できなかったものとみなしてそのまま処理を続行してもよい。そのまま処理を続行する場合において、データ作成部132は、ステップS223からステップS225の処理をスキップし、ステップS226の処理を実行する。
(ステップS223)
 データ作成部132は、ステップS222の処理において取得した各頂点データ505の「頂点ID」を「出力側頂点ID」として持つ辺データ506を抽出する。
(ステップS224)
 データ作成部132は、抽出した各辺データ506の「入力側頂点ID」に対応する頂点データ505を候補リストに登録する。データ作成部132は、ある頂点データ505が既に候補リストに登録されている場合、当該ある頂点データ505を重複して候補リストに登録しない。候補リストは、候補リストが含む要素に対する処理の時点において、データ登録条件の少なくとも一部が満たされている頂点データ505のリストである。ある頂点データ505のデータ登録条件は、当該ある頂点データ505の「頂点ID」を「入力側頂点ID」として持つ辺データ506が、本ステップの処理を実行するまでに、イテレーションにおけるステップS223及びステップS228の処理によって、全て抽出されていることである。
(ステップS225)
 データ作成部132は、候補リストが含む各頂点データ505について、データ作成部132が本フローチャートに示す処理を開始して以降本ステップの処理を実行するまでに抽出した各辺データ506によって、データ登録条件が満たされたか否かを確認し、データ登録条件が満たされた頂点データ505をリストに登録する。
(ステップS226)
 データ作成部132は、リスト内の各頂点データ505を参照し、移行ルールに基づいて頂点データ505を抽出し、抽出した頂点データ505を用いて移行データ510を作成する。移行ルールは、実施の形態1に係る移行ルールと同様である。移行データ510の作成方法は実施の形態1に係る移行データ510の作成方法と同様である。
 なお、リストが空である場合、データ作成部132は、ステップS226からステップS230までの処理をスキップし、ステップS231の処理をする。
(ステップS227)
 データ作成部132は、作成した移行データ510をデータ送信部133へ送信する。
(ステップS228)
 データ作成部132は、リスト内の各頂点データ505の「頂点ID」を「出力側頂点ID」として持つ辺データ506を抽出する。本ステップの処理は、ステップS223の処理と同様である。
(ステップS229)
 データ作成部132は、抽出した各辺データ506の「入力側頂点ID」に対応する頂点データ505を候補リストに登録する。本ステップの処理は、ステップS224の処理と同様である。
(ステップS230)
 データ作成部132は、候補リストが含む各頂点データ505について、データ作成部132が本フローチャートの処理を開始して以降本ステップの処理を実行するまでに抽出した各辺データ506によってデータ登録条件が満たされたか否かを確認し、登録条件が満たされた頂点データ505を次期リストに登録する。次期リストは実施の形態1に係る次期リストと同様である。
(ステップS231)
 データ作成部132は、リストと次期リストとが空であるか否かを確認する。
 リストと次期リストとが空である場合、データ作成部132はステップS233に進む。それ以外の場合、データ作成部132はステップS232に進む。
(ステップS232)
 データ作成部132は、移行データ510に含めた頂点データ505をリストから削除し、次期リストが含む頂点データ505をリストに追加し、次期リストを空にする。その後、データ作成部132はステップS226に進む。
(ステップS233)
 データ作成部132は、登録すべきトランザクションが残っているか否かを確認する。登録すべきトランザクションとは、データ移行装置1が登録することができるトランザクション全てである。登録することができるトランザクションはステップS221において説明した通りである。
 登録すべきトランザクションが残っている場合、データ作成部132はステップS222の処理を実施し、他のデータ移行装置1によって、データ登録条件が満たされたトランザクションがないか確認する。それ以外の場合、データ作成部132はステップS234に進む。
(ステップS234)
 データ作成部132は、データ送信部133に送信完了通知を送信し、本フローチャートの処理を終了する。
(ステップS205:データ送信処理)
 データ送信部133は、データ作成部132から受信した移行データ510に基づき、移行先ノード41にデータを送信する。また、データ送信部133は、移行先ノード41にデータを登録した結果を他のデータ移行装置1の台帳更新監視部15に送信する。
 図24は、データ送信部133が移行先ノード41と他のデータ移行装置1の台帳更新監視部15とにデータを送信する動作の一例を示すフローチャートである。本図を参照してデータ送信部133の動作を説明する。本例において、移行データ510の「順序データ」として数値が設定されているものとし、データ送信部133は値が小さい「順序データ」を有する移行データ510から順に処理するものとする。
(ステップS241)
 データ送信部133は、データ作成部132から受信したデータをリストに追加する。本ステップの処理はステップS161の処理と同様である。
(ステップS242)
 データ送信部133は、リストからデータを取得する。本ステップの処理はステップS162の処理と同様である。
(ステップS243)
 データ送信部133は、取得したデータが送信完了通知であるか否かを確認する。
 取得したデータが送信完了通知である場合、データ送信部133は本フローチャートの処理を終了する。それ以外の場合、即ち取得したデータが移行データ510である場合、データ送信部133はステップS244に進む。
(ステップS244)
 データ送信部133は、取得した移行データ510の「頂点データリスト」が含む要素に対応する頂点データ505の内、移行先分散型台帳にまだ登録されていないデータに対応する頂点データ505に対応する移行先ノード41に対して移行データ510を送信する。
 データ送信部133は、具体例として、ある頂点データ505に対応するデータが移行先分散型台帳に登録されているか否かを、台帳更新監視部15を利用することにより調査することができる。具体的には、データ送信部133は、取得した移行データ510の「頂点データリスト」が含む要素に対応する頂点データ505の「トランザクションID」が、台帳更新監視部15が管理するトランザクション登録の状況を示す情報に登録済みトランザクションとして登録されているか否か確認することにより、当該頂点データ505が移行先分散型台帳に登録されているデータに対応する頂点データ505であるか否かを判断することができる。他の調査方法として、データ送信部133が、移行先ノード41に対して、当該頂点データ505に対応するトランザクションを実行することができるか否かを問い合わせる方法が挙げられる。具体例として、データ移行対象である台帳のスマートコントラクトが、内容が同じであるデータを二重に登録しようとしているか否かを判定し、二重に登録しようとしている場合にトランザクションを棄却するようなロジックである場合を考える。この場合において、まず、データ送信部133は移行先ノード41に対して当該頂点データ505に対応するデータを送信する。次に、移行先ノード41は当該頂点データ505に対応するデータを登録することができるか否かをスマートコントラクトによって判定する。次に、データ送信部133は、当該頂点データ505に対応するデータを登録することができる場合に、当該頂点データ505に対応するデータが移行先分散型台帳に登録されていないと判断する。また、この場合において、データ送信部133は、移行先ノード41に問い合わせる方法ではなく、移行先ノード41にデータを登録する方法を採用してもよい。データ送信部133がデータを登録する方法を採用する場合において、データ送信部133は、無事に当該頂点データ505に対応するデータを移行先ノード41に登録することができれば当該データは移行先分散型台帳にまだ登録されていないと判断することができ、当該データを移行先ノード41に登録することができなければ当該データは既に移行先分散型台帳に登録されていたと判断することができる。
 データ送信部133がデータを移行先ノード41に送信する処理の具体例を説明する。まず、データ送信部133は、移行データ510の「台帳名」と、「接続先ノード」と、「接続先ノード資格情報」との少なくともいずれか等を利用して移行先ノード41に接続する。次に、データ送信部133は、「頂点データリスト」が含む各要素に対応する頂点データ505に対応する選別済みトランザクションデータ502と補足データ503との少なくともいずれかを参照する。次に、データ送信部133は、参照したデータに応じて、移行先ノード41にトランザクションを送信してもよく、移行先ノード41の機能を呼び出してもよい。これにより、移行先分散型台帳へのデータ送信は完了する。
(ステップS245)
 データ送信部133は、リストが空であるか否かを確認する。
 リストが空である場合、データ送信部133はステップS241に進む。それ以外の場合、データ送信部133はステップS242に進む。
 ここまでの動作の説明において、データ移行対象は移行元台帳ネットワーク3の移行対象である台帳が含む全てのトランザクションとしている。しかしながら、データ移行対象は移行元台帳ネットワーク3の移行対象である台帳に含まれる一部のトランザクションであってもよい。このときのデータ移行装置1の処理は実施の形態1と同様であるため、当該処理の説明を省略する。
***実施の形態2の効果の説明***
 以上のように、本実施の形態によれば、データ移行装置1は台帳更新監視部15を備え、さらに複数のデータ移行装置1が連携して動作する。そのため、本実施の形態に係るデータ移行装置1は、実施の形態1の特徴を有しつつ、移行元台帳ネットワーク3に含まれる移行対象のトランザクションの取得権限が設定されている場合、又は、移行先台帳ネットワーク4に対するトランザクションの登録権限が設定されている場合等においても、データを移行することができる。
 実施の形態3.
 以下、主に前述した実施の形態と異なる点について、図面を参照しながら説明する。
***構成の説明***
 本実施の形態に係るデータ移行装置1は、前述の実施の形態によって作成した移行先分散型台帳が移行元分散型台帳と同様であるか否かを確認する機能を有する。なお、本機能は他のいずれの実施の形態と組み合わせてもよいが、説明の便宜上、実施の形態1に本機能を追加した具体例を説明する。本実施の形態に係る処理は、移行元分散型台帳が記録している電子データの少なくとも一部を移行先分散型台帳に移行した後において実施することができる。
 図25は、本実施の形態に係るデータ移行システム90の構成例を示している。本実施の形態と実施の形態1との主な差分は、データ移行装置1がデータ検証部16を備える点と、管理装置2がデータ検証要求部23を備える点とである。
 データ取得部112は、データ検証要求511に基づいて、移行先移行データの各要素に対応するデータである移行先データを含む移行先取得データを、移行先分散型台帳から取得する。データ検証要求511は、移行元分散型台帳と移行先分散型台帳との同一性を検証する要求である。移行先移行データは移行データ510と同様である。移行先取得データは取得データと同様である。移行先データは作成要素に対応するデータと同様である。移行先移行データは、移行データ510の少なくとも一部に対応するデータである。
 データ選別部113は、移行先取得データから移行先データを選別して抽出する。
 トランザクション関係データ作成部121は、移行先データのいずれに対応する補足データ503もない場合に、必要に応じて、移行先データを用いて移行先トランザクション関係データを作成してもよい。また、トランザクション関係データ作成部121は、移行先データの少なくともいずれかそれぞれに対応する補足データ503がある場合に、必要に応じて、移行先データと、移行先データの少なくともいずれかそれぞれに対応する補足データ503とを用いて移行先トランザクション関係データを作成してもよい。移行先トランザクション関係データは、トランザクション関係データの少なくとも一部である比較用関係データと対応する。比較用関係データは、これまでに移行先分散型台帳に移行した電子データに対応する。移行すべき電子データを全て移行先分散型台帳に移行した場合において、比較用関係データはトランザクション関係データである。
 データ検証部16は、移行元分散型台帳と移行先分散型台帳との間の差異の有無を検証する。具体例として、データ検証部16は、管理装置2からデータ検証要求511を受信し、当該データ検証部16を備えるデータ移行装置1が移行対象とした移行元分散型台帳と移行先分散型台帳との比較を、移行元分散型台帳と移行先分散型台帳とのそれぞれのトランザクション関係データと補足データ503とを利用して実施する。データ検証部16は、台帳のトランザクション関係データと補足データ503として、それぞれ、移行順序作成部12と補足データ管理部14とが管理しているデータを利用する。データ検証部16は、移行順序作成部12と補足データ管理部14とのいずれかに必要なデータがない場合、データ抽出部11に取得要求を適宜送信し、必要なデータを台帳から取得するよう要求する。データ検証部16は、比較用関係データと移行先トランザクション関係データとを比較することにより、移行元分散型台帳と移行先分散型台帳との同一性を検証する。
 データ検証要求部23は、データ移行装置1に対して、データ検証要求511を送信する。
 図26は、本実施の形態に係るデータ移行システム90が備える各装置のソフトウェア構成例を示している。本実施の形態と実施の形態1との主な差分は、データ移行装置1がデータ検証部16を備える点と、管理装置2がデータ検証要求部23を備える点とである。
 データ検証部16は、検証要求受付部161と、検証データ取得要求部162と、検証部163とを備える。
 検証要求受付部161は、データ検証要求部23からデータ検証要求511を受け付ける。
 検証データ取得要求部162は、検証要求受付部161からデータ検証要求511を受け取り、受け取ったデータ検証要求511の内容を確認する。検証データ取得要求部162は、比較対象である台帳のトランザクション関係データと関連する補足データ503との少なくともいずれかが作成されていない場合に、取得要求受付部111に要求して当該台帳を保有するノードからデータを取得し、取得したデータを用いてトランザクション関係データと関連する補足データ503との少なくともいずれかを作成する。
 検証部163は、データ検証要求511が示す比較対象である各台帳を、各台帳のトランザクション関係データと関連する補足データ503を利用してデータ検証要求511が示す比較方法に従って比較することにより、各台帳が一致しているか否かを検証する。
***動作の説明***
 図27は、本実施の形態に係るデータ移行システム90の動作の一例を示すフローチャートである。本図を参照してデータ移行システム90の動作を説明する。
(ステップS301:検証要求送信処理)
 データ検証要求部23は、データ移行装置1にデータ検証要求511を送信する。
 図28は、データ検証要求511の具体例を示している。データ検証要求511は、「比較方法」と、「データ対応関係」と、比較対象である各台帳の情報を示す「比較対象台帳情報」とを含む。また、各「比較対象台帳情報」は、「比較対象台帳ID」と、「比較対象台帳名」と、「接続ノード」と、「接続ノード資格情報」とを含む。「比較対象台帳ID」は、「移行元台帳ID」と「移行先台帳ID」との総称である。「比較対象台帳名」は、「移行元台帳名」と「移行先台帳名」との総称である。「接続ノード」は、「移行元接続ノード」と「移行先接続ノード」との総称である。「接続ノード資格情報」は、「移行元接続ノード資格情報」と「移行先接続ノード資格情報」との総称である。
 「比較方法」は、比較対象である台帳を比較する方法を定めるルールを示す情報である。ルールの一例として、トランザクション関係データを比較することが挙げられる。本例は、比較対象である台帳それぞれから抽出されたトランザクションデータと、トランザクションデータ間の関連性を表すトランザクション関係データとが、それぞれ論理的に同じ内容である場合に、比較対象である台帳が一致しているとみなすルールである。
 「データ対応関係」は、ある項目の値が比較対象である台帳間で異なる場合において、当該ある項目の値が表現している内容が一致しているケースを具体的にまとめたものである。具体例として、データ登録の実行者を移行先分散型台帳において変更する場合がある。この場合において、データ登録の実行者の値を利用すると「比較方法」によっては移行元分散型台帳の内容と移行先分散型台帳の内容とは一致しないと判定される。しかしながら、「データ対応関係」においてこれら実行者が対応していることを記述しておくことにより、データ検証部16は、これら実行者が一致しているとみなすことができ、故に比較対象である台帳間で内容が一致しているとみなすことができる。「データ対応関係」の具体例として、台帳1のユーザAと台帳2のユーザBとが同じユーザであることを示す情報等のユーザを表す情報、又は、実行順序を示す情報等が挙げられる。トランザクションIDも移行元分散型台帳と移行先分散型台帳との間で典型的には値が異なる情報である。トランザクションIDに関しては、データ移行時にデータ送信部133又は台帳更新監視部15等がデータ移行の前後におけるトランザクションIDの対応関係を保持してもよく、データ検証部16は保持されているトランザクションIDの対応関係を利用してもよい。
 「台帳ID」は、比較対象である台帳それぞれを一意に表す識別子である。
 「比較対象台帳名」は、比較対象である台帳に設定された名前である。
 「接続ノード」は、台帳からデータを取得する際に接続するノードの所在を表す情報であり、「接続移行元ノード」等と同様である。
 「接続ノード資格情報」は、「接続ノード」へ接続する際に認証が必要である場合に利用される情報であり、「接続移行元ノード資格情報」等と同様である。
 なお、「比較対象台帳情報」の内、「比較対象台帳名」と、「接続ノード」と、「接続ノード資格情報」とについては、これらに対応する「比較対象台帳ID」が示す台帳を表すトランザクション関係データがトランザクション関係データ記録部122に保存されている場合、なくてもよい。
(ステップS302:検証要求受信処理)
 検証要求受付部161は、管理装置2からデータ検証要求511を受信し、受信したデータ検証要求511を検証データ取得要求部162に送る。
(ステップS303:検証要求確認処理)
 検証データ取得要求部162は、検証要求受付部161からデータ検証要求511を受け取り、受け取ったデータ検証要求511の内容を確認する。
 検証データ取得要求部162は、具体例として、データ検証要求511の各「比較対象台帳ID」を抽出し、抽出した各「比較対象台帳ID」が示す台帳を表すトランザクション関係データがトランザクション関係データ記録部122に保存されているか否かを確認する。検証データ取得要求部162は、具体例として、データ移行装置1がトランザクション関係データとしてトランザクション関係グラフ504を利用している場合において、「比較対象台帳ID」と値が同じである「取得対象台帳ID」を持つトランザクション関係グラフ504が保存されているか否かを確認する。当該トランザクション関係グラフ504が全て保存されている場合、検証データ取得要求部162は検証部163にデータ検証要求511を送る。トランザクション関係データが保存されていない比較対象台帳に関しては、データ抽出部11と移行順序作成部12とが、当該比較対象台帳に対応するトランザクション関係データを作成する。具体例として、まず、検証データ取得要求部162は、データ検証要求511が含むデータであって、取得したい比較対象台帳である当該比較対象台帳に対応する「比較対象台帳ID」と「比較対象台帳名」と「接続ノード」と「接続ノード資格情報」とのそれぞれを示すデータを用いて移行元データ取得要求501を作成する。次に、検証データ取得要求部162は、作成した移行元データ取得要求501を取得要求受付部111に送信することにより、データ抽出部11と移行順序作成部12とに取得したい比較対象台帳に対応するトランザクション関係データを作成させる。作成させたトランザクション関係データは移行先トランザクション関係データである。次に、検証データ取得要求部162は、データ検証要求511が含む「比較対象台帳情報」に対応するトランザクション関係データが作成されたことを確認し、検証部163にデータ検証要求511を送る。
(ステップS304:検証処理)
 検証部163は、検証データ取得要求部162からデータ検証要求511を受け取り、比較対象である台帳を検証し始める。
 具体例として、まず、検証部163は、データ検証要求511の「比較方法」を確認することにより、どのようなルールによって比較対象である台帳を比較するか確認する。次に、検証部163は、「比較方法」に従って、各比較対象である台帳に対応するトランザクション関係データと関連する補足データ503とを比較する。
 図29は、データ移行装置1がトランザクション関係データとしてトランザクション関係グラフ504を利用し、かつ、検証方法がトランザクション関係グラフ504の一致である場合における、検証部163が移行元分散型台帳と移行先分散型台帳とを比較する処理の一例を示すフローチャートである。本図を参照して検証部163の動作を説明する。
(ステップS321)
 検証部163は、移行元分散型台帳と移行先分散型台帳とのそれぞれのトランザクション関係グラフ504が有する「頂点集合」が含む要素に対応する頂点データ505の対応関係を整理する。
 図30は、ステップS321の詳細な処理の一例を示すフローチャートである。本図を参照して、ステップS321の詳細な処理を説明する。
(ステップS341)
 検証部163は、移行元分散型台帳におけるトランザクションIDと、移行先分散型台帳におけるトランザクションIDとの対応関係を示すトランザクションID対応表を作成する。
 具体例として、実施の形態2の構成においては、台帳更新監視部15が、移行元トランザクションのトランザクションIDと、当該移行元トランザクションを移行先に登録した際に新たに設定されたトランザクションIDとの対応を示す情報を保管している。そのため、検証部163は、台帳更新監視部15が保管している情報を利用することによりトランザクションID対応表を作成してもよい。また、実施の形態1の構成においては、データ送信部133が、移行先分散型台帳に登録した移行先トランザクションのトランザクションIDを取得し、取得したトランザクションIDと移行元トランザクションのトランザクションIDとを対応付けた情報を保管してもよい。このとき、検証部163は、データ送信部133が保管している情報を利用することによりトランザクションID対応表を作成してもよい。
(ステップS342)
 検証部163は、移行元分散型台帳に対応するトランザクション関係グラフ504の「頂点集合」が含む要素に対応する頂点データ505をリストに登録する。
(ステップS343)
 検証部163は、リストから1件の頂点データ505を取得し、取得した頂点データ505をリストから削除する。
(ステップS344)
 検証部163は、トランザクションID対応表を参照し、取得した頂点データ505の「トランザクションID」に対応する移行先分散型台帳のトランザクションIDを取得する。
(ステップS345)
 検証部163は、取得した頂点データ505の「トランザクションID」に対応する選別済みトランザクションデータ502と、当該選別済みトランザクションデータ502に関連する補足データ503と、取得した移行先分散型台帳におけるトランザクションIDに対応する選別済みトランザクションデータ502と、当該選別済みトランザクションデータ502に関連する補足データ503とを、データ検証要求511の「比較方法」と「データ対応関係」とに従って比較する。
(ステップS346)
 検証部163は、ステップS345における比較の結果、移行元トランザクションの内容と、移行元トランザクションに対応する移行先トランザクションの内容とが一致したか否かを確認する。
 両者の内容が一致した場合、検証部163はステップS348に進む。それ以外の場合、検証部163はステップS347に進む。
(ステップS347)
 検証部163は、比較対象である台帳の間において頂点に対応関係が成立していないことを確認したものとして、本フローチャートの処理を終了する。
(ステップS348)
 検証部163は、リストが空であるか否かを確認する。
 リストが空である場合、検証部163はステップS349に進む。それ以外の場合、検証部163はステップS343に戻る。
(ステップS349)
 検証部163は、比較対象である台帳の間において頂点に対応関係が成立していることを確認したものとして、本フローチャートの処理を終了する。
(ステップS322)
 検証部163は、ステップS321の処理の結果を受け、移行元分散型台帳と移行先分散型台帳との間で頂点に対応関係が成立しているか否かを確認する。
 頂点に対応関係が成立している場合、検証部163はステップS324に進む。それ以外の場合、検証部163はステップS323に進む。
(ステップS323)
 検証部163は、移行元分散型台帳と移行先分散型台帳とのそれぞれに対応するトランザクション関係グラフ504が一致していないことを通知し、本フローチャートの処理を終了する。
(ステップS324)
 検証部163は、頂点データ505の対応関係に基づいて、移行元分散型台帳と移行先分散型台帳とのそれぞれのトランザクション関係グラフ504が含む「辺集合」の要素に対応する辺データ506の対応関係を整理する。
 具体例として、移行元分散型台帳に対応するトランザクション関係グラフ504がG((v1(1234),v2(2345)),(e1(v1,v2)))であり、移行先分散型台帳に対応するトランザクション関係グラフ504がG((v9(9876),v8(8765)),(e9(v9,v8)))であり、トランザクションID対応表が((1234->9876),(2345->8765))であるものとする。ここで、v1(1234)は、「トランザクションID」が1234であり、「頂点ID」がv1である頂点データ505を示す。e1(v1,v2)は、「辺ID」がe1であり、「出力側頂点ID」がv1であり、「入力側頂点ID」がv2である辺データ506を示す。G(V,E)は、頂点集合Vと辺集合Eとから構成されるトランザクション関係グラフ504を示す。(1234->9876)は、移行元分散型台帳におけるトランザクションIDが1234であるトランザクションと、移行先分散型台帳におけるトランザクションIDが9876であるトランザクションとが対応していることを示す。このとき、トランザクションID対応表より、頂点データ505に関しては、v1及びv9と、v2及びv8とのそれぞれに対応関係が成立していることが分かる。よって、e9(v9,v8)はトランザクションの対応関係を考慮するとe9(v1,v2)と読み替えることができ、このことから、e1(v1,v2)とe9(v9,v8)とは対応関係が成立している辺ということが分かる。このように、検証部163は、移行元分散型台帳と移行先分散型台帳とのそれぞれに対応するトランザクション関係グラフ504の「辺集合」の全ての要素それぞれに対応する辺データ506に対して、対応関係が成立しているか否かを整理する。
(ステップS325)
 検証部163は、全ての辺データ506について、移行元分散型台帳と移行先分散型台帳との間において対応関係が成立しているか否かを確認する。
 全ての辺データ506について対応関係が成立している場合、検証部163はステップS326に進む。それ以外の場合、検証部163はステップS323に進む。
(ステップS326)
 検証部163は、移行元分散型台帳と移行先分散型台帳との間においてトランザクション関係グラフ504が一致していることを通知し、本フローチャートの処理を終了する。
***実施の形態3の効果の説明***
 以上のように、本実施の形態によれば、データ移行装置1がデータ検証部16を備えることにより、前述の実施の形態が有する特徴を残しつつ、移行先分散型台帳における移行したデータが移行元分散型台帳における元のデータと一致しているか否かを検証することができる。
 実施の形態4.
 以下、主に前述した実施の形態と異なる点について、図面を参照しながら説明する。
***構成の説明***
 データ抽出部11とデータ登録部13とは、分散型台帳以外にも、データストアからデータを抽出し及び移行してもよい。データストアは、分散型台帳のトランザクションデータの形式を登録することと参照することとの少なくとも一方が可能であるものとする。データストアは、移行元データストア5と移行先データストア6との総称でもある。
 いずれの他の実施の形態の構成にデータストアを追加しても構わないが、説明の便宜上、以下では実施の形態1にデータストアを追加した場合における具体例を説明する。
 図31は、本実施の形態に係るデータ移行システム90の構成例を示している。本実施の形態と実施の形態1との主な差分は、データ抽出部11が、移行元台帳ネットワーク3だけでなく、移行元データストア5と接続している点と、データ登録部13が、移行先台帳ネットワーク4だけでなく、移行先データストア6と接続している点とである。移行元データストア5は移行元トランザクション形式データストアとも呼ばれる。移行先データストア6は移行先トランザクション形式データストアとも呼ばれる。
 図32は、本実施の形態に係るデータ移行システム90が備える各装置のハードウェア構成例を示している。本実施の形態と実施の形態1との主な差分は、データ移行システム90が移行元データストア5と移行先データストア6とを備える点である。
 図33は、データ移行システム90が備える各装置のソフトウェア構成例を示している。本実施の形態と実施の形態1との主な差分は、データ移行システム90が移行元データストア5と移行先データストア6とを備える点である。
 データ取得部112は、移行元データ取得要求501の「取得対象台帳ID」と「取得対象台帳名」と「接続移行元ノード」と「接続移行元ノード資格情報」との少なくともいずれか等を利用して移行元データストア5に接続することができるものとする。データ取得部112は、移行要求に基づいて、移行元分散型台帳の代わりに移行元分散型台帳が記録しているデータと同じデータを記録しているデータストアから取得データを含むデータを取得してもよい。
 移行元データストア5は、トランザクション形式参照部51と、移行元データ保存部52とを備える。
 トランザクション形式参照部51は、データ取得部112が送信した移行元データ取得要求501に基づくデータ取得要求を受信し、移行元データ保存部52が保存しているデータを適宜参照し、また、適宜変換し、データ取得部112に適宜参照し、また、適宜変換したデータを送信する。
 移行元データ保存部52は、これまでのアプリケーションからのデータ処理リクエストに従ってデータを登録し、更新し、また、参照した記録を保持しているデータストアであり、最新のデータに加えてデータ処理リクエストに対応する実行履歴データも保持しているデータストアである。また、他にも、移行元データ保存部52は、データを登録していたアプリケーションと同等の機能を持つスマートコントラクト本体と、アプリケーションを構築しアプリケーションを移行元データ保存部52と連携した際のイベントデータと、アプリケーションのロジックを修正したイベントデータとを保存しており、トランザクション形式参照部51からの参照要求に応じて適宜呼び出されるものとする。
 移行元データストア5は、中央集権的な台帳システムを採用してもよい。このとき、具体例として、トランザクション形式参照部51において移行元分散型台帳と同じスマートコントラクトが動作しており、移行元データ保存部52は動作しているスマートコントラクトに対応するトランザクションと補足データ503とを記録する。
 データ送信部133は、移行データ510の「台帳名」と「接続移行先ノード」と「接続移行先ノード資格情報」との少なくともいずれか等を利用して移行先データストア6に接続することができるものとする。データ送信部133は、移行先分散型台帳の代わりにそれぞれの作成要素に対応するデータを処理することができるデータストアにそれぞれの作成要素に対応するデータを送信してもよい。
 移行先データストア6は、トランザクション形式登録部61と、移行先データ保存部62とを備える。
 トランザクション形式登録部61は、データ送信部133が送信した移行データ510をベースとしたデータを受信し、受信したデータを解釈し、移行先データ保存部62に登録するデータを適宜送信する。
 トランザクション形式登録部61は、指定されたスマートコントラクトと同等の処理を実施することができるアプリケーションを備えているものとする。
 移行先データ保存部62は、トランザクション形式登録部61からデータ登録又はデータ参照要求があったときに、データを適宜登録し、また、データを適宜参照する。
 移行先データストア6は、中央集権的な台帳システムを採用してもよい。このとき、具体例として、トランザクション形式登録部61において移行先分散型台帳と同じスマートコントラクトが動作しており、移行先データ保存部62は動作しているスマートコントラクトに対応するトランザクションと補足データ503とを記録する。
***動作の説明***
 以下、データ取得部112の動作と、データ送信部133の動作とについての実施の形態1との差分を主に説明する。
 図34は、本実施の形態に係るデータ取得部112の動作の一例を示すフローチャートである。本図を参照してデータ取得部112の動作を説明する。
(ステップS401:データ取得要求送信処理)
 データ取得部112は、移行元データ取得要求501の「接続移行元ノード」と「接続移行元ノード資格情報」とを利用し、移行元ノード31又は移行元データストア5に接続する。データ取得部112が移行元ノード31に接続する場合の処理については、実施の形態1における処理と同様であるため説明を省略する。データ取得部112が移行元データストア5に接続した場合、データ取得部112は、移行元データストア5に対して、移行元データ取得要求501の「取得対象台帳ID」と「取得対象台帳名」とを含むデータ取得要求を送信する。
(ステップS402:データ送信処理)
 トランザクション形式参照部51は、データ取得部112が送信したデータ取得要求を受信し、受信したデータ取得要求が含む「取得対象台帳ID」と「取得対象台帳名」とを利用し、データ取得要求に対応する台帳に関連するトランザクション相当データと補足データ503とを移行元データ保存部52から取得する。トランザクション相当データはトランザクションに相当するデータである。トランザクション形式参照部51は、取得したデータを移行元ノード31がデータ取得部112に送信するデータ形式と同様のデータ形式に変換し、変換したデータをデータ取得部112に送信する。当該同様のデータ形式は、具体的には、データ選別部113が選別済みトランザクションデータ502と補足データ503とを作成することができる内容を示すデータである。
 具体例として、移行元データ保存部52にデータを登録していたアプリケーションをスマートコントラクトとみなし、かつ、アプリケーションから移行元データ保存部52へのデータ処理リクエストを1つのトランザクションとしてみなすことにより、移行元データストア5の処理を分散型台帳の動作とほぼ同等の処理とみなすことができる。このとき、アプリケーションから移行元データ保存部52へのデータ処理リクエストに対する処理は、移行元データストア5のトランザクション機能等を利用することにより、ある1まとまりのデータ参照処理、データ登録処理、又はデータ更新処理が一貫して実行されるものであるものとする。また、分散型台帳におけるスマートコントラクトのデプロイのためのトランザクションは、アプリケーションを構築し、アプリケーションが移行元データ保存部52と連携した際のイベントデータである。分散型台帳におけるスマートコントラクトを更新するためのトランザクションは、アプリケーションのロジックを修正した際のイベントデータに相当する。
 トランザクション形式参照部51がデータ取得部112に送信するデータと、選別済みトランザクションデータ502との具体的な対応関係の具体例を示す。
 まず、トランザクション形式参照部51がデータ取得部112に送信するデータの内、アプリケーションの実行に関するデータと選別済みトランザクションデータ502との対応関係の例を説明する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「取得対象台帳ID」としてアプリケーションごとに割り振られた固有の値を利用し、選別済みトランザクションデータ502の「トランザクションID」としてアプリケーションから移行元データ保存部52に対するデータ処理リクエストのIDを利用する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行順序情報」として、アプリケーションから移行元データ保存部52へのデータ処理リクエストが示す実行順序情報を利用する。アプリケーションから移行元データ保存部52へのデータ処理リクエストの実行順序情報には、事前に、アプリケーションから移行元データ保存部52へのデータ処理リクエストのログと、アプリケーションの構築及び連携イベントと、アプリケーションの更新イベントとを確認することにより、適用順序が古いデータ処理リクエスト及びイベントから順番に番号が割り振られているものとする。トランザクション形式参照部51は、選別済みトランザクションデータ502の「種別」を「スマートコントラクト実行」と設定し、選別済みトランザクションデータ502の「実行対象」としてアプリケーションの名前を利用する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行処理」として、アプリケーションから移行元データ保存部52へのデータ処理リクエストを行った際のアプリケーションの内の処理名を利用する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「処理引数リスト」としてアプリケーションから移行元データ保存部52へのデータ処理リクエストを行った際に移行元データ保存部52に渡された引数データを利用する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行者情報」としてアプリケーションの保有者又は実行者情報を利用し、選別済みトランザクションデータ502の「実行結果」としてデータ処理リクエスト中に行ったデータストアへの参照および書込の情報を設定する。
 次に、トランザクション形式参照部51がデータ取得部112に送信するデータの内、アプリケーションの構築に関するデータと、選別済みトランザクションデータ502及び補足データ503との対応関係の具体例を説明する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「取得対象台帳ID」としてアプリケーションごとに割り振られた固有の値を利用し、選別済みトランザクションデータ502の「トランザクションID」として、他のトランザクションIDと重複しないIDであって、アプリケーションを構築し移行元データ保存部52と連携した際のイベントデータのIDを設定する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行順序情報」としてアプリケーションを構築し移行元データ保存部52と連携した際のイベントデータの実行順序情報を利用し、選別済みトランザクションデータ502の「種別」に「スマートコントラクトデプロイ」を設定する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行対象」と「実行処理」と「処理引数リスト」とを、アプリケーションが利用する初期データを移行元データ保存部52に登録した際等に、アプリケーションの実行に関するデータと選別済みトランザクションデータ502との対応関係において説明した処理と同様に適宜設定する。具体的には、トランザクション形式参照部51は、「実行対象」としてアプリケーションの名前を利用し、「実行処理」としてアプリケーションを構築して移行元データ保存部52と連携した際のイベントデータ又はアプリケーションのロジックを修正したイベントデータのイベント名等を利用し、「処理引数リスト」としてアプリケーションを構築して移行元データ保存部52と連携した際のイベントデータ又はアプリケーションのロジックを修正したイベントデータの本体等を利用する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行者情報」としてアプリケーションの保有者又はアプリケーション構築の実行者を示す情報を利用し、選別済みトランザクションデータ502の「実行結果」として、初期データ登録等を行った際の移行元データストア5への参照及び書込の情報を適宜設定する。トランザクション形式参照部51は、選別済みトランザクションデータ502に関連する補足データ503について、「補足データID」に他の補足データIDと重複しないような値を設定し、「取得対象台帳ID」と「トランザクションID」とに関連する選別済みトランザクションデータ502に設定した取得対象台帳IDとトランザクションIDとそれぞれ同じ値を設定し、「データ種別」に「スマートコントラクト」と設定し、「データ」に移行元データ保存部52が保存している、データを登録していたアプリケーションと同等の機能を持つスマートコントラクトの本体を設定する。
 次に、トランザクション形式参照部51がデータ取得部112に送信するデータの内、アプリケーションの更新に関するデータと、選別済みトランザクションデータ502及び補足データ503との対応関係の具体例を説明する。この対応関係は、アプリケーションの構築に関するデータと選別済みトランザクションデータ502及び補足データ503の対応関係と類似しているため、当該対応関係と異なる点についてのみ説明する。
 トランザクション形式参照部51は、選別済みトランザクションデータ502の「種別」を「スマートコントラクト更新」と設定し、選別済みトランザクションデータ502の「実行対象」と「実行処理」と「処理引数リスト」とを、アプリケーションの更新により既存データの変換が必要な場合等に、アプリケーションの実行に関するデータと選別済みトランザクションデータ502との対応関係において説明した処理と同様に適宜設定する。トランザクション形式参照部51は、選別済みトランザクションデータ502の「実行結果」に、アプリケーション更新による既存データの変換等を行った際に、移行元データストア5への参照及び書込を示す情報を適宜設定する。
 以上の処理により、トランザクション形式参照部51は、一般的なアプリケーションと移行元データストア5の実行記録とを移行元ノード31と同様のデータ形式に変換することができる。
 トランザクション形式参照部51は、移行元ノード31と同様のデータ形式に変換したデータを、データ取得部112に送信する。
 図35は、本実施の形態に係るデータ送信部133の動作の一例を示すフローチャートである。本図を参照してデータ送信部133の動作を説明する。
(ステップS421:データ送信処理)
 データ送信部133は、データ作成部132が作成した移行データ510を受け取り、受け取った移行データ510の「接続移行先ノード」と「接続移行先ノード資格情報」とを利用し、適宜、移行先ノード41又は移行先データストア6に接続する。データ送信部133が移行先ノード41に接続する場合の処理については実施の形態1における処理と同様であるため説明を省略する。データ送信部133が移行先データストア6に接続する場合、データ送信部133は移行データ510をベースとしたデータを移行先データストア6に送信する。
(ステップS422:実行処理)
 トランザクション形式登録部61は、データ送信部133からデータを受信し、受信したデータが含む処理を適宜実施し、処理の結果を移行先データ保存部62に記録する。ここでは、データ送信部133から、移行データ510の「頂点データリスト」と、「頂点データリスト」が含む要素に対応する各頂点データ505と、各頂点データ505に対応する選別済みトランザクションデータ502と、選別済みトランザクションデータ502に関連する補足データ503とが送信されたものと仮定して説明する。
 具体例として、まず、「頂点データリスト」が含むある要素に対応する頂点データ505に対応する選別済みトランザクションデータ502の「種別」が「スマートコントラクトデプロイ」又は「スマートコントラクト更新」である場合を考える。この場合において、トランザクション形式登録部61は、当該選別済みトランザクションデータ502に関連する補足データ503のスマートコントラクト本体を取得し、取得したスマートコントラクト本体と同等の処理が可能なアプリケーションを作成し、作成したアプリケーションの構築又は更新記録を移行先データ保存部62に登録する。次に、頂点データリストが含むある要素に対応する頂点データ505に対応する選別済みトランザクションデータ502の「種別」が「スマートコントラクト実行」である場合を考える。この場合において、トランザクション形式登録部61は、選別済みトランザクションデータ502の内容に従って、「実行対象」において指定されているスマートコントラクトと同等の処理を実行することができるアプリケーションを実行し、アプリケーションを実行した際の処理結果を移行先データ保存部62に記録する。また、トランザクション形式登録部61において分散型台帳と同じスマートコントラクトを動作させることができる場合において、トランザクション形式登録部61は、スマートコントラクト本体をアプリケーションに変換せず、スマートコントラクト本体をそのまま利用してもよい。
***実施の形態4の効果の説明***
 以上のように、本実施の形態によれば、分散型台帳以外にも、分散型台帳のトランザクションデータの形式を登録することと参照することとの少なくともいずれかが可能であるデータストアを対象として、データを抽出することと移行することとの少なくともいずれかが可能である。また、本実施の形態によれば、1つのデータ移行装置1により1つ以上の分散型台帳及びデータストアから抽出したデータを、1つ以上の別の分散型台帳及びデータストアに比較的簡単にデータを移行することができる。
 また、本実施の形態は、1つ以上の分散型台帳及びデータストアをトランザクション関係データとして表現し、当該トランザクション関係データに対応するデータを1つ以上の別の分散型台帳及びデータストアに移行することができる特徴を持つ。本特徴により、分散型台帳をデータ基盤として使用するシステムと、データストアをデータ基盤として使用するシステムとを統合する際に、データ移行作業の担当者が1つのツールを用いて比較的簡単にデータを移行することができる。従って、本実施の形態によれば、データを移行する作業に係る人的負荷を軽減することができる。
***他の実施の形態***
 前述した各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
 また、実施の形態は、実施の形態1から4で示したものに限定されるものではなく、必要に応じて種々の変更が可能である。フローチャート等を用いて説明した手順は、適宜変更されてもよい。
 1 データ移行装置、11 データ抽出部、111 取得要求受付部、112 データ取得部、113 データ選別部、12 移行順序作成部、121 トランザクション関係データ作成部、122 トランザクション関係データ記録部、13 データ登録部、131 登録要求受付部、132 データ作成部、133 データ送信部、14 補足データ管理部、141 補足データ受付部、142 補足データ記録部、15 台帳更新監視部、16 データ検証部、161 検証要求受付部、162 検証データ取得要求部、163 検証部、2 管理装置、21 移行要求部、211 取得要求部、212 登録要求部、22 補足データ登録要求部、23 データ検証要求部、3 移行元台帳ネットワーク、31 移行元ノード、4 移行先台帳ネットワーク、41 移行先ノード、5 移行元データストア、51 トランザクション形式参照部、52 移行元データ保存部、6 移行先データストア、61 トランザクション形式登録部、62 移行先データ保存部、501 移行元データ取得要求、502 選別済みトランザクションデータ、503 補足データ、504 トランザクション関係グラフ、505 頂点データ、506 辺データ、507 主キー更新履歴表、508 スマートコントラクト更新履歴表、509,509b 移行先データ登録要求、510 移行データ、511 データ検証要求、10 コンピュータ、81 プロセッサ、82 メモリ、83 通信インタフェース、84 補助記憶装置、88 処理回路、90 データ移行システム。

Claims (11)

  1.  移行元分散型台帳から移行先分散型台帳に電子データを移行する移行要求に基づいて、1つ以上の要素を含むデータである移行データの各要素として作成されるそれぞれの作成要素に対応するデータを含む取得データを前記移行元分散型台帳から取得するデータ取得部と、
     前記取得データから前記作成要素に対応するデータを選別して抽出するデータ選別部と、
     それぞれの前記作成要素に対応するデータを前記移行先分散型台帳に移行する移行順序を、前記作成要素に対応するデータを用いて作成する移行順序作成部と
    を備え、
     前記移行データは、前記移行要求に対応するデータであり、
     それぞれの前記作成要素は、前記電子データの少なくとも一部に対応するデータ移行装置。
  2.  前記移行順序作成部は、前記作成要素に対応するデータの少なくとも1つに1対1で対応する少なくとも1つのデータであって、それぞれの前記作成要素に対応するデータを前記移行先分散型台帳に移行することを補助するデータである補足データがある場合に、前記作成要素に対応するデータと前記補足データとを用いて前記移行順序を作成する請求項1に記載のデータ移行装置。
  3.  前記データ移行装置は、さらに、
     前記作成要素に対応するデータを用いて、それぞれの前記作成要素の形式に従ってそれぞれの前記作成要素を作成するデータ作成部と、
     それぞれの前記作成要素に対応するデータを、前記移行順序に基づいて前記移行先分散型台帳に送信するデータ送信部と
    を備える請求項2に記載のデータ移行装置。
  4.  前記データ移行装置と同じ機能を有する他のデータ移行装置を備えるデータ移行システムが前記データ移行装置を備え、
     前記データ移行装置は、さらに、
     前記移行先分散型台帳が前記他のデータ移行装置から受信して前記移行先分散型台帳に登録したデータを示す他装置登録情報を取得する台帳更新監視部を備え、
     前記データ作成部は、前記電子データを移行している途中において、前記移行先分散型台帳が前記データ送信部から受信して前記移行先分散型台帳に登録したデータと、前記他装置登録情報とに基づいてそれぞれの前記作成要素を作成し、
     前記データ送信部は、それぞれの前記作成要素に対応するデータを前記他装置登録情報に基づいて前記移行先分散型台帳に送信し、前記データ送信部がそれぞれの前記作成要素に対応するデータを前記移行先分散型台帳に送信することによって前記移行先分散型台帳が登録したデータを示す情報を前記他のデータ移行装置に送信する請求項3に記載のデータ移行装置。
  5.  前記作成要素に対応するデータは、トランザクションを示すデータであり、
     前記データ選別部は、前記取得データから前記作成要素に対応するデータを選別済みトランザクションデータとして抽出し、
     前記移行順序作成部は、
     前記補足データがない場合に、前記選別済みトランザクションデータを用いて、前記選別済みトランザクションデータ間の関係に基づいて前記移行順序を規定するデータであるトランザクション関係データを作成し、
     前記補足データがある場合に、前記選別済みトランザクションデータと、前記補足データとを用いて前記トランザクション関係データを作成するトランザクション関係データ作成部を備え、
     前記データ作成部は、それぞれの前記作成要素として、前記選別済みトランザクションデータを示すデータ、又は、前記選別済みトランザクションデータと前記選別済みトランザクションデータに対応する補足データとのそれぞれを示すデータを含むデータを、前記トランザクション関係データを利用して作成する請求項3又は4に記載のデータ移行装置。
  6.  前記トランザクション関係データ作成部は、前記トランザクション関係データとして、前記移行順序と、前記選別済みトランザクションデータを前記移行先分散型台帳に移行する移行条件とをグラフ構造により表すトランザクション関係グラフを作成し、
     前記データ作成部は、前記トランザクション関係グラフのグラフ構造を利用して、前記移行先分散型台帳に登録することができるそれぞれの前記作成要素に対応するデータを登録可能データとして抽出し、
     前記データ送信部は、前記登録可能データを含むデータを前記移行先分散型台帳に向けて送信する請求項5に記載のデータ移行装置。
  7.  前記電子データの少なくとも一部を前記移行先分散型台帳に移行した後において、
     前記データ取得部は、前記移行元分散型台帳と前記移行先分散型台帳との同一性を検証する要求であるデータ検証要求に基づいて、前記移行データの少なくとも一部に対応するデータである移行先移行データの各要素に対応するデータである移行先データを含む移行先取得データを前記移行先分散型台帳から取得し、
     前記データ選別部は、前記移行先取得データから前記移行先データを選別して抽出し、
     前記トランザクション関係データ作成部は、
     前記移行先データのいずれに対応する補足データもない場合に、前記移行先データを用いて移行先トランザクション関係データを作成し、
     前記移行先データの少なくともいずれかそれぞれに対応する補足データがある場合に、前記移行先データと、前記移行先データの少なくともいずれかそれぞれに対応する補足データとを用いて移行先トランザクション関係データを作成し、
     移行先トランザクション関係データは、前記トランザクション関係データの少なくとも一部である比較用関係データと対応し、
     前記データ移行装置は、さらに、
     前記比較用関係データと前記移行先トランザクション関係データとを比較することにより、前記移行元分散型台帳と前記移行先分散型台帳との同一性を検証するデータ検証部を備える請求項5又は6に記載のデータ移行装置。
  8.  前記データ取得部は、前記移行要求に基づいて、前記移行元分散型台帳の代わりに前記移行元分散型台帳が記録しているデータと同じデータを記録しているデータストアから前記取得データを含むデータを取得する請求項3から7のいずれか1項に記載のデータ移行装置。
  9.  前記データ送信部は、前記移行先分散型台帳の代わりにそれぞれの前記作成要素に対応するデータを処理することができるデータストアにそれぞれの前記作成要素に対応するデータを送信する請求項3から8のいずれか1項に記載のデータ移行装置。
  10.  データ取得部が、移行元分散型台帳から移行先分散型台帳に電子データを移行する移行要求に基づいて、1つ以上の要素を含むデータである移行データの各要素として作成されるそれぞれの作成要素に対応するデータを含む取得データを前記移行元分散型台帳から取得し、
     データ選別部が、前記取得データから前記作成要素に対応するデータを選別して抽出し、
     移行順序作成部が、それぞれの前記作成要素に対応するデータを前記移行先分散型台帳に移行する移行順序を、前記作成要素に対応するデータを用いて作成し、
     前記移行データは、前記移行要求に対応するデータであり、
     それぞれの前記作成要素は、前記電子データの少なくとも一部に対応するデータ移行方法。
  11.  移行元分散型台帳から移行先分散型台帳に電子データを移行する移行要求に基づいて、1つ以上の要素を含むデータである移行データの各要素として作成されるそれぞれの作成要素に対応するデータを含む取得データを前記移行元分散型台帳から取得するデータ取得処理と、
     前記取得データから前記作成要素に対応するデータを選別して抽出するデータ選別処理と、
     それぞれの前記作成要素に対応するデータを前記移行先分散型台帳に移行する移行順序を、前記作成要素に対応するデータを用いて作成する移行順序作成処理と
    をコンピュータであるデータ移行装置に実行させるデータ移行プログラムであって、
     前記移行データは、前記移行要求に対応するデータであり、
     それぞれの前記作成要素は、前記電子データの少なくとも一部に対応するデータ移行プログラム。
PCT/JP2021/003833 2021-02-03 2021-02-03 データ移行装置、データ移行方法、及び、データ移行プログラム WO2022168192A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
CN202180092049.2A CN116802622A (zh) 2021-02-03 2021-02-03 数据转移装置、数据转移方法以及数据转移程序
DE112021006204.2T DE112021006204T5 (de) 2021-02-03 2021-02-03 Daten-Transfereinrichtung, Daten-Transferverfahren und Daten-Transferprogramm
PCT/JP2021/003833 WO2022168192A1 (ja) 2021-02-03 2021-02-03 データ移行装置、データ移行方法、及び、データ移行プログラム
JP2022572731A JPWO2022168192A1 (ja) 2021-02-03 2021-02-03
US18/205,838 US20230315719A1 (en) 2021-02-03 2023-06-05 Data transfer device, data transfer method and non-transitory computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/003833 WO2022168192A1 (ja) 2021-02-03 2021-02-03 データ移行装置、データ移行方法、及び、データ移行プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/205,838 Continuation US20230315719A1 (en) 2021-02-03 2023-06-05 Data transfer device, data transfer method and non-transitory computer readable medium

Publications (1)

Publication Number Publication Date
WO2022168192A1 true WO2022168192A1 (ja) 2022-08-11

Family

ID=82741259

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/003833 WO2022168192A1 (ja) 2021-02-03 2021-02-03 データ移行装置、データ移行方法、及び、データ移行プログラム

Country Status (5)

Country Link
US (1) US20230315719A1 (ja)
JP (1) JPWO2022168192A1 (ja)
CN (1) CN116802622A (ja)
DE (1) DE112021006204T5 (ja)
WO (1) WO2022168192A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018014036A (ja) * 2016-07-22 2018-01-25 沖電気工業株式会社 データベースシステム、データ処理プログラム、及びデータ処理方法
JP2020042671A (ja) * 2018-09-12 2020-03-19 富士通株式会社 取引管理装置、取引管理方法および取引管理プログラム
JP2020526805A (ja) * 2017-05-05 2020-08-31 ジェフ ストールマン 関連する子ブロックチェーンを用いたブロックチェーンの実用性向上のためのシステムおよび方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018014036A (ja) * 2016-07-22 2018-01-25 沖電気工業株式会社 データベースシステム、データ処理プログラム、及びデータ処理方法
JP2020526805A (ja) * 2017-05-05 2020-08-31 ジェフ ストールマン 関連する子ブロックチェーンを用いたブロックチェーンの実用性向上のためのシステムおよび方法
JP2020042671A (ja) * 2018-09-12 2020-03-19 富士通株式会社 取引管理装置、取引管理方法および取引管理プログラム

Also Published As

Publication number Publication date
JPWO2022168192A1 (ja) 2022-08-11
US20230315719A1 (en) 2023-10-05
DE112021006204T5 (de) 2023-10-12
CN116802622A (zh) 2023-09-22

Similar Documents

Publication Publication Date Title
CN110417844B (zh) 使用区块链分散管理多所有者节点的系统和方法
JP6638024B2 (ja) システム、スマートコントラクトのライフサイクルの管理方法、及び非一時的コンピュータ可読媒体
CN109246179B (zh) 维护区块链的方法和装置、服务器和计算机可读存储介质
CN110620810B (zh) 在区块链上的连续资产转移的非链接所有权
US10108632B2 (en) Splitting and moving ranges in a distributed system
CN110300984B (zh) 改变在区块链中记录的智能合约
US20190266173A1 (en) Synchronization of data between systems
US20180183687A1 (en) System and Method for Managing Services and Licenses Using a Blockchain Network
CN112835612A (zh) 一种基于区块链的电子文档版本管理方法及装置
DE112021002797T5 (de) Datenschutzerhaltende architektur für genehmigungspflichtige blockchains
Mendes et al. Charon: A secure cloud-of-clouds system for storing and sharing big data
US11122012B2 (en) License utilization management system service suite
CN110474901B (zh) 公有区块链网络系统
US20210374112A1 (en) Migration support system, migration support method, and node
JP6868728B2 (ja) パーミッションドブロックチェーンアプリケーションの継続的デリバリのための方法及び装置
Konashevych Cross-blockchain protocol for public registries
CN109189778A (zh) 一种在线修改数据库表结构的方法
WO2022168192A1 (ja) データ移行装置、データ移行方法、及び、データ移行プログラム
JP2011522337A (ja) サーバクラスタに配信されるコンピュータシステムのソフトウェアモジュールの同期化方法、同期化システムおよびデータストレージへの適用
KR20210082481A (ko) 데이터베이스 관리 서비스 제공 시스템
US10657139B2 (en) Information processing apparatus and non-transitory computer readable medium for distributed resource management
KR102294569B1 (ko) 블록체인 네트워크를 구축할 수 있는 블록체인 관리시스템
WO2022079831A1 (ja) 登録者端末、保有者端末、方法およびプログラム
JP2022014369A (ja) 分散台帳管理システム、分散台帳管理方法、およびノード
JP7424490B2 (ja) 登録者端末、検証者端末、管理システムおよびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21924589

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022572731

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 202180092049.2

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 112021006204

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21924589

Country of ref document: EP

Kind code of ref document: A1