Information processing systems, information processing methods, and programs

Abstract

We provide information processing systems and other tools that enable the smooth execution of operations related to the safekeeping of funds. [Solution] According to one aspect of the present invention, an information processing system is provided comprising one or more processors, wherein in a receiving step, the processor receives a transfer instruction from a user including the transfer amount and the recipient account; in a transfer instruction step, the processor issues a transfer instruction to a management system of an intermediary account that enables online transfer instructions, instructing the system to transfer the funds to the recipient account when funds for paying the transfer amount are moved from the user's account to the intermediary account; in a calculation step, the processor calculates the amount of funds subject to protection based on the balance in the intermediary account or the deposits and withdrawals to the intermediary account; and in a processing step, the processor performs processing related to the protection of funds based on the calculated amount of funds subject to protection.

Description

Technical Field

[0001] The present invention relates to an information processing system, an information processing method, and a program.

Background Art

[0002] In Patent Document 1, when a combined debit transaction that periodically debits the total amount of multiple usage fees from an account occurs, it is determined whether there is a change in the transaction details between the current combined debit transaction and a past combined debit transaction. If it is determined that there is a change in the transaction details, the transaction detail information of the current combined debit transaction is output to the user terminal related to the user so that the user can identify that there is such a change.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a transfer agency that performs a transfer upon receiving an instruction from a user, since the user's funds are temporarily deposited, an obligation to preserve the deposited funds arises. There are various methods for preserving funds, but if the funds to be preserved are not grasped, it may hinder the operations related to the preservation of funds.

[0005] In view of the above circumstances, the present invention aims to provide an information processing system and the like that can smoothly perform operations related to the preservation of funds.

Means for Solving the Problems

[0006] According to one aspect of the present invention, an information processing system is provided comprising one or more processors, wherein in a receiving step, the processor receives a transfer instruction from a user including the transfer amount and the recipient account; in a transfer instruction step, the processor issues a transfer instruction to a management system of an intermediary account that enables online transfer instructions, instructing the system to transfer the funds to the recipient account when funds for paying the transfer amount are moved from the user's account to the intermediary account; in a calculation step, the processor calculates the amount of funds subject to protection based on the balance in the intermediary account or the deposits and withdrawals to the intermediary account; and in a processing step, the processor performs processing related to the protection of funds based on the calculated amount of funds subject to protection.

[0007] This configuration allows for the smooth execution of operations related to the safekeeping of funds. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of the overall configuration of payment support system 1. [Figure 2] This figure shows an example of the hardware configuration of the payment support server 10. [Figure 3] This figure shows an example of the hardware configuration of user terminal 50. [Figure 4] This diagram shows an example of the overall flow of payment support processing. [Figure 5] This is an activity diagram illustrating an example of payment support processing. [Figure 6] This figure shows an example of a list of displayed payment data. [Figure 7] This figure shows an example of a payment data entry screen. [Figure 8] This is a diagram showing an example of a summary image for a payment request. [Figure 9] This figure shows an example of an approval screen. [Figure 10] This figure shows an example of a period table. [Figure 11] This figure shows an example of an account management screen. [Figure 12]This figure shows an example of a screen for making corrections. [Figure 13] This diagram shows another example of the overall flow of payment support processing. [Figure 14] This diagram shows an example of the overall flow of payment support processing. [Figure 15] This figure shows another example of the overall configuration of Payment Support System 1. [Figure 16] This figure shows an example of the specified screen. [Figure 17] This figure shows an example of the displayed payment schedule screen. [Figure 18] This figure shows an example of the displayed payment plan screen. [Modes for carrying out the invention]

[0009] Embodiments of the present invention will be described below with reference to the drawings. The various features shown in the embodiments below can be combined with each other.

[0010] Incidentally, the program for realizing the software appearing in one embodiment may be provided as a non-transitory computer-readable medium, or it may be provided so that it can be downloaded from an external server, or it may be provided so that the program is launched on an external computer and its functions are realized on a client terminal (so-called cloud computing).

[0011] In addition, in various information processing according to an embodiment, an input and an output corresponding to the input can be realized. Here, if an output is obtained as a result of the input, the mode of information (hereinafter referred to as reference information) referred to in such information processing is not limited. The reference information may be, for example, rule-based information such as a database, a lookup table, a predetermined function (including a judgment formula such as a regression formula constructed by a statistical method), a learned model in which the correlation between the input and the output has been learned in advance, a large language model capable of outputting a desired result by inputting a prompt (these models include parameters for constructing the correlation between the input and the output), or a generative AI such as a vision language model.

[0012] In addition, in one embodiment, the "unit" may include, for example, hardware resources implemented by a circuit in a broad sense and information processing of software that can be specifically realized by these hardware resources. Also, in one embodiment, various information is handled, and these information are represented, for example, by physical values of signal values representing voltage and current, the high and low of signal values as a set of binary bits composed of 0 or 1, or quantum superposition (so-called quantum bits), and communication and calculation can be executed on a circuit in a broad sense.

[0013] Furthermore, a circuit in a broad sense is a circuit realized by appropriately combining at least a circuit, circuitry, a processor, a memory, etc. The processor may be a general-purpose processor or a dedicated circuit. That is, it includes application specific integrated circuits (ASICs), programmable logic devices (e.g., simple programmable logic devices (SPLDs), complex programmable logic devices (CPLDs), and field programmable gate arrays (FPGAs)), etc.

[0014] <Embodiment> 1. System Configuration Hereinafter, the system configuration according to the embodiment will be described. FIG. 1 is a diagram showing an example of the overall configuration of the payment support system 1. In FIG. 1, each device included in the payment support system 1 and an overview of the users who use those devices are shown. Each overview will be described as needed while referring to other figures.

[0015] The payment support system 1 is an information processing system that provides a payment support service for supporting payments generated in transactions, and executes various information processing for providing the service. The payment support system 1 particularly supports payments by withdrawing funds of the payer in the bank account and transferring them to the payee's bank account. The payment support system 1 is characterized by performing the procedures from withdrawal to transfer in one go.

[0016] The payment support system 1 comprises a communication line 2, a payment support server 10, a collection agency server 20, a data management server 30, a first bank server 41, a second bank server 42, and a third bank server 43 (referred to as "bank server 40" when not distinguished), and a payer terminal 51, an approver terminal 52, and a worker terminal 53 (referred to as "user terminal 50" when not distinguished).

[0017] Communication line 2 is not particularly limited, but for example, it is composed of the Internet network. Communication line 2 may also include a local area network, a mobile communication network, and a VPN (Virtual Private Network). Communication line 2 mediates the exchange of data between devices connected to its own line. In the example in Figure 1, each server is connected to communication line 2 by wire, and each terminal is connected wirelessly. Note that the connection of each device to communication line 2 may be either wired or wireless.

[0018] The payment support server 10 is an information processing device that performs central information processing for providing payment support services. The collection agency server 20 is an information processing device that performs information processing related to collection agency services, which act as an agent for collecting payments in transactions. The data management server 30 is an information processing device that performs information processing related to data management services, which store and manage user data. The collection agency service and the data management service may be provided by the business operator that provides the payment support system 1, or by a different business operator.

[0019] The bank server 40 is an information processing device that performs information processing related to bank operations. The first bank server 41 is a server that performs information processing related to the operations of the bank that manages the payer's account (hereinafter referred to as "the first bank"). The second bank server 42 is a server that performs information processing related to the operations of the bank that handles transfer operations in the payment support service (hereinafter referred to as "the second bank"). The third bank server 43 is a server that performs information processing related to the operations of the bank that manages the claimant's account (hereinafter referred to as "the third bank").

[0020] User terminal 50 is an information processing device that functions as the UI (User Interface) for users of the payment support system 1, and is, for example, a laptop computer. Payer terminal 51 is a terminal used by the payer who pays the transaction price. Approver terminal 52 is a terminal used by the approver who approves the payment. Worker terminal 53 is a terminal used by the worker who performs the operation of transferring funds from the first bank to the second bank for payment.

[0021] Each server (payment support server 10, collection agency server 20, data management server 30, and bank server 40) performs authentication processing to authenticate users using the user terminal 50, and display processing to display images on the user terminal 50. Each server stores authentication information (user ID and password, etc.) for authenticating users using the payment support system 1, and authenticates users who enter the authentication information. By authenticating users, each server can restrict access to data or add identification information to the data entered by the user to make it identifiable.

[0022] Each server performs display processing, such as generating and sending HTML (Hyper Text Markup Language) files, and displays a web page showing the system screen on the user terminal 50 using the browser's functions. Alternatively, the user terminal 50 may install an application program for using the payment support system 1, and each server may perform display processing, such as generating and sending display data for that application. Each server controls the display on the user terminal 50 by performing these display processing operations.

[0023] 2. Hardware Configuration The hardware configuration according to this embodiment will be described below. Figure 2 shows an example of the hardware configuration of the payment support server 10. The payment support server 10 comprises a control unit 101, a storage unit 102, a communication unit 103, and a bus 104. The bus 104 electrically connects each part of the payment support server 10.

[0024] (Control Unit 101) The control unit 101 has at least one processor. The at least one processor may consist of, for example, a central processing unit (CPU), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), one or more integrated circuits, one or more discrete circuits, or a combination thereof.

[0025] The control unit 101 is a computer that realizes various functions related to the payment support system 1 by reading predetermined programs stored in the memory unit 102. In other words, information processing by software stored in the memory unit 102 is concretely realized by the control unit 101, which is an example of hardware, and can be executed as each functional unit included in the control unit 101. Note that the control unit 101 is not limited to being a single unit, and may be implemented with multiple control units 101 for each function, or a combination thereof.

[0026] (Storage unit 102) The storage unit 102 stores various types of information as defined above. This can be done, for example, as a storage device such as a solid-state drive (SSD) or hard disk drive (HDD) that stores various programs related to the payment support system 1 executed by the control unit 101, or as a memory such as random access memory (RAM) that stores temporarily necessary information (arguments, arrays, etc.) related to program calculations. The storage unit 102 stores various programs and variables related to the payment support system 1 executed by the control unit 101.

[0027] (Communications Department 103) The communication unit 103 is comprised of a communication module. The communication module may be a wireless communication module compliant with standards such as IEEE 802.11a / b / g / n / ac / ax, LTE, 5G, 6G, or a wired communication module compliant with standards such as IEEE 802.3. The communication unit 103 is configured to transmit various electrical signals from the payment support server 10 to external components. The communication unit 103 is also configured to receive various electrical signals from external components to the payment support server 10. More preferably, the communication unit 103 has a network communication function, thereby enabling the communication of various information between the payment support server 10 and external devices via the communication line 2.

[0028] The payment collection server 20, data management server 30, and bank server 40 shown in Figure 2 have the same hardware configuration as the payment support server 10. For the payment collection server 20, data management server 30, and bank server 40, only the control units 201, 301, and 401 are denoted by different reference numerals than the control unit 101 of the payment support server 10.

[0029] Figure 3 shows an example of the hardware configuration of a user terminal 50. The user terminal 50 (payer terminal 51, approver terminal 52, and worker terminal 53) comprises a control unit 501, a storage unit 502, a communication unit 503, an input unit 504, an output unit 505, and a bus 506. The bus 506 electrically connects each part of the user terminal 50. The control unit 501, storage unit 502, and communication unit 503 are similar hardware to the control unit 101, storage unit 102, and communication unit 103 shown in Figure 5, although their specifications and models may differ.

[0030] (Input section 504) The input unit 504 has input receiving means such as keys, buttons, touchscreens, and mice, and accepts input from the user. The input unit 504 may also have sound receiving means such as a microphone, and may have a function to collect the user's voice and accept the input of the collected voice.

[0031] (Output section 505) The output unit 505 has display means such as a display and sound emission means such as a speaker, and outputs visual information and auditory information. For example, the output unit 505 displays visual information such as screens, images, icons, and text on the display surface of the display unit in a manner that is visible to the user. The output unit 505 also outputs audible sound such as speech or synthesized sound from the speaker.

[0032] 3. Information Processing The following describes the information processing according to the embodiment. In the following description, the payment support server 10, collection agency server 20, data management server 30, first bank server 41, second bank server 42, third bank server 43, payer terminal 51, approver terminal 52, and worker terminal 53 are described as the main entities of each information processing, but their information processing is performed by at least one processor provided in the payment support system 1, that is, by the processor in the control unit of each device. The payment support system 1 performs payment support processing to provide payment support services. The following describes the payment support processing with reference to Figures 4 and 5, etc.

[0033] Figure 4 is a diagram illustrating an example of the overall flow of payment support processing. Figure 5 is an activity diagram showing an example of payment support processing. While there are some common points in the explanations in Figures 4 and 5, the difference lies in the fact that Figure 4 includes human work, while Figure 5 focuses solely on the information processing performed by the information processing device. Payment support processing begins when a transaction takes place between the payer and the claimant, and the invoice issued by the claimant reaches the payer. The example in Figure 4 explains the case where a paper invoice 3 is issued.

[0034] First, the payer scans the invoice 3 using the scanner 4 shown in Figure 4 and uploads the generated invoice image to the data management server 30. The data management server 30 stores the uploaded invoice image in the management database 5 (Activity A11). Next, the data management server 30 recognizes the invoice information from the invoice image using, for example, an OCR (Optical Character Reader) function, and stores the recognized invoice information in the management database 5 in association with the invoice image (Activity A12).

[0035] Invoice information refers to information related to a billing transaction, such as the billing amount, recipient, billing source, bank account details, issue date, and payment due date. The payer may also enter the invoice information when uploading the invoice image. As A11 and A12 are repeatedly executed, the data management server 30 stores, for example, invoice images and invoice information addressed to the payer's organization as payment data (Figure 4(1)). The payer terminal 51 displays a list of the payment data stored in the data management server 30 (Activity A13).

[0036] Figure 6 shows an example of a list of displayed payment data. In Figure 6, the system screen G1 of the payment support system 1 is displayed. The system screen G1 is displayed by the payment support server 10 in cooperation with the data management server 30. The system screen G1 displays an unprocessed tab TB11 for displaying unprocessed payment data and a processed tab TB12 for displaying processed payment data.

[0037] In this context, "processing" refers to the payment application process. The Unprocessed tab TB11 displays payment data for which applications have not yet been submitted, while the Processed tab TB12 displays payment data for which applications have been submitted. In the example in Figure 6, the Unprocessed tab TB11 is selected. When the Unprocessed tab TB11 is selected, the Status field D11, the Transaction Date field D12, the Payment Data List C11, the Payment Application button B11, the Edit button B12, and the Application Check button B13 are displayed.

[0038] List C11 displays the following information in association with each other: "Status," "File Name," "Transaction Date," "UL Date and Time" (UL: Upload), "Payee," "Payment Amount," and "Payment Due Date." "File Name" displays the file name and path of the invoice image. "Transaction Date" displays the date the transaction subject to billing took place. "UL Date and Time" displays the date and time the invoice image was uploaded. "Payee" displays the payee of the invoice. "Payment Amount" displays the invoice amount.

[0039] The "Status" column displays either "Completed" (indicating that payment data information, such as the invoice amount and payment due date, has been entered) or "Incomplete" (indicating that it has not been entered). Pressing the edit button B12 will display the screen for entering payment data information.

[0040] Figure 7 shows an example of a payment data input screen. In Figure 7, the system screen G2 of the payment support system 1 is displayed. The system screen G2 is also displayed by the payment support server 10 in cooperation with the data management server 30. The system screen G2 displays an invoice image C21, a payment data input field D21, and an input completion button B21. The invoice image C21 is an image of the invoice for which payment will be made based on the payment data displayed in association with the edit button B12 operated in Figure 6. The invoice image C21 shows the recipient, invoice date, invoicer, payment due date, bank account for transfer, and invoice amount.

[0041] Input field D21 is an area for entering information indicating payment data. In the example in Figure 7, it includes areas for entering "Transaction Date," "Customer Name," "Payment Amount," "Payment Due Date," and "Bank Account for Transfer." Each input field D21 pre-displays information for each item recognized by the data management server 30 from the invoice image C21. The payer compares the information in input field D21 with the invoice image C21 to verify whether the correct information has been entered. If there is an error (i.e., a misrecognition), they enter the correct information.

[0042] The payer operates the Input Complete button B21 once all the information is correct. When the Input Complete button B21 is operated, the status of the payment data shown in Figure 6 becomes "Inputted". If, for example, "Inputted" is specified in the specification field D11 shown in Figure 6, only payment data with the status "Inputted" will be displayed. Also, if a specified period is specified in the specification field D12, only payment data whose transaction dates fall within the specified period will be displayed. When the payer checks the application check button B13 to select the payment data to be paid and operates the payment application button B11, the payer terminal 51 displays a summary image of the payment application.

[0043] Figure 8 shows an example of a summary image of a payment request. In Figure 8, the summary screen C12 is displayed overlaid on the system screen G1. The summary screen C12 displays the application details fields C13, C14, C15, and C16, the payment-related input fields D13 and D14, the cancel button B14, and the submit button B15.

[0044] Display field C13 shows the number of payment data selected in list C11 shown in Figure 6 as "Number of Payments". Display field C14 shows the subtotal amount of those payments as "Payment Amount". Display field C15 shows the "Fees" required for those payments. Display field C16 shows the "Total Amount" of the payment amount and fees. Input field D13 is the area for entering the name of the payment group indicated by the selected payment data. Input field D14 is the area for entering the payment due date indicated by the selected payment data.

[0045] If the payer wishes to change the payment target, they can return to the system screen G1 display and re-select the payment data by operating the cancel button B14. Once the payer has confirmed that there are no problems with the payment target and has entered the group name and payment date, they operate the application button B15 to complete the selection of the payment target (Figure 4 (2)) and confirm the application. The payer terminal 51 accepts the above operations as a selection operation of the payment target (activity A14) and sends request data to the approver terminal 52 requesting approval of the payment indicated by the selected payment data. Upon receiving the request data, the approver terminal 52 displays the payment approval screen indicated by the received request data (activity A15).

[0046] Figure 9 shows an example of an approval screen. In Figure 9, system screen G3 is displayed. System screen G3 is also displayed by the payment support server 10 in cooperation with the data management server 30. System screen G3 displays a payment tab TB31 for displaying payment data for which payment requests have been made, and a payment error tab TB32 for displaying payment data for which payment errors occurred. A payment error refers to, for example, a situation where a transfer could not be made because the recipient account was incorrect. In the example in Figure 9, the payment tab TB31 is selected.

[0047] When the Payment tab TB31 is selected, the Status field D31, Transaction Date field D32, Source field D33, Payment Data List C31, Payment Data Details Display field C32, and New Create button B31 are displayed. In List C31, the "Status," "Group Name," "Payment Date," and "Total Amount" of each payment data are displayed. The "Status" shows "Applied" (application submitted but not yet approved), "Approved" (approved but not yet paid), and "Paid" (payment completed). If a payment fails, the error will be displayed in the Payment Error tab TB32.

[0048] Here, system screen G3 is assumed to be both an approval screen for accepting approval operations by approvers and an application management screen for accepting applications by payers. Therefore, system screen G3 can also be displayed on the payer terminal 51. For example, when the new creation button B31 is operated, a creation screen for creating payment data is displayed, and the payer can manually enter new payment data. Payment data created manually is also added to and displayed in list C31.

[0049] If a status is specified in field D31, only payment data with the specified status will be displayed. If a specified period is specified in field D32, only payment data whose transaction date falls within the specified period will be displayed. If a source is specified in field D33, only payment data created by the specified source (scanner 4 or manual entry) will be displayed. Approver using the approver terminal 52 selects one of the payment data included in list C31.

[0050] Display area C32 shows the details and status of the payment data selected from list C31. Display area C32 also displays a duplicate button B32, a cancellation application button B33, a return button B34, and an approval button B35. For example, when a payer operates the duplicate button B32, the payment support server 10 generates and displays an editable copy of the selected payment data. By editing the payment date of the generated copy, the payer can easily create payment data for, for example, regularly occurring payments. The payer can also cancel the application for payment data themselves by operating the cancellation application button B33.

[0051] Next, we will explain the operation when the approver displays the display field C32. The approver views the details of the payment data and operates the return button B34 if they do not approve the payment, or the approve button B35 if they approve the payment (Figure 4 (3)). The returned payment data may be displayed back in the payment data list C11 shown in Figure 6, or it may be displayed in the processed tab TB12. When the approver terminal 52 receives an approval operation from the approver (activity A16), it sends approval data to the payment support server 10 indicating the details of the approved payment (payment amount, fee, payment date and recipient, etc.), the payer's account, and that the payment has been approved.

[0052] The payment support server 10 receives the approval data that has been sent and receives a transfer instruction for the payment amount indicated by that approval data (Activity A21). Next, the payment support server 10 calculates the date and time to issue a withdrawal instruction to make the transfer based on the received transfer instruction on the payment date (Figure 4 (4), Activity A22). This withdrawal instruction is an instruction to the First Bank's First Bank Server 41 to withdraw the funds for the payment amount from the payer's account.

[0053] The payment support server 10 calculates the withdrawal instruction date and time based on the payment details indicated by the approval data, for example. Specifically, the payment support server 10 calculates the withdrawal instruction date and time by counting back from the payment date, the number of days required for administrative processing, so that the transfer is completed by the payment date indicated by the approval data. Administrative processing here includes both processing performed by people such as bank employees and processing performed by machines such as the bank server 40. Administrative processing includes administrative processing for withdrawal from the withdrawal account (hereinafter referred to as "first administrative processing"), administrative processing for fund transfer (hereinafter referred to as "second administrative processing"), and administrative processing for transfer (hereinafter referred to as "third administrative processing").

[0054] The first administrative process is performed by the first bank, which has received the withdrawal instruction, in order to withdraw the funds for payment. The second administrative process is performed by the payment collection service provider in order to transfer the withdrawn funds to the second bank. The third administrative process is performed by the second bank in order to transfer the payment amount to the recipient's account. The time required for each administrative process may vary depending on the bank used as the first bank. The "time" referred to here is the period counted in bank business days. The payment support server 10 calculates the instruction date and time using a period table that associates the bank used as the first bank with the time required for each administrative process.

[0055] Figure 10 shows an example of a period table. In Figure 10, a period table TBL11 is shown that associates the first bank with the first, second, and third processing periods. For example, if the first bank is "Bank A", the processing periods are "2 days", "1 day", and "2 days". If the first bank is "Bank B", the processing periods are "1 day", "1 day", and "2 days". If the first bank is "Bank C", the processing periods are "3 days", "1 day", and "2 days".

[0056] The first processing period is the time required for the administrative processing carried out when a withdrawal is made, in accordance with the rules set by each bank (in the example in Figure 10, this is either "1 day" or "3 days"). On the other hand, the second processing period is "1 day" when, for example, funds are directly transferred from the payer's account at the first bank to the payment support service account at the second bank.

[0057] Here, some banks have rules that prevent direct transfer of funds from the payer's account to the payment support service account. In such cases, the funds must first be transferred to another account managed by the bank before being transferred to the payment support service account. This other account could be, for example, the account of the payment collection service provider. In the example in Figure 10, even in the case of a first bank where fund transfers must be made via this other account, the second processing period is "1 day". Note that the second processing period may differ between banks where a transfer via another account is required and banks where direct fund transfers are possible.

[0058] The third processing period is the time required for the transfer from the payment support service account at the second bank to the claimant's account at the third bank. Since the second bank is determined to be the bank that manages the payment support service account in partnership with the payment support service provider, the third processing period is fixed (two days in the example in Figure 10) regardless of which bank the first bank is. This third processing period includes one day of buffer time to ensure that the payment is made on time even in the event of unforeseen circumstances, but it is not required to include a buffer day.

[0059] The payment support server 10 calculates the total processing period by summing the first processing period, the second processing period, and the third processing period, which are associated in the period table TBL11 with the bank that manages the payer's account indicated by the approval data. The payment support server 10 then calculates the specified time as the instructed date and time, which is the date obtained by going back the total processing period from the payment designation date indicated by the approval data.

[0060] For example, if the first bank is Bank A and the designated payment date is Monday, November 25th, the payment support server 10 calculates a total processing period of "5 days," which is the sum of "2 days," "1 day," and "2 days" associated with Bank A, and calculates the specified time (for example, 0:00) on Monday, November 18th, which is 5 business days prior to Monday, November 25th, as the instructed date and time. Similarly, if the first bank is Bank B, the payment support server 10 calculates the specified time on Tuesday, November 19th, which is 4 business days prior to Monday, November 25th (the sum of "1 day," "1 day," and "2 days") as the instructed date and time. Furthermore, if the first bank is Bank C, the payment support server 10 calculates the specified time on Friday, November 15th, which is 6 business days prior to Monday, November 25th (the sum of "3 days," "1 day," and "2 days") as the instructed date and time.

[0061] Next, the payment support server 10 waits until the calculated instruction date and time (Activity A23), and when the instruction date and time arrives, it executes a withdrawal instruction process to issue a withdrawal instruction (Figure 4 (5-1), Activity A24). Specifically, the payment support server 10 generates instruction data that shows the payer's account and the withdrawal amount (total amount of payment amount and fees), which are the information necessary for the withdrawal, and executes the withdrawal instruction process to send it to the collection agency server 20. This withdrawal instruction process is performed, for example, using the withdrawal API (Application Programming Interface) provided by the First Bank.

[0062] When the payment collection server 20 receives the transmitted instruction data, it forwards the instruction data to the first bank server 41 of the bank that manages the payer's account indicated by the instruction data (Figure 4 (5-2), Activity A25). This forwarding is done automatically, so the instruction data reaches the first bank server 41 immediately. When the first bank server 41 receives the transmitted instruction data, it executes a withdrawal process to perform a withdrawal according to the instructions indicated by the received instruction data (Figure 4 (6), Activity A26).

[0063] The details of the withdrawal process vary from bank to bank. For example, in the case of Bank A, the first bank server 41 notifies Bank A's employees of the instructions indicated by the instruction data, and if the employees perform verification work related to the withdrawal and the withdrawal is approved, the server executes the withdrawal process (Figure 4 (7), Activity A31) on the next business day after approval, withdrawing the funds from the payer's account and depositing them into the account of the payment collection service provider (a separate account at Bank A). In this case, the payment collection service provider's account is a separate account at Bank A, different from the payer's account. Bank A's withdrawal process is executed over a period of two days, which is Bank A's first business processing period as shown in Figure 10.

[0064] In the case of Bank B, the first bank server 41 does not notify employees, etc., but on the next business day after receiving the instruction data, it executes a withdrawal process (Figure 4 (7), Activity A31) in which it withdraws funds from the payer's account according to the instructions indicated in the instruction data and deposits those funds into the account of the payment collection service provider (another account of Bank B). The withdrawal process for Bank B is executed over one day, which is the first business processing period for Bank B as shown in Figure 10.

[0065] When the deposit to the other account is completed, the first bank server 41 performs a reporting process for the withdrawal result (Figure 4 (8-1), Activity A32). Specifically, the first bank server 41 performs a reporting process that generates report data showing the payer's account that made the withdrawal, the other account to which the money was deposited (the account of the payment collection service provider), the withdrawal amount (total of payment amount and fees), and the date and time of the withdrawal, and sends it to the payment collection service server 20.

[0066] When the payment collection server 20 receives the report data, it forwards the report data to the payment support server 10 and the worker terminal 53 (Figure 4 (8-2), Activity A33). The processing by the payment support server 10 upon receiving the forwarded report data will be described later. When the worker terminal 53 receives the forwarded report data, it displays the management screen for the other account indicated by the report data (Activity A34).

[0067] Figure 11 shows an example of an account management screen. In Figure 11, system screen G4 is displayed. System screen G4 is displayed, for example, by the payment support server 10 in cooperation with the collection agency server 20. System screen G4 displays a list of withdrawal information C41 related to withdrawn funds, and login buttons B41, B42, and B43 for online banking procedures. List C41 displays the "payer," "other account," "withdrawal amount," "withdrawal date and time," and "total amount" associated with each other. The "total amount" is the sum of the "withdrawal amounts" for "other accounts" at the same bank.

[0068] For example, since payers α and β both have separate accounts at "Bank A," the sum of their withdrawal amounts is displayed as the "Total Amount." Similarly, since payers γ and δ both have separate accounts at "Bank D," the sum of their withdrawal amounts is displayed as the "Total Amount." Only payer ε has a separate account at "Bank F," so payer ε's withdrawal amount is displayed as the "Total Amount." By displaying the total withdrawal amount for the same bank in this way, it becomes easier to confirm the amount of funds being transferred from separate accounts at that bank compared to when the total amount is not displayed.

[0069] Payers α and β are associated with login button B41 for "Bank A". Payers γ and δ are associated with login button B42 for "Bank D", and payer ε is associated with login button B43 for "Bank F". The worker using the worker terminal 53 performs a fund transfer operation to move the payer's funds, which have been deposited into separate accounts at each bank (accounts of the payment collection service provider), to the payment support service account at the second bank.

[0070] When the worker operates the login button B41, the first bank server 41 displays a login screen on the worker terminal 53 for using the online service of Bank A. The worker enters user information on the login screen to log in, and on the displayed service screen, performs an operation to transfer the total amount of payers α and β, which were displayed in list C41, to the account for the payment support service. The worker terminal 53 accepts these operations as a fund transfer operation to move the payer's funds (Figure 4 (9), Activity A35), and sends request data requesting the fund transfer to the first bank server 41.

[0071] When the first bank server 41 receives the transmitted request data, it executes a fund transfer process to transfer the total amount indicated by the request data to the second bank's payment support service account (Figure 4 (10-1), Activity A36). The second bank server 42 executes a deposit process to deposit the funds transferred by the fund transfer process into the payment support service account (Activity A37). In this way, the processes from A31 to A37 are performed to transfer funds via another account at the first bank.

[0072] As mentioned above, some banks used as the first bank (for example, Bank B) can directly transfer funds from the payer's account at the first bank to the payment support service account at the second bank without going through a separate account. Such banks that do not require going through a separate account are mainly financial institutions that provide banking services over the internet (so-called online banks). In that case, the first bank server 41, through the withdrawal process of A26, executes a fund transfer process to transfer the withdrawn funds to the payment support service account instead of A31 (deposit to a separate account) (Figure 4 (10-2), activity A38). The second bank server 42 executes the deposit process to the payment support service account (A37).

[0073] In this way, the processing of A31, A38, and A37 enables a direct transfer of funds without going through another account. In this case as well, the first bank server 41 performs a reporting process in A32. If the payer's account does not have the funds for the withdrawal amount, the withdrawal will fail. In that case, the first bank server 41 performs a reporting process that generates and sends report data indicating that the withdrawal failed.

[0074] After receiving report data from the collection agency server 20, the payment support server 10 waits until the second processing period has elapsed if the report data indicates a successful withdrawal (Activity A41). In the example in Figure 10, since the second processing period is "1 day" for all banks, the payment support server 10 waits until 1 day has elapsed since the successful withdrawal was reported. Once the second processing period has elapsed, the payment support server 10 executes a transfer instruction process (a so-called remittance message instruction) to generate instruction data instructing the transfer of the withdrawn funds, i.e., the payment amount, and send it to the second bank server 42 (Figure 4 (11), Activity A42). This transfer instruction process is performed, for example, using a transfer API provided by the second bank.

[0075] When the second bank server 42 receives the instruction data, in the example in Figure 5, it executes a transfer process for the payment amount to the recipient account (the third bank account) indicated by the instruction data on the next business day after the day it was received (Figure 4 (12), Activity A43). The third bank server 43 then executes a deposit process to deposit the funds of the payment amount that have been transferred into the claimant's account (Figure 4 (13), Activity A44). In this way, on the payment date, the approved payment amount is transferred to the claimant's account.

[0076] The above-mentioned series of processes will be explained using actual dates as an example. If the designated payment date at Bank A is November 25th (Monday), then, as described above, November 18th (Monday) is calculated as the designated date and time for the withdrawal instruction. When the withdrawal instruction process is executed by the payment support server 10 on November 18th (Monday) (Figure 4 (5-1)), the instruction data is transferred by the collection agency server 20 on the same November 18th (Monday) (Figure 4 (5-2)). Then, after the "two days" of the first processing period have elapsed, on November 20th (Wednesday), the withdrawal process and deposit into the other account are performed by the first bank server 41 (Figure 4 (6), (7)).

[0077] On November 21st (Thursday), one day after the withdrawal, the first bank server 41 reports the withdrawal result (Figure 4 (8-1), (8-2)), the worker terminal 53 accepts the fund transfer operation (Figure 4 (9)), and the first bank server 41 processes the fund transfer (Figure 4 (10-1)). On the next business day, November 22nd (Friday), the payment support server 10 issues a transfer instruction (Figure 4 (11)), and on November 25th (Monday), two days after the fund transfer, the second bank server 42 processes the transfer (Figure 4 (12)).

[0078] As mentioned above, the "two days" of the third processing period include a buffer day. Therefore, for example, even if the fund transfer process is delayed by one day for some reason and carried out on November 22nd (Friday), the transfer instruction by the payment support server 10 may be issued on November 25th (Monday), and the transfer processing by the second bank server 42 may be carried out on the same day. Since the transfer instruction by the payment support server 10 is made online, the transfer instruction and the transfer processing can be carried out on the same day.

[0079] Next, we will explain the case of Bank B, where fund transfers can be made without going through a separate account. In Bank B, if the designated payment date is November 25th (Monday), as described above, November 19th (Tuesday) is calculated as the designated date and time for the withdrawal instruction. In Bank B, when the withdrawal instruction processing is executed by the payment support server 10 on November 19th (Tuesday) (Figure 4 (5-1)), the instruction data is transferred by the collection agency server 20 on the same November 19th (Tuesday) (Figure 4 (5-2)). After the "1 day" of the first administrative processing period has elapsed, on November 20th (Wednesday), the withdrawal processing and fund transfer processing to the account for the payment support service are performed by the first bank server 41 (Figure 4 (6), (10-2)). After the fund transfer, processing is carried out according to the same schedule as in the case of Bank A, and on November 25th (Monday), the transfer processing is performed by the second bank server 42 (Figure 4 (12)).

[0080] As described above, the payment support server 10 functions as an example of a receiving unit that receives transfer instructions from a user. Activity A21 is an example of a step that receives a transfer instruction. The transfer instruction includes the payment amount, the payer's account, and the recipient's account, as indicated by the approval data, i.e., the transfer amount, the withdrawal account, and the recipient's account. The withdrawal account is an account that can be instructed to withdraw online by sending instruction data to the First Bank server 41, as described above for the First Bank.

[0081] The payment support server 10 functions as an example of a withdrawal instruction unit that instructs the withdrawal of funds for the transfer amount indicated in the received transfer instruction, based on the received transfer instruction. Specifically, the payment support server 10 executes a withdrawal instruction process to instruct online that funds for the transfer amount be withdrawn from the withdrawal account in order to move them to a predetermined intermediary account. Activity A24 is an example of a withdrawal instruction step. The intermediary account is, for example, the account for the payment support service of the second bank mentioned above, and is an account for which online transfer instructions can be sent by transmitting instruction data to the second bank server 42.

[0082] The withdrawn funds are moved to the intermediary account via another account at the first bank using the fund transfer process A36, or they are moved directly to the intermediary account without going through another account using the fund transfer process A38. The payment support server 10 then functions as an example of a transfer instruction unit that instructs the transfer to the recipient account. Specifically, the payment support server 10 executes a transfer instruction process to instruct online the transfer of the funds moved to the intermediary account to the recipient account. Activity A42 is an example of a transfer instruction step.

[0083] Withdrawals from a bank account require the recipient of the funds to be withdrawn to be registered in advance. Therefore, when acting as an agent for payments to various payees, it is difficult to use the payee's account as the transfer destination, so it is necessary to move the funds to a specific account before initiating the transfer. The transfer procedure after the fund transfer is also time-consuming when performed manually, as it involves transferring funds to various payee accounts in various amounts, including verification work. In Payment Support System 1, upon receiving a transfer instruction, both the withdrawal and transfer of funds are performed online from the Payment Support Server 10 without human intervention (withdrawal instruction to the first bank server 41 via the collection agency server 20 and transfer instruction to the second bank server 42), thus reducing the effort involved in transfers when the transfer process is performed manually.

[0084] Furthermore, the transfer instructions received from the user include the transfer deadline, which is the deadline for the transfer. The payment designation date is an example of a transfer deadline. The payment support server 10 (an example of a withdrawal instruction unit) executes the withdrawal instruction process so that the withdrawal instruction from the withdrawal account reaches the financial institution (First Bank) managing that withdrawal account a predetermined number of days before the transfer deadline. The predetermined number of days is the sum of the first processing period, the second processing period, and the third processing period shown in Figure 10, and is the number of days corresponding to the financial institution (First Bank) managing the withdrawal account.

[0085] The prescribed number of days is, for example, 5 days (2 days + 1 day + 2 days) for Bank A, 4 days (1 day + 1 day + 2 days) for Bank B, and 6 days (3 days + 1 day + 2 days) for Bank C. With this arrangement, payments can be made closer to the transfer deadline compared to when the prescribed number of days is the same for all banks. In addition, by setting the prescribed number of days to allow for processing time, the transfer deadline is more likely to be observed compared to when processing time is not taken into consideration.

[0086] Here, the business providing the payment support service is assumed to be qualified as a Type 1 money transfer business. In this case, the business is regulated to only be able to hold funds for the maximum number of days necessary for processing. Therefore, increasing the number of days would reduce the likelihood of transfer delays, but this would exceed the limit on the period of fund retention. Thus, in Payment Support System 1, the specified number of days is the maximum number of days necessary for processing from the time the instruction to withdraw funds reaches the financial institution (First Bank) managing the withdrawal account until the funds are transferred to the recipient account. This configuration allows for both the suppression of transfer delays and the suppression of fund retention compared to setting the specified number of days to be less or more than this.

[0087] Furthermore, the payment support server 10 functions as an example of an amount display unit that displays the amount of funds to be transferred to the worker terminal 53. Activity A33 is an example of an amount display step. The worker terminal 53 is a terminal used by a worker who performs a transfer from another account to an intermediary account when the financial institution (First Bank) that manages the withdrawal account requires that the funds be transferred via another account at that financial institution. The account of the collection agency service provider at First Bank is an example of another account, and the account for payment support services at Second Bank is an example of an intermediary account.

[0088] In the above case, the payment support server 10 displays the amount of the withdrawn funds (withdrawal amount) on the worker terminal 53 after the withdrawn funds have been transferred to another account. The system screen G4, which includes the list of withdrawal information C41 shown in Figure 11, is an example of the displayed withdrawal amount. With this configuration, the discrepancy in the amount of funds transferred from the other account to the intermediary account can be reduced compared to when the withdrawal amount is not displayed. Note that since the intermediary account (account for payment support services) is fixed, there is no need to worry about transferring funds to the wrong destination even if it is not displayed.

[0089] Furthermore, the user's payment instruction mentioned above is an instruction for payment of the invoice issued in the transaction. In this case, the payment support server 10 functions as an example of an invoice display unit that displays invoice information, including the string read from the issued invoice, along with an appearance image showing the appearance of the invoice. Activity A13 is an example of an invoice display step.

[0090] Specifically, the payment support server 10 displays, for example, scanned images of invoices stored in the data management server 30 (an example of an appearance image) and billing information read from the scanned images on the payer terminal 51 and the approver terminal 52. The payment data list C11 shown in Figure 6 is an example of billing information, and the invoice image C21 shown in Figure 7 is an example of an appearance image. Note that the appearance image is not limited to scanned images of paper invoices, but may also be data representing an image of an invoice that was generated as data from the beginning.

[0091] The displayed billing information includes the billing amount. The payment amount included in the payment data list C11 is an example of a billing amount. The payment support server 10 (an example of a receiving unit) receives a transfer instruction with the billing amount indicated by the selected billing information from the displayed billing information as the transfer amount. Specifically, when the payment application selected from the payment data list C11 is approved, the payment support server 10 receives a transfer instruction with the requested payment amount (billing amount) as the transfer amount.

[0092] Compared to the payer manually entering all billing information after reviewing the received invoice, displaying billing information read from the invoice's appearance image, as described above, and allowing it to be selected as a payment target, reduces the effort required to enter billing information such as the transfer amount. Furthermore, displaying the appearance image along with the billing information makes it easier to verify whether the displayed billing information is correct, compared to when the appearance image is not displayed.

[0093] Furthermore, the billing information read from the invoice includes the payment due date. When the payment support server 10 receives an operation to duplicate billing information, it functions as an example of a duplicate display unit that displays billing information with the same billing amount as the original billing information, with an editable payment due date. The editable duplicate of payment data displayed when the duplicate button B32 shown in Figure 9 is operated is an example of billing information with the same billing amount as the original billing information, and activity A15 is an example of a duplicate display step.

[0094] Furthermore, the payment support server 10 (an example of a withdrawal instruction unit) executes withdrawal instruction processing so that the withdrawal instruction from the withdrawal account reaches the financial institution (First Bank) managing the withdrawal account a predetermined number of days before the edited payment due date. This configuration reduces the effort required to make payments for recurring invoices compared to a system where an editable copy of the invoice information is not displayed.

[0095] <Example: Automatic fund transfer> In the example above, the financial institution managing the withdrawal account (the First Bank) requires that the funds be transferred via another account within that institution. In this case, a worker performed the transfer of funds from the First Bank's other account to the Second Bank's intermediary account. However, this fund transfer could also be performed automatically, just like withdrawals and bank transfers. This is based on the premise that the other account can be instructed to make a transfer online.

[0096] In this case, the payment support server 10 functions as an example of a transfer instruction unit that online instructs the transfer of funds from another account to an intermediary account. After the withdrawn funds have been transferred to another account, the payment support server 10 online instructs the transfer of those funds from the other account to the intermediary account. Specifically, when the payment support server 10 receives report data in A33 indicating that the withdrawal was successful and the funds have been deposited into the other account, it generates instruction data to instruct the transfer of the funds deposited into the other account from the other account to the intermediary account and sends it to the First Bank Server 41, thereby performing the above instruction online. This transfer instruction process is performed, for example, using a transfer API provided by the First Bank. With this configuration, manual intervention can be eliminated when moving funds from another account to an intermediary account.

[0097] <Example: Correction process when payment fails> The above transfer may fail, for example, if the recipient's account information is entered incorrectly or if there are insufficient funds in the withdrawal account. In the former case, the second bank server 42 notifies the payment support server 10 that the transfer process has failed. In the latter case, the first bank server 41 notifies the payment support server 10 that the withdrawal has failed by sending the report data described in Figure 5 via the collection agency server 20.

[0098] When the payment support server 10 is notified that a transfer to the recipient's account has failed, it functions as an example of a correction display unit that displays a correction screen on the user terminal (payer terminal 51) of the user who issued the transfer instruction, allowing the user to request a correction of the recipient's account.

[0099] Figure 12 shows an example of a correction screen. In Figure 12, the system screen G5 of the payment support system 1 is displayed. The system screen G5 is displayed, for example, by the payment support server 10 in cooperation with the data management server 30. The system screen G5 displays an invoice image C51, a payment data input field D51, and a transfer instruction button B51. The invoice image C51 is an image of the invoice for which a transfer failure has been notified. The invoice image C51 shows the recipient, invoice date, invoicer, payment due date, transfer destination account, and invoice amount.

[0100] Input field D51 is an area for entering information indicating payment data. In the example in Figure 12, similar to the example in Figure 7, it includes areas for entering "Transaction Date," "Customer Name," "Payment Amount," "Payment Due Date," and "Bank Account for Transfer." The payer looks at the displayed invoice image C51 and corrects any errors in the invoice amount or bank account for transfer (insufficient funds may indicate an error in the invoice amount). Once the corrections are complete, the payer operates the transfer instruction button B51.

[0101] When the transfer instruction button B51 is pressed, the payment support server 10 (an example of a transfer instruction unit) executes a re-transfer instruction process to instruct online the transfer of funds to the recipient account corrected on the correction screen. Specifically, the payment support server 10 executes a re-transfer instruction process that generates instruction data instructing the transfer of the payment amount to the corrected recipient account and sends it to the second bank server 42. Upon receiving the instruction data, the second bank server 42 executes the transfer process for the payment amount to the corrected recipient account indicated by the instruction data. With this configuration, compared to when the correction screen is not displayed, re-transfers can be performed more smoothly when a transfer fails.

[0102] <Example: Securing withdrawn funds> As mentioned above, providers of payment support services are qualified as Type 1 money transfer businesses, but they have an obligation to protect the funds from the time the payer's funds are withdrawn from their account until they are transferred to the recipient's account. Methods of protecting funds include, for example, deposit and trust, but both require the provider's own funds. When using a bank guarantee, there is no cash outflow for protection, but a cost is incurred to pay the bank a certain percentage of the protected amount. As the number of users of payment support services increases, this cost becomes enormous.

[0103] Here, the second bank temporarily holds funds in an intermediary account (an account for payment support services), and since these funds serve as collateral, it is possible to reduce the guarantee risk of the protected funds, and therefore keep guarantee fees low. In addition, although the large-scale credit regulation limits the amount that a single bank can guarantee to a certain percentage of its capital (currently 25%), it is possible to exempt the second bank from the large-scale credit regulation by using the funds held in the intermediary account as collateral.

[0104] For the reasons stated above, when a provider of payment support services uses the guarantee service of the second bank, the second bank needs to know the amount that needs to be protected. Therefore, the second bank server 42 calculates the amount of funds to be protected. This process of calculating the amount to be protected is an example of a calculation step executed by the second bank server 42 as an example of a calculation unit. The second bank server 42 calculates the amount of funds to be protected based on the balance in the intermediary account, for example. Specifically, the second bank server 42 calculates the amount of funds to be protected using the balance in the intermediary account as is.

[0105] However, the method for calculating the amount subject to protection is not limited to this. The second bank server 42 may, for example, calculate the amount subject to protection as the amount obtained by adding or subtracting a predetermined amount from the balance of the intermediary account. Alternatively, the second bank server 42 may calculate the amount subject to protection as the amount obtained by multiplying the balance of the intermediary account by a predetermined percentage. These calculations are used, for example, when calculating a larger amount subject to protection to enhance security, or when calculating a smaller amount subject to protection to take on more risk. They may also be used depending on the terms and conditions of the fund protection service provided by the second bank (such as setting a minimum guaranteed amount).

[0106] Furthermore, the second bank server 42 may calculate the amount to be protected based on the deposit and withdrawal history of the intermediary account, rather than the balance of the intermediary account. More specifically, the second bank server 42 may calculate the amount to be protected as the amount obtained by subtracting the total amount of funds transferred to the recipient account (funds withdrawn from the intermediary account) from the total amount of funds withdrawn from the withdrawal account (funds deposited into the intermediary account) by withdrawal instruction processing. Alternatively, the second bank server 42 may calculate the amount to be protected as the amount obtained by adding or subtracting a predetermined amount or multiplying the amount calculated in this way based on the deposit and withdrawal history by a predetermined percentage.

[0107] The second bank server 42 functions as an example of a processing unit that performs processing related to the protection of funds (hereinafter referred to as "protection-related processing") based on the calculated amount of funds to be protected. For example, the second bank server 42 generates protection data showing the daily history of the calculated amount of funds to be protected and performs the process of accumulating the generated protection data as protection-related processing. For example, if a fee based on the total amount of funds to be protected is stipulated between the second bank and the payment support service provider, the second bank server 42 calculates the fee based on the amount of funds to be protected indicated by the accumulated protection data.

[0108] In the example above, the second bank server 42 generated the security data and calculated the fees, but the payment support server 10 may also perform these processes. In that case, the payment support server 10 would, for example, obtain deposit and withdrawal information for the intermediary account from the second bank server 42 as needed, and calculate the difference between the total amount of deposits shown in the obtained deposit history and the total amount of withdrawals shown in the withdrawal history as the amount to be secured. The payment support server 10 would then, for example, execute a process to notify the second bank server 42 of the calculated amount to be secured as a security-related process, and further execute a process to calculate the fees as a security-related process.

[0109] In this configuration, when obtaining a favorable guarantee using the funds in the intermediary account as collateral, as described above, operations related to the safeguarding of funds can be carried out more smoothly compared to when no safeguarding procedures are performed.

[0110] <Variations: Other implementations> In the example above, the payment support server 10 issued a withdrawal instruction to the first bank server 41 via the collection agency server 20. However, if the payment support service provider also provides collection agency services, the payment support server 10 may issue a withdrawal instruction directly to the first bank server 41. In that case, the first bank server 41 will also report the withdrawal result directly to the payment support server 10 without going through the collection agency server 20.

[0111] Furthermore, while the number of days expected when processing a direct debit instruction was previously determined by the financial institution, it may be set to a uniform number of days regardless of the financial institution, for example, if it is possible to clear regulations regarding the retention of funds. In that case as well, it is desirable that the number of days be sufficient to ensure that each bank has enough time for processing each transaction, so that the transfer deadline is more likely to be met.

[0112] Furthermore, in the example above, the funds were transferred to the intermediary account via direct debit, but the user may also perform the task of transferring the funds to the intermediary account. Figure 13 shows another example of the overall flow of the payment support process. Figure 13 shows a payment support system 1a without a collection agency server 20. In the example in Figure 13, the processes and operations shown in (1) to (3) in Figure 4 are performed and the payment is approved.

[0113] Once the payment is approved, the payer performs a transfer operation on the payer terminal 51, for example, using the internet banking service of the first bank, to transfer the payment amount from their own account at the first bank (the account corresponding to the withdrawal account in the example above) to the intermediary account at the second bank (the account for payment support services) (Figure 13 (4)). Based on the payer's transfer operation, the first bank server 41 executes a transfer process as a fund transfer process to transfer the payment amount from the payer's account to the intermediary account (Figure 13 (10-3)).

[0114] When the first bank server 41 executes the transfer process, the second bank server 42 executes the deposit process. Once the deposit process is complete, the second bank server 42 reports the transfer result by sending transfer result data to the payment support server 10 indicating that the transfer process has been completed and the transfer amount (Figure 13 (8-3)). After the payer has made the transfer to the intermediary account, the payer makes a transfer instruction operation to the payer terminal 51 instructing it to transfer the payment amount to the claimant's account (recipient account) (Figure 13 (5)). The payer terminal 51 generates instruction data indicating the recipient account, the payment amount, and the transfer instruction, and sends it to the payment support server 10.

[0115] When the payment support server 10 receives instruction data, it immediately executes a transfer instruction process (a so-called remittance message instruction) to send instruction data to the second bank server 42, either immediately if it has received a transfer result report, or after waiting until it has received one if it has not received a transfer result report (Figure 13 (11)). The second bank server 42 then executes a transfer process to the recipient account indicated by the instruction data (Figure 13 (12)).

[0116] As described above, in the example in Figure 13, the payment support server 10 (an example of the receiving unit) first receives a transfer instruction from the user. This transfer instruction includes the transfer amount and the recipient account (a withdrawal account is not required). In this case, the user is one who moves funds from their own account to the intermediary account. The payment support server 10 (an example of the transfer instruction unit) then executes a transfer instruction process to instruct online that the funds moved to the intermediary account be transferred to the recipient account. In this way, even in the example in Figure 13, since the transfer from the intermediary account to the recipient account is performed by online instruction, the effort involved in transfers in a transfer agency can be reduced compared to when the transfer work is performed manually.

[0117] Furthermore, even in the example shown in Figure 13, the provider of the payment support service has an obligation to protect the payer's funds. Therefore, the payment support server 10 may perform the above-mentioned protection processing. Specifically, the payment support server 10 (an example of a calculation unit) calculates the amount of funds to be protected by subtracting the total amount of funds transferred to the recipient account from the total amount of funds moved to the intermediary account by the user's transfer operation (the funds of the transfer amount indicated in the transfer result report). Then, the payment support server 10 (an example of a processing unit) performs the protection processing based on the calculated protection amount. In addition, similar to the example above, the second bank server 42 may notify the payment support server 10 of the completion of the transfer. Even in this embodiment, the operations related to fund protection can be performed more smoothly than when the protection-related processing is not performed.

[0118] As described above, the payment support service is based on the premise of using a transfer agency that makes transfers based on instructions from the user. The payment support server 10 (an example of the receiving unit) receives a transfer instruction from the user, which includes the transfer amount and the recipient account. The payment support server 10 (an example of the transfer instruction unit) also issues a transfer instruction to the management system of the intermediary account, which is capable of online transfer instructions, to execute the transfer of funds to the recipient account when funds for paying the transfer amount are moved from the user's account to the intermediary account. The second bank server 42 is an example of a management system that manages intermediary accounts.

[0119] Furthermore, the second bank server 42 or payment support server 10 (an example of a calculation unit) calculates the amount of funds subject to protection based on the balance in the intermediary account or the deposit and withdrawal history of the intermediary account. Specifically, the second bank server 42 or payment support server 10 calculates the amount of funds subject to protection as an amount corresponding to the balance of the intermediary account (the balance itself or an amount obtained by increasing or decreasing the balance as necessary). In addition, the second bank server 42 or payment support server 10 calculates the amount of funds subject to protection as an amount corresponding to the difference between the total amount of funds deposited into the intermediary account and the total amount of funds withdrawn from the intermediary account (the difference in the total amounts or an amount obtained by increasing or decreasing that difference as necessary).

[0120] Then, the second bank server 42 or payment support server 10 (an example of a processing unit) executes security-related processing based on the calculated amount of funds to be secured. As mentioned above, various methods can be used to calculate the amount of funds to be secured, but in short, any calculation method is acceptable as long as the security of funds is carried out smoothly.

[0121] Furthermore, in the example shown in Figure 4, for instance, the transfer instruction also includes a withdrawal account that can be withdrawn online. The payment support server 10 (an example of a withdrawal instruction unit) then executes a withdrawal instruction process to instruct the server to withdraw the funds indicated by the received transfer instruction from the withdrawal account in order to move them to the intermediary account. This configuration reduces the effort required of the user in the transfer process compared to when the withdrawal instruction process is not performed.

[0122] Furthermore, in the example shown in Figure 13, the payment support server 10 (an example of a withdrawal instruction unit) issues a transfer instruction for funds that the user has moved from their own account to an intermediary account. With this configuration, even users who have not registered for withdrawals, such as users using the payment support system 1 for the first time, users who have just started using it, or users who have not registered for withdrawals for some reason, can receive a transfer instruction.

[0123] <Variation: Security Account> In the example shown in Figure 4, the funds were transferred directly from the intermediary account (the second bank's payment support service account) where the transferred funds were stored. However, if, for example, funds are secured, the intermediary account may include both a security account and a transfer account. The overall flow of the payment support process in that case will be explained with reference to Figure 14.

[0124] Figure 14 shows an example of the overall flow of payment support processing. In the example in Figure 14, a security account and a transfer account are opened as accounts for the payment support service of the second bank. For example, the security account is an account in the name of the second bank, and the transfer account is an account in the name of the payment support service provider. The reason for these names is that the second bank is responsible for the security of the funds, and the payment support service provider is responsible for the transfer service. In the example in Figure 14, the user's funds are moved from the first bank account to the security account through fund transfer processing (10-1) and (10-2) by the first bank server 41.

[0125] The second bank server 42 executes a deposit process to deposit the transferred funds into the security account (12). The second bank server 42 provided by the payment support system 1 is, as mentioned above, an example of a management system for managing intermediary accounts. When the second bank server 42 receives a transfer instruction sent from the payment support server 10 in (11), it executes a transfer process to move the funds transferred to the security account to the transfer account (13). Then, the second bank server 42 executes a transfer of the funds transferred to the transfer account to the recipient account (14). The third bank server 43 executes a deposit process for the transferred funds (15).

[0126] If there is only one intermediary account, for example, a single processing error could result in the wrong funds being transferred. Specifically, for example, the same transfer could be processed twice, resulting in a double transfer. In contrast to that case, with the above configuration, even if an error occurs when moving funds from the safekeeping account to the transfer account, the funds are still only moving to the transfer account. By detecting the error and stopping the transfer from the transfer account, it is possible to return the wrongly moved funds to the safekeeping account, thus ensuring the safekeeping funds are secured more safely.

[0127] <Variation example: AI agent> In Payment Support System 1, various financial institution accounts may be used as the payer's withdrawal account. In other words, the source accounts of funds transferred to the intermediary account include accounts from two or more financial institutions. However, regardless of which financial institution's account is used, the transfer is always made from the intermediary account, so payment information from payers using different financial institutions is aggregated. An AI agent that has learned from such aggregated payment information may be utilized.

[0128] An AI agent is an artificial intelligence module that uses AI (Artificial Intelligence) technology to learn to make autonomous decisions and execute processes according to specific purposes. An AI module is a component that implements machine learning and inference as a specific processing unit, and operates independently within a system, working in cooperation with other modules to achieve advanced processing. The AI ​​agent collects and analyzes information in response to user instructions and changes in the environment, and takes the optimal action.

[0129] Figure 15 shows another example of the overall configuration of payment support system 1. In the example in Figure 15, payment support server 10 is equipped with AI agent 60. AI agent 60 has the function of processing based on payment information indicating the payment of a transaction. The processing performed by AI agent 60 based on payment information will be referred to as "AI processing" below. AI processing may include various processes, which will be explained in detail later.

[0130] The payment support server 10 inputs the transfer history from the intermediary account to the recipient account as payment information to the AI ​​agent 60. The AI ​​agent 60 performs AI processing based on the input payment information. The payment support server 10 outputs the results of the AI ​​processing based on the output of the AI ​​agent 60. This output process of the AI ​​processing results is an example of an AI processing step and is executed by the payment support server 10 as an example of an AI processing unit.

[0131] <Modified example: Fraudulent transaction detection> Let's explain a specific example of AI processing. For example, AI agent 60 learns the characteristics of payments that represent fraudulent transactions and performs AI processing to detect potentially fraudulent transactions. Fraudulent transactions include, for example, double billing, amount falsification, inflated billing, transactions at unnatural timings, transactions with dummy companies or shell companies, fraudulent discounts, fraudulent preferential transactions, impersonation of account information, internal fraud by employees, and transaction splitting.

[0132] In this case, the payment support server 10 (an example of a processing unit) outputs a fraud detection result indicating a potentially fraudulent transaction as the result of AI processing, based on the output of the AI ​​agent. The "fraud detection result" is represented, for example, by a score value (a value corresponding to the degree of fraud) or label information (content corresponding to the degree of fraud) assigned to the transaction. The payment support server 10 may, for example, notify the user that there is a possibility of a fraudulent transaction by outputting and displaying the fraud detection result output by the AI ​​agent 60 to the user terminal 50. Based on the notified fraud detection result, the user can take actions such as withholding approval or instructing reconfirmation for transactions that have been determined to be potentially fraudulent.

[0133] In this configuration, fraudulent transactions can be detected more easily than when AI processing is not performed. In particular, in the payment support system 1, as described above, payment information from payers of different financial institutions is aggregated, so the AI ​​agent 60 can learn a wider variety of transactions compared to when it is based only on payment information from a single financial institution, thereby improving the practicality of AI processing.

[0134] <Variation Example: Proposed Method for Asset Utilization> Furthermore, AI agent 60 learns how to utilize assets according to payment status and performs AI processing to create asset utilization suggestions for the user. Since payment information includes transaction history and spending patterns, AI agent 60 can learn from this and analyze asset utilization methods that are suitable for the user.

[0135] For example, AI Agent 60 can use payment information to create suggestions for automatic contributions to an expenditure leveling fund (a short-term investment fund designed to prepare for peak expenditure periods) for users who show a concentration of outsourcing expenses at the end and beginning of the month. Similarly, AI Agent 60 can use payment information to create suggestions for lease agreement models or leaseback asset management for users who show large capital investments every few months. AI Agent 60 generates suggestion data, including text, images, audio, and video, to represent these suggestions.

[0136] The payment support server 10 (an example of an AI processing unit) outputs suggestions for how to utilize the user's assets based on the output of the AI ​​agent when the user's transfer history is input as payment information, as a result of AI processing. For example, the payment support server 10 suggests how to utilize the user's assets by outputting and displaying the suggestion data created by the AI ​​agent 60 to the user terminal 50. This configuration can support the user in utilizing their assets (such as stabilizing cash flow and improving future creditworthiness).

[0137] <Variation example: Support for improving creditworthiness> Furthermore, AI Agent 60 learns the creditworthiness evaluation criteria used by financial institutions and executes AI processing to create action plans to improve the user's creditworthiness. User creditworthiness refers to indicators of reliability and ability to pay that financial institutions and third parties such as business partners use when deciding whether to "lend money based on trust" and "continue transactions" with a user (individual or corporation). Since payment information includes transaction history and spending patterns, AI Agent 60 can learn from this information and analyze appropriate measures (action plans) to improve the user's creditworthiness.

[0138] AI Agent 60 creates action plans to improve creditworthiness by analyzing payment information, for example, the status of compliance with payment due dates, trends in balance fluctuations, and the concentration of transactions with different trading partners and on specific payment / withdrawal dates. These action plans may include recommendations for automatic payment registration, maintaining balances at the end of each month, suggesting spending plans spread across multiple days, diversifying trading partners, proposing regular monthly payments of a certain percentage of sales, conducting short-term, small-amount credit transactions, and making early repayments on small loans. AI Agent 60 creates action plan data, including text, images, audio, and video, to represent these action plans.

[0139] The payment support server 10 (an example of an AI processing unit) outputs an action plan to improve the user's creditworthiness based on the output of the AI ​​agent when the user's transfer history is input as payment information. The payment support server 10 presents the user with an action plan to improve their creditworthiness by, for example, outputting and displaying the action plan data created by the AI ​​agent 60 to the user terminal 50. This configuration can help improve the user's creditworthiness at financial institutions.

[0140] <Example: Payment schedule based on billing information> Furthermore, AI agent 60 learns how to generate payment schedules based on billing information, including the billing amount and payment deadline, and executes the process of creating a payment schedule suitable for the user as an AI process. A payment schedule is planning information that shows "when, how much, and where" to pay for future invoices. By creating a payment schedule, it is possible to organize the appropriate timing, amount, and recipient in advance, taking into account cash flow and payment deadlines. Since billing information includes the billing amount, recipient account, and payment deadline, AI agent 60 learns this information and creates an optimal payment schedule that is tailored to the user's payment characteristics and financial situation.

[0141] The payment support server 10 accepts the user's designation of the invoice to be paid in the payment agency service. This process of accepting the designation of the invoice to be paid is an example of a reception step executed by the payment support server 10 as an example of a reception unit. For example, the payment support server 10 displays a designation screen on the user terminal 50 for specifying the invoice to be paid.

[0142] Figure 16 shows an example of a selection screen. The selection screen G6 in Figure 16 displays the text "Please select the invoices to be paid for in the payment agency service," along with the invoice list C61, the total amount G62, and the create button B61. The invoice list C61 is a list of invoice information received by the user and stored in the management database 5 shown in Figure 4. The invoice list C61 displays information such as a check box, transaction date, customer name, payment amount, payment due date, and bank account details. The check box is for checking the invoices to be designated as payment targets.

[0143] The total amount G62 is the sum of the invoice amounts of the invoices checked in the invoice list C61. The user looks at the invoice list C61, checks the invoices to be paid by the payment agency service while looking at the total amount, and when all are selected, operates the create button B61. When the create button B61 is operated, the payment support server 10 creates a payment schedule for the specified invoices.

[0144] In detail, the payment support server 10 inputs billing information for the specified invoice to the AI ​​agent 60, and based on the output of the AI ​​agent 60, outputs a payment schedule for the specified invoice as the result of AI processing. The payment support server 10 presents the payment schedule for the specified invoice to the user by, for example, outputting and displaying a payment schedule screen representing the above payment schedule to the user terminal 50.

[0145] Figure 17 shows an example of a displayed payment schedule screen. In the payment schedule screen G7 shown in Figure 17, the text "Payment schedule created." is displayed, along with a graph image D71, a payment amount image E71, a cumulative amount image E72, and the payment target E73. Graph image D71 is a bar graph with the date on the horizontal axis and the payment amount (in 10,000 yen) on the vertical axis. Payment amount image E71 is a bar image representing the payment amount on the scheduled payment date. Cumulative amount image E72 is a bar image representing the cumulative value of the payment amount.

[0146] The payment target E73 indicates the payment type shown in each payment amount image E71 (e.g., "Payment for Company A" and "Payment to Company B"), allowing users to visually confirm the details of the relevant payment. This display allows users to grasp at a glance the concentration of payments scheduled during a specific period and the increasing trend of cumulative payments. This configuration allows users to clearly see their future payment schedules, making it easier to plan and prioritize their finances. It also provides useful information for taking measures against peaks and imbalances in payment amounts (e.g., diversifying spending, coordinating with payees), thereby supporting users in making appropriate payments.

[0147] <Example: Payment plan tailored to asset status> Furthermore, the AI ​​agent 60 learns how to generate payment plans according to the user's financial situation and executes the process of generating a payment plan with a suitable payment timing as an AI process. For example, by learning a dataset of financial situations and optimal payment plans as training data, the AI ​​agent 60 can generate a realistic and flexible payment schedule that suits the user's financial situation.

[0148] The payment support server 10 obtains financial information that shows the user's financial status. This financial information includes, for example, the current account balance, monthly income, planned withdrawals, regular deposits and expenditures, and projected cash flow. The payment support server 10 obtains this financial information, for example, through the API or budget management system of the financial institution used by the user.

[0149] Furthermore, the payment support server 10 acquires billing information, including the billing amount and payment deadline. The payment support server 10 acquires billing information indicated by the read billing details, for example, by reading the billing details from scanned images of invoices stored in the data management server 30. This process of acquiring fund information and billing information is an example of an acquisition step executed by the payment support server 10 as an example of an acquisition unit.

[0150] The payment support server 10 (an example of a processing unit) then inputs the acquired fund information and billing information to the AI ​​agent 60, and based on the output of the AI ​​agent 60, outputs a recommended payment plan to the user as the result of AI processing. The payment support server 10 presents the recommended payment plan to the user, for example, by outputting and displaying a payment plan screen representing the generated payment plan to the user terminal 50.

[0151] Figure 18 shows an example of a displayed payment plan screen. The payment plan screen G8 in Figure 18 displays the text "Payment plan created," along with a graph image D81, a payment amount image E81, a funds image E82, and a deposit / withdrawal image E83. Graph image D81 is a bar graph with the date on the horizontal axis and the deposit / withdrawal amount (in 10,000 yen) on the vertical axis. Payment amount image E81 is a bar image representing the payment amount on the planned payment date.

[0152] The fund image E82 is a bar image representing the amount of funds held by the user at the time a deposit or withdrawal occurs. The arrow E84 visually indicates the occurrence of a deposit or withdrawal and is displayed superimposed above or below the bar image for each date. Deposits are represented by an arrow E84 pointing in the direction of increase in the bar graph, and withdrawals by an arrow E84 pointing in the direction of decrease, allowing the user to instantly grasp the timing of fund flows.

[0153] The graph image D81 shown in Figure 18 provides an integrated visualization of the user's payment schedule and deposit / withdrawal status. The payment amount image E81 and the funds image E82 display the payment and fund levels for each date in correspondence, allowing the user to visually grasp their daily cash flow. Furthermore, the deposit / withdrawal image E83 represents deposit or withdrawal events occurring on a specific date as identifiable labels. The deposit / withdrawal image E83 displays details of deposits and withdrawals such as "Payment for A," "Deposit from Company G," and "Payment to Company B," indicating the payee, source of deposit, and payment details.

[0154] The payment support server 10 displays the payment plan screen G8, allowing users to create a manageable payment schedule while ensuring sufficient funds are available, taking into account future income and expenditure plans. In particular, the fund image E82 clearly shows the balance level after payment and the fluctuations in funds before and after deposits, enabling the creation of plans that reduce cash flow risks.

[0155] As described above, generating a payment plan based on asset information makes it possible to support manageable payments tailored to the user's financial situation, thereby stabilizing cash flow and reducing the risk of default. The generated payment plan may also be configured so that the user can check the payment schedule on the screen and make modifications as needed. This allows for flexible use of the AI ​​agent 60's suggestions while reflecting the user's intentions and actual circumstances.

[0156] Furthermore, the outputted payment plan can be directly adopted and automatically linked to the payment processing. In this case, the AI ​​agent 60 has learned how to execute payments in accordance with the payment plan, and as an AI process, it generates a transfer instruction that instructs the payment to be made at the payment timing indicated by the input payment plan.

[0157] The payment support server 10 (an example of an AI processing unit) then inputs the received transfer instruction and the outputted recommended payment plan to the AI ​​agent 60, and as a result of the AI ​​processing, outputs a transfer instruction to the management system to make the payment according to that payment plan. As a result, a transfer instruction to the specified recipient account is automatically sent to the second bank server 42, which is an example of a management system, based on the recommended payment plan.

[0158] This configuration allows for the automation of payment execution processes based on the payment plan, and also enables a configuration that eliminates the need for user confirmation and submission. The output transfer instructions may be sent directly to the management system, or the user may review, approve, and modify the transfer instructions before submitting them.

[0159] In this way, by providing an automatic transfer instruction output function linked to the payment plan, users can easily and reliably make payments in accordance with the payment plan compared to systems without this function, thus avoiding risks such as missed payments and delays. Furthermore, the integrated operation of the AI ​​agent 60's learning results in suggesting and executing optimized payment timings contributes to improved operational efficiency and maintenance of creditworthiness.

[0160] <Variation: Chatbot> Furthermore, AI Agent 60 may be used as a so-called chatbot. In that case, AI Agent 60 would learn responses to questions regarding fund transfers or fund security, for example, and implement a function to output responses to those questions. However, the content that AI Agent 60 learns is not limited to this, and may also include responses to questions regarding payment support services in general.

[0161] Next, the payment support server 10 receives a question from the user. This question is received, for example, by displaying a chat screen for exchanging messages. This process of receiving a question is an example of a question receiving step executed by the payment support server 10 as an example of a question receiving unit. The payment support server 10 (an example of an AI processing unit) then outputs an answer to the question as the result of AI processing, based on the output of the AI ​​agent 60 that received the question as input.

[0162] The response output by the AI ​​agent 60 is displayed to the user, for example, by the user terminal 50. This configuration facilitates the smooth use of payment support services, including the bank transfer service, compared to when AI processing is not performed.

[0163] <Variation example: AI agent configuration> In the above examples, the payment support server 10 was equipped with the AI ​​agent 60, but other servers in the payment support system 1 (for example, the collection agency server 20 or the data management server 30) may be equipped with the AI ​​agent 60, or an external server located outside the payment support system 1 may be equipped with the AI ​​agent 60. Thus, the AI ​​agent 60 may be configured internally or externally. In either case, it is desirable to obtain the user's consent regarding how each piece of information will be used so that necessary information (such as billing information and asset information) can be input to the AI ​​agent 60.

[0164] <Example: Responding to delays in fund transfers> The payment support server 10 (an example of a withdrawal instruction unit) executed the withdrawal instruction process so that the withdrawal instruction from the withdrawal account would reach the first bank a predetermined number of days before the transfer due date. This ensured that the transfer of funds to the intermediary account was more reliable by the transfer due date, but even so, delays in fund transfer could still occur due to some operational or system abnormality.

[0165] Even if there is a delay in fund transfer, the transfer process itself by the second bank server 42 is basically carried out as instructed in order to meet the payment deadline. Meanwhile, the payment support server 10 notifies the worker in charge of fund transfers via the worker terminal 53, for example, that there is a delay in fund transfer. Upon receiving this notification, the worker can take measures such as prioritizing the transfer of the affected funds or identifying and resolving the cause of the delay in fund transfer.

[0166] <Example of variation: Variations in configuration> The configuration shown in Figure 1, etc. (overall configuration, hardware configuration, and functional configuration, etc.) is just an example, and other configurations can be adopted as long as they do not cause inconvenience in implementation. For example, each server (payment support server 10, collection agency server 20, data management server 30, and bank server 40) may be distributed across two or more devices, or may be provided in the form of SaaS (Software as a Service) or a cloud computing system.

[0167] Furthermore, the information processing performed by each server may be performed by other servers, or by an integrated device. For example, the screen previously displayed by payment support server 10 may be displayed by another server, or the data previously managed by other servers may be managed by payment support server 10. Also, the processing performed by the server may be performed by the user terminal, or the processing performed by the user terminal may be performed by the server. In short, as long as the necessary information processing is performed throughout the payment support system 1, the devices that perform that information processing are not limited.

[0168] The output destination for information or data (hereinafter referred to as "information, etc.") may be other devices, displays, storage units (including built-in and external storage units), email addresses, or accounts in other systems. Acquisition of information, etc. includes not only acquiring information, etc. transmitted from other devices, but also acquiring information, etc. generated by the device itself.

[0169] The embodiments described above consisted of information processing devices such as each server and each terminal (payer terminal 51, approver terminal 52, and worker terminal 53), or an information processing system such as the payment support system 1 equipped with these information processing devices, but it may also be an information processing method. The information processing method comprises the same steps as those performed by the information processing system. Furthermore, the embodiments described above may also be a program. The program causes a computer to perform the same steps as those performed by the information processing system.

[0170] <Note> Furthermore, they may be provided in the following embodiments.

[0171] (1) An information processing system comprising one or more processors, wherein the processors, in a receiving step, receive a transfer instruction from a user including the transfer amount and the recipient account; in a transfer instruction step, issue a transfer instruction to a management system for an intermediary account that enables online transfer instructions, to execute a transfer of the funds to the recipient account when the funds for paying the transfer amount are moved from the user's account to the intermediary account; in a calculation step, calculate the amount of funds subject to protection based on the balance in the intermediary account or the deposits and withdrawals to the intermediary account; and in a processing step, execute a process related to the protection of the funds based on the calculated amount of funds subject to protection.

[0172] This configuration allows for the smooth execution of operations related to the safekeeping of funds.

[0173] (2) The information processing system described in (1) above, wherein the transfer instruction further includes a withdrawal account that can be withdrawn online, and in the withdrawal instruction step, the information processing system executes a withdrawal instruction process to instruct the processor to withdraw funds from the withdrawal account in order to move the funds of the transfer amount indicated by the received transfer instruction to the intermediary account.

[0174] This configuration can reduce the effort required of users when making bank transfers.

[0175] (3) Information processing system as described in (1) above, wherein in the transfer instruction step, the processor issues the transfer instruction for the funds that the user has moved from their own account to the intermediary account.

[0176] In this configuration, a transfer instruction can be made even without a direct debit registration.

[0177] (4) An information processing system according to any one of (1) to (3) above, further comprising the management system, wherein the relay account includes a security account and a transfer account, the funds are moved to the security account, and when the management system receives the transfer instruction, it moves the funds moved to the security account to the transfer account and executes the transfer of the moved funds to the recipient account.

[0178] This configuration allows for more secure securing of funds for conservation purposes.

[0179] (5) An information processing system described in any one of (1) to (4) above, wherein the source account of the funds to be transferred to the intermediary account includes accounts of two or more financial institutions, and in the AI ​​processing step, the transfer history from the intermediary account is input as payment information to an AI agent having the function of processing based on payment information indicating the payment of a transaction, and the result of the processing is output based on the output of the AI ​​agent.

[0180] This configuration can improve the practicality of processing based on payment information.

[0181] (6) An information processing system as described in (5) above, wherein the AI ​​agent has learned payment characteristics that represent fraudulent transactions, and in the AI ​​processing step, the processor outputs a fraud detection result indicating a potentially fraudulent transaction as the result of the processing, based on the output of the AI ​​agent.

[0182] This configuration makes it easy to detect fraudulent transactions.

[0183] (7) An information processing system according to either (5) or (6) above, wherein the AI ​​agent has learned how to utilize assets according to the payment status, and in the AI ​​processing step, the processor outputs a suggestion for how to utilize assets according to the user's payment status as the result of the processing, based on the output of the AI ​​agent when the user's transfer history is input as payment information.

[0184] This approach can support the utilization of assets.

[0185] (8) An information processing system described in any one of (5) to (7) above, wherein the AI ​​agent has learned creditworthiness evaluation criteria at a financial institution, and in the AI ​​processing step, the processor outputs an action plan to improve the user's creditworthiness as the result of the processing, based on the output of the AI ​​agent when the user's transfer history is input as payment information.

[0186] This approach can help improve the creditworthiness of financial institutions.

[0187] (9) An information processing system as described in any one of (5) to (8) above, wherein the AI ​​agent has learned a method for generating a payment schedule based on billing information including the billing amount and payment deadline, in the reception step the processor receives the user's designation of the bill to be paid, and in the AI ​​processing step the processor inputs the billing information relating to the designated bill to the AI ​​agent and outputs a payment schedule for the bill as the result of the processing based on the output of the AI ​​agent.

[0188] In this manner, appropriate payments can be supported.

[0189] (10) An information processing system according to any one of (5) to (8) above, wherein the AI ​​agent has learned how to generate a payment plan according to the financial situation, in the acquisition step the processor acquires financial information indicating the financial situation of the user and billing information including the billing amount and payment deadline, and in the AI ​​processing step the processor inputs the acquired financial information and billing information to the AI ​​agent to output a payment plan recommended to the user as the result of the processing.

[0190] This approach can support payments that are manageable for the individual.

[0191] (11) An information processing system as described in (10) above, wherein the AI ​​agent has learned how to perform payments in accordance with a payment plan, and in the AI ​​processing step, the processor inputs the transfer instruction received in the receiving step and the recommended payment plan output to the AI ​​agent, thereby outputting a transfer instruction to the management system for payment in accordance with the payment plan as the result of the processing.

[0192] This method ensures that payments are made reliably.

[0193] (12) An information processing system according to any one of (5) to (11) above, wherein the AI ​​agent has learned the content of responses to questions regarding the transfer of funds or the safekeeping of funds, in a question receiving step, the processor receives the question from the user, and in the AI ​​processing step, the processor outputs an answer to the question as the result of the processing based on the output of the AI ​​agent that input the received question.

[0194] This configuration can support the smooth use of the remittance service.

[0195] (13) An information processing method comprising each of the steps described in any one of (1) to (12) above, which is performed by an information processing system.

[0196] This configuration allows for the smooth execution of operations related to the safekeeping of funds.

[0197] (14) A program that causes a computer to perform any one of the steps described in (1) to (12) above.

[0198] This configuration allows for the smooth execution of operations related to the safekeeping of funds. Of course, this is not always the case. Furthermore, the embodiments and modifications described above may be implemented in any combination.

[0199] Finally, various embodiments of the present invention have been described, but these are presented as examples only and are not intended to limit the scope of the invention. Novel embodiments can be implemented in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. Embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims and their equivalents. [Explanation of symbols]

[0200] 1: Payment support system 2: Communication lines 3: Invoice 4: Scanner 5: Management Database 10: Payment support server 20: Payment collection server 30: Data management server 40: Bank Server 41: First Bank Server 42: Second Bank Server 43: Third Bank Server 50: User terminal 51: Payer terminal 52: Approver terminal 53: Worker terminal 60: AI Agent 101: Control Unit 201: Control Unit 301: Control Unit 401: Control Unit 501: Control Unit

Claims

1. An information processing system comprising one or more processors, wherein the processors In the receiving step, the system receives a transfer instruction from the user, including the transfer amount and the recipient's bank account. In the transfer instruction step, a transfer instruction is made to the management system of an intermediary account that allows online transfer instructions, instructing it to transfer the funds to the recipient account when the funds to pay the transfer amount have been moved from the user's account to the intermediary account. In the calculation step, the amount of funds subject to protection is calculated based on the balance in the intermediary account or the deposit and withdrawal history of the intermediary account. In the processing step, based on the calculated amount of funds to be protected, the processing related to the protection of the funds is performed. Information processing system.

2. In the information processing system described in claim 1, The aforementioned transfer instructions further include withdrawal accounts that can be withdrawn online, In the withdrawal instruction step, the processor executes a withdrawal instruction process to instruct the withdrawal account to withdraw the funds of the transfer amount indicated by the received transfer instruction from the withdrawal account in order to move them to the intermediary account. Information processing system.

3. In the information processing system described in claim 1, In the transfer instruction step, the processor issues the transfer instruction for the funds that the user has moved from their own account to the intermediary account. Information processing system.

4. In the information processing system described in claim 1, The aforementioned management system is further provided, The aforementioned intermediary accounts include a security account and a transfer account. The aforementioned funds are transferred to the aforementioned security account. Upon receiving the transfer instruction, the management system moves the funds transferred to the security account to the transfer account and executes the transfer of the transferred funds to the recipient account. Information processing system.

5. In the information processing system described in claim 1, The source accounts of the funds being transferred to the aforementioned intermediary account include accounts at two or more financial institutions. In the AI ​​processing step, the transfer history from the intermediary account is input as payment information to an AI agent that has the function of processing based on payment information indicating the payment of a transaction, and the result of the processing is output based on the output of the AI ​​agent. Information processing system.

6. In the information processing system described in claim 5, The aforementioned AI agent has learned the characteristics of payments that represent fraudulent transactions. In the AI ​​processing step, the processor outputs a fraud detection result indicating a potentially fraudulent transaction as the result of the processing, based on the output of the AI ​​agent. Information processing system.

7. In the information processing system described in claim 5, The aforementioned AI agent has learned how to utilize assets according to payment status. In the AI ​​processing step, the processor outputs, as a result of the processing, a suggestion for how to utilize the user's assets according to the user's payment status, based on the output of the AI ​​agent when the user's transfer history is input as payment information. Information processing system.

8. In the information processing system described in claim 5, The aforementioned AI agent has learned the creditworthiness evaluation criteria used by financial institutions. In the AI ​​processing step, the processor outputs an action plan to improve the user's creditworthiness based on the output of the AI ​​agent when the user's transfer history is input as payment information. Information processing system.

9. In the information processing system described in claim 5, The aforementioned AI agent has learned how to generate payment schedules based on billing information, including the billing amount and payment deadline. In the reception step, the processor receives the user's designation of the invoice to be paid. In the AI ​​processing step, the processor inputs the billing information relating to the specified bill to the AI ​​agent, and outputs the payment schedule for the bill as the result of the processing based on the output of the AI ​​agent. Information processing system.

10. In the information processing system described in claim 5, The aforementioned AI agent has learned how to generate payment plans according to the financial situation. In the acquisition step, the processor acquires financial information indicating the user's financial status and billing information including the billing amount and payment deadline. In the AI ​​processing step, the processor inputs the acquired fund information and billing information to the AI ​​agent, and outputs a payment plan recommended to the user as the result of the processing. Information processing system.

11. In the information processing system according to claim 10, The aforementioned AI agent has learned how to execute payments in accordance with the payment plan. In the AI ​​processing step, the processor inputs the transfer instruction received in the receiving step and the recommended payment plan output to the AI ​​agent, thereby outputting a transfer instruction to the management system for payment according to the payment plan as the result of the processing. Information processing system.

12. In the information processing system described in claim 5, The AI ​​agent has learned the content of responses to questions regarding the transfer or safekeeping of the funds. In the question reception step, the processor receives the question from the user, In the AI ​​processing step, the processor outputs an answer to the question as the result of the processing, based on the output of the AI ​​agent that received the question. Information processing system.

13. Information processing method, The information processing system comprises each step according to any one of claims 1 to 12, Information processing methods.

14. It is a program, Cause the computer to perform each of the steps described in any one of claims 1 to 12. program.

Images