JP7318427B2 - Trading Systems, Transaction Processing Programs and Trading Methods - Google Patents

Description

The present invention relates to trading systems and the like.

In recent years, following the virtual currency boom, there are great expectations for the usefulness of blockchain as a non-centralized distributed ledger management technology. Virtual currencies are protected by cryptographic technology and can be easily transferred, but they have disadvantages, such as limited stores where they can be used compared to government-issued convertible currencies.

There is also a "community currency" intended for circulation within a specific community. Such "community currency" is introduced as a measure to promote the local economy, but in order to achieve its purpose, it is necessary to add an incentive that goes beyond the disadvantage of being limited to the community that can use it.

"Regional currency" includes "regional promotion coupons" issued by local governments for the purpose of promoting consumption activities in specific regions, and instead of restricting usage conditions, they are distributed at a lower price than the face value.

However, the store that accepts the regional promotion ticket has to check the terms of use and the counterfeit ticket, which is a burden on the store. In addition, the stores that accept regional promotion tickets often do not return change, so the current situation is that users are reluctant to purchase regional promotion tickets.

JP 2012-64005 A JP 2017-204070 A

Here, it is conceivable to replace regional promotion tickets with “regional currency” realized by blockchain. However, when replacing the regional promotion ticket with the local currency realized by the blockchain, the blockchain only verifies the movement of the asset value at the time of product purchase, so the usage conditions etc. are checked in the verification process of the asset movement. The problem is that it is difficult to implement.

In one aspect, the purpose is to provide a mechanism for promoting purchases by users using community currency realized by blockchain.

In one scheme, a trading system includes multiple blockchains that record transactions in different currencies, and a server that monitors transactions on the multiple blockchains. The server responds to a transaction request for asset transfer from the currency of the first blockchain to the currency of the second blockchain, and executes deposit processing according to the conversion rate to the second blockchain. a first execution unit, and a second execution unit that, in response to detection of a purchase transaction using the deposited currency, refunds an amount corresponding to the form of the purchase transaction in the first blockchain; have

According to one aspect, it is possible to provide a mechanism for promoting purchases by users using community currency realized by blockchain.

FIG. 1 is a functional block diagram showing the configuration of a trading system according to the first embodiment. FIG. 2 is a diagram illustrating an example of a condition DB according to the first embodiment; FIG. 3 is a diagram showing an example of transaction data of an exchange source BC. FIG. 4 is a diagram showing an example of transaction data of exchange destination BC. FIG. 5 is a diagram illustrating an example of the flow of transaction processing according to the first embodiment. FIG. 6 is a diagram illustrating an example of the flow of smart contract execution processing according to the first embodiment. FIG. 7 is a diagram illustrating an example of a flowchart of transaction processing executed by the server according to the first embodiment; FIG. 8 is a diagram illustrating an example of the flow of smart contract execution processing according to the second embodiment. FIG. 9 is a diagram illustrating an example of a flowchart of transaction processing executed by the server according to the second embodiment. FIG. 10 is a diagram showing an example of a computer that executes a transaction processing program.

Hereinafter, embodiments of the transaction system, transaction processing program, and transaction method disclosed in the present application will be described in detail based on the drawings. In addition, this invention is not limited by an Example.

[Configuration of transaction system according to embodiment 1]
FIG. 1 is a functional block diagram showing the configuration of a trading system according to the first embodiment. The transaction system 9 shown in FIG. 1 is managed by one blockchain (BC), exchanges a common currency that can be cashed and a community currency managed by the other BC, and manages transactions executed in the community currency. . A server 1 included in such a transaction system 9 monitors transactions of a plurality of blockchains (BC) that record transactions in different currencies. Then, the server 1, in response to a value transfer transaction request for transferring value from the general currency of one BC to the community currency of the other BC, executes deposit processing according to the conversion rate in the other BC. Then, in response to the detection of a purchase transaction in which the purchase is made using the deposited local currency, the server 1 executes cashback according to the form of the purchase transaction and settles the account at one of the BCs. The general currency referred to here is a virtual currency that is convertible into cash and has high circulation. The term "regional currency" as used herein means a virtual currency that is limited to a region, and is a currency that replaces regional promotion coupons. That is, the transaction system 9 including the server 1 discriminates the form of the purchase transaction when the purchase transaction is made in the local currency instead of the regional promotion coupon, and cash backs the user who made the purchase according to the discrimination result. In this way, we provide a mechanism to increase the user's willingness to purchase.

The trading system 9 has a server 1 and a P2P network 3,4 of a plurality of BCs. The server 1 executes a smart contract for transactions using P2P networks 3, 4 of multiple BCs. The smart contract here refers to a program that behaves in such a way that it receives deposits of assets and behaves in accordance with currency exchange rules. After the exchange, act to conduct transactions in community currency smoothly. The P2P networks 3 and 4 of the plurality of BCs are hereinafter referred to as "exchange source BC 3" and "exchange destination BC 4", respectively.

The exchange source BC3 refers to the P2P network of the exchange source (billing token) BC. For example, source BC3 includes multiple nodes participating in a P2P network of BCs that manage common currency. Transaction history of general currency is registered in each node. When a node broadcasts a transaction containing transaction data to the P2P network of the exchange source (charging token) BC, a block containing the transaction is generated, and the generated block is added to the end of each node's blockchain. be. The exchange source BC3 also includes a first transaction monitoring unit 31 .

The first transaction monitoring unit 31 monitors transactions (asset transfers) at the exchange source BC3. For example, when the user transfers the assets held in general currency in the transfer source account of the exchange source BC3 to his own transfer destination account of the exchange destination BC4, the assets held in the transfer source account are transferred to the "deposit account" managed by the smart contract. ”. When the first transaction monitoring unit 31 detects a remittance transaction addressed to the “deposit account”, the first transaction monitoring unit 31 notifies the money deposit receiving unit 11 (to be described later) of the server 1 of the asset transfer to the deposit account.

The exchange destination BC4 refers to the P2P network of the exchange destination (regional promotion coin) BC. For example, the exchange destination BC4 includes multiple nodes participating in a P2P network of BCs that manage local currency. Transaction histories of local currency are registered in each node. When a node broadcasts a transaction containing transaction data to the P2P network of the exchange destination (regional promotion coin) BC, a block containing the transaction is generated, and the generated block is added to the end of the blockchain of each node. be done. The exchange destination BC 4 also includes a second transaction monitoring unit 41 .

The second transaction monitoring unit 41 monitors transactions (asset transfers) in local currency at the exchange destination BC4. For example, when the second transaction monitoring unit 41 detects a transaction in the local currency to be monitored, the second transaction monitoring unit 41 notifies the smart contract execution unit 14 of the server 1 of the detection of the asset transfer in the local currency related to the monitoring target. Notice.

Also, the second transaction monitoring unit 41 monitors the transfer of the transaction to be monitored in response to a request from the server 1 .

The server 1 has a control section 10 and a storage section 20 .

The control unit 10 corresponds to an electronic circuit such as a CPU (Central Processing Unit). The control unit 10 has an internal memory for storing programs defining various processing procedures and control data, and executes various processing using these. The control unit 10 has a deposit acceptance unit 11 , a currency exchange unit 12 , a smart contract execution unit 13 , a refund amount remittance instruction unit 14 and a settlement amount remittance instruction unit 15 . Note that the money deposit reception unit 11 and the exchange money dispensing unit 12 are examples of the first execution unit. The smart contract execution unit 13 is an example of a second execution unit.

The storage unit 20 is, for example, a semiconductor memory device such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. The storage unit 20 has a condition DB (DataBase) 21 .

The condition DB 21 manages conditions for each monitoring target used in the smart contract when there is a transfer transaction. Note that the condition DB 21 is added and updated by the second transaction monitoring unit 41 . An example of the condition DB 21 will now be described with reference to FIG.

FIG. 2 is a diagram illustrating an example of a condition DB according to the first embodiment; As shown in FIG. 2, the condition DB 21 includes monitored account, transfer transaction TxID, deposit amount, refund deadline, permitted use, and permitted transfer destination.

The monitored account indicates the account information of the monitored user. The transfer transaction TxID indicates the ID of the transaction generated when the virtual currency is transferred in the asset transfer transaction. The deposit amount indicates the amount of money deposited in the "deposit account" in which the smart contract is managed.

The refund deadline indicates the deadline for a refund (cashback) of a predetermined price when the user makes a purchase using the local currency, and is determined in accordance with a rule set in advance as a refund rule. Refund (cashback) is performed as an incentive (incentive) to draw out the user's willingness to purchase. The refund period and refund amount are determined by the refund rules. The refund rule referred to here is composed of, for example, the form of the transaction such as the purchaser of the transaction, the object of the transaction (for example, goods or services), and the timing of the transaction. As an example of a refund rule that uses transaction timing, assume that the refund deadline is a certain period of time after the conversion from the general currency to the community currency. If the time of purchase (time of transaction) using local currency is before the refund deadline, the refund amount will be less if the time of purchase is later. That is, the refund amount decreases as the point of purchase is closer to the refund deadline.

Permitted use indicates the use for which the use of Community Currency is permitted. As an example, the permitted usage is set as "in the shopping district" indicating all objects in the shopping district, licensed shops in the shopping district, and licensed objects (e.g., goods and services) in the shopping district. . The permitted transferee indicates a transferee to which the local currency is permitted to be transferred. As an example, the names of relatives up to the second degree, such as parent and child, spouse, and siblings, may be set as permitted transferees.

As an example, when the monitored account is "0x223587", "0x33fa5662" is stored as the transfer transaction TxID and "30,000" is stored as the deposit amount. In addition, "2019/01/10" is stored as the refund deadline, "in the shopping district" as the permitted usage, and "Hanako, Jiro" as the permitted transfer destination.

Returning to FIG. 1, the money deposit reception unit 11 monitors the deposit of money. For example, the money deposit receiving unit 11 receives a notification of asset transfer to the deposit account from the first transaction monitoring unit 31 of the exchange source BC3. The money deposit acceptance unit 11 requests the exchange money dispensing unit 12 to issue a withdrawal request to the exchange destination BC 4 .

The exchange money payout unit 12 requests the payout of exchange money. For example, the exchange money payout unit 12 receives a payout request from the money deposit accepting unit 11 . The exchange money payout unit 12 instructs the exchange company to transfer assets in exchange money (local currency) from the account of the exchange company to the transfer destination account of the user in order to pay out coins according to the exchange rate. . That is, the exchange money payout unit 12 requests the exchange trader to conduct a value transfer transaction from the general currency to the community currency.

In addition, the exchange money dispensing unit 12 requests the second transaction monitoring unit 41 of the exchange destination BC 4 to monitor the asset transfer targeting the user's transfer destination account.

The smart contract execution unit 13 executes smart contracts. For example, the smart contract execution unit 13 receives a detection notification of asset transfer in local currency from the second transaction monitoring unit 41 of the exchange destination BC4. The smart contract execution unit 13 refers to the condition DB 21 according to the refund rule including the type of transaction such as the purchaser of the transaction, the target of the transaction, or the timing of the transaction, and determines the refund amount and settlement amount according to the transaction. . As an example, if the refund rule is a rule relating to the transaction target (corresponding to the permitted usage of the condition DB 21) and the timing of the transaction, the smart contract execution unit 13 may set Calculate the refund amount accordingly. The smart contract execution unit 13 reduces the amount of refund (cashback) as time elapses during the transaction period from the time of exchange (time of payment processing) to the deadline for refund. The smart contract execution unit 13 determines the amount of refund so that the amount of refund becomes zero when the timing of the transaction exceeds the refund deadline. Then, the smart contract execution unit 13 does not calculate the refund amount according to the timing of the transaction when the transaction target does not match the refund rule. Note that the content of the refund rule is an example, and is not limited to this. The calculation of the refund amount according to the refund rule is an example and is not limited to this.

The refund amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the refund amount. For example, the refund amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the refund amount determined by the smart contract execution unit 13 in general currency. After this, at the exchange source BC3, the refund amount in common currency is transferred from the deposit account of the smart contract to the transfer source account of the user.

The settlement amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the settlement amount. For example, the settlement amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the settlement amount determined by the smart contract execution unit 13 in general currency. Thereafter, at the exchange source BC3, the settlement amount in the general currency is transferred from the deposit account of the smart contract to the settlement account of the exchange company.

[Example of transaction data]
Here, an example of transaction data of the exchange source BC3 will be described with reference to FIG. FIG. 3 is an example of transaction data of the exchange source BC. As shown in FIG. 3, transaction data includes transaction ID, time stamp, remittance source, remittance destination, remittance amount, and electronic signature. The transaction ID indicates the ID of the transaction when remittance of general currency in asset transfer transaction. Transaction ID corresponds to transfer transaction TxID of condition DB 21 . Timestamp indicates the time of transaction. The remittance source indicates the account information of the user who made the remittance. The remittance destination indicates the account information of the remittance destination. The remittance amount indicates the remitted amount in general currency. A block containing a transaction describing such transaction data is added as a transaction history to the blockchain of each node in the exchange source BC3.

Also, an example of transaction data of the exchange destination BC4 will be described with reference to FIG. FIG. 4 is an example of transaction data of exchange destination BC. As shown in FIG. 4, the transaction data includes transaction ID, time stamp, remittance source, early destination, remittance amount, and electronic signature. The transaction ID indicates the ID of the transaction when transferring the local currency in the asset transfer transaction. Transaction ID corresponds to transfer transaction TxID of condition DB 21 . Timestamp indicates the time of transaction. The remittance source indicates the account information of the user who made the remittance. The remittance destination indicates the account information of the remittance destination. The remittance amount indicates the remitted amount in local currency. A block containing a transaction describing such transaction data is added as a transaction history to the blockchain of each node in the exchange destination BC4.

[Flow of transaction processing]
FIG. 5 is a diagram illustrating an example of the flow of transaction processing according to the first embodiment. In FIG. 5, the unit of general currency (charging token) used at the exchange source BC3 is called "portion". Common currency coins are sometimes called billing tokens. The unit of the regional currency (regional promotion coin) used in the exchange destination BC4 is called "coin". Community currency coins are sometimes referred to as community promotion coins.

As a premise, user A has accounts in both the exchange source (charging token) BC3 and the exchange destination (regional promotion coin) BC4. User A receives 30,000 portion (for example, cash 3 10,000 yen equivalent). Then, User A intends to receive issuance of 30,000 coins (equivalent to 30,000 yen at a specific store) of regional currency (regional promotion coin) to the transfer destination account of exchange destination (regional promotion coin) BC4. This issuance is accompanied by additional conditions (refund rules). Here, the refund rule is that if all coins are consumed within a month, 10,000 portions will be refunded, if within 6 months, 5,000 portions will be refunded, and after that, no refund will be received. is attached.

Under this premise, user A remits 30,000 portions of common currency (charging token) from the transfer source account to the deposit account for the smart contract (<1>). That is, user A remits the payment to the deposit account in order to receive the issuance of the regional currency (regional promotion coin). This activates the transaction processing of the smart contract.

Then, when the first transaction monitoring unit 31 detects a remittance transaction addressed to the smart contract deposit account, it notifies the server 1 of the detection of the asset transfer to the deposit account (<2>).

Then, in the server 1, the money deposit acceptance unit 11 receives the notification of the detection of the asset transfer to the deposit account, and the exchange money dispensing unit 12 transfers the exchange destination (regional promotion coin) BC4 specified at the time of activation by the user A. Instructions are issued to the exchange company to deposit money to the destination account (<3>). That is, the exchange money payout unit 12 pays out the regional promotion coin according to the exchange rate to the exchange company so as to perform a value transfer transaction from the general currency (charging token) to the regional currency (regional promotion coin). ask for In addition, the exchange money payout unit 12 requests the exchange destination (regional promotion coin) BC4 to monitor the asset transfer targeting the transfer destination account of the user A. When requesting asset transfer monitoring, the exchange money dispensing unit 12 specifies the transfer destination account, the deposit amount deposited in the deposit account, the refund deadline, the permitted usage, and the transferable transfer destination as the monitoring target account of user A. Attach and send information including:

In the exchange destination (regional promotion coin) BC4, when the second transaction monitoring unit 41 receives the request for monitoring the asset transfer, it adds the information attached to the request to the condition DB21. Further, when the exchange agent accepts the payment request, it remits 30,000 regional promotion coins from the payment account to the destination account of user A according to the exchange rate. As a result, user A receives 30,000 coins of the local currency (regional promotion coin) in the transfer destination account managed by him/herself (<4>).

After that, User A adds 20,000 yen in cash to the local currency (regional promotion coin) of the transfer destination account to purchase a computer for 50,000 yen at a local store. Promotion coin) 30,000 coins and cash of 20,000 yen are remitted (<5>). Then, one of the nodes of the exchange destination (regional promotion coin) BC4 updates the transfer transaction TxID corresponding to the transfer destination account in the condition DB 21 to the asset transfer transaction ID. Then, the second transaction monitoring unit 41 detects the asset transfer to be monitored, and transmits to the server 1 an asset transfer detection notification attached with the asset transfer transaction information including the transfer destination account to be monitored ( <6>).

In the server 1, when the smart contract execution unit 13 receives the asset transfer detection notification attached with the asset transfer transaction information including the transfer destination account to be monitored, the condition DB 21 is referred to according to the refund rule, and the refund amount and Determine the settlement amount (<7>). Here, since all the coins have been consumed within one month, the refund amount is determined to be 10,000 portions denominated in the general currency (charging token), and the settlement amount is 20,000 portions denominated in the general currency (charging token). Determined as a potion. Therefore, the refund amount remittance instruction unit 15 instructs the exchange source (charging token) BC3 to remit the refund amount of 10,000 portion to the monitored user A. The payment amount remittance instruction unit 15 instructs the exchange source (billing token) BC3 to transfer the payment amount of 20,000 portions to the monitored user A (<8>).

At the exchange source (billing token) BC3, a refund (cashback) of 10,000 portions is made to the transfer source account of user A (<9.1>). The settlement amount of 20,000 portions is remitted to the store association (<9.2>).

As a result, User A can receive a cashback equivalent to 10,000 yen. On the other hand, the store association receives a general currency (charging token) equivalent to 20,000 yen as a settlement amount in exchange for a regional promotion ticket equivalent to 30,000 yen. The store association will lose the difference of 10,000 yen, but can promote regional development. Note that even if user A does not purchase any product or service at the shopping mall for six months, the user A cannot receive a refund for the amount of coins spent, but the value equivalent to 30,000 yen remains. As a result, the user A can reduce anxiety when purchasing the regional currency (regional promotion coin).

[Example of flow of smart contract execution process]
FIG. 6 is a diagram illustrating an example of the flow of smart contract execution processing according to the first embodiment. Note that the condition DB 21 shows entries corresponding to monitored accounts. A plurality of transaction data of exchange destination (regional promotion coin) BC4 are shown as transaction history.

It is assumed that the smart contract execution unit 13 receives a detection notification of an asset transfer in local currency with attached asset transfer transaction information from the second transaction monitoring unit 41 of the exchange destination (regional promotion coin) BC4. The asset transfer transaction information indicates the transfer destination account "0x223587" to be monitored.

The smart contract execution unit 13 searches for a corresponding entry in the condition DB 21 from the monitoring target transfer destination account (transfer source of the asset transfer) indicated in the asset transfer transaction information (a1).

The smart contract execution unit 13 searches for corresponding transaction data in the transaction history from the transfer transaction TxID of the retrieved entry. The smart contract execution unit 13 acquires the time stamp at which the transfer transaction occurred from the retrieved transaction data. Here, the acquired time stamp is "201809221007". The smart contract execution unit 13 compares the acquired time stamp with the refund deadline, and determines whether the acquired time stamp is within the refund expiration date (a2). Here, since the refund deadline is "2019/01/10", it is determined that the acquired time stamp is within the refund validity period.

The smart contract execution unit 13 causes the payment amount remittance instruction unit 15 to remit the payment amount from the deposit account to the payment account if the acquired time stamp is not within the refund expiration date. On the other hand, if the acquired time stamp is within the expiration date of the refund, the smart contract execution unit 13 acquires the account number of the remittance destination of the transfer transaction from the retrieved transaction data. Here, since it is determined that the acquired time stamp is within the expiration date of the refund, the account number "0x46666" of the remittance destination of the transfer transaction is acquired. Then, the smart contract execution unit 13 determines the account type from the acquired account number of the remittance destination, and determines whether or not the account type is permitted for use (a3). Here, it is assumed that the account type is determined to be "within the shopping mall" from the account number "0x46666" of the remittance destination.

If the account type is not permitted for use, the smart contract execution unit 13 causes the payment amount remittance instruction unit 15 to transfer the payment amount from the deposit account to the payment account. On the other hand, if the account type is permitted for use, the smart contract execution unit 13 refers to the condition DB 21 according to the refund rule to determine the refund amount and settlement amount for the remittance amount in the regional promotion coin in the transaction data. The smart contract execution unit 13 causes the refund amount remittance instructing unit 14 to remit the determined refund amount from the deposit account to the transfer source account. Then, the smart contract execution unit 13 causes the payment amount remittance instruction unit 15 to transfer the determined payment amount from the deposit account to the payment account.

[Server transaction processing flow chart]
FIG. 7 is a diagram illustrating an example of a flowchart of transaction processing of the server according to the first embodiment.

As shown in FIG. 7, the server 1 waiting for a call receives the notification of the asset transfer to the deposit account (step S11). That is, when the user transfers the common currency held assets in the transfer source account of the exchange source BC3 to the transfer destination account of the exchange destination BC4, the held assets are transferred to the deposit account managed by the smart contract. At this time, the server 1 receives the notification of the asset transfer to the deposit account, which is transmitted by the first transaction monitoring unit 31 of the exchange source BC3.

Then, the server 1 instructs the exchange company of the exchange destination BC 4 to transfer assets from the exchange company's account to the user's transfer destination account in exchange currency (local currency) (step S12). That is, the server 1 requests the exchange agent of the exchange destination BC 4 for a value transfer transaction from the general currency to the local currency. In addition, the server 1 requests the second transaction monitoring unit 41 of the exchange destination BC 4 to monitor the asset transfer of the user's transfer destination account (step S13). The second transaction monitoring unit 41 monitors the asset transfer with the user's transfer destination account as the monitoring target account.

After that, the server 1 receives the detection notification of the asset transfer in the local currency from the second transaction monitoring unit 41 of the exchange destination BC 4 (step S14). That is, when a user makes a purchase transaction using community currency, assets are transferred from the user's transfer destination account. At this time, the second transaction monitoring unit 41 detects an asset transfer from the user's account to which the transfer is made, and transmits an asset transfer detection notification. The server 1 receives the asset transfer detection notification sent by the second transaction monitoring unit 41 .

Then, the server 1 determines whether or not the asset transfer is within the expiration date of the refund (step S15). For example, according to the refund rule, the server 1 refers to the refund deadline in the condition DB 21 and the time stamp of the transaction data of the purchase transaction to determine whether the asset transfer is within the refund validity period.

If it is determined that the asset transfer is not within the refund expiration date (step S15; No), the server 1 proceeds to step S18 to settle without refunding. The settlement amount in such a case is the remittance amount of the transaction data of the purchase transaction. On the other hand, if it is determined that the asset transfer is within the expiration date of the refund (step S15; Yes), the server 1 determines whether or not the asset transfer is permitted (step S16). For example, the server 1 refers to the remittance destination of the transaction data of the purchase transaction and the permitted use in the condition DB 21 to determine whether or not the use is permitted.

If it is determined that the asset transfer is not permitted for use (step S16; No), the server 1 moves to step S18 to settle without refunding. The settlement amount in such a case is the remittance amount of the transaction data of the purchase transaction. On the other hand, if it is determined that the asset transfer is permitted for use (Step S16; Yes), the server 1 calculates the refund (refund) amount and the settlement amount according to the refund rules, and transfers the refund amount to the smart contract. instructs the exchange source BC 3 to make a refund from the deposit account managed by , to the transfer source account of the user (step S17). Then, the server 1 shifts to step S18 in order to make a payment after refunding.

In step S18, the server 1 instructs the exchange source BC3 to remit the settlement amount from the deposit account managed by the smart contract to the settlement account of the exchanger (step S18). The server 1 ends transaction processing.

[Effect of Example 1]
According to Example 1 above, the trading system 9 has a plurality of BCs that record transactions in different currencies, and the server 1 that monitors the transactions of the plurality of BCs. The server 1 responds to the transaction request for asset transfer from the currency of the exchange source BC3 to the currency of the exchange destination BC4, and executes the deposit processing according to the conversion rate to the exchange destination BC4. In response to detection of a purchase transaction using the deposited currency, the server 1 refunds an amount corresponding to the form of the purchase transaction at the exchange source BC 3 . According to such a configuration, the transaction system 9 can provide a mechanism for promoting purchases by users using the local currency realized by the BC when the local currency is used as the currency of the exchange destination BC 4 . That is, the transaction system 9 not only detects the movement of the asset value at the time of the purchase transaction, but also verifies the form of the purchase transaction, thereby executing the refund of the amount according to the form of the purchase transaction. We can provide a mechanism for promoting purchases by

Further, according to the first embodiment, the server 1 determines the amount of refund according to the purchase transaction based on rules including at least one transaction mode of transaction timing, transaction purchaser, or transaction target. , to execute a refund of the determined amount. According to such a configuration, the server 1 can promote purchases in local currency by executing refunds using refund rules that limit transaction timing and usage.

Further, according to the first embodiment, the server 1 reduces the amount of refund as time elapses from the timing of the purchase transaction when the rule is the timing of the transaction. determine the amount. According to such a configuration, the server 1 can realize a "decreasing time coin" in which the asset value decreases with the passage of time by using the rule that the refund amount decreases with the passage of time.

Further, according to the first embodiment, the server 1 settles the transaction amount of the purchase transaction at the exchange source BC 3 when the form of the purchase transaction does not conform to the rules, but does not execute the refund. According to such a configuration, the server 1 does not execute a refund even if, for example, the purchase transaction has expired or the usage of the purchase transaction is not limited, but the purchase can be made in the local currency. can be done. As a result, the server 1 can promote conversion to local currency and purchasing with local currency. That is, the user can positively purchase the regional currency instead of the regional promotion ticket.

By the way, in the first embodiment, when a user who has purchased local currency performs a purchase transaction, the server 1 responds to the detection of the purchase transaction and executes a refund of an amount corresponding to the form of the purchase transaction. explained. However, this is not limited to the case where the user who purchased the community currency made the purchase transaction, and the user who purchased the community currency transfers the purchased community currency to the authorized transferee user, and the transferred user makes the purchase transaction. may be used. In such a case, the server 1 may, in response to the detection of the purchase transaction of the transferee user, refund the amount corresponding to the form of the purchase transaction to the transferor user.

Therefore, in the second embodiment, when a user to whom local currency is transferred performs a purchase transaction, the server 1 responds to the detection of the purchase transaction and refunds the amount corresponding to the form of the purchase transaction to the transferor. A case will be described where this is done for the user.

[Configuration of server according to embodiment 2]
The configuration of the server 1 according to the second embodiment is the same as that of the server 1 shown in FIG. 1, so the configuration thereof will be omitted. However, the operations of the smart contract execution unit 13, the refund amount remittance instruction unit 14, and the settlement amount remittance instruction unit 15 are slightly different, so these operations will be explained.

The smart contract execution unit 13 executes smart contracts. For example, the smart contract execution unit 13 receives a detection notification of asset transfer in local currency from the second transaction monitoring unit 41 of the exchange destination BC4. The smart contract execution unit 13 refers to the condition DB 21 and determines whether or not the transferee of the asset transfer is the permitted transferee. It should be noted that the permitted transferee is assumed to be relatives such as parent and child or siblings, which indicate a predetermined relationship with the transferor. If the transfer destination of the asset transfer is the authorized transferee, the smart contract execution unit 13 determines that the transfer is between users, and notifies the second transaction monitoring unit 41 of the exchange destination BC 4 of the transfer destination of the current asset transfer. Request monitoring of asset transfers that target accounts.

If the transferee of the asset transfer is not the authorized transferee, the smart contract execution unit 13 determines that the transfer is due to purchase. Then, the smart contract execution unit 13 refers to the condition DB 21 according to the refund rule including the type of transaction such as the purchaser of the transaction, the target of the transaction, or the timing of the transaction, and determines the refund amount and settlement amount according to the transaction. decide. Since the method of calculating the amount of refund is the same as in the first embodiment, the explanation thereof will be omitted.

The refund amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the refund amount. For example, the refund amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the refund amount determined by the smart contract execution unit 13 in general currency. After this, at the exchange source BC3, the refund amount in common currency is transferred from the deposit account of the smart contract to the transfer source account of the user. In other words, the refund amount is transferred to the transfer source account of the transfer source user who deposited the local currency in the deposit account of the smart contract.

The settlement amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the settlement amount. For example, the settlement amount remittance instruction unit 15 instructs the exchange source BC 3 to remit the settlement amount determined by the smart contract execution unit 13 in general currency. Thereafter, at the exchange source BC3, the settlement amount in the general currency is transferred from the deposit account of the smart contract to the settlement account of the exchange company.

[Example of flow of smart contract execution process]
FIG. 8 is a diagram illustrating an example of the flow of smart contract execution processing according to the second embodiment. Note that the condition DB 21 shows entries corresponding to monitored accounts. A plurality of transaction data of exchange destination (regional promotion coin) BC4 are shown as transaction history.

It is assumed that the smart contract execution unit 13 receives the detection notification of the asset transfer in the local currency attached with the asset transfer transaction information from the second transaction monitoring unit 41 of the exchange destination (regional promotion coin) BC4. The asset transfer transaction information indicates the transfer destination account "0x223587" to be monitored.

The smart contract execution unit 13 searches for a corresponding entry in the condition DB 21 from the monitoring target transfer destination account (transfer source of the asset transfer) indicated in the asset transfer transaction information (b1).

The smart contract execution unit 13 searches for corresponding transaction data in the transaction history from the transfer transaction TxID of the retrieved entry. The smart contract execution unit 13 acquires a remittance destination from the retrieved transaction data. Here, the acquired account number of the remittance destination is "0x46666". The smart contract execution unit 13 determines whether or not the acquired account number of the remittance destination is the permitted transferee of the retrieved entry (b2). Here, it is assumed that the account number "0x46666" of the remittance destination is determined to be the account number of "Hanako", the permitted transferee.

Therefore, the smart contract execution unit 13 requests the second transaction monitoring unit 41 of the exchange destination (regional promotion coin) BC4 to monitor the asset transfer targeting the transfer destination account "0x46666" of the current remittance destination. (b3). Here, for example, the second transaction monitoring unit 41 adds to the condition DB 21 an entry that designates the account to be monitored as "0x46666", which was the current remittance destination. Then, for the added entry, the second transaction monitoring unit 41 sets the refund deadline to the refund deadline “2019/01/10” of the entry of the asset transfer source, and sets the permitted usage to the permitted usage “shopping mall” of the entry of the asset transfer source. Update to "inside". Then, the second transaction monitoring unit 41 monitors the asset transfer of the monitored account including "0x46666".

After that, it is assumed that the smart contract execution unit 13 receives the detection notification of the asset transfer in the local currency attached with the asset transfer transaction information from the second transaction monitoring unit 41 of the exchange destination (regional promotion coin) BC4. The asset transfer transaction information indicates the monitored account "0x46666".

The smart contract execution unit 13 searches for a corresponding entry in the condition DB 21 from the monitored account (source of asset transfer) "0x46666" indicated in the asset transfer transaction information (b11).

The smart contract execution unit 13 searches for corresponding transaction data in the transaction history from the transfer transaction TxID of the retrieved entry. The smart contract execution unit 13 acquires a remittance destination from the retrieved transaction data. Here, the acquired account number of the remittance destination is "0x58888". The smart contract execution unit 13 determines whether or not the acquired account number of the remittance destination is the permitted transferee of the retrieved entry (b12). Here, it is assumed that the remittance destination account number "0x58888" is determined not to be the account number of the permitted transfer destination.

Then, the smart contract execution unit 13 acquires the time stamp at which the transfer transaction occurred from the retrieved transaction data. Here, the acquired time stamp is "201809302118". The smart contract execution unit 13 compares the acquired time stamp with the refund deadline, and determines whether or not the acquired time stamp is within the refund expiration date (b13). Here, since the refund deadline is "2019/01/10", it is determined that the acquired time stamp is within the refund validity period.

The smart contract execution unit 13 causes the payment amount remittance instruction unit 15 to remit the payment amount from the deposit account to the payment account if the acquired time stamp is not within the refund expiration date. On the other hand, if the acquired time stamp is within the expiration date of the refund, the smart contract execution unit 13 acquires the account number of the remittance destination of the transfer transaction from the retrieved transaction data. Here, since it is determined that the acquired time stamp is within the expiration date of the refund, the account number "0x58888" of the remittance destination of the transfer transaction is acquired. Then, the smart contract execution unit 13 determines the account type from the acquired account number of the remittance destination, and determines whether or not the account type is permitted for use (b14). Here, it is assumed that the account type is determined to be "within the mall" from the account number "0x58888" of the remittance destination.

If the account type is not permitted for use, the smart contract execution unit 13 causes the payment amount remittance instruction unit 15 to transfer the payment amount from the deposit account to the payment account. On the other hand, the smart contract execution unit 13 determines the refund amount and settlement amount for the remittance amount (regional promotion coin) in the transaction data by referring to the condition DB 21 according to the refund rule if the account type is used for permitted purposes. Here, since the account type is the permitted use, the refund amount and settlement amount are determined. As an example, if the refund rule is 2000 coins or less, the refund amount is 300 portions denominated in general currency (charging token). Then, the refund amount is determined to be 300 portions. The settlement amount is determined as the remaining 1700 portions.

Then, the smart contract execution unit 13 causes the refund amount remittance instructing unit 14 to remit the determined refund amount from the deposit account to the transfer source account of the transfer source. Then, the smart contract execution unit 13 causes the settlement amount remittance instruction unit 15 to remit the determined settlement amount from the deposit account to the settlement account.

As a result, the smart contract execution unit 13 can provide a mechanism for promoting purchases using the community currency even if the community currency is transferred between users who have a predetermined relationship with the user. In addition, the smart contract execution unit 13 can prevent fraudulent use of community currency.

[Server transaction processing flow chart]
FIG. 9 is a diagram illustrating an example of a flow chart of transaction processing of the server according to the second embodiment.

As shown in FIG. 9, the server 1 waiting for a call receives the notification of the asset transfer to the deposit account (step S21). That is, when the user transfers the common currency held assets in the transfer source account of the exchange source BC3 to the transfer destination account of the exchange destination BC4, the held assets are transferred to the deposit account managed by the smart contract. At this time, the server 1 receives the notification of the asset transfer to the deposit account, which is transmitted by the first transaction monitoring unit 31 of the exchange source BC3.

Then, the server 1 instructs the exchange company of the exchange destination BC 4 to transfer assets from the exchange company's account to the user's transfer destination account in exchange currency (local currency) (step S22). That is, the server 1 requests the exchange agent of the exchange destination BC 4 for a value transfer transaction from the general currency to the local currency. In addition, the server 1 requests the second transaction monitoring unit 41 of the exchange destination BC 4 to monitor the asset transfer of the user's transfer destination account (step S23). The second transaction monitoring unit 41 monitors the asset transfer with the user's transfer destination account as the monitoring target account.

After that, the server 1 receives the detection notification of the asset transfer in the local currency from the second transaction monitoring unit 41 of the exchange destination BC 4 (step S24). That is, when a user transfers part or all of his/her community currency, assets are transferred from the user's account. Also, when a user makes a purchase transaction using community currency, assets are transferred from the user's account. At this time, the second transaction monitoring unit 41 detects an asset transfer from the user's account and transmits an asset transfer detection notification. The server 1 receives the asset transfer detection notification sent by the second transaction monitoring unit 41 .

The server 1 that has received the asset transfer detection notification refers to the condition DB 21 and determines whether or not it is an asset transfer between users (step S25). If it is determined to be an asset transfer between users (step S25; Yes), the server 1 changes the target of asset transfer monitoring to the account to which the asset was transferred (step S26). The second transaction monitoring unit 41 monitors the asset transfer with the account to which the asset has been transferred as the account to be monitored. Then, the server 1 proceeds to step S24 in order to receive the next asset transfer detection notification.

On the other hand, if it is determined that the transaction is not an asset transfer between users (step S25; No), the server 1 determines whether or not the asset transfer is within the expiration date of the refund (step S27). For example, according to the refund rule, the server 1 refers to the refund deadline in the condition DB 21 and the time stamp of the transaction data of the purchase transaction to determine whether the asset transfer is within the refund validity period.

If it is determined that the asset transfer is not within the refund expiration date (step S27; No), the server 1 proceeds to step S30 to settle without refunding. The settlement amount in such a case is the remittance amount of the transaction data of the purchase transaction. On the other hand, if it is determined that the asset transfer is within the expiration date of the refund (step S27; Yes), the server 1 determines whether or not the asset transfer is permitted (step S28). For example, the server 1 refers to the remittance destination of the transaction data of the purchase transaction and the permitted use in the condition DB 21 to determine whether or not the use is permitted.

If it is determined that the asset transfer is not permitted for use (step S28; No), the server 1 proceeds to step S30 to settle without refunding. The settlement amount in such a case is the remittance amount of the transaction data of the purchase transaction. On the other hand, if it is determined that the asset transfer is permitted for use (step S28; Yes), the server 1 calculates the refund (refund) amount and settlement amount according to the refund rules, and transfers the refund amount to the smart contract. instructs the exchange source BC 3 to repay the transfer source account of the user (or the transfer source) from the deposit account managed by (step S29). Then, the server 1 shifts to step S30 in order to make a payment after refunding.

In step S30, the server 1 instructs the exchange source BC3 to transfer the settlement amount from the deposit account managed by the smart contract to the settlement account of the exchange company (step S30). The server 1 ends transaction processing.

[Effect of Example 2]
According to the second embodiment, the server 1 further requests the exchange destination BC 4 to detect a transaction whose monitoring target is the transfer source with which the asset transfer transaction was made. In response to detecting a transaction using deposited currency, the server 1 determines whether the transaction is a purchase transaction or an asset transfer transaction between users. Then, when the server 1 determines that the transaction is an asset transfer transaction between users, the server 1 requests the exchange destination BC 4 to detect a transaction targeting the asset transfer destination of the asset transfer transaction between users. do. According to such a configuration, the server 1 can continue the purchase promotion mechanism using the local currency even if there is an asset transfer in the local currency between users. Also, the server 1 can prevent misrepresentation that the local currency has been used.

[others]
Note that the server 1 can be realized by installing functions such as the above-described control unit 10 and storage unit 20 in an information processing apparatus such as a known personal computer or workstation.

Also, each component of the illustrated apparatus does not necessarily have to be physically configured as illustrated. That is, the specific mode of distributing/integrating the devices is not limited to the illustrated one, and all or part of them can be functionally or physically distributed/integrated in arbitrary units according to various loads and usage conditions. can be configured as For example, the money deposit reception unit 11 and the exchange money dispensing unit 12 may be integrated as one unit. The refund amount remittance instruction unit 14 and the settlement amount remittance instruction unit 15 may be integrated as one unit. On the other hand, the smart contract execution unit 13 is composed of a determination unit that determines whether or not the transfer destination of the asset transfer is the permitted transfer destination, an execution unit that determines whether the transfer destination of the asset transfer is the permitted transfer destination, and a It may be distributed to the execution part when the transfer destination is not the permission transfer destination. Alternatively, the storage unit 20 may be connected to the server 1 via a network as an external device.

Further, various processes described in the above embodiments can be realized by executing a prepared program on a computer such as a personal computer or a work station. Therefore, an example of a computer that executes a transaction processing program that implements the same functions as those of the server 1 shown in FIG. 1 will be described below. FIG. 10 is a diagram showing an example of a computer that executes a transaction processing program.

As shown in FIG. 10, the computer 200 has a CPU 203 that executes various arithmetic processes, an input device 215 that receives data input from the user, and a display control unit 207 that controls the display device 209 . The computer 200 also has a drive device 213 that reads programs and the like from a storage medium, and a communication control unit 217 that exchanges data with other computers via a network. The computer 200 also has a memory 201 that temporarily stores various information and a HDD (Hard Disk Drive) 205 . The memory 201 , CPU 203 , HDD 205 , display control section 207 , drive device 213 , input device 215 and communication control section 217 are connected via a bus 219 .

The drive device 213 is a device for the removable disk 211, for example. HDD 205 stores transaction processing program 205a and transaction processing related information 205b.

The CPU 203 reads the transaction processing program 205a, develops it in the memory 201, and executes it as a process. Such a process corresponds to each functional unit of the server 1. FIG. Transaction processing related information 205b corresponds to condition DB 21 . For example, the removable disk 211 stores information such as the transaction processing program 205a.

Note that the transaction processing program 205a does not necessarily have to be stored in the HDD 205 from the beginning. For example, a flexible disk (FD), a CD-ROM (Compact Disk Read Only Memory), a DVD (Digital Versatile Disk), a magneto-optical disk, an IC (Integrated Circuit) card inserted into the computer 200, and other "portable physical media" ” to store the program. Then, the computer 200 may read and execute the transaction processing program 205a from these.

1 Server 10 Control Unit 11 Money Deposit Receiving Unit 12 Exchange Money Dispensing Unit 13 Smart Contract Execution Unit 14 Refund Amount Remittance Instruction Unit 15 Settlement Amount Remittance Instruction Unit 20 Storage Unit 21 Condition DB
3 Exchange source BC
31 first transaction monitoring unit 4 exchange destination BC
41 second transaction monitoring unit 9 transaction system

Claims (7)

multiple blockchains that record transactions in different currencies;
a server that monitors transactions of the plurality of blockchains;
The server is
A first execution of performing deposit processing according to a conversion rate to the second blockchain in response to a transaction request for asset transfer from the currency of the first blockchain to the currency of the second blockchain. Department and
a second execution unit that, in response to detection of a purchase transaction using the deposited currency, refunds an amount corresponding to the form of the purchase transaction in the first blockchain;
A trading system characterized by having The second execution unit determines a refund amount according to the purchase transaction based on rules including at least one transaction form of transaction timing, transaction purchaser, or transaction target, and 2. The trading system of claim 1, wherein the transaction system performs refunds. The second execution unit, when the rule is a rule for the timing of the transaction, adjusts the refund amount so that the timing of the purchase transaction reduces the refund amount as time elapses from the time of the deposit. 3. The trading system of claim 2, further comprising: determining. The second execution unit further settles the transaction amount of the purchase transaction in the first blockchain, but does not execute the refund, if the form of the purchase transaction does not conform to the rule. 4. Trading system according to claim 2 or claim 3. The first execution unit further requests the second blockchain to detect a transaction targeting the transfer source where the asset transfer transaction was made,
The second execution unit
In response to detecting a transaction using deposited currency, determine whether the transaction is a purchase transaction or a transaction of asset transfer between users, and determine that the transaction is a transaction of asset transfer between users. 2. The trading system according to claim 1, wherein when it is determined, the second block chain is requested to detect a transaction that targets the asset transfer destination of the asset transfer transaction between the users. In response to a transaction request for asset transfer from a currency of a first blockchain that records transactions of a predetermined currency to a currency of a second blockchain that records transactions of a currency different from the first blockchain, Execute deposit processing according to the conversion rate for the second blockchain,
A transaction processing program characterized by causing a computer to execute a process of refunding an amount corresponding to the form of the purchase transaction in the first block chain in response to detection of a purchase transaction using the deposited currency. . In response to a transaction request for asset transfer from a currency of a first blockchain that records transactions of a predetermined currency to a currency of a second blockchain that records transactions of a currency different from the first blockchain, Execute deposit processing according to the conversion rate for the second blockchain,
A transaction method, wherein, in response to detection of a purchase transaction using deposited currency, a computer executes a process of refunding an amount corresponding to the form of the purchase transaction in the first blockchain.

Images