Information processing device, information processing method, and program

Abstract

To accelerate remittance processing between accounts.SOLUTION: One remittance transaction is executed in a manner divided into a withdrawal transaction and a deposit transaction. That is, as illustrated in Fig. 5, the withdrawal transaction is first executed by way of a message queuing system. It is confirmed that a balance of an account A is more than or equal to X yen, and if the balance of the account A is more than or equal to X yen, processing of withdrawing X yen from the account A is performed. Then, the deposit transaction to be performed next is executed by way of the message queuing system to deposit X yen withdrawn by the withdrawal transaction in an account B. By executing the withdrawal transaction and the deposit transaction separately in this manner, the overall processing time of many transactions can be accelerated as compared with conventional cases in which exclusion control in each transaction is performed simultaneously across two accounts.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to a technique for transferring money between accounts. [Background technology]

[0002] Financial institutions and other organizations are conducting research and demonstration experiments into digital currencies.

[0003] As a technology that contributes to speeding up remittance processing between accounts, for example, Patent Document 1 proposes a mechanism that allows update processing and search processing to be performed independently and in parallel. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 4175998 Summary of the Invention [Problem to be solved by the invention]

[0005] In systems that use relational databases, which are often used in bank accounting systems, the longer it takes to search for accounts whose balances need to be updated as the number of records in the table that manages each account's balance increases.Furthermore, if a table is split into multiple tables to reduce the number of records stored in one, and the accounts whose balances need to be updated are split across two tables, the update process described above takes even longer.

[0006] The present invention has been made in view of the above problems, and its object is to realize high-speed remittance processing between accounts. [Means for solving the problem]

[0007] In order to solve the above problem, the present invention provides a system including: an acquisition unit that acquires a remittance request to withdraw money from a first account and deposit money into a second account; a withdrawal processing unit that executes a withdrawal transaction to realize the withdrawal in the acquired remittance request and updates a database containing the balance of the first account; and a deposit processing unit that executes a deposit transaction different from the withdrawal transaction to realize the deposit in the remittance request after the withdrawal processing by the withdrawal processing unit, and updates the database containing the balance of the second account. The system comprises a message queue storage unit that writes and reads transactions on a first-in, first-out basis, and a storage unit that stores a transaction management database including information on the withdrawal transaction or the deposit transaction, wherein the acquisition unit writes the withdrawal transaction to the message queue storage unit, the withdrawal processing unit reads and executes the withdrawal transaction written in the message queue storage unit, and then writes the deposit transaction to the message queue storage unit, and the deposit processing unit reads and executes the deposit transaction written in the message queue storage unit, the transaction management database includes a transaction identifier assigned to the remittance request, each of the transaction identifiers is written in the message queue storage unit, and a re-execution unit that performs processing to re-execute the withdrawal transaction or deposit transaction corresponding to the remittance request if the transaction identifier written in the message queue storage unit is not included in the transaction management database. The present invention provides an information processing device characterized by the above.

[0012] The present invention also provides An information processing method performed by an information processing device communicably connected to a storage unit that stores a transaction management database including a transaction identifier assigned to a remittance request for withdrawing money from a first account and depositing it into a second account, the method comprising: an acquisition step of acquiring a remittance request; a withdrawal processing step of executing a withdrawal transaction to realize a withdrawal in the acquired remittance request and updating a database containing the balance of the first account; and a deposit processing step of executing a deposit transaction, which is a transaction to realize a deposit in the remittance request and is different from the withdrawal transaction, after the withdrawal processing step has been performed, and updating a database containing the balance of the second account. a re-execution step in which, in the acquisition step, the withdrawal transaction is written to a message queue storage unit which writes and reads transactions on a first-in, first-out basis; in the withdrawal processing step, the withdrawal transaction written in the message queue storage unit is read and executed, and then the deposit transaction is written to the message queue storage unit; in the deposit processing step, the deposit transaction written in the message queue storage unit is read and executed, each of the transaction identifiers being written in the message queue storage unit; and in the case where the transaction identifier written in the message queue storage unit is not included in a transaction management database containing information about the withdrawal transaction or the deposit transaction, a re-execution step in which processing is performed to re-execute the withdrawal transaction or the deposit transaction corresponding to the remittance request. The present invention provides an information processing method comprising the steps of:

[0013] The present invention also provides a communication unit connected to a storage unit that stores a transaction management database including transaction identifiers assigned to remittance requests to withdraw funds from a first account and deposit funds into a second account; On the computer, The aforementioned an acquisition step of acquiring a remittance request; a withdrawal processing step of executing a withdrawal transaction to realize a withdrawal in the acquired remittance request and updating a database containing the balance of the first account; and a deposit processing step of executing a deposit transaction, which is a transaction to realize a deposit in the remittance request and is different from the withdrawal transaction, after the withdrawal processing step has been performed, and updating a database containing the balance of the second account. In the acquisition step, the withdrawal transaction is written to a message queue storage unit that writes and reads transactions on a first-in, first-out basis; in the withdrawal processing step, the withdrawal transaction written in the message queue storage unit is read and executed, and then the deposit transaction is written to the message queue storage unit; in the deposit processing step, the deposit transaction written in the message queue storage unit is read and executed, and each transaction identifier is written in the message queue storage unit, and the transaction identifier written in the message queue storage unit is used for the withdrawal transaction or the deposit transaction. a re-execution step of performing a process for re-executing the withdrawal transaction or the deposit transaction corresponding to the remittance request when the withdrawal transaction or the deposit transaction corresponding to the remittance request is not included in a transaction management database containing information about the transaction; A program for executing the above is provided. [Effects of the Invention]

[0014] According to the present invention, it is possible to speed up the remittance process between accounts. [Brief explanation of the drawings]

[0015] [Figure 1] 1 is a block diagram showing the overall configuration of a system according to an embodiment of the present invention. [Figure 2] FIG. 2 is a block diagram showing a hardware configuration of an issuer server device according to the present embodiment. [Figure 3] FIG. 1 is a diagram illustrating a conventional remittance transaction processing procedure. [Figure 4] FIG. 1 is a diagram illustrating a conventional remittance transaction processing procedure. [Figure 5] FIG. 2 is a diagram illustrating a processing procedure of a remittance transaction in this embodiment. [Figure 6] FIG. 2 is a block diagram showing a functional configuration of an issuer server device according to the present embodiment. [Figure 7] 10 is a diagram illustrating an example of the data structure of a ledger database stored in an issuer server device according to the present embodiment. FIG. [Figure 8] 10 is a diagram illustrating an example of the data structure of a transaction management database stored in an issuer server device according to the present embodiment. FIG. [Figure 9] 3 is a diagram illustrating an example of the definition of a workflow ID, a function ID, and a step ID in this embodiment. FIG. [Figure 10] 10 is a diagram illustrating an example of the data structure of a transaction generated by an issuer server device according to the present embodiment. FIG. [Figure 11] 10 is a flowchart showing the operation of the issuer server device according to the present embodiment. [Figure 12] 10 is a flowchart showing the operation of the issuer server device according to the present embodiment. [Figure 13] 10 is a flowchart showing the operation of the issuer server device according to the present embodiment. [Figure 14]10 is a flowchart showing the operation of the issuer server device according to the present embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0016] [composition] An embodiment of the present invention will be described in detail below with reference to the drawings. In this embodiment, an example is shown in which the present invention is applied to digital currency issued by an issuer such as a financial institution. FIG. 1 is a block diagram showing the overall configuration of a system according to an embodiment of the present invention. This system includes a user terminal 10 used by a user, multiple intermediary institution server devices 20 used by intermediary institutions such as payment service providers, and an issuer server device 30 used by an issuer. The user terminal 10 and the intermediary institution server device 20, and the intermediary institution server device 20 and the issuer server device 30 are connected to each other via a predetermined communication network so that they can communicate with each other. The issuer server device 30 functions as an information processing device according to the present invention. In this embodiment, the issuer server device 30 uses an account-based ledger recording method.

[0017] 2 is a diagram showing the hardware configuration of issuer server device 30. Issuer server device 30 is physically configured as a computer including processor 3001, memory 3002, storage 3003, communication device 3004, input device 3005, output device 3006, and a bus connecting these. Each of these devices operates on power supplied from a battery (not shown). The hardware configuration of issuer server device 30 may be configured to include one or more of the devices shown in FIG. 2, or may be configured without including some of the devices. Furthermore, issuer server device 30 may be configured by connecting multiple devices in different housings via a communication line.

[0018] Each function in the issuer server device 30 is realized by loading specified software (programs) onto hardware such as a processor 3001 and a memory 3002, causing the processor 3001 to perform calculations, control communication via the communication device 3004, and control at least one of reading and writing data in the memory 3002 and the storage 3003.

[0019] The processor 3001 controls the entire computer by running, for example, an operating system. The processor 3001 may be configured as a central processing unit (CPU) including an interface with peripheral devices, a control unit, an arithmetic unit, a register, etc. The processor 3001 may also be configured to include hardware such as a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a field programmable gate array (FPGA).

[0020] The processor 3001 reads programs (program codes), software modules, data, etc. from at least one of the storage 3003 and the communication device 3004 into the memory 3002, and executes various processes in accordance with these. The program used is a program that causes a computer to execute at least some of the operations described below. The functional blocks of the issuer server device 30 may be implemented by a control program stored in the memory 3002 and running on the processor 3001. The various processes may be executed by one processor 3001, or may be executed simultaneously or sequentially by two or more processors 3001. The processor 3001 may be implemented by one or more chips. The program may be transmitted to the issuer server device 30 via a communication line.

[0021] The memory 3002 is a computer-readable recording medium and may be configured by, for example, at least one of a ROM (Read Only Memory), an EPROM (Erasable Programmable ROM), an EEPROM (Electrically Erasable Programmable ROM), a RAM (Random Access Memory), etc. The memory 3002 may also be called a register, a cache, a main memory (primary storage device), etc. The memory 3002 can store an executable program (program code), a software module, etc. for implementing the method according to this embodiment.

[0022] Storage 3003 is a computer-readable recording medium, and may be configured by at least one of, for example, an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (e.g., a compact disk, a digital versatile disk, a Blu-ray (registered trademark) disk), a smart card, a flash memory (e.g., a card, a stick, a key drive), etc. Storage 3003 may also be called an auxiliary storage device.

[0023] The communication device 3004 is hardware for communicating between computers via a communication network, and is also called, for example, a network device, a network controller, a network card, or a communication module.

[0024] The input device 3005 is an input device (for example, a key, a microphone, a switch, a button, a camera, a sensor, a two-dimensional code reader, etc.) that receives input from the outside. The output device 3006 is an output device (for example, a display, a speaker, an LED lamp, etc.) that outputs to the outside. The input device 3005 and the output device 3006 may be integrated into one device (for example, a touch panel).

[0025] Each device, such as the processor 3001 and the memory 3002, is connected by a bus for communicating information. The bus may be configured using a single bus, or may be configured using different buses between each device.

[0026] It should be noted that the user terminal 10 and the intermediary server device 20 are computers having the same configuration as the issuer server device 30, and therefore detailed explanations thereof will be omitted.

[0027] Here, the characteristic features of this embodiment will be described. First, with reference to Figures 3 and 4, the conventional remittance processing procedure for withdrawing X yen from the payer's account A and depositing the X yen into account B will be described. Conventionally, as shown in Figure 3, first it is confirmed that the balance of account A is X yen or more, and if the balance of account A is X yen or more, X yen is withdrawn from account A and the withdrawn X yen is deposited into account B. These three processing procedures are executed as one transaction (hereinafter referred to as a remittance transaction).

[0028] A transaction here refers to a unit of an indivisible series of processes executed in a computer system. Therefore, in the example of Figure 3, the entire remittance process is managed as a single transaction. In other words, a remittance transaction is considered complete when all processes included in the transaction are successful, but if any process included in the transaction fails, the transaction is considered to have failed and the remaining processes are canceled.

[0029] Furthermore, to reduce the number of records in a database containing the balances of each account, the database may be split into multiple databases. Even in such a case, as shown in the example in Figure 4, the database containing the balance of Account A confirms that the balance of Account A is at least X yen, and if the balance of Account A is at least X yen, X yen is withdrawn from Account A. Then, in the database containing the balance of Account B, the withdrawn X yen is deposited into Account B. Since these three processing steps are executed as a single remittance transaction, in this case too, the remittance transaction is considered to be completed when all steps included in the transaction are successful, but is considered to have failed if any step included in the transaction fails.

[0030] As described above, when making a withdrawal and a deposit in one remittance transaction, it is necessary to lock both the records corresponding to the withdrawal source account (the above-mentioned account A) and the deposit destination account (the above-mentioned account B) in the database containing the account balances in order to perform exclusive control on these records. Conventionally, such exclusive control is performed simultaneously across two accounts for each remittance transaction, so if a large number of remittance transactions are concentrated in a short period of time, the time required to complete these remittance transactions increases.

[0031] Therefore, in this embodiment, one remittance transaction is divided into two separate transactions: a withdrawal transaction and a deposit transaction. That is, as illustrated in FIG. 5 , the withdrawal transaction is first executed to confirm that Account A's balance is at least X yen. If Account A's balance is at least X yen, X yen is withdrawn from Account A. The next deposit transaction is then executed, and the withdrawn X yen is deposited into Account B. By dividing the transactions into withdrawal and deposit transactions in this way, the time required to complete multiple remittance transactions is shorter, i.e., multiple remittances can be processed more quickly, compared to conventional methods in which exclusive control for each remittance transaction is performed across two accounts simultaneously. Note that while FIG. 5 illustrates an example in which a single database contains the balances of Account A and Account B, the database configuration is not limited to this, and the database containing the balance of Account A and the database containing the balance of Account B may be different databases.

[0032] Furthermore, in this embodiment, NoSQL (Not only SQL), which has faster write and read speeds than relational databases, is used as the database containing the balances of each account. Since NoSQL does not implement the exclusive control of records described above, it is possible to speed up processing compared to when exclusive control of records is implemented. However, without exclusive control of records, problems may occur when updating data in the database, such as when a withdrawal transaction is confirmed to have sufficient balance to withdraw from an account, but before that withdrawal can be made, another withdrawal transaction executes a withdrawal, resulting in an insufficient balance.

[0033] Therefore, in this embodiment, a so-called message queuing system is used to perform data update processing for two accounts: a withdrawal process for the withdrawal source account (the above-mentioned account A) and a deposit process for the deposit destination account (the above-mentioned account B). Specifically, as illustrated in Figure 5, first, a withdrawal transaction is written to the message queuing system, which reads it and executes it, and then a deposit transaction is written to the message queuing system, which reads it and executes it. Because the message queuing system is a mechanism for writing and reading messages (here, transactions) on a first-in, first-out basis, even if withdrawal transactions and deposit transactions related to multiple remittance transactions are mixed, it is guaranteed that these transactions will be executed sequentially. This reduces the possibility of the above-mentioned problems occurring.

[0034] Fig. 6 is a diagram showing an example of the functional configuration of issuer server device 30. The functions illustrated in Fig. 6 are realized by loading predetermined software (programs) onto hardware such as processor 3001, memory 3002, etc., causing processor 3001 to perform calculations, control communication by communication device 3004, and control at least one of reading and writing of data from memory 3002 and storage 3003.

[0035] 6, acquisition unit 31 acquires various information from outside issuer server device 30 via a communication network. For example, acquisition unit 31 acquires a remittance request from intermediary agency server device 20, requesting that a remittance amount of X yen be withdrawn from a withdrawal source account (first account in the present invention) and deposited into a deposit destination account (second account in the present invention). This remittance request is generated by intermediary agency server device 20 in response to an instruction from user terminal 10, for example, and includes information specifying at least the withdrawal source account, the deposit destination account, and the remittance amount.

[0036] The storage unit 32 stores a ledger database (hereinafter, database will be referred to as DB) 321 and a transaction management DB 322. Note that each DB does not necessarily need to include any of the information groups exemplified below.

[0037] Ledger DB321 is a database containing information about each user's account. As shown in FIG. 7, ledger DB321 includes the account name (#1), account balance (#2), sequence number (#3), last transaction ID (#4), and transaction ID list (#5) for each account. The sequence number is incremented each time a transaction is executed for this account, and indicates the order of the transaction specified by the user, as well as the total number of transactions specified by this user in the past. In the withdrawal process described above, the sequence number in the withdrawal transaction is compared with the sequence number in ledger DB321, and if they do not match, a processing sequence error occurs.

[0038] In the ledger DB 321, the last transaction ID is a transaction ID (transaction identifier) ​​that identifies the last transaction that triggered an update of any data described in this record. The transaction ID list consists of a qualifier and a cell, where the qualifier is the last transaction ID mentioned above, and the cell is the last transaction ID of the transaction immediately preceding in time.

[0039] Because the transaction ID list is structured in this way, it is possible to see the history of transactions that have been executed in the past. Specifically, the qualifier in the first element of the transaction ID list corresponds to the last transaction ID (the same value as the last transaction ID in the ledger DB), Cell corresponds to the transaction ID immediately before in time, the qualifier in the next element corresponds to the transaction ID immediately before in time, and Cell corresponds to the transaction ID immediately before that (i.e., two transactions before that). This chain of transaction IDs continues, and the qualifier in the last element corresponds to the last transaction ID, and Cell is the terminal symbol (0).

[0040] During the withdrawal and deposit processes described above, the first element in this transaction ID list is updated with the last transaction ID in ledger DB 321. During the withdrawal or deposit process, if the transaction ID list contains the transaction ID of the transaction to be processed (withdrawal transaction or deposit transaction), that process is skipped, thereby preventing duplicate withdrawals or duplicate deposits.

[0041] The transaction management DB 322 is a database that contains information about each transaction (withdrawal transaction and deposit transaction). As shown in FIG. 8, the transaction management DB 322 contains the record creation date and time (#1), transaction ID (#2), workflow ID (#3), function ID (#4), step ID (#5), and transaction content (#6) for each transaction. The workflow ID, function ID, and step ID are defined as shown in FIG. 9. The transaction content is referenced when re-executing a transaction, as described below.

[0042] When the deposit process described above is completed successfully, or when an error occurs during the withdrawal process (e.g., the aforementioned mismatch in sequence numbers or insufficient balance in the withdrawal source account), the above information is written to this transaction management DB 322. For example, when the deposit process is completed successfully, the following information is written: the date and time when the deposit transaction was successful as the "record creation date and time," a string obtained by hashing the content of the remittance request as the transaction ID, "WF001" corresponding to "remittance" as the workflow ID (see FIG. 9), "FN002" corresponding to "deposit" as the function ID (see FIG. 9), "ST02" corresponding to "end" as the step ID (see FIG. 9), and the content of the remittance request as the transaction content. Furthermore, when an error occurs during the withdrawal process (e.g., the aforementioned mismatch in sequence numbers or insufficient balance in the withdrawal source account), the date and time when the error occurred as the "record creation date and time," a string obtained by hashing the content of the remittance request as the transaction ID, and the content of the remittance request as the transaction content. Furthermore, the workflow ID, function ID, and step ID are written with the content corresponding to the process being executed when the error occurred (see FIG. 9). In this way, the transaction management DB 322 records information about transactions that have ended normally and information about transactions that have not ended normally.

[0043] In this way, the combination of workflow ID and function ID defines the withdrawal transaction and deposit transaction included in one remittance transaction. For example, in a remittance transaction in which X yen is withdrawn from source account A and deposited into destination account B, the withdrawal transaction is defined by the combination of workflow ID "WF001" and function ID "FN001" as shown in Figure 9, and the deposit transaction is defined by the combination of workflow ID "WF001" and function ID "FN002". Therefore, transaction management DB322 contains information related to withdrawal transactions and deposit transactions.

[0044] The message queue storage unit 33 is a means for implementing a message queuing system, and writes and reads messages (here, transactions) on a first-in, first-out basis. Figure 10 illustrates the data structure of transactions (withdrawal transactions and deposit transactions) corresponding to messages in the message queue storage unit 33. A transaction includes a workflow ID (#1), a function ID (#2), a message sender (#3), a message lifetime (#4), a transaction ID (#5), and the contents of the message body (#6). In this transaction, the withdrawal transaction is defined by the combination of workflow ID "WF001" and function ID "FN001," and the deposit transaction is defined by the combination of workflow ID "WF001" and function ID "FN002." In other words, the withdrawal transaction and the deposit transaction are identified by the combination of the workflow ID and function ID included in the transaction. Note that the number of message queue storage units 33 is not limited to one; multiple units may be present.

[0045] When the acquisition unit 31 acquires a new remittance request from the intermediary server device 20, it hashes the content of the remittance request (the character string included in the remittance request) and writes the hashed character string as a transaction ID to the message queue storage unit 33. In other words, transaction IDs have a one-to-one correspondence with remittance requests. The same transaction ID is used for withdrawal transactions and deposit transactions. By using the same transaction ID for withdrawal transactions and deposit transactions in this way, it becomes possible to distinguish between withdrawal transactions and deposit transactions that correspond to the same remittance request.

[0046] The withdrawal processing unit 34 executes a withdrawal transaction to realize the withdrawal in response to the remittance request, and updates the balance of the withdrawal source account in the ledger DB 321. The withdrawal processing unit 34 reads and executes the withdrawal transaction written in the message queue storage unit 33, and then generates a deposit transaction and writes it to the message queue storage unit 33.

[0047] After the withdrawal processing is performed by the withdrawal processing unit 34, the deposit processing unit 35 reads and executes the deposit transaction to realize the deposit in the remittance request from the message queue storage unit 33, and updates the balance of the deposit destination account in the ledger DB321.

[0048] The output unit 36 ​​outputs various information to the outside of the issuer server device 30. For example, the output unit 36 ​​outputs the execution result of the process for the remittance request.

[0049] The re-execution unit 37 checks whether there are any inconsistencies in the execution results of a withdrawal transaction or a deposit transaction in case the process terminates abnormally while these transactions are being executed, and if there is an inconsistency, executes a remittance recovery transaction (see Figure 9) to perform processing to re-execute the transaction that is the subject of the inconsistency (the withdrawal transaction and the deposit transaction corresponding to the remittance request).

[0050] [Operation] Next, the operation of this embodiment will be described. First, with reference to Figure 11, the process from when the issuer server device 30 acquires a remittance request until it writes a withdrawal transaction to the message queue storage unit 33 will be described. In Figure 11, the acquisition unit 31 acquires a remittance request from the intermediary server device 20 (step S11).

[0051] In response to this remittance request, the acquisition unit 31 generates a withdrawal transaction and writes it to the message queue storage unit 33 (step S12). The withdrawal transaction written at this time has "WF001" (remittance) written as the workflow ID in Figure 10, "FN001" (withdrawal) written as the function ID, and a string of characters that is a hash of the remittance request content written as the transaction ID.

[0052] The above process is executed each time a remittance request is acquired by the issuer server device 30. As a result, withdrawal transactions corresponding to each remittance request are written sequentially to the message queue storage unit 33.

[0053] Next, referring to Figure 12, a description will be given of the process in which the issuer server device 30 reads a withdrawal transaction from the message queue storage unit 33, executes it, and writes a deposit transaction to the message queue storage unit 33. In Figure 12, the withdrawal processing unit 34 reads the withdrawal transaction from the message queue storage unit 33 in accordance with the first-in, first-out method (step S21).

[0054] The withdrawal processing unit 34 executes the read withdrawal transaction (step S22), thereby updating the ledger DB 321. At this time, the withdrawal processing unit 34 compares the sequence number in the withdrawal transaction with the sequence number in the ledger DB 321, and if they do not match, writes the required information into the transaction management DB 322 as a sequence error, and terminates the process.

[0055] When the withdrawal transaction is completed, the withdrawal processing unit 34 generates a deposit transaction corresponding to the remittance request and writes it to the message queue storage unit 33 (step S23). The deposit transaction written at this time has "WF001" (remittance) written as the workflow ID in Figure 10, "FN002" (deposit) written as the function ID, and the same transaction ID as the deposit transaction described above, i.e., a string of characters that is a hash of the contents of the remittance request, written. The above-mentioned processing is performed each time a withdrawal transaction is read from the message queue storage unit 33.

[0056] Next, the process from when the issuer server device 30 reads a deposit transaction from the message queue storage unit 33 to when it executes the transaction will be described with reference to Fig. 13. In Fig. 13, the deposit processing unit 35 reads a deposit transaction from the message queue storage unit 33 in accordance with the first-in, first-out method (step S31).

[0057] The deposit processing unit 35 executes the read deposit transaction (step S32). This updates the ledger DB 321. The above-mentioned process is performed each time a deposit transaction is read from the message queue storage unit 33. If the deposit transaction is successful, the deposit processing unit 35 updates the transaction management DB 322, as shown in Figure 8. Specifically, the deposit processing unit 35 writes the date and time when the deposit transaction was successful as the "record creation date and time" in Figure 8, a string obtained by hashing the contents of the remittance request mentioned above as the transaction ID, "WF001" corresponding to "remittance" (see Figure 9) as the workflow ID, "FN002" corresponding to "deposit" (see Figure 9) as the function ID, "ST02" corresponding to "end" (see Figure 9) as the step ID, and the contents of the remittance request as the transaction content.

[0058] As described above, withdrawal transactions and deposit transactions corresponding to each remittance request are written to the message queue storage unit 33. However, since the writing and reading of each transaction is managed on a first-in, first-out basis, withdrawal and deposit processes corresponding to multiple remittance requests are executed sequentially.

[0059] Next, the process of re-executing a withdrawal transaction or a deposit transaction when there is an inconsistency in the execution results of the transaction performed by the issuer server device 30 will be described with reference to Figure 14. In Figure 14, the re-execution unit 37 reads out the transaction ID of one of all transactions (withdrawal transactions and deposit transactions) stored in the message queue storage unit 33, for example, periodically or at any timing (step S41).

[0060] The re-execution unit 37 searches the transaction management DB 322 using the read transaction ID as a key (step S42).

[0061] The transaction management DB 322 should record transaction IDs that correspond one-to-one to all remittance requests acquired by the acquisition unit 31. If the transaction management DB 322 contains the corresponding transaction ID (step S43; YES), the re-execution unit 37 returns to step S41, reads the next transaction ID from the message queue storage unit 33, and repeats the above-mentioned process.

[0062] On the other hand, if the transaction management DB 322 does not contain the corresponding transaction ID (step S43; NO), the re-execution unit 37 re-executes the withdrawal transaction in response to the remittance request corresponding to this transaction ID. Specifically, the re-execution unit 37 writes the withdrawal transaction in response to the remittance request corresponding to the transaction ID into the message queue storage unit 33 (step S44), and then transitions to the processing of step S21 in Fig. 12. From this point on, the respective processing operations described with reference to Figs. 12 and 13 are re-executed.

[0063] At this time, if the transaction ID of the withdrawal transaction is included in the transaction ID list of the withdrawal source account in ledger DB 321, the withdrawal processing unit 34 determines that the withdrawal transaction has been executed, and creates a deposit transaction and writes it to the message queue storage unit 33 without updating the account balance of the account (step S23 in Figure 12). On the other hand, if the transaction ID of the withdrawal transaction is not included in the transaction ID list of the withdrawal source account in ledger DB 321, the withdrawal processing unit 34 determines that the withdrawal transaction has not been executed, and executes it. Similarly, if the transaction ID of the deposit transaction is included in the transaction ID list of the deposit destination account in ledger DB 321, the deposit processing unit 35 determines that the deposit transaction has been executed, and terminates the deposit transaction without updating the account balance of the account. On the other hand, if the transaction ID of the deposit transaction is not included in the transaction ID list of the deposit destination account in ledger DB 321, the deposit processing unit 35 determines that the deposit transaction has not been executed, and executes it.

[0064] In this manner, the re-execution unit 37 determines whether or not to re-execute the transaction IDs of all transactions stored in the message queue storage unit 33 .

[0065] According to the embodiment described above, one remittance transaction is essentially divided into two different transactions, a withdrawal transaction and a deposit transaction, and therefore the time required to complete multiple remittance transactions can be shortened compared to the conventional method in which exclusive control for each remittance transaction was performed simultaneously across two accounts. In other words, it is possible to speed up the processing of multiple remittances.

[0066] In addition, in the above embodiment, NoSQL, which has a faster write speed than a relational database, is used as the database containing the balances of each account, and a message queuing system is used to perform data update processing for two accounts sequentially, namely, a withdrawal process for the withdrawal source account and a deposit process for the deposit destination account, thereby making it possible to execute remittance processing quickly and reliably.

[0067] Furthermore, in the above embodiment, if there is an inconsistency in the execution results of a withdrawal transaction or a deposit transaction, the inconsistent transaction is executed again, thereby ensuring that the remittance process is executed reliably.

[0068] [Variations] The present invention is not limited to the above-described embodiment, and the above-described embodiment may be modified as follows: In the above embodiment, an example in which the present invention is applied to digital currency has been described, but the application of the present invention is not limited to this, and it may be applied to cases in which money is transferred between accounts in response to multiple remittance requests.

[0069] The present invention can be implemented not only as an information processing device, such as the issuer server device exemplified in the embodiment, but also as an information processing method performed by this information processing device, i.e., an information processing method including: an acquisition step of acquiring a remittance request to withdraw from a first account and deposit into a second account; a withdrawal processing step of executing a withdrawal transaction to realize the withdrawal in the acquired remittance request and updating a database containing the balance of the first account; and a deposit processing step of executing a deposit transaction, which is a transaction to realize the deposit in the remittance request and is different from the withdrawal transaction, after the withdrawal processing step has been completed, and updating the database containing the balance of the second account. Furthermore, the present invention can also be implemented in the form of a program for causing a computer to execute this information processing method. This program may be provided to the computer in the form of a recording medium such as an optical disc, or via a network such as the Internet. [Explanation of symbols]

[0070] 10: User terminal, 20: Intermediary server device, 30: Issuer server device, 31: Acquisition unit, 32: Memory unit, 33: Message queue storage unit, 34: Withdrawal processing unit, 35: Deposit processing unit, 36: Output unit, 37: Re-execution unit, 3001: Processor, 3002: Memory, 3003: Storage, 3004: Communication device, 3005: Input device, 3006: Output device.

Claims

1. an acquisition unit that acquires a remittance request to withdraw money from a first account and deposit money into a second account; a withdrawal processing unit that executes a withdrawal transaction to realize the withdrawal in the acquired remittance request and updates a database including the balance of the first account; a deposit processing unit that executes a deposit transaction different from the withdrawal transaction to realize the deposit in accordance with the remittance request after the withdrawal processing has been performed by the withdrawal processing unit, and updates a database including the balance of the second account; a message queue store for writing and reading transactions on a first-in, first-out basis; a storage unit that stores a transaction management database including information about the withdrawal transaction or the deposit transaction, the acquisition unit writes the withdrawal transaction to the message queue storage unit; the withdrawal processing unit reads and executes the withdrawal transaction written in the message queue storage unit, and then writes the deposit transaction in the message queue storage unit; the deposit processing unit reads and executes the deposit transaction written in the message queue storage unit; moreover, the transaction management database includes a transaction identifier assigned to the remittance request; The message queue storage unit has each of the transaction identifiers written therein; and a re-execution unit that performs processing to re-execute the withdrawal transaction or deposit transaction corresponding to the remittance request when the transaction identifier written in the message queue storage unit is not included in the transaction management database.

1. An information processing device comprising:

2. the database containing the balance of the first account includes a transaction identifier assigned to the transfer request corresponding to a withdrawal transaction performed on the account; the database containing the balance of the second account includes a transaction identifier assigned to the remittance request corresponding to a deposit transaction performed on the account; The re-execution unit If the transaction identifier written in the message queue storage unit is not included in the transaction management database and the transaction identifier is not included in a database containing the balance of the first account, re-executing a withdrawal transaction corresponding to the remittance request; If the transaction identifier written in the message queue storage unit is not included in the transaction management database and the transaction identifier is not included in the database containing the balance of the second account, re-execute the deposit transaction corresponding to the remittance request.

2. The information processing apparatus according to claim 1, wherein:

3. An information processing method performed by an information processing device communicably connected to a memory unit that stores a transaction management database including a transaction identifier assigned to a remittance request to withdraw money from a first account and deposit money into a second account, comprising: an acquiring step of acquiring the remittance request; a withdrawal processing step of executing a withdrawal transaction to realize the withdrawal in the acquired remittance request and updating a database including the balance of the first account; a deposit processing step of executing a deposit transaction different from the withdrawal transaction, which is a transaction for realizing the deposit in the remittance request, after the withdrawal processing step has been performed, to update a database including the balance of the second account; In the obtaining step, the withdrawal transaction is written to a message queue storage unit that writes and reads transactions on a first-in, first-out basis; in the withdrawal processing step, after reading and executing the withdrawal transaction written in the message queue storage unit, writing the deposit transaction in the message queue storage unit; In the deposit processing step, the deposit transaction written in the message queue storage unit is read and executed; The information processing method is characterized in that each transaction identifier is written in the message queue storage unit, and the information processing method further comprises a re-execution step of performing processing to re-execute the withdrawal transaction or deposit transaction corresponding to the remittance request if the transaction identifier written in the message queue storage unit is not included in a transaction management database containing information regarding the withdrawal transaction or the deposit transaction.

4. A computer communicably connected to a memory unit that stores a transaction management database including transaction identifiers assigned to remittance requests to withdraw money from a first account and deposit money into a second account, an acquiring step of acquiring the remittance request; a withdrawal processing step of executing a withdrawal transaction to realize the withdrawal in the acquired remittance request and updating a database including the balance of the first account; a deposit processing step of executing a deposit transaction different from the withdrawal transaction, which is a transaction for realizing the deposit in the remittance request, after the withdrawal processing step has been performed, to update a database including the balance of the second account; In the obtaining step, the withdrawal transaction is written to a message queue storage unit that writes and reads transactions on a first-in, first-out basis; In the withdrawal processing step, the withdrawal written in the message queue storage unit After reading and executing the transaction, writing the deposit transaction to the message queue store; In the deposit processing step, the deposit transaction written in the message queue storage unit is read and executed; Each transaction identifier is written in the message queue storage unit, and if the transaction identifier written in the message queue storage unit is not included in a transaction management database containing information about the withdrawal transaction or the deposit transaction, a program for executing a re-execution step that performs processing to re-execute the withdrawal transaction or the deposit transaction corresponding to the remittance request.

Images