JP7195016B2 - Transaction processing method, system and program - Google Patents

Description

TECHNICAL FIELD The present invention relates to a transaction processing method, system and program, and more specifically to a transaction processing method, system and program for processing a transaction using virtual currency and remitting a predetermined fee.

In recent years, in order to ensure the safety of payment when purchasing products and to ensure the provision of products, the product price is deposited in advance (deposited, entrusted), and funds are transferred until predetermined requirements are met. Various systems have been provided as so-called escrow service systems to stop Most of these escrow service systems are basically intended for legal currency, and are carried out by setting up a deposit account or the like in a financial institution. Specifically, in a transaction involving the exchange of money based on some kind of contract, the user who sent the remittance deposits a predetermined amount of money in a deposit account, and the service provider confirms it and conveys it to the recipient of the remittance, and the transaction is carried out. When the transaction is completed, the transaction is made safe by remittance to the remittee based on the finally deposited money. For example, Patent Document 1 aims to obtain a fund pooling device, an online shop payment method, and an online shop payment system that reduce payment costs and eliminate the risk of customers paying for products that have not arrived. , a customer terminal 20, an EC site terminal 40, a fund pool device 50, a store terminal 60, and a parcel tracking management server 80 are connected via a network 10. The EC site terminal 40 accepts and transmits product order information input from the customer terminal, the fund pooling device 50 accepts product purchase price settlement procedure information and product purchase price deposit processing information, pools the product purchase price, The store terminal 60 receives product order information, the store terminal 60 or the package tracking management server 80 transmits product delivery information, and the EC site terminal 40 receives the delivery information and transmits a deposit command signal to the fund pool device. , the fund pool device 50 receives the deposit instruction signal and remits the purchase price to the store terminal (see Patent Document 1).

On the other hand, in addition to conventional legal currency, virtual currency has come to be used as a payment method for consideration in various transactions. As one of such virtual currencies, a service using "Bitcoin (registered trademark)", which is based on the premise of a distributed platform, has already been provided. A technology called “blockchain” is used in the implementation of virtual currencies such as Bitcoin. In general, in blockchain, transactions, which are virtual currency transaction data whose authenticity is secured using hash functions and public key cryptography, are sent to all terminals connected by a P2P network that uses virtual currency. sent by broadcast. Transmitted transactions are verified for authenticity by terminals called miners, and once approved, they are grouped into blocks and recorded in a ledger of transactions called the blockchain. This enables management by a distributed system while maintaining a high level of reliability. A license request transaction including a payment transaction is transmitted to the P2P network of the content rights management block chain BC2, and the right holder device 2 transmits a license transaction corresponding to the license request transaction to the P2P network of the content rights management block chain BC2, By sending the payment transaction included in the permission request transaction to the virtual currency blockchain BC1, users and rights holders can manage payment and viewing permission simply by monitoring the content rights management blockchain BC2. A system has been disclosed (see Patent Document 2).
JP 2018-81342 A JP 2017-204070 A

However, when constructing an account service system using virtual currency, for example, in the system of Patent Document 1, although it is stated that virtual currency can also be used, it is necessary to set up an account for pooling (deposit) at a financial institution. is required. That is, for example, when it is determined that the deposit is possible, a deposit command signal is transmitted to the fund pool device 50, and the fund pool device 50 receives the deposit command, and transfers the funds from the fund pool device 50 to the store owner's net bank account. It is a method of sending payment processing information and settling the product purchase price, and since it is a process between accounts of financial institutions, it is a safe escrow service system that conforms to the remittance method of virtual currency even if you look at this disclosure. The problem is that it is not possible to build

The present invention has been made in view of the above-mentioned conventional problems, and constructs a remittance system that provides the optimum escrow service for virtual currency, achieves the merits of virtual currency, low fees and quick remittance, An object of the present invention is to provide a transaction processing method, system and program capable of achieving safer transactions. It also aims to provide safe transaction processing not only for escrow services but also for remittances using virtual currency.

The invention according to claim 1 is a method of remittance using a virtual currency in a remittance management device, and corresponds to a remittance amount to be remitted from a remittance source to a remittance destination in order to cause a remittance contract to execute remittance. a transaction generation step of generating a payment transaction to transfer virtual currency, signing it with a source private key generated for the sender, and storing the signed payment transaction; and whether predetermined payment conditions have been met. and, if satisfied, reading the stored payment transaction and sending it to the remittance contract to execute the sent payment transaction.

The invention according to claim 2 is the method according to claim 1, further comprising a deposit step of pre-remitting virtual currency corresponding to the remittance amount from the remittance source to the address of the remittance contract that executes the remittance. and

The invention according to claim 3 is the method according to claim 2, wherein the payment transaction is a transaction for transferring the remittance amount from the remittance contract address to the remittance destination, and the transaction generation step includes remittance from the remittance contract address. It is characterized by further generating a refund transaction for transferring the remittance amount to the original.

The invention according to claim 4 is the method according to claim 3, wherein the transaction execution step reads the stored refund transaction and sends it to the remittance contract when it is determined in the payment terms determination step that the payment terms have not been satisfied. to execute the submitted refund transaction.

The invention according to claim 5 is the method according to any one of claims 1 to 4, further comprising a contract generation step of generating a remittance contract and deploying it to the distributed processing platform.

The invention according to claim 6 is characterized in that, in the method according to claim 5, the distributed processing platform is Ethereum.

The invention according to claim 7 is the method according to any one of claims 1 to 6, characterized in that the remittance contract is broadcast and executed when the transaction is received.

The invention according to claim 8 is the method according to any one of claims 1 to 7, characterized in that the transaction is further signed using a sender private key generated for the sender.

The invention according to claim 9 is characterized in that, in the method according to any one of claims 1 to 8, the transaction generation step encrypts and saves the private key based on a passphrase that is not saved. Characterized by

In the invention according to claim 10, a program for causing a computer to execute a remittance method using virtual currency, wherein the remittance method is a remittance amount to be remitted from a remittance source to a remittee for causing a remittance contract to execute remittance. a transaction generation step of generating a transaction to transfer the sender, signing it with a source private key generated for the sender, storing the signed transaction; and determining whether predetermined payment terms have been satisfied. and a transaction execution step of retrieving the stored transaction and transmitting it to the remittance contract to execute the transmitted transaction when the remittance contract determines that the transaction is satisfied.

The invention according to claim 11 is a system for performing remittance using virtual currency, in which a transaction for transferring a remittance amount to be remitted from a remittance source to a remittance destination is generated for causing a remittance contract to execute remittance, transaction generating means for signing using a sender private key generated for the sender and storing the signed transaction; and transaction execution means for reading the transmitted transaction and transmitting it to the remittance contract to execute the transmitted transaction.

According to the present invention, there is a method of making a remittance using a virtual currency, in which a transaction for transferring a virtual currency corresponding to a remittance amount to be remitted from a remittance source to a remittance destination is executed by a remittance contract that executes remittance. a transaction generation step of generating, signing with a source private key generated for the sender, and storing the signed transaction; Then, the stored transaction is read out, transmitted to the remittance contract, and a transaction execution step for executing the transmitted transaction, so that escrow using virtual currency enables quick and reliable transactions. It also enables safe transaction processing in remittances using virtual currency.

1 is an overall system configuration diagram of an embodiment of the present invention; FIG. 3 is a functional block diagram of the SHC core of one embodiment of the present invention; FIG. FIG. 4 is a diagram showing an example of transactions used in one embodiment of the present invention; It is a figure for demonstrating the distributed processing platform of one Embodiment of this invention. It is a figure which shows an example of the block chain of one embodiment of this invention. 1 is a functional block diagram of a cold wallet according to one embodiment of the invention; FIG. FIG. 4 is a diagram for explaining encryption using HSM according to one embodiment of the present invention; It is a flowchart which shows the transaction generation process of one Embodiment of this invention. 4 is a flow chart showing transaction execution processing according to an embodiment of the present invention; FIG. 4 illustrates another example of a transaction for use with one embodiment of the present invention; FIG. 11 is a flow chart showing transaction generation processing according to another embodiment of the present invention; FIG. FIG. 11 is a flow chart showing transaction application processing according to another embodiment of the present invention; FIG. It is a flowchart which shows the execution process of another Example of this invention.

Embodiments of a transaction processing method, system, and program using virtual currency according to the present invention will be described below with reference to the drawings. In addition, even in different drawings, the same reference numerals are used to indicate the same processing and configuration.

In this embodiment, a party who has conducted some kind of commercial transaction pays for the transaction in virtual currency. , the system can also include processing from the beginning of the transaction. For example, it can be applied to purchasing overseas products via the Internet, or conversely, exporting products to overseas buyers and receiving remittances. Can be applied to scenes. That is, for example, at a sales site provided by an overseas business operator, the purchaser confirms the product of the product provider, decides to purchase the product, and proceeds to the payment process, and the system of the present embodiment operates. In this case, after acquiring the information necessary for remittance at the sales site, the information can be passed to the remittance system of this embodiment to proceed with the process, or the purchase can be determined at the sales site and the payment process selected. Then, the user is connected to the separately provided remittance system of the present embodiment, and can input information necessary for subsequent remittance and exchange information with the remittance source and remittee.

Further, in this embodiment, Shake Hands Contract (hereinafter referred to as SHC) or Ether is used as virtual currency, and the software of this embodiment is deployed and executed on the Ethereum platform, but not limited to this, various virtual currencies , various distributed platforms can be used. In this case, the software for performing various processes of this embodiment is distributed and processed on Ethereum nodes, which are computers such as personal computers and servers connected to a network. Any method known in the technical field by applying it to a system that broadcasts transactions and remittances by executing some processing on a specific server or using a specific database You can configure the system with Furthermore, although the remittance system of this embodiment implements an escrow service, the principle of the present invention can also be applied to normal transaction processing.

(System configuration)
The operation and processing of the remittance system used in one embodiment of the present invention are described below. FIG. 1 is an overall system configuration diagram of one embodiment of the present invention. In this system, an SHC core 101 for executing the main functions of remittance processing, processing interfaces with remittance sources such as purchasers and remittance destinations such as product providers, and controlling the entire system, and It includes various software and contracts 121 , 122 , and 123 operating on the Ethereum platform 102 that communicates with the SHC core 101 and executes various SHC-related processes, and is connected via a network 103 .

In addition to these nodes connected to the network, it is equipped with a cold wallet 131 that is isolated from the network and protects main data from unauthorized operations via the network. Data exchange between the cold wallet 131 and the SHC core 101 can be performed by a removable memory device or the like other than the always-connected network.

Furthermore, the remittance source terminal 111, which connects to a sales site (not shown) and performs product purchase processing, is basically connected to the network 103 regardless of whether it is wireless or wired, and can be a desktop personal computer, for example. In this embodiment, the connection with the network 103 can be performed by a normal connection, a mobile phone line, or a wireless network such as Wi-fi or BLUETOOTH (registered trademark). Here, the terminals 111 and 112 can be desktop computers, tablet terminals, smartphones, or mobile computers. Any device such as a general-purpose terminal or a dedicated terminal can be used as long as it can be operated. In this embodiment, in addition to the functions described above, 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. You can also obtain the information necessary for operating the remittance system, such as the process for determining execution.

FIG. 2 is a functional block diagram of the SHC core of one embodiment of the present invention. The SHC core mainly includes an SHC core system 201 that executes the main functions of remittance processing and controls the entire system, and an SHC web service 202 that processes services for external systems such as interfaces with remittance sources and remittees. Here, the SHC core system 201 has the main functions of remittance processing, specifically, the SHC address generation function that generates and manages the addresses of users using the remittance system of this embodiment, such as remittance sources and remittance destinations. A multisig contract generation function that generates an SHC escrow contract for each, a SHC/Ether transfer function that instructs remittance or refund in SHC or Ether, which is a virtual currency, under predetermined conditions, and a document hash storage function. In addition to this, it can also have a delivery information check function for receiving a delivery completion notification from a carrier or a delivery information management organization.

In addition, the SHC web service 202 performs main processing related to interfaces with remittance sources and remittees, specifically, input/output and management functions of user accounts of persons involved in transactions such as remittance sources and remittees, product purchase sites, etc. Transaction generation and participation function of this embodiment by linking from , SHC/Ether deposit information processing function related to deposits from payers such as product purchasers, transaction document storage function, receipt and management of delivery identification information at the time of product delivery Execute the input/correction function of delivery information, etc. The SHC core can have various functions according to other system configurations, such as a hardware security module (HSM) and an Ethereum node connection function, which will be described later.

FIG. 3 is a diagram showing an example of a transaction used in one embodiment of the invention. In general, with virtual currency using blockchain, remittance is executed by writing the transfer (transfer) of ownership in data called a transaction and going through a predetermined procedure. Also in this embodiment, the remittance process is started by writing the transfer amount and the other party in the transaction. In this embodiment, remittance processing can be performed using a transaction as shown in FIG. 3, which is also used for bitcoin, for example. That is, the content 302 of the transaction such as the remittance amount, the remittance destination information 303, and the remittance source information 304 are written in the transaction 301, and the remittance source's signature is entered. Specifically, a signature can be implemented, for example, by writing a transaction hash value encrypted with the sender's private key.

In this embodiment, as will be described later, the private key of the remittance source used when the SHC core system 201 generates a transaction is encrypted and stored on the disk for subsequent use after the transaction is generated. In order to prevent the core system 201 from performing inappropriate processing using the private key, the configuration is such that the private key cannot be easily deciphered. Specifically, in this embodiment, the passphrase used for encryption when storing the private key is acquired each time from the remittance source (not stored in the SHC core system) so that the user can Unless the encryption key is provided, the SHC core system 201 is configured so that it cannot obtain (decrypt) and use the private key stored on a disk or the like.

In this embodiment, the private key is also used for subsequent processing, so it is encrypted with a passphrase before being saved to avoid inappropriate processing. However, it is possible to prevent the private key from being saved at all . That is, since the SHC core system 201 cannot use the secret key if it is not saved, it can be handled by obtaining it from the user as necessary and not saving it on a disk or the like. At this time, if the secret key itself is randomly generated by the system, it may be presented to the user in advance so that the user can input it himself afterward.

In any case, in this embodiment, the secret key can be used only when the SHC core system 201 generates a transaction, but thereafter the secret key cannot be used unless provided by the user. Secure transaction creation can be achieved by not allowing transactions to be created solely at the discretion of the system.

FIG. 4 is a diagram for explaining an Ethereum platform as an example of a distributed processing platform according to one embodiment of the present invention. The Ethereum platform 102 is capable of running various distributed processing applications (Dapps), in this embodiment the SHC token contract 121 and the SHC blockchain 122 reside. The SHC token contract 401 manages SHC tokens, and assumes that specific functions required by various token management software in this technical field are prepared.

Additionally deployed on the Ethereum platform 102 is an SHC escrow contract 401 that is generated for each transaction as shown in FIG. The SHC escrow contract 401 holds deposits generated and sent for each transaction relating to remittance of this embodiment, and performs remittance processing according to instructions from the SHC core system 201 . The SHC escrow contract 401 of this embodiment can implement multisig, and can be made so that processing cannot be performed without the passphrases of both the seller and the buyer, in this embodiment, the remittance destination and the remittance source. Therefore, even if a third party intrudes into the system, it is possible to prevent unauthorized remittance. In this case, multisig uses source and destination secret keys, but can use any of the multiple key encryption techniques known in the art. In this embodiment, by deploying the contract to the Ethereum platform 102 and executing it independently, once the contract is generated, the SHC core system 201 only needs to execute the processing of the generated transaction. system safety can be further improved.

FIG. 5 is a diagram showing an example of the SHC blockchain of one embodiment of the present invention. The SHC blockchain 122 includes transaction documents 501 and KYC information 502, etc., and is used by each software of this embodiment. Transaction documents 501 are written with new blocks as transactions are executed, forming a blockchain. Also, KYC
The information 502 is a so-called Know Your Customer (KYC), which is a general term for document procedures for customer identification required by financial institutions when opening a new account, and other information is also stored. can be done.

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

FIG. 7 is a diagram for explaining encryption using HSM according to one embodiment of the present invention. In the SHC core 101 of this embodiment, all private keys and transactions are protected by HSM (Hardware Security Module). The HSM used satisfies all of the following specifications, and even if data is leaked 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 key leaks ・US Federal Standards FIPS140-2 Level 2/3 compliant ・Encryption keys cannot be exported, and users As shown in FIG. 7, in this embodiment, both the secret key 702 and the transaction 703 are encrypted and saved when they are saved on the disk 701, and the HSM 721 is encrypted when the secret key and transaction are used. On the memory 711, each process is performed as a decrypted plaintext private key 712 and a plaintext transaction 713, for example, broadcast to an Ethereum node, but the plaintext data is stored on the disk. Secure escrow service can be realized by using without saving. Here, as described above, the SHC core system 201 of this embodiment can use the private key only when the user approves and generates a transaction. In order to prevent the secret key from being used at the discretion of the SHC core system 201 thereafter, in addition to the encryption key stored in the HSM, encryption is performed using a passphrase that is obtained from the user each time and is not saved. Any method known in the technical field may be used to prevent inappropriate transaction generation at the discretion of the SHC core system 201 .

(Processing of the first embodiment)
In this embodiment, for convenience of explanation of the present invention, a purchaser who is a remittance source and a product provider who is a remittance destination complete a sales transaction at a predetermined sales site, and after payment and a certain performance of the transaction, The description will start from the phase where product delivery procedures are to be performed, but the remittance system of the present embodiment is not limited to this, and can be incorporated, for example, into sales transaction processing of a sales site, or can receive necessary information from the sales site. can be received and the system of the present embodiment can continue processing. This embodiment uses basic processing to which the principle of the present invention is applied, and a second embodiment, which will be described later, uses processing with enhanced security. Also, although the present embodiment has been described on the premise of an escrow service system, the principle of the present invention is not limited to this and can be applied to transaction processing in a general remittance system using virtual currency.

FIG. 8 is a flowchart showing transaction generation processing according to one embodiment of the present invention. As a premise for performing various processes in this system, the SHC web service 202 provides an information input screen and the like to the transaction parties, that is, the remittance source and the remittance destination, and prompts them to input necessary information to create an account (step 801). In general, if a sales transaction is completed, the remittee has information on the remittance source and the transaction, so when the remittee enters the information, an account is created and sent to both parties. For example, the information can be automatically sent from the sales site, or the information can be input by the purchaser who is the source of the remittance. Similarly, when transaction information is entered by one or both parties, or automatically (step 802), SHC core system 201 generates source and destination private keys A and B, respectively (step 803). ).

Furthermore, the SHC core system 201 generates a payment transaction for the amount of the transaction based on the obtained transaction information (step 804). , the payment transaction is a transaction to transfer the deposited SHC equivalent to the price from the SHC escrow contract 402 to the remittance destination 112 .

Thereafter, the generated transaction is signed with the sender's private key A (step 805), and the signed transaction is encrypted with a predetermined encryption key and stored (step 806). Keys and the like are further encrypted using a passphrase α separately provided by the remittance source and stored. After the passphrase α is used for encryption processing, it is not stored so as to avoid careless processing as described above. Either method can be used, and if there is no need to use the private key or the like in subsequent processing, it is not stored and the SHC core system 201 cannot generate new transactions. . At this time, if the secret key itself is randomly generated by the system, it may be presented to the user in advance so that the user can input it himself afterward.

(Transaction execution processing of this embodiment)
As described above, in the present embodiment, a payment transaction is first generated at the first stage of the remittance process, and after that, when predetermined conditions are met, that is, when the remittance destination completes the transaction up to a certain stage, such as purchasing a product, the payment transaction is completed. In the case of a transaction, the transaction is executed when it is confirmed that there is no problem even if the remittance is executed, such as when the product arrives at the remittance source, which is the purchaser, and the remittance is sent to the remittance destination. This achieves an escrow that makes transactions secure.

FIG. 9 is a flow chart showing transaction execution processing of this embodiment. As described above, the process starts from a state in which a transaction is generated and waiting for a certain completion of the transaction. First, the SHC escrow contract 401 is generated and deployed on the Ethereum platform 102 (step 901). Although this step is placed before confirmation of the next deposit, it is not limited to this, and may be performed after confirmation of deposit.

Next, it is checked whether or not the money has been deposited (step 903), and if it has not yet been deposited, the sender is urged to deposit it (step 904). If the deposit is confirmed, the remittance destination is informed of the fact (step 905), and is urged to perform the transaction, for example, to ship the product. Here, the completion of the deposit is not necessarily a requirement for starting the performance of the transaction, but other information can be taken into account as one factor in determining the remittance destination. However, in general, if the deposit is confirmed and preparations for the performance of the transaction are not started, subsequent processing such as payment will be delayed, so it is preferable to notify the remittee without delay. Further, deposit or deposit in this embodiment is performed by transferring money from the sender 111 to the address of the SHC escrow contract 402 . As a result, the SHC of the payment amount is held in the SHC escrow contract 402, and therefore, a transaction to transfer from the SHC escrow contract 402 to the remittance destination 112 can be executed at the time of payment.

At the time of refund, the SHC of the deposited amount may not be held in the SHC escrow contract 402, and the same amount of SHC may be held separately, or otherwise deposited by a method known in the technical field. In this case, refunds when the transaction is not performed can be implemented in any manner known in the art. It is also possible to generate a refund transaction in advance and execute a transaction to transfer from the SHC escrow contract 402 to the remittance source 111 .

As a result of the remittance destination's execution of a certain amount or more of the transaction and the remittance source's confirmation of this, if it is determined that there is no problem in remittance, the remittance source instructs the SHC core to that effect, so this is confirmed (step 906), and the transaction is performed. is not fulfilled, the transaction is deemed unsuccessful and the contract is canceled (step 908). At this time, a process of returning the deposited virtual currency to the remittance source is performed by any method known in the technical field.

On the other hand, if there is a remittance instruction, the payment transaction is sent to the contract and executed (step 907). Execution of payment transactions is performed by the SHC escrow contract 402 broadcasting to Ethereum nodes.

(Processing of the second embodiment)
The processing of this embodiment differs from the processing of the above-described first embodiment in the following points. The first point is that in the first embodiment, only the remittance source signed the transaction, but in addition to this, the remittance destination also signs, thereby further improving reliability. Second, when creating a transaction, create a refund transaction in addition to the payment transaction. In particular, in the escrow service, it is assumed that the remittance source has deposited a certain amount in advance, and it is possible to deposit in various forms, but a simple system using virtual currency like this embodiment Then, it is appropriate to transfer the deposited money to the SHC escrow contract generated as shown in the first embodiment, and execute a transaction to transfer the money to the remittee when executing the remittance. In this case, when the transaction is not fulfilled and it is necessary to refund the money to the sender, it is preferable to use a transaction to transfer money from the SHC exlo contract to the sender. Furthermore, as executed in the first embodiment, it is desirable to generate transactions in advance so that they cannot be tampered with until execution. to generate Others are basically the same as the first embodiment.

FIG. 10 is a diagram showing an example of transactions used in this embodiment. As in the first embodiment described above, in this embodiment, remittance is executed by writing data called a transaction and going through a predetermined procedure. The remittance destination information 303 and the remittance destination information 304 are written in the transaction 301, and the remittance source signs. In the transaction 1001 of this embodiment, the signature of the remittee is also added. Specifically, for example, the hash value of the transaction can be implemented by adding it to the secret key of the remittance source, encrypting it with the secret key 1002 of the remittee, and writing it.

As for the handling of the secret key, in the present embodiment, after it is used in transaction generation, it is encrypted and stored on the disk for subsequent use in the same manner as in the first embodiment. In order to prevent the private key from being easily deciphered, the passphrase used for encryption when storing the private key should be obtained from the sender and recipient each time. Therefore, unless the user provides the encryption key, the SHC core system 201 cannot obtain (decrypt) and use the private key stored in the disk or the like.

In this embodiment, since the private key is also used for other processes, it is encrypted with a passphrase presented by the user and stored to avoid inappropriate processing. You can also At this time, if the secret key itself is randomly generated by the system, it may be presented to the user in advance so that the user can input it himself afterward.

FIG. 11 is a flow chart showing transaction generation processing according to another embodiment of the present invention. Although this embodiment performs the same processing as the first embodiment, but differs particularly in transaction generation (step 1101) and transaction signing (step 1102), the entirety will be described. As a premise for performing various processes in this system, the SHC web service 202 provides an information input screen and the like to the transaction parties, that is, the remittance source and the remittance destination, and prompts them to input necessary information to create an account (step 801). Next, when transaction information is entered by one or both parties or automatically (step 802), SHC core system 201 generates private keys A and B for the sender and receiver, respectively (step 803). ).

Furthermore, the SHC core system 201 generates a payment transaction and a refund transaction for the amount of the transaction based on the obtained transaction information (step 1101). The payment transaction is a transaction to transfer the deposited SHC equivalent to the price from the SHC escrow contract 402 to the remittance destination 112, and the refund transaction transfers the deposited SHC equivalent to the price from the SHC escrow contract 402 to the remittance source. 112 transaction. In this embodiment, by generating a payment transaction and a refund transaction at the time of transaction generation, refund processing can be easily performed even if the transaction ends unsuccessfully. In other words, in the escrow system, deposit processing is performed before the transaction is completed. Although it is a process that must be handled as a system, if a refund transaction is generated when a payment transaction is generated, the refund transaction can be executed without performing various processes when the transaction is not completed. This is extremely effective when providing escrow services using virtual currency.

After that, the generated transaction is signed with the sender's private key A and the recipient's private key B (step 1102). In this embodiment, since a payment transaction and a refund transaction are generated as described above, the private keys of both the sender and receiver are inevitably used. By signing on both sides, the security of processing is further improved. The signed transaction thus encrypted is encrypted with a predetermined encryption key and stored (step 806). do.

Encryption is performed using passphrases α and β, etc., and any specific encryption method known in the technical field can be used. It is also possible to prevent SHC core system 201 from generating new transactions without storing them if they are not required to be used. Also, when the secret key is to be used thereafter, if the secret key itself is randomly generated by the system, it can be presented to the user in advance so that the user can input it himself.

(Transaction execution processing of this embodiment)
As described above, in the present embodiment, a payment transaction is first generated at the first stage of the remittance process, and then, when predetermined conditions are satisfied, that is, when the remittance source is a remittee and the remittance destination completes a certain transaction, If it is a purchase transaction, it can be confirmed that the product has arrived at the purchaser who is the remittance source, and the transaction is executed in a situation where it is confirmed that there is no problem even if the remittance is executed, and the remittance is sent to the remittance destination. This achieves an escrow that makes transactions secure.

FIG. 12 is a flowchart showing transaction application processing according to this embodiment of the present invention. As described above, the process starts from a state in which a transaction is generated and waiting for a certain completion of the transaction. First, the SHC escrow contract 401 is generated and deployed on the Ethereum platform 102 (step 901). Although this step is placed before confirmation of the next deposit, it is not limited to this, and may be performed after confirmation of deposit.

Next, it is checked whether or not the money has been deposited (step 903), and if it has not yet been deposited, the sender is urged to deposit it (step 904). If the deposit is confirmed, the remittance destination is informed of the fact (step 905), and is urged to carry out the transaction. Here, the completion of the deposit is not necessarily a requirement for starting the performance of the transaction, but other information can be taken into account as one factor in determining the remittance destination. However, in general, if the deposit is confirmed and preparations for the performance of the transaction are not started, subsequent processing such as payment will be delayed, so it is preferable to notify the remittee without delay. Further, deposit or deposit in this embodiment is performed by transferring money from the sender 111 to the address of the SHC escrow contract 402 . As a result, the SHC of the payment amount is held in the SHC escrow contract 402, and therefore, a transaction to transfer from the SHC escrow contract 402 to the remittance destination 112 can be executed at the time of payment.

At the time of refund, the refund transaction is used to execute the transfer transaction from the SHC escrow contract 402 to the remittance source 111 .

If the remittance destination completes the transaction above a certain level, for example, in the case of a product purchase transaction, the product arrives at the purchaser who is the remitter, and as a result of the remitter confirming this, the remitter determines that there is no problem with the remittance. Since the SHC core is instructed to that effect, this is confirmed (step 906), and if the transaction is not completed, the refund transaction is read as unsuccessful and sent to the SHC escrow contract for execution (step 1202). On the other hand, if there is a remittance instruction, the process proceeds to the process shown in FIG. 13, that is, the process of transmitting the payment transaction to the contract and executing the transaction (step 1101). Here, in this embodiment, payment processing or refund processing is performed after confirming the remittance instruction from the remittance source. Usually, the purchaser of the product, which is the source of remittance, instructs the execution of payment after the arrival of the product or after various processes after the arrival of the product. However, as will be described later, in recent years, information such as the arrival of parcels has been centrally managed, so it is possible to introduce such a tracking system and execute remittances without instructions from the remittance source.

(tracking process)
In the present embodiment, when the delivery process of packages etc. is involved, basically on the condition that the remittance source deposits SHC for the price, the remittee performs the delivery process, and on the condition that the transportation company completes the delivery, the deposited SHC is sent. You can also send money to the recipient. Any method known in the technical field can be used for the method of requesting delivery to the carrier and the specific procedures, but in general, when a delivery is requested, unique delivery identification information is given. Also in this embodiment, the SHC core system 201 can obtain delivery identification information from the remittee or itself, and proceed with processing based on this. When the remittee requests the carrier for delivery, the delivery identification information is set. This information is notified to the SHC web service 202 or contacted by the carrier, so that the SHC core associates it with the corresponding transaction to identify the delivery. make information available. That is, when the delivery process is performed and the delivery identification information is set, the arrival confirmation is set so as to receive a notification when the delivery is completed. Currently, most of domestic and foreign shipping companies have their own or external organizations and companies such as related information processing companies, and have delivery management and tracking systems for the packages they handle. Other information is also available in real time. In recent years, not only tracking systems for individual shipping companies, but also companies that collect and provide information from multiple shipping companies have emerged. information can also be used.

In this embodiment, a service such as AfterShip, for example, enables tracking of major shipping companies including those overseas, but is not limited to this, and similar services provided by various companies can also be used. Confirmation of arrival depends on the tracking service used, but in this embodiment, as described above, the delivery identification information is set, and when the delivery is completed (when the remitter receives the product), a notification to that effect is sent. Since it is set in advance to receive it, it is only necessary to wait for the notification that the specified package has arrived from the tracking service and then perform the subsequent processing. Here, the delivery identification information can be an inquiry number set when a delivery request is made to the carrier, but is not limited to this, and can be any number such as a product number as long as the package to be delivered can be specified. It can also be identifying information. As described above, by incorporating the tracking process into the system of this embodiment, it is possible to construct a more effective system, and this process can also be incorporated into the above-described first embodiment.

(Transaction execution processing of this embodiment)
In the above, it was explained that when remittance becomes possible, such as remittance instructions from the remittance source, the process shifts to remittance execution processing and refund processing. Next, the process of executing remittance will be described more specifically.

FIG. 13 is a flow chart showing execution processing for transactions according to one embodiment of the present invention. As described above, the processing is started from a state of waiting for a certain completion of transactions. First, it is confirmed whether or not there is any incompleteness in the documents (step 1301). For example, if the transaction is not a domestic transaction but involves imports and exports, it will be a bilateral transaction and various documents will be required. I will not explain the details here, but if the documents are incomplete, it may be necessary to cancel the transaction depending on the degree of the insufficiency. The SHC core system 201 sends the stored payment or refund transaction to the SHC escrow contract 402 for execution (S1304).

In addition, there are cases where the transaction is not completed due to some accident or the like, and in this case as well, there are many cases where the transaction should be canceled after a predetermined time limit has passed. Cause the escrow contract 402 to execute the refund transaction (S1305). Even if a certain amount of the transaction is completed within the deadline, if there is an objection from one of the parties, it may be necessary to cancel the transaction as soon as possible depending on the content of the objection. The SHC core system 201 causes the SHC escrow contract 402 to execute a payment transaction or a refund transaction according to the determined content (S1304).

If there are no incomplete documents or no objection, and the transaction is completed within the deadline, the remittance process can be executed immediately. After 24 hours have passed since the instruction, etc., the SHC core system 201 causes the SHC escrow contract 402 to execute the payment transaction (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 arbitrarily set according to the contents of the transaction, the usage environment, and the like.

Here, execution of payment and refund transactions is performed by the SHC escrow contract 402 broadcasting to Ethereum nodes.

Claims (10)

A method of remittance using a virtual currency in a remittance management device,
generating a payment transaction for transferring a virtual currency corresponding to a remittance amount to be remitted from a remittance source to a remittance destination, in order to cause the remittance contract to execute the remittance; a transaction generation step of signing with a payee's private key generated for and storing the signed payment transaction;
a transaction execution step of determining whether a predetermined payment condition is satisfied and, if it is determined that it is satisfied, reading the stored payment transaction, transmitting it to the remittance contract, and causing the transmitted payment transaction to be executed; wherein said transaction generating step encrypts said sender private key based on a non-stored passphrase sent by said sender; and encrypts said sender private key based on a non-stored passphrase sent by said sender; A method characterized in that the private key is stored encrypted. 2. The method according to claim 1, further comprising a deposit step of pre-remitting virtual currency corresponding to said remittance amount from said remittance source to an address of a remittance contract that executes remittance. the payment transaction is a transaction for transferring the remittance amount from the address of the remittance contract to the remittee;
3. The method of claim 2, wherein the transaction generating step further generates a refund transaction that transfers the remittance amount from the remittance contract address to the remittance source. 4. The step of executing a transaction, upon determining that the payment terms have not been met, retrieves the stored refund transaction and transmits it to the remittance contract to execute the submitted refund transaction. 3. The method described in 3. 5. The method of any of claims 1-4, further comprising a contract generation step of generating and deploying the remittance contract to a distributed processing platform. 6. The method of claim 5, wherein the distributed processing platform is Ethereum. 7. The method of any of claims 1-6, wherein the remittance contract broadcasts and executes upon receipt of the payment transaction. 8. The method of any of claims 1-7, wherein the payment transaction is further signed using a beneficiary private key generated for the beneficiary. A program that causes a computer to execute a remittance method using virtual currency, the remittance method comprising:
Generate a transaction for transferring the remittance amount to be remitted from the remittance source to the remittance destination, and transfer the remittance source secret key generated for the remittance source and the remittance generated for the remittance destination to cause the remittance contract to execute the remittance a transaction generation step of signing with a prior private key and storing the signed transaction;
a transaction execution step of determining whether predetermined payment conditions are satisfied and, if it is determined that they are satisfied, reading the stored transaction, transmitting it to the remittance contract, and causing the transmitted transaction to be executed; , the transaction generating step encrypts the sender private key based on a non-stored passphrase sent by the sender; and encrypts the recipient private key based on a non-stored passphrase sent by the recipient. A program characterized by encrypting and storing . A system for remittance using virtual currency,
Generate a transaction for transferring the remittance amount to be remitted from the remittance source to the remittance destination, and transfer the remittance source secret key generated for the remittance source and the remittance generated for the remittance destination to cause the remittance contract to execute the remittance a transaction generating means for signing with a prior private key and storing the signed transaction;
a transaction execution means for determining whether or not predetermined payment conditions have been satisfied, and if it is determined that they have been satisfied, reading the stored transaction, transmitting it to the remittance contract, and causing the transmitted transaction to be executed. , the transaction generating means encrypts the sender private key based on a non-stored passphrase sent by the sender, and encrypts the sender private key based on a non-stored passphrase sent by the receiver; A system characterized by encrypting and storing

Images