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

Abstract

To properly process bills.SOLUTION: An advance payment apparatus includes: a bill information linkage unit which acquires bill information by accessing the bill information using bill link information to access the bill information related to bills issued from a requester to payers; an output unit which outputs the bill information; an acquisition unit which acquires advance payment information indicating whether to make advance payment for a bill according to the bill information output by the output unit; and a control unit which executes advance payment on the basis of the advance payment information for which advance payment is to be made.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] The payer performs payment operations for the invoices issued by the claimant. For example, Patent Document 1 discloses a technology that can reduce the expenses incurred for sending invoices by consolidating them and sending them together. [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] However, the above-mentioned technologies have not been sufficient to reduce the burden of invoice processing. For example, entrepreneurs (payers) who operate relatively small-scale businesses, such as sole proprietors, often pay invoices while running their stores, etc., and this can be a burden during busy periods.

[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 processing bills appropriately. [Means for solving the problem]

[0006] (1) One aspect of the present invention is an advance payment device that includes a claim information linking unit that acquires claim information by accessing claim information using claim link information that can access claim information regarding a claim issued by a claimant to a payer, an output unit that outputs the claim information, an acquisition unit that acquires advance payment information indicating whether or not a claim corresponding to the claim information output by the output unit should be an advance payment, and a control unit that executes an advance payment based on the advance payment information indicating that an advance payment should be made.

[0007] (2) In one aspect of the present invention, in the advance payment device described in (1) above, the billing information linking unit acquires the billing information in response to a trigger such as the operation of a billing information linking button provided on an electronic invoice corresponding to the billing information.

[0008] (3) In one aspect of the present invention, in the advance payment device described in (1) or (2) above, the billing information linking unit extracts a notification related to an invoice corresponding to the billing information based on information about the biller registered by the payer, and obtains the billing information from the extracted notification.

[0009] (4) In one aspect of the present invention, in the advance payment device described in (1) to (3) above, the billing link information includes a payment method to the advance payer in the case where the bill corresponding to the billing information is to be paid on behalf of the advance payer, and the output unit outputs the billing information corresponding to the payment method to the advance payer indicated in the billing link information.

[0010] (5) One aspect of the present invention is an advance payment system comprising: an advance payment device described above; and a payer device that acquires advance payment information indicating whether the payer applies for an advance payment based on information from the advance payment device.

[0011] (6) One aspect of the present invention is an advance payment method comprising: a claim information linking step of acquiring claim information by accessing claim information using claim link information that can access claim information related to a claim issued from a claimant to a payer; an output step of outputting the claim information; an acquisition step of acquiring advance payment information indicating whether or not a claim corresponding to the claim information output by the output step should be an advance payment; and a control step of executing an advance payment based on the advance payment information indicating that an advance payment should be made. Effect of the Invention

[0012] According to the present invention, bills can be processed in an optimal manner. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram for explaining an overview of a payment on behalf system according to an embodiment. [Diagram 2] FIG. 1 is a diagram for explaining a payment-on-reimbursement system according to a first embodiment. [Diagram 3] 1 is a block diagram showing an example of the configuration of a payment-on-reimbursement system according to a first embodiment. [Figure 4] FIG. 4 is a diagram showing an example of billing information according to the first embodiment. [Diagram 5] FIG. 4 is a diagram showing an example of payment information according to the first embodiment. [Figure 6] 4 is a flowchart showing the flow of processes performed by the payment advance device according to the first embodiment. [Figure 7] FIG. 4 is a diagram showing a first example of a screen presented on the payer device according to the first embodiment. [Figure 8] FIG. 11 is a diagram showing a second example of a screen presented on the payer device according to the first embodiment. [Figure 9] FIG. 11 is a diagram for explaining a payment-on-reimbursement system according to a second embodiment. [Figure 10] FIG. 11 is a block diagram showing an example of the configuration of a payment-on-reimbursement system according to a second embodiment. [Figure 11]FIG. 11 is a diagram showing a first example of a screen presented on a payer device according to the second embodiment. [Figure 12] 13 is a flowchart showing the flow of processes performed by the payment advance device according to the second embodiment. [Figure 13] FIG. 13 is a diagram showing a second example of a screen presented on the payer device in accordance with the first modification of the second embodiment. [Figure 14] FIG. 13 is a diagram showing a third example of a screen presented on the payer device in accordance with the second modification of the second embodiment. [Figure 15] FIG. 13 is a diagram for explaining a payment-on-replacement system according to a third embodiment. [Figure 16] FIG. 13 is a block diagram showing an example of the configuration of a payment-on-reimbursement system according to a third embodiment. [Figure 17] FIG. 13 is a diagram showing a first example of a screen presented on a payer device according to the third embodiment. [Figure 18] FIG. 13 is a diagram showing a second example of a screen presented on the payer device according to the third embodiment. [Figure 19] FIG. 13 is a diagram showing a third example of a screen presented on the payer device according to the third embodiment. [Figure 20] FIG. 13 is a diagram showing a fourth example of a screen presented on the payer device according to the third embodiment. [Figure 21] 13 is a flowchart showing the flow of processes performed by the payment advance device according to the third embodiment. [Figure 22] FIG. 13 is a diagram showing a first example of a screen presented on the payer device in accordance with the first modified example of the third embodiment. [Figure 23] FIG. 13 is a diagram showing a second example of a screen presented on the payer device in accordance with the first modification of the third embodiment. [Figure 24] FIG. 2 is a block diagram showing an example of an internal configuration of the payment device according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] [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.

[0015] [Overview of the advance payment system] Fig. 1 is a diagram for explaining an overview of an advance payment system according to an embodiment. First, an overview of the advance payment system 1 will be explained with reference to the figure. The advance payment system 1 is used by a claimant C, a payer P, and an advance payer R. There may be multiple claimants C.

[0016] The biller C issues an invoice to the payer P. The payer P receives an invoice from the biller C. The payer P may receive multiple invoices. In the illustrated example, the payer P decides whether or not to make an advance payment for the received invoice. Advance payment here refers to 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. The payer P transmits information about the invoices for which an advance payment is 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 advance payer R obtains information about the invoice to be paid on behalf of the payer P from the payer P. The advance payer R makes a payment to the claimant C based on the obtained invoice information. The advance payer R issues an invoice to the payer P for the combined amount (advance payment) of the invoices for which advance payments have been made. Note that the payer P may add a fee to the payment to the advance payer R. The payer P pays the advance payment and any necessary fees to the advance payer R. By adopting such a configuration, the payer P can request the advance payer R to make a payment instead of paying the claimant C.

[0018] [First embodiment] 2 is a diagram for explaining the advance payment system according to the first embodiment. In this embodiment, the payer P pays the advance payment with future sales. The future sales are the sales of the payer P that will occur after the advance payment is made by the advance payer R.

[0019] In this case, the advance payer R makes a payment to the biller C in response to a request from the payer P, and also purchases the future receivables of the payer P. A future receivable is a receivable that is predicted to arise in the future for the payer P. As a result, when a settlement occurs for the payer P after making an advance payment, a deduction amount according to the settlement amount is made, and remittance is made from the settlement account of the payer P to the account of the advance payer R. In other words, the payer P can pay the advance amount and necessary fees to the advance payer R from future sales. Therefore, according to this embodiment, the payer P can reduce the conventional hassle of processing invoices.

[0020] When payer P selects future sales as the payment method to the advance payer, he sets a deduction rate. The deduction rate is the ratio of the amount paid to advance payer R to the total amount of sales. For example, if the deduction rate is set high, the amount paid to advance payer R will be large, but the payment to the advance payer will be completed in a short period of time. On the other hand, if the deduction rate is set low, the amount paid to advance payer R will be small, but the payment to the advance payer will not be completed unless payments are continued for a long period of time. For example, payer P can set any deduction rate within the range of deduction rates presented by advance payer R.

[0021] The payer R may decide whether or not future sales can be selected as a payment method to the payer on behalf of the payer P, depending on the past sales situation of the payer P. For example, for a payer P who is expected to make a certain amount of sales in the future based on the past payment history, future sales may be selected as a payment method to the payer on behalf of the payer. On the other hand, for a payer P who has just started a business and has not yet accumulated a history of past payments, future sales may not be selected as a payment method to the payer on behalf of the payer.

[0022] In addition, when the payer P, who can select future sales as a payment method to the payer, selects future sales, the advance payer R may determine whether or not to approve payment from future sales depending on the advance amount. That is, the advance payer R may set an upper limit on the advance amount that can be advanced to the payer P by payment from future sales. The advance payer R may change the upper limit of the advance amount every month, or may set the same amount as the upper limit of the advance amount every month.

[0023] [Function configuration] FIG. 3 is a block diagram showing an example of the configuration of the advance payment system according to the first embodiment. With reference to the same figure, an example of the functional configuration of each device included in the advance payment system 1 according to the first embodiment will be described. The advance payment system 1 includes an advance payment device 10, a payer device 20, a claimant device 30, and a payment management device 40. Each functional unit included in the advance payment device 10, the payer device 20, the claimant device 30, and the payment management device 40 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, claimant device 30, and payment management device 40 may exist on, for example, a cloud server. Furthermore, each of the advance payment device 10, payer device 20, claimant device 30, and payment management device 40 may be composed of multiple devices (computers), and each functional block may be distributed across multiple devices.

[0024] The advance payment device 10 is a device operated by the advance payer R. The advance payment device 10 includes, for example, a billing information acquisition unit 11, a billing information storage unit 12, an advance payment device control unit 13, a payer device IF unit 14, a claimant device IF unit 15, and a payment management device IF unit 16.

[0025] 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 may acquire multiple billing information BI. The multiple 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.

[0026] 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.

[0027] 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 via the payer P after the biller C issues the bill to the payer P. Acquisition of the billing information BI may also 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 platformer. 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] [Billing Information] Here, the billing information BI will be described with reference to FIG. 4. FIG. 4 is a diagram showing an example of the billing information BI stored in the billing information storage unit according to this embodiment. 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.

[0032] 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.

[0033] 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.

[0034] 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 -.

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

[0036] The advance payment device control unit 13 controls the advance payment device 10. The advance payment device control unit 13 includes a sales collection unit 130. The process performed by the sales collection unit 130 will be described later.

[0037] The advance device control unit 13 selects billing information BI for an invoice issued to a specific payer from among the multiple billing information BI acquired by the billing information acquisition unit 11 and stored in the billing 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 billing information BI associated with the payer P corresponding to the payer device 20 from the multiple billing information BI stored in the billing information storage unit 12. The advance device control unit 13 outputs the selected billing information BI to the payer device 20 via the payer device IF unit 14.

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

[0039] The payer device IF unit 14 acquires from the payer device 20 information indicating whether or not to make an advance payment, which is a response to the specific billing information SBI output to the payer device 20. 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 to the advance payer. That is, when advance payment is selected, the payer device IF unit 14 may further acquire information on the payment method to the advance payer. In addition, it is preferable that the payer device IF unit 14 acquires information on the payment method to the advance payer for each biller C. The payer device IF unit 14 outputs the acquired advance payment information RPI to the advance payment device control unit 13.

[0040] The payer device 20 may transmit the advance payment information RPI together with the billing information BI. That is, the payer device IF unit 14 may obtain the advance payment information RPI for the billing information BI for which an advance payment is made together with the billing information BI.

[0041] Here, the information on the payment method to the advancing party acquired by the payer device IF unit 14 includes at least payment from future sales. In addition, the information on the payment method to the advancing party preferably includes either payment by credit card or payment by bank transfer. Furthermore, the information on the payment method to the advancing party acquired by the payer device IF unit 14 may broadly include payment agency, Business Payments Solution Provider (BPSP), a format specified by the Japan Bankers Association for transfers via Internet banking, external transfer, etc. Examples of external transfers include transfers at a bank counter and transfers using an automated teller machine (ATM).

[0042] The advance payment device control unit 13 acquires the advance payment information RPI from the payer device IF unit 14, 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 it corresponds to information on whether or not an advance payment is to be made.

[0043] The claimant device IF unit 15 exchanges information with the claimant device 30. The claimant device IF unit 15 executes a transfer process for claimant C based on the claim information BI stored in the claim 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 claim information storage unit 12. The advance device control unit 13 outputs a control signal CI to the claimant device IF unit 15, and the claimant device IF unit 15 executes transfer processing (makes payment to the transfer destination account) for the case subject to transfer processing indicated by the control signal CI. The claimant device IF unit 15 executes transfer processing for the claimant who issued the invoice. As a result of executing the transfer processing, the claimant device IF unit 15 outputs transfer information TI indicating that the transfer processing has been executed to the claimant device 30.

[0044] The payment management device IF unit 16 exchanges information with the payment management device 40. The payment management device IF unit 16 acquires settlement information KI for the payer P based on the billing information BI stored in the billing information storage unit 12, which has already been executed as an advance payment, and which indicates that the payment method to the advance person is a payment transfer from future sales. Whether the payment method to the advance person is a payment transfer from future sales is determined, for example, by the advance device control unit 13 by referring to the billing information storage unit 12.

[0045] [Payment information] Here, the payment information KI will be described with reference to FIG. 5. FIG. 5 is a diagram showing an example of the payment information KI stored in the payment information storage unit according to this embodiment. In the example shown, the payment information KI stored in the payment information storage unit 41 is associated with a "store", a "sales date", a "sales amount", and a "sales product". The "store" is information that identifies the store as the business run by the payer P. The "sales date" is information that identifies the date on which sales were made at the store. The "sales amount requested" is information that indicates the amount of sales made at the store. The "sales product" is information that indicates the product sold at the store.

[0046] [Sales Collection] Here, when the payer P makes a sale, the sales collection section 130 collects the advance by paying all or a part of the sales proceeds of the payer P to the advance payer.

[0047] Returning to FIG. 3, the sales collection unit 130 outputs the payment information request RKI to the payment management device IF unit 16, and the payment management device IF unit 16 outputs the payment information request RKI to the payment management device 40, requesting the payment information KI of the payer P. In response to a request from the payment management device IF unit 16 of the advance payment device 10, the payment management device 40 outputs the payment information KI of the payer P to the advance payment device 10. The payment management device IF unit 16 acquires the payment information KI of the payer P, and outputs the acquired payment information KI to the sales collection unit 130. The sales collection unit 130 determines the deduction amount to be debited from the payment account of the payer P based on the payment information KI. The deduction amount is the amount obtained by multiplying the sales amount by a preset deduction rate. The sales collection unit 130 debits the determined deduction amount from the payment account of the payer P. When the sales collection unit 130 performs the deduction, it updates the billing information BI stored in the billing information storage unit 12. That is, the billing information BI is associated with information indicating that a payment has been made to the payer by updating the information by the sales collection unit 130. For example, the billing information BI is updated so that the amount obtained by subtracting the amount debited from the amount paid on behalf of the payer becomes the amount billed by the payer R to the payer P.

[0048] [Function configuration] Next, a 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 from the payer P as to whether or not to make an advance payment, based on information from the advance device 10. The payer device 20 outputs the information acquired from the payer P as to whether or not to make an advance payment, to the advance device 10.

[0049] The payer device 20 includes a payer device control unit (not shown). The payer device control unit 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 presents the claim information BI to be paid by the payer P to the payer P. The payer device control unit outputs information to be presented by the presentation unit 22 as presentation information DI.

[0050] The payer device 20 includes a presentation unit (not shown). The presentation unit presents the billing information BI output from the advance payment device 10 to the payer P. The presentation unit 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.

[0051] The payer device 20 includes an operation reception unit (not shown). The operation reception unit receives operations from the payer P. The operation reception unit 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 presented on the presentation unit. The operation reception unit receives an operation by the payer selecting whether or not to make an advance payment in accordance with the presented billing information BI. The payer device 20 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.

[0052] Next, a description will be given of the functional configuration of the claimant device 30. The claimant device 30 is a device operated by the claimant C. The claimant device 30 obtains transfer information TI indicating that a transfer has been executed from the advance device 10. The claimant device 30 may also have other functions such as issuing claim information BI to the payer device 20.

[0053] Next, the functional configuration of the payment management device 40 will be described. The payment management device 40 is a device operated by a business operator who manages payments. The payment management device 40 acquires a payment information request RKI requesting payment information KI of the payer P from the advance payment device 10. In response to a request from the advance payment device 10, the payment management device 40 outputs the payment information KI of the payer P to the advance payment device 10. In addition, the payment management device 40 may have a payment function of making payments for businesses conducted by the payer P, such as services provided at a store managed by the payer P.

[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. For example, when a deduction is made from the settlement account of the payer P, the information on the payment status is updated so that the amount obtained by subtracting the deduction amount from the advance amount becomes the billing amount to be claimed from the payer R to the payer P.

[0055] [Flow of processing 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. 6. 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.

[0056] 6 is a flow chart showing the flow of processing 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.

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

[0058] (Step S12) The acquired billing information 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.

[0059] (Step S13) Next, the advance payment device control unit 13 judges whether or not an advance payment application has been made from the payer device 20. An advance payment application is an application by the payer P requesting the advance payment person R to make an advance payment. Here, an advance payment application is made by outputting advance payment information RPI from the payer device 20 to the advance payment device 10.

[0060] When an application for advance payment is made, first, the advance 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 payer device IF 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 (see FIG. 7) for which the payer P is the payment target.

[0061] FIG. 7 is a diagram showing a first example of a screen presented on the payer device according to the first 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.

[0062] 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."

[0063] 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.

[0064] 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 collective selection check box D14 may also be provided. By selecting the collective 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.

[0065] In the example of this figure, 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. In addition, 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. In addition, 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.

[0066] Reference symbol D15 denotes a statement informing the payer P that, when he / she selects advance payment for the invoice indicated by reference symbol D12, he / she may select "future sales" as the payment method to the advance person. When the payer P can select "future sales" as the payment method to the advance person, the advance device 10 may display such a statement to clearly indicate that "future sales" is selectable as the payment method to the advance person.

[0067] Regarding D15, the advance device control unit 13 judges whether or not "future sales" by the payer P is selectable as a payment method to the advance person based on the billing information BI output to the payer device 20. The advance device control unit 13 judges whether or not "future sales" is selectable based on, for example, the sales record of the payer P. For example, if the payer P has sales exceeding a certain amount each month, it judges that "future sales" is selectable for that payer P. In this case, the advance device 10 outputs the billing information BI and the judgment result by the advance device control unit 13 (the judgment result of judging whether or not "future sales" is selectable as a payment method to the advance person) to the payer device 20 via the payer device IF unit 14. As a result, in the unpaid list as shown in FIG. 7, it is possible to display, together with the bill described in D12, that "future sales" is selectable as a payment method to the advance person as shown in D15.

[0068] On the other hand, if the payer P does not have sales exceeding a certain amount each month, or if the payer P has no track record of sales, such as when the payer P has just started its business, the advance payment device control unit 13 does not allow the payer P to select "future sales." In this case, the advance payment device 10 outputs the billing information BI and the determination result by the advance payment device control unit 13 (determination result indicating that "future sales" is not selectable as a payment method for the advance payment person) to the payer device 20 via the payer device IF unit 14. This enables the advance payment device 10 to not display the wording indicated by reference symbol D15 in the unpaid amount list as shown in FIG. 7.

[0069] Here, the advance device control unit 13 may set an upper limit (upper limit amount) of the amount for which the payment method to the advance person can be set to "future sales" based on the sales record of the payer. For example, when the monthly sales amount of the payer P is equal to or more than the first threshold value and the annual sales amount is equal to or more than the second threshold value, the advance device control unit 13 sets an amount equivalent to a predetermined ratio (e.g., 20%) of the first threshold value as the upper limit amount. Alternatively, the amount obtained by multiplying the second threshold value by a predetermined ratio (e.g., 1%) is set as the upper limit amount. In this way, by setting the upper limit amount based on not only the monthly sales amount but also the annual sales amount, even if the payer P has a large fluctuation in monthly sales amount, such as a business operator that handles seasonal products, an appropriate upper limit amount can be set for that payer P.

[0070] In addition, the advance device control unit 13 may vary the upper limit amount from month to month. For example, in the case of a payer P whose sales amount fluctuates greatly from month to month, it is expected that the fluctuation in the invoice amount from month to month will also be large, such as the invoice amount being larger in months when seasonal products are purchased compared to other months. In such a case, by varying the upper limit amount from month to month, it is possible to set an appropriate upper limit amount for that month for that payer P.

[0071] The advance device control unit 13 allows the selection of future sales when the billing amount related to the billing information BI does not exceed a preset upper limit based on the payer's sales performance. In this case, when advance payment is selected in the billing information BI, the advance device control unit 13 determines whether or not the billing amount related to the selected billing information BI exceeds the upper limit. When the billing amount related to the selected billing information BI does not exceed the upper limit, the advance device control unit 13 displays the message related to code D15. On the other hand, when the billing amount related to the selected billing information BI exceeds the upper limit, the advance device control unit 13 does not display the message related to code D15.

[0072] Furthermore, the advance device control unit 13 may display the "upper limit" set for the payer P, instead of or together with the reference symbol D15. In this case, the advance device 10 outputs the billing information BI and the determination result by the advance device control unit 13 (the determination result indicating that "future sales" is selectable as a payment method to the advance person within a range not exceeding the "upper limit") to the payer device 20 via the payer device IF unit 14. This allows the advance device 10 to clearly indicate the "upper limit" for which "future sales" is selectable as a payment method to the advance person in an unpaid amount list as shown in FIG. 7.

[0073] Furthermore, the advance device control unit 13 may display the "maximum amount" set for the payer P, regardless of the billing amount related to the billing information BI selected as the advance payment, and display that the payment method to the advance person can be payment by "future sales" within the range not exceeding the "maximum amount". In this case, the advance device 10 outputs the billing information BI and the determination result by the advance device control unit 13 (determination result indicating that "future sales" can be selected as the payment method to the advance person within the range not exceeding the "maximum amount") to the payer device 20 via the payer device IF unit 14. In this way, the advance device 10 can clearly display in the unpaid amount list as shown in FIG. 7 that "future sales" can be selected as the payment method to the advance person within the range not exceeding the "maximum amount".

[0074] Furthermore, the advance device control unit 13 may display that the payment method to the advance payer can be used in combination with the "future sales" payment method and other payment methods (for example, a payment method by credit card, a payment method by bank transfer, etc.). In this case, the advance device 10 outputs the billing information BI and the determination result by the advance device control unit 13 (the determination result indicating that "future sales" can be selected as a payment method to the advance payer to the extent that it does not exceed the "upper limit amount", and that the remaining amount can be paid by other payment methods) to the payer device 20 via the payer device IF unit 14. In this way, the advance device 10 can clearly indicate in the unpaid amount list as shown in FIG. 7 that "future sales" can be selected as a payment method to the advance payer to the extent that it does not exceed the "upper limit amount", and that the remaining amount can be paid by other payment methods.

[0075] Fig. 8 is a display screen presented on the payer device according to the first embodiment, showing an example of a screen configuration displayed before an advance payment application is made. Fig. 8 shows a screen displayed on the payer device 20 when, for example, advance payment is selected as a result of the payer device 20 presenting billing information BI in Fig. 7. An example of the screen configuration of the advance payment application screen D20 will be described with reference to the figure.

[0076] Reference symbol D21 is a selection button for selecting a payment method to the payer. In the figure, reference symbols D211 and D212 are shown as examples of selection buttons for selecting a payment method to the payer. When reference symbol D211 is selected, payer P makes payment to payer R using "future sales". When reference symbol D212 is selected, payer P makes payment to payer R by credit card. Either of the selection buttons for selecting a payment method to the payer may be selected exclusively. Note that buttons showing other possible payment methods may be provided as selection buttons for selecting a payment method to the payer.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 10, if "future sales" is selected as the payment method to the payer in step S13 (i.e., step S13; YES), the process proceeds to step S14. If "future sales" is not selected as the payment method to the payer in step S13 (i.e., step S13; NO), the process proceeds to step S16.

[0081] (Step S14) The advance payment device 10 executes an advance payment and also purchases the future claim of the payer P. First, the advance payment device 10 executes an advance payment. The advance payment device 10 executes a transfer process for the claimant 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 indicated in the billing information BI, which is the subject of the advance payment. By configuring the 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. Next, the advance payment device 10 purchases the future claim of the payer P. In step S13, the payer P applies for an advance payment with "future sales" selected as the payment method to the advance payment device, thereby selling the claim that will arise according to future sales to the advance payment device R as a future claim. The advance payment device 10 executes an advance payment and thereby purchases the future claim of the payer P.

[0082] (Step S15) The advance device 10 collects the advance payment according to the sales (future sales) of the payer P that occur after the advance payment in step S14. The sales collection unit 130 acquires the payment information KI from the payment management device 40 via the payment management device IF unit 16, and when sales occur by the payer P based on the acquired payment information KI, collects the advance payment by debiting all or part of the sales of the payer P to the account of the advance payer R.

[0083] (Step S16) The advancing device 10 executes the advancing payment. The method by which the advancing device 10 executes the advancing payment is the same as that in step S14.

[0084] [Summary of the first embodiment] As described above, the advance payment device 10 according to the first embodiment includes a billing information acquisition unit 11, an advance payment device control unit 13 (control unit), and a payer device IF unit 14 (output unit). The billing information acquisition unit 11 acquires billing information BI. The advance payment device control unit 13 determines whether or not the payer P can select "future sales" as a payment method to the advance payment person based on the billing information BI. The payer device IF unit 14 outputs the billing information BI and the determination result of the control unit's determination of whether or not future sales can be selected as a payment method to the advance payment person. In this way, the advance payment device 10 according to the first embodiment can present to the payer P the determination result of whether or not future sales can be selected as a payment method to the advance payment person when making an advance payment for an invoice issued to the payer P. If future sales is selected, not only can the invoice be paid on advance payment, but the payment to the advance payment person can be debited from future sales. Therefore, the payer P can reduce the hassle of money transactions and can concentrate on his business. That is, bills can be processed efficiently.

[0085] [Second embodiment] FIG. 9 is a diagram for explaining the advance payment system according to the second embodiment. In this embodiment, the payer P can link the billing information BI to the advance payment device 10 based on the matters registered in advance. For example, the payer P registers in advance in the advance payment device 10 that an invoice issued by a specific biller C will be paid on behalf of the payer P. In this case, when the specific biller C issues an invoice addressed to the payer P, the advance payment device 10 stores the billing information BI related to the invoice in the billing information storage unit 12. Then, an advance payment application related to the billing information BI is output to the payer device 20. As a result, the payer P can execute the process related to the invoice by simply responding to the advance payment application notified by the advance payment device 10, without opening the PDF of the invoice issued by the biller C to check the amount or printing it.

[0086] [Function configuration] FIG. 10 is a block diagram showing an example of the configuration of an advance payment system according to the second embodiment. With reference to the same figure, an example of the functional configuration of each device included in the advance payment system 1 according to the second embodiment will be described. Note that a description of the same configuration as in the first embodiment may be omitted. In the second embodiment, the advance payment system 1 includes an invoice issuing device 50. The advance payment device 10 includes an invoice issuing device IF unit 17. Furthermore, the advance payment device 10 includes a billing information linking unit 131 in the advance payment device control unit 13.

[0087] The invoice issuing device 50 is a device operated by a business entity that issues invoices. The invoice issuing device 50 is a device that issues electronic invoices (e.g., a PDF file of an invoice). The invoice issuing device 50 is, for example, an invoice issuing system built on an existing platform. By using an existing platform, it becomes easy to link billing information BI between the advance payment device 10 and the invoice issuing device 50. Linking of billing information BI can be performed, for example, by using an API or the like. The biller device 30 may be used as the invoice issuing device 50.

[0088] The invoice issuing device IF unit 17 exchanges information with the invoice issuing device 50 .

[0089] The billing information linking unit 131 stores the billing information BI in the billing information storage unit 12 based on the items registered in advance by the payer P. In this way, the billing information BI is linked.

[0090] Here, the items registered in advance by payer P are, for example, information related to the bill that is the subject of an advance payment application. For example, when an invoice issued by a specific biller C is to be paid in advance, payer P registers information related to that specific biller C in advance. The information related to the specific biller C is sufficient as long as it is information that at least enables identification of the invoice that biller C issues to payer P. For example, the information related to the specific biller C can be the URL (Uniform Resource Locator) of the site that stores the invoice that biller C issues to payer P.

[0091] The billing information linking unit 131 requests the invoice issuing device 50 to notify the payer P of the billing link information BIL when issuing an invoice addressed to the payer P by a specific biller C, based on the items registered in advance by the payer P. The billing link information BIL is information that enables access to the invoice issued by the biller C to the payer P. For example, the billing link information BIL is information that includes the URL of the site where the invoice issued by the invoice issuing device 50 is stored, and a program (linking program) for linking invoices generated using an API or the like.

[0092] The advance payment device 10 may provide the link program to the invoice issuing device 50, thereby requesting the invoice issuing device 50 to notify the payer P of the invoice link information BIL.

[0093] The invoice issuing device 50 generates an electronic invoice with an association function, for example, an invoice with an operation button for executing an association program, and stores the generated electronic invoice on a specified site. The invoice issuing device 50 notifies the payer P that an invoice has been issued by a specific biller C to the payer P by sending the URL of the site to the payer device 20.

[0094] 11 is a diagram showing an example of a screen (bill screen) presented on the payer device according to the second embodiment. With reference to the drawing, an example of the screen configuration of the bill screen D30 will be described.

[0095] Reference symbol D31 is a billing information linking button. The billing information linking button is an example of "billing link information BIL." The billing information linking button is set in association with billing link information BIL. When it is detected that the billing information linking button of reference symbol D31 has been operated, a transition is made to a login screen for the advance payment service provided by the advance payment system 1, and after logging in, an operation is performed to link the billing information BI.

[0096] Reference number D32 displays the amount billed on the invoice. Reference number D33 displays the breakdown of the billed amount. Reference number D34 displays the transfer account number. In the example shown in the figure, specifically, the "billed amount" is 20,600 yen. The breakdown is four pieces of sample AA1, each with a unit price of 4,000 yen, and two pieces of sample AA2, each with a unit price of 2,000 yen.

[0097] When the payer device 20 is notified of the issuance of an invoice by the invoice issuing device 50, it displays an electronic invoice with a linking function as shown in FIG. 11. The payer P visually checks the displayed electronic invoice and operates the invoice link information BIL. When the invoice link information BIL is operated, the linking program is executed. When the linking program is executed, the billing information linking unit 131 accesses the site corresponding to the URL, downloads the electronic invoice stored on the site, and stores the billing information BI related to the downloaded electronic invoice in the billing information storage unit 12. This causes the billing information BI to be linked.

[0098] When the invoice issuing device 50 issues an invoice addressed to the payer P, it notifies the payer device 20 of the invoice link information BIL corresponding to the issued invoice.

[0099] Returning to FIG. 10, the payer device 20 outputs the billing link information BIL notified from the invoice issuing system to the advance payment device 10. The billing information linking unit 131 acquires the billing link information BIL via the payer device IF unit 14. The billing information linking unit 131 outputs the acquired billing link information BIL via the invoice issuing device IF unit 17. As a result, the billing information linking unit 131 accesses a site where the billing information BI in the invoice issuing device 50 is stored. The billing information linking unit 131 acquires the billing information BI stored in the accessed site. For example, the billing information linking unit 131 acquires the billing information BI via the invoice issuing device IF unit 17 by performing an operation to download the billing information BI. The billing information linking unit 131 stores the acquired billing information BI in the billing information storage unit 12.

[0100] 12 is a flowchart showing the flow of the process performed by the advance payment device according to the second embodiment. With reference to this figure, the flow of the process performed by the advance payment device 10 to link billing information BI will be described.

[0101] (Step S20) First, the billing link information BIL is notified to the payer device 20. The invoice issuing device 50 issues an invoice addressed to the payer P, and notifies the payer device 20 of the billing link information BIL corresponding to the issued invoice.

[0102] (Step S21) The billing link information BIL is operated in the payer device 20. The billing information link information BIL is operated by, for example, clicking the billing information link button D31 of the electronic bill presented by the payer device 20.

[0103] (Step S22) When the billing link information BIL is operated, the billing information linking unit 131 accesses the billing information BI. The billing information linking unit 131 accesses the billing information BI by accessing the site where the electronic bill is stored as a result of the linking program being executed.

[0104] (Step S23) When the billing information BI is accessed, the billing information linking unit 131 downloads the billing information BI and stores the downloaded billing information BI in the billing information storage unit 12. When the billing information linking unit 131, which has accessed the site, executes an operation to download the billing information BI, the invoice issuing device 50 outputs the billing information BI to the advance payment device 10. The billing information linking unit 131 acquires the billing information BI output from the invoice issuing device 50 via the invoice issuing device IF unit 17. The billing information linking unit 131 stores the acquired billing information BI in the billing information storage unit 12.

[0105] (Step S24) After storing the billing information BI in the billing information storage unit 12, the advancing device 10 executes an advancing payment in response to an application for advancing payment from the payer P. The advancing device 10 acquires advancing payment information RPI from the payer device 20, and when an application for advancing payment is made in the acquired advancing payment information RPI, it executes processing for executing an advancing payment in response to the application.

[0106] [Summary of the second embodiment] As described above, the advance payment device 10 according to the second embodiment includes a billing information linking unit 131, an advance payment device control unit 13, and a payer device IF unit 14. The billing information linking unit 131 acquires the billing information BI by accessing the billing information BI based on the billing link information BIL. For example, the billing information linking unit 131 accesses the billing information BI by accessing a site indicated in the billing link information BIL, downloads the billing information BI from the site, and stores the downloaded billing information BI in the billing information storage unit 12. The payer device IF unit 14 outputs the billing information BI associated with the billing information linking unit 131 to the payer device 20. The payer device IF unit 14 acquires advance payment information RPI indicating whether or not the bill corresponding to the billing information BI output to the payer device 20 is to be paid on behalf of the payer. The advance payment device control unit 13 executes an advance payment based on the advance payment information RPI indicating that an advance payment is to be made. For example, the advance payment device control unit 13 executes a transfer process corresponding to the invoice for which advance payment is to be made (performs payment to the transfer destination account) via the claimant device IF unit 15. This allows the advance payment device 10 according to the second embodiment to link billing information BI.

[0107] [Modification 1 of the second embodiment] Here, a first modification of the second embodiment will be described. In this modification, the billing link information BIL itself is notified to the payer P instead of or together with the electronic bill.

[0108] FIG. 13 is a diagram for explaining the first modified example of the second embodiment. This modified example will be described with reference to the same figure. FIG. 13 shows an example in which a biller C (A Corporation in the example of this figure) notifies the fact that an invoice has been issued via an SNS. As shown in the example of this figure, the notification of the issuance of an invoice includes, for example, a message M1 indicating that the invoice has been issued, and billing link information BIL1 for linking the issued invoice. The payer P operates the billing link information BIL1 shown in the notification by clicking on it, for example. As a result, the linking program is executed as in the second embodiment. When the linking program is executed, the billing information linking unit 131 accesses a site corresponding to the URL, downloads an electronic invoice stored on the site, and stores the billing information BI related to the downloaded electronic invoice in the billing information storage unit 12. As a result, the billing information BI is linked. As a result, invoices can be linked without opening the electronic invoices one by one, reducing the effort of operations related to linking and improving convenience. In addition, the invoice issuing device 50 can also omit the effort of generating an electronic invoice with a linking function.

[0109] In addition, in the example shown in this figure, an example is shown in which billing link information BIL2 for checking the contents of the invoice is also notified together with billing link information BIL1. In this way, billing link information BIL1 and BIL2 may be notified. This allows invoices to be linked, the contents of the invoice to be displayed, and operations according to the purpose to be possible.

[0110] In addition, in this modified example, the billing link information BIL corresponding to the payment method to the payer may be notified. For example, together with a message M such as "Click here to select payment method X as the payment method to the payer", billing link information BIL for setting payment method X as the payment method to the payer is notified. Any payment method can be applied as payment method X, such as future sales, invoice (bank transfer), credit card, payment agency, BPSP, etc. In this case, the billing information BI is linked, and billing information BI related to the advance payment application in which payment method X is selected as the payment method to the payer in the linked billing information BI is output from the advance payment device 10 to the payer device 20. As a result, the advance payment device 10 links the bills and can display on the payer device 20 an advance payment application screen (for example, a screen as shown in FIG. 8) in which the payment method intended by the payer P has already been selected. The payer P can apply for an advance payment by simply visually checking the application content for the advance payment, confirming that there are no errors in the application content, and clicking the application button (reference symbol D26). This not only enables invoices to be linked, but also allows the entire process, including applying for advance payment using the intended payment method, to be carried out in one stop.

[0111] [Modification 2 of the second embodiment] Here, a second modification of the second embodiment will be described. In this modification, a preset email or SNS related to the issuance of an invoice notified by the biller C is linked, and billing information BI is extracted from the linked email or SNS.

[0112] E-mails and SNS messages related to invoice issuance are often sent from a specific sender address. Furthermore, the titles of e-mails and SNS messages related to invoice issuance often contain specific wording, for example, "Notice of invoice issuance." Taking advantage of this property, in this modified example, e-mails and SNS messages related to invoice issuance are extracted using a specific sender address, a title containing specific wording, or the like as a key, and the extracted e-mails and SNS messages are uploaded by outputting them to the advance payment device 10.

[0113] In this modification, for example, information related to invoice notification is registered as information related to a specific biller C registered in advance by the payer P. Information related to invoice notification is, for example, information indicating the sender address and subject of an email or SNS message indicating that an invoice has been issued. The information related to invoice notification may include the name of the specific biller C.

[0114] The billing information linking unit 131 extracts an e-mail (or SNS) notified from a specific sender address (billant C) or the like based on the items registered in advance by the payer P. For example, web scraping or RPA (Robotics Process Automation) can be used as a technique for extracting a specific e-mail (or SNS). For example, the billing information linking unit 131 generates an RPA for linking an invoice, and outputs the generated RPA to the payer device 20. The payer device 20 acquires the RPA notified from the advance device 10. When the payer P executes the RPA with a specific application (e.g., an email application), the e-mail (or SNS) notified from the specific sender address (billant C) is extracted, and the extracted e-mail (or SNS) is output to the advance device 10.

[0115] Fig. 14 is a diagram for explaining modified example 2 of the second embodiment. This modified example will be explained with reference to the same figure. Fig. 14 shows a screen D50 for uploading a file on the page of a user (payer P) of the advance payment service provided by the advance payment system 1. The uploaded file is stored in the billing information storage unit 12.

[0116] Reference symbol D51 is an area that displays the file to be uploaded. Reference symbol D510 is a button that is operated when adding (uploading) a file. Reference symbol D511 displays the uploaded file name. For example, in the absence of RPA, in order to upload an invoice, payer P extracts the invoice PDF that he / she wants to upload, logs into the advance payment service, accesses the user (payer P) page, transitions to screen D50 for uploading files, and uploads the file by dragging and dropping the invoice PDF file into the area displayed as reference symbol D51. On the other hand, in the presence of RPA, payer P only needs to execute RPA, and a series of operations are automatically executed, enabling the desired invoice to be linked, reducing the effort required for linking operations and improving convenience.

[0117] By using RPA, it is possible to perform uploading according to the wishes of the payer P. For example, it is possible to create an RPA that automatically uploads the invoice PDF displayed on the payer device 20.

[0118] [Modification 3 of the second embodiment] Here, a third modification of the second embodiment will be described. In this modification, automatic registration is performed. Automatic registration means linking invoices related to a specific biller C, without relying on registration by the payer P. By performing automatic registration, the payer P can reduce the effort required to register information related to a specific biller C.

[0119] The advance payment device 10 determines a specific biller C to be automatically registered based on the performance of past advance payment applications by the user (payer P). For example, when the payer P applies for an advance payment for an invoice issued by a specific biller C, the advance payment device 10 performs registration so that from the next time onwards, invoices issued by that biller C are automatically linked to the advance payment system. This allows the advance payment device 10 to perform automatic registration.

[0120] The advance payment device 10 may be configured to notify the fact that automatic registration has been performed by email or SNS. Alternatively, when the billing information BI is linked by automatic registration, the advance payment device 10 may be configured to notify the fact that the link has been performed by email or SNS. In addition, the advance payment device 10 may be configured to cause the payer device 20 to display a screen related to an advance payment application corresponding to the billing information BI linked by automatic registration.

[0121] Furthermore, if the payer P has applied for an advance payment in the past, automatic registration may be performed according to the payment method selected for the advance payment to the advance payer. From the next time onwards, invoices issued by the biller C are automatically linked according to the payment method for the advance payer. In this case, the advance payment device 10 may cause the payer device 20 to display a screen on which the payment method has already been selected in the advance payment application corresponding to the billing information BI linked by automatic registration.

[0122] [Third embodiment] Fig. 15 is a diagram for explaining an advance payment system according to the third embodiment. As shown in the figure, in this embodiment, payer P makes a payment via BPSP as a payment method to an advance payer. In a payment via BPSP, the BPSP company settles the credit card payment to payer P, and the BPSP company makes a payment to biller C. By selecting payment via BPSP, payer P can make a payment by credit card to biller C, who does not accept credit card payments.

[0123] [Function configuration] FIG. 16 is a block diagram showing an example of the configuration of an advance payment system according to the third embodiment. With reference to the same figure, an example of the functional configuration of each device included in the advance payment system 1 according to the third embodiment will be described. Note that a description of the same configuration as in the first embodiment may be omitted. In the third embodiment, the advance payment system 1 includes a credit card company device 60. The advance payment device 10 includes a credit card company device IF unit 18. Furthermore, the advance payment device 10 includes an application confirmation unit 132 in the advance payment device control unit 13.

[0124] The credit card company device 60 is a device operated by a credit card issuing business. The credit card issuing business may be the same business as the business that performs the advance payment related to the advance payment device 10, or it may be a different business. In response to an inquiry from the advance payment device 10, the credit card company device 60 outputs the available credit card balance at the time of the inquiry. The "available credit" here is the amount obtained by subtracting the "used balance" from the "available credit line (limit)". The "available credit line" is the upper limit of the amount that can be used with the credit card. The "used balance" is the amount of the credit card that is currently unpaid to the credit card company. For example, if 400,000 yen has already been used out of the available credit line of 1 million yen, the available credit is 600,000 yen (1 million - 400,000) yen.

[0125] The credit card company device IF section 18 exchanges information with the credit card company device 60 .

[0126] The application confirmation unit 132 acquires the advance payment information RPI. The application confirmation unit 132 acquires the advance payment information RPI output from the payer device 20 via the payer device IF unit 14. Based on the acquired advance payment information RPI, the application confirmation unit 132 determines whether or not payment by BPSP has been selected as the payment method to the advance payer in the advance payment application. If payment by BPSP has been selected, the application confirmation unit 132 determines whether or not payment by BPSP can be made.

[0127] The application confirmation unit 132 identifies the credit card selected as the card to be used for payment by the BPSP, based on the advance payment information RPI. The application confirmation unit 132 outputs a card usage information request RAI inquiring about the available credit card balance of the identified credit card to the credit card company device IF unit 18. The credit card company device IF unit 18 outputs the card usage information request RAI to the credit card company device 60. In response to the inquiry from the advance payment device 10, the credit card company device 60 outputs card usage information AI indicating the available credit card balance to the advance payment device 10. The credit card company device IF unit 18 acquires the card usage information AI output from the credit card company device 60, and outputs the acquired card usage information AI to the application confirmation unit 132. The application confirmation unit 132 acquires the card usage information AI via the credit card company device IF unit 18.

[0128] Based on the card usage information AI, the application confirmation unit 132 obtains the available balance of the credit card selected as the card to be used for payment by the BPSP. The application confirmation unit 132 compares the billing amount related to the billing information BI with the available balance. If the billing amount related to the billing information BI does not exceed the available balance of the credit card, the application confirmation unit 132 determines that it can be used for payment by the BPSP. On the other hand, if the billing amount related to the billing information BI exceeds the available balance of the credit card, the application confirmation unit 132 determines that it cannot be used for payment by the BPSP.

[0129] FIG. 17 is a diagram showing an example of a display screen presented on the payer device according to the third embodiment, which is displayed before an application for advance payment is made.

[0130] Fig. 17 is the same screen as Fig. 8, but differs from Fig. 8 in that BPSP is selected in reference symbol D71 (corresponding to the selection button reference symbol D21 in Fig. 8). That is, Fig. 17 shows an example in which BPSP is selected as the payment method to the payer.

[0131] Also, reference number D72 (corresponding to reference number D22 in Fig. 8, the number of invoices that are the subject of the advance payment application) differs from Fig. 8 in that three invoices are the subject of the advance payment application. In other words, Fig. 17 shows an example in which the number of invoices that are the subject of the advance payment application is multiple.

[0132] Fig. 18 is a display screen presented on the payer device according to the third embodiment, and shows an example of the configuration of a card selection screen displayed when BPSP is selected as the payment method to the payer in an advance payment application. Fig. 18 shows a screen displayed on the payer device 20 when, for example, the symbol D76 in Fig. 17 is clicked. An example of the screen configuration of the card selection screen D80 will be described with reference to the same figure.

[0133] Reference symbol D81 and reference symbol D24 display the total amount of one or more invoices (e.g., three) that are the subject of the advance payment application. Reference symbol D82 displays a list of one or more invoices that are the subject of the advance payment application. This list is associated with the "business partner name," "invoice amount," and "scheduled payment date." The "business partner name," "invoice amount," and "scheduled payment date" are items that are determined at the time the billing information acquisition unit 11 acquires the billing information BI.

[0134] Reference symbol D83 displays a list of credit cards that can be selected as cards to be used for payments via the BPSP. This list is of card information (e.g., card number, expiration date, and name, etc.) that has been registered in advance by the payer P. In this way, multiple cards may be registered as cards to be used for payments via the BBPSP. The payer P can select for each card whether it will be used for payments via the BPSP. 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 independently. In the example shown in the figure, the check box for card A2 is checked (i.e., card A2 is selected as the card to be used for payments via the BPSP).

[0135] Reference numeral D84 displays the available credit limit of 100,000 yen for the credit card selected in reference numeral D83, which in this example is card A2.

[0136] In the field D85, a warning is displayed to the effect that the advance payment amount exceeds the available amount. The advance payment amount in this case is the total amount of the three invoices that are the subject of the advance payment application, as shown in the field D81.

[0137] Code D86 is a content confirmation button. When the content confirmation button is operated, detailed content is displayed when the payment method to the advance payer is set to payment by BSPS in the advance payment application. Payer P can confirm detailed content when payment is made by BSPS by operating code D26.

[0138] In this embodiment, when a warning is displayed in D85, that is, when the advance amount exceeds the available amount, the content confirmation button in D86 is controlled so as not to be operable.

[0139] 19 is a diagram showing an example of a screen configuration displayed on a payer device according to the third embodiment when BPSP is selected as the payment method to the payer in an advance payment application. An example of the screen configuration of the card selection screen D90 will be described with reference to the same figure.

[0140] Figure 19 is a card selection screen equivalent to that of Figure 18, but differs from Figure 18 in that card A3 is selected in reference D93 (corresponding to the credit card list of reference D83 in Figure 18). That is, Figure 19 shows an example in which card A3 is selected as the card to be used for payment by BPSP.

[0141] In this case, 200,000 yen is displayed as the available balance on card A3 in D94. Then, D95 displays that the advance payment amount is within the available balance. In this case, the content confirmation button in D96 is displayed so that it can be operated. That is, in this embodiment, if no warning is displayed in D95 and the advance payment amount is within the available balance, the content confirmation button in D96 is controlled so that it can be operated. This allows the advance payment application to proceed only when the advance payment amount is within the available balance. Then, an advance payment application that exceeds the available balance (one in which payment by BPSP is selected as the payment method to the advance payer) cannot be executed.

[0142] 20 is a diagram showing an example of a screen configuration displayed on a payer device according to the third embodiment when BPSP is selected as the payment method to the payer in an advance payment application. An example of the screen configuration of the application content confirmation screen D100 will be described with reference to the same figure.

[0143] Fig. 20 shows an application content confirmation screen D100 that is displayed when the content confirmation button related to reference character D96 in Fig. 19 is operated. Reference characters D101 to D103 correspond to reference characters D91 to D93 in Fig. 19.

[0144] Reference symbol D104 displays the available amount after advance payment. This available amount after advance payment is the available amount before the advance payment is made, i.e., the available amount of 200,000 yen displayed as reference symbol D94 in FIG. 19 minus the advance payment amount of 103,000 yen. This available amount after advance payment is displayed before the advance payment is made. In other words, it is the available amount that has not yet been recognized by the credit card company. The advance payment device 10 can display this available amount after advance payment without making an inquiry to the credit card company device 60. The payer P can grasp the available amount after advance payment before the actual credit card settlement is made.

[0145] Reference symbol D105 displays a message asking whether it is OK to apply with this content. Reference symbol D106 is a button that is operated when payer P recognizes that it is OK to apply with this content. Reference symbol D107 is a button that is operated when changing the application content.

[0146] Fig. 21 is a flowchart showing the flow of processing performed by the advance payment device according to the third embodiment. With reference to the same figure, the flow of processing in which the advance payment device 10 links billing information BI will be described. This flowchart is based on the premise that an application for advance payment of an invoice has been made.

[0147] (Step S30) The advance payment device 10 judges whether or not "BPSP" has been selected as the payment method to the advance payer in the advance payment application. If "BPSP" has been selected as the payment method to the advance payer (i.e., step S30; YES), the process proceeds to step S31. If "BPSP" has not been selected as the payment method to the advance payer (i.e., step S30; NO), the process ends.

[0148] (Step S31) The payment advance device 10 causes the payer device 20 to display a card selection screen (eg, FIG. 18 or FIG. 19).

[0149] (Step S32) The advance payment device 10 judges whether or not the payer P has selected a card to be used for the BPSP payment (Step S32). If the payer P has selected a card to be used for the BPSP payment (i.e., Step S32; YES), the process proceeds to Step S33. If the payer P has not selected a card to be used for the BPSP payment (i.e., Step S32; NO), the process returns to Step S32.

[0150] (Step S33) When a card to be used for payment via BPSP is selected, the advance payment device 10 inquires about the available credit card balance of the selected credit card and obtains the available balance. The advance payment device 10 outputs a card usage information request RAI inquiring about the available balance to the credit card company device 60, and obtains the available balance based on card usage information AI, which is the response obtained from the credit card company device 60. The advance payment device 10 displays the obtained available balance on the card selection screen.

[0151] (Step S34) The advance device 10 judges whether the advance amount is within the available amount. If the advance amount is within the available amount (i.e., step S34; YES), the process proceeds to step S35. If the advance amount exceeds the available amount (i.e., step S34; NO), the process proceeds to step S36.

[0152] (Step S35) The advance payment device 10 enables transition to an application content confirmation screen (eg, FIG. 20), calculates the available amount after advance payment, and displays the available amount after advance payment on the application content confirmation screen.

[0153] (Step S36) The advance payment device 10 does not allow transition to the application content confirmation screen (eg, FIG. 20), and displays a warning to the effect that the advance payment amount exceeds the available credit on the card selection screen.

[0154] In the above-mentioned flow chart, when a credit card is selected, the available credit card balance is displayed, but this is not limited to the above. The available credit card balance may be displayed only when the advance payment amount exceeds the available credit card balance. In other words, when the advance payment amount is within the range of the available credit card balance (the advance payment amount is equal to or less than the available credit card balance), the available credit card balance may not be displayed.

[0155] [Summary of the third embodiment] As described above, the advance payment device 10 according to the third embodiment includes a billing information acquisition unit 11, an application confirmation unit 132, and a payer device IF unit 14 (acquisition unit). The billing information acquisition unit 11 acquires billing information BI. The payer device IF unit 14 acquires advance payment information RPI indicating whether or not the bill corresponding to the billing information BI is to be an advance payment. When payment by BPSP is selected as the payment method to the advance payment person in the advance payment information RPI indicating that an advance payment is to be made, the application confirmation unit 132 determines whether or not to approve payment by BPSP according to the relationship between the available balance of the credit card used for the BPSP and the advance payment amount (amount of the advance payment according to the billing information BI). In this way, the advance payment device 10 according to the third embodiment can prevent the BPSP from being executed when the advance payment amount exceeds the available balance.

[0156] [Modification 1 of the third embodiment] Here, a first modified example of the third embodiment will be described. In this modified example, a card selection screen is displayed with all selectable credit cards selected as cards to be used for payment by BPSP as the initial screen.

[0157] 22 is a diagram showing an example of a card selection screen configuration presented on the payer device according to Modification 1 of the third embodiment. With reference to the same figure, an example of the screen configuration of the card selection screen D110 will be described.

[0158] The symbols D111 and D112 are equivalent to the symbols D81 and D82 in FIG.

[0159] Reference symbol D113 is equivalent to reference symbol D83 in Fig. 8, but differs from Fig. 8 in that all credit cards displayed in the list are selected. Also, it differs from Fig. 8 in that, together with the words "Select credit card", the words "Cards not to be used for BPSP can be set to unselected" are displayed.

[0160] In this case, code D114 displays 1,000,000 yen as the total available balance for all cards selected in code D113, i.e., cards A1 to A4. Code D95 displays that the advance amount is within the available balance. In this case, a content confirmation button in code D96 is displayed so that it can be operated.

[0161] Reference symbol D115 is an operation button for "setting credit card details." In this way, in this embodiment, when multiple cards are selected as credit cards to be used for BPSP, the details of the amount to be used from each credit card can be set.

[0162] 23 is a diagram showing an example of a screen configuration of a breakdown setting screen for setting the breakdown of the amount to be used from a credit card, which is a display screen presented on a payer device according to the third embodiment. An example of the screen configuration of the breakdown setting screen D120 will be described with reference to the same figure.

[0163] Reference D122 displays a list of credit cards that the card can use for BPSP. In this list, an "available amount," an "advance amount," and an "available amount after advance" are associated with each credit card. The "available amount" is the available amount of the credit card. The "advance amount" is the amount to be paid from the credit card (advance amount). The "available amount after advance" is the amount obtained by subtracting the amount to be paid from the credit card (advance amount) from the available amount of the credit card. The advance device 10, for example, calculates the advance amount according to the available amount of the credit card as a breakdown. For example, the advance device 10 pays a larger advance amount to the credit card with a larger available amount. And it pays a smaller advance amount to the credit card with a smaller available amount.

[0164] Reference characters D123 to D125 correspond to reference characters D105 to D107 in FIG.

[0165] In this way, in this modified example, the initial screen shows all credit cards registered as cards to be used with the BPSP selected, and the payer P selects credit cards to be excluded from that list. This increases the available credit limit, making it easier to set up payments with the BPSP. Since sole proprietors can use personal cards, they often use multiple credit cards for their business. In such cases, it would be very convenient if multiple cards could be combined and used with the BPSP.

[0166] In addition, in this modification, if multiple credit cards are selected as cards to be used for BPSP, a breakdown of the amount to be paid from each card is presented. This eliminates the need for payer P to check the breakdown of each card, as the breakdown is presented even when multiple credit cards are used for payment, and makes the process less complicated.

[0167] FIG. 24 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.

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

[0169] 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.

[0170] 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.

[0171] 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]

[0172] 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 (control unit), 14...payer device IF unit 14 (output unit), 15...biller device IF unit, 16...payment management device IF unit, 17...invoice issuing device IF unit, 18...credit card company device IF unit, 130...sales collection unit, 131...billing information linking unit, 132...application confirmation unit, 20...payer device, 30...biller device, 40...payment management device, 50...invoice issuing device, 60...credit card company device, BI...billing information, UPI...update information, TI...transfer information

Claims

1. a claim information linking unit that acquires the claim information by accessing the claim information using claim link information that allows access to the claim information related to a claim issued by a claimant to a payer; an output unit that outputs the request information; an acquisition unit that acquires advance payment information indicating whether or not the claim corresponding to the claim information output by the output unit is to be an advance payment; a control unit that executes an advance payment based on the advance payment information indicating that an advance payment is to be made; A payment device comprising:

2. the billing information linking unit acquires the billing information in response to a trigger of a billing information linking button provided on an electronic bill corresponding to the billing information being operated; The payment device according to claim 1.

3. The billing information linking unit extracts a notice related to an invoice corresponding to the billing information based on information about the biller registered by the payer, and acquires the billing information from the extracted notice. The payment device according to claim 1.

4. the billing link information includes a payment method for a person who pays on behalf of the bill in response to the billing information, the output unit outputs the billing information corresponding to the payment method to the payer indicated in the billing link information. The payment device according to claim 1.

5. The payment device according to any one of claims 1 to 4, a payer device that acquires advance payment information indicating whether the payer applies for an advance payment based on information from the advance payment device; An advance payment system that includes:

6. a claim information linking step of acquiring the claim information by accessing the claim information using claim link information that allows access to the claim information issued by the claimant to the payer; an output step of outputting the request information; an acquisition step of acquiring advance payment information indicating whether or not the bill corresponding to the billing information output by the output step is to be an advance payment; a control step of executing an advance payment based on the advance payment information indicating that an advance payment is to be made; A payment method having the above structure.

Images