JP2021056943A - Data management system and data management method - Google Patents

Abstract

To provide a data management system and a data management method that can associate a series of files and store them in a referable manner while achieving both time required for approval and stability when recording the series of files on a block chain.SOLUTION: A data management system that associates a series of multiple files and stores them in a referable manner includes: reception means for receiving each of the multiple files; distribution recording means for distributing and recording the multiple files received by the reception means to a first block chain and a second block chain having different platforms; and storage means for associating and storing each hash value acquired from each block chain at the time of recording with specific information specifying each file.SELECTED DRAWING: Figure 1

Description

The present invention relates to a data management system and a data management method in which a series of a plurality of files are associated and stored for reference.

Traditionally, a series of business records have been filed and used in paper media in various business formats. For example, personal medical records at medical institutions, customer transaction records and transaction histories at financial institutions, and judicial precedents at legal institutions. In the case of contracts, contracts, and manufacturers, business records such as product authenticity certification are filed and stored in chronological order. Such business records are managed as a series of information for each time series so that they can be referred to later, and are used for reference and comparison of history on an individual or incident basis, and subsequent medical examinations, transactions, and authenticity judgments. It is useful for such things. In recent years, these business records and the like are converted into electronic data input by a computer or the like and stored as files in a storage medium such as a server by a centralized management method. In addition, contracts between companies and individuals have begun to shift from paper media to electronic contracts, and are stored in storage media such as servers as files converted into electronic data.

In recent years, there is a service that uses a distributed data management system such as a blockchain instead of storing and managing such electronic data files on a storage medium such as a server by a centralized management method. Due to its nature, blockchain has a high tamper-proof function and is suitable for storing the above-mentioned files that require strict reliability, and has been attracting attention in recent years. Taking the case of using blockchain for electronic contracts as an example, the contracts exchanged between the two parties are often reorganized in the process of confirmation work between the two parties, and multiple versions of the contracts created ( A series of multiple files) will be recorded on the blockchain (see, for example, Patent Document 1).

Re-table 2017/10455 (page 9, Fig. 1)

Blockchain is made up of a wide variety of platforms, each with its own strengths and weaknesses. For example, Ethereum, which is widely used by developers of services using blockchain, has the advantage of excellent network and operational stability due to the large number of users, but it also has the advantage of transaction approval mode and usage. Due to the large number of people, it takes time to approve the transaction, and the fee for approval is high. In addition, EOS, which is one of the blockchains, has the advantages that the approval time is short and the approval fee is low due to the transaction approval mode and the relatively small number of users. Therefore, there is a problem that the reliability of network and operation stability is lacking as compared with Ethereum. In this way, even if it is called a blockchain, the characteristics of each platform are different, and the service developer needs to be aware of the weaknesses and selectively select a series of files on the blockchain. It was not possible to achieve both the time required for approval when recording and the stability.

The present invention has been made by paying attention to such a problem, and refers to a series of files in association with each other while achieving both the time required for approval when recording a series of files on the blockchain and the stability. An object of the present invention is to provide a data management system and a data management method that can be stored in a possible manner.

In order to solve the above problems, the data management system of the present invention
A data management system that associates a series of multiple files and stores them for reference.
A reception means that accepts each of multiple files,
A distribution recording means for distributing and recording a plurality of files received by the reception means to the first blockchain and the second blockchain having different platforms.
A storage means that stores each hash value acquired at the time of recording from each blockchain in association with specific information that identifies each file, and
It is characterized by having.
According to this feature, the data management system is configured to distribute and record multiple received files to multiple blockchains as needed, so for example, the final version of the file is a platform with excellent network and operational stability. It is possible to record in the second blockchain of the platform, and to record the other process version files in the first blockchain of the platform, which has the advantages of short approval time and low approval fee, and blockchain. A series of files can be associated and stored for reference while balancing the time and stability required for approval when recording a file on top.

It is characterized in that it includes a setting means for setting a distribution condition for distributing a plurality of files in the distribution recording means to each blockchain.
According to this feature, the distribution conditions can be arbitrarily set by the setting means, so that, for example, only the final version of the file is distributed and recorded on the blockchain of the first platform, which is excellent in network and operation stability. Other files can be set and recorded in the second blockchain of the platform, which has the advantages of short approval time and low approval fee, depending on the situation. Sorting conditions can be set.

The distribution recording means is characterized in that, as a distribution condition, a file received by the reception means is distributed to the second blockchain based on the reception of a predetermined instruction from the user.
According to this feature, based on the acceptance of a predetermined instruction, the recording destination of the file is automatically determined and sorted according to the sorting conditions, so that human error can be prevented and the file is surely placed on the desired blockchain. The file can be recorded, and the time and stability required for approval at the time of recording can be compatible. Further, since the file when the predetermined instruction is received is uniformly recorded on the blockchain of the predetermined second platform, the data management becomes easy when the file is referred to later.

As a distribution condition, the distribution recording means is characterized in that, when a predetermined instruction is received, the file received by the reception means is recorded in the first blockchain in addition to the second blockchain. ..
According to this feature, since the file when a predetermined instruction is received is recorded on both the first blockchain and the second blockchain, there is less risk of loss due to the corruption of the file and access at the time of reference. Multiple destinations can be selected.

The plurality of files include a contract file of a process version and a contract of a final version file.
The distribution recording means is characterized in that the process version of the contract file is distributed to the first blockchain and the final version of the contract file is distributed to the second blockchain for recording.
According to this feature, the contents of clauses etc. are examined by multiple persons in charge of the contract file, and multiple editions are often formed by the time the final version is reached. Records on the blockchain of the platform, which has the advantages of short approval time and low approval fee, and records only the final contract file on the blockchain of the platform with excellent network and operation stability. By doing so, it is easy to achieve both the time required for approval and the stability.

When a web page is provided that allows a user to access and refer to the plurality of files and approve one of the plurality of files, and the file is recorded on the blockchain, the file is recorded. It is characterized by including a service server that displays a hash value returned from the blockchain on the web page.
According to this feature, the user can confirm that the recording of the file on the blockchain is completed, and the reliability of the data management system can be improved.

In order to solve the above problems, the data management method of the present invention
A data management method that associates a series of multiple files and stores them for reference.
Steps to accept each of multiple files,
A step to distribute and record multiple received files to the first blockchain and the second blockchain with different platforms,
A step to store each hash value obtained at the time of recording from each blockchain in association with specific information that identifies each file, and
It is characterized by having.
According to this feature, the data management system distributes multiple received files to multiple blockchains as needed, for example, the final version of the file to be a blockchain for a platform with excellent network and operational stability. When recording files on the blockchain, it is possible to record and record the other process version of the certification data on the blockchain of the platform, which has the advantages of short approval time and low approval fee. A series of files can be associated and stored for reference while achieving both the time required for approval and stability.

It is a conceptual diagram which shows the network which comprises the data management system and the data management method in the Example of this invention. It is a figure which shows the initial screen displayed on a personal computer. It is also a diagram showing a user page. Similarly, it is a figure which shows the contract creation screen. It is also a figure which shows the text input display displayed on the contract creation screen. Similarly, it is a figure which shows the encryption key input screen. It is also a figure which shows the encryption completion display displayed on the contract creation screen. Similarly, it is a figure which shows the contract participant addition screen. Similarly, it is a figure which shows the contract participant listed in the contract participant addition screen. Similarly, it is a diagram showing the progress of recording on the EOS blockchain, (a) is a diagram showing a pop-up display showing the progress of recording, and (b) is a diagram showing a state in which recording is completed. It is a figure which shows the invitation mail received by a contract participant. It is a figure which shows the access code confirmation screen displayed on the personal computer. Similarly, it is a diagram showing a display prompting the input of the encryption key displayed on the contract confirmation screen for contract participants in the company. Similarly, it is a diagram showing a state in which the text data of the contract file is displayed on the contract confirmation screen for contract participants in the company. Similarly, it is a figure which shows the contract confirmation screen for the contract participant of the other party. Similarly, it is a figure which shows the state which the list display of a plurality of created contract files is displayed on the contract confirmation screen for the contract participant of the other party. Similarly, it is a figure which shows the contract confirmation request screen. It is also a diagram showing a contract approval screen for contract participants in the company. Similarly, it is a figure which shows the contract approval screen for the contract participant of the other party. It is also a diagram showing the progress of recording on the Ethereum blockchain. It is a figure which shows the conclusion completion display which is displayed on the contract confirmation screen for the contract participant in the company who is also a person in charge. It is a flowchart which shows the contract confirmation process. It is a flowchart which shows the contract approval process. It is a flowchart which shows the final version recording process.

A mode for implementing the data management system and the data management method according to the present invention will be described below based on examples.

The data management system and the data management method according to the embodiment will be described with reference to FIGS. 1 to 24.

Data management systems are used for communication between service providers and recipients in various business categories, such as personal medical records at medical institutions, customer transaction records and transaction histories at financial institutions, and precedents and wills at legal institutions. This is a system in which management materials such as contract documents related to legal affairs such as real estate transactions and proof of authenticity of products by manufacturers are converted into electronic data and managed by a server so that they can be referred to later. In this embodiment, the management of contract documents will be described as an example. In the data management system of this embodiment, a client (hereinafter, also referred to as “in-house”) who is the main body of creating contract documents and a client of the other party of the contract based on the contract documents (hereinafter, referred to as “other party”) The contract file can be updated as appropriate via the API server 7 of the service server 1 described later. At that time, the process version of the contract file and the final version of the contract file to be finally concluded are divided into a first blockchain (for example, EOS) and a second blockchain (for example, Ethereum) having different platforms. By storing each hash value that is recorded and acquired from each blockchain at the time of recording in association with specific information that identifies each contract file, it is stored and managed as a series of contract files. For example, in-house, the person in charge prepares a draft contract, stores it as the first edition of the created contract, and then the boss in the company browses the first edition of the contract, and if necessary. The revised version is saved each time, and the contract approved by the boss is saved as the approved version. In addition, the person in charge of the other party or the boss also corrects and stores the revised version each time, and then the contract approved by the boss is stored as the approved version. The contract files up to this point are stored in the first blockchain (for example, EOS), and when the prescribed instructions are finally received by both parties, the final version of the contract becomes the second blockchain (for example, Ethereum). ) Is stored.

FIG. 1 shows a system and a network for realizing an embodiment of the data management system of the present invention, where reference numeral 1 is a service server for a management company (administrator) to provide a data management system, and reference numeral 2 is a reference numeral 2. Is a client and a personal computer as an output means (hereinafter abbreviated as "personal computer"), which are connected to each other via the Internet so as to be able to communicate with each other. A scanner 3, a keyboard 4, a mouse 5, and the like as input means are connected to the personal computer 2, respectively. In addition, a pen tablet and a stylus pen can be used as input means.

The service server 1 is configured by connecting an API (Application Program Interface) server 7, a user management server 8, and a processing server 9 via a network, and receives a file related to contract documents from a personal computer 2 on the client side. Manage files. Further, the service server 1 is configured to record files related to contract documents to a plurality of computer groups 20, 21, 22 which are the operating environment of the blockchain platform and the operating environment of the distributed file system, which will be described later. There is.

Of the plurality of computer groups 20, 21 and 22, which are the operating environment of the blockchain platform and the operating environment of the distributed file system, the computer group 20 serves as a distributed server constituting a distributed file system called IPFS (Inter Planetary File System). Node. The computer group 21 is a plurality of nodes that generate blocks of a blockchain of a platform called EOS, and is also a node as a distributed server that constitutes a distributed file system. The computer group 22 is a plurality of nodes that generate blocks of a blockchain of a platform called Ethereum, and is also a node as a distributed server that constitutes a distributed file system.

The API server 7 is a server operated by a management company that provides a data management system, and performs data format conversion and the like necessary for storing files related to contract documents received from the client-side personal computer 2 on the blockchain. A server on the Internet that provides APIs to perform. The API is implemented on the API server 7 and operates on a web browser started on the personal computer 2 on the client side.

A user who uses a data management system registers a unique user ID (user identification information) and a password in advance on a homepage published by a data management system management company. The user management server 8 includes a correspondence table that holds a correspondence relationship between the user ID and password entered on the home page and the link information to the blockchain assigned to the user of the user ID.

When a user inputs input data into a data management system, he / she first accesses a homepage published by a management company using a web browser started on a personal computer 2. As shown in FIG. 2, the user ID input field 11, the password input field 12, and the login button 13 are displayed on the initial screen 10 of the home page, and the user ID and password are displayed for the accessing user. You will be asked to enter.

The user inputs in the input field 11 of the user ID and the input field 12 of the password, and selects the login button 13. When the login button 13 is selected, the entered user ID and password are sent to the user management server 8 (see FIG. 1), and the combination of the entered user ID and password is correct by referring to the corresponding table. Based on the fact that it can be determined, the user page 14 shown in FIG. 3 is displayed.

The user page 14 involves a template display 15 that calls a template function for registering and editing a template that can be used for contract creation, a contract creation display 17 that calls a function for creating a contract file, and a logged-in user. A list display 18, a notification icon 19, etc. that call a function for confirming a contract file that is or is continuously involved are displayed. For example, when the template display 15 is selected, the text data templates of a plurality of contract files registered in advance can be called.

The number of unconfirmed notification messages is superimposed on the notification icon 19, and by selecting this notification icon 19, the contract file in which the logged-in user is continuously involved. A notification window 19a is displayed so that the actions of a plurality of persons in charge related to the service and notifications from the service management side can be confirmed.

When the contract creation display 17 that calls the function for creating the contract file is selected, the contract creation screen 25 is displayed on the personal computer 2 used by the user, as shown in FIG. On the contract creation screen 25, first, the preamble input display 25a shown in FIG. 4 is displayed. In the preamble input display 25a, an input form 26 for inputting the contract name, an input form 27 for inputting a tag attached to the contract file, and an input confirmation button 28 are displayed. When the input is completed and the input confirmation button 28 is selected, the text input display 25b shown in FIG. 5 is displayed.

In the text input display 25b, a pull-down display 29 for selecting a folder name, an editor 30 for inputting the text data of the contract file, an attachment registration button 31 for uploading an attachment, and a template import for calling a template. Button 32, status display 33, and input confirmation button 34 are displayed.

When inputting the text data text of the contract file in the editor 30, the user can use the template function of the text data of a plurality of contract files called by selecting the template display 15, and the template import button. By selecting 32, it is possible to omit a part of the text data input by calling one template from the text data templates of a plurality of contract files. In addition, by selecting the attachment file registration button 31, it is possible to upload photos, videos, sounds, etc. that constitute the contract file together with the text data.

The editor 30 includes a preview button 35 and a temporary save button 36. In the editor 30, the text is displayed in XML format, but in the data management system, the final output is displayed in PDF format. Therefore, by selecting the preview button 35, the text data of the contract file being created can be confirmed in a form close to the actual output format.

When the input of the text data of the contract file is completed in the editor 30 by the user and the input confirmation button 34 is selected, the input text data and the attached file uploaded by the attached file registration button 31 are present. It is accepted as a contract file together with the attached file (reception means), and the contract file is associated with the specific information (user ID in this case) that identifies the user and stored in the service server 1. Further, the service server 1 moves to the process of recording the input contents based on the acceptance of the contract file. When the input confirmation button 34 is selected, the encryption key input screen 37 shown in FIG. 6 is displayed.

In the status display 33 shown in FIG. 5, the actions performed on the contract file are displayed in chronological order. For example, it is displayed that the creation of the contract has started, the input of the preamble has been completed, and the like.

The encryption key input screen 37 shown in FIG. 6 is a screen for setting an encryption key to be given to encrypt the contract and decrypt it at the time of viewing, and the input form 38 for inputting the encryption key and the encryption. The encryption button 39, which determines the above, is displayed.

When the encryption key is input to the input form 38, the encryption button 39 is selected, and the confirmation button of the confirmation pop-up is selected, the encryption completion display 25c shown in FIG. 7 is displayed. On the encryption completion display 25c, a text indicating that the encryption is completed is displayed, and the contents input to the preamble input display 25a and the text input display 25b are displayed. Further, a contract participant addition button 40 is displayed at the bottom of the encryption completion display 25c.

When the contract participant addition button 40 is selected, the screen is switched from the contract creation screen 25 to the contract participant addition screen 41 shown in FIG.

As shown in FIG. 8, the contract participant addition screen 41 displays the contract name, contract tag, folder name, etc. entered on the contract creation screen 25, and the contract participant addition area 42 is displayed. Is displayed. In the contract participant addition area 42, a pull-down display 42a that allows the user to select whether the contract participant to be added is "in-house" or "other party", and the roles of the contract participant are "person in charge", "approver", and "approver". A pull-down display 42b that can be selected as one of "confirmers", an input form 42c that allows input of the contract participant's e-mail address, and an add button 42d are displayed. In addition to directly inputting the e-mail address in the input form 42c, if the contact information is registered in advance, the e-mail address is automatically input by inputting the name.

When the input in the contract participant addition area 42 is completed and the add button 42d is selected, the added contract participants are listed as shown in FIG. In the list display of contract participants, a name input form 44, an input e-mail address, an input form 45 for inputting an access code, and an access code generation button 46 are displayed. The access code can be arbitrarily set by the user, and when the generation button 46 is selected, the access code required when the contract participant confirms the contract, which will be described later, is generated, and information that identifies the contract participant (information that identifies the contract participant ( For example, it is linked to an e-mail address and stored in the service server 1.

Check boxes 47 are displayed in the list of added contract participants, and when the mail transmission button 48 is selected with any check box 47 checked, the check box 47 is checked. An invitation email (see FIG. 11) is sent to the email address of the contract participant.

Further, a record button 49 to the blockchain is displayed below the list display of the added contract participants, and when this record button 49 is selected, the contract created on the contract creation screen 25 is displayed. The file is uploaded and recorded on the EOS blockchain (computer group 21 (see FIG. 1) constituting the EOS network) (distribution recording means). As shown in FIG. 10A, a pop-up display 50a indicating the progress of recording is displayed by animation, and when the recording is completed, a word indicating that the recording is completed on the blockchain and a word indicating that the recording is completed are returned from the blockchain. The hash value is shown in the pop-up display 50b (see FIG. 10B).

Further, the service server 1 distributes the added contract participant information to the specific information indicating the contract file (here, the contract filed) based on the selection of the record button 49. It is stored in association with a unique ID) (storage means).

Next, the electronic contract process performed by the service server 1 will be described with reference to the flowcharts of FIGS. 22 to 24. FIG. 22 is a flowchart showing a contract confirmation process in which a “person in charge” and a “confirmer” confirm the contract in the contract participant. In addition, the case where the contract participant in the company who exchanges the contract is registered as a user in the service of the data management system and the contract participant of the other party is not registered as a user will be described as an example.

As described above, the “person in charge (user)” who is an in-house contract participant enters the user ID and password on the initial screen 10 of the homepage shown in FIG. 2 to log in (step Sa01). Then, a contract file is created on the contract creation screen 25 shown in FIG. 5 (step Sa02). When the service server 1 has an attached file or the like excluding the text data in the contract file, the service server 1 extracts the attached file or the like excluding the text data of the contract and extracts the text data of the contract with the encryption key shown in FIG. It is encrypted with the encryption key set on the input screen 37 (step Sa03).

The service server 1 uploads the attached files and the like excluding the extracted contract text data onto the distributed file system (computer group 20 (see FIG. 1) constituting the IPFS network) of the IPFS platform (step Sa04). .. The service server 1 temporarily holds the hash value returned from the IPFS distributed file system, and together with this hash value and the text data which is the XML of the encrypted contract file, the blockchain of the EOS platform ( It is uploaded and recorded on the computer group 21 (see FIG. 1) that constitutes the EOS network (distribution recording means, step Sa05). Then, the service server 1 stores the hash value returned from the EOS blockchain (hereinafter referred to as "EOS hash value") in association with the unique ID assigned to the proposed contract (storage means).

The service server 1 can accept a confirmation request for the contract file from the user based on the hash value returned from the EOS blockchain 21. Specifically, when the user performs an operation of sending an invitation e-mail to the e-mail address of the contract participant on the contract participant addition screen 41 shown in FIG. 8, the service server 1 requests confirmation of the contract file. It is determined that the contract has been submitted, and an invitation email 51 (see FIG. 11) is sent to the email addresses of the "person in charge" and the "confirmer" of the added contract participants to request confirmation of the contract (step Sa06). In addition to the invitation e-mail 51, the service server 1 separately sends an e-mail containing the access code entered on the contract participant addition screen 41.

As shown in FIG. 11, in the invitation mail 51, the EOS block in which the created contract is recorded in addition to the contract name requested for confirmation, the invitee, the invited contract participant, and the contract conclusion deadline. The hash value 52 of the chain is described. Further, in the invitation mail 51, a contract confirmation button 53 linked to the web page of the electronic contract provided by the service server 1 that can confirm the contract requested to be confirmed is displayed.

When the invited contract participant selects the contract confirmation button 53 and accesses the web page of the electronic contract provided by the service server 1, the service server 1 displays the access PC 2 in FIG. The displayed access code confirmation screen 54 is displayed. On the access code confirmation screen 54, a display 55 indicating that a confirmation request for the contract file has been made to the person who received the e-mail, an input form 56 for inputting the access code, and an access for transmitting the input access code. It is equipped with a code confirmation button 57. The contract participant enters the separately sent access code in the input form 56 and selects the access code confirmation button 57.

The service server 1 determines whether or not the input access code is correct based on the selection of the access code confirmation button 57 (step Sa07). If the access code is correct, the contract confirmation screen 58 shown in FIG. 13 is displayed. The contract confirmation screen 58 in FIG. 13 is a screen for contract participants in the company. On the contract confirmation screen 58, the contract name, the contract tag, the folder name, the contract version, the hash value of the EOS blockchain in which the contract file is recorded, and the like are displayed. At this time, the service server 1 downloads and holds the files constituting the contract file from the EOS blockchain and IPFS.

Further, on the contract confirmation screen 58, a display 59 prompting the input of the encryption key that encrypts the contract file is displayed. The display 59 includes an input form 60 for inputting an encryption key and a release button 61 for transmitting the input encryption key. The encryption key can be notified to the contract participant by various methods, but here, it is assumed that the service server 1 sends the invitation mail 51 and the mail containing the access code to the contract participant separately.

The service server 1 determines whether or not the encryption key input when the release button 61 is selected is correct (step Sa08). Specifically, an attempt is made to decrypt the downloaded contract using the encryption key, and if successful, the text data 62 of the decrypted contract file is displayed on the contract confirmation screen 58 as shown in FIG. Display it so that it can be viewed (step Sa09).

On the contract confirmation screen 58, in addition to the text data 62 of the decrypted contract file, a status display 63 and a confirmation button 64 for confirming the decrypted attached file are displayed. The contract participant can confirm the attached file by selecting the confirmation button 64.

Below the text data 62 of the contract file, a download button 65 that can download the contract in PDF format, an edit button 66 that calls the contract editing function, and an add button 67 that calls the function to add more contract participants are displayed. Will be done.

Further, the contract confirmation screen 70 of FIG. 15 is a screen for the contract participant of the other party, and unlike the contract confirmation screen 58 for the contract participant in the company, the contract tag and the contract folder are not displayed. The text data 72 of the decrypted contract file, the confirmation button 71 for confirming the attached file, the status display 73, and the comment button 74 are displayed.

By selecting the comment button 74, the contract participant can input a comment such as a correction request for the confirmed contract, and this comment is displayed on the contract confirmation screens 58 and 70 of all contract participants. Can be viewed. When a comment such as a correction request is actually input (step Sa10), the service server 1 notifies the user in the company that there is a comment by e-mail or notification (notification icon 19 in FIG. 4) (notification means). , Step Sa11).

The user in the company modifies the contents of the contract file if necessary (step Sa12). The modified contract is encrypted by the encryption key set on the encryption key input screen 37 shown in FIG. 7 (step Sa03), and each time the contract file is modified, the processing after step Sa03 is performed. Is repeated, the modified contract file is recorded as a new version on the EOS blockchain, and the EOS hash value is linked to the unique ID assigned to the proposed contract along with the version numbering. It is attached and stored as a series of contract files (storage means).

When the contract version display 75 on the contract confirmation screen 70 is selected with reference to FIG. 16, a list display 76 of a plurality of contract files created up to that point is displayed. A comparison button 77 is provided in the list display 76, and when the comparison button 77 is selected, the comparison between the latest contract file at that time and the previous contract file can be displayed on one screen. It is easy to check the corrected part.

As shown in FIG. 15, an action button 80 for the confirmed contract is displayed at the lower part of the contract confirmation screen 70. The action button 80 is displayed differently depending on the roles of the contract participant, that is, the “person in charge”, the “approver”, and the “confirmer” (see FIG. 8). Specifically, if it is the "person in charge", it is "approval request", if it is "confirmer", it is "contract confirmation", and if it is "approver", it is "contract approval".

When the action button 80 of the "approval request" is selected by the "person in charge", the service server 1 determines that the confirmation of the contract participant who is the "person in charge" has been completed, and submits the person in charge confirmation completion information. It is stored as a series of contract files linked to the unique ID assigned to the contract. When the action button 80 of "contract confirmation" is selected by the "confirmer", the service server 1 is shown in FIG. 17 from the contract confirmation screens 58 and 70 viewed by the contract participant who is the "confirmer". Switch to the contract confirmation request screen 78.

On the contract confirmation request screen 78, a preview 79 of the text data of the contract file and a confirmation completion button 81 for transmitting the completion of the contract confirmation to the service server 1 are displayed. A comment button 79a for inputting a comment is displayed on the preview 79, and the comment can be transmitted to other contract participants. Further, when the confirmation completion button 81 is selected by the "confirmer", the service server 1 determines that the confirmation of the contract participant who is the "confirmer" has been completed, and provides the contract confirmation information to the proposed contract. It is stored as a series of contract files linked to the unique ID assigned to the document.

In the service server 1, the action button 80 of "approval request" is selected by the "person in charge" of the contract participant in the company, and the confirmation completion button 81 is selected by the "confirmer" of the contract participant in the company. In addition, the action button 80 of "approval request" was selected by the "person in charge" of the contract participant of the other party, and the confirmation completion button 81 was selected by the "confirmer" of the contract participant of the other party. , The contract approval process proceeds based on the fact that all the conditions that the contract participant did not input a comment such as a correction request (step Sa10) were satisfied on the contract confirmation screens 58 and 70. The contract approval process is shown in the flowchart of FIG.

When the contract approval process starts, the service server is in a state of waiting for the completion of approval of the "approver" in the company. Then, when the action button 80 of "contract approval" is selected by the "approver" in the company, the service server 1 is the contract confirmation screen 58 (FIG. 14) viewed by the contract participant who is the "approver". (See), the screen is switched to the contract approval screen 82 shown in FIG. 18, and the “approver” in the company is requested to approve the contract (step Sb01). Similarly, when the action button 80 of "contract approval" is selected by the "approver" of the other party, the service server 1 displays the contract approval screen 86 shown in FIG. 19 on the personal computer 2 of the other "approver". Display it.

The contract approval screen 82 shown in FIG. 18 is a screen for the “approver” of the contract participants in the company. On the contract approval screen 82, a preview 79 of the text data of the contract file, a signature area 83, a seal area 84, and an approval completion button 85 for transmitting the completion of the contract approval to the service server 1 are displayed.

The contract participant who is the “approver” inputs the signature image data in the signature area 83, inputs the seal image data in the seal area 84, and selects the approval completion button 85. The signature image data and the seal image data are registered in the service server 1 in advance by the upload function which is not described in detail here.

Similarly, when the action button 80 of "contract approval" is selected by the "approver" of the other party, the service server 1 displays the contract approval screen 86 shown in FIG. Request approval of the contract (step Sb02).

The contract approval screen 86 of FIG. 19 is a screen for the “approver” of the other contract participant. On the contract approval screen 86, a preview 79 of the text data of the contract file, a signature area 87, a seal area 88, and an approval completion button 89 for transmitting the completion of the contract approval to the service server 1 are displayed.

Here, the service server 1 determines whether or not a comment such as a correction request has been input from the "approver" in the company (step Sb03), and there is no comment such as a correction request input in the company. When the approval completion button 85 is selected by the "approver" (step Sb05), the service server 1 determines that the approval of the contract participant who is the "approver" has been completed, and the contract within the company. The approval information is linked to the unique ID assigned to the submitted contract and stored as a series of contract files.

Similarly, the service server 1 determines whether or not a comment such as a correction request has been input from the other party's "approver" (step Sb04), has not input a comment such as a correction request, and has not entered a comment such as a correction request, and the other party's "approver" When the approval completion button 89 is selected (step Sb06), the contract approval information of the other party is linked to the unique ID assigned to the proposed contract as a series of contract files. store.

The service server 1 determines that the approval of both companies has been obtained and the approval has been completed by the selection of the approval completion button 85 by the "approver" in the company and the selection of the approval completion button 89 by the "approver" of the other party. , The approval completion information is linked to the unique ID assigned to the submitted contract and stored as a series of contract files.

When the service server 1 determines that the approvals of both companies have been completed (accepted the predetermined instruction) (step Sb07), the service server 1 moves to the final version recording process. In the final version recording process, the contract participant who is the "person in charge" in the company is first notified. The “person in charge” displays the contract confirmation screen 58 (FIG. 14) from the notification window 19a (FIG. 3) on the user page 14. Although not shown here, the final version recording process is started when the person in charge selects the recording start button displayed on the contract confirmation screen 58. In step Sb07, an example in which selection by the person in charge is required is described, but when steps Sb05 and Sb06 are yes, it is determined that both parties have approved the selection, and the notification to the person in charge is omitted. Then, the process may shift to the final version recording process shown in FIG. 24.

FIG. 24 is a flowchart showing the final version recording process started when the recording start button is selected on the service server 1 side. When the final version recording process is started, the service server 1 composes the contract file of the latest version and the approved version from the EOS blockchain and IPFS based on the EOS hash value. Download the file (step Sc01) and then get the time stamp (step Sc02).

The service server 1 encrypts the downloaded contract text data with the encryption key set on the encryption key input screen 37 shown in FIG. 6 (step Sc03), and further removes the contract text data. The file, the signature image data, and the seal image data are uploaded onto the distributed file system of the IPFS platform (computer group 20 (see FIG. 1) constituting the IPFS network) (step Sc04).

The service server 1 temporarily holds the hash value returned from the IPFS distributed file system, and the text data that is the XML of this hash value and the encrypted contract file, and the EOS hash of the approved version. The value and the obtained time stamp are combined and uploaded and recorded on the blockchain of the platform called Ethereum (computer group 22 (see FIG. 1) constituting the Ethereum network) (distribution recording means, step Sc05). .. The user who is the "person in charge" in the company can confirm the progress status when recording on the blockchain 22 of Ethereum on the recording progress screen 90 shown in FIG. The service server 1 stores the hash value returned from the Ethereum blockchain 22 (hereinafter referred to as "Ethereum hash value") in association with the unique ID assigned to the proposed contract (storage means). ..

Based on the receipt of the Ethereum hash value, the service server 1 determines that the conclusion of the contract has been completed (step Sc06), and displays the conclusion completion display 92 shown in FIG. 21 as the contract of the "person in charge" in the company. It is displayed on the document confirmation screen 58.

The Ethereum hash value 93 is displayed on the conclusion completion display 92, and the EOS hash value 94 is also written below the conclusion completion display 92 for the contract file of the approved version.

Further, here, the conclusion completion display 92 shown in FIG. 21 is a screen for the “person in charge” in the company, but the content displayed on the conclusion completion display 92 participates in the proposed contract. All the contract participants who have made the contract can view it when they access the electronic contract provided by the service server 1. Then, the contract participant who participated in the proposed contract can later view the contract file of the process version before the completion of approval by selecting the version display 95 displayed on the conclusion completion display 92. it can. In addition, although not shown here, since the EOS hash value is displayed in association with the contract file of the process version before the completion of approval, it is certain that the contract participant is the contract file of the process version. You can browse the contents after making a judgment.

As described above, the data management system of the present invention has a configuration in which a plurality of contract files received from the user are distributed and recorded in a plurality of blockchains 21 and 22 as needed, and the final version in the above embodiment is used. The contract file is recorded on the blockchain 22 of Ethereum, which is a platform with excellent network and operational stability, and the other process version contract files have the advantages of short approval time and low approval fee. It is possible to record on the blockchain 21 of EOS, which is a platform equipped with, and it is possible to associate and refer to a series of contract files while achieving both the time and stability required for approval when recording a file on the blockchain. Can be stored.

Further, the service server 1 is configured to change the recording destination from the EOS blockchain 21 to the Ethereum blockchain 22 based on the acceptance of the approval information by the approver, and automatically sets the recording destination of the contract file according to the distribution conditions. Since human error can be prevented, the contract file can be reliably distributed and recorded on the desired blockchain, and the time and stability required for approval at the time of recording can be obtained. Can be compatible. Further, since the file when the predetermined instruction is received is uniformly recorded on the blockchain 22 of the predetermined Ethereum, data management becomes easy when the file is referred to later.

Further, the distribution recording means of the service server 1 records the accepted contract file in the Ethereum blockchain 22 in addition to the EOS blockchain 21 based on the acceptance information by the approver as the distribution condition. .. According to this, the contract file (the final version contract file in the above embodiment) when the approval information by the approver is received is recorded in both the EOS blockchain 21 and the Ethereum blockchain 22. There is little risk of loss due to damage to the contract file, and multiple access destinations can be selected for reference.

Further, the distribution recording means of the service server 1 distributes the process version contract file to the EOS blockchain 21 and distributes the final version contract file to the Ethereum blockchain 22 for recording. According to this, the contents of clauses etc. are examined by multiple persons in charge of the contract file, and multiple editions are often formed by the time the final version is reached. The platform EOS blockchain 21 has the advantages of short approval time and low approval fee, and only the final contract file is recorded on the platform Ethereum, which has excellent network and operational stability. By recording on the blockchain 22, it is easy to achieve both the time required for approval and the stability.

Further, when the contract file is recorded on the blockchain 21 of EOS or the blockchain 22 of Ethereum, the hash value returned from the blockchain is displayed on the web page provided by the service server 1, so that the user himself / herself Can confirm that the recording of the file on the blockchain is completed, and the reliability of the data management system can be improved.

Although examples of the present invention have been described above with reference to the drawings, the specific configuration is not limited to these examples, and any changes or additions within the scope of the gist of the present invention are included in the present invention. Is done.

For example, in the above-described embodiment, the service server 1 gives the predetermined instruction that the contract approval information for approving the contract by the "approver" is obtained from both the company and the other party. Based on this, the distribution condition is that the final version of the contract file is recorded on the Ethereum blockchain 22, and if there is no prescribed instruction, the previous process version of the contract file is recorded on the EOS blockchain 21. However, this distribution condition may be appropriately set (setting means) by the service administrator. For example, the version of the contract file at the time of confirmation by the "confirmer" and the final version of the contract at the time of approval by the "approver" are recorded on the Ethereum blockchain 22, and the others are recorded. By setting the distribution conditions such as recording on the EOS blockchain 21, all the contract files of the highly important version may be recorded on the highly reliable blockchain, and other conditions may be met. Optimal distribution conditions can be set.

In addition, regarding the mode of dividing the contract file into two blockchains and recording it, it is prescribed that the contract approval information that approved the contract by the "approver" was obtained from both the company and the other party. The instruction is not limited to the acceptance, and for example, the administrator may make an appropriate judgment and distribute the instruction.

Further, the blockchain platform for distributing and recording the contract file is not limited to two types, and may be a plurality of three or more types.

Further, in the above embodiment, the blockchain for sorting and recording the contract file is a network of the EOS blockchain as a typical platform having the advantages of short approval time and low approval fee. Ethereum was selected as a platform with excellent operational stability, but it is not limited to this, and any platform with the same contrasting relationship does not have to be a blockchain of these platforms. Not to mention.

In addition, the EOS hash value of the approved version does not have to be recorded in the Ethereum blockchain.

Further, in the above embodiment, the case where the data management system is used for the electronic contract has been described as an example, but the present invention is not limited to this, for example, personal medical records at medical institutions, customer transaction records and transaction histories at financial institutions, and the like. It can be effectively used in a scene where management materials that require reliability of contents, such as proof of product authenticity at a manufacturer, are stored in a series associated with each time series.

Further, in the above embodiment, the image data is stored using IPFS, which is a distributed file system, but the present invention is not limited to this, and for example, in a storage environment other than the blockchain for storing text data, the image data is distributed. It is not necessary to use a file system, and it may be stored on a server, a local server, or the like. In addition, since the signature image data and the seal image data are not large in capacity, the step of using IPFS may be omitted and the signature image data and the seal image data may be directly stored in the Ethereum blockchain 22 together with the document data of the contract. Further, in the case of a file having a small capacity, the step of using IPFS may be omitted and the file may be stored directly in the blockchain 21 of EOS or the blockchain 22 of Ethereum.

Further, although the blockchains of the two platforms in the above embodiment have been described in the specifications of the public chain, they are so-called private chains that operate in an environment on a plurality of computers constituting the service server 1 provided by the management company. May be good.

Further, the API server 7 provided with the API constituting the service server 1 provided by the management company, the user management server 8 provided with the corresponding table, and the processing server 9 are composed of one computer having their respective functions. You may.

Further, the client-side terminal used by the user is not limited to a personal computer, but may be a tablet or a smartphone.

1 Service server 2 PC 7 API server 8 User management server 9 Processing server 10 Initial screen 14 User page 19 Notification icon 19a Notification window 20, 21, 22, Computer group 25 Contract creation screen 30 Editor 33 Status display 37 Encryption key input Screen 41 Contract participant addition screen 46 Generate button 48 Email send button 49 Record button 51 Invitation email 52 EOS hash value 54 Access code confirmation screen 58, 70 Contract confirmation screen 74 Comment button 75 Contract version display 76 List display 78 Contract Confirmation request screen 80 Action button 81 Confirmation completion button 82,86 Contract approval screen 83,87 Signature area 84,88 Seal area 85,89 Approval completion button 90 Recording progress screen 92 Conclusion completion display 93 Computer hash value 94 EOS hash value 95 Version display

Claims (7)

A data management system that associates a series of multiple files and stores them for reference.
A reception means that accepts each of multiple files,
A distribution recording means for distributing and recording a plurality of files received by the reception means to the first blockchain and the second blockchain having different platforms.
A data management system including a storage means for storing each hash value acquired at the time of recording from each blockchain in association with specific information that identifies each file. The data management system according to claim 1, further comprising a setting means for setting distribution conditions for distributing a plurality of files in the distribution recording means to each blockchain. The distribution recording means according to claim 1 or 2, characterized in that, as a distribution condition, the file received by the reception means is distributed to the second blockchain based on the reception of a predetermined instruction from the user. Described data management system. As a distribution condition, the distribution recording means is characterized in that, when a predetermined instruction is received, the file received by the reception means is recorded in the first blockchain in addition to the second blockchain. The data management system according to claim 3. The plurality of files include a contract file of a process version and a contract of a final version file.
The distribution recording means is characterized in that the process version of the contract file is distributed to the first blockchain and the final version of the contract file is distributed to the second blockchain for recording. The data management system according to any one of 4. When a web page is provided that allows a user to access and refer to the plurality of files and approve one of the plurality of files, and the one file is recorded on the blockchain, The data management system according to any one of claims 1 to 5, further comprising a service server that displays a hash value returned from the blockchain on the web page. A data management method that associates a series of multiple files and stores them for reference.
Steps to accept each of multiple files,
A step to distribute and record multiple received files to the first blockchain and the second blockchain with different platforms,
A step to store each hash value obtained at the time of recording from each blockchain in association with specific information that identifies each file, and
A data management method characterized by having.

Images