JPWO2020027269A1 - Remittance methods, systems and programs - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable quick and reliable transactions by escrow using virtual currency. SOLUTION: The SHC core 101 for executing the main function of the remittance process, processing the interface with the purchaser and the product provider, and controlling the entire system, and receiving the instruction from the SHC core 101. The other SHC process 102 that executes various processes related to the SHC is provided, and is connected via the network 103. Necessary for operating the remittance system, such as the process of determining the execution of remittance by connecting 121 such as a carrier that delivers cargo such as goods and a delivery management system that manages the delivery status by the carrier via the network 103. Information can be obtained. [Selection diagram] Fig. 1

Description

The present invention relates to a remittance method, a system and a program, and more specifically, a remittance method, a system and a program for remittance of expenses such as purchase of goods using virtual currency.

In recent years, virtual currencies have come to be used in addition to the conventional legal tender as a payment method for consideration and the like in various transactions. As such a virtual currency, a service using "Bitcoin (registered trademark)" premised on a decentralized platform has already been widely provided. In the implementation of virtual currencies such as Bitcoin, a technology called "blockchain" is used. Generally, in a blockchain, a transaction, which is transaction data of virtual currency whose authenticity is guaranteed by using a hash function and a public key encryption method, is sent to all terminals connected by a P2P network using virtual currency. Is sent by broadcast. The transmitted transactions are verified for authenticity by a terminal called a miner, and when approved, they are grouped into blocks and recorded in a transaction ledger called a blockchain. In addition, since remittance using virtual currency is possible without going through the account of a specific financial institution, it is particularly effective for remittance related to transactions with foreign countries such as import / export. In other words, when making a bilateral remittance, if the conventional interbank transaction is adopted, the remittance will be between a domestic bank and a foreign bank, so the procedure is complicated, the fee is high, and the processing time is long. , Overseas remittance by virtual currency without going through a bank account has many merits.

In Patent Document 1, for the purpose of efficiently linking blockchains, a permission request transaction including a payment transaction for virtual currency blockchain BC1 is sent to a P2P network of content rights management blockchain BC2. The right holder device 2 transmits the license transaction according to the license request transaction to the P2P network of the content right management blockchain BC2, and also transmits the payment transaction included in the license request transaction to the virtual currency blockchain BC1. Therefore, a system is disclosed in which users and right holders can manage payment of consideration and viewing permission only by monitoring the content right management blockchain BC2 (see Patent Document 1).

On the other hand, in order to ensure the safety of payment of the price when purchasing the product and to provide the product reliably, the product price is deposited in advance and the transfer of funds is stopped until the predetermined requirements are met. Various systems are provided as so-called escrow service systems. In addition, in such an escrow service system, in general, the arrival of goods is recognized by the contact from the purchaser and payment is executed, but in recent years, many transportation companies and transportation companies have a delivery management system or a delivery management system. Since it has a baggage tracking system, a system for determining payment using this information has also been proposed. For example, in Patent Document 2, when order information is received from the purchaser system for the purpose of smoothly performing credit processing between the product purchaser and the seller, billing to the purchaser, payment processing to the seller, and the like. , Sends order information and request to start credit processing to the purchaser system, performs credit processing after confirming the purchaser, and includes baggage identification information such as the estimated shipping date and invoice number from the seller system. By receiving the shipping schedule information, accumulating these as transaction information in association with the order information, and periodically collating this transaction information with the baggage tracking information, the transaction information newly collected has been collected. Is disclosed, and a settlement intermediary system is disclosed in which billing processing and payment processing are automatically advanced (see Patent Document 2).
JP-A-2017-204070 Japanese Unexamined Patent Publication No. 2002-81342

However, even if an X-law system is constructed using virtual currency, the arrival of luggage must rely on information from the purchaser of the product, and even if the tracking system of Patent Document 2 is used, payment by credit card is assumed. Therefore, the credit is settled after the product arrives, and it takes a considerable period of time to deposit to the product provider, so there is a problem that an appropriate escro service system using virtual currency cannot be provided. There is.

The present invention has been made in view of the above-mentioned conventional problems, constructs a remittance system that provides an optimal escrow service for virtual currencies, achieves low fees and quick remittances, which are the merits of virtual currencies, and at the same time. The purpose is to provide remittance methods, systems and programs that enable secure transaction execution by confirming arrival of goods based on delivery management information.

The invention according to claim 1 is a remittance method using virtual currency, and receives in advance from the consignee an amount of virtual currency that satisfies the costs incurred in a transaction between the consignor and the consignee to the deposit address. Information that a deposit step, a transaction generation step that generates a transaction for transferring costs from a deposit address to a shipper, and a package sent from a shipper to a consignee based on a transaction by a predetermined carrier have arrived at the consignee. It is characterized by including a arrival confirmation step received from a delivery management organization related to a transportation agency, and a transaction execution step of executing a generated transaction after receiving arrival information.

The invention according to claim 2 is a transaction for buying and selling a predetermined product at an expense in the method according to claim 1, and the consignee and the shipper are the purchaser and the product provider, respectively. It is characterized by.

The invention according to claim 3 is characterized in that, in the method according to claim 1 or 2, the transaction is executed by broadcasting the transaction.

The invention according to claim 4 is the method according to any one of claims 1 to 3, wherein when the deposit step receives the virtual currency at the deposit address, it further transmits and receives information to the effect that it has been received by the shipper. It is characterized in that it further includes a delivery instruction step in which the shipper instructs a predetermined transportation agency to deliver the information to that effect.

The invention according to claim 5 is characterized in that, in the method according to claim 4, the arrival information is specified and received by the delivery identification information received from the delivery management organization.

The invention according to claim 6 is characterized in that, in the method according to claim 5, the shipper instructs a predetermined transportation agency to deliver and transmits the delivery identification information received from the delivery management agency. ..

In the invention according to claim 7, in the method according to any one of claims 1 to 5, the consignee transmits to the deposit address an amount of virtual currency that satisfies the costs incurred in the transaction when the transaction is completed. It is characterized by that.

The invention according to claim 8 is characterized in that, in the method according to any one of claims 1 to 7, the transaction is signed by both the shipper and the consignee.

The invention according to claim 9 states that, in the method according to any one of claims 1 to 8, the transaction executes the generated transaction after a predetermined time has elapsed after receiving the arrival information. It is a feature.

The invention according to claim 10 is a program for causing a computer to execute a remittance method using virtual currency, and the remittance method is a virtual currency having an amount satisfying a transaction incurred in a transaction between a shipper and a consignee. A deposit step that is received from the consignee to the deposit address in advance, a transaction generation step that generates a transaction that transfers the cost from the deposit address to the shipper, and a transaction generation step that generates a transaction from the consignee to the consignee based on the transaction by a predetermined transportation agency. A receipt confirmation step that receives information that the shipment to be sent has arrived at the consignee from the delivery management agency related to the transportation agency, and a transaction execution step that executes the generated transaction after receiving the arrival information. It is characterized by being prepared.

The invention according to claim 11 is a system for causing a computer to execute a remittance method using virtual currency, and the consignee previously receives a virtual currency in an amount satisfying the cost incurred in a transaction between the consignor and the consignee. The depositor receives the deposit to the deposit address, the transaction generator generates a transaction to transfer the cost from the deposit address to the shipper, and the consignee receives the cargo sent from the shipper to the consignee based on the transaction by a predetermined transportation agency. It is characterized in that it includes a arrival confirmation means for receiving information that it has arrived at the transportation agency from a delivery management organization related to the transportation agency, and a transaction execution means for executing a generated transaction after receiving the arrival information. ..

The invention according to claim 12 is a device for controlling a remittance method using virtual currency, which is a contract generating means for generating a contract for executing escrow, and a cost incurred in a transaction between a shipper and a consignee. A deposit instruction means for transmitting the amount of virtual currency to be satisfied from the consignee to the address of the contract generated in advance, a transaction generation means for generating a transaction for transferring the cost from the contract address to the shipper, and a predetermined transportation agency. It is generated after receiving the arrival confirmation means that receives the information that the shipment sent from the shipper to the consignee based on the transaction has arrived at the consignee from the delivery management organization related to the transportation agency, and the arrival information. It is characterized by providing a transaction execution means for transmitting a transaction to a contract and executing the transaction.

According to the present invention, a deposit step of receiving a virtual currency in an amount satisfying the cost incurred in a transaction between a shipper and a consignee from a consignee to a deposit address in advance, and a transfer of the cost from the deposit address to the consignor. A receipt confirmation that receives from the delivery management agency associated with the carrier the transaction generation step that generates the transaction and the information that the shipment sent from the shipper to the consignee by the given carrier based on the transaction has arrived at the consignee. Since it includes a step and a transaction execution step of executing the generated transaction after receiving the arrival information, escrow using virtual currency enables quick and reliable transaction.

It is a whole system block diagram of one Embodiment of this invention. It is a functional block diagram of the SHC core of one Embodiment of this invention. It is a figure for demonstrating another SHC treatment of one Embodiment of this invention. It is a figure for demonstrating the Ethereum platform of one Embodiment of this invention. It is a figure which shows an example of the SHC credit information of one Embodiment of this invention. It is a functional block diagram of the cold wallet of one Embodiment of this invention. It is a figure for demonstrating the encryption using HSM of one Embodiment of this invention. It is a flowchart which shows the transaction start processing of one Embodiment of this invention. It is a flowchart which shows the tracking-related processing of one Embodiment of this invention. It is a flowchart which shows the transaction execution processing of one Embodiment of this invention. It is a flowchart which shows the changed transaction start processing of one Embodiment of this invention. It is a flowchart which shows the changed transaction generation, execution processing of one Embodiment of this invention.

Hereinafter, embodiments of the remittance method, server, and program using the virtual currency of the present invention will be described with reference to the drawings. Even in different drawings, the same reference numerals are used to indicate the same processing and configuration.

In this embodiment, the party who has made some kind of commercial transaction pays the consideration etc. in virtual currency, and it is only the processing of the money exchange part after the state where the transaction is completed, but it is not limited to this. , It can also be a system that includes processing from the beginning of the transaction. In addition, the remittance system of the present embodiment can be used for all transactions involving the transfer of money, but it is premised that a carrier or the like, which is a transportation institution, delivers goods or other cargo in the transaction. Typically, it is possible to purchase an overseas product via the Internet, but the present invention is not limited to this and can be applied to the remittance scene in various transactions. That is, for example, the system of the present embodiment operates at the stage where the purchaser confirms the product of the product provider, decides to purchase the product on the sales site provided by the overseas business operator, and proceeds to the payment processing. In this case, after acquiring the information necessary for remittance on the sales site, the information can be passed to the remittance system of the present embodiment to proceed with the processing, or the purchase is decided on the sales site and payment processing is selected. Then, it is connected to the remittance system of the present embodiment provided separately, and it is also possible to input information necessary for remittance and exchange information with the purchaser and the product provider.

Further, in the present embodiment, Shake Hands Control (hereinafter referred to as SHC) or Ether is used as the virtual currency, and the software of the present embodiment is deployed and executed on the Ethereum platform, but the present invention is not limited to various virtual currencies. , Various distributed platforms can be used. In this case, the software that performs various processes of the present embodiment is distributed and processed on the Ethereum node, which is a computer such as a personal computer or a server, which is connected to the network. The system can be configured by the method known in the present embodiment by executing a part of the processing by a specific server or using a specific database.

(System configuration)
The operation and processing of the remittance system used in one embodiment of the present invention will be described below. FIG. 1 is an overall system configuration diagram of an embodiment of the present invention. In this system, the main functions of the remittance process are executed, the interface with the purchaser and the product provider is processed, and the instructions from the SHC core 101 and the SHC core 101 for controlling the entire system are received. The other SHC process 102 that executes various processes related to the SHC is provided, and is connected via the network 103.

In addition to the nodes connected to these networks, a cold wallet 131 that is isolated from the network and protects main data from unauthorized operations via the network is provided. Data can be exchanged between the cold wallet 131 and the SHC core 101 using a removable memory device or the like other than the always-connected network. In the present embodiment, in addition to the above functions, 121 such as a carrier that delivers cargo such as goods and a delivery management system that manages the delivery status by the carrier are connected via the network 103 to determine the execution of remittance. It is possible to obtain the information necessary for operating the remittance system, such as the processing to be performed.

Further, the purchaser terminal 111 that connects to a sales site (not shown) or the like to perform product purchase processing is basically connected to the network 103 regardless of whether it is wireless or wired, and can be, for example, a desktop computer. In the present embodiment, the connection with the network 103 can be made by a mobile phone line or a wireless network such as Wi-fi or BLUETOOTH (registered trademark) in addition to the normal connection. Here, the terminals 111 and 112 can be a desktop personal computer, a tablet terminal, a smartphone, a mobile personal computer, or the like, but basically they can perform transmission / reception, display an image, and input a certain value with a touch panel, a mouse, or a keyboard. Any device such as a general-purpose terminal or a dedicated terminal can be used as long as it can be operated.

FIG. 2 is a functional block diagram of the SHC core according to the embodiment of the present invention. The SHC core mainly includes an SHC core system 201 that executes the main function of remittance processing and controls the entire system, and an SHC web service 202 that processes services for external systems such as interfaces with purchasers and product providers. Here, the SHC core system 201 has a main function of remittance processing, specifically, an SHC address generation function for generating and managing addresses of users who use the remittance system of the present embodiment, such as a purchaser and a product provider. Multi-sig contract generation function that generates SHC escro contract for each transaction, SHC / Ether transfer function that instructs remittance or refund by virtual currency SHC or Ether under predetermined conditions, document hash storage function and delivery information management Execute a delivery information check function that receives a delivery completion notification from the institution.

In addition, the SHC web service 202 provides main processing related to the interface with the purchaser and the product provider, specifically, the input / output and management function of the user account of the person involved in the transaction such as the purchaser and the product provider, and the product purchase. Link from the site etc. to the transaction generation and participation function of this embodiment, the SHC / Ether deposit information processing function regarding the deposit from the payer such as the product purchaser, the transaction document storage function, and the delivery identification information at the time of product delivery. Execute the delivery information input / correction function such as receipt management. The SHC core can have various other functions depending on the system configuration, such as a hardware security module (HSM) and an Ethreum node connection function, which will be described later.

FIG. 3 is a diagram for explaining another SHC treatment according to the embodiment of the present invention. In the present embodiment, the SHC core 101 executes the entire processing such as address management of transaction-related parties, transaction generation, transaction execution timing management, and instructions, but processing of virtual currencies such as SHC and Ether is performed. Another software deployed by the SHC core system 201 and running on the Ethereum platform 301 runs. In connection with this, the blockchain 302 of SHC credit information and other 303 are also provided on the network.

FIG. 4 is a diagram for explaining an Ethereum platform according to an embodiment of the present invention. The software particularly required in this embodiment is the SHC token contract 401 and the SHC escrow contract 402 generated for each transaction. The SHC Token Contract 401 manages SHC tokens, and it is assumed that specific functions required by various token management software in the present technical field are prepared.

Further, the SHC escrow contract 402 is generated for each transaction related to the remittance of the present embodiment, holds the transmitted deposit, and performs the remittance process according to the instruction from the SHC core. The SHC escrow contract 402 of the present embodiment can implement multisig, so that processing cannot be performed without the passphrases of both the seller and the buyer, and in the present embodiment, both the product provider and the purchaser. Therefore, even if a third party invades the system, it is possible to make a configuration in which unauthorized remittance cannot be performed.

FIG. 5 is a diagram showing an example of SHC credit information according to an embodiment of the present invention. The blockchain 302 of SHC credit information includes transaction documents 501, KYC information, and the like 502, and is used in each software of the present embodiment. When a transaction is executed, a new block is written in the transaction document 501 to form a blockchain. In addition, 502 such as KYC information is a so-called Know Your Customer (KYC), that is, a general term for document procedures for verifying the identity of a customer, which is required by a financial institution when opening a new account, and includes other information. Can be stored.

(Security support of this embodiment)
The remittance system of the present embodiment has various security functions for enabling secure transactions, and the main ones will be described below. FIG. 6 is a functional block diagram of a cold wallet according to an embodiment of the present invention. In this embodiment, the private key and the illiquid currency are stored in the cold wallet 131, which is isolated from the network offline, and the data is retrieved and used when necessary. Specifically, it can be mounted using a removable memory such as a USB memory, but the present invention is not limited to this, and various methods known in the present technical field can be used. The cold wallet 131 includes an SHC cold wallet system 602 for managing important data offline, as well as an HSM 601 described later.

FIG. 7 is a diagram for explaining encryption using HSM according to an embodiment of the present invention. In the SHC core 101 of the present embodiment, all private keys and transactions are protected by the HSM (Hardware Security Module). The HSM used meets all of the following specifications, and even if data leaks due to hacking or the like, the leaked data cannot be restored and cannot be used without the HSM.
-The encryption key is stored in secure tamper-resistant hardware to prevent the key from leaking.-Compliant with the US federal standard FIPS140-2 level 2/3.-The encryption key cannot be exported and the user can use the key value. As shown in FIG. 7, in the present embodiment, when saving on the disk 701, both the private key 702 and the transaction 703 are encrypted and saved, and the HSM721 is stored when the private key and the transaction are used. It is used to decrypt on demand, and on memory 711, each process is performed as a plaintext private key 712 that has been decrypted and a plaintext transaction 713, for example, broadcasting to an Ethereum node, but the plaintext data is stored on disk. Can be used without saving to realize a secure escrow service.

(Transaction start processing of this embodiment)
In the present embodiment, for convenience of explanation of the present invention, the purchaser and the product provider complete the sales transaction at a predetermined sales site, and the payment of the price and the delivery procedure of the product will be performed from now on. The money transfer system of the embodiment is not limited to this, and can be incorporated into, for example, the sales transaction processing of the sales site, or the system of the present embodiment can be continued to proceed by receiving necessary information from the sales site. Further, since the present embodiment only executes the remittance processing accompanied by the movement of the luggage, the target is not limited to such a sales transaction.

FIG. 8 is a flowchart showing a transaction generation process according to an embodiment of the present invention. As a premise of performing various processes in this system, the SHC web service 202 provides an information input screen or the like to the trading parties, that is, the purchaser and the product provider, and causes the necessary information to be input to generate an account (S801). Generally, if the sales transaction is completed, the product provider has the purchaser and transaction information, so when the product provider enters the information, an account is generated and sent to both parties. However, for example, each information can be automatically transmitted from the sales site, or the purchaser can enter the information. Similarly, when transaction information is entered from one or both parties or automatically (S802), the SHC core system 201 generates their respective private keys from the purchaser and product provider passphrases α and β. (S803).

Further, the SHC core system 201 generates a payment transaction and a refund transaction of the transaction amount based on the obtained transaction information (S804), but the SHC corresponding to the payment amount is deposited in the SHC escrow contract 402 as described later. Therefore, the payment transaction is a transaction for transferring the deposited SHC corresponding to the price from the SHC escrow contract 402 to the product provider 112, and the refund transaction is the transaction for transferring the deposited SHC when the transaction is not fulfilled to the SHC escrow. It is a transaction to transfer from the contract 402 to the purchaser.

After that, the generated transaction is signed with the passphrases α and β of the product provider and the purchaser (S805), and the signed transaction is encrypted and saved (S806), but the passphrases α and β are saved. It is also possible to prevent the SHC core system 201 from generating new transactions.

(Tracking process of this embodiment)
With the above processing, the conditions for proceeding with the remittance processing and the delivery processing are satisfied, so that the actual processing can be executed. In the present embodiment, the product provider basically performs the delivery process on the condition that the purchaser deposits the SHC for the price, and remits the deposited SHC to the product provider on the condition that the delivery is completed, but other conditions. The process may be executed first, or additional conditions may be added to determine whether or not to execute the process. In addition, the specific processing and procedure of deposit can be performed by any method known in the present technical field, and will not be described here. Furthermore, the method of requesting delivery to the carrier and the specific procedure can be executed by any method known in the present technology, but in general, when requesting delivery, unique delivery identification information is given. Therefore, also in the present embodiment, the SHL core system 201 obtains the delivery identification information from the product provider or by itself, and proceeds with the process based on the delivery identification information.

FIG. 9 is a flowchart showing a tracking-related process according to an embodiment of the present invention. First, an SHC escrow contract is generated and deployed on the Ethereum platform (S901). This step is placed before the next confirmation of deposit, but is not limited to this, and may be after confirmation of deposit or after delivery of goods.

Next, it is confirmed whether or not the deposit has been completed (S903), and if it has not been deposited yet, the purchaser is urged to deposit (S904). If the deposit is confirmed, the product provider is notified to that effect (S905) and the product is urged to be shipped. Here, the completion of deposit is not necessarily a requirement for starting the delivery process, but it can be determined by taking other information into consideration as one element of the product provider's determination of shipment. However, in general, if the deposit is confirmed and the delivery preparation is not started, the subsequent processing such as payment will be delayed, so it is preferable to notify the product provider without delay. Further, in the present embodiment, the deposit or deposit is specifically made by remittance from the purchaser 111 to the address of the SHC escrow contract 402. As a result, the SHC of the payment amount is held by the SHC escrow contract 402. Therefore, at the time of payment, the transaction of transferring from the SHC escrow contract 402 to the product provider 112 may be executed.

At the time of refund, a transaction for transferring from SHC escrow contract 402 to purchaser 111 may be executed. Further, even if the SHC of the deposit amount is not held in the SHC escrow contract 402, the deposit can be made by a method known in the present technology such as separately holding the same amount of SHC. In this case, as the above-mentioned transaction, if the refund can be performed by another method, the refund transaction may not be generated and only the payment transaction may be generated.

When the product provider requests delivery from the carrier, delivery identification information is set, so the SHC core will deliver it in association with the corresponding transaction by notifying the SHC web service 202 or contacting the carrier. Make it possible to obtain identification information.

Therefore, it is confirmed whether or not the delivery processing has been performed within the period (S906), and if the processing is not performed, the transaction is considered unsuccessful and the SHC core system 201 sends a refund transaction to the SHC escrow contract 402 to execute the transaction. The refund process is executed (S908) and the process ends. Here, the period for ending the transaction differs for each transaction and is generally determined at the stage when the sales transaction is completed, so that it can be set according to the information. If there is no such provision, the possible period may be determined by any method known in the art. In addition, the SHC escrow contract 402 that received the refund transaction confirms that it is a genuine transaction by checking whether it is signed with two private keys if it supports multisig, and then executes the contents. can do. This process is the same when executing a payment transaction.

On the other hand, when the delivery process is performed and the delivery identification information is set, the arrival confirmation is set so as to receive the notification when the delivery is completed (S907). Currently, many domestic and overseas carriers are external organizations / companies such as their own or related information processing companies, and have a delivery management and tracking system for the packages they handle. Information such as is also available in real time. In recent years, not only such tracking systems for individual shipping companies, but also companies that collect and provide information on multiple shipping companies have appeared, and especially when shipping to overseas, such companies provide. Information can also be used.

In the present embodiment, for example, a service such as AfterShip enables tracking of major carriers including overseas, but the same type of service provided by various companies can be used. Confirmation of arrival depends on the tracking service used, but in this embodiment, as described above, when the delivery identification information is set and the delivery is completed (when the purchaser receives the item), a notification to that effect is given. Since it is set in advance to receive it, it is sufficient to wait for the notification from the tracking service that the specified baggage has arrived and then perform the subsequent processing. Here, the delivery identification information can be an inquiry number set when a carrier is requested to deliver, but the delivery identification information is not limited to this, and any of the product numbers and the like can be specified as long as the package to be delivered can be specified. It can also be discriminating information.

(Transaction execution process of this embodiment)
As described above, if the delivery process is not performed within the predetermined period, the transaction is terminated, but in the present embodiment, if the delivery is started, it is based on the information of the completion of the delivery without relying on the contact from the purchaser or the like. It is possible to judge the situation and automatically execute the specified processing such as payment to the product provider. Various processing is possible depending on the contract content and situation of the transaction, but in this embodiment, the transaction is executed by making the following judgment according to the arrival time and situation, especially in consideration of the transaction with overseas. Perform processing.

FIG. 10 is a flowchart showing a transaction execution process according to an embodiment of the present invention. As described above, the delivery process is performed (delivery identification information is added), and this process is started from the state of waiting for the arrival notification. First, it is confirmed whether or not there is any incompleteness in the documents (S1001). Unlike domestic delivery, especially when importing and exporting is involved, various documents are required because it is a bilateral transaction. The details will not be explained here, but if the documents are incomplete, it may be necessary to cancel the transaction anymore depending on the degree of the incompleteness. The SHC core system 201 sends and executes a payment transaction or a refund transaction stored in the SHC escrow contract 402 (S1004).

In addition, as with the delivery process, delivery may not be completed due to some accident, etc. In this case as well, the transaction should be canceled after the predetermined deadline, so the transaction is also canceled in this embodiment, and SHC is used. The core system 201 causes the SHC escrow contract 402 to execute a refund transaction (S1005). Even if the delivery is completed within the deadline, if there is an objection from either party, it may be necessary to cancel the transaction anymore depending on the content, so in this case, it is generally decided by discussion between both parties. Depending on the content, the SHC core system 201 causes the SHC escrow contract 402 to execute a payment transaction or a refund transaction (S1004).

If the delivery is completed within the deadline without any incomplete documents or objections, it will be treated as a successful transaction, but there may be some unforeseen circumstances between the parties, so a notice of arrival. After 24 hours have passed, the SHC core system 201 causes the SHC escrow contract 402 to execute a payment transaction (S1006). In the present embodiment, the transaction is executed after waiting for 24 hours, but the waiting period is not limited to this, and can be arbitrarily set depending on the transaction content, the usage environment, and the like.

Here, the execution of the payment transaction and the refund transaction is executed by the SHC escrow contract 402 broadcasting to the Ethereum node.

(Another transaction start process and transaction execution process of this embodiment)
In the present embodiment, in addition to the above-mentioned processing, the following processing that has been partially modified is also possible. That is, since the tracking process including the deposit-related process described above is the same in this process, it will not be described below. Therefore, transaction processing is particularly different in this processing. This will be described below with reference to FIGS. 11 and 12.

FIG. 11 is a flowchart showing a transaction start process according to an embodiment of the present invention. As a premise of performing various processes in this system, the SHC web service 202 provides an information input screen or the like to the trading parties, that is, the purchaser and the product provider, and causes the necessary information to be input to generate an account (S1101). Generally, if the sales transaction is completed, the product provider has the purchaser and transaction information, so when the product provider enters the information, an account is generated and sent to both parties. However, for example, each information can be automatically transmitted from the sales site, or the purchaser can enter the information. Similarly, when transaction information is entered from one or both parties or automatically (S1102), the SHC core system 201 generates their respective private keys from the purchaser and product provider passphrases α and β. And save (S1103).

As described above, if the delivery process is not performed within the predetermined period, the transaction is terminated, but in the present embodiment, if the delivery is started, it is based on the information of the completion of the delivery without relying on the contact from the purchaser or the like. It is possible to judge the situation and automatically execute the specified processing such as payment to the product provider. Various processing is possible depending on the contract content and situation of the transaction, but in this embodiment, the transaction is executed by making the following judgment according to the arrival time and situation, especially in consideration of the transaction with overseas. Perform processing.

FIG. 12 is a flowchart showing a transaction execution process according to an embodiment of the present invention. As described above, the delivery process is performed (delivery identification information is added), and this process is started from the state of waiting for the arrival notification. First, it is confirmed whether or not there is any incompleteness in the documents (S1001). Unlike domestic delivery, especially when importing and exporting is involved, various documents are required because it is a bilateral transaction. The details will not be explained here, but if the documents are incomplete, it may be necessary to cancel the transaction anymore depending on the degree of the incompleteness. The SHC core system 201 uses the stored passphrase to generate a payment or refund transaction and send it to the SHC escrow contract 402 for execution (S1201).

In addition, as with the delivery process, delivery may not be completed due to some accident, etc. In this case as well, the transaction should be canceled after the predetermined deadline, so the transaction is also canceled in this embodiment, and SHC is used. The core system 201 generates a refund transaction using the stored passphrase and sends it to the SHC escrow contract 402 for execution (S1202). Even if the delivery is completed within the deadline, if there is an objection from either party, it may be necessary to cancel the transaction anymore depending on the content, so in this case, it is generally decided by discussion between both parties. Depending on the content, the SHC core system 201 generates a payment transaction or a refund transaction and executes it in the SHC escrow contract 402 (S1201).

If the delivery is completed within the deadline without any incomplete documents or objections, it will be treated as a successful transaction, but there may be some unforeseen circumstances between the parties, so a notice of arrival. After 24 hours have passed, the SHC core system 201 generates a payment transaction and sends it to the SHC escrow contract 402 for execution (S1203). In the present embodiment, the transaction is executed after waiting for 24 hours, but the waiting period is not limited to this, and can be arbitrarily set depending on the transaction content, the usage environment, and the like.

Here, the execution of the payment transaction and the refund transaction is executed by the SHC escrow contract 402 broadcasting to the Ethereum node.

Claims (12)

It is a remittance method using virtual currency,
A deposit step of receiving a virtual currency in advance from the consignee to the deposit address in an amount that satisfies the cost incurred in the transaction between the consignor and the consignee.
A transaction generation step that generates a transaction for transferring the cost from the deposit address to the shipper, and a transaction generation step.
A arrival confirmation step of receiving information from a delivery management organization related to the transportation agency that the cargo sent from the shipper to the consignee by the predetermined transportation agency based on the transaction has arrived at the consignee.
A method comprising: a transaction execution step of executing the generated transaction after receiving the arrival information. The method according to claim 1, wherein the transaction is a sales transaction for buying and selling a predetermined product at the cost, and the consignee and the shipper are a purchaser and a product provider, respectively. The method according to claim 1 or 2, wherein the transaction is executed by broadcasting the transaction. When the virtual currency is received at the deposit address, the deposit step further transmits information to the effect that the virtual currency has been received to the shipper.
The method according to any one of claims 1 to 3, further comprising a delivery instruction step in which the shipper instructs the predetermined transportation agency to deliver the information to the effect that the information has been received. The method according to claim 4, wherein the arrival information is specified and received by the delivery identification information received from the delivery management organization. The method according to claim 5, wherein the shipper instructs the predetermined transportation agency to deliver and transmits the delivery identification information received from the delivery management agency. The method according to any one of claims 1 to 5, wherein the consignee transmits virtual currency in an amount satisfying the cost incurred in the transaction when the transaction is completed to the deposit address. The method of any of claims 1-7, wherein the transaction is signed by both the shipper and the consignee. The method according to any one of claims 1 to 8, wherein the transaction executes the generated transaction after a predetermined time has elapsed after receiving the arrival information. A program that causes a computer to execute a remittance method using virtual currency.
A deposit step of receiving a virtual currency in advance from the consignee to the deposit address in an amount that satisfies the cost incurred in the transaction between the consignor and the consignee.
A transaction generation step of generating a transaction for transferring the cost from the deposit address to the shipper, and a transaction generation step.
A arrival confirmation step of receiving information from a delivery management organization related to the transportation agency that the cargo sent from the shipper to the consignee by the predetermined transportation agency based on the transaction has arrived at the consignee.
A program including a transaction execution step for executing the generated transaction after receiving the arrival information. A system that allows a computer to execute a remittance method using virtual currency.
A deposit means for receiving virtual currency from the consignee in advance to the deposit address in an amount that satisfies the costs incurred in the transaction between the consignor and the consignee.
A transaction generating means for generating a transaction for transferring the cost from the deposit address to the shipper, and a transaction generating means.
A receipt confirmation means for receiving information from a delivery management organization related to the transportation agency that the cargo sent from the shipper to the consignee by the predetermined transportation agency based on the transaction has arrived at the consignee.
A system including a transaction execution means for executing the generated transaction after receiving the arrival information. A device that controls the remittance method using virtual currency.
A contract generation means that generates a contract that executes escrow,
A deposit instruction means for causing the consignee to send a virtual currency in an amount that satisfies the cost incurred in the transaction between the consignor and the consignee to the address of the contract generated in advance.
A transaction generating means for generating a transaction for transferring the cost from the address of the contract to the shipper, and
A receipt confirmation means for receiving information from a delivery management organization related to the transportation agency that the cargo sent from the shipper to the consignee by the predetermined transportation agency based on the transaction has arrived at the consignee.
A device including a transaction execution means for transmitting the generated transaction to the contract and executing the generated transaction after receiving the arrival information.

Images