JP2023088789A - Information processing device, information processing method, and program - Google Patents

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

The present invention relates to technology for transferring money between accounts.

Financial institutions, etc. are proceeding with research and demonstration experiments on digital currency.

As a technology that contributes to speeding up the remittance process between accounts, for example, Patent Literature 1 proposes a mechanism capable of performing update processing and search processing independently and in parallel.

Japanese Patent No. 4175998

In systems that use relational databases, which are often used in bank accounting systems, etc., as the number of records in the table that manages the balance of each account increases, it takes time to search for the account whose balance is to be updated. Also, if you divide the table into multiple tables to reduce the number of records stored in one table, and the account to be updated the balance is divided into two tables, the above update process will take more time. .

The present invention has been made in view of such problems, and an object of the present invention is to speed up remittance processing between accounts.

In order to solve the above problems, the present invention provides an acquisition unit for acquiring a remittance request to withdraw money from a first account and deposit it in a second account, and an acquisition unit for realizing the withdrawal in the acquired remittance request. A withdrawal processing unit that executes a withdrawal transaction 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 and updates a database containing the balance of the second account. do.

a message queue storage for writing and reading transactions on a first-in, first-out basis; wherein the acquisition unit writes the withdrawal transaction to the message queue storage; and the withdrawal processing unit writes to the message queue storage. After reading and executing the withdrawal transaction, the deposit transaction is written in the message queue storage unit, and the deposit processing unit reads and executes the deposit transaction written in the message queue storage unit. good too.

A storage unit may be provided for storing a transaction management database containing information on the withdrawal transaction or the deposit transaction.

The transaction management database includes transaction identifiers assigned to the remittance requests, the message queue storage unit is written with each transaction identifier, and the transaction identifiers written in the message queue storage unit. is not included in the transaction management database, a re-execution unit may be provided that performs processing for re-executing the withdrawal transaction or the deposit transaction corresponding to the remittance request.

The database containing the balance of the first account includes transaction identifiers assigned to the money transfer requests corresponding to withdrawal transactions performed against the account, and the database containing the balance of the second account includes: including a transaction identifier assigned to the remittance request corresponding to the deposit transaction executed for the account; If not included and the transaction identifier is not included in the database including the balance of the first account, re-execute the withdrawal transaction corresponding to the remittance request and save the message queue. When the transaction identifier written in the account 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, the remittance request may be re-executed.

In addition, the present invention includes an acquisition step of acquiring a remittance request to withdraw money from a first account and deposit money into a second account, and executing a withdrawal transaction for realizing the withdrawal in the acquired remittance request. a payment processing step for updating a database containing the balance of the first account; and executing a deposit transaction different from the withdrawal transaction to update a database containing the balance of the second account.

Further, the present invention provides a computer with an acquisition step of acquiring a remittance request for withdrawing money from a first account and depositing money into a second account, and a withdrawal for realizing the withdrawal in the acquired remittance request. a withdrawal processing step of executing a transaction to update a database containing the balance of the first account; and a deposit processing step of executing a deposit transaction different from the withdrawal transaction to update a database containing the balance of the second account.

According to the present invention, it is possible to speed up the remittance process between accounts.

1 is a block diagram showing the overall configuration of a system according to one embodiment of the present invention; FIG. It is a block diagram which shows the hardware constitutions of the issuing subject server apparatus which concerns on this embodiment. It is a figure which illustrates the processing procedure of the remittance transaction in the past. It is a figure which illustrates the processing procedure of the remittance transaction in the past. It is a figure which illustrates the processing procedure of the remittance transaction in this embodiment. 3 is a block diagram showing the functional configuration of an issuer server device according to the present embodiment; FIG. 4 is a diagram illustrating the data structure of a ledger database stored by the issuer server device according to the present embodiment; FIG. 4 is a diagram exemplifying the data structure of a transaction management database stored by the issuing subject server device according to the present embodiment; FIG. FIG. 4 is a diagram illustrating definitions of workflow IDs, function IDs, and step IDs in this embodiment; 4 is a diagram exemplifying the data structure of a transaction generated by the issuing subject server device according to the present embodiment; FIG. 4 is a flow chart showing the operation of the issuer server device according to the present embodiment; 4 is a flow chart showing the operation of the issuer server device according to the present embodiment; 4 is a flow chart showing the operation of the issuer server device according to the present embodiment; 4 is a flow chart showing the operation of the issuer server device according to the present embodiment;

[composition]
Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In this embodiment, a case where the present invention is applied to a digital currency issued by an issuer such as a financial institution will be exemplified. FIG. 1 is a block diagram showing the overall configuration of a system according to one embodiment of the present invention. This system includes a user terminal 10 used by a user, a plurality of intermediary agency server devices 20 used by an intermediary agency such as a payment business operator, and an issuer server device 30 used by an issuer. The user terminal 10 and the intermediation agency server device 20, and the intermediary agency server device 20 and the issuer server device 30 are connected to each other via a predetermined communication network so as to be communicable. The issuing subject server device 30 functions as an information processing device according to the present invention. In this embodiment, the issuer server device 30 employs an account type as a ledger recording method.

FIG. 2 is a diagram showing the hardware configuration of the issuer server device 30. As shown in FIG. The issuer server device 30 is physically configured as a computer including a processor 3001, a memory 3002, a storage 3003, a communication device 3004, an input device 3005, an output device 3006, and a bus connecting them. Each of these devices operates with 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 some of the devices. Further, the issuer server device 30 may be configured by connecting a plurality of devices each having a different housing by a communication line.

Each function of the issuer server device 30 is performed by loading predetermined software (programs) onto hardware such as the processor 3001 and the memory 3002 so that the processor 3001 performs calculations, controls communication by the communication device 3004, It is realized by controlling at least one of data reading and writing in the memory 3002 and the storage 3003 .

The processor 3001, for example, operates an operating system and controls the entire computer. The processor 3001 may be configured by a central processing unit (CPU) including an interface with peripheral devices, a control device, an arithmetic device, registers, and the like. Further, the processor 3001 may include hardware such as a digital signal processor (DSP), an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), and an FPGA (Field Programmable Gate Array). good.

The processor 3001 reads programs (program codes), software modules, data, etc. from at least one of the storage 3003 and the communication device 3004 to the memory 3002, and executes various processes according to them. As the program, a program that causes a computer to execute at least part of the operations described later is used. The functional blocks of issuer server device 30 may be implemented by a control program stored in memory 3002 and running on processor 3001 . Various processes may be executed by one processor 3001, but may also be executed by two or more processors 3001 simultaneously or sequentially. Processor 3001 may be implemented by one or more chips. Note that the program may be transmitted to the issuer server device 30 via a communication line.

The memory 3002 is a computer-readable recording medium, and is composed of at least one of, for example, ROM (Read Only Memory), EPROM (Erasable Programmable ROM), EEPROM (Electrically Erasable Programmable ROM), and RAM (Random Access Memory). may be The memory 3002 may also be called a register, cache, main memory (main storage device), or the like. The memory 3002 can store executable programs (program code), software modules, etc. to perform the methods of the present invention.

The storage 3003 is a computer-readable recording medium, for example, an optical disk such as a CD-ROM (Compact Disc ROM), a hard disk drive, a flexible disk, a magneto-optical disk (for example, a compact disk, a digital versatile disk, a Blu-ray (registered trademark) disk), smart card, flash memory (eg, card, stick, key drive) and/or the like. Storage 3003 may also be called an auxiliary storage device.

The communication device 3004 is hardware for performing communication between computers via a communication network, and is also called a network device, network controller, network card, communication module, or the like.

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

Each device such as processor 3001 and 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 devices.

Since the user terminal 10 and the intermediation agency server device 20 are computers having the same configuration as the issuer server device 30, detailed description thereof will be omitted.

Here, the characterizing portion of this embodiment will be described. First, with reference to FIGS. 3 and 4, conventional remittance processing procedures for withdrawing X yen from a payer's account A and depositing the X yen into an account B will be described. Conventionally, as exemplified in FIG. Deposit Yen into Account B. These three processing procedures are executed as one transaction (hereinafter referred to as remittance transaction).

The term "transaction" as used herein refers to an indivisible series of processing units executed in a computer system. Therefore, in the example of FIG. 3, the entire remittance process is collectively managed as one transaction. In other words, when all the processes included in the money transfer transaction are successful, the money transfer transaction is considered to be completed. The remaining processing will be canceled.

Also, in order to reduce the number of records that a database containing the balance of each account has, it may be divided into multiple databases. Even in such a case, as exemplified in FIG. For example, X yen is withdrawn from account A, and in the database containing the balance of account B, the withdrawn X yen is deposited into account B. Since these three processing procedures are executed as one remittance transaction, even in this case, the remittance transaction is considered to be completed when all the processes included in the remittance transaction are successful. If either process fails, the remittance transaction is said to have failed.

As described above, when withdrawals and deposits are made in one remittance transaction, the database containing the account balance corresponds to the withdrawal source account (above account A) and the deposit destination account (above account B). Both of these records must be locked in order to perform exclusive control for each record to be processed. Conventionally, such exclusive control is performed simultaneously across two accounts according to each remittance transaction, so if a large number of remittance transactions are concentrated in a short time, will increase the time required to complete the

Therefore, in the present embodiment, one remittance transaction is divided into two different transactions, a withdrawal transaction and a deposit transaction, and executed. In other words, as illustrated in FIG. 5, first, a withdrawal transaction is executed to confirm that the account A has a balance of X yen or more. Process to withdraw money. Then, the next deposit transaction is executed, and the withdrawn X yen is deposited into the account B. By executing the withdrawal transaction and the deposit transaction separately in this way, it is possible to complete a large number of remittance transactions compared to the conventional method in which exclusive control in each remittance transaction was performed across two accounts at the same time. The required time can be shortened, that is, it is possible to speed up a large number of remittance processes. Although FIG. 5 shows an example in which one database contains the balances of accounts A and B, the configuration of the database is not limited to this. It may be a database different from the database containing.

In addition, in this embodiment, NoSQL (Not only SQL), which has faster writing and reading speeds than relational databases, is used as the database containing the balances of each account. Since NoSQL does not implement exclusive control of records as described above, processing speed can be increased compared to the case of exclusive control of records. However, if exclusive control of records is not performed, when data is updated in the database, for example, before making a withdrawal from an account that has been confirmed to have a sufficient balance for withdrawal by a certain withdrawal transaction , there is a possibility that the withdrawal will be executed by another withdrawal transaction and problems such as insufficient balance may occur.

Therefore, in this embodiment, a so-called message queuing system is used to process two accounts: withdrawal processing for the withdrawal source account (above account A) and deposit processing for the deposit destination account (above account B). Perform data update processing for Specifically, as illustrated in FIG. 5, the withdrawal transaction is first written to the message queuing system, read and executed, and then the deposit transaction is written to the message queuing system and read. Execute. Since the message queuing system writes and reads messages (transactions in this case) on a first-in, first-out basis, even if each withdrawal transaction and each deposit transaction related to multiple remittance transactions are mixed, these transactions are guaranteed to be sequential. Therefore, the possibility of occurrence of the problems described above is reduced.

FIG. 6 is a diagram showing an example of the functional configuration of the issuer server device 30. As shown in FIG. The functions illustrated in FIG. 6 are performed by causing the processor 3001 to perform calculations, controlling communication by the communication device 3004, and controlling the and by controlling at least one of data reading and writing in the storage 3003 .

In FIG. 6, an acquisition unit 31 acquires various kinds of information from outside the issuer server device 30 via a communication network. For example, the acquiring unit 31 withdraws the remittance amount X yen from the withdrawal source account (first account in the present invention) from the intermediary institution server device 20 and transfers the amount to the destination account (second account in the present invention) ) to obtain a remittance request. This remittance request is generated, for example, by the intermediary server device 20 in response to an instruction from the user terminal 10, and includes at least information designating a withdrawal source account, a deposit destination account, and a remittance amount.

The storage unit 32 stores a ledger database (hereinafter, the database is referred to as DB) 321 and a transaction management DB 322 . Note that each DB does not have to include any information among the information groups exemplified below.

The ledger DB 321 is a database containing information on each user's account. As illustrated in FIG. 7, the ledger DB 321 contains the account name (#1), account balance (#2), sequence number (#3), last transaction ID (#4) and transaction ID list (# 5). The sequence number is a number that is incremented each time one transaction is executed for this account, and represents the order of the transactions instructed by the user, as well as the total number of transactions instructed by this user in the past. . In the payment processing described above, the sequence number in the payment transaction and the sequence number in the ledger DB 321 are compared, and if they do not match, a processing sequence error occurs.

In the ledger DB 321, the last transaction ID is a transaction ID (transaction identifier) that identifies the last transaction that triggered the 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 described above, and the cell is the last transaction ID of the previous transaction in terms of time.

Since the transaction ID list has such a structure, it is possible to know the history of transactions executed in the past. Specifically, the qualifier in the top element of the transaction ID list corresponds to the last transaction ID (the same value as the last transaction ID in the ledger DB), the Cell corresponds to the previous transaction ID in terms of time, The qualifier in the next element corresponds to the transaction ID that is temporally one before, and the Cell corresponds to the transaction ID that is temporally one (that is, two) before. This chain of transaction IDs continues, with the qualifier in the last element corresponding to the last transaction ID and the Cell being the terminator (0).

In the course of the withdrawal process and the deposit process described above, the leading element in this transaction ID list and the last transaction ID in the ledger DB 321 are updated. Then, in the process of withdrawal processing or deposit processing, if the transaction ID list includes the transaction ID of the transaction to be processed (withdrawal transaction or deposit transaction), skipping that process eliminates duplicate transactions. It is designed to prevent money and double deposits.

The transaction management DB 322 is a database containing information on each transaction (withdrawal transaction and deposit transaction). As illustrated in FIG. 8, the transaction management DB 322 stores record creation date/time (#1), transaction ID (#2), workflow ID (#3), function ID (#4), and step ID (#5) of each transaction. ), including the contents of the transaction (#6). Workflow IDs, function IDs, and step IDs are defined as illustrated in FIG. The contents of the transaction are referenced when re-executing the transaction, which will be described later.

When the aforementioned deposit processing ends normally, or when some sort of error occurs in the withdrawal processing (for example, the above-mentioned sequence number mismatch or lack of balance in the withdrawal source account), the transaction management DB 322 Information is written. For example, if the deposit process ends normally, the date and time when the deposit transaction was successful as the "record creation date and time", the hashed character string of the above-mentioned remittance request as the transaction ID, and "remittance" as the workflow ID. Corresponding "WF001" (see Fig. 9), "FN002" corresponding to "deposit" as the function ID (see Fig. 9), "ST02" corresponding to "finish" as the step ID (see Fig. 9), transaction details , the content of the remittance request is written. Also, if any error occurs in the withdrawal process (for example, the above-mentioned sequence number mismatch or insufficient balance in the withdrawal source account), the date and time when the error occurred as the "record creation date and time" and the transaction ID The content of the remittance request is written as a character string hashed from the content of the remittance request, the content of the remittance request is written as the content of the transaction, and the content corresponding to the process being executed at the time of error occurrence as the workflow ID, function ID, and step ID (Fig. 9) is written. In this way, the transaction management DB 322 records information about normally completed transactions and information about unsuccessfully completed transactions.

Thus, a withdrawal transaction and a deposit transaction included in one remittance transaction are defined by a combination of the workflow ID and the function ID. For example, in a remittance transaction of withdrawing X yen from withdrawal source account A and depositing X yen into deposit destination account B, the combination of workflow ID “WF001” and function ID “FN001” illustrated in FIG. defines a withdrawal transaction, and a combination of workflow ID "WF001" and function ID "FN002" defines a deposit transaction. Therefore, the transaction management DB 322 contains information regarding withdrawal or deposit transactions.

The message queue storage unit 33 is means for realizing a message queuing system, and writes and reads messages (transactions in this case) on a first-in, first-out basis. FIG. 10 is a diagram illustrating the data structure of transactions (withdrawal transactions and deposit transactions) corresponding to messages in the message queue storage unit 33. As shown in FIG. A transaction includes a workflow ID (#1), a function ID (#2), a message sender (#3), a message lifetime (#4), a transaction ID (#5), and message body content (#6). . In this transaction, a withdrawal transaction is defined by the combination of workflow ID "WF001" and function ID "FN001", and a deposit transaction is defined by the combination of workflow ID "WF001" and function ID "FN002". In other words, a withdrawal transaction and a deposit transaction are identified by a 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, and a plurality of them may be provided.

When obtaining a new remittance request from the intermediation agency server device 20, the obtaining unit 31 hashes the content of the remittance request (a character string included in the remittance request), and stores the hashed character string in a message queue as a transaction ID. Part 33 is written. In other words, the transaction ID corresponds to the remittance request on a one-to-one basis. The same transaction ID is used for the withdrawal transaction and the deposit transaction. By using the same transaction ID in the withdrawal transaction and the deposit transaction in this way, the withdrawal transaction and the deposit transaction corresponding to the same remittance request can be identified.

The withdrawal processing unit 34 executes a withdrawal transaction for realizing withdrawal in the remittance request, and updates the balance of the account of the withdrawal source in the ledger DB 321 . The withdrawal processing unit 34 reads and executes the withdrawal transaction written in the message queue storage unit 33 , then generates a payment transaction and writes it in the message queue storage unit 33 .

After the withdrawal processing is performed by the withdrawal processing unit 34 , the deposit processing unit 35 reads out the deposit transaction for realizing the deposit in the remittance request from the message queue storage unit 33 , executes it, and stores the deposit destination account in the ledger DB 321 . update the balance of

The output unit 36 outputs various types of 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.

The re-executing unit 37 checks whether there is any inconsistency in the execution results of these transactions, in preparation for cases such as when the process terminates abnormally while executing a withdrawal transaction or a deposit transaction, and if there is an inconsistency 2, the remittance recovery transaction (see FIG. 9) is executed to re-execute the transaction subject to inconsistency (withdrawal transaction and deposit transaction corresponding to the remittance request).

[motion]
Next, the operation of this embodiment will be described. First, with reference to FIG. 11, the processing from the acquisition of the remittance request by the issuer server device 30 to the writing of the withdrawal transaction in the message queue storage unit 33 will be described. In FIG. 11, the acquiring unit 31 acquires a remittance request from the intermediary agency server device 20 (step S11).

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). For the withdrawal transaction written at this time, "WF001" (remittance) is written as the workflow ID in FIG. 10, "FN001" (withdrawal) is written as the function ID, and the content of the remittance request is hashed as the transaction ID. A character string is written.

The processing described above is executed each time a remittance request is obtained by the issuer server device 30 . As a result, withdrawal transactions corresponding to each remittance request are sequentially written in the message queue storage unit 33 .

Next, with reference to FIG. 12, the processing from the issuer server device 30 reading out a payment transaction from the message queue storage unit 33 to executing it and writing a payment transaction to the message queue storage unit 33 will be described. In FIG. 12, the withdrawal processing unit 34 reads withdrawal transactions from the message queue storage unit 33 according to the first-in, first-out method (step S21).

The payment processing unit 34 executes the read payment transaction (step S22). Thereby, the ledger DB 321 is updated. 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 necessary information to the transaction management DB 322 as a sequence error and ends the process. do.

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). In the payment transaction written at this time, "WF001" (remittance) is written as the workflow ID in FIG. In other words, a character string in which the content of the remittance request is hashed is written. The processing described above is executed each time a withdrawal transaction is read out from the message queue storage unit 33 .

Next, with reference to FIG. 13, the processing from the time when the issuer server device 30 reads out the deposit transaction from the message queue storage unit 33 to the execution thereof will be described. In FIG. 13, the deposit processing unit 35 reads deposit transactions from the message queue storage unit 33 according to the first-in, first-out method (step S31).

The deposit processing unit 35 executes the read deposit transaction (step S32). Thereby, the ledger DB 321 is updated. The processing described above is executed each time a deposit transaction is read out from the message queue storage unit 33 . The deposit processing unit 35 updates the transaction management DB 322 illustrated in FIG. 8 when the deposit transaction is successful. Specifically, the deposit processing unit 35 sets the date and time when the deposit transaction was successful as the “record creation date and time” in FIG. "WF001" (see Fig. 9), "FN002" (see Fig. 9) corresponding to "deposit" as the function ID, "ST02" (see Fig. 9) corresponding to "finish" as the step ID, transaction The content of the remittance request is written as the content of .

Withdrawal transactions and deposit transactions corresponding to each remittance request are written in the message queue storage unit 33 as described above. Withdrawal processing and deposit processing are sequentially executed in response to the remittance request.

Next, with reference to FIG. 14, processing when issuing subject server device 30 re-executes a payment transaction or a payment transaction when there is an inconsistency in the execution results of these transactions will be described. In FIG. 14, the re-executing unit 37 periodically or at any time, for example, re-executes any one of all the transactions (withdrawal transactions and deposit transactions) stored in the message queue storage unit 33. The ID is read (step S41).

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

The transaction management DB 322 should record transaction IDs corresponding to all remittance requests acquired by the acquisition unit 31 on a one-to-one basis. If the corresponding transaction ID is included in the transaction management DB 322 (step S43; YES), the re-execution unit 37 returns to step S41, reads out the next transaction ID from the message queue storage unit 33, and repeats the above-described processing. .

On the other hand, if the corresponding transaction ID is not included in the transaction management DB 322 (step S43; NO), the re-execution unit 37 re-executes the withdrawal transaction corresponding to the remittance request corresponding to this transaction ID. Specifically, the re-execution unit 37 writes the withdrawal transaction corresponding to the remittance request corresponding to the transaction ID to the message queue storage unit 33 (step S44), and then transitions to the process of step S21 in FIG. Thereafter, each process as described with reference to FIGS. 12 and 13 is executed again.

At this time, if the transaction ID of the withdrawal transaction is included in the transaction ID list of the withdrawal source account in the ledger DB 321, the withdrawal processing unit 34 determines that this withdrawal transaction has been executed, and without updating the account balance, a deposit transaction is created and written in the message queue storage unit 33 (step S23 in FIG. 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 the ledger DB 321, the withdrawal processing unit 34 determines that the withdrawal transaction has not been executed. to run. Similarly, if the transaction ID of the deposit transaction is included in the transaction ID list of the deposit destination account in the ledger DB 321, the deposit processing unit 35 determines that this deposit transaction has been executed, and End the deposit transaction without updating the balance. 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 the ledger DB 321, the deposit processing unit 35 determines that the deposit transaction has not been executed and executes it.

As described above, 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 .

According to the embodiment described above, one remittance transaction is substantially divided into two different transactions, namely, a withdrawal transaction and a deposit transaction. The turnaround time required to complete a large number of money transfer transactions can be reduced as compared to the traditional methods used. That is, it becomes possible to speed up a large number of remittance processes.

In addition, in the above embodiment, as a database containing the balance of each account, NoSQL, which has a faster writing speed than a relational database, is adopted, and a message queuing system is used to process withdrawals and deposits to accounts from which withdrawals are made. Since data update processing for two accounts, that is, deposit processing for one account, is sequentially performed, remittance processing can be executed at high speed and with certainty.

In addition, in the above embodiment, if there is an inconsistency in the execution result of a withdrawal transaction or a deposit transaction, the inconsistent transaction is re-executed. This makes it possible to reliably execute remittance processing.

[Modification]
The present invention is not limited to the embodiments described above, and the embodiments described above may be modified as follows. In the above embodiment, an example in which the present invention is applied to digital money transfer has been described, but the application of the present invention is not limited to this, and can be applied to the case of performing remittance between accounts in response to a plurality of remittance requests.

The present invention applies not only to the information processing device, which is the issuer server device exemplified in the embodiment, but also to an information processing method performed by this information processing device, that is, a remittance method in which money is withdrawn from a first account and deposited into a second account. an acquisition step of acquiring a request; a withdrawal processing step of executing a withdrawal transaction for realizing withdrawal in the acquired remittance request and updating a database containing the balance of the first account; After the withdrawal processing is performed by the withdrawal processing step, a transaction for realizing the deposit in the remittance request, which is different from the withdrawal transaction, is executed to reduce the balance of the second account. It can also be implemented as an information processing method comprising a payment processing step of updating a database including Furthermore, implementation is also possible 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 a form recorded on a recording medium such as an optical disk, or may be provided to the computer via a network such as the Internet.

10: user terminal, 20: intermediary agency server device, 30: issuer server device, 31: acquisition unit, 32: storage unit, 33: message queue storage unit, 34: withdrawal processing unit, 35: deposit processing unit, 36 3001: Processor 3002: Memory 3003: Storage 3004: Communication device 3005: Input device 3006: Output device.

Claims (7)

an acquisition unit for acquiring a remittance request to withdraw from the first account and deposit to the second account;
a withdrawal processing unit that executes a withdrawal transaction for realizing withdrawal in the acquired remittance request and updates a database containing the balance of the first account;
After the withdrawal processing is performed by the withdrawal processing unit, a transaction for realizing the deposit in the remittance request, which is different from the withdrawal transaction, is executed to open the second account. and a deposit processing unit that updates a database containing balances. Equipped with a message queue storage that writes and reads transactions on a first-in, first-out basis,
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 payment transaction in the message queue storage unit,
2. The information processing apparatus according to claim 1, wherein the deposit processing unit reads and executes the deposit transaction written in the message queue storage unit. 3. The information processing apparatus according to claim 2, further comprising a storage unit that stores a transaction management database containing information about the payment transaction or the payment transaction. the transaction management database includes a transaction identifier assigned to the remittance request;
Each transaction identifier is written in the message queue storage unit,
a re-executing unit that performs processing for re-executing a withdrawal transaction or a 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; 4. The information processing apparatus according to claim 3, comprising: a database containing the balance of the first account includes transaction identifiers assigned to the money transfer requests corresponding to withdrawal transactions performed against the account;
a database containing the balance of the second account includes a transaction identifier assigned to the transfer request corresponding to a deposit transaction performed against the account;
The re-execution unit
When the transaction identifier written to the message queue storage unit is not included in the transaction management database, and when the transaction identifier is not included in the database containing the balance of the first account , re-execute the withdrawal transaction corresponding to said remittance request,
when the transaction identifier written to the message queue storage unit is not included in the transaction management database, and when the transaction identifier is not included in the database containing the balance of the second account; 5. The information processing apparatus according to claim 4, wherein a deposit transaction corresponding to said remittance request is executed again. an obtaining step of obtaining a remittance request to withdraw from the first account and deposit to the second account;
a withdrawal processing step of executing a withdrawal transaction for realizing withdrawal in the acquired remittance request and updating a database containing the balance of the first account;
After the withdrawal processing is performed by the withdrawal processing step, a transaction for realizing the deposit in the remittance request, which is different from the withdrawal transaction, is executed to open the second account. and a deposit processing step of updating a database containing balances. to the computer,
an obtaining step of obtaining a remittance request to withdraw from the first account and deposit to the second account;
a withdrawal processing step of executing a withdrawal transaction for realizing withdrawal in the acquired remittance request and updating a database containing the balance of the first account;
After the withdrawal processing is performed by the withdrawal processing step, a transaction for realizing the deposit in the remittance request, which is different from the withdrawal transaction, is executed to open the second account. A program for running a payment processing step that updates a database containing balances.

Images