JP2020086478A - Distributed data management method and distributed data management apparatus - Google Patents

Abstract

To issue transaction data by automatically selecting an approval destination of addition, modification and deletion of data.SOLUTION: A distributed data management method of a block chain system in which a server including a processor, a memory, and a storage unit for storing a ledger manages the ledger by distributing the ledger with another server, includes a first step in which the server receives a modification content to the ledger including an item and an item value, and a second step in which the server refers to approval group management information that sets an approval destination server for approving the modification contents in advance according to the item and the item value, and determines the approval destination server.SELECTED DRAWING: Figure 2

Description

The present invention relates to a distributed data management method and a distributed data management device in which a platform using a block chain is shared by a plurality of businesses.

The supply chain is the route of goods and services from the manufacturer to the final consumer, and is the transaction between various companies (or groups) or departments within the company, from materials, parts, assembly, transportation, and sales. Information is exchanged.

Information such as commercial flow, money flow, and physical distribution is transmitted on the supply chain, but there is a difference in information between the companies. For example, a business operator closer to the final consumer can detect demand fluctuations, etc. earlier, while information transmission to upstream suppliers is delayed, so there is a sudden response such as a change in delivery date, inventory depletion or excess. Such a situation can occur. In the distribution of information in the supply chain, it is necessary for the stakeholders to form consensus rather than changing it unilaterally.

On the other hand, the distributed ledger technology such as the block chain is expected to be effective in that it can share information while safely and tampering-proof, and eliminate the information disparity in the supply chain.

In Patent Document 1, when the sender wants to attach an agreement of the contract content to the receiver, the contract content and the approval request thereof are simultaneously broadcast to the blockchain participants with a signature in the blockchain transaction. Then, Patent Document 1 discloses a method in which a receiver acquires a record approved by himself/herself from received data of himself/herself and further broadcasts an approved transaction with a signature.

In Patent Document 1, while maintaining a form of one electronic signature for one transaction by such a mechanism, even a large number of people effectively leave a trail of contract on the blockchain.

JP, 2017-220710, A

When the technology of Patent Document 1 is utilized in transactions on a supply chain, there arises a problem that a method of selecting an approval party and that three or more parties cannot modify the same contract data (record).

Regarding the selection of the first approval party, the receiver must automatically select the sender in the supply chain. In addition, the number of transactions in the supply chain becomes huge. For example, in the case of changing the delivery date or the order quantity of a product, when requesting a correction from a plurality of vendors, it takes a great deal of work for the sender to specify the approval destinations one by one.

Secondly, when contract data is shared by three or more parties, there is a problem that a plurality of changes cannot be made at the same time before approval. For example, suppose three companies, Company A, Company B, and Company C, have contracts regarding the delivery date and quantity of products. Company A requests Company B to change the contract regarding the delivery date. On the other hand, it is assumed that Company C changes the contract regarding delivery date to Company A at the same time or later.

However, since the company C does not know the details of the change from the company A to the company B, the contract change request from the company C to the company A may be wasted. In order to prevent this, when the contract change request is sent from company A to company B, the change related to the contract record is locked, but the business of company C is unnecessarily stopped for the locked contract. There was a problem.

In view of the above problems, it is an object of the present invention to automatically select an approval destination for data addition, change, and deletion in a huge supply chain transaction and issue transaction data. Furthermore, even if multiple companies try to modify transaction data at the same time, the purpose of sharing the modification contents with all participants before approval and enabling each participant to issue transaction data in view of each modification content And

The present invention is a distributed data management method for a block chain system, wherein a server having a processor, a memory, and a storage unit for storing a ledger manages the ledger in a distributed manner with other servers. A first step of receiving correction contents for the ledger including the value of, and the approval group management information in which the server presets an approval destination server that approves the correction contents according to the item and the value of the item. And a second step of determining an approval destination server.

Therefore, the present invention makes it possible to issue transaction data in which an approval destination for data addition, change, and deletion is automatically selected in a huge number of transactions in the supply chain. Further, according to the present invention, when a plurality of participants try to modify the same data at the same time, all the participants share the modification content before the transaction is approved, and the approval result (transaction data) is issued in consideration of each modification content. It becomes possible to do.

The details of at least one implementation of the subject matter disclosed herein are set forth in the accompanying drawings and the description below. Other features, aspects, and effects of the disclosed subject matter will be made apparent by the following disclosure, drawings, and claims.

It is a block diagram which shows the Example of this invention and shows an example of a ledger joint management system. It is a block diagram which shows the Example of this invention and shows an example of the functional element of a ledger joint management server. It is a block diagram showing an example of the present invention and showing an example of composition of a ledger joint management server. It is a figure which shows the Example of this invention and shows an example of an order book. It is a figure which shows the Example of this invention and shows an example of a production management ledger. It is a figure which shows the Example of this invention and shows an example of an access right management ledger. It is a figure which shows the Example of this invention and shows an example of a progress information display screen. 9 is a flowchart illustrating an example of the present invention and an example of progress information generation processing. It is a figure which shows the Example of this invention and shows an example of a correction request screen. It is a figure which shows the Example of this invention and shows an example of the correction request screen when a warning is displayed. It is a figure which shows the Example of this invention and shows an example of a temporary update ledger. 9 is a flowchart illustrating an example of the present invention and an example of data correction and correction request processing. It is a figure which shows the Example of this invention and shows an example of an approval request screen. It is a figure which shows the Example of this invention and shows an example of the approval record contained in a temporary update ledger. It is a flow chart which shows an example of the present invention and shows an example of approval processing. 10 is a flowchart illustrating an example of the present invention and an example of a data reflection process after approval. It is a figure which shows the Example of this invention and shows an example of an approval status confirmation screen.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

FIG. 1A is a block diagram showing an example of the consensus building system of this embodiment. FIG. 1B is a block diagram showing an example of the functional elements of the ledger collaboration management server that constitutes the consensus building system.

In FIG. 1A, the consensus building system is connected to the business systems 101-1 to 101-3 of a plurality of trading companies such as Company H, Company I, and Company J, and terminals 111-1 to 111-4 of each company. The ledger collaboration management servers 100-1 to 100-3 and the network 200 connecting the ledger collaboration management servers 100-1 to 100-3 to each other.

The business system 101-1 of the H company includes a terminal 111-1 of the A factory and a terminal 111-2 of the procurement department. The business system 101-2 of company I and the business system 101-3 of company J include w terminals 111-3 and 111-4, respectively.

In the following description, when the individual ledger co-management server is not specified, the reference numeral “100” is used by omitting the reference numerals after “−”. The same applies to the reference numerals of other components.

In the terminal 111 of each company, the ordering system database 121 and the production management system database 122 operate. A ledger collaborative management server 100 that manages the ledger in a distributed manner by using a block chain (block chain system) 104 is arranged in each business system 101 of each company, and is connected to a terminal 111.

The terminal 111 transmits information such as ordering, shipping, contract request, change, and approval to the ledger co-management server 100. The ledger joint management servers 100-1 to 100-3 of the H company, the I company, and the J company share the information received from the terminal 111 of each company by reflecting it on the ledger on the block chain 104 described later and jointly managing it. To do.

The ledger collaborative management server 100 executes an automatic execution program 105 that shares and manages the ledger with the ledger collaborative management server 100 of another company using the block chain 104. As shown in FIG. 1B, the distributed shared ledger on the block chain 104 shared by the ledger collaborative management server 100 of each company includes an order ledger 131, a production management ledger 132, an access right management ledger 133, and an update ledger 133. An example in which the temporary order ledger 141, the temporary production management ledger 142 for updating, the temporary update ledger 140 and the access right management ledger 133 are shown.

The ordering ledger 131 and the production management ledger 132 function as a master, and the temporary ordering ledger 141 and the temporary production management ledger 142 are duplicates of the ordering ledger 131 and the production management ledger 132, and function as an updating ledger. The temporary update ledger 140 stores the correction contents for the ordering ledger 131 or the production management ledger 132 and the approval history for the correction contents.

As will be described later, the access right management ledger 133 is preset with an approval group for approval in units of supply chain groups.

Transactions of the order book 131, the production control book 132, the temporary order book 141, the temporary production management book 142, the temporary update book 140, and the access right management book 133 are recorded in the block chain 104. The contents of each ledger will be described later.

The automatic execution program 105 of the ledger co-management server 100 is a program for referencing and updating transactions in the block chain 104. The ledger co-management server 100 can actively activate the automatic execution program 105, and can also execute the automatic execution program 105 each time a transaction is updated. The automatic execution program 105 may use a function held by the block chain 104 such as a smart contract.

The automatic execution program 105 includes program modules of a data combination unit 151, a data registration unit 152, a data collection unit 153, an agreement formation unit 154, an approval unit 155, and an update unit 156.

FIG. 2 is a block diagram showing an example of the configuration of the ledger collaboration management server 100 of this embodiment. The ledger co-management server 100 includes a CPU 202, a memory 207, a network interface 203, an input device 204, a storage device 205, and an output device 206. These constituent elements are connected via a bus (or interconnect) 201, and input/output data respectively.

The CPU 202 executes the automatic execution program 105 loaded in the memory 207 and executes various processes such as data input, calculation, and data output.

The network interface 203 is a device that transmits/receives data to/from another company's ledger joint management server 100 or the like via the network 200. The contents transmitted and received by the network interface 203 are controlled by the CPU 202. The network interface 203 is composed of, for example, a NIC (Network Interface Card) or a wireless LAN interface card.

The input device 204 receives an instruction from a user who uses the ledger co-management server 100 and transmits it to the CPU 202. The input device 204 is composed of, for example, a keyboard, a mouse, a touch panel, or the like.

The memory 207 stores programs processed by the CPU 202, data, and the like. The storage device 205 includes a non-volatile storage medium. The storage device 205 is composed of, for example, a magnetic disk such as an HDD (Hard Disk Drive), an optical disk such as a DVD, or a non-volatile memory.

The storage device 205 stores an ordering ledger 131, a production management ledger 132, a temporary ordering ledger 141, a temporary production management ledger 142, an access right management ledger 133, and a temporary updating ledger 140. The temporary update ledger 140 shown in the figure is information for accumulating the approval content for the change of the temporary order ledger 141 and the temporary production management ledger 142 as described later.

The output device 206 is a device that displays a screen of a user interface based on a command from the CPU 202. The output device 206 is, for example, a liquid crystal display or the like.

The CPU 202 operates as a functional unit that provides a predetermined function by executing processing according to a program of each functional unit. For example, the CPU 202 functions as the data combination unit 151 by executing processing according to the data combination program. The same applies to other programs. Further, the CPU 202 also operates as a functional unit that provides each function of a plurality of processes executed by each program. The computer and the computer system are devices and systems including these functional units.

In the following description, an example is shown in which the user requests addition or correction of data to each ledger from the input device and the output device (not shown) of the terminal 111 via the ledger joint management server 100. The input device 204 and the output device 206 of the server 100 may be used to request addition or correction of data to each ledger.

Next, various data included in FIG. 1B will be described. FIG. 3 is a diagram showing an example of the order ledger 131.

The order book 131 manages data regarding orders received and received between companies or between organizations within a company (group companies). The order book 131 includes, for example, an order number 301, an order source 302, a person in charge 303, an order destination 304, an order date 305, a delivery date 306, a product name 307, and a quantity 308.

The order book 131 manages order information generated in the order system database 121 and the production management system database 122. The order book 131 may be a row of free-form records as shown in FIG. 3, or may be in a format such as RDB (Relational Data Base).

The order number 301 includes an identifier that distinguishes the order history included in the order book 131. Therefore, the order number 301 is given a number or symbol different from those of other records.

The ordering party 302 stores the name or identifier of the ordering company. The person in charge 303 stores the name of the person in charge of ordering in the orderer 302. The orderee 304 stores the name or identifier of the orderee company.

The order date 305 stores the date when the order source 302 and the order destination 304 agree on the order content. The delivery date 306 stores the expected delivery date included in the agreed content of the order content.

The product name 307 is the name or identifier of the product ordered by the order source 302. The quantity 308 stores the quantity of the product ordered by the orderer 302.

Note that the configuration of the order ledger 131 shown in FIG. 3 is merely an example, and the order and addition of items and the change of item names may be performed as necessary. If a special contract is required and cannot be expressed in the current table, information associated with the contract may be stored.

FIG. 4 is a diagram showing an example of the production management ledger 132. The production management ledger 132 manages production progress between companies or organizations within a company (group companies). The production management ledger 132 has the same configuration as the production management system database 122.

The production management ledger 132 includes, for example, a work number 401, an order number 402, an order source 403, a product name 404, a quantity 405, an order date 406, a requested delivery date 407, a scheduled delivery date 408, and a work content 409. And the completion schedule 410 is included in the component.

The production management ledger 132 manages business plans such as production, procurement, and work for the order contents of this embodiment. As shown in FIG. 4, the production management ledger 132 may be a row of free-form records, or may be in a format such as RDB.

The work number 401 stores an identifier for distinguishing each work included in the production management ledger 132. The work number 401 is given a number or symbol different from those of other records.

The order number 402 is the order number 301 included in the order ledger 131, and serves as association information of the order ledger 131. In this embodiment, it is assumed that there are a plurality of work numbers 401 for one order number 402.

The order source 403, product name 404, and quantity 405 are information of the same name included in the order ledger 131. The order reception date 406 stores the date when the information was written in the production management ledger 132. The requested delivery date 407 stores the estimated delivery date included in the order content (agreement content).

The scheduled delivery date 408 is a scheduled delivery date from the order receiving side that is updated by the content of production management or manually. If the planned delivery date 408 exceeds the requested delivery date 407, a problem will occur, and it is necessary to form consensus as described later.

The work content 409 stores the work content and the work name scheduled to be executed based on the production management. Scheduled completion 410 describes the scheduled date when the work included in this work number 401 will end. The scheduled completion date may be updated each time as the work progresses.

Note that the configuration of the production management ledger 132 shown in FIG. 4 is merely an example, and the order and addition of items and the change of item names may be performed as necessary. If a special contract is required and cannot be expressed in the current table, information associated with the contract may be stored.

Next, a ledger to which the block chain 104 is applied will be described. The block chain 104 includes an order ledger 131, a production management ledger 132, an access right management ledger 133, a temporary order ledger 141, a temporary production management ledger 142, and a temporary updated ledger 140.

The temporary order ledger 141 is a temporary ledger for updating the order ledger 131. The temporary production management ledger 142 is a temporary ledger for updating the production management ledger 132. As described above, the temporary update ledger 140 stores the correction content and the approval history.

The temporary order register 141 has the same format as the order register 131 of FIG. The temporary production management ledger 142 also has the same format as the production management ledger 132 of FIG. In this embodiment, as transactions on the block chain 104, each record of the ordering ledger 131 and the production control ledger 132 of FIGS. 3 and 4 is encrypted by a signature and recorded in each ledger.

In the consensus building system of this embodiment, the ordering ledger 131 and the production management ledger 132 stored in the blockchain 104 are regularly ordered by the data collection unit 153 of the automatic execution program 105 by the ordering system database 121 and the production management system database. It is assumed to be synchronized with 122.

The relationship between the master ordering ledger 131 and the temporary ordering ledger 141 for updating is as follows. When the terminal 111 adds or updates (or deletes) information (transaction), first, the correction contents for the master are written in the temporary update ledger 140 and the temporary order ledger 141 by the ledger joint management server 100 of the company.

The ledger co-management server 100 refers to the access right management ledger 133 and identifies the company 504 related to the correction content data as the approval destination.

Upon receiving the approval condition (agreement condition) from the terminal 111, the ledger co-management server 100 writes the transaction for the approval application into the temporary update ledger 140 and transmits it to the specified approval destination.

The ledger co-management server 100, which is requested to approve, accepts the approval at its own terminal 111, and responds to the ledger co-management server 100 requesting the approval via the block chain 104.

The ledger co-management server 100 that has requested the approval determines whether or not a predetermined agreement condition is satisfied based on the approval result of the other company. If the agreement condition is satisfied, the order ledger 131 and the production management ledger 132 are corrected. To reflect. Further, the ledger co-management server 100 records the transaction in the temporary update ledger 140 as an agreement-formed transaction.

The automatic execution program 105 can reflect the contents written in the master order book 131 in the order system database 121.

On the other hand, if the agreement conditions are not satisfied, the master is not written to the order book 131, the correction contents of the temporary order book 141 are restored, and the transactions that did not satisfy the approval condition in the temporary update book 140. Accumulated as.

The relationship between the production management ledger 132 and the temporary production management ledger 142 is similar to the relationship between the order placement ledger 131 and the temporary order placement ledger 141, and a predetermined transaction among additions and updates (or deletions) to the temporary production management ledger 142 is performed. The transaction satisfying the agreement condition is written in the master production management ledger 132.

The ordering ledger 131, the production management ledger 132, the temporary ordering ledger 141, the temporary production management ledger 142, the temporary update ledger 140, and the access right management ledger 133 on the block chain 104 form blocks for each predetermined number of transactions. Each block includes at least the hash value of the immediately preceding block and the transaction. Also, each block may be encrypted with a signature as described above.

The block may be generated by the ledger co-management server 100 or by another computer connected to the network 200. Further, the implementation of the nonce when generating the hash value and the adoption of the signature can be appropriately selected according to the operation of the consensus building system.

Further, the ordering ledger 131 and the production control ledger 132 may be manually synchronized. Further, the order book 131 and the production management book 132 may be files generated by text or spreadsheet software instead of the database system. In that case, the person in charge of each business system 101 manually uploads the files and The registration unit 152 may be able to update.

Next, the access right management ledger 133 will be described. FIG. 5 is a block diagram showing an example of the access right management ledger 133. The access right management ledger 133 is generated in advance by an administrator or the like. In this example, the ledger co-management server 100 uses the access right management ledger 133 as an approval destination management ledger.

The access right management ledger 133 stores data references and editing rights for transactions on the block chain 104. The access right management ledger 133 is composed of a group number 501, a group key 502, group information 503, and an affiliated company 504.

The group number 501 is a number that identifies a group of access rights. In the group key 502, the names of columns included in the order book 131 and the production management book 132 are set. The group key 502 stores a unit (item) for controlling a group of access rights. In the example of FIG. 5, a group is configured for each “product name” of the items in the order register 131 and the production management register 132.

The group information 503 indicates the contents of the group (item value) actually configured for the group key 502. In the example shown in the figure, the supply chain group is set by the item names 307 and 404 of the order register 131 and the production management ledger 132, and the product name includes data including the value “member X”.

The affiliated company 504 stores the company name that can access the record having the value specified by the group information 503. In the example of FIG. 5, the company H, company I, and company J can refer to or edit the order register 131 and the production management register 132 related to the group information 503=the product name “member X”. The ledger co-management server 100 of a company that is not set as the affiliated company 504 is denied access to the data of the group number 501.

The ledger co-management server 100 with the company name set for the affiliated company 504 becomes an approval group for the approval application. For example, in the example of FIG. 5, the approval group is configured by the ledger joint management servers 100 of company H, company I, and company J that handle the product name “member X”. In the approval group, when one company proposes an application for approval of correction contents, approval is executed by the ledger co-management server 100 of the remaining companies.

That is, the approval application for the correction content proposed by Company H is executed by the ledger joint management server 100 of Company I and Company J.

The ledger co-management server 100 refers to the access right management ledger 133 shown in FIG. 5 to transmit the approval application based on the group key 502 (item) and the group information 503 (product name) which is the value of the key. It is possible to specify the company name of the approval destination (ledger joint management server 100).

As a result, the ledger co-management server 100 can share the ordering ledger 131 and the production management ledger 132 with a large number of companies, and can quickly identify the consensus formation destination (approval destination).

These access rights may be created, for example, in the material transactions on the supply chain and the extent of their influence.

Next, an example of processing performed by each program module that constitutes the automatic execution program 105 will be described.

The data combination unit 151 of the automatic execution program 105 calls each transaction registered in the block chain 104 in response to a command (correction request or approval result) from the terminal 111 of each company, and obtains the latest progress information from the terminal 111. (Or output to the output device 206 of the ledger co-management server 100).

Specifically, the program module of the data combining unit 151 generates the progress information 601 from the data extracted from the temporary order register 141 and the temporary production management ledger 142, and displays the progress information on the terminal 111 that has received the request for the progress information 601. The screen 600 is output.

The data collection unit 153 synchronizes the data of the ordering system database 121 and the production management system database 122 of the companies participating in the block chain 104 with the ordering ledger 131 and the production management ledger 132 in a predetermined cycle.

Further, the data collection unit 153 synchronizes the data of the order register 131 and the production management ledger 132 with the temporary order ledger 141 and the temporary production management ledger 142 at a predetermined cycle.

The consensus building unit 154 acquires the transaction for which correction has been requested from the temporary order ledger 141 and the temporary production management ledger 142, adds the transaction to the temporary update ledger 140, and automatically adds the ledger joint management server 100 of the company requesting approval. Select and output the correction request screen to the output device 206.

The approval unit 155 transmits the approval application to the ledger collaboration management server 100 that is the approval destination that has been set. Upon receiving the approval request, the ledger collaboration management server 100 that is the approval destination outputs an approval request screen to the output device 206 or the terminal 111.

When the approval unit 155 of the ledger co-management server 100 of the approval destination receives the approval result from the terminal 111 or the input device 204, the approval record is written in the temporary update ledger 140 on the block chain 104.

When the approval record is written in the provisional update ledger 140, the update unit 156 determines whether or not an agreement has been formed. The updating unit 156 reflects the correction contents on the order book 131, the production management book 132, the temporary order book 141, and the temporary production management book 142 if the approval results from the accessible companies are complete and an agreement is formed. , Complete a series of processes from correction to consensus building.

On the other hand, when the agreement is not formed, the update unit 156 writes “reject” in the status 908 of the provisional update ledger 140, writes the failure of agreement, and accumulates it as a history of agreement formation. Note that the corrections made to the temporary order ledger 141 and the temporary production management ledger 142 are restored.

The data registration unit 152 is used at the time of main maintenance of the order book 131 and the production management book 132.

FIG. 6 is a diagram showing an example of the progress information display screen 600. The progress information display screen 600 includes the progress information 601 generated from the temporary order register 141 and the temporary production management ledger 142, a status update button 602, and a data correction request button 603 as constituent elements.

In the progress information 601, the latest order status related to the company is displayed. The update of the progress information 601 is executed by the data combination unit 151 program of the automatic execution program 105 when the progress information display screen 600 is first opened or when the status update button 602 is clicked.

The progress information 601 includes an order number 611, a purchasing department 612, a purchaser 613, an order receptionist 614, a supplier receptionist 615, an order date 616, a delivery date 617, a product name 618, and a quantity 619. , Status 620 is included in one entry.

The order number 301 of the order book 131 is displayed in the order number 611. In the purchasing department 612, the order source 302 of the order ledger 131 is displayed. For the person in charge of purchasing 613, the person in charge 303 of the order book 131 is displayed.

The order receiver 304 in the order register 131 is displayed in the order receiver 614. The name of the person in charge of the supplier 304 is displayed in the supplier reception section 615. On the order date 616, the order date 305 of the order ledger 131 is displayed.

In the delivery date 617, the delivery date 306 of the order ledger 131 or the requested delivery date 407 of the production management ledger 132 is displayed. In the product name 618, the product name 307 of the order book 131 is displayed. The quantity 619 displays the quantity 308 of the order book 131.

The status calculated by the data combining unit 151 is displayed in the status 620. As the status 620, for example, "reception", "not yet delivered", "delivering", "inspection", and "delivery completed" can be adopted. When the status 620 is “acceptance”, it indicates a state in which the planned delivery date 408 of the production management ledger 132 is not described at the stage when the orderer accepts it.

When the status 620 is “undelivered”, it indicates that the product has not arrived at the ordering source 403. When the status 620 is "delivery in progress", it indicates that the product has been shipped from the supplier. When the status 620 is “inspection”, it indicates that the product name has arrived at the ordering company and the inspection is being performed.

When the status 620 is “delivery completed”, it indicates a state in which the orderer has received the goods from the orderee and has passed the inspection.

FIG. 7 is a flowchart showing an example of the processing performed by the data combining unit 151. This process is executed when the automatic execution program 105 receives a request for the progress information display screen 600 from the terminal 111.

The data combining unit 151 acquires preset user information from the address of the terminal 111 that has requested the progress information display screen 600 (S1). The user information includes the address of the terminal 111, the company name, and the department name (organization name), and is stored in the storage device 205 of the ledger co-management server 100.

The data combining unit 151 identifies the company name and department name of the user who uses the terminal 111 based on the user information, and places order information corresponding to the identified company name and department name in the provisional order of the block chain 104. It is acquired from the ledger 141. That is, from the user information of the terminal 111 that has requested the progress information display screen 600, data relating to the company name or department name of the terminal 111 is acquired from the temporary order ledger 141.

Next, the data combining unit 151 acquires the latest information from the temporary production management ledger 142 using the order number 301 included in the acquired record of the temporary order ledger 141 as a key, and generates the progress information 601 (S2). ..

The data combining unit 151 combines the data of the temporary order ledger 141 and the temporary production management ledger 142 by using the order number 301 as a key to generate the progress information display screen 600 including the information of the progress information 601, and outputs the progress information 601. Output to the requested terminal 111 (S3).

Through the above processing, the data combining unit 151 narrows down the information related to the company using the terminal 111 from the temporary order ledger 141 and the temporary production management ledger 142 to generate the progress information 601 in the tabular format, and the terminal 111 concerned. The progress information display screen 600 is output to. The user can correct the value of each item of the progress information 601 in the progress information display screen 600 from the input device (not shown) of the terminal 111 or the input device 204.

When the user of the terminal 111 (or ledger co-management server 100) corrects the value of the progress information 601 on the progress information display screen 600 and then clicks the correction request button 603, the automatic execution program 105 changes the correction content to another value. The approval request process for obtaining approval is started in the ledger co-management server 100.

FIG. 8A is a diagram showing an example of the correction request screen 800. The correction request screen 800 is a screen generated by the consensus forming unit 154 and output to the terminal 111 (or the output device 206) when the correction request button 603 is clicked on the progress information display screen 600 of FIG. 6. The correction request screen 800 can be set with information for obtaining approval for the content of the progress information 601 (temporary order register 141 or temporary production management ledger 142) that has been corrected (or added or deleted).

The correction request screen 800 includes approval destination registration settings 801, 802, 804, and 805 for registering the approval request destination (approval destination in the figure), a correction content area 810 showing a preview of the correction content, and an approval request button 806. A cancel button 807, an approval destination addition button 803, an approval route addition button 808, and approval condition setting buttons 814 and 815 are included.

Approval destination registration settings 801, 802, 804, and 805 are input items for setting the approval destination. When sharing information flatly on the blockchain 104, it is possible to request a plurality of approval destinations at a time. However, depending on the content of approval, if it is better to set the order of approval, the order can be added by clicking the approval route addition button 808.

In the example of the approval route shown in the drawing, the consensus forming unit 154 approves the approval destination registration settings 804 and 805 after requesting approval to the approval destination registration settings 801 and 802 and accepting the approval result of the approval destination registration settings 801 and 802. The approval request will be sent first.

The approval condition setting button 814 sets that the approval condition of the approval destination registration settings 801, 802, 804, 805 is the condition of “AND”. The approval condition setting button 815 sets that the approval condition of the approval destination registration settings 801, 802, 804, 805 is the condition of “OR”.

In the correction content area 810, the contents of the target item 811 of the correction content, the pre-correction 812 in which the value before correction of the item is stored, and the post-correction 813 in which the value after correction of the item is stored are displayed. It

The approval destination is automatically set according to the contents of the progress information 601 in FIG. That is, the consensus building unit 154 refers to the access right management ledger 133 and automatically selects a relevant approval destination based on information such as the purchasing department and the ordering source. This makes it possible to reduce the effort of setting the approval destination for each case.

The automatic selection of the approval destination may be set by the consensus forming unit 154 by referring to the access right management ledger 133. That is, the user who can access the record (data) can be set so that the consensus forming unit 154 automatically becomes the approval destination registration settings 801 and 802.

When the approval request button 806 is clicked to execute the approval request process, the consensus building unit 154 once writes the correction content of the progress information 601 to both the temporary order register 141 and the temporary production management register 142. The temporary update ledger 140 is a ledger that stores a history of consensus formation such as approval or rejection from an approval destination in addition to the correction content.

FIG. 9 shows an example of the format of the temporary update ledger 140. The temporary update ledger 140 includes information on an application number 901, an application source 902, a key 903, a correction content 904, an approval target 905, an approval condition 906, a comment 907, and a status 908.

The application number 901 is a number that distinguishes the records included in the temporary update ledger 140 and is given by the automatic execution program 105. The application source 902 is the name (or identifier) of the company to which the terminal 111 (ledger collaboration management server 100) executing the approval route belongs.

The key 903 is information for identifying the records of the temporary order ledger 141 and the temporary production management ledger 142 to be corrected. The key 903 is a value corresponding to the order number 301 of the order ledger 131 (temporary order ledger 141) and the order number 402 of the production management ledger 132 (temporary production management ledger 142).

The correction content 904 indicates the correction content for the data designated by the key 903, and is the content corrected by the progress information 601.

In the approval target 905, the name of the company requesting approval (or department name) and the approval result of each company are recorded. As for the approval result, “unapproved” indicates that approval is pending, “approval” indicates that the correction content 904 has been approved, and “rejection” indicates that the correction content 904 has been rejected.

As the approval condition 906, the approval condition determined by the approval condition setting button 814 or the approval condition setting button 815 shown in FIG. 8A is set.

In the comment 907, information input by the terminal 111 (or the input device 204) of the approval destination is stored. The status 908 stores the approval status of the temporary update ledger 140, the initial value of the approval status is “not completed”, and when approval is performed, information of “approval completed” or “rejected” is set. It “Approval completed” indicates that the agreement has been established, and “rejection” indicates that the agreement has not been established.

In the consensus building system of the present embodiment, once the correction content 904 is recorded in the temporary update ledger 140, there is an effect of preventing double correction from other terminals 111. That is, since the temporary update ledger 140 is also shared by the terminals 111 by the block chain 104, the user of the terminal 111 has already made a change application for the same key 903 before approving the correction content 904. It is possible to determine whether or not

If the temporary update ledger 140 with the same key 903 has already been corrected, a warning is displayed as shown in FIG. 8B. FIG. 8B is a diagram showing an example of a correction request screen when a warning is displayed.

In the modification request screen 800 of FIG. 8B, a warning area 820 is added in addition to the structure of the modification request screen 800 of FIG. 8A. In the warning area 820, the key 903 of the temporary update ledger 140 is the same and the previously proposed correction content is displayed.

In the warning area 820, the target item 821 of the correction content, the content 822 before the modification and the content 823 after the modification are displayed.

Thereby, the user of the terminal 111 can determine whether or not to make the approval application in view of the existing correction request. Further, by outputting the warning area 820 to the approval-side terminal 111 (or the ledger co-management server 100), it is possible to prevent duplicate corrections for the same key 903.

The correction request screen 800 shown in FIGS. 8A and 8B is generated by the consensus forming unit 154 and output to the terminal 111. FIG. 10 is a flowchart showing an example of processing performed by the consensus forming unit 154. This process is executed when the data correction request button 603 shown in FIG. 6 is clicked.

The consensus forming unit 154 reads the information corresponding to the correction content from the progress information 601 on the progress information display screen 600 (S11). The information corresponding to the correction content is, for example, the order number 611, the item to be corrected (for example, the delivery date 617), and the product name 618 for searching the access right management ledger 133.

The consensus forming unit 154 then loads the contents of the temporary update ledger 140 (S12). The consensus forming unit 154 searches the access right management ledger 133 with the product name 618 and the company name of the company, and selects the entry in which the group information 503 matches the product name 618 and the company 504 belongs to the company. The consensus building unit 154 selects a company excluding its own company from the affiliated company 504 as an approval destination (S13).

Next, the consensus building unit 154 adds a new entry to the temporary update ledger 140 shown in FIG. 9 and writes the correction content and the approval destination (S14). Note that the consensus building unit 154 writes the target item 811 in the correction content 810 shown in FIG. 8A, writes the content acquired in step S11 in the corrected content 813, and places the order register 131 or the production management register 132 that matches the key 903. The value of the corresponding item is acquired and written in the uncorrected 812.

The consensus forming unit 154 registers the temporary update ledger 140 in which the correction content and the approval destination are written in the block chain 104. The consensus forming unit 154 automatically determines the ledger including the correction item as to whether to write the correction content of the provisional update ledger 140 into either the provisional order ledger 141 or the provisional production management ledger 142.

Next, the consensus building unit 154 determines whether or not there is data in the temporary update ledger 140 that is the same as the key 903 to be modified this time and is waiting for approval (S15). The agreement forming unit 154 proceeds to step S16 if there is data in the temporary update ledger 140 that is the same as the key 903 to be modified this time and is waiting for approval, otherwise proceeds to step S17. The agreement formation unit 154 can determine whether approval is awaiting approval if the status 908 of the temporary update ledger 140 is “not completed”.

In step S16, the consensus building unit 154 acquires the temporary update ledger 140 that is the same as the key 903 to be corrected this time and is waiting for approval, and the target item 821 corresponding to the warning area 820 in FIG. The information of 822 before and 823 after correction is acquired.

Next, the consensus building unit 154 creates the correction request screen 800 (S17). If there is a temporary update ledger 140 that is the same as the key 903 to be corrected this time and is waiting for approval in the determination in step S15, the consensus forming unit 154 includes a correction request screen including a warning area 820 shown in FIG. 8B. 800 is generated, and if not, a correction request screen 800 without the warning area 820 shown in FIG. 8A is generated.

The consensus building unit 154 transmits the generated modification request screen 800 to the terminal 111 that requested the modification (S18).

Through the above processing, a new entry is added to the temporary update ledger 140 based on the information corrected in the progress information 601, and the correction request screen 800 is output to the terminal 111 that applies for correction.

Further, the consensus building unit 154 may make an additional application to the existing application content. Further, the automatic selection of the approval destination may be automatically presented by the consensus building unit 154 based on the content of the progress information 601 of FIG.

When the approval request button 806 on the correction request screen 800 is clicked on the terminal 111 (or the ledger co-management server 100) that proposes a correction, the consensus forming unit 154 of the ledger co-management server 100 causes the approval destination registration settings 801 and 802. , 804, 805, the approval application is transmitted to the ledger co-management server 100 of the company.

The approval application includes the application number 901, the target item 811 of the correction content, the pre-correction 812, and the post-correction 813.

Next, an example of processing performed by the approval unit 155 that approves the approval request will be described. When the approval application is notified from another terminal 111, the approval unit 155 generates the approval request screen 1000 and outputs it to the terminal 111 (or the output device 206).

FIG. 11 shows an example of the approval request screen 1000. The approval request screen 1000 includes an approval execution area 1100 and a correction content display area 1200 as shown in FIG. The approval execution area 1100 includes an application number 1101, a proposal source 1102, an approval status 1103, an action 1104, and a comment 1105 in one entry, and a selection switch 1110 is set in each entry.

A unique value in the block chain 104 assigned by the consensus building unit 154 is set to the application number 1101. In the proposal source 1102, the company name to which the ledger co-management server 100 that issued the approval application belongs is set. In the approval status 1103, the value of the approval target 905 of the temporary order ledger 141 is set.

In the action 1104, the button of the approval result selected by the user who operates the terminal 111 (or the ledger collaboration management server 100) is displayed. In the illustrated example, an approval button and a rejection button are displayed. When the approval button is clicked, the approval application is approved by the company of the terminal 111 (ledger joint management server 100), and the temporary order ledger 141 is updated. When the rejection button is clicked, the approval application is rejected by the company of the terminal 111, and the temporary order ledger 141 is updated.

Information input from the input device (or input device 204) of the terminal 111 is stored in the comment 1105, and is reflected in the comment 907 of the temporary order register 141.

Further, in the correction content display area 1200, the information of the approval application received by the ledger co-management server 100 is reflected, and the target item 1201 of the correction content, the pre-correction 1202 and the post-correction 1203 of the item are displayed. ..

The user of the terminal 111 (ledger co-management server 100) who approves selects the approval target selection switch 1110 and confirms the modification content of the modification target application number 1101. If there is no problem, the user finishes the approval work by clicking the approval button in action 1104. If there is a problem, you can reject the approval with the reject button. In the approval status 1103, the approval status of other companies can be viewed. You can also leave a comment for approval.

After accepting the approval (or refusal) instructed in the action 1104, the approval unit 155 writes the approval content in the approval record of the temporary update ledger 140 on the block chain 104. FIG. 12 shows an example of the approval record that the approval unit 155 writes in the temporary update ledger 140.

The approval record shown in FIG. 12 has the same format as the temporary update ledger 140 shown in FIG. The approval unit 155 writes the result of the action 1104 of FIG. 11 in the content of the approval target 905. Further, if the comment 1105 is described on the approval request screen 1000, the approval unit 155 reflects it in the comment 907 of the approval record on the temporary update ledger 140.

FIG. 13 is a flowchart showing an example of processing performed by the approval unit 155. This process is executed by the ledger collaboration management server 100 at a predetermined cycle.

The approval unit 155 first checks whether an approval application has arrived (S21), and if the approval application is received, presents the approval request screen 1000 shown in FIG. 11 on the screen of the terminal 111 (output device 206). (S22). After that, the user of the terminal 111 (ledger joint management server 100) confirms the correction content, and then selects approval or rejection in action 1104 of the approval execution area 1100.

When the approval unit 155 receives the approval result of approval or rejection (rejection), the approval unit 155 reflects the approval result in the approval record illustrated in FIG. 12 and writes it in the temporary update ledger 140 of the block chain 104.

Next, the processing performed by the updating unit 156 of the automatic execution program 105 will be described. The update unit 156 is activated when an event of writing to the temporary update ledger 140 on the block chain 104 executed by the approval unit 155 occurs.

FIG. 14 is a flowchart showing an example of processing performed by the updating unit 156. The update unit 156 acquires the application number 901 and the approval target 905 of the temporary update ledger 140 written in the block chain 104, and searches the approval record of the temporary update ledger 140 with the acquired application number 901 and approval target 905.

Then, the updating unit 156 determines whether or not all approval records issued by the approval target 905 corresponding to the application number 901 are complete (S31). That is, the update unit 156 determines whether the number of companies subject to approval 905 and the number of approval records corresponding to the application number 901 match.

The update unit 156 ends the process when all the approval records of the approval target 905 are not complete, and proceeds to step S32 when all the approval records are complete.

In step S32, the updating unit 156 reads all the approval records of the approval target 905, and determines whether the content of the approval target 905 satisfies the approval condition 906. If the approval condition 906 is satisfied, the process proceeds to step S33, and if not, the process proceeds to step S34.

In step S<b>33, since the consensus is formed on the approval target 905, the updating unit 156 reflects the correction content 904 of the temporary update ledger 140 in the order entry ledger 131 and the production management ledger 132. Furthermore, the updating unit 156 writes “approval completed” in the status 908 of the temporary update ledger 140 and ends the processing.

In step S34, since the agreement is rejected for the approval target 905, the update unit 156 does not reflect the correction content 904 of the temporary update ledger 140, writes “rejected” in the status 908 of the temporary update ledger 140, and executes the processing. finish.

When the order book 131 and the production control book 132 are synchronized with the ordering system database 121 and the production management system database 122 of each terminal 111, the ledger co-management server 100 causes the ordering system database 121 and the production management system database 122. The corrected contents may be written in.

The consensus building unit 154 can further display the content of each approval result. FIG. 15 shows an example of a screen showing a list of approval results.

The approval status display screen 1500 of FIG. 15 has almost the same configuration as the approval request screen 1000 shown in FIG. 11, but differs from FIG. 11 in that the items of the action 1104 are a confirmation button and a recorrection button. To do.

When the user of the terminal 111 confirms the approval content and clicks the confirmation button, it is not displayed on the approval status display screen 1500. On the other hand, if the application content is rejected, the application can be re-applied in consideration of the reason for refusal of the comment 1105.

In the present embodiment, the case of changing the order transaction on the supply chain is shown, but this is not necessarily the case. For example, by adding payment data, bill data, etc. to the data type, it can be utilized for changing the payment date and price negotiation.

As described above, according to the present embodiment, the ledger co-management server 100, which shares the ledger (the ordering ledger 131 and the production control ledger 132, the same applies hereinafter) that records the contents of the transaction, sets the ledger item (group key 502) and the item. By referring to the access right management ledger (approval group management ledger) 133 with the value (group information 503), the participant (business operator) who approves the correction content of the data is specified. As a result, it is possible to easily identify the participants to which the approval application should be sent when updating the ledger in the supply chain in which many companies cooperate.

When changing the data of the ledger, the ledger co-management server 100 can automatically select the participants to which the approval application should be sent from the access right management ledger 133, and the ledger can be corrected using the blockchain 104. The agreement can be realized by the participants (ledger joint management server 100) in the approval group.

In the access right management ledger 133 of the present embodiment, an example is shown in which the approval group configured by the affiliated company 504 is set by the company name, but the present invention is not limited to this, and the ledger that participates in distributed ledger management. The identifier or address of the joint management server 100 can be used.

Therefore, not all companies participating in the supply chain approve the correction content, but an approval group is formed among the companies that use the correction request data, so that the ledger co-management server 100 that requires approval Can only send approval requests to. This makes it possible to exclude unnecessary transactions from the block chain 104.

Further, according to the present embodiment, the ledger co-management server 100 causes the ledger joint management server 100 to make a revision request for the ledger data in the provisional update ledger 140 that accumulates the revision contents of the ledger and the approval history (904), and approves the revision request (905). ) Manage.

With this, when multiple participants try to modify the same data at the same time, each participant shares the modification contents with each other before approval, and issues the approval result (transaction) in consideration of each modification content. It becomes possible.

Further, the ledger co-management server 100 can set approval conditions (conditions for approval of correction contents) when issuing an approval application, and the approval result issued by the ledger co-management server 100 of the approval destination is approved. When the condition is satisfied (formation of agreement), the correction content can be reflected in the ledger.

On the other hand, when the approval result does not satisfy the approval condition, the ledger co-management server 100 writes “reject” in the status 908 of the temporary update ledger 140 and saves it. As a result, the temporary update ledger 140 can record the process from the correction request to the approval result of each participant.

Further, the ledger, which is the master of the data, is updated only with the correction contents for which the consensus of the participants has been formed, so that each participant can use the ledger as valid data. Note that the ledger co-management server 100 can apply the revised content to the data (ordering system 121 or production management system 122) that cooperates with the ledger after reflecting the amended correction content on the ledger.

<Summary>

As described above, in the distributed data management method described in the above embodiment, the server (ledger joint management server 100) having the processor (202), the memory (207), and the storage unit (205) storing the ledger is the ledger. In a block chain system (104) for managing (order ledger 131, production management ledger 132) in a distributed manner with other servers, the server (100) includes the ledger including an item (502) and an item value (503). The first step of receiving the correction content (904) for (131, 132), and the server (100) approving the correction content according to the item (502) and the value (503) of the item. The second step of determining the approval destination server (504) by referring to the approval group management information (access right management ledger 133) preset for the destination server (affiliated company 504).

As a result, it is possible to easily identify the participants to which the approval application should be transmitted when updating the ledger in the supply chain in which many companies cooperate.

A second step in which the server (100) writes the correction content (904) and the approval destination server (905) in the temporary update ledger (140), and the server (100) writes the correction content (604). (3) accepting the approval condition (906) for (4) and writing it in the provisional update ledger (140), and the server (100) sends an approval request including the correction content (904) to the approval destination server (504). And a fourth step of transmitting to.

Therefore, not all companies participating in the supply chain approve the correction content, but an approval group is formed among the companies that use the correction request data, so that the ledger co-management server 100 that requires approval Can only send approval requests to. This makes it possible to exclude unnecessary transactions from the block chain 104.

Then, when changing the data of the ledger, the ledger co-management server 100 can automatically select the participants to which the approval application is to be transmitted from the access right management ledger 133, and the ledger using the block chain 104 can be changed. The correction agreement can be realized by the participants (ledger joint management server 100) in the approval group.

A fifth step in which the server (100) receives an approval result from the approval destination server (504) and determines whether the approval result satisfies the approval condition (906); When the server (100) satisfies the approval condition (906), a sixth step of reflecting the correction content (904) in the ledger (131), 132 is further included.

Further, the ledger co-management server 100 can set approval conditions (conditions for approval of correction contents) when issuing an approval application, and the approval result issued by the ledger co-management server 100 of the approval destination is approved. When the condition is satisfied (formation of agreement), the correction content can be reflected in the ledger.

In the first step, the data related to the server (100) is extracted from the data of the ledger (131, 132), the progress information display screen (600) is output, and the progress information display screen is displayed. The modification to (600) is accepted as the modification content (904).

As a result, by extracting only the data of the supply chain related to the server (100) from the data of the ledger, it is possible to exclude the data that the server does not approve in (100).

Further, in the sixth step, when the ledger (131, 132) is linked with external data (121, 122), the correction content (904) is changed to the external data (121, 122). To reflect.

As a result, the ledger (131, 132) is updated only with the correction contents for which the consensus of the participants has been formed, so that each participant can use the ledger as valid data, and the external data (121 , 122) can also reflect the agreed correction content.

It should be noted that the present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments are described in detail in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the configurations described. Further, a part of the configuration of a certain embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of a certain embodiment. Further, with respect to a part of the configuration of each embodiment, any of addition, deletion, or replacement of other configurations can be applied alone or in combination.

Further, each of the above-described configurations, functions, processing units, processing means, and the like may be realized in hardware by designing a part or all of them with, for example, an integrated circuit. Further, each of the above-described configurations, functions, and the like may be realized by software by a processor interpreting and executing a program that realizes each function. Information such as a program, a table, and a file that realizes each function can be placed in a memory, a hard disk, a recording device such as an SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, and a DVD.

Further, the control lines and information lines are shown as being considered necessary for explanation, and not all the control lines and information lines in the product are necessarily shown. In practice, it may be considered that almost all configurations are connected to each other.

100 Ledger Joint Management Server 105 Automatic Execution Program 151 Data Combining Unit 152 Data Registration Unit 153 Data Collection Unit 154 Agreement Forming Unit 155 Approval Unit 156 Updating Unit 104 Block Chain 131 Order Ledger 132 Production Management Ledger 133 Access Right Management Ledger 140 Temporary Update Ledger 141 Temporary Order Ledger 142 Temporary Production Management Ledger 202 CPU
203 network interface 204 input device 205 storage device 206 output device 207 memory

Claims (10)

A distributed data management method of a block chain system, wherein a server having a processor, a memory, and a storage unit for storing a ledger is managed by distributing the ledger with other servers.
A first step in which the server accepts correction contents for the ledger including items and item values;
A second step in which the server determines an approval destination server by referring to approval group management information in which an approval destination server that approves the correction content is preset according to the item and the value of the item; ,
A distributed data management method comprising: The distributed data management method according to claim 1, wherein
A second step in which the server writes the correction content and the approval destination server in a temporary update ledger;
A third step in which the server accepts the approval condition for the correction content and writes it in the temporary update ledger;
A fourth step in which the server transmits an approval application including the correction content to the approval destination server;
A distributed data management method, further comprising: The distributed data management method according to claim 2, wherein
A fifth step in which the server receives an approval result from the approval destination server and determines whether the approval result satisfies the approval condition;
If the server satisfies the approval condition, a sixth step of reflecting the correction content on the ledger,
A distributed data management method, further comprising: The distributed data management method according to claim 1, wherein
The first step is
A distributed data management method comprising extracting data related to the server from the data of the ledger, outputting a progress information display screen, and accepting corrections to the progress information display screen as correction contents. The distributed data management method according to claim 3,
The sixth step is
A distributed data management method, wherein when the ledger is linked with external data, the correction content is reflected in the external data. A server having a processor, a memory, and a storage unit that stores a ledger is a distributed data management device of a block chain system that manages the ledger in a distributed manner with other servers,
The processor accepts corrections to the ledger including items and item values,
According to the item and the value of the item, the processor refers to approval group management information in which an approval destination server that approves the correction content is preset, and determines the approval destination server. Distributed data management device. The distributed data management device according to claim 6,
The processor writes the correction content and the approval destination server into a temporary update ledger,
The processor receives an approval condition for the correction content and writes it in the temporary update ledger,
The distributed data management device, wherein the processor transmits an approval application including the correction content to the approval destination server. The distributed data management device according to claim 7,
The processor receives an approval result from the approval destination server, determines whether or not the approval result satisfies the approval condition, and when the approval result satisfies the approval condition, the correction content is stored in the ledger. A distributed data management device characterized by being reflected in. The distributed data management device according to claim 8, wherein
The distributed data management device, wherein the processor extracts data related to the server from the data of the ledger, outputs a progress information display screen, and accepts corrections to the progress information display screen as correction contents. . The distributed data management device according to claim 8, wherein
The distributed data management device, wherein the processor reflects the correction content in the external data when the ledger is linked with external data.

Images