Digital currency management system
The digital currency management system integrates digital currency transactions with existing banking systems by using a joint deposit account, allowing seamless integration and stable transactions without altering banking procedures, addressing the volatility risks of digital currency.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- DIGITAL PLATFORMER CO LTD
- Filing Date
- 2024-12-26
- Publication Date
- 2026-07-08
Smart Images
Figure 2026114000000001_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a digital currency management system, and particularly to a mechanism for realizing transactions of digital currency backed by fiat currency.
Background Art
[0002] Recently, the trading of digital currency (also referred to as "virtual currency" or "cryptocurrency") has become widespread by digital currency exchange operators. Under such circumstances, methods for providing platform services on the premise of an environment where digital currency can be used have been proposed (see, for example, Patent Document 1 below).
[0003] Originally, digital currency, that is, virtual currency, has attracted attention as a mechanism that enables the exchange of property values without going through financial institutions such as banks, and can be obtained and exchanged from virtual currency exchange operators called "exchanges" or "trading houses". Virtual currency is not fiat currency issued by a country or its central bank, and since it has no backing assets, its price tends to fluctuate greatly due to various factors such as the supply and demand relationship of users.
[0004] In recent years, with the development of distributed ledger technologies such as blockchain, financial institutions such as banks have also started to provide various services using virtual currency. For example, a token management system for issuing and transferring tokens based on financial products has been proposed on the blockchain (see, for example, Patent Document 2 below).
[0005] Although virtual currency is expected to have effects such as cost reduction and high convenience, its high volatility (price fluctuation rate) poses a high risk and lacks stability as a settlement means or asset holding. Therefore, there is a background where so-called stablecoins have emerged as virtual currency designed to be linked to assets such as the yen, US dollar, and gold for the purpose of stabilizing the transaction price.
Prior Art Documents
Patent Documents
[0006] [Patent Document 1] Special Publication No. 2024-510307 [Patent Document 2] Patent No. 6865251 [Overview of the project] [Problems that the invention aims to solve]
[0007] Unlike private cryptocurrency exchange operators, when financial institutions such as banks handle cryptocurrencies, they use them as stablecoins. That is, they issue tokens backed by fiat currencies such as the yen, record them on a blockchain, and use them as local currencies or points.
[0008] Banks handle three main functions: deposit services, lending services, and foreign exchange (settlement) services. To ensure the smooth and reliable execution of these operations in the enormous volume of daily transactions, the core banking system, the accounting system, supports these functions. Due to its importance and scale, the accounting system requires high reliability and enormous processing capacity. Therefore, there is a strong need to avoid significant changes or additions to existing operations and various business procedures within the accounting system. Even when banks introduce new cryptocurrency services, such as issuing local currencies, fundamental modifications to the accounting system are impossible. Furthermore, if the entire history of cryptocurrency usage by numerous users were to be integrated into the accounting system for data management, it could exceed the processing capacity of the core system and place an additional burden on existing banking operations.
[0009] Therefore, the present invention aims to provide a cryptocurrency management system that can easily integrate with a blockchain system for recording cryptocurrency transactions, without modifying existing banking accounting systems and maintaining their independence. In the following description of the present invention, "cryptocurrency" will be replaced with "digital currency." [Means for solving the problem]
[0010] To achieve the aforementioned objective, the digital currency management system according to the present invention, provided that a joint deposit account is opened at a financial institution in which the deposits of unrelated users are aggregated for the purpose of trading digital currencies backed by legal tender, controls the transfer of funds between the legal tender deposit account and the joint deposit account when a request is made for the transfer of funds between a legal tender deposit account managed by the financial institution and a digital currency account managed outside the financial institution, and the amount of increase or decrease in funds in the joint deposit account for each request corresponds to the amount of increase or decrease in funds in one or more of the digital currency accounts related to that request.
[0011] Furthermore, the digital currency management system according to the present invention is characterized in that, if the request is a request to charge the digital currency account, it sends a request to the financial institution for the transfer of funds from the designated user's fiat currency account to the joint deposit account, and if the request is a request to exchange for fiat currency, it sends a request to the financial institution for the transfer of funds from the joint deposit account to the designated user's fiat currency account.
[0012] Furthermore, the digital currency management system according to the present invention is characterized in that, regardless of whether the request is a request to charge the digital currency account or a request to exchange it for legal tender, the change in the balance of the designated user's legal tender account in the request is inversely proportional to the change in the balance of the joint deposit account, and the change in the balance of the joint deposit account is directly proportional to the change in the balance of the designated user's digital currency account in the request.
[0013] Furthermore, the digital currency management system according to the present invention is characterized in that the accounting system of the financial institution does not manage the deposit shares of each user related to the joint deposit account, and that fund transfers are made between the legal tender deposit account and the joint deposit account, and that the legal tender deposit account includes accounts opened at affiliated financial institutions related to the financial institution. [Effects of the Invention]
[0014] The digital currency management system according to the present invention allows for the transfer of deposits from bank deposit accounts to digital currency accounts for transactions using digital currency, and the conversion of funds in digital currency accounts back into bank deposit accounts, without requiring any changes to existing banking procedures, accounting system operations, or data processing. Therefore, financial institutions managing accounting systems do not need to make large-scale modifications to their accounting systems to introduce digital currency services using digital currency accounts, thus facilitating the introduction of digital currency services.
[0015] In the digital currency management system according to the present invention, a blockchain system for digital currency that records transaction history based on distributed ledger technology is linked with the accounting system of a bank or the like, through a joint deposit account for an unspecified number of users. The joint deposit account of the present invention is a deposit account that concerns all users of digital currency and is held in the name of the bank, but in terms of settlement procedures, it is not particularly different from the methods used in the accounting systems of banks and the like. Furthermore, each user's share and the specific details of digital currency transactions are managed on the blockchain, and the accounting system only needs to manage the total deposit balance of the joint deposit account. Since both the accounting system of the bank or the like and the blockchain are configured not to record digital currency transaction history redundantly, it has the effect of enabling linkage with the blockchain system without increasing the processing load of the accounting system. [Brief explanation of the drawing]
[0016] [Figure 1] This diagram shows the overall configuration of the digital currency management system according to the present invention. [Figure 2] This is a flowchart illustrating the processing steps of a digital currency management system. [Figure 3] This diagram shows the sequence for the self-charging process. [Figure 4] This is a diagram showing a sequence diagram in the case of self-cashing processing. [Figure 5] This is a conceptual diagram showing other bank charge processing. [Figure 6] This is a diagram showing a sequence diagram in the case of other bank charge processing. [Figure 7] This is a diagram showing a sequence diagram in the case of other bank cashing processing. [Figure 8] This is a sequence diagram for explaining the settlement processing of franchise stores.
Embodiments for Carrying Out the Invention
[0017] Hereinafter, an embodiment of a digital currency management system according to the present invention will be described in detail with reference to the drawings. In all the drawings for explaining the following embodiments, the same parts are generally denoted by the same reference numerals, and the repeated description thereof will be omitted. In addition, a part of the configuration that is not important for explanation in each drawing is omitted and shown. It should be noted that the present invention can be implemented in many different forms and is not limited only to the description disclosed below. Needless to say, various changes, substitutions, and omissions are possible without departing from the gist thereof.
[0018] First, definitions of terms are given for the understanding of the following description. When depositing money in a financial institution, it is necessary to open an account, but in principle, the account must be in one's own name. That is, a deposit account can be opened in the name representing an individual person or an organization of a corporation. However, depending on the financial institution, it is also possible to open an account in the name of an arbitrary group. An arbitrary group is a group in which people gather and carry out activities with a specific purpose and is an organization that does not have a legal personality. Specifically, for example, it is an account that is exceptionally recognized for the convenience of a plurality of interested parties such as the fund management of a neighborhood association based on the geographical relationship of those having a residence in a certain area and a condominium self-management association.
[0019] Because voluntary associations do not have legal personality, opening a bank account for them almost always requires special procedures and conditions. For example, they must prove that they have an organizational structure by presenting documents such as the association's bylaws, articles of association, and records of their activities. In some cases, identification documents of the representative may also be required.
[0020] On the other hand, the "joint deposit account" used in this invention is, as described above, a deposit account for all users who use digital currency. Although it is an account for multiple users, it does not presuppose that the users have geographical ties or that it is an account for a limited number of people with vested interests. It differs from accounts held by voluntary organizations that have existed before in that it is a deposit account for an unspecified number of unrelated depositors. Furthermore, in the joint deposit account of this invention, the account holder is the financial institution (bank, etc.) itself, and there are no special procedures or conditions required to open an account that have existed before. The joint deposit account is similar to accounts held in the name of voluntary organizations that have existed before in that it is a deposit account for multiple users.
[0021] Furthermore, a joint deposit account is, after all, a type of ordinary deposit account. Therefore, in order to guarantee full protection of deposits under the deposit insurance system (an insurance system in which financial institutions pay deposit insurance premiums to the Deposit Insurance Corporation, and in the event of a financial institution's failure, a certain amount of deposits are protected), it is possible to convert it into a settlement deposit (for example, a current account). In this embodiment of the digital currency management system, joint deposit accounts are treated as settlement deposits, and the full protection of deposits for all users is ensured.
[0022] A "digital currency account" refers to an account used for transactions using digital currency, while a "fiat currency account" refers to an account used for transactions using fiat currency, such as a regular savings account. Examples of fiat currency accounts include yen accounts and dollar accounts, but are not limited to these. Furthermore, "digital currency services" refers to services related to any transaction using digital currency, including, for example, "digital currency exchange." "Digital currency exchange" refers to a transaction that converts fiat currency in a user's fiat currency account into digital currency, or a transaction that converts digital currency in a user's digital currency account into fiat currency.
[0023] Figure 1 is a diagram showing the overall configuration of the digital currency management system 100 according to this embodiment. Figures 2(A) and 2(B) are flowcharts showing the main processing steps of the digital currency management system. The digital currency management system 100 is broadly divided into a blockchain system 1 and an API (Application Programming Interface) 2. The main components of the blockchain system 1 include a user registration unit 11 for registering information of users who use the digital currency service, an API linkage unit 12 for linking with API 2, and a blockchain control unit 13 that handles commands for reading and writing to blockchain data. In reality, there are various other means for realizing different functions, but these are not directly related to the present invention and are therefore omitted.
[0024] First, we will show an example of the main processing steps of the digital currency management system 100. The user registration unit 11 performs identity verification of user 4 in advance and records the user's information as blockchain data in the blockchain DB 14 (step S201 in Figure 2(A)). The digital currency account established in the digital currency management system 100 of this embodiment is not an account opened within a financial institution such as a bank, but an account managed by the blockchain system 1. Therefore, identity verification is not necessarily required as it does not directly fall under the identity verification required when financial institutions conduct transactions such as concluding deposit contracts, as stipulated in the "Act on Identity Verification of Customers, etc. by Financial Institutions, etc." However, the digital currency management system 100 of this embodiment performs identity verification of the user when opening a digital currency account.
[0025] Each user 4 whose identity has been verified can use the digital currency service through a designated application launched on their information terminal 4a. Specifically, for example, as a digital currency exchange, they can request to withdraw N yen from their fiat currency account (regular savings account) 31 and charge it to their digital currency account in the blockchain DB 14. The transaction history of each digital currency account will be managed within the blockchain system 1 for each user 4.
[0026] When the request instructed by user 4 using the specified application is received by the blockchain system 1 (step S202 in Figure 2(A)), it is passed to the API integration unit 12. Next, the API integration unit 12 makes an API call to API 2 (step S203 in Figure 2(A)). When the API integration unit 12 receives an API response from API 2 (step S204 in Figure 2(A)), it instructs the blockchain control unit 13 to record the information in the blockchain DB 14 (step S207 in Figure 2(A)).
[0027] API2 responds to the API call from the API integration unit 12 described above, creates a command in the bank's accounting system 3 to transfer funds between user 4's deposit account and the joint deposit account 32, and sends this command to the bank's accounting system 3. In other words, it issues a settlement command specifying how much money should be transferred from whose savings account to the joint deposit account, or how much money should be transferred from the joint deposit account to whose savings account.
[0028] The bank's accounting system 3 responds to a command from API 2 and, for example, moves the commanded amount of funds (i.e., a deposit) between the designated user 4's ordinary deposit account 31 and the bank's joint deposit account 32. The accounting system 3 then returns the result of the fund transfer to API 2, and API 2, in response, sends an API response to the blockchain system 1's API integration unit 12. If the API integration unit 12 confirms that the fund transfer has been completed successfully, it communicates the contents of the API call and API response to the blockchain control unit 13. The blockchain control unit 13 records this information in the blockchain DB 14.
[0029] When recorded in the blockchain DB14, the balance of the digital currency account will increase or decrease as a result of the fund transfer, and the latest balance will be calculated. This latest balance (and the reason if the fund transfer was unsuccessful) is displayed on the user's information terminal 4a as the charge request result. In the case of the above-mentioned charge request to the digital currency account, user 4 can use the increased digital currency balance displayed on the information terminal 4a to purchase desired goods, etc.
[0030] Next, we will detail the data flow between blockchain system 1, API 2, and X Bank's accounting system 3, as well as the movement of fiat currency, in the form of digital currency exchange, divided into various embodiments. In the following explanation, fiat currency will be described as Japanese yen.
[0031] 1. Self-charging process Self-charge processing means that a user's fiat currency account (i.e., a regular savings account) and joint deposit account are located at the same Bank X (Bank X is often also the issuer of digital currency, but is not necessarily limited to being the issuer), and the amount of currency in the user's digital currency account increases by transferring funds from the regular savings account to the joint deposit account. Now, let's assume that user 4 launches the application on information terminal 4a and charges digital currency equivalent to N yen into their digital currency account.
[0032] Figure 3 shows the sequence diagram for the self-charge process. The general outline is as explained in Figure 2(A), but users often do not keep track of the balance of their digital currency account at all times. Since users often check their balance and charge only when it is insufficient, Figure 3 (1) to (4) shows that the first step is to check the balance of the digital currency account. Note that if a charge is made without checking the balance, Figure 3 (1) to (4) are omitted.
[0033] First, when a user requests to check the balance of their digital currency account on the information terminal 4a (Figure 3(1)), the blockchain control unit 13 of the blockchain system 1 issues a request to read the latest balance of the digital currency account of user 4 who made the balance check request from the blockchain DB 14 (Figure 3(2)). Needless to say, the read request includes user identification information. In this embodiment, reading the balance of the digital currency account does not mean directly reading the balance itself, but rather calculating the balance based on the accumulated transaction history that has been recorded in the past. Alternatively, the balance information of each user could be recorded and read from there. In any case, the blockchain system 1 is configured to manage the balance of each user's digital currency account by combining each user ID and transaction information related to the balance.
[0034] When the blockchain control unit 13 receives balance information (Figure 3(3)), it displays the balance on the information terminal 4a (Figure 3(4)). If user 4 checks the balance and determines that it is insufficient, they request a top-up on the information terminal 4a (Figure 3(5)). The process after the top-up request follows the same procedure as in Figure 2(A), but will be explained again in conjunction with Figure 3.
[0035] The API integration unit 12 receives a charge request from user 4 (5 in Figure 3, step S202 in Figure 2(A)) and issues an API call to API 2 which is a settlement request (6 in Figure 3, step S203 in Figure 2(A)). A settlement request for self-bank charge processing is an instruction to transfer N yen from the user's ordinary deposit account 31 to a joint deposit account 32 in the name of Bank X. In response, API 2 sends a withdrawal request message to the accounting system 3, which includes authentication information (ID, date and time of transmission, signature) and transaction information (source of remittance, amount information). In the case of self-bank charge processing, the "source of remittance" is the user's own ordinary deposit account 31 that made the charge request. Note that the "destination" is always the joint deposit account 32, so this information is practically unnecessary in the withdrawal request message.
[0036] The settlement process in the accounting system 3 is instantaneous. When funds are withdrawn from the user's savings account 31, which is designated as the sender, they are deposited into the joint deposit account 32 in the name of Bank X almost in real time. Therefore, API 2 functions as an instant settlement gateway between the blockchain system 1 and the accounting system 3. At this point, the balance in the user's savings account 31 within Bank X becomes -N yen, and the balance in the joint deposit account 32 in the name of Bank X becomes +N yen. In other words, the balance changes of the savings account and the joint deposit account are inversely proportional.
[0037] When the immediate settlement process is completed in the accounting system 3, API 2 immediately receives a response message containing the settlement process result and information identifying the process (Step S204 in Figure 3(7), Figure 2(A)). If the specified amount cannot be withdrawn due to insufficient funds in the ordinary deposit account 31, the settlement process result in the response message is reported to API 2 as "unavailable" (Step S206 in Figure 2), and finally, a message indicating that the charge could not be made is displayed on the information terminal 4a.
[0038] When the API integration unit 12 receives a response message indicating that the immediate settlement process has been completed, it instructs the blockchain control unit 13 to record the received content on the blockchain (step S207 in Figure 3(8), Figure 2(A)). In response, the blockchain DB 14 records in a cumulative manner as transaction history that N yen has been transferred from the ordinary deposit account in the name of the user designated as the sender to the joint deposit account 32. In the case of self-charge processing, the increase in the joint deposit account corresponds to the increase in the digital currency account. In other words, looking at the relationship between the joint deposit account and the digital currency account, the balance changes of both are directly proportional.
[0039] Next, the blockchain system 1 can calculate each user's balance by summing up increases and decreases in the digital currency account based on the transaction history recorded on the blockchain, and the latest balance of user 4's digital currency account is determined to be the amount increased by +N yen through this self-charge process. This latest balance is displayed on the user's information terminal 4a (Figure 3 (10), step S208 in Figure 2 (A)), and user 4 can confirm that the funds have been charged to their digital currency account. At this time, it is preferable that the blockchain system 1 is configured to check whether there is a difference between the total balance of the joint deposit account and the total balance obtained by summing the balances of each user's digital currency account, and to output an alert if there is a difference.
[0040] As described above, the digital currency management system 100 of this embodiment links the increase or decrease in deposits in a joint deposit account under the name of Bank X with the increase or decrease in the currency balance of the user's digital currency account. This clearly demonstrates that the digital currency forms a stablecoin backed by fiat currency. Of particular note is that the accounting system 3's processing based on the withdrawal request message in the case of the self-charge process described above, although using a joint deposit account as the account, is no different from a transfer to the head office or a branch within the same bank, which is routinely carried out as part of bank settlement operations.
[0041] Therefore, the charging of digital currency does not require any changes to the operation or administrative procedures of the accounting system 3. Moreover, since the funds can be moved as long as the basic information of the sender is known, the accounting system 3 only manages the total balance as information for joint deposit accounts. In other words, joint deposit accounts do not contain the names of multiple users. The result of the settlement processing by the accounting system 3 is linked to API 2 (Figure 3 (7), step S204 in Figure 2 (A)), and the charge request result is recorded in the blockchain DB 14. As a result, the accounting system 3 itself does not need to hold information about the digital currency account (such as the user's share of the funds transferred to the joint deposit account and the purpose of settlement), and only the total balance needs to be managed. Therefore, without placing a burden on the accounting system 3, the amount withdrawn from the ordinary deposit account 31 is deposited into the joint deposit account 32, increasing the total balance of the joint deposit account 32 and increasing the currency balance of the requesting user's digital currency account by the same amount, thus enabling a charge process from a fiat currency account to a digital currency account.
[0042] 2. Self-processed cash redemption Self-bank redemption processing means that, in the opposite case of self-bank charge processing, the user's legal tender account (i.e., savings account) and joint deposit account are located at the same Bank X (Bank X is often also the issuer of digital currency, but is not necessarily limited to being the issuer), and a transfer of funds from the joint deposit account to the savings account reduces the funds in the user's digital currency account. Now, let's assume that user 4 launches the application on information terminal 4a and redeems the digital currency equivalent to N yen in their digital currency account to their savings account.
[0043] Similar to the self-charge process, User 4 will first check the balance of their digital currency account if necessary (Figure 4 (1) to (4)).
[0044] User 4 requests a cash withdrawal on information terminal 4a (Figure 4(5), step S202 in Figure 2(B)). Upon receiving the cash withdrawal request from user 4, the blockchain control unit 13 first instructs the blockchain to record a transaction history indicating that N yen will be withdrawn from the joint deposit account in the name of Bank X (Figure 4(6), step S213 in Figure 2(B)). In other words, unlike the charge process, the record is made on the blockchain before a settlement request is made to the accounting system 3. The reason for the configuration described above, where the withdrawal from the ordinary deposit account is completed in the accounting system 3 and the writing to the blockchain is performed only after notification of this is to prevent a situation where the balance of the digital currency account is displayed as increased on information terminal 4a, but the transfer of funds from the ordinary deposit account to the joint deposit account is actually incomplete. This eliminates the risk of a situation occurring where funds are charged to the digital currency account even though an actual withdrawal from the ordinary deposit account is impossible.
[0045] In contrast, if the fund transfer in the accounting system 3 were executed first in the case of self-cash redemption processing, there is a possibility that the balance of the digital currency account on the information terminal 4a would not change even though the fund transfer in the accounting system 3 is completed between the time the user presses the redemption button on the information terminal 4a, the subtraction calculation based on the record on blockchain 1 is completed, and user 4 confirms the redemption. This carries the risk that user 4 may press the redemption button again to request a fund transfer, thus preventing the desired redemption process from being realized. For this reason, the system is configured to first subtract the balance of the digital currency account to complete the record on blockchain 1 and the display of the latest balance on the information terminal 4a, and then execute the fund transfer in the accounting system 3.
[0046] When the blockchain control unit 13 receives a report that the write result is complete (Figure 4 (7)), the latest balance is displayed on the user's information terminal 4a (Figure 4 (8), step S214 in Figure 2 (B)), and the API linkage unit 12 then issues a settlement request to API 2 (Figure 4 (9), step S215 in Figure 2 (B)). In the self-bank redemption process, the settlement request is an instruction to transfer N yen from the joint deposit account 32 in the name of Bank X to the user's ordinary deposit account 31. In response, API 2 sends a withdrawal request message containing authentication information (ID, date and time of transmission, signature) and transaction information (recipient, amount information) to the accounting system 3. In the case of self-bank redemption, the "recipient" is the user's own ordinary deposit account 31 that made the charge request. Note that the "sender" is always the joint deposit account 32, so it is practically unnecessary to include this information in the withdrawal request message.
[0047] This settlement process is instantaneous; when funds are withdrawn from the joint deposit account 32 in the name of Bank X, they are deposited almost in real time into the ordinary deposit account 31 in the name of the user who requested the withdrawal from the bank. Unlike the bank charge process, the deposit and withdrawal accounts in the accounting system 3 are reversed, but even in the case of the bank withdrawal process, API 2 functions as an instant settlement gateway between the blockchain system 1 and the accounting system 3. At this point, the balance in the ordinary deposit account 31 in the name of the user at Bank X becomes +N yen, and the balance in the joint deposit account 32 in the name of Bank X becomes -N yen. In other words, even in the case of the bank withdrawal process, the balance changes of the ordinary deposit account and the joint deposit account are inversely proportional.
[0048] As soon as the instant settlement process is completed in the accounting system 3, API 2 immediately receives the settlement result and sends it to the blockchain system 1 (step S216 in Figure 4(10), Figure 2(B)). Due to the bank's redemption process, the joint deposit account 32 is reduced by N yen, and the balance of user 4's digital currency account is reduced by N yen. In other words, the increase or decrease in the total deposit of the joint deposit account in the name of Bank X is linked to the currency balance of the user's digital currency account.
[0049] The self-conversion process of the accounting system 3 based on the withdrawal request message described above, although using a joint deposit account as the account, is no different to the bank's accounting system 3 from a transfer to the head office or branch within the same bank, which is routinely carried out as part of the bank's settlement operations. Therefore, no changes to the operation or administrative procedures of accounting system 3 are required for the digital currency conversion process. In addition, although Bank X only manages the total balance as information for the joint deposit account, the settlement processing results are linked to API 2, so the conversion request results can be recorded in the blockchain DB 14. As a result, the balance of the digital currency account decreases as the funds are withdrawn from the digital currency account of the user who made the conversion request, and the total balance of the joint deposit account 32 decreases as an amount equivalent to the amount of digital currency to be withdrawn is withdrawn from the joint deposit account 32. In the case of self-conversion, when looking at the relationship between the joint deposit account and the digital currency account, the balance changes of both are directly proportional. It is possible to convert a digital currency account to a fiat currency account by decreasing the total balance of the joint deposit account and increasing the balance of the requesting user's regular savings account 31 by the same amount.
[0050] The above charge and redemption processes apply when both the ordinary deposit account 31 and the joint deposit account 32 are located within the same X Bank. However, there may be cases where a charge is made from a bank other than X Bank, or where you wish to redeem funds to an account at a bank other than X Bank. Therefore, the processes of charging and redeeming funds at other banks will be explained below. The explanation will primarily focus on the differences between these processes and the in-house charge and redemption processes.
[0051] 3. Other bank charge processing Figure 5 is a conceptual diagram showing the process of charging to other banks, and Figure 6 shows the sequence diagram. Note that in Figure 6, (1) to (5) are the same as in Figures 3 and 4, so they are omitted. User 4 does not have a regular savings account with Bank X, but already has a regular savings account with a specific partner financial institution. The interbank charge process means increasing the funds in the user's digital currency account by transferring funds from the regular savings account at the partner financial institution to a joint deposit account at Bank X.
[0052] The blockchain system 1 in the digital currency management system 100 is basically implemented with the same technical philosophy as the bank's own charge processing, but the instructions created in response to API calls from the API integration unit 12 concern fund transfers between the deposit account of a partner financial institution and the joint deposit account of Bank X, instead of fund transfers between user deposit accounts and joint deposit accounts within Bank X. As shown in Figure 5, when the accounting system 5 of the partner financial institution receives a settlement instruction from API 2 (Figure 6 (6)), it withdraws the instructed amount from the user's ordinary deposit account 31 already opened within the partner financial institution, sets it as a temporary receipt 33, and then transfers it to the accounting system 3 of Bank X. The accounting system 3 of Bank X then transfers the transferred amount as a temporary payment 34 to the joint deposit account 32.
[0053] Figure 6 illustrates the detailed fund movement in a sequence diagram. API2 responds to API calls from API Integration Unit 12 and sends a withdrawal request message containing authentication information (ID, date and time of transmission, signature) and transaction information (sender and amount information) to the partner financial institution's accounting system 5. In the case of an interbank charge process, the "sender" is the user's own savings account 31 that made the charge request. Note that the partner financial institution withdraws the funds from savings account 31 to a savings account at Bank X located within the partner financial institution, so there is no specification of a "recipient". In other words, the affiliated financial institution's accounting system 5 withdraws N yen from the user's ordinary deposit account 31 specified in the settlement command and processes the settlement immediately as a temporary receipt 33. The fact that N yen has been withdrawn from the ordinary deposit account 31 is communicated to API 2 as a settlement processing result (Figure 6 (7)), and through the processing of blockchain system 1, user 4 can check on information terminal 4a whether or not the funds have been charged.
[0054] Note that "temporary receipts" is an account used to temporarily process deposits, and since it is a one-time payment, the affiliated financial institution's accounting system 5 withdraws these temporary receipts (at this point, the temporary receipts in the affiliated financial institution's accounting system 5 become zero) and transfers them to X Bank's accounting system 3. Now, the API call instruction is a charge process, so it needs to be deposited into the joint deposit account 32. For this reason, X Bank's accounting system 3 withdraws N yen as temporary payment 34 and transfers it to the joint deposit account 32. Note that "temporary payment" is an account used to process temporary payments of provisional amounts.
[0055] Financial institutions have traditionally handled temporary receipts and transfers of temporary receipts. In other words, if a user's ordinary deposit account 31 and joint deposit account 32 are not located at the same financial institution, the charge process is carried out via the accounting system 5 of the partner financial institution where the ordinary deposit account 31 is opened. However, the partner financial institution and Bank X only need to perform conventional financial transactions such as instant settlement processing, transfers, and remittances, and the digital currency charge process is ultimately completed.
[0056] Furthermore, it is possible to use another financial institution (for example, a credit central bank) as an additional relay station between the partner financial institution's accounting system 5 and X Bank's accounting system 3. Since there are various connection methods depending on the type of financial institution, even if immediate settlement processing is not possible, it can be processed as borrowed funds and temporary payments as described above.
[0057] Even in the case of interbank charge processing via partner financial institutions, the transfer of funds from ordinary deposit account 31 to joint deposit account 32 is equivalent to charging the digital currency equivalent to those funds into the digital currency account. X Bank's accounting system 3, which holds the joint deposit account 32, only manages the total balance of the joint deposit account based on deposits and withdrawals via transfer. Through the process described above, the amount withdrawn from the partner financial institution's ordinary deposit account 31 is deposited into the joint deposit account 32 within X Bank, increasing its total balance and thereby increasing the currency balance of the user's digital currency account by the same amount, thus enabling a charge process from a fiat currency account to a digital currency account.
[0058] In the case of an interbank charge, although the difference is that the withdrawal destination (i.e., the sender) is a regular savings account within a partner financial institution rather than Bank X, the balance of the user's regular savings account 31 becomes -N yen, and the balance of the joint savings account 32 in the name of Bank X becomes +N yen. Therefore, looking at the relationship between the regular savings account and the joint savings account, the balance changes of the two are inversely proportional, just like in the case of an in-bank charge. Furthermore, the increase in the joint savings account corresponds to the increase in the digital currency account, and looking at the relationship between the joint savings account and the digital currency account, the balance changes of the two are directly proportional.
[0059] 4. Other bank cashing Interbank redemption processing means that funds are transferred from a joint deposit account at Bank X to a regular savings account at a partner financial institution, resulting in a decrease in the funds in the user's digital currency account. This process is implemented using essentially the same technical principles as in-house cash redemption, but as shown in Figure 7, in the case of cash redemption at another bank, a transfer process is performed where N yen is withdrawn from the joint deposit account 32 at Bank X and deposited into the ordinary deposit account 31 at the partner financial institution. The reason a transfer is used instead of instant settlement is that the need for immediacy is lower in the case of cash redemption than in the case of charging. Alternatively, instant settlement may be applied instead of the transfer process.
[0060] The increase or decrease in deposits in a joint deposit account under the name of Bank X is linked to the currency balance in the user's digital currency account. This allows for a conversion process where an amount equivalent to the amount of currency withdrawn from the user's digital currency account is withdrawn from the joint deposit account 32, decreasing the total balance of the joint deposit account 32, and conversely increasing the deposit balance in the user's ordinary deposit account 31 at a partner financial institution by the same amount. In the case of redemption processing at another bank, although the difference is that the recipient (i.e., the remittance destination) is a regular savings account within a partner financial institution rather than Bank X, the balance of the user's regular savings account 31 becomes +N yen, and the balance of the joint savings account 32 in the name of Bank X becomes -N yen. In other words, looking at the relationship between the regular savings account and the joint savings account, the balance changes of the two are inversely proportional, just as in the case of redemption processing at the same bank. Furthermore, since the funds are withdrawn from the digital currency account of the user who made the redemption request, the balance of the digital currency account decreases, and an amount equivalent to the amount of digital currency to be withdrawn is withdrawn from the joint savings account 32 at Bank X, thus decreasing the total balance of the joint savings account 32. Therefore, looking at the relationship between the joint savings account and the digital currency account, the balance changes of the two are directly proportional.
[0061] 5. Charging and redemption of accounts between different accounts. The self-charge processing, self-redemption processing, other-bank charge processing, and other-bank redemption processing described above all involved the user's own savings account and digital currency account. On the other hand, there are cases where charge processing or redemption processing is performed with another person's savings account or digital currency account. For example, one can imagine a case where an employer pays a salary in digital currency. Even in the case where the salary is transferred from the employer's legal tender account to the employee's digital currency account, there is no particular change to the withdrawal request message in the API call (settlement request) that the API integration unit 12 sends to API 2, as seen in the self-charge processing described above, or to the processing of the accounting system. The blockchain system 1 registers the correspondence information of each employee and their salary amount in advance, and in response to a fund charge request from the employer, it sends a withdrawal request message from the employer's savings account to the accounting system. At this time, the amount to be withdrawn is specified as the sum of the salaries of all employees. Once API2 receives the payment processing result and confirms that the funds have been transferred, the blockchain system can then use the aforementioned correspondence information between each employee and their salary to add the digital currency corresponding to their respective salary to each employee's digital currency account.
[0062] Furthermore, it is conceivable that individuals may use digital currency to make purchases at merchants participating in the digital currency service, but this does not fundamentally differ from the in-house redemption process or the redemption process at other banks described above. Figure 8 is a sequence diagram illustrating the payment processing at a participating merchant. The explanation for Blockchain 1 is omitted as it is no different from the charge process or the redemption process.
[0063] A payment request from the API integration unit 12 to API 2 for a certain user 4, (1) Transfer N yen from joint deposit account 32 to the ordinary deposit account of affiliated store A. (2) Transfer M yen from joint deposit account 32 to the ordinary deposit account of affiliated store B. Assume that each of these is a command to transfer funds. Assume that merchant A's savings account is at Bank X, and merchant B's savings account is at a partner financial institution.
[0064] When X Bank's core banking system 3 receives a withdrawal request message from API 2, it should withdraw (N+M) yen from the joint deposit account 32, transfer N yen to merchant A's savings account, and deposit M yen into merchant B's savings account within the partner financial institution. Therefore, the merchant's settlement process can be achieved through either in-house or interbank liquidation.
[0065] The advantages of the present invention are summarized below. In previous blockchain systems for managing digital currency accounts, processing the charging and exchange of digital currency between each user's fiat currency account at a bank was cumbersome. One reason for this is that the All-Japan Bankers Association Data Communication System (commonly known as the All-Japan Bankers Association System) must transmit data using a standard communication protocol called the All-Japan Bankers Association File Format in order to reliably send and receive notifications regarding domestic exchange transactions between banks participating in the All-Japan Bankers Association Domestic Exchange System, and to calculate and settle the amount of interbank exchange settlements resulting from such transactions. The All-Japan Bankers Association File Format includes numerous items, and the number of digits and setting values that must be specified for each item are predetermined. If, for the purpose of transactions using digital currency, domestic exchange transactions such as transfers are to be conducted directly between a user's ordinary deposit account and that user's digital currency account, it will be necessary to manage a large amount of daily settlement data in accordance with the All-Japan Bankers Association File Format, just as with fiat currency.
[0066] According to the digital currency management system 100 of the present invention, within the bank's accounting system, fund transfers between multiple fiat currency accounts are managed collectively in a single joint deposit account, and the blockchain system links only the fund transfer records of this joint deposit account to increases and decreases in the balance of the digital currency account. As a result, the information received from the bank's accounting system is limited, and compared to the Zengin File format, the linkage with the bank's accounting system can be simplified.
[0067] For the bank's core banking system, this only requires transferring funds between each user's savings account and the joint deposit account, so it does not require any changes to the normal operation and procedures of the core banking system. Therefore, it is an optimal means of easily realizing digital currency services based on integration with blockchain systems. Moreover, since the joint deposit account is in the name of the bank, if a savings account is opened within that bank, it becomes an internal fund transfer, simplifying data processing in the core banking system. On the other hand, a joint deposit account, which aggregates funds from multiple users, only manages the total balance. In other words, the detailed transaction history of the cryptocurrency is recorded only on the blockchain and is not managed as joint deposit account information in the bank's core banking system. If a joint deposit account only has information on the total balance and is merely a collective account like a savings account in the name of the bank, the total balance becomes a deposit in the name of the bank. Therefore, by treating the ordinary savings account, although in the bank's name, as a "joint deposit account," it becomes possible to externally determine that the collective account in the bank's name is a deposit contributed by multiple users, and by linking it with the blockchain system, it can be treated as an aggregate of each user's share.
[0068] Most digital currency services proposed to date have a system configuration in which either a bank's accounting system or a blockchain system is integrated into the other. This invention, however, is based on the concept of keeping the two systems independent while loosely linking them, rather than integrating them. As a result, blockchain systems can be easily linked simply by each financial institution holding a joint deposit account, thereby promoting the widespread adoption of digital currency services.
[0069] Furthermore, since the present invention enables settlement processing, including charging and redemption, through fund transfers between a legal tender account (ordinary deposit account) and a joint deposit account, and between a joint deposit account and a digital currency account, from the perspective of realizing settlement processing, it is not necessary to link the legal tender account and the digital currency account to each other. However, for example, if the digital currency account holder dies or transactions are suspended, an obligation arises to refund the digital currency balance of that account holder. In this case, if the digital currency balance can be redeemed and transferred to a legal tender account, there is an advantage in that the refund process can be carried out smoothly. Therefore, in this embodiment, the blockchain system is configured to record legal tender account information corresponding to each user's digital currency account.
[0070] The digital currency management system of the present invention is realized by processes, means, and functions executed by a computer in accordance with instructions from a program (software) launched on the system. The program can send commands to each component of the computer, causing it to execute predetermined processes, functions, etc., according to the present invention as described above. In other words, each process, means, and function in the present invention is realized by specific means in which the program and the computer work together. All or part of the program is provided, for example, on a magnetic disk, optical disk, semiconductor memory, or any other computer-readable recording medium, and the program read from the recording medium is installed on the computer and executed. Alternatively, the program can be loaded directly onto the computer via a communication line without using a recording medium and executed. Furthermore, the digital currency management system of the present invention can be configured on a single information processing device (for example, one personal computer) or on multiple information processing devices (for example, a group of multiple server computers). Note that the above embodiments are examples to illustrate the present invention in an easy-to-understand manner.
[0071] Furthermore, terminals that connect to the digital currency management system via a network are computers connected to a network such as the internet or a dedicated line. Specifically, examples include PCs (Personal Computers), mobile phones and smartphones, PDAs (Personal Digital Assistants), tablets, and wearable devices. By configuring terminals connected to the network via wired or wireless connections to communicate with each other, a business scheme including the digital currency management system is formed. In the embodiment described above, the digital currency management system is a system that works in conjunction with an ASP, but it does not necessarily have to be configured to work in conjunction with an ASP; the functions of the ASP may be implemented by a blockchain system. [Explanation of Symbols]
[0072] 1 Blockchain System 2 API (Application Programming Interface) 3. Bank accounting systems 4a Information terminal 5. Accounting systems of partner financial institutions 11. User Registration Section 12 API Integration Section 13 Blockchain Control Unit 14 Blockchain DB 31. Savings account 32 Joint deposit accounts 100 Digital Currency Management Systems
Claims
1. A digital currency management system that conducts transactions of digital currencies backed by legal tender, Provided that a joint deposit account is opened at a financial institution where the deposits of unrelated users are combined, if a request is made to transfer funds between a legal tender deposit account managed by the said financial institution and a digital currency account managed outside the said financial institution, the system will control the transfer of funds to occur between the legal tender deposit account and the joint deposit account. A digital currency management system in which the amount of increase or decrease in funds for each request in the joint deposit account corresponds to the amount of increase or decrease in funds in one or more digital currency accounts relating to that request.
2. The digital currency management system according to claim 1, wherein if the request is a request to charge the digital currency account, it transmits a request to the financial institution for the transfer of funds from the designated user's fiat currency account to the joint deposit account.
3. The digital currency management system according to claim 1, wherein if the request is a request to convert to legal tender, it transmits a request to the financial institution to transfer funds from the joint deposit account to the legal tender account of the designated user in the request.
4. The digital currency management system according to claim 1, wherein, regardless of whether the request is a request to charge the digital currency account or a request to exchange it for legal tender, the change in the balance of the designated user's legal tender account in the request is inversely proportional to the change in the balance of the joint deposit account.
5. The digital currency management system according to claim 1, wherein, regardless of whether the request is a request to charge the digital currency account or a request to exchange it for legal tender, the change in the balance of the joint deposit account is directly proportional to the change in the balance of the digital currency account of the designated user in the request.
6. The digital currency management system according to claim 1, wherein the accounting system of the financial institution manages the deposit shares of each user related to the joint deposit account, and funds are transferred between the legal tender deposit account and the joint deposit account.
7. The digital currency management system according to any one of claims 1 to 6, wherein the legal tender deposit account includes an account opened at a partner financial institution related to the financial institution.