Advance payment apparatus, advance payment system, and advance payment method

Abstract

To properly process a plurality of bills.SOLUTION: An advance payment apparatus includes: bill information acquisition unit which acquires multiple pieces of bill information related to bills issued from a requester to payers; a control unit which selects bill information for a specific payer out of the multiple pieces of bill information acquired by the bill information acquisition unit; an output unit which outputs the bill information selected by the control unit; an acquisition unit which acquires information indicating whether to make advance payment, according to the bill information output by the output unit; and a transfer execution unit which executes transfer processing based on the bill information for which the advance payment is to be made. The output unit outputs the bill information issued to the payer from a payment agent in response to the advance payment, and the bill information issued from the requester, to be presented to the payer.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an advance payment device, an advance payment system, and an advance payment method. [Background technology]

[0002] In the past, the sending dates of invoices, etc. from each billing company were different from each other, which made management troublesome. To solve this problem, there was a technology that made it possible to send invoices, etc. together in a lump sum, reducing the expenses incurred by each billing company for sending them (for example, see Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2003-30569 A Summary of the Invention [Problem to be solved by the invention]

[0004] According to the technology described above, a proxy delivery of invoices etc. to a specified bank account is accepted, information to be transferred from the accepted information is tallied, and a consolidated billing document is created. In other words, by using the technology described above, invoices issued over a specified period of time are sent as a consolidated invoice, rather than as individual invoices as in the past. This technology is carried out by a company that performs a delivery agent business, which did not exist before. However, even if this technology is used, there is still a possibility that individual invoices will arrive from companies that are not included in the scheme, and it has not been sufficient to reduce the complexity of processing individual invoices.

[0005] The present invention has been made in consideration of the above circumstances, and has an object to provide an advance payment device, an advance payment system, and an advance payment method that are capable of suitably processing a plurality of invoices. [Means for solving the problem]

[0006] (1) One aspect of the present invention is an advance payment device that presents to the payer billing information relating to a claim issued by a biller to a payer, the advance payment device comprising: a billing information acquisition unit that acquires multiple pieces of billing information; a control unit that selects the billing information for a specific payer from the multiple pieces of billing information acquired by the billing information acquisition unit; an output unit that outputs the billing information selected by the control unit; an acquisition unit that acquires information indicating whether or not to make an advance payment in accordance with the billing information output by the output unit; and a transfer execution unit that executes a transfer process based on the billing information indicating that an advance payment will be made, the output unit outputting the billing information issued by the advance payment agent to the payer as an advance payment and the billing information issued by the biller, thereby presenting the billing information to the payer.

[0007] (2) In one aspect of the present invention, in the advance payment device described in (1) above, the output unit presents to the payer the billing information issued by the advance payer to the payer as a result of the advance payment and the billing information issued by the biller in the same format.

[0008] (3) In one aspect of the present invention, in the advance payment device described in (1) or (2) above, when there are multiple pieces of billing information issued by the advance payer to the payer as an advance payment, the output unit outputs them as a single piece of billing information.

[0009] (4) One aspect of the present invention is an advance payment system comprising an advance payment device described in any one of (1) to (3) above, a payer device that acquires information on whether the payer will make an advance payment based on information from the advance payment device, and a claimant device that acquires information indicating that a transfer has been made from the advance payment device, wherein the payer device comprises a presentation unit that presents the billing information output from the advance payment device to the payer, an operation receiving unit that receives an operation by the payer to select whether or not to make an advance payment in accordance with the presented billing information, and a payer device control unit that outputs information on whether or not to make an advance payment to the advance payment device based on the received operation.

[0010] (5) One aspect of the present invention is a method for advance payment, comprising: a claim information acquisition step for acquiring multiple pieces of claim information relating to a claim issued by a claimant to a payer; a control step for selecting the claim information for a specific payer from the multiple pieces of claim information acquired by the claim information acquisition step; an output step for outputting the claim information selected by the control step; an acquisition step for acquiring information indicating whether or not to make an advance payment based on the claim information output by the output step; and a transfer execution step for executing a transfer process based on the claim information indicating that an advance payment will be made, wherein the output step presents to the payer the claim information issued by the advance payer to the payer due to an advance payment being made and the claim information issued by the claimant. Effect of the Invention

[0011] According to the present invention, it is possible to provide an advance payment device, an advance payment system, and an advance payment method that are capable of suitably processing a plurality of invoices. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram for explaining an overview of a payment-on-reimbursement system according to an embodiment of the present invention. [Diagram 2] FIG. 13 is a diagram for explaining an example of a case where a payer makes an advance payment for a portion of an invoice in the advance payment system according to the present embodiment. [Diagram 3] FIG. 2 is a functional configuration diagram for explaining an example of the functional configuration of each device included in the advance payment system according to the present embodiment. [Figure 4] 5 is a diagram showing an example of information stored in a billing information storage unit according to the embodiment; FIG. [Diagram 5] This is a diagram to explain an example of a case in which a biller in this embodiment issues an invoice from the head office and each branch office. [Figure 6] 11 is a diagram showing an example of information stored in the billing information storage unit when a payer issues a bill from the head office and each branch office according to the present embodiment. FIG. [Figure 7] FIG. 13 is a functional configuration diagram showing a modified example of the payment device according to the present embodiment. [Figure 8] 4 is a functional configuration diagram showing an example of a detailed functional configuration of a payment-advancement device control unit according to the present embodiment. FIG. [Figure 9] FIG. 2 is a functional configuration diagram showing an example of a functional configuration when the advance payment device according to the present embodiment makes a determination regarding automatic advance payment. [Figure 10] 1 is a first flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 11] 13 is a second flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 12] 13 is a third flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 13] FIG. 13 is a diagram showing an example of a screen configuration of a payment list screen presented by the payer device according to the embodiment. [Figure 14] FIG. 13 is a diagram showing an example of a display screen presented on the payer device according to the present embodiment, the screen configuration being displayed before an application for advance payment is made. [Figure 15] FIG. 13 is a diagram showing an example of a display screen presented on the payer device according to the present embodiment, the screen configuration being displayed after an application for advance payment has been made. [Figure 16]FIG. 13 is a diagram showing an example of an unpaid bill list screen presented by the payer device according to the present embodiment, showing an example of the screen configuration when an application for partial advance payment has been made. [Figure 17] FIG. 13 is a diagram showing an example of an unpaid bill list screen presented by the payer device according to the present embodiment, illustrating a screen configuration for confirming which bills have been paid in advance. [Figure 18] FIG. 13 is a diagram showing an example of a screen configuration of an automatic advance payment setting screen presented by the payer device according to the embodiment. [Figure 19] FIG. 13 is a diagram showing an example of a display screen presented on the payer device according to the present embodiment, illustrating a screen configuration for selecting whether or not to make an advance payment when there is an unpaid debt. [Figure 20] 2 is a block diagram showing an example of an internal configuration of the payment device according to the present embodiment. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] [Embodiment] The following describes in detail preferred embodiments of the advance payment device, advance payment system, and advance payment method according to the aspects of the present invention, with reference to the accompanying drawings. Note that the aspects of the present invention are not limited to these embodiments, and include various modifications or improvements. In other words, the components described below include those that a person skilled in the art can easily imagine, and those that are substantially the same, and the components described below can be combined as appropriate. Furthermore, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the present invention. Furthermore, in the following drawings, the scale and number of each structure may be different from the scale and number of the actual structure in order to make each structure easier to understand.

[0014] [Overview of the advance payment system] FIG. 1 is a diagram for explaining an overview of the advance payment system according to this embodiment. First, an overview of the advance payment system 1 will be explained with reference to the diagram. The advance payment system 1 is used by a claimant C, a payer P, and an advance payer R. Of these, there are at least multiple claimants C. The diagram shows claimants C1, C2, and C3 as examples of multiple claimants C. The advance payment system 1 may also include multiple payers P. The diagram shows, as an example, a case where the advance payment system 1 includes only payer P.

[0015] A biller C issues an invoice to a payer P. Multiple billers C each issue an invoice to a payer P at any time and in any format. In the illustrated example, a biller C1 issues an invoice A to a payer P, a biller C2 issues an invoice B to a payer P, and a biller C3 issues an invoice C to a payer P.

[0016] The payer P receives an invoice from the biller C. The payer P receives invoices issued by each of the multiple billers C. In the illustrated example, the payer P receives invoice A from the biller C1, invoice B from the biller C2, and invoice C from the biller C3. The payer P decides whether to make an advance payment for each of the received invoices. Here, an advance payment is a method in which an advance payer R makes a payment to the biller C on behalf of the payer P. The illustrated example shows an example of a case in which an advance payment is made for all received invoices (i.e., invoice A, invoice B, and invoice C). The payer P transmits information about the invoices for which an advance payment is to be made to the advance payer R. Note that the payer P may transmit information about all received invoices to the advance payer R, together with information about which invoices are to be paid in advance.

[0017] The payer R obtains information about the invoices for which he / she will make an advance payment from the payer P. In the example shown, the payer R obtains information about invoices A, B, and C from the payer P as information about the invoices for which he / she will make an advance payment. The payer R makes payment to the biller C based on the obtained invoice information. Specifically, in the example shown, the payer R makes payment to the biller C1 who issued invoice A based on invoice A, makes payment to the biller C2 who issued invoice B based on invoice B, and makes payment to the biller C3 who issued invoice C based on invoice C.

[0018] The payer R issues an invoice to the payer P for the total amount of the invoices that he / she has paid on behalf of (invoice A, invoice B, and invoice C in the illustrated example). The payer P may add a fee when making the payment to the payer R. The payer P pays the total amount of the invoices that he / she has requested to be paid on behalf of the payer R (invoice A, invoice B, and invoice C in the illustrated example) and the necessary fee to the payer R. By adopting such a configuration, the payer P can make a lump-sum payment to the payer R instead of paying each of the multiple billers C. Therefore, according to this embodiment, the payer P can reduce the conventional hassle of processing each invoice separately.

[0019] FIG. 2 is a diagram for explaining an example of a case where a payer makes an advance payment for some invoices in the advance payment system according to this embodiment. This figure is a modified example of the example shown in FIG. 1. In the example shown in FIG. 2, an example of a case where payer P makes an advance payment for some of the invoices received is shown. In the specifically illustrated example, payer P receives invoice A from biller C1, invoice B from biller C2, and invoice C from biller C3. Of these received invoices, payer P pays invoice C to biller C3 himself, and makes an advance payment for the remaining invoices A and B.

[0020] In this case, payer P sends information about invoice A and invoice B to payer R. Alternatively, payer P sends information about invoice A, invoice B, and invoice C, as well as information about invoice A and invoice B to be paid on behalf of payer R. Payer R makes payment to biller C1 who issued invoice A based on invoice A, and makes payment to biller C2 who issued invoice B based on invoice B. Payer R issues an invoice to payer P for the total amount of invoices for which it has made on behalf payments (invoice A and invoice B in the illustrated example). Payer P pays to payer R the total amount of invoices for which it has requested on behalf (invoice A and invoice B in the illustrated example), as well as the necessary fees.

[0021] [Function configuration] FIG. 3 is a functional configuration diagram for explaining an example of the functional configuration of each device included in the advance payment system according to this embodiment. With reference to the same figure, an example of the functional configuration of each device included in the advance payment system 1 will be explained. The advance payment system 1 includes an advance payment device 10, a payer device 20, and a claimant device 30. Each functional unit included in the advance payment device 10, the payer device 20, and the claimant device 30 is realized, for example, by using an electronic circuit. Each functional unit may also include internal storage means such as a semiconductor memory or a magnetic hard disk device, as necessary. Each function may also be realized by a computer having a CPU (Central Processing Unit) and software. All or a part of each functional unit may also be realized by using hardware such as an ASIC (Application Specific Integrated Circuit), a PLD (Programmable Logic Device), or an FPGA (Field-Programmable Gate Array). All or a part of each functional unit may also be realized by a combination of software and hardware. All or part of the functions of the advance payment device 10, payer device 20, and claimant device 30 may exist on, for example, a cloud server. Furthermore, each of the advance payment device 10, payer device 20, and claimant device 30 may be composed of multiple devices (computers), and each functional block may be distributed across multiple devices.

[0022] The advance payment device 10 comprises a billing information acquisition unit 11 , a billing information storage unit 12 , an advance payment device control unit 13 , an output unit 14 , an acquisition unit 15 , and a transfer execution unit 16 .

[0023] The billing information acquisition unit 11 acquires billing information BI, which is information regarding a bill issued by a biller C to a payer P. The billing information acquisition unit 11 acquires multiple pieces of billing information BI. The multiple pieces of billing information BI may be issued respectively by multiple billers C, or may be issued by a specific biller C. The billing information BI includes at least information identifying the biller C who issued the invoice.

[0024] The billing information BI acquired by the billing information acquisition unit 11 may have at least two or more modes. That is, the billing information acquisition unit 11 may be configured to acquire billing information BI in a plurality of modes. The plurality of modes includes, first, a first mode in which the billing information BI exists as electronic data provided by the biller C. The billing information BI as electronic data may be, for example, information obtained by performing optical character recognition (OCR) on a paper bill. Also, a second mode in which the billing information BI exists is input to the advance device 10 by the payer P operating an input device (which may be, for example, the payer device 20). The modes of the billing information BI may include modes other than those exemplified above.

[0025] The billing information acquisition unit 11 is thus configured to be able to acquire billing information BI in a plurality of different types, and is thus able to handle bills from a plurality of billers C who issue bills in different formats. The billing information acquisition unit 11 may acquire the billing information BI directly from the biller C, or may acquire the billing information BI indirectly from the payer P after the biller C issues the bill to the payer P. Acquisition of the billing information BI may include acquiring bills stored in a predetermined database. The bills stored in the predetermined database may be, for example, bill information stored by an existing platform provider. That is, the advance payment device 10 may also perform advance payment processing by cooperating with an existing platform. The billing information BI stored in a predetermined database in the existing platform may be arranged in, for example, a unified format.

[0026] The link with the system of the other platform may be performed, for example, through an API (Application Programming Interface). Also, in order to link with the system of the other platform, the payer R may provide an SDK (Software Development Kit) to the existing system of the other platform, or the SDK may be provided on an OEM basis. As a linking method, the service according to this embodiment may be embedded in the system of the other platform, which is to be a partner, or information may be linked from the system of the other platform, which is to be a partner, to the pay-by-payment device 10 according to this embodiment.

[0027] The acquisition of the billing information BI is not limited to the examples of acquisition from a system such as another platform or direct input of information to the advance payment device 10, and it may also be acquired by other methods.

[0028] The billing information storage unit 12 accumulates a plurality of billing information BI acquired by the billing information acquisition unit 11. The billing information storage unit 12 is configured to include a hard disk drive (HDD: Hard Disk Drive), a solid state drive (SSD: Solid State Drive), a flash memory, a ROM (Read Only Memory), etc. The billing information storage unit 12 does not have to exist as a hardware configuration equipped in the advance payment device 10, and may exist in, for example, a server device connected via a network.

[0029] Here, an example of the billing information BI stored in the billing information storage unit 12 will be described with reference to FIGS.

[0030] [Billing Information] FIG. 4 is a diagram showing an example of information stored in the billing information storage unit according to this embodiment. With reference to the diagram, an example of billing information BI stored in the billing information storage unit 12 will be described. In the example shown in the figure, the billing information BI is associated with a “biller”, a “payer”, a “billing amount”, a “scheduled payment date”, a “status”, and “advance payment selection information”. The “biller” is information for identifying the biller C who issued the billing information BI. The “payer” is information for identifying the payer P to whom the billing information BI is issued. The “billing amount” is information indicating the billing amount of the billing information BI. The “scheduled payment date” is information indicating the scheduled payment date of the billing information BI to the biller C. The “status” is information indicating the status of the billing information BI. The “advance payment selection information” is information indicating whether or not the biller P has selected the billing information BI as an advance payment.

[0031] Specific examples of the above-mentioned "status" may include the following: · Unpaid: Payment has not been made to claimant C, and no option has been chosen as to whether or not to make an advance payment. · Applied: Payer P has selected advance payment, and advance payer R is determining whether or not to allow advance payment. Waiting for advance payment to be made: This is the state in which the advance payment is awaited after the payer P selects the advance payment and the advance payer R determines that the advance payment is possible. Advance payment completed: This is the state after the payer P selects advance payment, the advance payer R determines that advance payment is possible, and the advance payment is then executed. · Unpaid (waiting for transfer): After the payer R has made an advance payment, the payer P is waiting for the payer R to transfer the payment. · Paid (transfer completed): This is the state after the payer R has made the advance payment and after the payer P has made a transfer to the payer R.

[0032] In addition, the above-mentioned "status" may include an error-related status. An error-related status may include a case where processing is interrupted for some reason, or the information in the billing information BI is incomplete. In addition, the above-mentioned "status" may include a pattern in which insurance / guarantee has been fulfilled. In addition, the above-mentioned "status" may broadly include statuses regarding the processing status of other billing information BIs.

[0033] Specifically, in the illustrated example, the billing information BI1 shows a case where the "biller" is A Shoji, the "payer" is A Co., Ltd., the "billing amount" is ¥50,000, the "scheduled payment date" is 2023 / 4 / 28, the "status" is unpaid, and the "advance payment selection information" is ◯. The billing information BI2 shows a case where the "biller" is B Shoji, the "payer" is B Co., Ltd., the "billing amount" is ¥20,000, the "scheduled payment date" is 2023 / 4 / 30, the "status" is unpaid, and the "advance payment selection information" is -. The billing information BI3 shows a case where the "biller" is C Shoji, the "payer" is C Co., Ltd., the "billing amount" is ¥30,000, the "scheduled payment date" is 2023 / 4 / 30, the "status" is unpaid, and the "advance payment selection information" is -.

[0034] FIG. 5 is a diagram for explaining an example of a case where a biller according to this embodiment issues an invoice from the head office and each branch office. Here, depending on the biller C, there may be multiple issuers even though they are the same biller C. As an example, the figure shows an example of a case where the biller C issues an invoice from the head office and each branch office. That is, the figure shows a case where an invoice is issued from multiple roles. Specifically, as the biller C, there is a head office C1 and multiple branches C2. As the multiple branches C2, there are branches C2-1, PC-2, and PC-3. In such a situation, an invoice may be issued from each issuer. In the example shown in the figure, invoice A1 is issued from the head office C1, invoice A21 is issued from the branch office C2-1, invoice A22 is issued from the branch office PC-2, and invoice A23 is issued from the branch office P2-3. In such a case, an identification number may be assigned to each role, and the invoice information BI may include the identification number to make each role identifiable.

[0035] Figure 6 is a diagram showing an example of information stored in the billing information storage unit when a payer in this embodiment issues invoices from the head office and each branch office. The example shown in the figure shows an example of billing information BI, similar to Figure 4. The example shown in Figure 6 differs from the example shown in Figure 4 in that, although all biller Cs are A Shoji, they are distinguished as the head office, the XX branch office, or the △△ branch office. In this way, biller information may be structured in a hierarchical structure, with each one identifiable.

[0036] [Function configuration] Returning to FIG. 3, the explanation of the functional configuration of the payment advance device 10 will be continued.

[0037] The advance device control unit 13 selects claim information BI for an invoice issued to a specific payer from among the multiple claim information BI acquired by the claim information acquisition unit 11 and stored in the claim information storage unit 12. This process may be triggered by, for example, an execution instruction from the payer device 20. When the advance device control unit 13 acquires the execution instruction from the payer device 20, it selects claim information BI associated with the payer P corresponding to the payer device 20 from among the multiple claim information BI stored in the claim information storage unit 12. The advance device control unit 13 outputs the selected claim information BI to the payer device 20 via the output unit 14. In the following description, the advance device control unit 13 may be simply referred to as a control unit.

[0038] The output unit 14 outputs the claim information BI selected by the advance payment device control unit 13 to the payer device 20. The claim information BI selected by the advance payment device control unit 13 is claim information BI associated with a specific payer P. The output unit 14 outputs information to the payer device 20 corresponding to the specific payer P. Note that the claim information BI for a specific payer P may be referred to as specific claim information SBI.

[0039] The acquisition unit 15 acquires information indicating whether or not to make an advance payment from the payer device 20 in accordance with the specific claim information SBI output by the output unit 14. Whether or not to make an advance payment is included in the advance payment information RPI, for example. The advance payment information RPI may include information on the payment method after the advance payment. In other words, when an advance payment is selected, the acquisition unit 15 may further acquire information on the payment method after the advance payment. In addition, it is preferable that the acquisition unit 15 acquires information on the payment method after the advance payment for each biller C. The acquisition unit 15 outputs the acquired advance payment information RPI to the advance payment device control unit 13.

[0040] It is preferable that the information on the payment method after advance payment acquired by the acquisition unit 15 includes at least either a payment by credit card or a payment by bank transfer. In addition, the information on the payment method after advance payment acquired by the acquisition unit 15 may widely include a payment agent, a Business Payments Solution Provider (BPSP) which is a payment by credit card, a format specified by the Japan Bankers Association for transfers via Internet banking, an external transfer, etc. Examples of an external transfer include a transfer at a bank counter and a transfer using an automated teller machine (ATM).

[0041] The advance payment device control unit 13 acquires the advance payment information RPI from the acquisition unit 15, and updates the billing information BI stored in the billing information storage unit 12 according to the acquired advance payment information RPI. That is, the advance payment device control unit 13 updates the billing information BI, so that the billing information BI is associated with information on whether or not an advance payment is to be made.

[0042] The transfer execution unit 16 executes a transfer process for the claimant C based on the billing information BI stored in the billing information storage unit 12 and indicating that an advance payment is to be made. Whether or not a case is subject to transfer processing is determined, for example, by the advance device control unit 13 referring to the billing information storage unit 12. The advance device control unit 13 outputs a control signal CI to the transfer execution unit 16, and the transfer execution unit 16 executes transfer processing (makes payment to the transfer destination account) for the case subject to transfer processing indicated by the control signal CI. The transfer execution unit 16 executes transfer processing for the claimant who issued the invoice. As a result of executing the transfer processing, the transfer execution unit 16 outputs transfer information TI to the claimant device 30 indicating that the transfer processing has been executed.

[0043] Next, the functional configuration of the payer device 20 will be described. The payer device 20 is a terminal device operated by the payer P. The payer device 20 acquires information on whether or not to make an advance payment from the payer PI based on information from the advance device 10. The payer device 20 outputs the information on whether or not to make an advance payment acquired from the payer PI to the advance device 10. The payer device 20 includes a payer device control unit 21, a presentation unit 22, and an operation reception unit 23.

[0044] The payer device control unit 21 acquires specific claim information SBI indicating claim information BI to be paid by the payer P from the advance payment device 10. The payer device control unit 21 presents the claim information BI to be paid by the payer P to the payer P. The payer device control unit 21 outputs information to be presented by the presentation unit 22 as presentation information DI.

[0045] The presentation unit 22 presents the billing information BI output from the advance payment device 10 to the payer P. The presentation unit 22 may include a display unit (not shown) capable of visually displaying the billing information BI to the payer P. The display unit may be, for example, a liquid crystal display, an organic EL (Electroluminescence) display, or the like.

[0046] The operation reception unit 23 receives operations from the payer P. The operation reception unit 23 receives operations from the payer P via an input device such as a keyboard, touch panel, or microphone (not shown). The payer P selects whether or not to make an advance payment for each invoice based on the information displayed on the presentation unit 22. The operation reception unit 23 receives an operation by the payer to select whether or not to make an advance payment in accordance with the presented billing information BI. The payer device control unit 21 outputs advance payment information RPI, including information on whether or not to make an advance payment, to the advance payment device 10 based on the operation received by the operation reception unit 23.

[0047] Next, we will explain the functional configuration of the claimant device 30. The claimant device 30 acquires transfer information TI indicating that a transfer has been executed from the advance device 10. The claimant device 30 may also have a function of issuing claim information BI to the payer device 20.

[0048] The advance device 10 may be configured to perform a transfer operation with the intervention of an operator OP. Hereinafter, as a modified example of the advance device 10, an example of a case where the advance device 10 is configured to perform a transfer operation with the intervention of an operator OP will be described with reference to the drawings.

[0049] [An example of a transfer process involving an operator] Fig. 7 is a functional configuration diagram showing a modified example of the advance payment device according to this embodiment. With reference to the same figure, an example of the functional configuration of the advance payment device 10A, which is a modified example of the advance payment device 10, will be described. The advance payment device 10A differs from the advance payment device 10 in that it further comprises an application instruction output unit 17 and a transfer data file import unit 18. In the description of the advance payment device 10A, the same components as those in the advance payment device 10 are given the same reference numerals and description thereof may be omitted. Furthermore, in the description of the advance payment device 10A, description of the same components as those in the advance payment device 10 may be omitted.

[0050] The application instruction output unit 17 outputs the billing information BI indicating that an advance payment is to be made to the operator. The billing information BI output by the application instruction output unit 17 may be information that is searched for in the billing information storage unit 12 by the advance payment device control unit 13 and passed to the application instruction output unit 17, for example.

[0051] The operator OP creates a transfer data file in which the transfer execution information is described based on the information output from the application instruction output unit 17. The transfer data file may be created in a predetermined format that can be recognized by the advance payment device 10A, or in a predetermined format specified by a predetermined internet banking service.

[0052] The transfer data file import unit 18 imports the transfer data file based on instructions from the operator OP. When importing the transfer data file, the transfer data file import unit 18 may refer to the information output by the application instruction output unit 17 and determine whether there are any omissions in the confirmation results by the operator OP.

[0053] The transfer execution unit 16 executes the transfer process based on the transfer data file imported by the transfer data file import unit 18. The transfer execution unit 16 may, for example, import the transfer data file imported by the transfer data file import unit 18 into Internet banking and execute the transfer process by general transfer or transfer.

[0054] [Payment Status Update] Here, it is preferable that the billing information BI stored in the billing information storage unit 12 is associated with information on the payment status. The information on the payment status is information on the payment status of the bill when the payer P selects advance payment. The information on the payment status includes at least the status of unpaid (unpaid). The information on the payment status may also include a wide range of other statuses such as those described with reference to FIG. 4. The information on the payment status may be acquired from the payer device 20 by, for example, the acquisition unit 15 shown in FIG. 3.

[0055] The information on the payment status may be updated manually by the payer P, or automatically by the advance payment device 10. When the payer P performs a transfer process at a bank counter or at an automated teller machine (ATM), it is preferable for the information on the payment to be updated manually by the payer P. In this case, the acquisition unit 15 acquires information on the payment status of the billing information BI from the payer device 20, based on the operation of the payer P who presents the billing information BI and selects whether or not to make an advance payment.

[0056] In addition, when the information on the payment status can be manually changed by the payer P, the payer device 20 may present it to the payer P in a manner that allows the payer P to recognize that it is changeable. Specifically, the payer device 20 acquires the billing information BI associated with the information on the payment status from the advance device 10, and presents it to the payer P based on the acquired information. The payer device 20 may present it in different manners depending on the information on the payment status, depending on whether the status is changeable by the payer P or not. For example, when the status is changeable by the payer P (for example, in the case of external transfer), the payer device 20 may display it by changing (activating) the status display color. Furthermore, the payer device 20 may notify the payer P of the status change method during onboarding.

[0057] In addition, in the case of a status such as payment agency or advance payment, the information regarding the payment may be automatically updated by the advance payment device 10. In the case of a status that is automatically updated in this way, for example, the payer device 20 may display the status by changing the status display color (deactivating it).

[0058] Below, with reference to the drawings, a case where the advance payment device 10 automatically updates information related to payment will be described. An example of a case where the advance payment device 10 automatically updates information related to payment is when it performs a payment agent or advance payment. When the advance payment device 10 automatically updates information related to payment, it automatically clears the data based on information acquired by batch processing or transfer completion data obtained by detecting a deposit.

[0059] 8 is a functional configuration diagram showing an example of the detailed functional configuration of the advance device control unit according to this embodiment. With reference to the same figure, an example of the detailed functional configuration of the advance device control unit 13 in the case where information related to payment is automatically updated by the advance device 10 will be described. The advance device control unit 13 comprises a virtual account allocation unit 131, a deposit detection unit 132, a payment status acquisition unit 133, a payment status reconciliation unit 134, and a warning unit 135.

[0060] The virtual account allocation unit 131 refers to the billing information BI acquired by the billing information acquisition unit 11 and stored in the billing information storage unit 12, and allocates a different virtual account for each payer. By allocating a different virtual account for each payer, the virtual account allocation unit 131 identifies the payer P who made the deposit when a deposit is made from the payer P. The virtual account allocation unit 131 outputs information identifying the payer P and information on the virtual account corresponding to the payer P to the payment status reconciliation unit 134 as virtual account information VAI.

[0061] The deposit detection unit 132 detects that a deposit has been made from the payer P to the virtual account. The deposit detection unit 132 outputs information regarding the deposit as deposit information PI to the payment status reconciliation unit 134. The deposit information PI may include, for example, information identifying the payer P who made the deposit, the amount of the deposit, information identifying the billing information BI, and the like.

[0062] When a payment is made manually by the payer P, the payment status acquisition unit 133 acquires information indicating that the payment has been made from the payer device 20. The payment status acquisition unit 133 outputs the information indicating that the payment has been made manually by the payer P as payment status information PSI to the payment status reconciliation unit 134. The payment status information PSI may include, for example, information identifying the payer P who made the deposit, and information identifying the payment amount, the payment method, and the billing information BI.

[0063] The payment status reconciliation unit 134 acquires virtual account information VAI from the virtual account allocation unit 131, acquires deposit information PI from the deposit detection unit 132, and acquires payment status information PSI from the payment status acquisition unit 133. The payment status reconciliation unit 134 updates the billing information BI stored in the billing information storage unit 12 based on the acquired information. The billing information BI is updated by outputting update information UPI to the billing information storage unit 12. More specifically, for example, the payment status reconciliation unit 134 changes information regarding the payment status to "paid" based on the deposit information to the virtual account. Changing information regarding the payment status to "paid" can also be said to be erasing debt data.

[0064] When the status of the billing information BI is "unpaid," the warning unit 135 issues a warning (alarm) in accordance with the payment due date. The warning unit 135 issues a warning to the payer P in accordance with the period until the payment due date, based on information on the payment status of the billing information BI stored in the billing information storage unit 12. The warning unit 135 issues a warning to the payer P, for example, when the period until the payment due date becomes shorter (specifically, the period until the payment due date may be within three days, etc.). The warning may be issued, for example, by presenting information to the payer P via the presentation unit 22 included in the payer device 20.

[0065] [Automatic Advance Payment] Next, automatic advance payment will be described. Automatic advance payment means that an advance payment is made without the operation of the payer P (i.e., the advance payment device 10 transfers the money to the biller C). Whether or not to make an automatic advance payment may be set, for example, on a statement by statement basis. Whether or not to make an automatic advance payment may be set, for example, by the payer P. The payer P selects whether or not to make an automatic advance payment according to the billing information BI output by the output unit 14 of the advance payment device 10, and the selected information is acquired by the acquisition unit 15. The payer P may set, for example, when making a transfer to the advance payer R, whether or not to make an automatic advance payment for bills from the following month onwards.

[0066] It should be noted that the automatic advance payment according to this embodiment is different from the registration of a transfer destination in the conventional technology of internet banking, etc. For example, in the conventional technology of internet banking, the registration of a transfer destination is performed after a transfer is executed, but the automatic advance payment according to this embodiment can also be set for billing information BI issued by biller C, who has never executed a transfer.

[0067] When the advance payment device 10 supports automatic advance payment, the billing information BI is associated with information on whether or not to make an automatic advance payment. The information on whether or not to make an automatic advance payment may be acquired from the payer device 20. The transfer execution unit 16 executes the transfer process based on the billing information BI indicating that an automatic advance payment is to be made, without the operation of the payer P (i.e., without the payer P determining whether or not to make an advance payment for each invoice).

[0068] The automatic advance payment is not limited to the example set by the payer P. The automatic advance payment may be set automatically by the advance device 10. For example, the advance device 10 may be set to automatically transfer all cases from the following month onward, regardless of the transfer record, once the advance payment process is completed for a bill for which an advance payment has been requested. This is based on the idea that in principle, all cases are advanced and the setting of the automatic advance payment can be cancelled later for cases that the payer P judges not to require an advance payment. After the automatic advance payment has been set, if the payer P requests to cancel the automatic advance payment, the advance device control unit 13 cancels the setting of the automatic advance payment based on the operation of the payer P.

[0069] The automatic advance payment is set by the advance device control unit 13. That is, the advance device control unit 13 sets the billing information BI for which information on advance payment has been acquired by the acquisition unit 15 to perform an automatic advance payment regardless of the operation of the payer P. Note that the advance device control unit 13 may also set the billing information BI for which information on advance payment has been acquired by the acquisition unit 15 to perform an automatic advance payment based on the operation of the payer P.

[0070] The automatic advance payment may be set in a form limited to a specific payee. Also, by registering a payee from the link information before a transfer is made, it is possible to set the automatic advance payment before the transfer is made. Also, the advance payment device 10 may set the automatic advance payment based on the transfer history after the transfer is made.

[0071] Fig. 9 is a functional configuration diagram showing an example of the functional configuration when the advance payment device according to this embodiment makes a judgment about automatic advance payment. With reference to the same figure, an example of a case where it is judged whether or not it is possible to set up automatic advance payment based on the transfer record of past transfers will be described. In this case, the advance payment device 10 further comprises a transfer record storage unit 121. Furthermore, the advance payment device control unit 13 further comprises an automatic advance payment judgment unit 136. In the explanation of the same figure, explanation of the configuration already explained may be omitted.

[0072] The transfer history storage unit 121 stores past records of transfers made by the payer P to the advancing person R. The information stored in the transfer history storage unit 121 may be referred to as transfer history information TRI. The transfer history information TRI is, in other words, information on transfers made by the payer P in the past. The transfer history information TRI may be associated with, for example, the transfer amount, transfer date and time, transfer deadline, information on the biller C, and the like for each transfer process. The transfer history information TRI may be stored, for example, for each payer P. In addition to records of transfers from the payer P to the advancing person R, the transfer history information TRI may also be associated with records of transfer processes made by the payer P directly (without using an advance payment) to the biller C.

[0073] When the acquisition unit 15 acquires information indicating that an automatic advance payment is to be made from the payer device 20, the automatic advance payment determination unit 136 determines whether or not an automatic advance payment is possible. This determination is not limited to the case where information indicating that an automatic advance payment is to be made is acquired from the payer device 20, and the advance payment device 10 may make this determination voluntarily. Information indicating that an automatic advance payment is to be made, acquired from the payer device 20, may be referred to as automatic advance payment information ARPI. For example, when the automatic advance payment determination unit 136 acquires automatic advance payment information ARPI from the acquisition unit 15, the automatic advance payment determination unit 136 determines whether or not an automatic advance payment is possible based on the transfer record information TRI stored in the transfer record storage unit 121. Whether or not an automatic advance payment is possible may be determined based on, for example, whether or not there is an invoice that has not been transferred even after the transfer deadline has passed. In addition, the determination criterion of the automatic advance payment determination unit 136 may be any.

[0074] [Flow of a series of processes performed by the advance payment device] Next, a flow of a series of processes performed by the advance payment device 10 according to this embodiment will be described with reference to Fig. 10 to Fig. 12. In the description of the flow of the processes, an example of a screen configuration of a processing screen will also be described with reference to the drawings.

[0075] 10 is a first flow chart showing the flow of a series of processes performed by the advance payment device according to this embodiment. First, the overall flow performed by the advance payment device 10 will be described with reference to the same figure.

[0076] (Step S11) First, the billing information acquisition unit 11 acquires billing data BI. The billing data BI may be acquired from another existing platform, or may be directly input by the payer P.

[0077] (Step S12) The acquired billing data BI is stored in the billing information storage unit 12. Here, the advance payment system 1 according to this embodiment is capable of linking with various other existing platforms. The billing information storage unit 12 may store a mixture of billing information BI acquired from a plurality of platforms and billing information BI directly input by the payer P. It is preferable that the format of the billing information BI stored in the billing information storage unit 12 be unified into a predetermined format. In order to unify the format, it is preferable that the advance payment system 1 according to this embodiment link through an API or provide an SDK to other existing platform providers and the payer P.

[0078] (Step S13) Next, the advance payment device control unit 13 extracts the billing information BI for a specific payer P from the billing information BI stored in the billing information storage unit 12. The output unit 14 outputs the extracted information to the payer device 20 corresponding to the specific payer P. The payer device 20 presents a list of invoices for which the payer P is the payment target.

[0079] FIG. 13 is a diagram showing an example of the screen configuration of a payment list screen presented by the payer device according to this embodiment. With reference to the same figure, an example of the screen configuration of the payment list screen D10 will be described. The payment list screen D10 has a tab D111 and a tab D112 as a screen configuration. The tab D111 is a tab for displaying the unpaid list. The tab D112 is a tab for displaying the payment history. The tabs D111 and D112 are mutually exclusive. In the example shown in the figure, the tab D111 is selected, and therefore the unpaid list is displayed.

[0080] The code D12 indicates the unpaid amount. The unpaid amount is, for example, an amount including a fee. In the example shown, the unpaid amount is "103,000 yen." It is preferable that the amount of the fee out of the unpaid amount is presented so that it can be easily recognized. In the example shown, the fee is "3,000 yen."

[0081] Reference symbol D13 displays a list of unpaid items. The unpaid list displays billing information BI that is unpaid (i.e., payment from the payer P to the biller C or the advance payer R has not been completed). The billing information BI is associated with "business partner name", "billing amount", "scheduled payment date", "status", and "advance payment option". Of these, "business partner name", "billing amount", and "scheduled payment date" are items that are determined at the time the billing information acquisition unit 11 acquires the billing information BI. "Status" and "advance payment option" are items that can be changed by the payer P or the advance payment device 10.

[0082] When the "Status" button is active, the payer P can change the status. For example, the payer P changes the status to "paid" after making a deposit to the biller C at a payment bank counter or ATM. When the "Status" button is inactive, the payer P cannot change the status. The "Status" button becomes inactive, for example, in the case of a payment agent or advance payment. In these cases, the status is changed by the biller device 30, and therefore the payer P cannot change the status.

[0083] The payer P can select advance payment for each billing information BI. Each billing information BI is provided with a check box for selecting whether or not to make an advance payment, and the payer P can select each one independently. In the example shown in the figure, none of the check boxes are checked (i.e., advance payment is not selected). A bulk selection check box D14 may also be provided. By selecting the bulk selection check box D14, the payer P can select advance payment for all billing information BI, reducing the effort of selecting each one one by one. In the example shown in the figure, the bulk selection check box D14 is not checked (i.e., advance payment is not selected in bulk).

[0084] In the illustrated example, billing information BI11, billing information BI12, and billing information BI13 are displayed as unpaid billing information BI. Specifically, the "customer name" of billing information BI11 is A Shoji, the "billing amount" is 50,000 yen, the "scheduled payment date" is April 28, 2023, the "status" is unpaid, and the "advance payment selection" is not selected. The "customer name" of billing information BI12 is B Shoji, the "billing amount" is 20,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and the "advance payment selection" is not selected. The "customer name" of billing information BI13 is C Shoji, the "billing amount" is 30,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and the "advance payment selection" is not selected.

[0085] Returning to FIG. 10, the description of the flow of a series of processes performed by the payment advance device 10 according to this embodiment will be continued.

[0086] (Step S14) When the payer device 20 presents the billing information BI and advance payment is selected (i.e., step S14; YES), the advance device 10 advances the process to step S15. On the other hand, when advance payment is not selected (i.e., step S14; NO), the advance device 10 advances the process to step S16.

[0087] (Step S15) When advance payment is selected, the advance payment device 10 performs an advance payment process for the billing information BI for which advance payment has been selected. A detailed flow of the advance payment process will be described later with reference to FIG.

[0088] (Step S16) If advance payment is not selected, the payer P performs payment processing by a payment agent, transfer via internet banking, ATM, or other method. As a result of making payment by these methods, the payer P changes the status to "paid."

[0089] Fig. 11 is a second flow chart showing the flow of a series of processes performed by the advance payment device according to this embodiment. With reference to the same figure, the detailed flow of the advance payment process will be explained. The series of processes shown in the same figure are, in other words, the details of the process of step S15 explained with reference to Fig. 10.

[0090] (Step S21) First, the advance payment device 10 acquires a payment method for each piece of billing information BI from the payer P. Here, the selection of the payment method may be performed individually for each piece of billing information BI, or may be performed collectively for multiple pieces of billing information BI.

[0091] (Step S22) If a batch request has been made (i.e., step S22; YES), the process proceeds to step S24. If an individual request has been made (i.e., step S22; NO), the process proceeds to step S23.

[0092] (Step S23) If an individual request is made, a request is made for each payment statement.

[0093] (Step S24) An advance payment application is made for billing information BI for which advance payment was selected in the selection of payment method in step S21. In the advance payment application, the method of payment to the advance payer R resulting from the advance payment is specified. Examples of the method of payment to the advance payer R include invoice payment and credit card payment. An example of the screen configuration of the display screen presented on the payer device 20 before the advance payment application is made and an example of the screen configuration of the display screen presented on the payer device 20 after the advance payment application is made will be described with reference to the drawings.

[0094] Fig. 14 is a diagram showing an example of a screen configuration of a display screen presented on the payer device according to this embodiment, which is displayed before an advance payment application is made. With reference to the figure, an example of the screen configuration of the advance payment application screen D20 will be described. The advance payment application screen D20 includes the elements D21 to D26 as screen components.

[0095] Reference symbol D21 is an advance payment method selection button. In the same figure, reference symbols D211 and D212 are shown as examples of advance payment method selection buttons. When reference symbol D211 is selected, payer P makes payment to advance payer R by invoice payment (bank transfer). When reference symbol D212 is selected, payer P makes payment to advance payer R by credit card payment. Either of the advance payment method selection buttons may be selected exclusively. Note that buttons showing other payment method candidates may be provided as advance payment method selection buttons.

[0096] Reference symbol D22 is a display unit that shows the number of invoices that are the subject of the advance payment application. In the example shown, one invoice is the subject of the advance payment application. The advance payment device 10 according to this embodiment can advance pay multiple invoices collectively. When multiple invoices are advanced paid collectively, reference symbol D22 displays the number of invoices that have been combined. By making an advance payment for multiple invoices collectively and selecting invoice payment by payer P, payer P can combine multiple invoices into one invoice, thereby reducing the cumbersome work of dealing with multiple invoices.

[0097] Reference symbol D23 is a display unit that displays the deadline (payment due date) when the payment to the payer R is made as a result of the advance payment. In the illustrated example, the payment due date is set to May 31, 2023. Reference symbol D24 is a display unit that displays the total amount of one or more invoices that are the subject of the advance payment application. If one invoice is selected, the total payment amount is the invoice amount of that invoice, and if multiple invoices are selected, the total payment amount is the total amount of the selected multiple invoices. In the illustrated example, 20,600 yen is displayed as the total payment amount. Note that reference symbol D24 may explicitly display the fee of the total payment amount. In the illustrated example, the fee is 600 yen.

[0098] Reference symbol D25 is a button for displaying the terms of use for advance payment. By operating this button, the payer P can refer to the terms of use for advance payment. Reference symbol D26 is a button for applying for advance payment. If there are no errors in the content displayed on the advance payment application screen D20, the payer P can apply for an advance payment by operating reference symbol D26.

[0099] Fig. 15 is a diagram showing an example of a display screen presented on the payer device according to this embodiment, which is displayed after an advance payment application has been made. With reference to the figure, an example of the screen configuration of the advance payment application completion screen D30 will be described. As shown in the figure, the advance payment application completion screen D30 displays content that explicitly indicates that the advance payment application has been completed.

[0100] The advance payment application completion screen D30 may also show the future flow of the process. The future flow of the process is as follows: (1) The advance payer R sends an email to the payer P on the same day to inform them of the acceptance of the application. (2) The advance payer R then conducts an internal review, and informs the payer P of the results of the internal review on the next business day. (3) If the internal review determines that the advance payment is possible, the advance payer R transfers the payment to the biller C by the payment due date. (4) At the beginning of the following month, the advance payer R sends an invoice to the payer P. At the same time as sending the invoice, the payer P is informed of the payment due date.

[0101] Returning to FIG. 11, the detailed flow of the advance payment process performed by the advance payment device 10 according to this embodiment will be described further.

[0102] (Step S25) When an application for advance payment is made, the advance payment device control unit 13 checks the transfer record information (transfer execution data) TRI stored in the transfer record storage unit 121.

[0103] (Step S26) If it is determined that the transfer is possible (advance payment is possible) as a result of checking the transfer record information (transfer execution data) TRI (i.e., step S26; YES), the process proceeds to step S28. If it is determined that the transfer is not possible (advance payment is not possible) (i.e., step S26; NO), the process proceeds to step S27.

[0104] (Step S27) If it is determined that the advance payment is not possible, the advance payment device 10 outputs information indicating that the advance payment is not possible to the payer device 20, and notifies the payer P that the advance payment is not possible.

[0105] (Step S28) If it is determined that the advance payment is possible, the advance payment device 10 executes a transfer process to the biller C, which is indicated in the billing information BI, which is the subject of the advance payment. The advance payment device 10 may execute the transfer process on the payment due date, which is indicated in the billing information BI, which is the subject of the advance payment. By configuring the advance payment device 10 to execute the transfer process on the payment due date, it becomes possible to cancel the application for the advance payment up until the payment due date.

[0106] (Step S29) After the transfer process is performed, automatic transfer settings are made. The detailed flow of the automatic transfer setting process will be described later with reference to FIG.

[0107] Fig. 12 is a third flow chart showing the flow of a series of processes performed by the advance payment device according to this embodiment. With reference to the same figure, the detailed flow of the automatic transfer setting process will be explained. The series of processes shown in the same figure is, in other words, the detailed process of step S29 explained with reference to Fig. 11.

[0108] (Step S31) In the automatic transfer setting process, first, the advance payment device 10 judges whether or not the automatic advance payment setting is set. If the automatic advance payment setting is set (i.e., step S31; YES), the process proceeds to step S32. If the automatic advance payment setting is not set (i.e., step S31; NO), the process ends without setting the automatic advance payment.

[0109] (Step S32) Next, the advance payment device 10 judges whether or not there has been a request from the payer P to turn off the automatic advance payment setting. If the automatic advance payment setting has been turned off by the payer P (i.e., Step S32; YES), the advance payment device 10 ends the process without setting the automatic advance payment.

[0110] (Step S33) If the automatic advance payment setting is set and there is no request from the payer P to turn off the automatic advance payment setting, the automatic advance payment will be performed. In other words, from the next month onwards, the advance payment will be performed automatically without the operation of the payer P.

[0111] FIG. 16 is a diagram showing an example of the screen configuration of the unpaid list screen presented by the payer device according to this embodiment when an application for advance payment is made for a portion of the unpaid amount. With reference to the same figure, an example of the screen configuration of the display screen D40 will be described. The display screen D40 is an example of a display screen displayed when the billing information BI12 is set to advance payment in the state of the payment list screen D10 described with reference to FIG. 13. As shown in the figure, the display screen D40 differs from the payment list screen D10 in that the billing information BI12 is deleted from the reference symbol D13 and a new reference symbol D41 is displayed. In the description of the display screen D40, the same screen configuration as the payment list screen D10 may be omitted by assigning the same reference symbol.

[0112] Reference symbol D41 shows billing information BI for an advance payment. In the illustrated example, reference symbol D41 shows billing information BI12. The billing information BI shown in reference symbol D41 is associated with "client name", "billing amount", "payment due date to client", "payment due date to advance payer", "status", and "automatic advance payment". Of these, "payment due date to client", "payment due date to advance payer", and "automatic advance payment" are items that do not exist in reference symbol D13 which displays the payment list.

[0113] "Payment due date to business partner" is the due date on which payment is made from payer R to biller C for billing information BI for which an advance payment has been made. Since payer R will make the payment on that due date, payer P can cancel the advance payment up until the due date. "Payment due date to advance" is the due date for the new invoice that has been generated by payer R to payer P as a result of the advance payment. "Automatic advance payment" is a selection button that indicates whether or not to make automatic advance payment from the next month onwards. This selection button may be set to ON by default (i.e., to make automatic advance payment).

[0114] In the example shown, specifically, the “customer name” of billing information BI12 is B Shoji, the “billing amount” is 20,000 yen, the “scheduled payment date to customer” is April 30, 2023, the “scheduled payment date to advance payer” is May 31, 2023, the “status” is R being confirmed, and “automatic advance payment” is ON.

[0115] As shown in Fig. 16, the invoice issued by the advancing person R to the payer P as a result of the advance payment and the invoice issued by the claimant C are displayed on the same screen in the same format. In other words, the output unit 14 of the advance payment device 10 presents information to the payer P by outputting the invoice issued by the advancing person R to the payer P as a result of the advance payment and the invoice issued by the claimant C in the same format. By displaying in this manner, the payer P can easily confirm the total payment amount, which is the amount paid to the claimant C and the amount paid to the advancing person R.

[0116] Furthermore, for invoices issued by biller C, information indicating that advance payment is possible is also displayed. Specifically, the "status" item with reference code D13 is in an active state, which can be said to explicitly indicate that advance payment is possible. On the other hand, for invoices issued by payer R to payer P as an advance payment, information indicating that advance payment is not possible is also displayed. Specifically, the "status" item with reference code D41 is in an inactive state, which can be said to explicitly indicate that advance payment is not possible.

[0117] Note that invoices for which advance payment has been made are not presented in code D13. In other words, the advance payment device 10 does not display the same billing information BI in both code D13 and code D41. By displaying only one of them in this way, the payer P can easily check the total amount remaining to be paid.

[0118] Also, in the explanation given with reference to Fig. 16, a case has been described in which an advance payment has been made for one invoice. However, payer P can make an advance payment for multiple invoices. When multiple invoices have been issued by payer R to payer P as a result of an advance payment, they may be displayed as a single invoice in code D41. In other words, multiple invoices that have been paid on behalf of one another may be displayed together as a single invoice in code D41.

[0119] FIG. 17 is an example of the screen configuration of the unpaid bill list screen presented by the payer device according to this embodiment, which is used to confirm which bills have been paid on behalf of the payer. An example of the screen configuration of the display screen D50 will be described with reference to the same figure. The display screen D50 is a modified example of the payment list screen D40 described with reference to FIG. 16. As shown in the figure, the display screen D50 displays display sections D51 and D52. The bill payer P pays to the biller C and the bill payer P pays to the payer R by making the payment on behalf of the payer. The bill payer P pays to the biller C is the billing information BI11 and the billing information BI13. The bill payer P pays to the payer R by making the payment on behalf of the payer is the billing information BI12B. The bill payer P pays to the payer R by making the payment on behalf of the payer is the billing information BI12A. The bill payer P pays to the payer R by making the payment on behalf of the payer is the billing information BI12B. The bill payer D52 shows the bill payable on behalf of the payer. The bill payable on behalf of the payer is the billing information BI12A. The billing information BI12A and the billing information BI12B are generated based on the same invoice.

[0120] FIG. 18 is a diagram showing an example of the screen configuration of the automatic advance payment setting screen presented by the payer device according to this embodiment. With reference to the same figure, an example of the screen configuration of the display screen D60 will be described. The screen configuration includes tabs D611, D612, and D613. The tab D611 is a tab for displaying the automatic advance payment setting screen. The tab D612 is a tab for displaying the credit card information setting screen. The tab D613 is a tab for displaying a notification screen. In the example shown in the figure, the tab D611 is selected, and therefore the automatic advance payment setting screen is displayed.

[0121] Reference symbol D62 is an all-item automatic advance payment setting section. The all-item automatic advance payment setting section has reference symbols D621 and D622 as screen components. Reference symbol D621 is an all-item automatic advance payment setting button. Reference symbol D622 is an advance payment method setting button. Advance payment methods include invoice payment and credit card payment. When the all-item automatic advance payment setting is set by reference symbol D621, the advance payment method can be set by reference symbol D622. In the example shown, the all-item automatic advance payment setting is OFF, so the advance payment method setting button is inactive. By turning the all-item automatic advance payment setting ON, the payer P can automatically make advance payments for all items without having to set it for each individual invoice.

[0122] Reference number D63 is a screen for setting whether or not to make an automatic advance payment for each business partner (i.e., for each biller C). Payer P can set whether or not to make an automatic advance payment for each business partner. If automatic advance payment is set to ON, the advance payment method is set for each business partner. In the example shown, the automatic advance payment setting is OFF for Business Companies A and C. On the other hand, the automatic advance payment setting is ON for Business Company B. The advance payment method for Business Company B is set in the invoice.

[0123] FIG. 19 is a diagram showing an example of a screen configuration of a display screen presented on the payer device according to this embodiment, in which the user selects whether or not to make a payment on behalf of the user when there is an unpaid debt. With reference to the same figure, an example of the screen configuration of the display screen D70 will be described. The display screen D70 is displayed when the payment due date is approaching (for example, within three days of the payment due date) and payment has not been made. The display screen D70 is displayed, for example, based on an instruction from the warning unit 135 described with reference to FIG. 8. The display screen D70 includes the references D71, D72, and D73 as screen components. The display screen D70 displays a message that informs the payer P that the payment due date is approaching. Examples of messages that inform the payer P that the payment due date is approaching include, for example, "There is an invoice for which payment has not been confirmed", "The payment due date for the following invoices is approaching", and "Please pay the shortfall by the payment due date".

[0124] In the reference number D71, the payment amount (unpaid amount) of the invoice whose due date is approaching and the breakdown of the invoice are displayed. As the breakdown of the invoice, for example, the "client name", "billing amount", and "payment due date" are displayed. In the illustrated example, specifically, an invoice with a "client name" of A Shoji Co., Ltd., a "billing amount" of 50,000 yen, and a "payment due date" of 2023 / 4 / 28 (2 days remaining) is described as the invoice information BI21. In addition, an invoice with a "client name" of B Shoji Co., Ltd., a "billing amount" of 20,000 yen, and a "payment due date" of 2023 / 4 / 30 (4 days remaining) is described as the invoice information BI22. In addition, an invoice with a "client name" of C Shoji Co., Ltd., a "billing amount" of 30,000 yen, and a "payment due date" of 2023 / 4 / 30 (4 days remaining) is described as the invoice information BI23.

[0125] Reference symbol D72 is a button used when the payer P wishes to log in to the system and check the details of the invoice described in reference symbol D71. When the advance payment device 10 detects that reference symbol D72 has been operated, it transitions to a login screen, and after logging in, displays the details of the invoice described in reference symbol D71.

[0126] Reference symbol D73 is a button used when the payer P wishes to make an advance payment for the invoice indicated by reference symbol D71. When the advance payment device 10 detects that the invoice D73 has been operated, it may transition to a login screen, and after login, display details of the invoice indicated by reference symbol D71 and prompt the payer P to set up an advance payment.

[0127] FIG. 20 is a block diagram showing an example of the internal configuration of the advance payment device 10 according to this embodiment. At least a part of the functions of the advance payment device 10 can be realized using a computer. As shown in the figure, the computer is configured to include a central processing unit 901, a RAM 902, an input / output port 903, input / output devices 904 and 905, etc., and a bus 906. The computer itself can be realized using existing technology. The central processing unit 901 executes instructions included in a program read from the RAM 902, etc. The central processing unit 901 writes data to the RAM 902, reads data from the RAM 902, and performs arithmetic and logical operations according to each instruction. The RAM 902 stores data and programs. Each element included in the RAM 902 has an address and can be accessed using the address. Incidentally, RAM is an abbreviation for "random access memory." The input / output port 903 is a port through which the central processing unit 901 exchanges data with an external input / output device, etc. The input / output devices 904 and 905 are input / output devices. The input / output devices 904 and 905 exchange data with the central processing unit 901 via the input / output port 903. The bus 906 is a common communication path used inside the computer. For example, the central processing unit 901 reads and writes data in the RAM 902 via the bus 906. Also, for example, the central processing unit 901 accesses the input / output port via the bus 906. Also, all or part of each functional unit provided in the advance payment device 10 may be realized using hardware such as an ASIC, PLD, or FPGA. Also, all or part of each functional unit may be realized by a combination of software and hardware.

[0128] The payer device 20 and the claimant device 30 may have an internal configuration as shown in FIG. 20, similar to the claimant device 30.

[0129] [Summary of the embodiment] As described above, the claimant device 30 includes the claim information acquisition unit 11 to acquire multiple claim information BI, which are claim information BI related to a claim issued from the claimant C to the payer P, the advance device control unit 13 to select claim information BI for a specific payer P from the multiple claim information BI acquired by the claim information acquisition unit 11, the output unit 14 to output the claim information BI selected by the advance device control unit 13, the acquisition unit 15 to acquire information indicating whether or not to make an advance payment according to the claim information BI output by the output unit 14, and the transfer execution unit 16 to execute a transfer process based on the claim information BI indicating that an advance payment will be made. That is, the advance device 10 makes an advance payment for the invoices desired by the payer P among the invoices held by the payer P. For the invoices for which an advance payment has been made, an invoice is issued to the payer P by the advance R. That is, according to the advance device 10, the advance payer R transfers the amount of multiple invoices issued to the payer P, and the advance payer R issues an invoice to the payer P. Therefore, the payer P does not need to perform a transfer process for each of the multiple invoices, but only needs to deal with the invoice issued by the advance payer R. Therefore, according to this embodiment, the payer P can suitably process multiple invoices.

[0130] Furthermore, according to the embodiment described above, there are at least two types of forms of the billing information BI acquired by the billing information acquisition unit 11. As a first form, there is the billing information BI as electronic data provided by the biller C, and as a second form, there is the billing information BI input by the payer P operating an input device (e.g., the payer device 20). The first form is, for example, information acquired from another existing platform. The second form is information input by the payer P himself. In other words, according to the embodiment, it is possible to realize the advance payment system 1 by linking with another existing platform, and it is also possible to realize the advance payment system 1 without linking with another existing platform.

[0131] Furthermore, according to the embodiment described above, the billing information acquisition unit 11 acquires multiple billing information BI requested by multiple billers C, the billing information BI includes information identifying the biller C who issued it, and the transfer execution unit 16 executes a transfer process for the biller C who issued it. Therefore, according to this embodiment, the payer R can make a payment to the biller C based on the billing information BI acquired from the payer P.

[0132] According to the above-mentioned embodiment, in the claimant device 30, when an advance payment is selected, the acquisition unit 15 further acquires information on the payment method after the advance payment. Therefore, according to this embodiment, after the advance payment is made by the advance payer R, the advance payer R can collect the advance amount from the payer P. The information on the payment method after the advance payment may include at least either a credit card payment or a bank transfer payment. Furthermore, the information on the payment method after the advance payment may broadly include a payment agent, a format specified by the Japan Bankers Association for transfers via Internet banking, an external transfer at an ATM or at a bank counter, etc.

[0133] Furthermore, according to the embodiment described above, the information regarding the payment method after advance payment may be different for each claimant C. Therefore, according to this embodiment, the advance payment can be made using a payment method suitable for each claimant C.

[0134] Moreover, according to the above-described embodiment, the advance payment device 10 further comprises an application instruction output unit 17, which outputs billing information BI indicating that an advance payment will be made to the operator OP, and further comprises a transfer data file import unit 18, which imports a transfer data file based on an instruction from the operator OP. The transfer execution unit 16 executes the transfer process based on the transfer data file imported by the transfer data file import unit 18. That is, according to this embodiment, the operator OP can determine whether or not a transfer can be made, and execute the transfer process based on the judgment of the operator OP. Therefore, according to this embodiment, even a business operator that is not registered as an electronic payment agent can carry out the business related to this embodiment.

[0135] According to the embodiment described above, when an advance payment is selected, the acquisition unit 15 further acquires information regarding the payment status for the billing information BI, and the advance device control unit 13 associates the information regarding the payment status acquired by the acquisition unit 15 with the billing information BI. The advance device 10 presents the information regarding the payment status associated with the billing information BI to the payer device 20, by outputting it to the payer device 20. Therefore, according to this embodiment, when making an advance payment, the payer P can easily check the payment status for each billing information BI. Note that, according to the embodiment described above, the information regarding the payment status associated with the billing information BI includes at least an unpaid status.

[0136] Furthermore, according to the above-described embodiment, the acquisition unit 15 acquires information on the payment status of the billing information BI based on the operation of the payer P who has presented the billing information BI and selected whether or not to make an advance payment. In other words, the payer P can manually change the payment status when, for example, the payer P makes a payment to the biller C outside the platform.

[0137] Furthermore, according to the above-described embodiment, the advance device 10, by comprising the virtual account allocation unit 131, refers to the billing information BI acquired by the billing information acquisition unit 11 and allocates a different virtual account to each payer P, by comprising the deposit detection unit 132, it detects that money has been deposited into the virtual account, and by comprising the payment status reconciliation unit 134, it changes the information on the payment status to "paid" based on the information on the deposit into the virtual account. In other words, the advance device 10 can automatically change the payment status.

[0138] Furthermore, according to the above-described embodiment, the advance payment device control unit 13, by being provided with the warning unit 135, issues a warning to the payer according to the period until the payment due date, based on the information on the payment status acquired by the acquisition unit 15. Therefore, the payer P can view information on invoices whose due date is approaching, and can prevent the payment due date from passing. Furthermore, the payer P can change to advance payment for invoices whose due date is approaching, based on the warning. Therefore, according to this embodiment, if the payer P finds it troublesome to process multiple invoices and is unable to process the transfer within the due date, he or she can process the invoices with less effort by changing to advance payment.

[0139] According to the embodiment described above, the acquisition unit 15 acquires information indicating whether or not to perform an automatic advance payment, which is an automatic transfer that is made without the operation of the payer P, in accordance with the billing information BI output by the output unit 14. Furthermore, the transfer execution unit 16 executes a transfer process without the operation of the payer P, based on the billing information BI indicating that an automatic advance payment is to be made. In other words, according to this embodiment, an advance payment can be made automatically. Therefore, the payer P can easily use the advance payment without having to go through the trouble of setting up an advance payment for each billing information BI.

[0140] Furthermore, according to the embodiment described above, the acquisition unit 15 acquires information indicating whether or not to perform automatic advance payment for billing information BI issued by biller C who has never made a transfer. In other words, according to this embodiment, it is possible to set to advance payment even before a single transaction is made.

[0141] Furthermore, according to the embodiment described above, the advance device control unit 13 further includes the automatic advance payment determination unit 136, and determines whether or not automatic advance payment is possible based on transfer record information, which is information on transfers made by the payer in the past. Therefore, according to this embodiment, automatic advance payment is prevented for a payer P with low reliability, and the possibility of collecting the payment can be increased.

[0142] Furthermore, according to the above-described embodiment, the information indicating whether to make an automatic advance payment is set for each item. Since the payer P can decide whether to make an automatic advance payment for each item, the payer P can make an advance payment only for invoices that require an advance payment.

[0143] According to the embodiment described above, the advance payment device control unit 13 sets the automatic advance payment for billing information BI for which information on advance payment has been acquired by the acquisition unit 15 to perform an automatic transfer without the operation of the payer P. Therefore, according to this embodiment, the payer P can set the advance payment to be automatic.

[0144] Furthermore, according to the embodiment described above, the advance payment device control unit 13 sets the advance payment to be performed automatically without the operation of the payer P. That is, according to the embodiment, the advance payment can be performed automatically.

[0145] Furthermore, according to the embodiment described above, after automatic advance payment is set, the advance device control unit 13 cancels the setting of the automatic advance payment based on the operation of the payer. That is, according to this embodiment, although automatic advance payment is set automatically, the payer P who does not want automatic advance payment can cancel the setting of the automatic advance payment.

[0146] According to the above-mentioned embodiment, the output unit 14 outputs the invoice issued by the payer P from the payer R as a result of the advance payment and the invoice issued by the claimant C, thereby presenting them to the payer. Furthermore, the output unit 14 also outputs information indicating that the advance payment is possible for the invoice issued by the claimant C, and also outputs information indicating that the advance payment is not possible for the invoice issued by the payer R as a result of the advance payment. That is, according to this embodiment, an advance payment can be made only once, and the payer P can confirm whether or not he or she has made an advance payment once. Therefore, according to this embodiment, it is possible to prevent delays in payment from the payer P to the payer R by making advance payments multiple times for the same invoice.

[0147] Furthermore, according to the embodiment described above, the output unit 14 does not present invoices for which payment has been made on behalf of the payer P. Therefore, the payer P can check only invoices that need to be paid. Therefore, according to this embodiment, the visibility of information is high.

[0148] Furthermore, according to the above-described embodiment, the presenting unit 22 of the payer device 20 presents an active button to indicate that an advance payment is possible for an invoice issued by the biller C, and presents an inactive button to indicate that an advance payment is not possible for an invoice issued by the advance payer to the payer as a result of an advance payment. In other words, according to this embodiment, an advance payment can only be made once, and the payer P can confirm whether or not he or she has made an advance payment once. Therefore, according to this embodiment, it is possible to prevent delays in payment by making multiple advance payments for the same invoice.

[0149] According to the embodiment described above, the output unit 14 outputs the invoice issued by the payer R to the payer P as a result of the advance payment, and the invoice issued by the biller C to the payer P, thereby presenting them to the payer P. Therefore, according to this embodiment, the payer P can simultaneously check the invoices for which an advance payment has not been made and the invoices for which an advance payment has been made.

[0150] Furthermore, according to the embodiment described above, the output unit 14 presents to the payer P the invoice issued by the payer R to the payer P as a result of the advance payment, and the invoice issued by the biller C, in the same format. According to this embodiment, the payer P can see the invoices for which no advance payment has been made and the invoices for which an advance payment has been made, in the same format, providing high visibility.

[0151] Furthermore, according to the embodiment described above, when there are multiple invoices issued by the advancing person R to the payer P as a result of the advance payment, the output unit 14 outputs them as a single invoice. Therefore, according to this embodiment, the advancing device 10 consolidates multiple invoices into a single invoice and bills the payer P, thereby reducing the effort of the payer P in dealing with multiple invoices.

[0152] In addition, all or part of the functions of each unit of the advance payment device 10 in the above-mentioned embodiment may be realized by recording a program for realizing these functions in a computer-readable recording medium, and reading and executing the program recorded in the recording medium into a computer system. Note that the "computer system" referred to here includes hardware such as the OS and peripheral devices.

[0153] In addition, the term "computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, and storage units such as hard disks built into computer systems. Furthermore, the term "computer-readable recording medium" may also include those that dynamically hold a program for a short period of time, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line, and those that hold a program for a certain period of time, such as a volatile memory inside a computer system that serves as a server or client in such cases. Furthermore, the above program may be one that realizes part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

[0154] Although an embodiment of the present invention has been described above, the present invention is not limited to the above embodiment, and various modifications can be made without departing from the spirit of the present invention. [Explanation of symbols]

[0155] 1...advance payment system, C...biller, P...payer, R...advance payment person, 10...advance payment device, 11...billing information acquisition unit, 12...billing information storage unit, 13...advance payment device control unit, 14...output unit, 15...acquisition unit, 16...transfer execution unit, 20...payer device, 21...payer device control unit, 22...presentation unit, 23...operation reception unit, 30...biller device, BI...billing information, UPI...update information, TI...transfer information, 17...application instruction output unit, 18...transfer data file import unit, 131...virtual account allocation unit, 132...deposit detection unit, 133...payment status acquisition unit, 134...payment status reconciliation unit, 135...warning unit

Claims

1. a billing information acquisition unit for acquiring a plurality of billing information related to a bill issued by a biller to a payer; a control unit that selects the billing information for a specific payer from among the plurality of billing information acquired by the billing information acquisition unit; an output unit that outputs the billing information selected by the control unit; an acquisition unit that acquires information indicating whether or not to make an advance payment in accordance with the billing information output by the output unit; a transfer execution unit that executes a transfer process based on the billing information indicating that an advance payment is to be made; Equipped with The output unit outputs the billing information issued by the payer from the payer on behalf of the payer as well as the billing information issued by the biller, thereby presenting the billing information to the payer. Replacement device.

2. The output unit presents, to the payer, the billing information issued by the payer from the payer as a result of the advance payment and the billing information issued by the biller in the same format. The payment device according to claim 1.

3. The output unit outputs, when there are a plurality of pieces of billing information issued from the payer to the payer as a result of the advance payment, the billing information as a single piece of billing information. The payment device according to claim 1 or 2.

4. 3. An advance payment system comprising: an advance payment device according to claim 1 or 2; a payer device which acquires information on whether or not a payer will make an advance payment based on information from the advance payment device; and a claimant device which acquires information from the advance payment device indicating that a transfer has been made, The payer device comprises: a presentation unit that presents the billing information output from the advance payment device to a payer; an operation receiving unit that receives an operation of a payer to select whether or not to make an advance payment in accordance with the presented billing information; a payer device control unit that outputs information on whether or not to make an advance payment to the advance device based on the accepted operation; An advance payment system that includes:

5. a billing information acquisition step of acquiring a plurality of billing information related to a bill issued by a biller to a payer; a control step of selecting the billing information for a specific payer from among the plurality of billing information acquired by the billing information acquisition step; an output step of outputting the request information selected by the control step; an acquisition step of acquiring information indicating whether or not to make an advance payment according to the billing information output by the output step; a transfer execution step of executing a transfer process based on the billing information indicating that an advance payment is to be made; The output step outputs the billing information issued by the payer from the payer in response to the advance payment and the billing information issued by the biller, thereby presenting the billing information to the payer. Advance payment method.

Images