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

Abstract

PROBLEM TO BE SOLVED: To provide a data management system and a data management method capable of associating and storing a series of files while assuring both stability and time required for approval when recording a series of files on a block chain. Kind Code: A1 A data management system that stores a series of files so that they can be referred to each other, and accepting means for accepting each of the plurality of files, and the plurality of files accepted by the accepting means for a first block of a different platform. A distribution recording means for distributing and recording the chain and the second block chain, and a storage means for storing each hash value acquired at the time of recording from each block chain in association with specific information specifying each file. Prepare [Selection diagram] Figure 1

Description

  The present invention relates to a data management system and a data management method for storing a series of files in association with each other so that they can be referenced.

  Conventionally, a series of business records have been filed and used in paper format in various business formats.For example, medical institutions record individual medical records, financial institutions record customer transactions and transactions, and legal institutions set precedents. In contracts, contracts and manufacturers, business records such as product authenticity certification are filed and stored in chronological order. Such work records are managed as a series of information in chronological order so that they can be referred to later, and are used for reference and comparison of history on an individual basis or on an incident basis, and subsequent medical examinations, transactions, and authenticity judgments. It is used for such purposes. In recent years, these business records and the like are stored in a storage medium such as a server by a centralized management method as a file that is converted into electronic data input by a computer or the like. Further, contracts between companies and individuals are also starting to be transferred from paper media to electronic contracts, and are stored as electronic data files in storage media such as servers.

  In recent years, instead of storing and managing such electronic data files in a storage medium such as a server by a centralized management method, there is a service that uses a distributed data management system such as a block chain. The blockchain, by its nature, has a high tampering prevention 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 a blockchain for electronic contracts as an example, the contracts exchanged between the two parties are often reorganized in the process of confirmation by both parties, and the contracts of multiple versions created ( A series of plural files will be recorded in the block chain (for example, refer to 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 that it has excellent network and operation stability because it has a large number of users. Due to the large number of persons, it takes time to approve a transaction, and the fee for approval is high. EOS, which is one of the blockchains, has the advantage that the approval time is short and the fee for approval is low due to the fact that the transaction approval mode and the number of users are relatively small. However, there is a problem that the reliability of the stability of the network and the operation is lower than that of Ethereum. In this way, even if it is called a block chain, the characteristics of each platform are different, and the service developer must be aware of the disadvantages and select one by one, and a series of files on the block chain must be selected. It was not possible to balance the time required for approval when recording and stability.

  The present invention has been made focusing on such a problem, and refers to a series of files by associating them while achieving both stability and time required for approval when recording a series of files on a blockchain. It is an object to provide a data management system and a data management method that can be stored as much as possible.

In order to solve the above problems, the data management system of the present invention comprises:
A data management system that stores a series of multiple files so that they can be referenced and stored.
A receiving means for receiving each of a plurality of files,
Distribution recording means for distributing and recording the plurality of files received by the reception means to the first block chain and the second block chain of different platforms,
A storage unit that stores each hash value acquired from each block chain at the time of recording in association with specific information that identifies each file,
It is characterized by having.
According to this feature, the data management system is configured to divide the received multiple files into multiple block chains as necessary, and record the files. Can be recorded on the second blockchain of the platform, and other process versions of the files can be recorded on the first blockchain of the platform, which has the advantages that the approval time is short and the fee for approval is low. It is possible to store a series of files in association with each other while ensuring both stability and time required for approval when recording files on the above.

The distribution recording means is characterized by comprising setting means for setting distribution conditions for distributing a plurality of files to each block chain.
According to this feature, since the distribution condition can be arbitrarily set by the setting means, 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. It is possible to set and set other files to be distributed and recorded in the second blockchain of the platform, which has the advantage that the approval time is short and the fee for approval is low. It is possible to set distribution conditions.

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

The distribution recording means, when a predetermined instruction is received as a distribution condition, records the file received by the receiving means in the first block chain in addition to the second block chain. .
According to this feature, the file at the time of accepting the predetermined instruction is recorded in both the first block chain and the second block chain, so there is little risk of loss due to damage of the file and access at the time of reference. Multiple destinations can be selected.

The plurality of files includes a process version contract file and a final version file contract,
The distribution recording means distributes the process version contract document file to a first block chain and records the final version contract file to a second block chain for recording.
According to this feature, the contract file is often examined by multiple persons in terms of terms and conditions, and multiple versions are often formed before the final version. Has the advantage that the approval time is short and the fee for approval is low, it records it on the blockchain of the platform, and only the final contract file is recorded 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 stability.

When a user provides a web page that can access and reference one of the plurality of files and approve one of the plurality of files, and the one file is recorded on the block chain, It is characterized by comprising a service server for displaying the hash value returned from the block chain on the web page.
According to this feature, the user himself can confirm that the recording of the file on the block chain 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 comprises:
A data management method for storing a series of multiple files in association with each other,
Accepting each of a plurality of files,
Recording the plurality of received files by dividing them into a first block chain and a second block chain of different platforms,
A step of storing each hash value acquired at the time of recording from each block chain in association with specific information identifying each file,
It is characterized by having.
According to this feature, the data management system distributes the received multiple files to multiple blockchains as needed, and, for example, the final version of the file to the blockchain of the platform with excellent network and operation stability. It is possible to record and record the other version of the proof data on the blockchain of the platform, which has the advantages that the approval time is short and the fee for approval is low. It is possible to store a series of files in association with each other while maintaining both the time required for approval of and the stability.

It is a conceptual diagram which shows the network which comprises the data management system and 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 a figure which similarly shows a user page. It is a figure which similarly shows a contract creation screen. It is a figure which similarly shows the text input display displayed on the contract creation screen. It is a figure which similarly shows an encryption key input screen. It is a figure which similarly shows the encryption completion display displayed on the contract creation screen. It is a figure which similarly shows a contract participant addition screen. It is a figure which shows the contract participant similarly displayed on the contract participant addition screen. Similarly, it is a diagram showing a progress situation of recording on the EOS block chain, (a) is a diagram showing a pop-up display showing a progress of recording, and (b) is a diagram showing a state where the recording is completed. It is a figure which shows the invitation email which the contract participant received. It is a figure which shows the access code confirmation screen displayed on a personal computer. It is a figure which shows the display which urges the input of the encryption key similarly 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 within the company. It is a figure which similarly shows the contract confirmation screen for contract partners of a partner. Similarly, it is a diagram showing a state in which a list display of a plurality of created contract file is displayed on the contract confirmation screen for the contract participant of the other party. It is a figure which similarly shows a contract confirmation request screen. It is a figure which similarly shows the contract approval screen for contract participants in the company. It is a figure which similarly shows the contract approval screen for contract participants of a partner. It is a figure which similarly shows the progress situation at the time of recording on an Ethereum blockchain. It is a figure which shows the conclusion completion display displayed on the contract confirmation screen for contract participants in the company who is also the person in charge. It is a flowchart which shows a contract confirmation process. It is a flowchart which shows a contract approval process. 9 is a flowchart showing a final version recording process.

  Modes for carrying out a data management system and a data management method according to the present invention will be described below based on embodiments.

  A data management system and a data management method according to an embodiment will be described with reference to FIGS. 1 to 24.

  Data management systems are used to exchange information between service providers and recipients in various business formats, such as medical records of individuals at medical institutions, transaction records and transaction histories at financial institutions, and legal precedents and wills at legal institutions. This is a system in which contract documents related to legal affairs such as real estate transactions and management materials for product authenticity proofs by manufacturers are converted into electronic data and managed by a server for later reference. In this embodiment, management of contract documents will be described as an example. In the data management system according to the present embodiment, a client (hereinafter, also referred to as “company”) who is a main body for creating a contract document and a client (hereinafter, referred to as “partner”) who is a contractor of the contract document, The contract file can be appropriately updated via the API server 7 of the service server 1 described later. The process version contract file and the final contract file to be finally concluded are distributed to the first block chain (for example, EOS) and the second block chain (for example, Ethereum) which have different platforms. By storing each hash value recorded and acquired from each block chain at the time of recording in association with the specific information for identifying each contract document file, it is stored and managed as a series of contract document files. For example, if the person in charge creates a draft of the contract within the company and keeps it as the first version of the created contract, the boss in the company browses the first version of the contract and, if necessary, Each revision is stored and the revised version is stored, and then the contract approved by the boss is stored as the approved version. Further, 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 file up to this point is stored in the first blockchain (for example, EOS), and when the final instructions are received by the predetermined instructions due to the approval by both parties, the final version of the contract is for the second blockchain (for example, Ethereum ).

  FIG. 1 shows a system and a network for realizing an embodiment of a data management system of the present invention. Reference numeral 1 is a service server for a management company (manager) to provide a data management system, and reference numeral 2 Is a client and a personal computer (hereinafter abbreviated as "personal computer") as output means, which are connected to each other via the Internet so that they can communicate with each other. The personal computer 2 is connected to a scanner 3, a keyboard 4, a mouse 5 and the like as input means. In addition, a pen tablet, a stylus pen or the like can be used as the 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, receives a file related to a contract document from the client personal computer 2, and Manage files. Further, the service server 1 is configured to record the file relating to the contract document in 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 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 is a distributed server that constitutes a distributed file system called IPFS (Inter Planetary File System). Is a node of. The computer group 21 is a plurality of nodes that generate blocks of the block chain of the EOS platform, 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 the block chain of the Ethereum platform, 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 to store the files related to the contract documents received from the client-side personal computer 2 on the block chain. It is a server on the Internet that provides an API to perform. The API is implemented by the API server 7 and operates on the web browser activated on the client-side personal computer 2.

  A user who uses the data management system registers a unique user ID (user identification information) and a password in advance on a homepage published by the management company of the data management system. 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 block chain assigned to the user of the user ID.

  When the user inputs the input data to the data management system, first, the web browser activated on the personal computer 2 is used to access the home page published by the management company. As shown in FIG. 2, on the initial screen 10 of the home page, a user ID input field 11, a password input field 12 and a login button 13 are displayed, and the user ID and password are displayed to the accessing user. Will be prompted for.

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

  The user page 14 includes a template display 15 that calls a template function that registers and edits a template that can be used to create a contract, a contract creation display 17 that calls a function that creates a contract file, and a login user. Also, a list display 18, a notification icon 19 and the like for calling the function of confirming the contract file that is continuously involved are displayed. For example, when the template display 15 is selected, the templates of text data of a plurality of contract file 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 that the logged-in user is continuously involved in is displayed. A notification window 19a for confirming actions of a plurality of persons in charge of the service, notifications from the service management side, and the like is displayed.

  When the contract creation display 17 that calls the function of creating a contract file is selected, a 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. On 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 of the text data of the contract file, an attachment file registration button 31 for uploading an attachment file, and a template import for calling a template. A button 32, a status display 33, and an input confirmation button 34 are displayed.

  When inputting the text data of the contract file into the editor 30, the user can use the template function of the text data of a plurality of contract files, which is called by selecting the template display 15, and the template import button can be used. By selecting 32, one of the templates of the text data of a plurality of contract files can be called up to partially omit the input of the text data. Further, by selecting the attached file registration button 31, it is possible to upload a photograph, a moving image, a voice or the like that constitutes the contract file together with the text data.

  The editor 30 includes a preview button 35 and a temporary save button 36. The editor 30 displays text in XML format, but the data management system displays final output 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 user completes the input of the text data of the contract file in the editor 30 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 displayed. It is accepted as a contract document file together with the attached file (accepting means), and is stored in the service server 1 by associating the contract document file with specific information (here, user ID) for specifying the user. Further, the service server 1 shifts to the process of recording the input content 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 time series. For example, the fact that the creation of the contract has been started, the input of the preamble has been completed, etc. are displayed.

  The encryption key input screen 37 shown in FIG. 6 is a screen for encrypting the contract and setting an encryption key to be given for decryption at the time of browsing, and an input form 38 for inputting the encryption key and an encryption key. The encryption button 39 for determining 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 further selected, the encryption completion display 25c shown in FIG. 7 is displayed. In the encryption completion display 25c, a text notifying that the encryption is completed is displayed, and the input contents are displayed in the preamble input display 25a and the text input display 25b. 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 document 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 also has a contract participant addition area 42. Is displayed. In the contract participant addition area 42, a pull-down display 42a for selecting whether the contract participant to be added is "in-house" or "other", and the role of the contract participant is "person in charge" "approver" " A pull-down display 42b that can be selected as any of "confirmers", an input form 42c in which the mail addresses of the contract participants can be input, and an add button 42d are displayed. In addition to directly inputting a mail address in the input form 42c, when a contact is registered in advance, the 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, a list of the added contract participants is displayed as shown in FIG. In the list display of contract participants, a name input form 44, an input 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, an access code required when the contract participant confirms the contract document, which will be described later, is generated, and information for identifying the contract participant ( For example, it is stored in the service server 1 in association with an e-mail address).

  A check box 47 is displayed in the list display of the added contract participants. When the e-mail send 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 block chain is displayed below the list display of the added contract participants. When the record button 49 is selected, the contract document created on the contract document creation screen 25 is displayed. The file is uploaded and recorded on the EOS block chain (computer group 21 (see FIG. 1) constituting the EOS network) (sorting recording means). As shown in FIG. 10 (a), a pop-up display 50a showing the progress of recording is displayed as an animation, and when the recording is completed, a message indicating that the recording is completed on the block chain and a message returned from the block chain are returned. The hash value is displayed in the pop-up display 50b (see FIG. 10B).

  In addition, the service server 1 assigns the information of the added contract participant based on the selection of the record button 49 to the specific information indicating the contract file (here, it is assigned to the proposed contract). 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 the contract participants confirm the contract by the “person in charge” and the “confirmer”. An example will be described in which the contract participants within the company exchanging the contract are registered as users in the service of the data management system and the contract participants of the other party are not registered as users.

  As described above, the “person in charge (user)” who is the in-house contract participant logs in by entering the user ID and password on the initial screen 10 of the home page shown in FIG. 2 (step Sa01). Then, a contract file is created on the contract creation screen 25 shown in FIG. 5 (step Sa02). When the contract file has an attachment file or the like excluding the text data, the service server 1 extracts the attachment file or the like excluding the text data of the contract, and the text data of the contract is encrypted by the encryption key shown in FIG. The data 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 text data of the extracted contract document onto the distributed file system of the IPFS platform (computer group 20 (see FIG. 1) that constitutes the IPFS network) (step Sa04). . The service server 1 temporarily holds the hash value returned from the IPFS distributed file system, and combines this hash value and the text data which is the XML of the encrypted contract file, and combines it with the block chain ( It is uploaded and recorded on the computer group 21 (see FIG. 1) that constitutes the EOS network (sorting recording means, step Sa05). Then, the service server 1 stores the hash value returned from the EOS block chain (hereinafter referred to as “EOS hash value”) in association with the unique ID assigned to the proposed contract (storing means).

  The service server 1 allows the user to accept a contract file confirmation request based on the hash value returned from the EOS block chain 21. More specifically, when the user performs an operation of sending an invitation email to the email 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. Then, the invitation mail 51 (see FIG. 11) is transmitted to the mail addresses of the “person in charge” and the “confirmer” of the added contract participants, and the contract confirmation request is made (step Sa06). In addition to the invitation email 51, the service server 1 separately sends an email describing 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 inviter, the invited contract participant, and the contract conclusion deadline The hash value 52 of the chain is described. Further, the invitation email 51 displays 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.

  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 screen of the personal computer 2 shown in FIG. The displayed access code confirmation screen 54 is displayed. On the access code confirmation screen 54, a display 55 showing that the person who received the email has requested confirmation of the contract file, an input form 56 for inputting the access code, and an access for transmitting the input access code A code confirmation button 57 is provided. The contract participant inputs the separately sent access code into the input form 56 and selects the access code confirmation button 57.

  The service server 1 determines whether 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 of FIG. 13 is a screen for contract participants within the company. The contract confirmation screen 58 displays a contract name, a contract tag, a folder name, a contract version, a hash value of the EOS block chain in which the contract file is recorded, and the like. At this time, the service server 1 downloads and holds the files constituting the contract document file from the block chain of EOS and IPFS.

  Further, on the contract confirmation screen 58, a display 59 for prompting the user to input the encryption key that encrypted the contract file is displayed. The display 59 is provided with 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 participants by various methods, but here, the service server 1 is to be transmitted to the contract participants separately from the invitation mail 51 and the mail describing the access code.

  The service server 1 determines whether the encryption key input by selecting the cancel button 61 is correct (step Sa08). More specifically, the decryption of the contract document downloaded using the encryption key is tried, and if successful, as shown in FIG. 14, the text data 62 of the decrypted contract file is displayed on the contract confirmation screen 58. It is displayed so that it can be browsed (step Sa09).

  In 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 for downloading the contract in PDF format, an edit button 66 for calling the editing function of the contract, and an add button 67 for calling the function of adding more contract participants are displayed. To be done.

  Further, the contract confirmation screen 70 of FIG. 15 is a screen for the contract participants of the other party, and unlike the contract confirmation screen 58 for contract participants within the company, there is no display of the contract tag and contract folder, Text data 72 of the decrypted contract document file, a confirmation button 71 for confirming the attached file, a status display 73, and a comment button 74 are displayed.

  The contract participant can input a comment such as a correction request to the confirmed contract by selecting the comment button 74. The comment is displayed on the contract confirmation screens 58 and 70 of all contract participants. You can browse. 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 email or notification (notification icon 19 in FIG. 4) (notification means). , Step Sa11).

  The user within the company corrects the content of the contract file if necessary (step Sa12). The corrected contract is encrypted with the encryption key set on the encryption key input screen 37 shown in FIG. 7 (step Sa03), and the processing after step Sa03 is performed each time the contract file is corrected. 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).

  Referring to FIG. 16, when the contract version display 75 on the contract confirmation screen 70 is selected, 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 document file at that time and the previous contract document file can be displayed on one screen, It is easy to check the correction points.

  As shown in FIG. 15, an action button 80 for the confirmed contract is displayed at the bottom of the contract confirmation screen 70. The action button 80 is displayed differently depending on the roles of the contract participant, namely, “person in charge”, “approver”, and “confirmer” (see FIG. 8). More specifically, the “person in charge” is “approval request”, the “confirmer” is “contract confirmation”, and the “approver” is “contract approval”.

  When the "person in charge" selects the "approval request" action button 80, the service server 1 judges that the confirmation of the contract participant who is the "person in charge" has been completed, and provides the person in charge confirmation completion information. It is stored as a series of contract document files in association with the unique ID assigned to the contracted contract. When the "confirmer" selects the "contract confirmation" action button 80, the service server 1 displays the contract confirmation screens 58 and 70 viewed by the contract participant who is the "confirmer", as shown in FIG. The contract confirmation request screen 78 is displayed.

  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 confirmation of the contract to the service server 1 are displayed. On the preview 79, a comment button 79a for entering a comment is displayed, 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" is completed, and the contract confirmation information is added to the contract confirmation information. It is stored as a series of contract file associated with the unique ID assigned to the document.

  The service server 1 selects the “approval request” action button 80 by the “person in charge” of the contract participant within the company, and selects the confirmation completion button 81 by the “confirmer” of the contract participant within the company. In addition, the action button 80 of "request approval" 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. On the contract confirmation screens 58 and 70, the contract participant does not enter a comment such as a correction request from the contract participant (step Sa10). The contract approval process is shown in the flowchart of FIG.

  When the contract approval process starts, the service server waits for the approval of the “approver” within the company. When the "approval" action button 80 is selected by the "approver" within the company, the service server 1 causes the contract confirmation screen 58 (Fig. 14) viewed by the contract participant who is the "approver". 18) to switch to the contract approval screen 82 shown in FIG. 18 and request approval of the contract from the "approver" in the company (step Sb01). Similarly, when the action button 80 of “contract approval” is selected by the partner “approver”, the service server 1 displays the contract approval screen 86 shown in FIG. 19 on the partner “approver” PC 2. Display it.

  The contract approval screen 82 shown in FIG. 18 is a screen for "approver" among contract participants in the company. The contract approval screen 82 displays 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 to the service server 1 that the approval of the contract has been completed.

  The contract participant who is the “approver” inputs the signature image data in the signature area 83, the stamp image data in the stamp 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 an upload function not described in detail here.

  Similarly, when the action button 80 of “contract approval” is selected by the partner “approver”, the service server 1 displays the contract approval screen 86 shown in FIG. Requesting approval of the contract (step Sb02).

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

  Here, the service server 1 determines whether or not a comment such as a correction request has been input from an “approver” within the company (step Sb03), and no comment such as a correction request has been input and the service server 1 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" is completed, and the contract document within the company. The approval information is associated with a unique ID assigned to the proposed 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 "approver" of the partner (step Sb04), and no comment such as a correction request has been input and the "approver of the partner" has not been input. When the approval completion button 89 has been selected by “” (step Sb06), the contract approval information of the other party is linked to the unique ID assigned to the proposed contract to create a series of contract files. store.

  The service server 1 determines that the approval has been completed by both companies by the selection of the approval completion button 85 by the “approver” within the company and the selection of the approval completion button 89 by the partner “approver”. , The approval completion information is stored as a series of contract document files in association with a unique ID assigned to the proposed contract document.

  When the service server 1 determines that the approval of both companies has been completed (accepts the predetermined instruction) (step Sb07), the process proceeds to the final version recording process. In the final version recording process, first, the contract participants who are the "person in charge" in the company are notified. The "person in charge" displays the contract confirmation screen 58 (Fig. 14) from the notification window 19a (Fig. 3) of the user page 14. Although not shown here, when the person in charge selects the recording start button displayed on the contract confirmation screen 58, the final version recording process is started. In addition, although an example in which selection by the person in charge is required is described in step Sb07, if steps Sb05 and Sb06 are YES, it is determined that both parties have approved, and notification to the person in charge is omitted. However, the final version recording process shown in FIG. 24 may be performed.

  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 configures the contract file of the latest version and the approved version of the contract file from the EOS block chain and IPFS based on the EOS hash value. The file is downloaded (step Sc01), and then the time stamp is obtained (step Sc02).

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

  The service server 1 temporarily holds the hash value returned from the IPFS distributed file system, and the hash value, the text data which is the XML of 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 Ethereum platform (computer group 22 (see FIG. 1) that constitutes the Ethereum network) (sort recording means, step Sc05). . The user who is the “person in charge” within the company can check the progress status when recording on the Ethereum block chain 22 on the recording progress screen 90 shown in FIG. The service server 1 stores the hash value returned from the Ethereum block chain 22 (hereinafter referred to as “Ethereum hash value”) in association with the unique ID assigned to the proposed contract (storing means). .

  Based on the Ethereum hash value being received, the service server 1 determines that the contract has been concluded (step Sc06), and displays the conclusion completion display 92 shown in FIG. It is displayed on the document confirmation screen 58.

  An Ethereum hash value 93 is displayed on the conclusion completion display 92, and an EOS hash value 94 is also shown 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” within the company, but the contents displayed on the conclusion completion display 92 are included in the proposed contract. All of the contract participants who have made access can access the electronic contract provided by the service server 1 when browsing. Then, the contract participants who participated in the proposed contract may select the version display 95 displayed on the conclusion completion display 92 to later browse the process version contract file before the approval is completed. it can. Although not shown here, since the EOS hash value is displayed in association with the process version contract file before the approval is completed, the contract participants are sure to be the process version contract file. You can browse the contents after making a decision.

  As described above, the data management system of the present invention has a configuration in which a plurality of contract document files received from a user are distributed and recorded in a plurality of block chains 21 and 22 as necessary, and in the embodiment, the final version is recorded. The contract file is recorded on Ethereum's blockchain 22 which is a platform with excellent network and operation stability, and other process version contract files have a short approval time and a low fee for approval. It can be recorded on the blockchain 21 of EOS, which is a platform equipped with, and makes it possible to reference a series of contract files by associating them with both the time required for approval when recording files on the blockchain and stability. Can be stored.

  Further, the service server 1 is configured to change the recording destination from the EOS block chain 21 to the Ethereum block chain 22 based on the acceptance of the approval information by the approver, and the contract file recording destination is automatically changed according to the distribution condition. Since it is determined and distributed, it is possible to prevent human error, reliably distribute and record the contract file on the desired blockchain, and the time and stability required for approval at the time of recording. Can achieve both. In addition, since the files when the predetermined instruction is received are uniformly recorded on the predetermined Ethereum block chain 22, the data management becomes easy when referring to them later.

  Further, the distribution recording means of the service server 1 records the accepted contract file in the Ethereum block chain 22 in addition to the EOS block chain 21 based on the acceptance of the approval information by the approver as the distribution condition. . According to this, since the contract file when the approval information is received by the approver (the final version contract file in the above-mentioned embodiment) is recorded in both the EOS block chain 21 and the Ethereum block chain 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 block chain 21 and allocates the final version contract file to the Ethereum block chain 22 for recording. According to this, the content of terms etc. is examined by multiple persons in charge of the contract file, and multiple versions are often formed before the final version. , The approval time is short and the fee for approval is low, it is recorded on the EOS blockchain 21 of the platform, and only the final version of the contract file is Ethereum of the platform with excellent network and operation stability. By recording in the block chain 22, it is easy to achieve both the time required for approval and stability.

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

  Although the embodiments of the present invention have been described above with reference to the drawings, the specific configurations are not limited to these embodiments, and any modifications or additions within the scope of the present invention are included in the present invention. Be done.

  For example, in the above-described embodiment, the service server 1 determines that the contract approval information that approves the contract by the “authorizer” has been obtained from both within the company and the other party, and the service server 1 executes the predetermined instruction. Based on this, the distribution condition that the final version of the contract file is recorded on the Ethereum blockchain 22 and the previous process version of the contract file is recorded on the EOS blockchain 21 if there is no prescribed instruction. However, the distribution condition may be set appropriately by a service manager (setting means). For example, the contract file of the version at the time of confirmation by the "confirmer" and the contract document of the final version at the time of approval by the "approver" are recorded on the blockchain 22 of Ethereum, and the others are recorded. By setting the distribution conditions such as recording on the EOS block chain 21, all contract files of high importance version may be recorded on the highly reliable block chain. Optimal distribution conditions can be set.

  In addition, regarding the aspect in which the contract file is distributed and recorded in the two block chains, the predetermined information such as that the contract approval information by the "approver" who has approved the contract is obtained from both within the company and the other party. It is not limited to receiving the instruction, and for example, the administrator may appropriately determine and distribute.

  Moreover, the platform of the block chain that distributes and records the contract file is not limited to two types, and may be a plurality of three or more types.

  Further, in the above-mentioned embodiment, the EOS blockchain is used as a typical platform having a merit that the approval time is short and the fee for approval is low for the blockchain for distributing and recording the contract file. Ethereum was selected as a platform with excellent stability of operation and operation, but it is not limited to this, and it is not necessary that it is a blockchain of these platforms as long as it has a characteristic that a similar contrast relation holds. There is no end.

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

  Further, in the above-mentioned 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. It can be effectively used in a scene in which management data whose authenticity is required, such as proof of authenticity of a product in a maker, is stored in association with each other in time series.

  Further, in the above-described embodiment, the image data is stored using the IPFS which is a distributed file system, but the present invention is not limited to this. For example, if the storage environment is other than the block chain for storing the text data, the distributed type is used. The file system may not be used, and may be stored in 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 block chain 22 together with the document data of the contract. If the file has a small capacity, the step of using IPFS may be omitted and the file may be directly stored in the EOS block chain 21 or the Ethereum block chain 22.

  In addition, the block chains of the two platforms in the above-described embodiment are so-called private chains that operate in an environment on a plurality of computers that configure the service server 1 provided by the management company, although they have been described in the specification of the public chain. Good.

  Further, the API server 7 including the API configuring the service server 1 provided by the management company, the user management server 8 including the correspondence table, and the processing server 9 are configured by a single computer having the respective functions. May be.

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

1 Service Server 2 Personal Computer 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 Add contract participant screen 46 Create button 48 Send mail button 49 Record button 51 Invitation mail 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 Fastening completion display 93 Ethereum Gerhard value 94 EOS hash value 95 version display

Claims (7)

A data management system that stores a series of multiple files so that they can be referenced and stored.
A receiving means for receiving each of a plurality of files,
Distribution recording means for distributing and recording the plurality of files received by the reception means to the first block chain and the second block chain of different platforms,
A data management system, comprising: a storage unit that stores each hash value acquired from each block chain during recording in association with specific information that identifies each file.   The data management system according to claim 1, further comprising a setting unit that sets a distribution condition for distributing a plurality of files in the distribution recording unit to each block chain.   3. The distribution recording means distributes the file accepted by the acceptance means to the second block chain based on acceptance of a predetermined instruction from a user as a distribution condition. Described data management system.   The distribution recording means, when a predetermined instruction is received as a distribution condition, records the file received by the receiving means in the first block chain in addition to the second block chain. The data management system according to claim 3. The plurality of files includes a process version contract file and a final version file contract,
2. The distribution recording means distributes the contract version contract file to the first block chain and records the final version contract file to the second block chain for recording. 4. The data management system according to any one of 4.   When a user provides a web page that can be accessed to perform reference work of one of the plurality of files and approval of one of the plurality of files, and the one file is recorded on the block chain, 6. The data management system according to claim 1, further comprising a service server that displays the hash value returned from the block chain on the web page. A data management method for storing a series of multiple files in association with each other,
Accepting each of a plurality of files,
Recording the plurality of received files by dividing them into a first block chain and a second block chain of different platforms,
A step of storing each hash value acquired at the time of recording from each block chain in association with specific information identifying each file,
A data management method comprising:

Images