JP7550402B2 - Escrow processing method, system, and program using virtual currency - Google Patents

Description

The present invention relates to an escrow processing method, system, and program using virtual currency, and more specifically, to an escrow processing method, system, and program using virtual currency for processing transactions using virtual currency and providing a specified escrow service with high security.

In recent years, in trade business settlement systems, the introduction of an escrow service that manages deposits between sellers, buyers, and administrators has been proposed to ensure the security of transactions, and the incorporation of virtual currencies has also been requested. On the other hand, in providing an escrow service using virtual currencies, transaction processing related to settlement is necessary, and a multi-signature technology that requires multiple private keys to sign a transaction has been proposed for the purpose of improving security. In multi-signature technology, the number of signatures required is expressed as a fraction, such as "n/m," and indicates that a signature is made with n keys out of m private keys generated in advance. For example, in the case of Bitcoin transaction processing using 2/3 multi-signature, two private keys are required to generate and issue a transaction, so even if one of the three private keys is leaked, Bitcoin cannot be processed without the other private key, so a highly secure wallet can be constructed. In addition, it is very difficult for an attacker to simultaneously invade two or more platforms with different designs.

One such multi-signature technology has been proposed, for example, with the aim of providing a new signature system that can improve the reliability of multi-sig transactions. A transaction 80 signed and issued by an operator system 50 with a private key 542 is signed with a private key 342 corresponding to the private key 542, and a transaction reference request from a user terminal 40 is used as a trigger to collect multi-sig transactions 80M that require a signature with the private key 342. Upon receiving signature approval for the collected multi-sig transaction 80M from the user terminal 40, the signature-approved multi-sig transaction 80M is signed with the private key 342 (see Patent Document 1).
JP 2019-161302 A

However, while conventional technology using multi-signatures is effective simply for the sake of high security when providing escrow services using general virtual currencies, there is a problem with trade-oriented escrow systems in that simply adopting conventional multi-signature technology is not enough to meet the various system requirements.

The present invention has been made in consideration of the above-mentioned problems, and aims to provide an escrow processing method, system, and program using virtual currency that can provide an escrow service using virtual currency that is optimal for trade businesses.

The invention described in claim 1 is an escrow processing method using virtual currency by a distributed processing platform processed on a peer-to-peer network , comprising: a transaction generation step in which the distributed processing platform generates a payment transaction for transferring virtual currency corresponding to the amount to be remitted from the buyer to the seller in order to have an escrow contract execute settlement, and signs the transaction using a buyer private key and a seller private key generated for the buyer and the seller, and n-2 of n-1 administrator private keys, where n is an integer equal to or greater than 3, generated for an administrator; and a transaction execution step in which, upon receiving a payment instruction from the buyer, the distributed processing platform sends the signed payment transaction to the escrow contract to execute the sent payment transaction , and further comprises a fee collection step in which a predetermined administrator fee is settled to the administrator account from the virtual currency that has been previously remitted .

The invention described in claim 2 is characterized in that the method described in claim 1 further includes a deposit step in which the buyer transfers in advance virtual currency corresponding to the transfer amount to the address of the escrow contract that executes the transfer.

The invention as set forth in claim 3 is characterized in that in the method as set forth in claim 1 or 2 , the predetermined administrator fee is determined according to the remittance amount.

The invention described in claim 4 is characterized in that in the method described in any one of claims 1 to 3 , the payment transaction is a transaction for transferring a remittance amount from an address of an escrow contract to a seller.

The invention described in claim 5 is characterized in that the method described in any one of claims 1 to 4 further comprises a contract generation step of generating an escrow contract and deploying it on a distributed processing platform.

The invention as set forth in claim 6 is characterized in that in the method as set forth in claim 5 , the distributed processing platform is Ethereum.

The invention described in claim 7 is characterized in that, in the method described in any one of claims 1 to 6, the escrow contract broadcasts and executes the payment transaction upon receiving the payment transaction.

The invention described in claim 8 is characterized in that, in the method described in any one of claims 1 to 7, the transaction generation step encrypts a buyer private key based on a pass phrase that is not stored sent from the buyer, and encrypts and stores a seller private key based on a pass phrase that is not stored sent from the seller.

The invention described in claim 9 is a program for causing a computer to execute an escrow processing method using virtual currency, the escrow processing method comprising: a transaction generation step of generating a payment transaction for transferring virtual currency corresponding to the amount to be remitted from the buyer to the seller, in order to execute a remittance to an escrow contract, having the buyer and seller sign the transaction using a buyer private key and a seller private key generated for the buyer and seller by a distributed processing platform, and signing the transaction using n-2 of n-1 administrator private keys, where n is an integer greater than or equal to 3, generated for the administrator; and a transaction execution step of sending the signed payment transaction to the escrow contract upon receiving a payment instruction from the buyer , and executing the sent payment transaction, and further comprising a fee collection step of settling a predetermined administrator fee into the administrator account from the virtual currency that has been remitted in advance .

The invention described in claim 10 is a system for performing escrow processing using virtual currency, comprising a transaction generation means for generating a payment transaction to transfer virtual currency corresponding to the amount to be remitted from the buyer to the seller in order to have an escrow contract execute the remittance, and signing it using a buyer private key and a seller private key generated for the buyer and the seller, and n-2 of n-1 administrator private keys, where n is an integer greater than or equal to 3, generated for the administrator, and a transaction execution means for, upon receiving a payment instruction from the buyer , sending the signed payment transaction to the escrow contract and executing the sent payment transaction, and further comprising a fee collection step for settling a predetermined administrator fee to the administrator account from the virtual currency that has been remitted in advance .

According to the present invention, there is provided an escrow processing method using virtual currency by a distributed processing platform processed on a peer-to-peer network , comprising a transaction generation step of generating , by the distributed processing platform, a payment transaction for transferring virtual currency corresponding to the amount to be remitted from the buyer to the seller, in order to have an escrow contract execute settlement, and signing the transaction using a buyer private key and a seller private key generated for the buyer and the seller, and n-2 of n-1 administrator private keys, where n is an integer equal to or greater than 3, generated for an administrator, and a transaction execution step of, upon receiving a payment instruction from the buyer , sending the signed payment transaction to the escrow contract to execute the sent payment transaction , and further comprising a fee collection step of settling a predetermined administrator fee from the virtual currency previously remitted to the administrator account , thereby making it possible to provide an escrow service using virtual currency that is optimal for trade-oriented businesses.

1 is a diagram showing an overall system configuration of an embodiment of the present invention; FIG. 2 is a functional block diagram of an escrow core of one embodiment of the present invention. FIG. 2 illustrates an example of a transaction used in one embodiment of the present invention. FIG. 1 is a diagram for explaining the overall flow of a trade-related transaction according to one embodiment of the present invention. FIG. 2 illustrates an example of a transaction used in one embodiment of the present invention. FIG. 2 illustrates an example of a transaction used in one embodiment of the present invention. FIG. 2 is a diagram for explaining highly secure encryption according to an embodiment of the present invention. 1 is a flowchart illustrating a transaction generation process according to an embodiment of the present invention. 1 is a flowchart illustrating a transaction execution process according to an embodiment of the present invention. FIG. 1 is a diagram illustrating an example of a blockchain according to an embodiment of the present invention. 1 is a diagram for explaining a distributed processing network according to an embodiment of the present invention;

Below, an embodiment of the escrow processing method, system, and program using virtual currency of the present invention will be described with reference to the drawings. Note that the same reference numerals will be used to indicate the same processes and configurations even in different drawings.

In this embodiment, the parties who have conducted trade-related business make payments such as compensation in virtual currency, and this is only a process of monetary transactions after a transaction has been concluded, but it is not limited to this, and can also be a system that includes processing from the beginning of a transaction. For example, it can be applied to cases such as purchasing overseas products via the Internet, or conversely, exporting products to an overseas importer and receiving remittances, but it is not limited to this and can be applied to various transaction remittance scenes. That is, in general, trade-related businesses start with a customer development process, such as a simple listing of one's own products or services on a marketplace, followed by specific business negotiations and contract conclusions between buyers and sellers, and as a result, necessary fundraising, exchange of delivery documents, and delivery arrangements related to a tracking system, and finally settlement processing, but processing related to various processes other than such settlement processing can also be included in the processing of this embodiment. In this case, after acquiring information necessary for remittance at a trade-related portal site, the information can be passed to the escrow system of this embodiment to proceed with the processing, or it can be connected to a separately provided escrow system of this embodiment, where information necessary for settlement can be entered thereafter and information can be exchanged with buyers and sellers.

To explain the overall flow more specifically, FIG. 4 is a diagram for explaining the overall flow of a trade-related transaction according to one embodiment of the present invention. As shown in FIG. 4, when a seller lists a product (step 401), a buyer browses the product through the marketplace, and matching begins. After that, the seller contacts the buyer and negotiations begin (step 402). After the negotiation is completed, a sales contract is concluded, and then the seller requests an order on the system (step 403). After receiving the order, the seller signs the transaction using the private key of his/her wallet to generate a multi-sig escrow (step 404). The seller further signs using the private key of his/her wallet (step 405). (One of the two keys held by the escrow agent is automatically signed) and a multi-sig escrow is generated (step 406). The buyer deposits the trade amount into the escrow in cryptocurrency. After confirming that the deposit has been made, the seller ships the product (step 407).

After the product is delivered, the seller requests a withdrawal from the multi-sig escrow (step 408). Once the seller and the buyer give their permission, the funds are paid from the escrow to the wallet specified by the seller (step 409). At this time, a fee of, for example, 0.7% of the settlement amount is paid to the escrow agent to the wallet of the key that automatically signs among the keys held by the agent (step 4010). In this explanation, a fee of 0.7% is collected as a success fee, but this is not limited to this, and a success fee of an appropriate ratio can be used. That is, generally, the fee F = basic fee B + ratio R x total transaction amount T, and the ratio R can be changed depending on the quantity, for example, set to 0 up to the minimum guaranteed amount and gradually increased, etc., according to the system and business practices, but it is not limited to this and any method of calculating a success fee known in the technical field can be adopted.

In this embodiment, DIGITRAD or Ether is used as the virtual currency, and the software of this embodiment is deployed and executed on the Ethereum platform, but this is not limited to this, and various virtual currencies and various distributed platforms can be used. In this case, the software that performs various processes in this embodiment is distributed and processed on Ethereum nodes (such as node 1101 shown in FIG. 11), which are computers such as personal computers and servers connected to a distributed network as shown in FIG. 11. However, regardless of such a form, the principles of the present invention are applied to a system that broadcasts transactions and transfers money by having a specific server execute some of the processes or by using a specific database, and the system is configured by any method known in this technical field to realize an escrow service.

(System Configuration)
The operation and processing of the escrow system used in one embodiment of the present invention will be described below. FIG. 1 is a diagram showing the overall system configuration of one embodiment of the present invention. This system includes an escrow core 101 for executing the main functions of escrow processing, processing interfaces with buyers such as importers and sellers such as exporters, and controlling the entire system, and various software and contracts 121, 122, and 123 that operate on an Ethereum platform 102 that communicates with the escrow core 101 and executes various processes related to escrow, and are connected via a network 103. Note that while FIG. 1 illustrates the Ethereum platform 102 logically, in reality, processing is performed on a peer-to-peer network of multiple nodes 1101 shown in FIG. 11.

The buyer terminal 111 and seller terminal 112, which connect to a portal site (not shown) and perform marketing and negotiation processing for trade-related businesses, are basically connected to the network 103, whether wireless or wired, and can be, for example, a desktop computer. In this embodiment, the connection to the network 103 can be made not only by normal connection, but also by a mobile phone line, Wi-fi, BLUETOOTH (registered trademark), or other wireless network. Here, the terminals 111 and 112 can be desktop computers, tablet terminals, smartphones, mobile computers, etc., but any device, such as a general-purpose or dedicated terminal, can be used as long as it can basically perform transmission and reception, display images, and perform certain input operations using a touch panel, mouse, or keyboard. In this embodiment, in addition to the above functions, a carrier that delivers goods and the like, and a delivery management system (not shown) that manages the delivery status of the carrier are also connected via the network 103, and information necessary for operating the escrow system, such as a process for determining the execution of settlement, can be obtained.

Figure 2 is a functional block diagram of an escrow core according to one embodiment of the present invention. The escrow core mainly comprises an escrow core system 201 that executes the main functions of the escrow process and controls the entire system, and an escrow web service 202 that processes services for external systems, such as interfaces with buyers and sellers. Here, the escrow core system 201 executes the main functions of the escrow process, specifically, an address generation function that generates and manages addresses of users who use the escrow system of this embodiment, such as buyers and sellers, a multi-sig contract generation function that generates an escrow contract for each transaction, a DIGITRAD/Ether transfer function that instructs remittance or refund using virtual currencies DIGITRAD or Ether under specified conditions, and a document hash storage function, but in addition to this, it can also have a delivery information check function that receives delivery completion notifications from carriers and delivery information management organizations.

The escrow web service 202 also performs the main processes related to the interface with the buyer and seller, specifically, input/output and management functions for user accounts of parties involved in the transaction such as the buyer and seller, a function for generating and participating in the transaction of this embodiment by linking with a product purchase site, a function for processing DIGITRAD/Ether deposit information related to deposits from payers such as product importers, a function for storing transaction documents, and a function for inputting/modifying delivery information for receiving and managing delivery identification information at the time of product delivery. The escrow core can further have various functions according to other system configurations, such as a hardware security module (HSM) and an Ethereum node connection function. In this system, the buyer and seller perform various processes on the escrow core that provides the escrow service. The software or system that provides the escrow service in this way is sometimes called an escrow agent, but in this embodiment, the entity that provides part or all of the system's services, including such an escrow agent, is called the administrator.

Figure 3 is a diagram showing an example of a transaction used in one embodiment of the present invention. In general, in virtual currencies that use blockchain, the transfer of ownership (transfer) is written into data called a transaction and a specified procedure is followed to execute the remittance. In this embodiment, the escrow process is also started by writing the amount to be transferred and the recipient into the transaction. In this embodiment, the escrow process can be performed using a transaction such as that shown in Figure 3, which is also used in Bitcoin, for example. That is, the transaction details 302, such as the remittance amount, seller information 303, and buyer information 304 are written into transaction 301, and the buyer signs it. Specifically, the signature can be implemented by, for example, writing the hash value of the transaction encrypted with the buyer's private key.

In this embodiment, as described below, the buyer's private key and other information used by the escrow core system 201 when generating a transaction is encrypted and stored on disk for subsequent use after the transaction is generated. However, to prevent the escrow core system 201 from performing inappropriate processing using the private key, the private key is configured to be difficult to decrypt, but this is not limited to this and any configuration known in the art may be used.

In this embodiment, since the private key is also used for subsequent processing, it is encrypted and stored with a passphrase to avoid inappropriate processing, but it is also possible to avoid storing the private key altogether. In this embodiment, the escrow core system 201 can use the private key only when generating a transaction, but thereafter the private key cannot be used unless provided by the user, thereby preventing transactions from being generated solely at the system's discretion, thereby achieving secure transaction generation.

An escrow contract generated for each transaction is deployed on the Ethereum platform 102. The escrow contract is generated for each transaction related to the settlement of this embodiment, holds the transmitted deposit, and performs escrow processing upon instructions from the escrow core system 201. The escrow contract of this embodiment can implement a multi-signature (or multi-sig) described later, and can be configured so that processing cannot be performed without the private keys generated by the passphrases of both the seller and the buyer of this embodiment and the private key of the administrator, so that even if a third party breaks into the system, it cannot perform unauthorized remittances. In this embodiment, the multi-sig uses the private keys of the buyer, seller, and administrator, but is not limited to this, and any encryption method using multiple keys known in the technical field can be used. In this embodiment, the contract is deployed on the Ethereum platform 102 in this way and executed independently, so that once the escrow core system 201 generates a contract, it can only execute the processing of the generated transaction and cannot intervene in the processing, thereby further improving the security of the system.

Figure 10 is a diagram showing an example of a blockchain in one embodiment of the present invention. The blockchain 122 includes transaction documents 1001 and trade-related information, etc. 1002, and is used by each piece of software in this embodiment. When a transaction is executed, a new block is written into the transaction documents 1001, forming a blockchain. In addition, the trade-related information, etc. 1002 can also store information on paperwork procedures for verifying the identity of the customer, which is requested by the financial institution when opening a new account, and other information.

(Encryption process of this embodiment)
7 is a diagram for explaining encryption according to an embodiment of the present invention. In the escrow core 101 of this embodiment, all private keys and transactions are protected by an HSM (Hardware Security Module). The HSM used meets all of the following specifications, and even if data leakage occurs due to hacking or the like, the leaked data cannot be restored and cannot be used without the HSM.
・Encryption keys are stored in secure tamper-resistant hardware to prevent leakage of keys ・Complies with US Federal Standard FIPS140-2 Level 2/3 ・Encryption keys cannot be exported, and users cannot know the key value As shown in FIG. 7, in this embodiment, when stored on a disk 701, both private keys 702 and transactions 703 are encrypted and stored, and when the private keys and transactions are used, they are decrypted on demand using an HSM 721, and each process is performed as a decrypted plaintext private key 712 and plaintext transaction 713 on a memory 711, and for example, broadcast to an Ethereum node, but the plaintext data is used without being stored on the disk, thereby realizing a secure escrow service. Here, in the escrow core system 201 of this embodiment, as described above, the private key can be used only when a user approves and generates a transaction. Thereafter, to prevent the private key from being used at the discretion of the escrow core system 201, the encryption is performed using a passphrase that is obtained from the user each time and not stored, in addition to the encryption key stored in the HSM; however, this is not limited to this, and a similar process can be performed using any method known in the art to prevent inappropriate generation of transactions at the discretion of the escrow core system 201.

In this embodiment, for example, an HSM can be used to ensure high security, but the present invention can be implemented alone without such functionality and still be effective.

(Multi-signature support in this embodiment)
In this embodiment, so-called multi-signature encryption is adopted, in which four private keys are prepared in advance and a transaction is signed using three of the four private keys. Specifically, as shown in FIGS. 3, 5 and 6, a transaction 301 signed with a buyer's private key A 305 is signed with a seller's private key B 502 to become a transaction 501, and further signed with an administrator's private key C 602 to become a transaction 601. In the signature of this embodiment, in addition to the above three private keys, three private keys out of four private keys including the administrator's private key D prepared in advance are required for transaction processing. As a result, in this embodiment, the administrator's private key is required to process a transaction, and therefore the transaction cannot be processed with only the two private keys of the buyer and the seller. With this configuration, in this embodiment, the administrator can receive an appropriate fee as a remuneration for escrow processing, as described later.

In other words, in the past, administrators who provided escrow systems were only allowed to receive a fixed amount as remuneration for escrow processing, but in general, when the settlement amount becomes large, a contingency fee type commission that receives a remuneration appropriate to the settlement amount is desirable. However, in the past, if a transaction could be processed with only two private keys, the seller's and the buyer's, the administrator may have been able to collect the contingency fee, and there was a risk that the administrator would only be able to collect a fixed fee limited to the early stage of the procedure, such as before the remittance amount was finalized. In this embodiment, by requiring three private keys out of four private keys, including the administrator's private key D prepared in advance, it is possible to receive a contingency fee type commission, but since the conventional multi-signature technology only aims to strengthen security as described above, it is not possible to achieve such an objective, unlike this embodiment.

As described above, in this embodiment, a multi-signature is used that uses three of the four private keys, but since the principle of the present invention can be achieved by the administrator having a private key in addition to the private keys of the buyer and seller, the present invention is not limited to this and can be applied to a multi-signature that uses n-1 administrator private keys among the private keys for an integer n of 3 or more. In other words, by using an n/m multi-signature and having n-1 private keys for the administrator, it is possible to achieve the effect of earning a performance-based fee according to the present invention. In this case, the transaction is signed with a total of n private keys, including the private keys of the seller and buyer and n-2 of the n-1 private keys of the administrator. Note that, although m is usually m=n+1, this is not limited thereto.
8 is a flowchart showing a transaction generation process according to an embodiment of the present invention. As a prerequisite for carrying out various processes in this system, the escrow web service 202 provides the transaction parties, i.e., the buyer and seller, with an information input screen and the like, and generates an account by having them input the necessary information (step 801). Generally, if a trade transaction contract has been completed, the seller has the buyer and transaction information, so when the seller inputs the information, an account is generated and sent to both parties, but for example, each piece of information can be automatically sent from a trade-related portal site, or the buyer, an importer, can input the information. Similarly, when the transaction information is input by one or both parties or automatically (step 802), the escrow core system 201 generates private keys A and B for the buyer and seller, respectively (step 803). In addition, private keys C and D for the administrator are generated and stored by any method known in the art (step 804).

Furthermore, the escrow core system 201 generates a payment transaction for the amount of the transaction based on the obtained transaction information (step 805). As described below, the virtual currency equivalent to the payment amount is deposited in the escrow contract 402, so the payment transaction is a transaction for transferring the deposited virtual currency equivalent to the purchase amount from the escrow contract 402 to the seller 112.

Then, the generated transaction is signed with the buyer's buyer private key A, the seller's seller private key B, and the administrator's private key C (step 806). In this embodiment, by using the administrator's private key in addition to the private keys of both the buyer and seller, the transaction cannot be processed by the buyer and seller alone, and the administrator can obtain a commission based on success. The signed transaction encrypted in this way is encrypted and stored with a specified encryption key (step 807); specifically, it is encrypted and stored using passphrases α and β, etc.

As described above, encryption is performed using passphrases α and β, but the specific encryption method can be any method known in the art, and if there is no need to use private keys A or B in subsequent processing, they can be omitted and the escrow core system 201 can be made unable to generate new transactions. Also, even if a private key is to be used later, if the private key itself is generated randomly by the system, it can be presented to the user in advance and the user can then enter it themselves.

(Transaction Execution Processing of the Present Embodiment)
As described above, in this embodiment, a payment transaction is generated at the first stage of the escrow process, and then when certain conditions are met, that is, when a certain stage of the transaction at the seller is completed (for example, in the case of a product purchase transaction, the product arrives at the buyer (importer) and it is confirmed that there is no problem in executing the remittance, the transaction is executed and the money is remitted to the seller. In this way, an escrow process that safely executes the transaction is achieved.

Figure 9 is a flowchart showing the transaction execution process of this embodiment. As described above, this process begins when a transaction has been generated and a certain completion of the transaction is awaited. First, an escrow contract 401 is generated and deployed to the Ethereum platform 102 (step 901). Note that this step is placed before the next deposit confirmation, but is not limited to this, and can also be placed after the deposit confirmation, etc.

Next, it is confirmed whether the deposit has been made (step 903), and if it has not been made, the buyer is urged to make the deposit (step 904). If the deposit has been made, the seller is notified of this (step 905) and the seller is prompted to perform the transaction, for example, to ship the product. The completion of the deposit is not necessarily a requirement for the start of the transaction, but it can be determined as one element of the seller's judgment, taking other information into consideration. However, in general, if the deposit is confirmed, preparations for the transaction will be required to be made, otherwise subsequent processing such as payment will be delayed, so it is preferable to notify the seller without delay. In this embodiment, the deposit is made by sending money from the buyer 111 to the address of the escrow contract 402. As a result, the escrow contract 402 holds the virtual currency of the payment amount, so at the time of payment, a transaction can be executed to transfer the amount from the escrow contract 402 to the seller 112.

When making a refund, the amount of virtual currency deposited may not be held in the escrow contract 402, but may be deposited by a method known in the art, such as by holding the same amount of virtual currency separately. In this case, if the transaction is not fulfilled, a refund may be made by any method known in the art. It is also possible to generate a refund transaction in advance and execute a transaction to transfer the amount from the escrow contract 402 to the buyer 111.

When the seller has performed the transaction to a certain extent and the buyer has confirmed this and determined that there is no problem with transferring the money, the buyer instructs the escrow core 101 to that effect, which is confirmed (step 906). If the transaction has not been performed, the transaction is deemed unsuccessful and the contract is terminated (step 908). In this case, the process of refunding the deposited virtual currency to the buyer is carried out using any method known in this technical field.

On the other hand, if a remittance instruction is given, a payment transaction is sent to the contract for execution, and a fee according to the transaction amount is collected (step 907). The payment transaction is executed by the escrow contract 402 broadcasting it to the Ethereum node. The amount of the fee can be calculated by any method known in the technical field, but for example, a fixed fee can be set up to a certain transaction amount, and an additional fee according to the transaction amount can be added if the transaction amount exceeds that amount, but this is not limited to this. In addition, the fee can be collected by any method known in the technical field, but for example, a fee according to the remittance amount can be collected by separately transferring it to the administrator from the remittance amount at the time of remittance.

Generally, if there are no incomplete documents or objections and the transaction is completed within the deadline, the escrow process can be executed immediately, but since there is a possibility that some unforeseen situation may occur between the parties, the escrow core system 201 causes the escrow contract 402 to execute the payment transaction 24 hours after an instruction from the buyer, etc. (S1306). In this embodiment, the transaction is executed after waiting for 24 hours, but the waiting period is not limited to this and can be set arbitrarily depending on the transaction content, usage environment, etc.

(Tracking process)
In this embodiment, when the delivery process of the luggage or the like is involved, the seller basically performs the delivery process on the condition that the buyer deposits virtual currency equivalent to the purchase price, and the seller can also remit the deposited virtual currency to the seller on the condition that the delivery is completed by the carrier. The method of requesting delivery to the carrier and the specific procedure can be performed by any method known in the art, but since a unique delivery identification information is generally given when a delivery is requested, in this embodiment, the escrow core system 201 can obtain the delivery identification information from the seller or by itself and proceed with the process based on this. When the seller requests delivery from the carrier, the delivery identification information is set, and the escrow core can associate this with the corresponding transaction and obtain the delivery identification information by notifying the escrow web service 202 or having the carrier contact the seller. In other words, when the delivery process is performed and the delivery identification information is set, the arrival confirmation is set so that a notification is received when the delivery is completed. Currently, many domestic and foreign carriers have delivery management and tracking systems for the luggage they handle, either in-house or at external institutions and companies such as related information processing companies, and can obtain information on not only shipment and arrival but also passage through business offices on the way in real time. In recent years, in addition to these tracking systems for individual shipping companies, companies have appeared that collect and provide information on multiple shipping companies, and when shipping overseas in particular, the information provided by such companies can be used.

In this embodiment, for example, a service such as AfterShip can be used to track major shipping companies, including overseas companies, but this is not limited to this, and similar services provided by various companies can also be used. Confirmation of arrival of goods depends on the tracking service used, but in this embodiment, as described above, delivery identification information is set and a notification is received when delivery is completed (when the buyer receives the product), so that subsequent processing can be performed after waiting for a notification from the tracking service that the specified package has arrived. Here, the delivery identification information can be an inquiry number set when a delivery request is made to the shipping company, but is not limited to this and can be any identifiable information such as a product number as long as it can identify the package to be delivered. As described above, by incorporating tracking processing into the system of this embodiment, a more effective system can be constructed.

Claims (10)

An escrow processing method using virtual currency by a distributed processing platform processed on a peer-to-peer network,
A transaction generation step of generating, by the distributed processing platform, a payment transaction for transferring virtual currency corresponding to the remittance amount to be remitted from the buyer to the seller in order to execute settlement in an escrow contract, and signing the transaction using a buyer private key and a seller private key generated for the buyer and the seller, and n-2 of n-1 administrator private keys, where n is an integer equal to or greater than 3, generated for an administrator;
and a transaction execution step of, upon receiving a payment instruction from the buyer, transmitting the signed payment transaction to the escrow contract by the distributed processing platform to execute the transmitted payment transaction;
The method further comprises a fee collection step of settling a predetermined administrator fee from the previously transferred virtual currency into an administrator account. The method according to claim 1, further comprising a deposit step in which the buyer transfers in advance virtual currency corresponding to the transfer amount to the address of an escrow contract that executes the transfer. The method according to claim 1 or 2, characterized in that the predetermined administrator fee is determined according to the remittance amount. A method according to any one of claims 1 to 3, characterized in that the payment transaction is a transaction for transferring the remittance amount from the address of the escrow contract to the seller. A method according to any one of claims 1 to 4, further comprising a contract generation step of generating the escrow contract and deploying it on a distributed processing platform. The method of claim 5, wherein the distributed processing platform is Ethereum. 7. The method of claim 1, wherein the escrow contract broadcasts and executes upon receiving the payment transaction. A method according to any one of claims 1 to 7, characterized in that the transaction generation step encrypts the buyer private key based on a passphrase sent by the buyer that is not stored, and encrypts and stores the seller private key based on a passphrase sent by the seller that is not stored. A program for causing a computer to execute an escrow processing method using virtual currency, the escrow processing method comprising:
A transaction generation step of generating a payment transaction for transferring virtual currency corresponding to a remittance amount to be remitted from a buyer to a seller in order to execute remittance to an escrow contract, having the buyer and the seller sign the transaction using a buyer private key and a seller private key generated for the buyer and the seller by a distributed processing platform, and signing the transaction using n-2 administrator private keys out of n-1 administrator private keys, where n is an integer equal to or greater than 3, generated for the administrator;
and a transaction execution step of, upon receiving a payment instruction from the buyer, transmitting the signed payment transaction to the escrow contract to execute the transmitted payment transaction;
The program further comprises a fee collection step of settling a predetermined administrator fee from the virtual currency transferred in advance into an administrator account. A system for performing escrow processing using virtual currency,
A transaction generating means for generating a payment transaction for transferring virtual currency corresponding to a remittance amount to be remitted from a buyer to a seller in order to execute remittance to an escrow contract, and signing the transaction using a buyer private key and a seller private key generated for the buyer and the seller, and n-2 of n-1 administrator private keys, where n is an integer equal to or greater than 3, generated for an administrator;
and a transaction execution means for, upon receiving a payment instruction from the buyer, transmitting the signed payment transaction to the escrow contract to execute the transmitted payment transaction.
The system further comprises a fee collection means for settling a specified administrator fee from the virtual currency transferred in advance into an administrator account.

Images