Information processing system, information processing method, and program

Abstract

To provide an information processing system, information processing method, and program, which allow for performing processing for making on-behalf-of payments of bills.SOLUTION: An information processing system disclosed herein provides a service that makes on-behalf-of payments of bills. The information processing system comprises a reception unit for receiving a bill of a user from a bill platform, and a generation unit configured to generate service price information for notifying the user of a price of an on-behalf-of payment when the on-behalf-of payment was made for the bill of the user received by the reception unit.SELECTED DRAWING: Figure 8

Description

[Technical field]

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

[0002] Bills or statements for utility bills, telephone bills, insurance premiums, tuition fees, credit payments, taxes, etc. are sent to users individually by mail from electric power companies, gas companies, telephone companies, insurance companies, credit card companies, etc. It is also well known that payments for such bills or statements are made by automatic transfer or automatic remittance to a bank account owned by the user. Regarding the sending of payment invoices or statements, there is known technology that sends invoices and statements together in a single package, while reducing the enormous expenses incurred by each billing company in carrying out the sending operations (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

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

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

[0005] An object of the present invention is to provide an information processing system, an information processing method, and a program capable of processing for advancing a payment of a bill. [Means for solving the problem]

[0006] (1) One aspect of the present invention is an information processing system providing a service of advancing the payment of an invoice, the information processing system comprising: a reception unit that accepts a user's invoice from an invoice platform; and a creation unit that creates service fee information to notify the user of the fee for the advance payment when the reception unit advances the payment of the user's invoice accepted by the reception unit. (2) One aspect of the present invention is an information processing system as described in (1) above, wherein the reception unit receives an integration application from the invoice platform to integrate the user's account with the service, and the information processing system further includes an integration processing unit that performs processing to integrate the user's account with the service based on the integration application, and the creation unit creates the service fee information when the integration processing unit advances an invoice for the user for which the integration processing unit has performed the integration processing. (3) One aspect of the present invention is an information processing system as described in (1) above, further comprising an integration processing unit that performs processing to integrate the user's account with the service, wherein the integration processing unit creates an integration application for linking the user's account with the service, and the creation unit creates the service fee information when the integration processing unit advances the invoice for the user for whom the integration processing unit has performed the integration processing. (4) One aspect of the present invention is an information processing system as described in (2) or (3) above, wherein the creation unit creates coordination information for notifying the user who has performed the processing in which the coordination processing unit coordinates, of information indicating the content of the service. (5) One aspect of the present invention is an information processing system as described in (1) above, wherein the creation unit creates the service fee information in response to the user logging in to the service. (6) One aspect of the present invention is the information processing system described in (1) above, wherein the creation unit creates the service fee information at a predetermined cycle. (7) One aspect of the present invention is an information processing system as described in (1) above, further comprising a transfer execution unit that advances payment of the user's invoice, and the creation unit updates the service fee information when the transfer execution unit advances payment of the invoice. (8) One aspect of the present invention is the information processing system described in (1) above, wherein the creation unit updates the service fee information when a fee for the advance payment is paid.

[0007] (9) One aspect of the present invention is an information processing method executed by a computer, which accepts an invoice for a user from an invoice platform, and, when the invoice is paid in advance for the user, creates service fee information to notify the user of the fee for the advance payment.

[0008] (10) One aspect of the present invention is a program that causes a computer to execute the steps of accepting a user's invoice from an invoice platform and, when the invoice for the user accepted in the accepting step is paid in advance, creating service fee information to notify the user of the fee for the advance payment. Effect of the Invention

[0009] According to the present invention, it is possible to obtain an effect that a process for advancing payment of a bill can be carried out. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram for explaining an overview of a payment-on-reimbursement system according to an embodiment of the present invention. [Diagram 2] FIG. 13 is a diagram for explaining an example of a case where a payer makes an advance payment for a portion of an invoice in the advance payment system according to the present embodiment. [Diagram 3] FIG. 2 is a functional configuration diagram for explaining an example of the functional configuration of each device included in the advance payment system according to the present embodiment. [Figure 4] 5 is a diagram showing an example of information stored in a billing information storage unit according to the embodiment; FIG. [Diagram 5] This is a diagram to explain an example of a case in which a biller in this embodiment issues an invoice from the head office and each branch office. [Figure 6] 11 is a diagram showing an example of information stored in the billing information storage unit when a payer issues a bill from the head office and each branch office according to the present embodiment. FIG. [Figure 7] FIG. 13 is a functional configuration diagram showing a modified example of the payment device according to the present embodiment. [Figure 8] 4 is a functional configuration diagram showing an example of a detailed functional configuration of a payment-advancement device control unit according to the present embodiment. FIG. [Figure 9] 10 is a functional configuration diagram showing an example of a functional configuration when the payment-on-demand device according to the present embodiment performs a cooperative process with a server. FIG. [Figure 10] 4 is a flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 11] FIG. 13 is a diagram showing an example of a screen configuration of a payment list screen presented by the payer device according to the embodiment. [Figure 12] 4 is a flowchart showing the flow of a series of processes performed by the advance payment device according to the present embodiment. [Figure 13] FIG. 13 is a diagram showing an example of a display screen presented on the payer device according to the present embodiment, the screen configuration being displayed before an application for advance payment is made. [Figure 14] FIG. 13 is a diagram showing an example of a display screen presented on the payer device according to the present embodiment, the screen configuration being displayed after an application for advance payment has been made. [Figure 15A] 4 is a flowchart showing the flow of a series of processes performed by the advance payment system according to the present embodiment. [Figure 15B] 4 is a flowchart showing the flow of a series of processes performed by the advance payment system according to the present embodiment. [Figure 16] FIG. 13 is a diagram showing an example of a screen configuration of a possible link list screen presented by the payer device according to the embodiment. [Figure 17] 4 is a flowchart showing the flow of a series of processes performed by the advance payment system according to the present embodiment. [Figure 18] 4 is a flowchart showing the flow of a series of processes performed by the advance payment system according to the present embodiment. [Figure 19] 2 is a block diagram showing an example of an internal configuration of the payment device according to the present embodiment. FIG. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] [Embodiment] Hereinafter, the information processing system, the information processing method, and the program according to the aspects of the present invention will be described in detail with reference to the accompanying drawings, showing preferred embodiments. 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 appropriately combined. In addition, various omissions, substitutions, or modifications of the components can be made without departing from the gist of the present invention. In addition, 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.

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

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

[0014] The payer P receives an invoice from the biller C. The payer P receives invoices issued by each of the multiple billers C. In the illustrated example, the payer P receives invoice A from the biller C1, invoice B from the biller C2, and invoice C from the biller C3. The payer P decides whether or not to make an advance payment for each of the received invoices.

[0015] Here, advance payment is a method in which an advance payer R makes a payment to a biller C on behalf of a payer P. The illustrated example shows a case in which an advance payment is made for all received invoices (i.e., invoice A, invoice B, and invoice C). The payer P sends information about the invoices for which an advance payment is to be made to the advance payer R. Note that the payer P may send information about all received invoices to the advance payer R, together with information about which invoices are to be paid in advance.

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

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

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

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

[0020] [Function configuration] Fig. 3 is a functional configuration diagram for explaining an example of the functional configuration of each device included in the advance payment system according to this embodiment. With reference to the same figure, an example of the functional configuration of each device included in the advance payment system 1 will be explained. The advance payment system 1 includes an advance payment device 10, a payer device 20, and a claimant device 30. Each functional unit included in the advance payment device 10, the payer device 20, and the claimant device 30 is realized using, for example, an electronic circuit. Furthermore, each functional unit may include internal storage means such as a semiconductor memory or a magnetic hard disk device, as necessary.

[0021] Each function may be realized by a computer having a CPU (Central Processing Unit) and software. All or part of each functional unit may 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 part of each functional unit may be realized by a combination of software and hardware. All or part of the functions of the advance payment device 10, the payer device 20, and the claimant device 30 may exist on, for example, a cloud server. Each of the advance payment device 10, the payer device 20, and the claimant device 30 may be composed of multiple devices (computers), and each functional block may be distributed across multiple devices.

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

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

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

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

[0026] The link with the systems of other platforms may be performed, for example, through an API (Application Programming Interface). Furthermore, in order to link with systems of other platforms, the payer R may provide an SDK (Software Development Kit) to the existing systems of other platforms, or the SDK may be provided on an OEM basis. As a linking method, a service for paying invoices on behalf of the systems of other platforms that will become partners may be embedded, or information may be linked from the systems of other platforms that will become partners to the pay-by-advance device 10 according to this embodiment. The case where the pay-by-advance device 10 performs the pay-by-advance process by linking with a platform will be described later.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0048] In addition, some of the payers R are not registered as agents for electronic settlement, etc. In such cases, the advance payment device 10 may be configured to perform the transfer service with the intervention of an operator OP. Hereinafter, as a modified example of the advance payment device 10, an example of a case where the advance payment device 10 is configured to perform the transfer service with the intervention of an operator OP will be described with reference to the drawings.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0064] The notification information creation unit 135 creates service fee information for notifying the payer P of the fee for the advance payment. For example, when the status of the billing information BI changes from "advance payment completed" to "unpaid (waiting for transfer)" as a result of the biller C making an advance payment of the payer P's invoice, the notification information creation unit 135 creates service fee information for notifying the payer P of the fee for the advance payment. When the status of the billing information BI changes from "unpaid" to "paid," the notification information creation unit 135 updates the service fee information. When the status of the billing information BI is unpaid, the notification information creation unit 135 issues a warning (alarm) in accordance with the payment due date. The notification information creation unit 135 issues a warning to the payer P in accordance with the period until the payment due date, based on information on the payment status of the billing information BI stored in the billing information storage unit 12. For example, the notification information creation unit 135 issues a warning to the payer P when the period until the payment due date is within three days. The warning may be issued, for example, by presenting information to the payer P via the presentation unit 22 provided in the payer device 20.

[0065] [An example of a case where the advance payment device 10 performs processing in cooperation with an existing platform] Next, an example of the case where the advance payment device 10 performs processing to link with an existing platform will be described. An example of an existing platform is an invoice platform. The invoice platform acquires an invoice issued by the biller C. The invoice platform may also issue an invoice on behalf of the biller C. Whether or not to link may be selected, for example, by the payer P. The payer P selects whether or not to link, and the selected information is acquired by the acquisition unit 15. This information includes the account of the payer P.

[0066] The linking process may be performed by the advance payment device control unit 13. That is, when the acquisition unit 15 acquires information to be linked, the advance payment device control unit 13 performs linking process with the server 40 functioning as an invoice platform. Fig. 9 is a functional configuration diagram showing an example of the functional configuration when the advance payment device according to this embodiment performs a linking process. With reference to the same figure, an example of a case where an advance payment device 10 applies for linking to the invoice platform when the payer P selects linking with the invoice platform will be described. In this case, in the advance payment device 10, the billing information acquisition unit 11 further comprises a reception unit 111, and the advance payment device control unit 13 further comprises a linking processing unit 136. In the explanation of the same figure, explanation of the configuration that has already been explained may be omitted.

[0067] The server 40 includes a billing information storage unit 42, a server control unit 43, an output unit 44, and an acquisition unit 45. The billing information storage unit 42 accumulates multiple billing information BI. The billing information storage unit 42 is configured to include a hard disk drive, a solid state drive, a flash memory, a ROM, etc. The billing information storage unit 42 does not have to exist as a hardware configuration equipped in the server 40, and may exist in, for example, a storage device connected via a network. An example of information stored in the billing information storage unit 42 can be the billing information BI stored in the billing information storage unit 12, so a description thereof will be omitted.

[0068] The server control unit 43 selects billing information BI for an invoice issued to a specific payer from among the multiple billing information BI stored in the billing information storage unit 42. This process may be triggered by, for example, an execution instruction from the advance payment device 10. When the server control unit 43 acquires the execution instruction from the advance payment device 10, it selects billing information BI associated with the payer P corresponding to the payer device 20 from among the multiple billing information BI stored in the billing information storage unit 42. The server control unit 43 outputs the selected billing information BI to the advance payment device 10 via the output unit 44.

[0069] The output unit 44 outputs the billing information BI selected by the server control unit 43 to the advance payment device 10. The billing information BI selected by the server control unit 43 is the billing information BI associated with a specific payer P. In the server control unit 43, the cooperation processing unit 411 performs processing to cooperate with the account of the payer P and the service of paying an invoice on behalf of the advance payment device 10. For example, the cooperation processing unit 411 may acquire a cooperation application from the advance payment device 10 via the acquisition unit 45, and perform cooperation processing via the API based on the acquired cooperation application. The cooperation application includes the account of the payer P.

[0070] In this case, payer P selects whether or not to cooperate, and the selected information is acquired by the acquisition unit 45. In the server control unit 43, the collaboration processing unit 411 creates a collaboration application for linking the payer P's account with the service of paying an invoice on behalf of the advance payment device 10. The collaboration application created by the collaboration processing unit 411 is sent to the advance payment device 10. In the advance payment device 10, the collaboration processing unit 136 acquires the collaboration application. The collaboration processing unit 136 performs collaboration processing with the collaboration processing unit 411 via the API based on the acquired collaboration application.

[0071] Furthermore, in the advance payment device control unit 13, the cooperation processing unit 136 may create a cooperation application for cooperation when performing processing to cooperate between the account of the payer P and the service of paying an invoice on behalf of the advance payment device 10. The cooperation application created by the advance payment device 10 is transmitted to the server 40. The cooperation application includes the account of the payer P. The cooperation processing unit 411 acquires the cooperation application. The cooperation processing unit 411 may perform cooperation processing with the cooperation processing unit 136 via an API based on the acquired cooperation application. After the billing information acquisition unit 11 completes the process of linking payer P's account with the service, the reception unit 111 acquires payer P's billing information BI from the server 40 and accepts the acquired billing information of payer P.

[0072] The payer P may select multiple services for advancing the payment of an invoice. In this case, information indicating the selected services is acquired by the acquisition unit 15 of each of the multiple advancing devices providing the service of advancing the payment of an invoice. In each of the multiple advancing devices, the cooperation processing unit 136 creates a cooperation application for cooperation. The cooperation application created by each of the multiple advancing devices is transmitted to the server 40. In the server 40, the cooperation processing unit 411 acquires the multiple cooperation applications. The cooperation processing unit 411 may perform cooperation processing via an API with the cooperation processing unit 136 of each of the multiple advancing devices.

[0073] Furthermore, information indicating the service selected by payer P may be acquired by the acquisition unit 45 in the server 40. In this case, in the server control unit 43, the coordination processing unit 411 may acquire information indicating the information indicating the service from the acquisition unit 45, and create a coordination application for coordinating the account of payer P with a service of paying an advance for an invoice provided by each of the multiple advance devices based on the acquired information. The coordination application created by the coordination processing unit 411 is transmitted to each of the multiple advance devices. In each of the multiple advance devices, the coordination processing unit 136 acquires the coordination application. The coordination processing unit 136 may perform coordination processing with each of the coordination processing units 411 of the multiple advance devices via an API.

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

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

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

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

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

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

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

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

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

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

[0084] In the illustrated example, billing information BI11, billing information BI12, and billing information BI13 are displayed as unpaid billing information BI. Specifically, the "customer name" of billing information BI11 is A Shoji, the "billing amount" is 50,000 yen, the "scheduled payment date" is April 28, 2023, the "status" is unpaid, and the "advance payment selection" is not selected. The "customer name" of billing information BI12 is B Shoji, the "billing amount" is 20,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and the "advance payment selection" is not selected. The "customer name" of billing information BI13 is C Shoji, the "billing amount" is 30,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and the "advance payment selection" is not selected. Returning to FIG. 10, the description of the flow of a series of processes performed by the payment advance device 10 according to this embodiment will be continued.

[0085] (Step S14) When the payer device 20 presents the billing information BI and advance payment is selected (Step S14; YES), the advance device 10 advances the process to Step S15. On the other hand, when advance payment is not selected (Step S14; NO), the advance device 10 advances the process to Step S16. (Step S15) When advance payment is selected, the advance payment device 10 performs an advance payment process for the billing information BI for which advance payment has been selected. A detailed flow of the advance payment process will be described later with reference to FIG. (Step S16) If advance payment is not selected, the payer P performs payment processing by a payment agent, transfer via internet banking, ATM, or other method. As a result of making payment by these methods, the payer P changes the status to "paid."

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

[0087] (Step S21) The advance payment device 10 acquires a payment method for each piece of billing information BI from the payer P. Here, the selection of the payment method may be performed individually for each piece of billing information BI, or may be performed collectively for multiple pieces of billing information BI. (Step S22) If a batch request has been made (Step S22; YES), the process proceeds to Step S24. If an individual request has been made (Step S22; NO), the process proceeds to Step S23. (Step S23) If an individual request is made, the request is made for each payment statement.

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

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

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

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

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

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

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

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

[0096] Returning to FIG. 12, the detailed flow of the advance payment process performed by the advance payment device 10 according to this embodiment will be described further. (Step S25) When an application for advance payment is made, the advance payment device control unit 13 checks the transfer record information (transfer execution data) TRI stored in the transfer record storage unit 121. (Step S26) If it is determined that the transfer is possible (advance payment is possible) as a result of checking the transfer record information (transfer execution data) TRI (Step S26; YES), the process proceeds to Step S28. If it is determined that the transfer is not possible (advance payment is not possible) (Step S26; NO), the process proceeds to Step S27.

[0097] (Step S27) If it is determined that the advance payment is not possible, the advance payment device 10 outputs information indicating that the advance payment is not possible to the payer device 20, and notifies the payer P that the advance payment is not possible. (Step S28) If it is determined that the advance payment is possible, the advance payment device 10 executes a transfer process to the biller C, which is indicated in the billing information BI, which is the subject of the advance payment. The advance payment device 10 may execute the transfer process on the payment due date, which is indicated in the billing information BI, which is the subject of the advance payment. By configuring the advance payment device 10 to execute the transfer process on the payment due date, it becomes possible to cancel the application for advance payment up until the payment due date. (Step S29) After the transfer process is completed, service fee information is created.

[0098] 15A is a flow chart showing the flow of a series of processes performed by the advance payment system according to this embodiment. With reference to this figure, a case where a cooperation application is made from the server 40 side to the advance payment device 10 will be described. (Step S31-1) When the payer P performs an operation to create an association application for linking with the service to the payer device 20, the operation reception unit 23 accepts the operation. The payer device control unit 21 creates the association application based on the operation accepted by the operation reception unit 23. (Step S32-1) The payer device 20 transmits the created link application to the server 40 functioning as a bill platform that is to be linked with the service. (Step S33-1) In the server 40, the cooperation processing unit 411 acquires the cooperation application transmitted by the payer device 20, and creates a cooperation application to be transmitted to the advance payment device 10 based on the acquired cooperation application.

[0099] (Step S34-1) In the server 40, the output unit 44 acquires a cooperation application from the cooperation processing unit 411, and transmits the acquired cooperation application to the payment advance device 10. (Step S35-1) In the payment-advance device 10, the cooperation processing unit 136 acquires a cooperation application and judges whether or not to approve the cooperation based on the acquired cooperation application. Here, the explanation will be continued on the case where the cooperation processing unit 136 judges that the cooperation is approved. If the cooperation is not approved, a predetermined error process is performed. The cooperation processing unit 136 creates a cooperation response. The cooperation response may include information indicating the contents of the approved service. (Step S36-1) In the payment advance device 10, the output unit 14 acquires a link response from the link processing unit 136, and transmits the acquired link response to the server 40.

[0100] (Step S37-1) In the server 40, the cooperation processing unit 411 acquires a cooperation response from the payment-advance device 10, and creates cooperation information including information indicating the contents of the service approved based on the acquired cooperation response. (Step S38-1) In the server 40, the output unit 44 acquires the linkage information from the linkage processing unit 411, and transmits the acquired linkage information to the payer device 20 of the payer P. (Step S39-1) The payer device 20 receives the linkage information transmitted by the server 40, and the payer device control unit 21 acquires the linkage information. The presentation unit 22 acquires the linkage information from the payer device control unit 21, and displays information indicating the content of the approved service based on the linkage information.

[0101] 15B is a flowchart showing the flow of a series of processes performed by the advance payment system according to this embodiment. With reference to the same figure, a detailed flow of the cooperation process between the advance payment device 10 and the invoice platform will be described in the case where an application for cooperation is made from the advance payment device 10 to the server 40. (Step S31-2) When the payer P performs an operation to create an association application for linking with the service to the payer device 20, the operation reception unit 23 accepts the operation. The payer device control unit 21 creates the association application based on the operation accepted by the operation reception unit 23. (Step S32-2) The payer device 20 transmits the created cooperation application to the advance payment device 10 providing the service. (Step S33-2) In the advance payment device 10, the cooperation processing unit 136 acquires the cooperation application transmitted by the payer device 20, and creates a cooperation application to be transmitted to the server 40 based on the acquired cooperation application.

[0102] (Step S34-2) In the payment advance device 10, the output unit 14 acquires the cooperation application from the cooperation processing unit 136, and transmits the acquired cooperation application to the server 40. (Step S35-2) In server 40, cooperation processing unit 411 acquires the cooperation application, and judges whether or not to approve the cooperation based on the acquired cooperation application. Here, the explanation will be continued on the case where cooperation processing unit 411 judges that the cooperation is approved. If the cooperation is not approved, a predetermined error process is performed. (Step S36-2) In the server 40, the cooperation processing unit 411 creates cooperation information including information indicating the contents of the approved service.

[0103] (Step S37-2) In the server 40, the output unit 44 acquires the linkage information from the linkage processing unit 411, and transmits the acquired linkage information to the payer device 20 of the payer P. (Step S38-2) The payer device 20 receives the linkage information transmitted by the server 40, and the payer device control unit 21 acquires the linkage information. The presentation unit 22 acquires the linkage information from the payer device control unit 21, and displays information indicating the content of the approved service based on the linkage information.

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

[0105] The possible collaboration list screen D40 includes information D42 indicating the total amount of unpaid amounts, an unpaid amount list D43, information D45 indicating deferred payment services, and an application button D46. The information D42 showing the outstanding amount may include, for example, a fee. In the example shown, the total outstanding amount is "72,100 yen." It is preferable that the amount of the fee included in the outstanding amount is presented so that it can be easily recognized. In the example shown, the fee is "2,100 yen."

[0106] The unpaid amount list D43 displays billing information BI that is unpaid by payer P who can make a deferred payment using the "deferred payment service A" shown in the information D45 indicating the deferred payment service described below (i.e., the payment from payer P to biller C has not been completed). The billing information BI is associated with "business partner name", "billing amount", "scheduled payment date", "status", and "deferred payment application selection". Of these, "business partner name", "billing amount", and "scheduled payment date" are items that are determined at the time the invoice is issued. "Status" and "deferred payment application selection" are items that can be changed by payer P or the advance payment device 10.

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

[0108] The payer P can select the deferred payment service for each billing information BI. Each billing information BI is provided with a check box for selecting whether or not to apply for the deferred payment service, 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., the application for the deferred payment service is not selected). A bulk selection check box D44 may also be provided. By selecting the bulk selection check box D44, the payer P can select advance payment for all billing information BI, thereby reducing the effort of selecting each one one by one. In the example shown in the figure, the bulk selection check box D44 is not checked (i.e., the application for the deferred payment service is not selected in bulk).

[0109] In the illustrated example, billing information BI11 and billing information BI12 are displayed as billing information BI for unpaid bills of payer P who can use the deferred payment service A. Specifically, the "business partner name" of billing information BI11 is A Commercial Corporation, the "billing amount" is 50,000 yen, the "scheduled payment date" is April 28, 2023, the "status" is unpaid, and the "deferred payment application selection" is not selected. Also, the "business partner name" of billing information BI12 is B Commercial Corporation, the "billing amount" is 20,000 yen, the "scheduled payment date" is April 30, 2023, the "status" is unpaid, and the "deferred payment application selection" is not selected. If the deferred payment application selection is selected (checked by pressing) by payer P and the application button D46 is pressed, the operation reception unit 23 in the payer device 20 accepts the operation. The payer device control unit 21 creates a linkage application including information indicating post-payment service A and the account of the payer P, based on the operation accepted by the operation acceptance unit 23. The linkage application created by the payer device control unit 21 is transmitted to the server 40 or the advance device that provides post-payment service A.

[0110] 17 is a flowchart showing the flow of a series of processes performed by the advance payment system according to this embodiment. With reference to the same figure, an example of the process in which the payer device 20 acquires service fee information from the advance payment device 10-1 and the advance payment device 10-2 will be described. (Step S41) The payer P operates the payer device 20 to log in to the payment system 1. (Step S42) In the payer device 20, the payer device control unit 21 creates a service fee information request for requesting service fee information. (Step S43) In the payer device 20, the payer device control unit 21 transmits the created service fee information request to the advance payment device 10-1.

[0111] (Step S44) In the advance payment device 10-1, the acquisition unit 15 acquires the service cost information request sent by the payer device 20. The notification information creation unit 135 acquires the service cost information request from the acquisition unit 15, and creates a service cost information response including service cost information based on the acquired service cost information request. (Step S45) In the payment advance device 10-1, the output unit 14 acquires the service fee information response from the notification information generating unit 135, and transmits the acquired service fee information response to the payer device 20. (Step S46) In the payer device 20, the payer device control unit 21 acquires the service fee information response. The payer device control unit 21 determines whether there is an advancing device that has not acquired the service fee information. Here, the payer device control unit 21 determines that there is an advancing device 10-2 that has not acquired the service fee information. (Step S47) In the payer device 20, the payer device control unit 21 creates a service fee information request for requesting service fee information.

[0112] (Step S48) In the payer device 20, the payer device control unit 21 transmits the created service fee information request to the advance payment device 10-2. (Step S49) In the advance payment device 10-2, the acquisition unit 15 acquires the service cost information request sent by the payer device 20. The notification information creation unit 135 acquires the service cost information request from the acquisition unit 15, and creates a service cost information response including service cost information based on the acquired service cost information request. (Step S50) In the advancing device 10-2, the output unit 14 acquires the service fee information response from the notice information generating unit 135, and transmits the acquired service fee information response to the payer device 20. (Step S46) In the payer device 20, the payer device control unit 21 acquires the service fee information response. The payer device control unit 21 determines whether there is an advance payment device that has not acquired the service fee information. Here, the payer device control unit 21 determines that there is no advance payment device that has not acquired the service fee information.

[0113] (Step S51) In the payer device 20, the payer device control unit 21 outputs the service price information included in each of the two acquired service price information responses to the presentation unit 22. The presentation unit 22 displays each piece of service price information output by the payer device control unit 21. (Step S52) In the payer device 20, the payer device control unit 21 calculates the sum of the service fee information included in each of the two acquired service fee information responses, and outputs the calculated sum to the presentation unit 22. The presentation unit 22 displays the calculated sum output by the payer device control unit 21. (Step S52) In the payer device 20, the payer device control unit 21 determines whether a certain period of time has elapsed. The certain period of time is determined in advance as a predetermined period of time. If the certain period of time has not elapsed, the process waits, and if the certain period of time has elapsed, the process proceeds to step S42. In FIG. 17, the payer device 20 may acquire service fee information from one advancing device 10, or may acquire service fee information from three or more advancing devices 10.

[0114] Fig. 18 is a flow chart showing the flow of a series of processes performed by the advance payment system according to this embodiment. With reference to the same figure, an example of the process when the service fee information is updated will be described. Steps S51 to S55 can be applied to steps S31-1 to S35-1 in Fig. 15A, so the description will be omitted. (Step S56) In the advance payment device 10, the transfer execution unit 16 executes a transfer process to advance payment. (Step S57) In the advance payment device 10, the notice information generating unit 135 generates service fee information. (Step S58) In the advance payment device 10, the output unit 14 acquires the service fee information from the notice information generating unit 135, and transmits the acquired service fee information to the payer device 20. (Step S59) In the payer device 20, the payer device control unit 21 acquires the service fee information from the advance payment device 10. The payer device control unit 21 updates the previously acquired service fee information with the acquired service fee information.

[0115] (Step S60) In the advance payment device 10, the notice information creation unit 135 creates a warning in accordance with the payment due date when the status of the billing information BI is "unpaid." (Step S61) In the advance payment device 10, the output unit 14 acquires a warning from the notification information creation unit 135, and transmits the acquired warning to the payer device 20. (Step S62) In the payer device 20, the payer device control unit 21 acquires the warning. The payer device control unit 21 outputs the acquired warning to the presentation unit 22. The presentation unit 22 displays the warning output by the payer device control unit 21. (Step S63) The payer P makes a deposit by, for example, operating the payer device 20. (Step S64) In the payer device 20, the deposit detection unit 132 detects that money has been deposited into the virtual account from the payer P. The deposit detection unit 132 outputs information related to the deposit to the payment status reconciliation unit 134 as deposit information PI.

[0116] (Step S65) In the payer device 20, the notification information generating unit 135 updates the service fee information when the status of the billing information BI is changed from "unpaid" to "paid." (Step S66) In the payment advance device 10-2, the output unit 14 acquires the updated service fee information from the notification information generating unit 135, and transmits the acquired service fee information to the payer device 20. (Step S67) The payer device 20 receives the service fee information transmitted by the server 40, and the payer device control unit 21 acquires the service fee information. The presentation unit 22 acquires the service fee information from the payer device control unit 21 and displays the service fee information.

[0117] FIG. 19 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. It should be noted that 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, a PLD, or an FPGA. Also, all or part of each functional unit may be realized by a combination of software and hardware. The payer device 20 and the claimant device 30 may have an internal configuration as shown in FIG.

[0118] According to the information processing system of this embodiment, a service of paying an invoice on behalf of the user is provided. The information processing system includes a reception unit 111 that receives an invoice from a invoice platform, and a notification information creation unit 135 as an example of a creation unit that creates service fee information for notifying a user of the fee for the advance payment when the information processing system advances the payment of the user's invoice received by the reception unit 111. By configuring in this way, the information processing system can notify the user of the fee for the advance payment when the information processing system advances the payment of the user's invoice, and can therefore encourage the user to pay the fee.

[0119] In the information processing system, the reception unit 111 receives an association application from an invoice platform to associate a user's account with a service, the information processing system further includes an association processing unit 136 that performs processing to associate the user's account with a service based on the association application, and the creation unit creates service fee information when the association processing unit 136 advances an invoice for a user for whom the association processing has been performed. By configuring in this manner, the information processing system can associate a user's account with a service based on an association application from any invoice platform selected by the user.

[0120] The information processing system further includes an integration processing unit 136 that performs processing to integrate a user's account with a service, the integration processing unit 136 creates an integration application for linking the user's account with a service, and the creation unit creates service fee information when the integration processing unit 136 advances an invoice for a user for whom the integration processing unit 136 has performed the integration processing. By configuring in this manner, the information processing system can create an integration application for linking the user's account with a service when selected by the user, and can therefore be integrated with an invoice platform.

[0121] In the information processing system, the creation unit creates linkage information for notifying the user, who has performed the linking process by the linkage processing unit 136, of information indicating the contents of the service. By configuring in this way, the information processing system can notify the user of information indicating the contents of the service when the linkage process is performed, and can therefore inform the user that the linkage was successful and of the service that has become possible as a result of the linkage.

[0122] In the information processing system, the creation unit creates service consideration information when a user logs in to a service. By configuring in this way, the information processing system can notify the user of the consideration for the advance payment immediately after the user logs in, and can encourage the user to pay the consideration.

[0123] In the information processing system, the creation unit creates service price information at a predetermined cycle. By configuring in this manner, the information processing system can update the price for advance payment notified to the user at the predetermined cycle, and therefore notify the user of the latest information.

[0124] The information processing system further includes a transfer execution unit 16 that advances payment of a user's invoice, and the creation unit updates the service fee information when the transfer execution unit 16 advances payment of the invoice. By configuring in this way, the information processing system can update the service fee information when the invoice is paid in advance, and therefore can notify the user of the latest information.

[0125] In the information processing system, the creation unit updates the service fee information when the consideration for the advance payment is paid. By configuring in this manner, the information processing system can update the service fee information when the consideration for the advance payment is paid, and therefore can notify the user of the latest information.

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

[0127] 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-mentioned 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.

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

[0129] 1...advance payment system, C...biller, P...payer, R...advance payment person, 10...advance payment device, 11...billing information acquisition unit, 12...billing information storage unit, 13...advance payment device control unit, 14...output unit, 15...acquisition unit, 16...transfer execution unit, 20...payer device, 21...payer device control unit, 22...presentation unit, 23...operation reception unit, 30...biller device, 42...billing information storage unit, 43...server control unit, 44...output unit, 45...acquisition unit, 40...server, BI...billing information, UPI...update information, TI...transfer information, 17...application instruction output unit, 18...transfer data file import unit, 111...reception unit, 131...virtual account allocation unit, 132...deposit detection unit, 133...payment status acquisition unit, 134...payment status reconciliation unit, 135...notification information creation unit, 136...linkage processing unit, 411...linkage processing unit

Claims

1. An information processing system for providing a bill payment service, comprising: a reception unit that receives an invoice from the invoice platform; a creation unit that creates service fee information for notifying the user of the fee for the advance payment when the payment of the invoice accepted by the acceptance unit has been advanced for the user; An information processing system comprising:

2. The reception unit receives an application for linking the user's account with the service from the invoice platform, The information processing system includes: A link processing unit that performs processing for linking the account of the user with the service based on the link application. Further equipped with The information processing system according to claim 1 , wherein the creation unit creates the service fee information when the link processing unit has paid the invoice in advance for the user who has performed the linked process.

3. A linking processing unit that performs processing for linking the user's account with the service. Further equipped with The link processing unit creates a link application for linking the account of the user with the service, The information processing system according to claim 1 , wherein the creation unit creates the service fee information when the link processing unit has paid the invoice in advance for the user who has performed the linked process.

4. 4. The information processing system according to claim 2, wherein the creation unit creates linkage information for notifying the user who has performed the process linked by the link processing unit of information indicating the content of the service.

5. The information processing system according to claim 1 , wherein the creation unit creates the service price information when the user logs in to the service.

6. The information processing system according to claim 1 , wherein the creation unit creates the service fee information at a predetermined cycle.

7. A transfer execution unit that advances payment of the user's bill Further equipped with 2. The information processing system according to claim 1, wherein the creation unit updates the service fee information when the payment of the invoice is made on behalf of the invoice by the transfer execution unit.

8. The information processing system according to claim 1 , wherein the creation unit updates the service fee information when a fee for the advance payment has been paid.

9. 1. A computer-implemented information processing method, comprising: Accept the user's invoices from the invoice platform; An information processing method for creating service consideration information for notifying a user of a consideration for the advance payment when the invoice for the user that has been accepted is paid in advance.

10. On the computer, accepting the user's invoice from an invoice platform; a step of creating service price information for notifying the user of the price for the advance payment when the invoice of the user accepted in the accepting step is paid in advance; A program to execute.

Images