WO2020040070A1 - Procédé, système et programme de traitement de transaction - Google Patents

Procédé, système et programme de traitement de transaction Download PDF

Info

Publication number
WO2020040070A1
WO2020040070A1 PCT/JP2019/032205 JP2019032205W WO2020040070A1 WO 2020040070 A1 WO2020040070 A1 WO 2020040070A1 JP 2019032205 W JP2019032205 W JP 2019032205W WO 2020040070 A1 WO2020040070 A1 WO 2020040070A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
remittance
contract
source
shc
Prior art date
Application number
PCT/JP2019/032205
Other languages
English (en)
Japanese (ja)
Inventor
丈雄 安島
規行 杉江
Original Assignee
株式会社Ｓｔａｎｄａｇｅ
株式会社フェアーウェイ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社Ｓｔａｎｄａｇｅ, 株式会社フェアーウェイ filed Critical 株式会社Ｓｔａｎｄａｇｅ
Priority to JP2020538366A priority Critical patent/JP7195016B2/ja
Publication of WO2020040070A1 publication Critical patent/WO2020040070A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme

Definitions

  • 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 cost.
  • escrow service systems In recent years, in order to ensure the safety of payment at the time of product purchase and to provide reliable products, deposit (deposit, deposit) of the product price in advance, and transfer of funds until predetermined requirements are satisfied Various systems are provided as so-called escrow service systems. Most of such escrow service systems basically target legal currency, and are performed by setting up a deposit account or the like at a financial institution. Specifically, in a transaction that involves the exchange of money based on a contract, the remittance source user deposits a predetermined amount in a deposit account, the service provider confirms it and transmits it to the remittee, and the transaction is executed.
  • Patent Literature 1 aims to obtain a fund pooling device, an online shop settlement method, and an online shop settlement system in which the settlement cost is low and the risk of the customer paying the price even though the product does not arrive is eliminated.
  • a system in which a customer terminal 20, an EC site terminal 40, a fund pool device 50, a store terminal 60, and a package tracking management server 80 are connected via a network 10 is disclosed.
  • the EC site terminal 40 receives and transmits the product order information input from the customer terminal, and the fund pooling device 50 receives the settlement procedure information of the product purchase price and the payment processing information of the product purchase price, pools the product purchase price,
  • the store terminal 60 receives the product order information
  • the store terminal 60 or the package tracking management server 80 transmits the delivery information of the product
  • the EC site terminal 40 receives the delivery information and transmits a deposit command signal to the fund pool device.
  • the fund pooling device 50 receives the deposit command signal and remits the purchase price of the product to the store terminal (see Patent Document 1).
  • Patent Literature 2 aims at efficiently linking the block chains, and the user device 1 uses the virtual currency block chain BC1 for the virtual currency block chain BC1.
  • the permission request transaction including the payment transaction is transmitted to the P2P network of the content right management blockchain BC2, and the right holder apparatus 2 transmits the permission transaction corresponding to the permission request transaction to the P2P network of the content right management blockchain BC2.
  • the present invention has been made in view of the above-described conventional problems, and has built a remittance system that provides an optimal escrow service for virtual currency, and achieves inexpensive commissions and quick remittance, which are advantages of virtual currency.
  • An object of the present invention is to provide a transaction processing method, system, and program capable of achieving more secure transactions. It is another object of the present invention to provide secure transaction processing in remittance using virtual currency, not limited to the escrow service.
  • the invention according to claim 1 is a method of performing 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 for a remittance contract to execute remittance.
  • the invention according to claim 2 is the method according to claim 1, further comprising a deposit step of previously remitting a virtual currency corresponding to the remittance amount from a remittance source to an address of a remittance contract that executes remittance.
  • the payment transaction is a transaction for transferring a remittance amount from a remittance contract address to a remittee
  • the transaction generating 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 transaction execution step when the transaction execution step determines that the payment condition is not satisfied in the payment condition determination step, the transaction execution step reads the saved refund transaction and transmits the transaction to the remittance contract. Then, the transmitted refund transaction is executed.
  • the invention described in 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 the contract to a distributed processing platform.
  • the invention described in claim 6 is the method according to claim 5, wherein the distributed processing platform is Ethereum.
  • the invention according to claim 7 is characterized in that, in the method according to any one of claims 1 to 6, when the remittance contract receives a transaction, it broadcasts and executes the transaction.
  • the transaction is further signed using a source private key generated for the remittance source.
  • the transaction generation step encrypts and stores the secret key based on a passphrase that is not stored.
  • the invention according to claim 11 is a system for performing remittance using virtual currency, and generates a transaction for transferring a remittance amount to be remitted from a remittance source to a remittee for causing a remittance contract to execute remittance,
  • Transaction execution means for reading the transmitted transaction, transmitting the transaction to the remittance contract, and executing the transmitted transaction.
  • a method for performing 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 remittee is performed in order for a remittance contract for performing a remittance to execute.
  • FIG. 1 is an overall system configuration diagram of an embodiment of the present invention. It is a functional block diagram of an SHC core of one embodiment of the present invention.
  • FIG. 4 is a diagram illustrating an example of a transaction used in an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating a distributed processing platform according to an embodiment of the present invention. It is a figure showing an example of a block chain of one embodiment of the present invention. It is a functional block diagram of a cold wallet of one embodiment of the present invention.
  • FIG. 5 is a flowchart illustrating a transaction execution process according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating another example of a transaction used in an embodiment of the present invention.
  • 13 is a flowchart illustrating a transaction generation process according to another embodiment of the present invention.
  • 11 is a flowchart illustrating a transaction application process according to another embodiment of the present invention.
  • 11 is a flowchart illustrating an execution process according to another embodiment of the present invention.
  • a party who has performed some commercial transaction makes payment such as consideration in virtual currency, and it is a process of exchanging money after the transaction is completed, but is not limited to this.
  • the system may include a process from the beginning of the transaction.
  • the present invention can be applied to a case where an overseas product is purchased via the Internet, or a case where the product is exported to a foreign buyer and remittance is received, but is not limited to this. Can be applied to scenes. That is, for example, the system of the present embodiment operates at the stage where the purchaser confirms the product of the product provider and decides to purchase the product at the sales site provided by the overseas company, and proceeds to the payment process.
  • the information can be passed to the remittance system of the present embodiment to proceed with the process, or the sales site can determine the purchase and select the payment process. Then, it is connected to the remittance system of this embodiment, which is provided separately, so that it is possible to input information necessary for remittance, and to exchange information with a remittance source and a remittance destination.
  • Shake Hands Contract hereinafter referred to as SHC
  • Ether is used as the virtual currency
  • the software of the present embodiment is deployed and executed on the Ethereum platform.
  • the present invention is not limited to this.
  • a variety of distributed platforms can be used.
  • the software for performing the various processes of the present embodiment is distributedly processed on an Ethereum node which is a computer such as a personal computer or a server connected to a network, but the principle of the present invention is not limited to such a mode.
  • Any of the methods known in the art can be applied to a system in which a transaction is broadcast and remittance is performed by executing a part of processing by a specific server or using a specific database.
  • the system can be configured with.
  • the remittance system of the present embodiment realizes an escrow service, but the principle of the present invention can be applied to ordinary transaction processing.
  • FIG. 1 is an overall system configuration diagram of an embodiment of the present invention.
  • an SHC core 101 for executing main functions of remittance processing, processing an interface with a remittance source such as a purchaser, a remittee such as a product provider, and controlling the entire system, and Various software and contracts 121, 122, and 123 that operate on an Ethereum platform 102 for performing various processes related to the SHC by exchanging with the SHC core 101 are provided, and are connected via a network 103.
  • a cold wallet 131 which is isolated from the network and protects main data from unauthorized operation via the network is provided. 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.
  • the remittance source terminal 111 that connects to a sales site or the like (not shown) and performs product purchase processing and the like is basically connected to the network 103 irrespective of wireless or wired, and can be, for example, a desktop personal computer.
  • the connection with the network 103 can be made by a connection of a mobile phone or a wireless network such as Wi-Fi or BLUETOOTH (registered trademark) in addition to a normal connection.
  • the terminals 111 and 112 can be tablet PCs, smartphones, mobile PCs, etc., in addition to desktop PCs, but can basically execute transmission and reception, display images, and perform certain input with a touch panel, mouse or keyboard.
  • any device such as a general-purpose terminal and a dedicated terminal can be used.
  • a carrier for delivering cargo such as merchandise
  • a delivery management system (not shown) for managing the delivery status of the carrier, and the like are also connected via the network 103, and It is also possible to obtain information necessary for operating the remittance system, such as a process for determining execution.
  • FIG. 2 is a functional block diagram of the SHC core according to one embodiment of the present invention.
  • the SHC core mainly includes an SHC core system 201 that executes a main function of a remittance process and controls the entire system, and an SHC web service 202 that processes services for external systems such as an interface with a remittance source and a remittance destination.
  • 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 remittance source and a remittee, and a transaction.
  • a multi-sig contract generation function for generating an SHC escrow contract for each time, an SHC / Ether transfer function for instructing remittance or refund by SHC or Ether which is a virtual currency under predetermined conditions, and a document hash storage function are executed.
  • a delivery information check function for receiving a delivery completion notification from a carrier or a delivery information management organization can be provided.
  • the SHC web service 202 is a main processing related to the interface with the remittance source and the remittance destination, specifically, the input / output and management functions of the user accounts of the parties involved in the transaction such as the remittance source and the remittee, the product purchase site, etc. From the payer such as a product purchaser, a deposit information processing function of SHC / Ether relating to a deposit, a storage function of a transaction document, and a delivery identification information at the time of delivery of a product. Execute the input / correction function of the delivery information.
  • the SHC core can further have various functions according to other system configurations, such as a hardware security module (HSM) and an Ethernet node connection function described later.
  • HSM hardware security module
  • FIG. 3 is a diagram showing an example of a transaction used in one embodiment of the present invention.
  • remittance is executed by writing a transfer (transfer) of its ownership to data called a transaction and going through a predetermined procedure.
  • the remittance process is started by writing the amount to be transferred and the other party in the transaction.
  • a remittance process can be performed using a transaction such as that shown in FIG. That is, the transaction contents 302 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 is signed.
  • the signature can be implemented, for example, by writing a hash value of the transaction encrypted with the private key of the sender.
  • the private key of the remittance source used when the SHC core system 201 generates a transaction is stored in a disk after the transaction is generated and then encrypted for subsequent use.
  • the secret key cannot be easily decrypted.
  • the passphrase used for encryption when storing the secret key is obtained from the remittance source or the like each time (not stored in the SHC core system), Unless an encryption key is provided, the SHC core system 201 cannot acquire (decrypt) a secret key stored on a disk or the like and use it.
  • the secret key since the secret key is also used in the subsequent processing, inappropriate processing is avoided by intentionally encrypting and saving with a passphrase.
  • the secret key may not be saved. . That is, since the secret key cannot be used by the SHC core system 201 if the key is not stored, the key may be obtained from the user as needed and may not be stored on a disk or the like. At this time, if the secret key itself is randomly generated by the system, the secret key itself can be presented to the user in advance, and then the user can input the secret key.
  • the SHC core system 201 can use the secret key only when generating a transaction as described above, but thereafter, the secret key cannot be used unless provided by the user. By preventing transactions from being generated only at the discretion of the system, secure transaction generation can be achieved.
  • FIG. 4 is a diagram for explaining an Ethereum platform as an example of a distributed processing platform according to an embodiment of the present invention.
  • the Ethereum platform 102 can operate various distributed processing applications (Dapps).
  • the SHC token contract 121 and the SHC blockchain 122 are provided.
  • the SHC token contract 401 manages the SHC token, and it is assumed that specific functions required by various token management software in the technical field are prepared.
  • an SHC escrow contract 401 generated for each transaction is deployed on the Ethereum platform 102 as shown in FIG.
  • the SHC escrow contract 401 is generated for each transaction related to remittance in the present embodiment, holds the transmitted deposit, and performs remittance processing according to an instruction from the SHC core system 201.
  • the SHC escrow contract 401 of the present embodiment can implement a multisig, and can not process unless there is a passphrase of both the seller and the buyer, in this embodiment, the remittee and the sender. Therefore, even if a third party intrudes into the system, an unauthorized remittance cannot be made.
  • the multisig uses the secret keys of the source and destination, but is not limited to this, and any encryption method using a plurality of keys known in the art can be used.
  • the contract is deployed on the Ethereum platform 102 and executed independently as described above.
  • the SHC core system 201 once generates the contract, the SHC core system 201 only executes the processing of the generated transaction. , It is possible to further improve the security of the system.
  • FIG. 5 is a diagram illustrating an example of an SHC block chain according to an embodiment of the present invention.
  • the SHC blockchain 122 includes transaction documents 501 and KYC information 502, and is used by each software of the present embodiment.
  • KYC Know Your Customer
  • the information 502 is a so-called Know Your Customer (KYC), that is, a general term for the document procedure required by the financial institution to open a new account and for confirming the identity of the customer, and also stores other information. Can be.
  • KYC Know Your Customer
  • FIG. 6 is a functional block diagram of a cold wallet according to one embodiment of the present invention.
  • the secret key and the currency with poor liquidity are stored in the cold wallet 131 which is isolated from the network by offline, and the data is extracted and used when necessary.
  • it can be implemented using a removable memory such as a USB memory, but is not limited to this, and various methods known in this technical field can be used.
  • the cold wallet 131 includes an HSM 601 to be described later, in addition to an SHC cold wallet system 602 for managing important data off-line.
  • FIG. 7 is a diagram for explaining encryption using the HSM according to one embodiment of the present invention.
  • HSM hardware security module
  • the HSM used satisfies all of the following specifications. 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 being leaked.-Compliant with US Federal Standard FIPS 140-2 Level 2/3.-The encryption key cannot be exported, and the user can use the key value. As shown in FIG.
  • both the secret key 702 and the transaction 703 are encrypted and stored, and the HSM 721 is used when the secret key and the transaction are used.
  • Decryption is performed on demand using on-demand, and in the memory 711, each process is performed as a decrypted plaintext secret key 712 and a plaintext transaction 713. For example, broadcast to an Ethereum node is performed. Use a secure escrow service without using it Can be manifested.
  • the secret key can be used only when the user approves and generates a transaction.
  • encryption is performed using a passphrase that is obtained from the user each time and is not stored.
  • the present invention is not limited thereto, and a similar process may be performed by any method known in the art to prevent inappropriate generation of a transaction at the discretion of the SHC core system 201.
  • the purchaser who is the remittance source and the product provider that is the remittee at a predetermined sales site complete the sales transaction, pay the price and perform a certain amount of the transaction.
  • the remittance system according to the present embodiment is not limited to this. Can be received and the system of the present embodiment can continue the processing. In this embodiment, a basic process to which the principle of the present invention is applied is used, and in a second embodiment described later, a process with further enhanced security is used.
  • the present embodiment has been described on the premise of an escrow service system, the present invention is not limited to this, and the principle of the present invention can be applied to transaction processing in a remittance system using general virtual currency.
  • FIG. 8 is a flowchart illustrating a transaction generation process according to an embodiment of the present invention.
  • the SHC web service 202 provides an information input screen or the like to a transaction party, that is, a remittance source and a remittee, and inputs necessary information to generate an account (step 801).
  • a transaction party that is, a remittance source and a remittee
  • the remittee has the information of the sender and the transaction, so when the remittee inputs the information, an account is created and sent to both parties.
  • each information can be automatically transmitted from a sales site, or a buyer who is a remittant can input the information.
  • the SHC core system 201 generates the respective private keys A and B of the sender and recipient (step 803). ).
  • the SHC core system 201 generates a payment transaction of the transaction amount based on the obtained transaction information (step 804).
  • the payment transaction is a transaction for transferring the deposited SHC corresponding to the price from the SHC escrow contract 402 to the remittee 112.
  • the generated transaction is signed with the private key A of the sender (step 805), and the signed transaction is encrypted with a predetermined encryption key and stored (step 806).
  • the key and the like are further encrypted and saved using a passphrase ⁇ provided separately from the remittance source.
  • the passphrase ⁇ is used in the encryption process, it is not stored so as to avoid careless processing as described above, but a specific encryption method is known in the art. Either method can be used, and if there is no need to use a secret key or the like in subsequent processing, it is also possible to prevent the SHC core system 201 from generating a new transaction without saving it. .
  • the secret key itself is randomly generated by the system, the secret key itself can be presented to the user in advance, and then the user can input the secret key.
  • a payment transaction is first generated, and then, a situation where predetermined conditions are satisfied, that is, a transaction at the remittee is completed to a certain stage, for example, purchase of a product.
  • the transaction is executed in a situation where it is confirmed that there is no problem even if the remittance is executed, for example, when the merchandise arrives at the remittance source, which is the purchaser, and is remitted to the remittee.
  • escrow for safely performing transactions is achieved.
  • FIG. 9 is a flowchart showing the transaction execution processing of this embodiment. As described above, the present process is started from a state in which a transaction is generated and waiting for a certain completion of the transaction. First, an SHC escrow contract 401 is generated and deployed on the Ethereum platform 102 (step 901). Note that this step is placed before the confirmation of the next deposit, but is not limited to this, and may be after the confirmation of the deposit.
  • step 903 it is confirmed whether or not the deposit has been made. If the deposit has not been made yet, the remittance source is urged to deposit (step 904). If the deposit is confirmed, the remittance destination is notified to that effect (step 905), and the execution of the transaction, for example, the shipment of goods is urged.
  • the completion of the deposit is not necessarily a requirement for starting the execution of the transaction, but can be determined by taking into account other information as one element of the determination of the remittee. However, in general, if the deposit is confirmed, if the preparation for the execution of the transaction is not started, the subsequent processing such as payment is delayed. Therefore, it is preferable to notify the remittee without delay.
  • the deposit or deposit is made by remittance from the remittance source 111 to the address of the SHC escrow contract 402.
  • the SHC of the payment amount is held by the SHC escrow contract 402. Therefore, at the time of payment, a transaction for transferring from the SHC escrow contract 402 to the remittance destination 112 may be executed.
  • the deposit amount of SHC may not be held by the SHC escrow contract 402, but may be deposited by a method known in the art, such as holding the same amount of SHC separately.
  • a refund if the transaction is not fulfilled can be performed in any way known in the art.
  • the remittance source instructs the SHC core to that effect (step 906). Is not fulfilled, the transaction is determined to be unsuccessful and the contract is canceled (step 908). In this case, the virtual currency deposited by any method known in the art is refunded to the sender.
  • the payment transaction is transmitted to the contract and executed (step 907). Execution of the payment transaction is performed by the SHC escrow contract 402 broadcasting to the Ethereum node.
  • the processing of this embodiment is different from the processing of the above-described first embodiment in the following points.
  • the first point is that the transaction is signed only by the remittance source in the first embodiment.
  • the remittance destination is also signed, thereby further improving the reliability.
  • the remittance source has deposited a fixed amount in advance, and it is possible to deposit it in various forms, but a simple system using virtual currency as in this embodiment
  • the deposit is remitted to the SHC escrow contract generated as shown in the first embodiment, and a transaction for transferring the deposit to the remittee is executed when the remittance is executed.
  • the transaction is not fulfilled and it is necessary to refund to the sender, it is preferable to use a transaction in which the SHC Xrow contract remits to the sender.
  • the first embodiment it is desirable to generate a transaction in advance and to prevent tampering until the transaction is executed.
  • a transaction when a transaction is generated, a payment transaction and a refund transaction are executed.
  • Others are basically the same as the first embodiment.
  • FIG. 10 is a diagram showing an example of a transaction used in this embodiment. Similar to the first embodiment described above, in this embodiment, remittance is executed by writing data in a transaction and passing through a predetermined procedure. In the first embodiment, the transaction contents 302 such as the remittance amount and the like, The remittance destination information 303 and the remittee destination information 304 are written in the transaction 301, and the remittance source is signed. In the transaction 1001 of this embodiment, a signature of the remittee is additionally performed. Specifically, for example, it can be implemented by adding a hash value of a transaction to a secret key 1002 of a remittance destination in addition to a secret key of a remittance source and writing.
  • the SHC core system 201 uses the secret key.
  • the SHC core system 201 cannot acquire (decrypt) a secret key stored on a disk or the like and use it unless a user provides an encryption key.
  • the secret key since the secret key is used for other processing, inappropriate processing is avoided by intentionally encrypting and saving with the passphrase presented by the user. You can also. At this time, if the secret key itself is randomly generated by the system, the secret key itself can be presented to the user in advance, and then the user can input the secret key.
  • FIG. 11 is a flowchart showing a transaction generation process according to another embodiment of the present invention.
  • the present embodiment performs the same processing as the first embodiment, except for the generation of a transaction (step 1101) and the signature on the transaction (step 1102).
  • the SHC web service 202 provides an information input screen or the like to a transaction party, that is, a remittance source and a remittee, and inputs necessary information to generate an account (step 801).
  • the SHC core system 201 generates the respective secret keys A and B of the remittance source and the remittance destination (step 803). ).
  • the SHC core system 201 generates a payment transaction and a refund transaction for the transaction amount based on the acquired transaction information (step 1101). Since the SHC corresponding to the payment amount is deposited with the SHC escrow contract 402, The payment transaction is a transaction for transferring the deposited SHC corresponding to the price from the SHC escrow contract 402 to the remittee 112, and the refund transaction is for transferring the deposited SHC corresponding to the price from the SHC escrow contract 402 to the remittance source. This is a transaction transferred to 112.
  • the payment transaction and the refund transaction are generated at the time of generating the transaction as described above, so that the refund process can be easily performed even if the transaction ends abnormally.
  • the deposit processing is performed before the transaction is completed, so it is inevitable not only when the transaction is completed without any problem and the payment processing is performed, but also how to process the currency once deposited when the transaction is unsuccessful.
  • the system must respond as a system, but when generating a payment transaction, if a refund transaction is generated, the refund transaction can be executed without performing various processing if the transaction is not completed. This is extremely effective when providing escrow services using virtual currency.
  • the generated transaction is signed with the remittance source private key A and the remittance destination private key B (step 1102).
  • the private key of both the remittance source and the remittee may be inevitably used.
  • the signed transaction encrypted in this manner is encrypted and stored using a predetermined encryption key (step 806).
  • the transaction is encrypted using pass phrases ⁇ and ⁇ and stored. I do.
  • Encryption is performed using passphrases ⁇ and ⁇ , and a specific encryption method can use any method known in the art.
  • secret key A or B is used. If it is not necessary to use it, it is possible to prevent the SHC core system 201 from generating a new transaction without saving. Also, when a secret key is subsequently used, if the secret key itself is randomly generated by the system, the secret key can be presented to the user in advance so that the user can input the secret key.
  • a payment transaction is first generated, and thereafter, a predetermined condition is satisfied, that is, as a remittance source, a certain completion of a transaction at the remittance destination, for example, a product
  • a predetermined condition that is, as a remittance source, a certain completion of a transaction at the remittance destination, for example, a product
  • the transaction is executed and the remittance destination is remitted. As a result, escrow for safely performing transactions is achieved.
  • FIG. 12 is a flowchart showing the transaction application processing according to this embodiment of the present invention.
  • the present process is started from a state in which a transaction is generated and waiting for a certain completion of the transaction.
  • an SHC escrow contract 401 is generated and deployed on the Ethereum platform 102 (step 901). Note that this step is placed before the confirmation of the next deposit, but is not limited to this, and may be after the confirmation of the deposit.
  • step 903 it is confirmed whether or not the deposit has been made. If the deposit has not been made yet, the remittance source is urged to deposit (step 904). If the deposit is confirmed, the remittance destination is notified to that effect (step 905), and the execution of the transaction is prompted.
  • the completion of the deposit is not necessarily a requirement for starting the execution of the transaction, but can be determined by taking into account other information as one element of the determination of the remittee. However, in general, if the deposit is confirmed, if the preparation for the execution of the transaction is not started, the subsequent processing such as payment is delayed. Therefore, it is preferable to notify the remittee without delay.
  • the deposit or deposit is made by remittance from the remittance source 111 to the address of the SHC escrow contract 402.
  • the SHC of the payment amount is held by the SHC escrow contract 402. Therefore, at the time of payment, a transaction for transferring from the SHC escrow contract 402 to the remittance destination 112 may be executed.
  • a transaction for transferring from the SHC escrow contract 402 to the remittance source 111 is executed using a refund transaction.
  • the remittee fulfills the transaction over a certain amount, for example, if it is a purchase transaction for goods, the item arrives at the purchaser who is the remittance source and the remittance source confirms this, and if it is determined that there is no problem with remittance, the remittance source will Since this is instructed to the SHC core, this is confirmed (step 906). If the processing has not been performed, the transaction is determined to be unsuccessful, the refund transaction is read out, transmitted to the SHC escrow contract, and executed (step 1202). On the other hand, if there is a remittance instruction, the process proceeds to the process shown in FIG.
  • step 1101 payment processing or refund processing is performed by confirming the remittance instruction from the remittance source, but basically in the case of commercial transactions, etc., the delivery of the package causing the remittance is performed.
  • the purchaser of the product which is the source of the remittance, instructs the execution of the payment after the arrival of the product or after various processes after the arrival.
  • information on the arrival of luggage has been centrally managed, so that such a tracking system can be introduced and remittance can be executed without instructions from the remittance source.
  • the remittee performs the delivery processing on condition that the SHC deposits the amount of the money by the remittance source, and removes the SHC deposited on condition that the delivery is completed by the carrier. You can also send money to the recipient.
  • the method of requesting delivery to the carrier and the specific procedure can be performed by any method known in the art, but generally, when a delivery is requested, unique delivery identification information is assigned.
  • the SHC core system 201 can acquire the delivery identification information from the remittance destination or by itself, and can proceed with the processing based on this. When the remittee requests delivery to the carrier, the delivery identification information is set.
  • the delivery identification information is set in the SHC core by notifying the SHC web service 202 or contacting the carrier with the SHC core by associating it with the corresponding transaction. Make information available. That is, when delivery processing is performed and delivery identification information is set, arrival confirmation is set so that a notification is received when delivery is completed.
  • most domestic and overseas carriers are self-organized or related information processing companies and other external organizations and companies, and have delivery management and tracking systems for packages handled, not only shipping and arriving but also passing through offices on the way. And other information are available in real time. In recent years, companies that collect and provide information on multiple shipping companies as well as such individual tracking systems have emerged, especially when delivering overseas, including such companies. Information can also be used.
  • a service such as AfterShip can enable tracking of major carriers including overseas, but the invention is not limited to this, and the same kind of service provided by various companies can be used.
  • the confirmation of the arrival depends on the tracking service to be used.
  • a notification to that effect is given. Since it is set in advance so as to receive, it is sufficient to wait for a notification from the tracking service that the designated package has arrived, and then perform the subsequent processing.
  • the delivery identification information can be an inquiry number set when requesting delivery to a carrier, but is not limited to this, and any information such as a product number can be used as long as it can specify the package to be delivered.
  • the information can be distinguished.
  • tracking processing into the system of the present embodiment, a more effective system can be constructed.
  • present processing can also be incorporated in the above-described first embodiment.
  • FIG. 13 is a flowchart showing execution processing for a transaction according to an embodiment of the present invention. As described above, this processing is started from a state where a certain amount of transaction is completed. First, it is confirmed whether or not there is a defect in the document (step 1301). For example, if the transaction is not domestic but involves import / export, it is a bilateral transaction and various documents are required. Here, the details will not be explained, but if the documents are incomplete, it may be necessary to stop the transaction depending on the degree of incompleteness, so in this case, in general in this case, The SHC core system 201 sends and executes the stored payment transaction or refund transaction to the SHC escrow contract 402 (S1304).
  • S1304 SHC escrow contract
  • the transaction may not be completed due to some accident or the like. In this case, too, the transaction should often be stopped after a predetermined time limit. Therefore, the transaction is also stopped in this embodiment, and the SHC core system 201
  • the escrow contract 402 executes a refund transaction (S1305). Even if the transaction is completed within a certain period within the time limit, if there is an objection from one of the parties, it may be necessary to stop the transaction at the earliest depending on the content, so in this case, generally both parties will discuss According to the determined content, the SHC core system 201 causes the SHC escrow contract 402 to execute a payment transaction or a refund transaction (S1304).
  • the SHC core system 201 causes the SHC escrow contract 402 to execute a payment transaction (S1306).
  • the transaction is executed after waiting for 24 hours.
  • the waiting period is not limited to this, and can be set arbitrarily according to the transaction contents, the use environment, and the like.
  • the execution of the payment transaction and the refund transaction is performed by the SHC escrow contract 402 broadcasting to the Ethereum node.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Le problème décrit par la présente invention est de rendre possible une transaction commerciale rapide et fiable par entiercement en utilisant une devise virtuelle, et de permettre une transaction sûre à un stade précoce à l'aide de la devise virtuelle. La solution de l'invention porte, en fonction d'informations de gestion d'entreprise acquises, sur un système de noyau SHC (201) qui génère une transaction de paiement de montant de transaction commerciale (étape 804). La transaction générée est signée à l'aide d'une clé secrète A d'un émetteur (étape 805), et la transaction signée est chiffrée à l'aide d'une clé de chiffrement prescrite, et sauvegardée (étape 806). Pour la clé secrète A, une phrase secrète α fournie séparément par le destinataire peut être utilisée pour chiffrer davantage la transaction, et la génération d'une nouvelle transaction peut être désactivée.
PCT/JP2019/032205 2018-08-24 2019-08-18 Procédé, système et programme de traitement de transaction WO2020040070A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020538366A JP7195016B2 (ja) 2018-08-24 2019-08-18 トランザクション処理方法、システムおよびプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018157871 2018-08-24
JP2018-157871 2018-08-24

Publications (1)

Publication Number Publication Date
WO2020040070A1 true WO2020040070A1 (fr) 2020-02-27

Family

ID=69592936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/032205 WO2020040070A1 (fr) 2018-08-24 2019-08-18 Procédé, système et programme de traitement de transaction

Country Status (2)

Country Link
JP (1) JP7195016B2 (fr)
WO (1) WO2020040070A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012248915A (ja) * 2011-05-25 2012-12-13 Takeshi Mizunuma 識別名管理システム
JP2018081342A (ja) * 2016-11-14 2018-05-24 株式会社関西アーバン銀行 資金プール装置、ネットショップ決済方法およびネットショップ決済システム
JP2018128723A (ja) * 2017-02-06 2018-08-16 株式会社日立製作所 信用度管理システムおよび信用度管理方法

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6511017B2 (ja) * 2016-06-03 2019-05-08 日本電信電話株式会社 契約合意方法、合意検証方法、契約合意装置および合意検証装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012248915A (ja) * 2011-05-25 2012-12-13 Takeshi Mizunuma 識別名管理システム
JP2018081342A (ja) * 2016-11-14 2018-05-24 株式会社関西アーバン銀行 資金プール装置、ネットショップ決済方法およびネットショップ決済システム
JP2018128723A (ja) * 2017-02-06 2018-08-16 株式会社日立製作所 信用度管理システムおよび信用度管理方法

Also Published As

Publication number Publication date
JPWO2020040070A1 (ja) 2021-10-07
JP7195016B2 (ja) 2022-12-23

Similar Documents

Publication Publication Date Title
US20200013045A1 (en) Stake pool for a secure and trusted data communication system
CA3058558C (fr) Systeme de paiement base sur un serveur de gestion de fonds croises, et procede, dispositif et serveur associe
CA3055645C (fr) Systeme de paiement base sur un serveur de gestion de fonds partages, et procede, dispositif et serveur correspondants
CA2988807A1 (fr) Systeme de paiement entre serveurs de gestion de fonds, et procede, dispositif et serveur
CA3190182A1 (fr) Systeme de paiement base sur serveur pour la gestion de fonds croises, et procede, dispositif et serveur associes
CA2987295C (fr) Systeme de paiement base sur un serveur de gestion de fonds partages, et procede, dispositif et serveur associe
CA2987695A1 (fr) Systeme de paiement base sur un serveur de gestion de fonds partage ainsi que procede, dispositif et serveur associes
CN106203976A (zh) 基于同一资金服务器的支付系统及其支付方法、装置和服务器
WO2020040070A1 (fr) Procédé, système et programme de traitement de transaction
KR102263220B1 (ko) 블록체인을 이용한 전자상거래 지불 방법
CA2987802A1 (fr) Systeme de paiement base sur un serveur de fonds croises et procede, dispositif et serveur de paiement associes
CA2987660C (fr) Systeme de paiement base sur un serveur de gestion de fonds partages, et procede, dispositif et serveur associe
WO2020027269A1 (fr) Système, programme et procédé de transfert d'argent
JP2022011103A (ja) 仮想通貨を用いたエスクロー処理方法、システムおよびプログラム
WO2024116484A1 (fr) Serveur de traitement de jeton, procédé de traitement de jeton et programme
CA2987803A1 (fr) Systeme de paiement base sur un serveur de gestion de fonds croises, et procede, dispositif et serveur associes
CA2987699A1 (fr) Systeme de paiement base sur un serveur partage de gestion de fonds, et procede, dispositif et serveur associes
CA2987442C (fr) Systeme de paiement base sur un serveur de gestion de fonds partage, et procede, dispositif et serveur associes
CA3176595A1 (fr) Systeme de paiement base sur un serveur de gestion de fonds partages, et procede, dispositif et serveur associe

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19852224

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020538366

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19852224

Country of ref document: EP

Kind code of ref document: A1