JP7680900B2 - Electronic contract method, electronic contract system, and program - Google Patents

Description

Embodiments of the present invention relate to an electronic contract method, an electronic contract system, and a program.

A contract agreement system has been proposed in which transactions related to agreed-upon contracts are stored in a blockchain. A blockchain is a mechanism in which multiple devices that make up a distributed network synchronize transactions and store them in a chain.

For example, a technology has been proposed in which multiple terminals used by multiple contract holders each have a memory unit that stores a blockchain, and transactions including evidence of whether or not the contract was agreed to are stored in the memory unit of the terminal itself.

JP 2017-220710 A International Publication No. 2017/010455

However, in conventional technologies, there are cases where it is not easy to build a system that stores a blockchain related to a contract. For example, in the above conventional technologies, each terminal is configured to store a blockchain, so when adding a contractor, a terminal equipped with a memory unit that stores the blockchain must be prepared for each contractor to be added. In addition, all terminals corresponding to multiple contractors must store transactions for contracts that are unrelated to the corresponding contractor.

The electronic contract method of the embodiment is an electronic contract method executed in an electronic contract system connected to a blockchain system that stores transactions in a blockchain. The electronic contract method includes a contract processing step and a storage control step. The contract processing step receives instructions of agreement to a contract concluded between the first contractor and the second contractor from each of the first contractor and the second contractor. The storage control step transmits to the blockchain system an instruction to store in the blockchain a first transaction indicating that the first contractor has agreed to the contract, and an instruction to store in the blockchain a second transaction indicating that the second contractor has agreed to the contract.

FIG. 1 is a block diagram showing an example of the configuration of an electronic contract system according to this embodiment. FIG. 2 is a diagram illustrating an example of a data structure of the correspondence information. FIG. 3 is a sequence diagram showing an example of the advance registration process in this embodiment. FIG. 4 is a sequence diagram showing an example of electronic bidding and electronic contract processing in this embodiment. FIG. 5 is a diagram showing an example of the flow of electronic bidding and electronic contract processing. FIG. 6 is a diagram showing an example of a contract content input screen. FIG. 7 is a diagram showing an example of the contract output screen. FIG. 8 is a diagram showing an example of the electronic contract screen. FIG. 9 is a diagram showing an example of the flow of an electronic contract on the successful bidder's side. FIG. 10 is a diagram showing an example of the flow of an electronic contract on the part of the purchaser. FIG. 11 is a diagram showing an example of a data structure of the transaction information. FIG. 12 is an explanatory diagram illustrating an example of the hardware configuration of the device according to the present embodiment.

Below, preferred embodiments of the electronic contract method, electronic contract system, and program of the present invention are described in detail with reference to the attached drawings.

In the following, we will explain an example of implementing an electronic contract system as a system for managing electronic bidding and entering into contracts related to electronic bidding. Applicable systems are not limited to systems related to electronic bidding.

In the above-mentioned conventional technology, multiple terminals used by multiple contractors each have a storage unit that stores the blockchain. In other words, in the conventional technology, each terminal is configured to be a user terminal used to agree on a contract, and also to store the blockchain.

If this configuration were applied to an electronic contract system for electronic bidding, for example, the bidding companies (businesses and corporations equivalent to contractors who agree to a contract) would also store the blockchain on their own terminals. Because the blockchain stores transactions for all contracts, bidding companies need to store all contracts for which there may be a large number of cases (for example, thousands to tens of thousands per year) on their own terminals, even if they are contracts that are not related to them.

The electronic contract system in this embodiment does not have a memory unit that stores the blockchain internally, but instead instructs a blockchain system that has a memory unit that stores the blockchain to store transactions.

The blockchain system is configured to store the blockchain in an internal storage unit according to instructions from an external system, including the electronic contract system of this embodiment. The blockchain system is configured, for example, from multiple servers (blockchain peers) that are distributed in a distributed manner. Each server is operated, for example, by multiple businesses that are unrelated to the parties to the electronic contract.

The electronic contract system, for example, uses a private key to affix an electronic signature to the transaction (a packet containing the transaction) and sends the transaction to the blockchain system. After this, processing related to the blockchain is carried out by the blockchain system.

In this way, the electronic contract system only needs to have functions (programs, etc.) for creating transactions, electronic signatures, and sending transactions, and does not need to have a memory unit for storing the blockchain internally. When a contract holder is added, for example, it is only necessary to make the above functions available from the terminal used by the contract holder, or to add a terminal that can use the above functions. In this way, it becomes possible to more easily build a system that stores blockchains related to contracts.

Figure 1 is a block diagram showing an example of the configuration of an electronic contract system 100 according to this embodiment. As shown in Figure 1, the electronic contract system 100 is connected to certification authorities 201 and 202, an orderer terminal 301, a bidder terminal 302, and a blockchain system 400 via a network 10.

The network 10 is, for example, the Internet, but may be any other form of network. The network 10 may be a wired network, a wireless network, or a network that combines wired and non-wired networks.

Certification authorities 201 and 202 are organizations that issue electronic certificates used in various systems. For example, certification authorities 201 and 202 issue private keys and public key certificates in authentication technology based on the Public Key Infrastructure (PKI).

Certification authority 201 may be, for example, a ministry certification authority recognized by GPKI (Government Public Key Infrastructure) or an organization certification authority recognized by LGPKI (Local Government Public Key Infrastructure). A ministry certification authority is, for example, a certification authority that issues an official position certificate for a purchaser. An organization certification authority is a certification authority that issues a position certificate for a purchaser. Certification authority 202 may be, for example, a private certification authority that issues position certificates for bidders.

The certificate authorities 201 and 202 do not need to be distinguished and may be replaced by a single certificate authority that issues electronic certificates to both purchasers and bidders. The electronic contract system 100 may also be connected to three or more certificate authorities.

Certification authorities 201, 202 may be configured to issue IC (Integrated Circuit) cards that store private keys and public key certificates.

The purchaser terminal 301 is a terminal used by the purchaser of the electronic bid. Although one purchaser terminal 301 is shown in FIG. 1, the electronic contract system 100 may be connected to two or more purchaser terminals 301.

The bidder terminal 302 is a terminal used by a bidder in an electronic bid. Although one bidder terminal 302 is shown in FIG. 1, the electronic contract system 100 may be connected to two or more bidder terminals 302.

Each terminal (purchaser terminal 301 and bidder terminal 302) can be configured as a general computer such as a personal computer. Furthermore, each terminal uses each function of the electronic contract system 100 via various screens provided by the electronic contract system 100. For example, each terminal can be configured to use each function of the electronic contract system 100 via a browser or web application, etc.

As described above, the blockchain system 400 is a system configured to store a blockchain in an internal memory unit in accordance with instructions from an external system.

The blockchain system 400 includes a communication control unit 411, a smart contract processing unit 412, a management unit 413, and a blockchain storage unit 421. The blockchain system 400 includes multiple servers (blockchain peers) that are multiplexed and distributed so as to include each of these units. Each server may be built on a cloud environment.

The blockchain storage unit 421 is a storage unit that stores the blockchain. For example, the blockchain storage unit 421 stores transactions in the blockchain according to a smart contract executed by the smart contract processing unit 412.

The communication control unit 411 controls communication with external systems such as the electronic contract system 100. For example, the communication control unit 411 receives an instruction (such as an instruction to execute a smart contract) sent from the electronic contract system 100 to store a transaction in the blockchain storage unit 421. The communication control unit 411 also sends the execution result of the process (such as the return value of the instructed smart contract) to the source of the process request (such as the electronic contract system 100).

The smart contract processing unit 412 executes the smart contract that has been instructed to be executed. For example, the smart contract processing unit 412 executes the instructed smart contract from among multiple smart contracts that each define processing for a different type of transaction, and stores the transaction in the blockchain. The multiple smart contracts include an electronic contract smart contract that stores a contract made by the electronic contract system 100.

Smart contracts may be written in a general-purpose language such as JavaScript (registered trademark). An external system such as the electronic contract system 100 can execute a desired smart contract using a web application that uses an API that calls the smart contract.

The execution of a smart contract can also be interpreted as a transaction. A log (transaction log) indicating the execution status of a transaction is stored in the blockchain. The transaction log includes, for example, information identifying the called smart contract, the arguments of the smart contract, the date and time, and the caller.

Smart contracts may be able to be newly added and modified. The management unit 413 manages such smart contracts, as well as managing the system status and users. For example, the management unit 413 displays a management screen on the administrator's terminal for modifying smart contracts and performing test execution. The management unit 413 also displays a screen for checking the status of the blockchain system 400 and a screen for changing user authority.

Modifications to smart contracts and other operations by administrators (such as changes to system configurations and changes to user permissions) may also be stored as transactions on the blockchain. This makes it possible to realize a more reliable system.

A smart contract may have the function of calling other smart contracts. For example, an electronic contract smart contract may be configured to call a smart contract for executing payment processing. If realized as a smart contract, the transaction log can be stored in the blockchain as described above, making it possible to realize a more reliable system compared to a method of realizing payment processing outside the blockchain system 400.

The electronic contract system 100 includes a registration processing unit 111, a contract management unit 112, a bidding processing unit 113, a contract processing unit 114, a memory control unit 115, an authentication unit 116, and a memory unit 121.

The registration processing unit 111 performs registration processing for users (first users) of the electronic contract system 100. A user corresponds to a contractor who enters into an electronic contract using the electronic contract system 100. For example, the registration processing unit 111 executes contractor registration processing to screen the qualifications of contractors who will be making electronic bids and register contractors who have been approved as users. In the contractor registration processing, contractor information such as the contractor's name, representative's name, location, email address, and the registration number issued at the time of approval is stored, for example, in the memory unit 121.

The registration processing unit 111 also executes a usage registration process to allow registered contractors to use the electronic contract system 100. The usage registration process includes, for example, a process of registering information on an IC card that has been assigned to the contractor in advance. Prior to the usage registration process, the contractor obtains the IC card by, for example, requesting the issuance of an IC card from the certification authorities 201 and 202. The IC card can be used, for example, for login processing to the electronic contract system 100 (identification using IC card information, or identity verification using a user ID and password) and for electronic signatures on electronic documents handled in electronic bidding processing.

The private key and public key certificate stored in the IC card may be used to electronically sign a transaction stored in the blockchain system 400. The key information used to electronically sign a transaction is not limited to the key information stored in the IC card issued for use in the electronic contract system 100.

For example, instead of an IC card, a private key assigned to a user (merchant) by any other method (any method is acceptable) may be used to electronically sign a transaction. A wallet that stores a private key and a public key may be used instead of an IC card.

Two or more pieces of key information (IC cards, wallets) may be assigned to one vendor. For example, a vendor may be assigned different pieces of key information for each type of electronic bidding. Also, a vendor may be assigned different pieces of key information for each individual belonging to the vendor.

In such a case, the registration processing unit 111 may execute a process (association process) of associating a user (second user) of the blockchain system 400 with multiple pieces of key information. For example, the registration processing unit 111 executes an association process of associating one or more public keys assigned to a user of the electronic contract system 100 with a user of the blockchain system. A wallet address generated from the public key may be used instead of the public key.

The matching process enables users of the electronic contract system 100 to store electronic contract transactions that have been digitally signed using a private key assigned to them in the blockchain system 400.

The contract management unit 112 manages contracts related to electronic bidding. For example, the contract management unit 112 registers items that are the subject of electronic bidding, manages successful bidders in electronic bidding, and manages the contents of contracts with successful bidders.

The bidding processing unit 113 executes processing related to electronic bidding. For example, the bidding processing unit 113 enables bidders to display or search for cases registered by the contract management unit 112 as the subject of electronic bidding. The bidding processing unit 113 also accepts bid application forms from bidders and accepts information indicating the determined successful bidder.

The contract processing unit 114 executes processing related to electronic contracts. For example, the contract processing unit 114 accepts instructions for agreement on a contract concluded between a contractor (first contractor) corresponding to the purchaser of an electronic bid and a contractor (second contractor) corresponding to the successful bidder of an electronic bid. Then, the contract processing unit 114 uses the storage control unit 115 to perform processing to store in the blockchain a transaction indicating that the contract has been agreed upon.

The function of the contract processing unit 114 may be integrated into the contract management unit 112. When adding a function for digitizing contracts (electronic contract function) to an existing system (such as an electronic bidding system), a configuration may be adopted in which the contract processing unit 114 that realizes the electronic contract function is provided independently of the contract management unit 112, as in this embodiment. This makes it possible to more easily add an electronic contract function to an existing system, i.e., a function for storing contracts in the blockchain system 400.

The storage control unit 115 controls the process of storing transactions in the blockchain storage unit 421. For example, the storage control unit 115 transmits to the blockchain system 400 an instruction to store in the blockchain a transaction (first transaction) indicating that the purchaser has agreed to the contract, and an instruction to store in the blockchain a transaction (second transaction) indicating that the successful bidder has agreed to the contract.

When the above-mentioned electronic contract smart contract is prepared, the storage control unit 115 can use the electronic contract smart contract, i.e., by calling the electronic contract smart contract, to instruct the storage of a transaction indicating that the contract has been agreed to in the blockchain.

When the registration processing unit 111 executes the matching process, the storage control unit 115 may store in the blockchain a transaction indicating the matching process, for example, a transaction (third transaction) indicating that one or more public keys (or wallet addresses) assigned to a user of the electronic contract system 100 have been matched with a user of the blockchain system. This makes it possible to verify that the electronic contract has been stored by the correct user.

The authentication unit 116 authenticates the user of the electronic contract system 100. For example, the authentication unit 116 authenticates the user using authentication information including a user ID, which is the user's identification information, and a password. The authentication method is not limited to this, and any method may be used. For example, an authentication method using a PIN (Personal Identification Number) number stored in an IC card may be used.

The storage unit 121 stores various information used in the electronic contract system 100. For example, the storage unit 121 stores vendor information obtained in the vendor registration process by the registration processing unit 111. The storage unit 121 also stores correspondence information obtained in the matching process by the registration processing unit 111.

Figure 2 is a diagram showing an example of the data structure of the correspondence information. As shown in Figure 2, the correspondence information has a structure in which a blockchain user ID and key information are associated with each other. The blockchain user ID is identification information of a user of the blockchain system 400. The key information is information that identifies a key assigned to a user (such as a trader) of the electronic contract system 100 that corresponds to the user identified by the blockchain user ID. For example, the information that identifies the key is a public key contained in an IC card or wallet, or a unique value calculated from this public key.

Each of the above units (registration processing unit 111, contract management unit 112, bidding processing unit 113, contract processing unit 114, memory control unit 115, and authentication unit 116) is realized, for example, by one or more processors. For example, each of the above units may be realized by having a processor such as a CPU (Central Processing Unit) execute a program, i.e., by software. Each of the above units may be realized by a processor such as a dedicated IC, i.e., by hardware. Each of the above units may be realized by using a combination of software and hardware. When multiple processors are used, each processor may realize one of the units, or two or more of the units.

Each of the above memory units (memory unit 121 and blockchain memory unit 421) can be configured from any commonly used storage medium, such as a flash memory, a memory card, a RAM (Random Access Memory), a HDD (Hard Disk Drive), and an optical disk.

The electronic contract system 100 may be built on a cloud environment, or may be configured with multiple servers in a distributed manner, similar to the blockchain system 400.

Next, the pre-registration process by the electronic contract system 100 configured in this manner will be described. The pre-registration process is a process that is performed before the execution of an electronic contract, and includes the above-mentioned trader registration process and user registration process. Figure 3 is a sequence diagram showing an example of the pre-registration process in this embodiment.

The bidder uses the bidder terminal 302 to send a qualification application to the electronic contract system 100 (step S101). For example, a screen for the qualification application provided by the electronic contract system 100 is displayed on the browser of the bidder terminal 302. The bidder uses this screen to send the qualification application.

The registration processing unit 111 of the electronic contract system 100 accepts the submitted qualification application and executes the contractor registration process to register the approved bidder (step S102).

The qualification review may be performed by a reviewer by reviewing the application documents. In such a case, the contractor registration process may be executed when the reviewer completes the review and indicates to the electronic contract system 100 that the reviewer has approved the bidder.

The registration processing unit 111 transmits the screening results to the bidder terminal 302 (step S103). The screening results are transmitted, for example, by email, but may be transmitted by any other method.

If the bidder is approved as a result of the qualification application, the bidder uses the bidder terminal 302 to request the certification authority 202 to issue an IC card for the user registration process (step S104). The certification authority 202 sends the issued IC card to the requesting bidder (step S105).

After receiving the IC card, the bidder uses the bidder terminal 302 to send a registration application to the electronic contract system 100 (step S106). For example, the electronic contract system 100 (registration processing unit 111) displays a screen on the bidder terminal 302 for inputting the bidder's registration number and password, etc., which are notified when the qualification application is submitted or are notified as a result of the qualification screening. When the bidder inputs the registration number and password, etc., on this screen, the registration processing unit 111 displays a screen for registering user information. The user information includes, for example, the bidder's (contractor's) company information, the person in charge, and a contact email address. When the bidder inputs the user information on this screen and instructs registration, a registration application including the user information is sent to the electronic contract system 100.

The registration processing unit 111 executes the usage registration process in response to the transmitted usage registration application (step S107). For example, the registration processing unit 111 stores the user information included in the usage registration application in the storage unit 121 or the like.

The registration processing unit 111 may execute a matching process (step S108). The registration processing unit 111 stores the matching information obtained by the matching process in the memory unit 121. The registration processing unit 111 also stores a transaction indicating the matching process in the blockchain system 400 (blockchain memory unit 421) via the memory control unit 115 (step S109).

Next, the electronic bidding and electronic contract processing by the electronic contract system 100 configured in this manner will be described. The electronic bidding and electronic contract processing includes processing related to electronic bidding (steps S201 to S210) and processing for storing the contract concluded as a result of electronic bidding in the blockchain (steps S211 to S217). Figure 4 is a sequence diagram showing an example of electronic bidding and electronic contract processing in this embodiment.

Steps S201 to S204 correspond to the login process for the purchaser and bidder to the electronic contract system 100.

For example, the purchaser uses an authentication screen displayed on the purchaser terminal 301 to input the purchaser's authentication information (e.g., user ID and password) and transmits the authentication information to the electronic contract system 100 (authentication unit 116) (step S201). The authentication unit 116 performs authentication using the authentication information and transmits the authentication result to the purchaser terminal 301 (step S202).

Similarly, the bidder uses the authentication screen displayed on the bidder terminal 302 to input the bidder's authentication information and transmits the authentication information to the electronic contract system 100 (authentication unit 116) (step S203). The authentication unit 116 performs authentication using the authentication information and transmits the authentication result to the bidder terminal 302 (step S204).

If the login is successful, the purchaser inputs information about the project to be the subject of electronic bidding (project information) using, for example, a project registration screen displayed on the purchaser terminal 301, and issues an instruction for registration. In response to the instruction, the purchaser terminal 301 sends an instruction to register the project information to the electronic contract system 100 (contract management unit 112) (step S205).

The contract management unit 112 performs processes such as registering the relevant project as a target for electronic bidding according to the received project information. The registered project is displayed, for example, on the screen for electronic bidding, or is searchable on the screen for electronic bidding.

If the bidder is able to log in successfully, the bidder inputs bidding information including the bidding conditions for the desired project, for example, using an electronic bidding screen displayed on the bidder terminal 302, and issues an instruction to send the information. In response to the instruction, the bidder terminal 302 sends the bidding information to the electronic contract system 100 (bidding processing unit 113) (step S206).

The purchaser refers to the bidding information sent by each bidder and determines the successful bidder. The purchaser inputs successful bidder information indicating the determined successful bidder, for example, using a screen for registering the successful bidder displayed on the purchaser terminal 301, and issues an instruction to transmit the information. In response to the instruction, the purchaser terminal 301 transmits the successful bidder information to the electronic contract system 100 (bidding processing unit 113) (step S207).

The bidding processing unit 113 transmits the transmitted successful bidder information to the contract management unit 112 (step S208). This allows the contract management unit 112 to manage the fact that a successful bidder for the case has been determined.

The purchaser further inputs the contents of the contract to be concluded with the successful bidder, for example, using a screen for registering the contract contents displayed on the purchaser terminal 301, and instructs transmission. In response to the instruction, the purchaser terminal 301 transmits the contract contents to the electronic contract system 100 (contract management unit 112) (step S209).

The contract management unit 112 generates contract information equivalent to the electronic data of the contract according to the received contract contents (step S210).

In the case of a system that does not execute electronic contracts, for example, the generated contract information is printed on paper media, and the contract is executed using the paper media. In this embodiment, an electronic contract is executed using the electronic data of the contract through the following steps S211 to S217.

The contract processing unit 114 transmits the contract information to the bidder terminal 302 used by the successful bidder (step S211). The contract information may include not only the contract but also electronic data of other related documents (related books) (details will be described later).

The bidder (successful bidder) inputs information indicating that he/she agrees to the contract, for example, using a screen for forming an agreement displayed on the bidder terminal 302, and issues an instruction to send it. In response to the instruction, the bidder terminal 302 sends information indicating the agreement to the contract to the electronic contract system 100 (contract processing unit 114) (step S212).

When the contract processing unit 114 receives the instruction to agree to the contract, it instructs the storage control unit 115 to store the transaction information including the information indicating the contract agreement as a transaction in the blockchain system 400 (step S213). For example, the contract processing unit 114 instructs to store a transaction indicating that the contract has been agreed to using an electronic contract smart contract.

The storage control unit 115 stores the transaction information as a transaction in the blockchain system 400 (blockchain storage unit 421) in response to the instruction (step S214). For example, the storage control unit 115 stores the transaction by calling an electronic contract smart contract.

A similar process is also performed on the client side. For example, the client uses the agreement formation screen displayed on the client terminal 301 to input information indicating agreement to the contract and instructs transmission. In response to the instruction, the client terminal 301 transmits information indicating agreement to the contract to the electronic contract system 100 (contract processing unit 114) (step S215).

Steps S216 and S217 are similar to steps S213 and S214, so explanations will be omitted.

In FIG. 4, the bidder (successful bidder) first stores the contract agreement transaction, and then the purchaser stores the contract agreement transaction, but the order of these storage processes may be reversed.

Although Figure 4 shows an example of a two-party (client, successful bidder) agreement on a contract, a similar procedure can be applied to an agreement between three or more contracting parties. In this case, multiple transactions indicating an agreement between multiple contracting parties are linked and stored in the blockchain.

Next, we will further explain the details of electronic bidding and electronic contract processing. Figure 5 is a diagram showing an example of the flow of electronic bidding and electronic contract processing.

In FIG. 5, the contract processing unit 114 is shown divided into an "electronic contract" function that creates contract information for an electronic contract, a "contract APL (application)" function that stores contract transactions in the blockchain, and a "login processing" function that performs identity verification for the contracting party.

The vendor information obtained by the qualification application and vendor registration process by the registration processing unit 111 is stored in the memory unit 121 or the like and is referenced by the contract management unit 112 (step S301). The contract management unit 112 registers the case information transmitted in accordance with the purchaser's instructions (step S302). The registered case is transmitted to the bidding processing unit 113 as a subject for electronic bidding (step S303).

The bidding processing unit 113 receives the bidding information sent from the bidders (step S304). The bidding processing unit 113 notifies the successful bidder among the bidders that the bid has been successful, in accordance with the successful bidder information determined by the purchaser (step S305). The bidding processing unit 113 also transmits the successful bid result to the contract management unit 112 (step S306).

The contract management unit 112 receives the contract contents entered by the client (step S307). FIG. 6 shows an example of a contract contents input screen used to input the contract contents. The contract contents input screen includes functions such as searching for the target case, deleting a contract, updating a contract, and registering the entered contract contents.

Returning to FIG. 5, the contract management unit 112 transmits the contract information generated based on the contract contents entered on the contract contents input screen of FIG. 6 or the like to the contract processing unit 114 (step S308).

The contract information may be output to the contract processing unit 114 when the purchaser specifies the output. FIG. 7 is a diagram showing an example of a contract output screen for specifying the output of the contract information. The contract output screen includes a function for searching for the target case and a function for outputting the contract information corresponding to the contract contents.

Returning to FIG. 5, information identifying the successful bidder (e.g., identification information such as a user ID) is transmitted, for example, from the bidding processing unit 113 to the contract processing unit 114 (step S309).

As described above, the contract information may include electronic data of related books of the contract. For example, the contract processing unit 114 displays a screen for specifying related books on the client terminal 301, and receives information indicating the related books specified by the client using this screen (step S310). The contract processing unit 114 may store and manage the related books in the memory unit 121 or the like (book management in FIG. 5).

When generating a contract transaction, the contract holder's identification information (step S311) and the hash value of the contract holder information (step S312) are used.

The contract processing unit 114 transmits the contract information to the bidder terminal 302 used by the successful bidder (step S313). If the successful bidder indicates agreement to the contract, information indicating the agreement to the contract is transmitted to the contract processing unit 114 (step S314). The contract processing unit 114 stores the transaction information including information indicating that the successful bidder has agreed to the contract as a transaction in the blockchain system 400.

When the purchaser indicates agreement to the contract (step S315), the contract processing unit 114 stores transaction information including information indicating that the purchaser has agreed to the contract as a transaction in the blockchain system 400.

The contract processing unit 114 sends information indicating the contract result to the contract management unit 112 (steps S316, S317).

In this way, according to this embodiment, it is possible to realize the electronic contract function (contract processing unit 114) in cooperation with each function such as qualification application (registration processing unit 111), electronic bidding (bidding processing unit 113), and contract management (contract management unit 112).

Figure 8 is a diagram showing an example of an electronic contract screen that can be used in various processes by the contract processing unit 114. The electronic contract screen includes an add related document button 801, a send contract document button 802, an agree to contract button 803, and an end button 804.

When the Add Related Books button 801 is pressed, for example, a screen is displayed for specifying related books to be added to the contract. The contractor can add related books using this screen.

When the contract document transmission button 802 is pressed, the contract information is transmitted to the successful bidder (bidder terminal 302). This function corresponds to step S313 in FIG. 5.

When the contract agreement button 803 is pressed, transaction information including information indicating that the contract has been agreed to is stored as a transaction in the blockchain system 400. This function corresponds to steps S314 and S315 in FIG. 5.

When the end button 804 is pressed, the processing by the contract processing unit 114 ends. At this time, information indicating the contract result may be sent to the contract management unit 112 (step S317 in FIG. 5).

Figure 9 is a diagram showing an example of the flow of an electronic contract on the successful bidder's side. The successful bidder is authenticated, for example, by the login processing function of the contract processing unit 114. The contract APL function of the contract processing unit 114 makes it possible to search for cases that are the subject of an electronic contract and to download contract information. The contract set corresponds to the downloaded contract information (which may include related documents).

The successful bidder can further specify the contract agreement using the contract APL function of the contract processing unit 114 and store the contract agreement as a transaction indicative of the contract agreement in the blockchain system 400.

Figure 10 is a diagram showing an example of the flow of an electronic contract on the client side. The client is authenticated, for example, by the login processing function of the contract processing unit 114. The client can input the contract contents to be included in the contract using the contract management unit 112 ("Contract Management" in Figure 10). In addition, the contract APL function of the contract processing unit 114 makes it possible to add related documents and search for other past contracts.

The purchaser can further specify a contract agreement using the contract APL function of the contract processing unit 114 and store the contract agreement in the blockchain system 400 as a transaction indicating the contract agreement.

Figure 11 is a diagram showing an example of the data structure of transaction information. The electronic document in Figure 11 corresponds to, for example, electronic data of a contract. Party A and Party B correspond to, for example, the successful bidder and the purchaser.

As shown in FIG. 11, the transaction information includes information that is an electronic signature on the hash value of an electronic document, the address of the public key, and information that indicates the transaction.

The hash value may be calculated by any method. For example, a calculation method using a hash function such as SHA-256 (Secure Hash Algorithm 256-bit) can be applied. SHA-256 calculates a hash value by summarizing data of any length into 256 bits.

The information indicating the transaction corresponds to, for example, information indicating an agreement to a contract. If it is specified that the contract is not agreed to, the information indicating that the contract is not agreed to may be stored as information indicating the transaction.

In this way, in this embodiment, the electronic document itself is not stored in the blockchain, and only the fact that a transaction (contract agreement) has been made is stored. Also, in this embodiment, for example, after A (the successful bidder) has stored in the blockchain storage unit 421 that he or she has reached an agreement, B (the purchaser) can reach an agreement on the same electronic document. In other words, it is possible to store in the blockchain that multiple contracting parties (A, B) have reached an agreement on the electronic data of a single contract.

The validity of transactions stored in the blockchain can be verified by a third party. Third parties include, for example, individuals (such as auditors) other than the contractor (successful bidder) belonging to the contractor, loan officers for the contractor, and residents related to the contracted project.

In this embodiment, the electronic document stored in the blockchain is an electronic bidding contract. As described above, electronic bidding may be permitted only to bidders who have been certified in a qualification screening and have been issued an IC card by a certification authority. For this reason, the electronic bidding contract may only correspond to a portion of the documents handled by the organization to which the bidder belongs.

However, since the electronic document storage method of this embodiment is a method that does not sign the electronic document itself, the electronic document to be stored does not need to be limited to an electronic bidding contract. In other words, the electronic document to be stored in the blockchain is not limited to an electronic bidding contract, and may be any electronic document.

For example, the target document can be expanded to the following document: Even when the target document is expanded in this way, the method of this embodiment can be applied without modification.
・Contracts and contract-related documents for discretionary contracts (applications, drawings, documents, etc.)
・Other general documents

As described above, the electronic contract system according to this embodiment does not have a storage unit for storing a blockchain internally, but instructs a blockchain system that has a storage unit for storing a blockchain to store transactions related to electronic documents. Therefore, it becomes easier to build a system that stores a blockchain related to a contract.

In addition, even if an existing system (such as an electronic bidding system) exists, transactions related to electronic documents can be stored in the blockchain simply by adding a function (contract processing unit) that links with the blockchain system.

If the existing system has a linkage function for the function to be added, such as a single sign-on function, the electronic contract system can be realized more easily by using such a linkage function.

In addition, if key information such as an IC card is used in an existing system, this key information can also be used for the electronic signature of a transaction stored in the blockchain system 400. This makes it possible to simplify the management of key information.

Next, the hardware configuration of the device (orderer terminal 301, bidder terminal 302) according to this embodiment will be described with reference to FIG. 12. FIG. 12 is an explanatory diagram showing an example of the hardware configuration of the device according to this embodiment.

The device according to this embodiment includes a control device such as a CPU 51, a storage device such as a ROM (Read Only Memory) 52 and a RAM (Random Access Memory) 53, a communication I/F 54 that connects to a network and communicates, and a bus 61 that connects each part.

The programs executed by the electronic contract system of this embodiment are provided pre-installed in ROM 52, etc.

The programs executed by the electronic contract system according to this embodiment may be configured to be provided as a computer program product by being recorded in an installable or executable format on a computer-readable recording medium such as a CD-ROM (Compact Disk Read Only Memory), a flexible disk (FD), a CD-R (Compact Disk Recordable), or a DVD (Digital Versatile Disk).

Furthermore, the program executed by the electronic contract system according to this embodiment may be configured to be stored on a computer connected to a network such as the Internet and provided by downloading it via the network. Also, the program executed by the electronic contract system according to this embodiment may be configured to be provided or distributed via a network such as the Internet.

The program executed in the electronic contract system according to this embodiment can cause a computer to function as each part of the electronic contract system described above. In this computer, the CPU can read the program from a computer-readable storage medium onto the main memory device and execute it.

Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the gist of the invention. These embodiments and their modifications are included in the scope and gist of the invention, and are included in the scope of the invention and its equivalents described in the claims.

100 Electronic contract system 111 Registration processing unit 112 Contract management unit 113 Bidding processing unit 114 Contract processing unit 115 Memory control unit 116 Authentication unit 121 Memory unit 201 Certification authority 202 Certification authority 301 Purchaser terminal 302 Bidder terminal 400 Blockchain system 411 Communication control unit 412 Smart contract processing unit 413 Management unit 421 Blockchain memory unit

Claims (12)

1. An electronic contract method executed in an electronic contract system connected to a blockchain system that stores transactions in a blockchain, comprising:
a contract processing step of receiving, from each of a first contractor and a second contractor, an instruction of agreement on a contract concluded between the first contractor and the second contractor;
a storage control step of transmitting to the blockchain system an instruction to store in the blockchain a first transaction indicating that the first contractor has agreed to the contract, and an instruction to store in the blockchain a second transaction indicating that the second contractor has agreed to the contract;
An electronic contract method including: The blockchain system is configured to store the transaction in the blockchain in accordance with a designated smart contract among a plurality of smart contracts each defining a process for each type of transaction;
The plurality of smart contracts include an electronic contract smart contract that stores a contract by the electronic contract system;
The storage control step includes transmitting, using the electronic contract smart contract, an instruction to store the first transaction in the blockchain and an instruction to store the second transaction in the blockchain.
The electronic contract method according to claim 1 . a registration processing step for performing a process of associating one or more public keys or wallet addresses assigned to a first user, who is either the first contract holder or the second contract holder, with a second user, who is a user of the blockchain system;
A second storage control step of transmitting an instruction to the blockchain system to store a third transaction indicating that the public key or wallet address has been associated with the second user in the blockchain,
The electronic contract method according to claim 1 . The storage control step includes transmitting to the blockchain system an instruction to store in the blockchain the first transaction digitally signed by a first private key assigned to the first contractor, and an instruction to store in the blockchain the second transaction digitally signed by a second private key assigned to the second contractor.
The electronic contract method according to claim 1 . The first contractor is an orderer for electronic bidding,
The second contractor is a successful bidder in the electronic bidding,
The contract indicates the contract for electronic bidding,
the first private key is a key assigned to the first contractor for processing the electronic bid;
the second private key is a key assigned to the second contractor for processing the electronic bid;
The electronic contract method according to claim 4. The first contractor is an orderer for electronic bidding,
The second contractor is a successful bidder in the electronic bidding,
The contract indicates the contract for electronic bidding,
The second private key is a key assigned to the second contractor who is not assigned a private key for processing the electronic bid, for use in electronically signing a transaction to be stored in the blockchain.
The electronic contract method according to claim 4. the first private key is a key assigned to the first contractor for processing the electronic bid;
The electronic contract method according to claim 6. The first private key is a key assigned to the first contractor who is not assigned a private key for processing the electronic bid, for use in electronically signing a transaction to be stored in the blockchain.
The electronic contract method according to claim 6. The first transaction includes information indicating that the first contractor has agreed to the contract and a hash value of an electronic document related to the contract;
the second transaction includes information indicating that the second contracting party has agreed to the agreement and a hash value of the electronic document;
The electronic contract method according to claim 1 . The contract processing step includes receiving, from each of a plurality of contracting parties including the first contracting party and the second contracting party, an instruction of agreement regarding a contract concluded between the plurality of contracting parties, the plurality of contracting parties including the first contracting party and the second contracting party;
The storage control step includes transmitting, to the blockchain system, a plurality of instructions to store, in the blockchain, a plurality of transactions indicating that each of the plurality of contracting parties has agreed to the contract.
The electronic contract method according to claim 1 . An electronic contract system connected to a blockchain system that stores transactions in a blockchain,
a contract processing unit that receives, from each of a first contractor and a second contractor, an instruction of agreement on a contract concluded between the first contractor and the second contractor;
a storage control unit that transmits to the blockchain system an instruction to store in the blockchain a first transaction indicating that the first contractor has agreed to the contract, and an instruction to store in the blockchain a second transaction indicating that the second contractor has agreed to the contract;
An electronic contract system comprising: A computer included in an electronic contract system connected to a blockchain system that stores transactions in a blockchain,
a contract processing step of receiving, from each of a first contractor and a second contractor, an instruction of agreement on a contract concluded between the first contractor and the second contractor;
a storage control step of transmitting to the blockchain system an instruction to store in the blockchain a first transaction indicating that the first contractor has agreed to the contract, and an instruction to store in the blockchain a second transaction indicating that the second contractor has agreed to the contract;
A program for executing.

Images