Invoice payment system, invoice payment method, and program

Abstract

To improve user convenience.SOLUTION: An invoice payment system (1) includes: a payment source information acquisition unit (101) configured to acquire payment source information regarding a payment source that is directly or indirectly used for payment of an invoice; a proposal unit (102) configured to propose, on the basis of the payment source information, a proposal timing related to payment to a user who makes a payment reservation; a setting unit (103) configured to set a specified timing designated by the user when the proposal timing is proposed; and an execution unit (104) configured to execute processing related to payment on the basis of the specified timing.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to a bill payment system, a bill payment method, and a program. [Background technology]

[0002] Conventionally, bills have been used to pay for utility bills, merchandise, etc. For example, Patent Document 1 describes a method of making a payment of a bill indicated by bill information sent to a user's user terminal on a payment date and time designated by the user. Patent Document 1 also describes making a payment of a bill based on pre-charged electronic money or a pre-registered credit card. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2023-085846 Summary of the Invention [Problem to be solved by the invention]

[0004] However, with the technology of Patent Document 1, users sometimes had trouble determining what payment date and time was appropriate. This also applies when a user specifies a timing other than the payment date and time as the timing for paying a bill. For example, when a user specifies the timing for charging a payment method to be used to pay a bill, the user may not know what timing is appropriate. For this reason, conventional technology has not been able to sufficiently improve the convenience of users who schedule bill payments.

[0005] One of the purposes of the present disclosure is to improve user convenience. [Means for solving the problem]

[0006] The bill payment system of the present disclosure includes a payment source information acquisition unit that acquires payment source information regarding payment sources used directly or indirectly in paying bills, a proposal unit that proposes a proposed timing for the payment to a user who reserves the payment based on the payment source information, a setting unit that sets a specified timing specified by the user when the proposed timing is proposed, and an execution unit that executes processing related to the payment based on the specified timing. [Effects of the Invention]

[0007] The present disclosure can improve convenience for users. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of the hardware configuration of a bill payment system. [Figure 2] FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal. [Figure 3] FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal. [Figure 4] FIG. 1 is a diagram illustrating an example of functions implemented in a bill payment system. [Figure 5] FIG. 10 is a diagram illustrating an example of a payment service database. [Figure 6] FIG. 1 is a diagram illustrating an example of processing performed in a bill payment system. [Figure 7] FIG. 10 is a diagram illustrating an example of a function realized in a modified example. [Figure 8] FIG. 11 is a diagram showing an example of a reservation screen according to Modification 3. [Figure 9] FIG. 10 is a diagram showing an example of a reservation screen when multiple invoices are reserved at once. [Figure 10] FIG. 10 is a diagram showing an example of a flow in which a user changes reservation details of an invoice that has already been reserved. [Figure 11] FIG. 20 is a diagram showing an example of a reservation screen according to Modification 8. [Figure 12] FIG. 23 is a diagram showing an example of a reservation screen according to a tenth modification. DETAILED DESCRIPTION OF THE INVENTION

[0009] [1. Hardware configuration of bill payment system] An example of an embodiment of a bill payment system, bill payment method, and program according to the present disclosure will be described. Figure 1 is a diagram showing an example of the hardware configuration of a bill payment system. For example, bill payment system 1 includes a payment service provider server 10, a card company server 20, a receiving organization server 30, and a user terminal 40. Each of payment service provider server 10, card company server 20, receiving organization server 30, and user terminal 40 is connected to a network N such as the Internet or a LAN.

[0010] The payment service provider server 10 is a server computer of a payment service provider that operates a payment service. The payment service is a service that provides users with electronic payments (cashless payments). For example, the payment service provider server 10 includes a control unit 11, a memory unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The memory unit 12 includes at least one of a volatile memory such as RAM and a non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0011] The card company server 20 is a server computer of the card company that issued the credit card. For example, the card company server 20 includes a control unit 21, a memory unit 22, and a communication unit 23. The hardware configurations of the control unit 21, the memory unit 22, and the communication unit 23 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. In this embodiment, an example is given in which the card company is different from the payment service provider, but the card company may be the same as the payment service provider.

[0012] The collection organization server 30 is a server computer of the collection organization that acts as an agent for collecting invoices. The collection organization is sometimes called a collection agent. For example, the collection organization server 30 includes a control unit 31, a memory unit 32, and a communication unit 33. The hardware configurations of the control unit 31, the memory unit 32, and the communication unit 33 may be similar to the control unit 11, the memory unit 12, and the communication unit 13, respectively. In this embodiment, an example is given in which the collection organization is different from the payment service provider and the card company, but the collection organization may also be the same as at least one of the payment service provider and the card company.

[0013] The user terminal 40 is a user's computer. For example, the user terminal 40 is a smartphone, a tablet, a personal computer, or a wearable terminal. The user terminal 40 includes a control unit 41, a memory unit 42, a communication unit 43, an operation unit 44, a display unit 45, and an imaging unit 46. The hardware configurations of the control unit 41, the memory unit 42, and the communication unit 43 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 44 is an input device such as a touch panel or a mouse. The display unit 45 is a display such as an LCD or organic EL. The imaging unit 46 includes at least one camera.

[0014] The programs stored in the memories 12, 22, 32, 42 may be supplied to the payment processor server 10, the card company server 20, the receiving organization server 30, or the user terminal 40 via the network N. Also, at least one of a reading unit (e.g., a memory card slot) that reads a computer-readable information storage medium and an input / output unit (e.g., a USB port) for inputting and outputting data to and from an external device may be included in the payment processor server 10, the card company server 20, the receiving organization server 30, or the user terminal 40. For example, a program stored in an information storage medium may be supplied to the payment processor server 10, the card company server 20, the receiving organization server 30, or the user terminal 40 via at least one of the reading unit and the input / output unit.

[0015] Furthermore, bill payment system 1 only needs to include at least one computer. The computers included in bill payment system 1 are not limited to the example in Figure 1. For example, bill payment system 1 may include only payment service provider server 10. In this case, card company server 20, collection organization server 30, and user terminal 40 are external to bill payment system 1. For example, bill payment system 1 may include payment service provider server 10 and other computers not shown in Figure 1.

[0016] [2. Overview of the bill payment system] In this embodiment, an example is taken of a case where a user uses a payment service from a payment app installed on user terminal 40. The payment app is an application provided by a payment service provider. For example, when a user causes a terminal of an affiliated party of the payment service to read a code (e.g., a barcode or two-dimensional code) displayed on the payment app, payment is executed based on a pre-specified payment method.

[0017] The payment means available to users in a payment service may be of any type. A payment means is a means used by a user for payment. For example, a payment means may be a credit card, electronic money, points, cryptocurrency, debit card, wallet, account such as a bank account, sales proceeds from an online flea market service, or other means. Codes such as barcodes or two-dimensional codes are also means for payment and therefore correspond to a payment means. A payment means can also be called a payment method.

[0018] Furthermore, the payment methods available to users of the payment service are not limited to having the affiliated party's terminal read a code displayed on the payment app. Any payment method may be used. For example, the payment method may be a type in which a code displayed on the affiliated party's terminal is read by the user terminal 40, a type in which a code posted at the affiliated party's facility is read by the user terminal 40, a type in which the payment is completed by operating the user terminal 40 alone, a type in which an IC chip in the user terminal 40 is used, online payment (e.g., account payment using the user's account or ID payment using the user's ID), carrier payment, which is payment by the carrier used by the user terminal 40, or any other type.

[0019] In this embodiment, a bill payment service is provided as one of the payment services. The bill service is a service that allows a user to pay a bill from a payment app. An invoice may be physical paper or electronic data. An invoice may also be called a payment slip or a payment slip. An invoice can be used for any payment. For example, an invoice can be used to pay utility bills such as electricity or gas, pay for goods or services, pay taxes, or make other payments.

[0020] In this embodiment, the invoice is a physical piece of paper. The invoice may be in any format. For example, an invoice ID, which is an ID used to identify the invoice, the name of the payee, information about the payee's account, the name of the collection organization, the payment amount, the payment deadline, and a code (e.g., a barcode or two-dimensional code) are printed on the invoice. While a user can pay an invoice at a store such as a convenience store, in this embodiment, the user operates user terminal 40 to read the invoice with a payment app and pay the invoice.

[0021] 2 and 3 are diagrams showing examples of screens displayed on user terminal 40. For example, when a user performs an operation to use a bill payment service in a payment app, user terminal 40 activates photographing unit 46. As shown in the upper left of FIG. 2, user terminal 40 displays photographed screen SC1, which shows a photographed image generated by photographing unit 46, on display unit 45. User terminal 40 reads the bill code shown in the photographed image.

[0022] For example, the invoice code is generated based on information required for payment. This information may be information used in known invoices. For example, the invoice code is generated based on at least one of an invoice ID that can identify an individual payment, a payee ID that can identify the payee, a receiving organization ID that can identify the receiving organization, the payment amount, and the payment deadline. When the user terminal 40 reads this information from the invoice code, the user terminal 40 displays a details screen SC2 showing the details of the invoice on the display unit 45 based on this information, as shown in the upper right corner of Figure 2.

[0023] In this embodiment, an example is given in which a user pays a bill using online electronic money. For example, the details screen SC2 displays the user's electronic money balance. The user can make an immediate payment by selecting button B20. This process may be similar to the process employed in known bill payment services. The user can schedule a payment by selecting button B21 instead of making an immediate payment.

[0024] For example, when the user selects button B21, the user terminal 40 displays a reservation screen SC3 on the display unit 45, as shown in the lower left of Figure 2, for the user to reserve payment. The user specifies the payment timing from the reservation screen SC3. The payment timing is the timing at which payment is made. In this embodiment, an example is given in which the payment timing is expressed only by date, but the payment timing may also be expressed by a date and time that includes not only the date but also the time. The user can specify any payment timing. However, if a payment deadline is set for the invoice, the user will, in principle, specify the payment timing up to the payment deadline. Hereinafter, the payment timing specified by the user will be referred to as the specified payment timing.

[0025] For example, if a user specifies a designated payment timing from the calendar displayed on the reservation screen SC3 and selects button B30, the user terminal 40 will display confirmation details such as the designated payment timing specified by the user on the reservation screen SC3, as shown in the lower right of FIG. 2. The user can also select button B31 to cancel the payment reservation. If the user selects button B32 on the reservation screen SC3 in the lower right of FIG. 2, the payment reservation is completed. Once the payment reservation is completed, payment will be made when the designated payment timing specified by the user arrives. If the user pays with electronic money, an error will occur if the electronic money balance is insufficient at the designated payment timing. For this reason, the user needs to manage their electronic money balance so that it does not run out.

[0026] In this embodiment, the user can perform operations for charging electronic money from the reservation screen SC3. For example, when the user selects button B33, the user terminal 40 displays an input form F34 on the reservation screen SC3, as shown in the upper left of FIG. 3, for the user to input the charging amount. The user can specify any settings for charging from the reservation screen SC3. For example, the user can specify a charging method, which is the payment method that will be used to fund the charge. In the example in the upper left of FIG. 3, the user specifies a credit card as the charging method.

[0027] For example, when the user selects button B35, charging is performed immediately. The charging process may be similar to the process used in known charging. The conditions specified by the user for charging may also be similar to the conditions used in known charging. In the example in the upper left of Figure 3, charging is performed for the charging amount entered by the user in input form F34 based on the credit card specified by the user as the charging method. The balance of the electronic money increases immediately after charging. In this embodiment, after a certain amount of time (for example, about one week) has passed since charging was performed, the payment service provider accepts a deposit equivalent to the charging amount from the card company.

[0028] In this embodiment, the user can not only pay bills but also reserve charging. Charges reserved by the user are executed automatically, and are therefore a type of auto-charge. For example, when the user selects button B36, the user terminal 40 displays a calendar on the reservation screen SC3, as shown in the upper right corner of FIG. 3, which allows the user to specify the charge timing. The charge timing is the timing at which charging is executed. In this embodiment, an example is given in which the charge timing is expressed only by date, but the charge timing may also be expressed by a date and time that includes not only the date but also the time. The user can specify any charge timing. Hereinafter, the charge timing specified by the user will be referred to as the specified charge timing.

[0029] In this embodiment, a recommended charge timing is suggested on the reservation screen SC3, as shown in the upper right corner of FIG. 3. The recommended charge timing may differ depending on the charge method. For example, if a charge is performed immediately before the designated payment timing, depending on the charge method, there is a possibility that the funds will be insufficient and a sufficient balance will not be prepared by the designated payment timing. For this reason, a charge timing with a certain margin from the designated payment timing is suggested. In addition, for example, a charge timing based on the period until the credit card company of the credit card set as the charge method makes a deposit may also be suggested as a recommended charge timing. Hereinafter, the charge timing suggested to the user will be referred to as the suggested charge timing. When there is no distinction between the designated charge timing and the suggested charge timing, it will simply be referred to as the charge timing.

[0030] For example, if the charging method is a credit card, charging may be more reliably performed after the day the shopping limit is released (for example, after the monthly closing date or deduction date). If the charging method is sales from an online flea market service, charging may be more reliably performed after the day the sales are deposited. If the charging method is a bank account, charging may be more reliably performed after payday. These charging timings are examples of charging timings that primarily benefit the user, but proposed charging timings that primarily benefit the payment service provider may also be proposed.

[0031] For example, in the example in the upper right of FIG. 3, a proposed charge timing is suggested some time in advance (e.g., more than one week in advance) from the designated payment timing specified by the user. The user specifies the designated charge timing based on the suggestion on the reservation screen SC3. When the user selects button B37, the user terminal 40 displays confirmation details of the designated charge timing specified by the user on the reservation screen SC3, as shown in the lower left of FIG. 3. The user can also cancel the charge reservation by selecting button B38.

[0032] For example, when the user selects button B39, the user terminal 40 displays on the reservation screen SC3, as shown in the lower right of FIG. 3, that the payment reservation and charge reservation have been completed. The user can also select button B40 to modify at least one of the payment reservation and charge reservation. When the payment reservation and charge reservation are completed, the charge is made at the designated charge timing specified by the user, and the payment is made at the designated payment timing specified by the user. In the example in the lower right of FIG. 3, the charge is made some time before the designated payment timing, allowing the user to make the payment with a sufficient balance of electronic money.

[0033] As described above, the bill payment system 1 of this embodiment proposes a recommended proposed charging timing on the reservation screen SC3 based on the charging method and payment timing specified by the user. The user can specify the proposed charging timing from the reservation screen SC3 after understanding what proposed charging timing to specify, so the bill payment system 1 can improve user convenience. Details of the bill payment system 1 will be explained below.

[0034] [3. Functions realized by the bill payment system] Figure 4 is a diagram showing an example of the functions realized by the bill payment system 1. The various parts realized by the bill payment system 1 can be configured as a single device or as more finely divided devices.

[0035] [3-1. Functions realized by the payment service provider server] For example, the payment service provider server 10 includes a data storage unit 100, a payment source information acquisition unit 101, a proposal unit 102, a setting unit 103, and an execution unit 104. The data storage unit 100 is realized by the storage unit 12. Each of the payment source information acquisition unit 101, the proposal unit 102, the setting unit 103, and the execution unit 104 is realized by the control unit 11.

[0036] [Data storage section] The data storage unit 100 stores data necessary for the payment service. For example, the data storage unit 100 stores a payment service database DB.

[0037] FIG. 5 is a diagram showing an example of a payment service database DB. The payment service database DB is a database that stores various information related to users. For example, the payment service database DB stores user IDs, passwords, code IDs, payment method information, payment history information, charge method information, and reservation history information. The payment service database DB may also store other data. For example, the payment service database DB may store information related to payment methods used by users when making payments using codes displayed on the payment app, charge history information related to the history of past charge attempts, and bill payment history information related to the history of past bill payments.

[0038] The user ID of a payment service is an example of user identification information that can identify a user in the payment service. A login account may exist in addition to the user ID. The login account may be freely changeable by the user. A password is information that is confirmed when logging in. A code ID is also an example of user identification information, as it is an ID that can identify a user in the payment service. The code ID is updated each time a code is displayed in the payment app. Any information may be used as user identification information.

[0039] Payment method information is information that allows a user to identify payment methods that can be used for a payment service. For example, payment method information is information such as a credit card number, electronic money number, account information such as a bank account, or point card number balance. Payment history information is information related to a user's usage history of a payment service. For example, payment history information indicates the date and time of payment, the payment location, the payment amount, the payment target, or a combination of these. When a user makes a payment, the payment history information is updated to indicate the details of the payment.

[0040] The charging method information is information that can identify the charging method specified by the user. For example, the charging method information is information such as a credit card number, account information such as a bank account, information such as the number of other electronic money that will be used as the source of funds, or information for identifying the sales proceeds of the online flea market service. The user can specify any payment method other than the electronic money to be charged from the payment methods indicated in the payment method information as the charging method. When the user changes the charging method, the payment service provider server 10 updates the charging method information.

[0041] In this embodiment, an example is given in which the charging means corresponds to the payment source, and therefore charging means information is an example of payment source information that can identify the payment source. Therefore, the parts that say charging means information can be read as payment source information. If the payment means indirectly used in payment is a payment means other than the charging means (for example, a payment means used in combination with the main payment means), the payment source information is information that can identify the other payment means. If a directly used payment means, which is a payment means directly used in payment, corresponds to the payment source, the payment source information is information that can identify the directly used payment means.

[0042] Reservation history information is information relating to the reservation history of invoices reserved by a user. For example, reservation history information indicates at least one of a payment reservation and a charge reservation. Reservation history information indicates an invoice ID that can identify the invoice that was the subject of the payment reservation, the payment reservation details specified by the user (for example, at least one of the specified payment timing specified by the user and information on the directly used payment method specified by the user), and the charge reservation details specified by the user (for example, at least one of the specified charge timing specified by the user, information on the charge method specified by the user, and the charge amount specified by the user). In this embodiment, an example is given in which reservation history information is stored in the payment service database DB for each invoice, but one piece of reservation history information may also indicate reservation details specified for multiple invoices.

[0043] For example, if a user specifies a designated payment timing, the reservation history information indicates the designated payment timing specified by the user. If a user specifies a designated charge timing, the reservation history information indicates the designated charge timing specified by the user. If a user does not make a charge reservation, the reservation history information only indicates information related to the payment reservation. A user may specify multiple designated charge timings for a single invoice. For example, a user may specify a designated charge timing that is earlier than the designated payment timing and a designated charge timing that is later than the designated payment timing. By specifying a charge timing that is later than the designated payment timing, the user can restore the balance of electronic money that was reduced by paying the invoice so that the electronic money can be used for payments other than paying the invoice.

[0044] The data stored in the data storage unit 100 is not limited to the above examples. The data storage unit 100 may store data necessary for the payment service. For example, the data storage unit 100 may store data for various screens displayed on a payment app. The data storage unit 100 may store data necessary for proposing recommended charging timings. The data storage unit 100 may store data indicating the deposit period required for a card company to deposit funds into a payment service provider. The data storage unit 100 may store data indicating the deposit period required for a business that handles payment methods other than credit cards to deposit funds into a payment service provider. The data storage unit 100 may store data indicating the deposit period required for a payment service provider to deposit funds into a collection organization.

[0045] [Payment source information acquisition section] The payment source information acquisition unit 101 acquires payment source information regarding payment sources used directly or indirectly to pay bills. A directly used payment source is a payment method through which payment is made. In other words, a directly used payment source is a payment method that serves as the source of funds at the time of payment. In this embodiment, electronic money is described as an example of a directly used payment source. Therefore, any description of electronic money used for payment can be interpreted as a directly used payment source. A directly used payment source may be a credit card, points, cryptocurrency, debit card, wallet, account such as a bank account, sales proceeds from an online flea market service, or other means. In this embodiment, an example is given in which a directly used payment source is a rechargeable payment method, but a directly used payment source does not have to be rechargeable. A directly or indirectly used payment source may be one that a user can set in a payment app.

[0046] An indirectly used payment source is a payment method that is the source of funds for a directly used payment source. An indirectly used payment source is a payment method different from a directly used payment source. In other words, an indirectly used payment source is a method by which payment (also referred to as charging, remittance, or conversion) is performed before the time of payment. In this embodiment, a credit card is described as an example of an indirectly used payment source. Therefore, any description of a credit card used to pay a bill can be interpreted as an indirectly used payment source. An indirectly used payment source may be electronic money, points, cryptocurrency, a debit card, a wallet, an account such as a bank account, sales proceeds from an online flea market service, or other means. Note that a payment method used in conjunction with a directly used payment source may also correspond to a directly used payment source. Furthermore, an exchange source for a directly used payment source (e.g., an exchange source for points) may also correspond to an indirectly used payment source.

[0047] In this embodiment, the payment source is a charging means for charging a directly used payment means that is directly used for payment, and is an example of a charging means that is indirectly used for payment. Furthermore, electronic money will be described as an example of a directly used payment means. The payment source information acquisition unit 101 acquires charging means information related to the charging means as payment source information. Since charging means information is stored in the payment service database DB, the payment source information acquisition unit 101 acquires charging means information from the payment service database DB. For example, when a user makes a reservation, the payment source information acquisition unit 101 acquires charging means information associated with the user ID of that user.

[0048] The charging method information may be stored in a database other than the payment service database DB. In this case, the payment source information acquisition unit 101 acquires the charging method information from the other database. The charging method information may be stored in a computer or external information storage medium other than the payment service provider server 10. In this case, the payment source information acquisition unit 101 acquires the charging method information from the other computer or external information storage medium.

[0049] Furthermore, in this embodiment, the term "payment source" simply refers to a concept that encompasses both directly used payment sources and indirectly used payment sources. Therefore, the description of the term "payment source" is common to both directly used payment sources and indirectly used payment sources. If the payment source of this embodiment means a directly used payment source rather than an indirectly used payment source, it is possible that only directly used payment sources exist and no indirectly used payment sources exist. The processing when the payment source of this embodiment means a directly used payment source will be described in the modified example below.

[0050] [Proposal Department] The proposal unit 102 proposes a proposed timing for payment to a user who reserves payment based on the payment source information. The proposed timing for payment is a concept that encompasses the proposed payment timing, which is the payment timing proposed to the user, and the proposed charge timing. The proposed charge timing is also the proposed timing for charge made for payment, and is a proposed timing that is somehow related to payment, so it corresponds to the proposed timing for payment. In this embodiment, the explanation simply written as the proposed timing is an explanation common to both the proposed payment timing and the proposed charge timing. Similarly, in this embodiment, the explanation simply written as the designated timing is an explanation common to both the designated payment timing and the designated charge timing. Note that hereinafter, when there is no distinction between the proposed payment timing and the designated payment timing, it will simply be referred to as the payment timing.

[0051] Proposing a proposed timing means notifying the user of the proposed timing identified by the proposing unit 102. In this embodiment, displaying the proposed timing on the reservation screen SC3 corresponds to proposing the proposed timing. The proposing unit 102 generates display data for the reservation screen SC3 indicating the proposed timing to be proposed. The display data is data for displaying some kind of screen on the user terminal 40. When a browser is used, the display data is HTML data. When a dedicated app such as a payment app is used, the display data is data (e.g., HTML data or image data) used to display some kind of screen in the app. The proposing unit 102 proposes the proposed timing to the user by transmitting display data for the reservation screen SC3 to the user terminal 40. The proposed timing is not limited to the image of a speech bubble as shown in FIG. 3 , and may be proposed by other images or messages. The proposed timing may be presented in a manner that the user can visually or audibly recognize.

[0052] For example, the data storage unit 100 stores proposed timing data indicating the relationship between payment source information and the proposed timing that the proposal unit 102 should propose. The proposed timing data indicates the proposed timing that the proposal unit 102 should propose for each payment source indicated in the payment source information. In this embodiment, an example is given in which the proposed timing data indicates a relative proposed timing based on a designated payment timing specified by the user (for example, a timing one week or more before the payment timing), but the proposed timing data may also indicate an absolute proposed timing that is not based on the designated payment timing specified by the user.

[0053] For example, the proposed timing data associates payment source information indicating a first payment source (e.g., a credit card) with a first proposed timing (e.g., a proposed timing one week or more before the specified payment timing). The proposed timing data associates payment source information indicating a second payment source (e.g., a bank account) with a second proposed timing (e.g., a proposed timing two days or more before the specified payment timing). The proposed timing data may indicate proposed timings for three or more payment sources. The proposed timing data may be in any format, such as a formula, a table, part of a program, a machine learning model, or other format of data.

[0054] For example, the suggestion unit 102 suggests to the user a suggested timing associated with the payment source information acquired by the payment source information acquisition unit 101, based on the suggested timing data. When the payment source information acquired by the payment source information acquisition unit 101 indicates a first payment source, the suggestion unit 102 suggests to the user a first suggested timing associated with the first payment source. When the payment source information acquired by the payment source information acquisition unit 101 indicates a second payment source, the suggestion unit 102 suggests to the user a second suggested timing associated with the second payment source. In this embodiment, since the suggested timing data indicates relative suggested timings as the first suggested timing and the second suggested timing, the suggestion unit 102 suggests to the user a suggested timing for payment based on the designated payment timing specified by the user and the relative suggested timing indicated in the suggested timing data.

[0055] For example, the proposing unit 102 may propose to the user a proposed timing according to the deposit period for the payment source based on the payment source information. In this embodiment, the proposing unit 102 proposes to the user, as the proposed timing for payment, a proposed charge timing according to the deposit period from the administrator of the charge method (in this embodiment, the card company) to the administrator of the directly used payment method directly used for payment (in this embodiment, the payment service provider) based on the charge method information and the designated payment timing specified by the user.

[0056] The administrator of the charging means is the business operator that manages the charging means. For example, if the charging means is a credit card, the card company that issued the credit card corresponds to the administrator of the charging means. If the charging means is an account such as a bank account, the financial institution that manages the account corresponds to the administrator of the charging means. The administrator of the directly used payment means is the business operator that manages the directly used payment means. For example, if the directly used payment means is electronic money, the business operator that manages the electronic money corresponds to the administrator of the directly used payment means. If the directly used payment means is an account such as a bank account, the financial institution that manages the account corresponds to the administrator of the directly used payment means. Note that the deposit period does not refer to the period from when the user issues a charge instruction to when the charge is completed, but rather to the period from when the deposit that serves as the funds for the charge is received from the administrator of the charging means after the charge is completed. Any deposit method, such as bank transfer, may be used for the deposit. Data indicating the length of the deposit period is stored in data storage unit 100.

[0057] The suggestion method of the suggestion unit 102 is not limited to the above example. The suggestion unit 102 may suggest the proposed timing to the user by transmitting data indicating the proposed timing to the user terminal 40 or another computer. For example, the suggestion unit 102 may suggest the proposed timing to the user by displaying the proposed timing on a screen other than the reservation screen SC3 among the screens displayed in the payment app. The suggestion unit 102 may suggest the proposed timing to the user by other methods such as a pop-up, a window, or a modal. The suggestion unit 102 may suggest the proposed timing to the user by using means other than the payment app. The other means may be email, SMS, push notification, banner notification, or other means.

[0058] Furthermore, the proposing unit 102 may propose a plurality of proposed timings. In the example of FIG. 3, the proposing unit 102 may propose a plurality of days included in the period from the date on which the user makes the reservation to January 17, 2024 as a plurality of proposed timings. That is, the proposing unit 102 may propose a period including a plurality of proposed timings. The plurality of proposed timings do not have to be consecutive. For example, the proposing unit 102 may propose a plurality of non-consecutive proposed timings. In the example of FIG. 3, the proposing unit 102 may propose three non-consecutive proposed timings, such as January 3, 2024, January 10, 2024, and January 17, 2024.

[0059] [Settings section] When the suggestion unit 102 suggests a proposed timing, the setting unit 103 sets the specified timing specified by the user. Setting the specified timing means recording the specified timing specified by the user in the data storage unit 100. The setting unit 103 associates an invoice ID with the specified timing specified by the user and records them in the data storage unit 100. The invoice ID is an example of invoice identification information that can identify an invoice. The invoice identification information may be information other than an invoice ID. For example, the invoice identification information may be a number that is not classified as an ID. The invoice identification information may be information used in publicly known invoices. The setting unit 103 sets the specified timing specified by the user after the suggestion unit 102 suggests a proposed timing. The specified timing may be the same as or different from the proposed timing. In other words, the user may or may not specify the same specified timing as the proposed timing.

[0060] In this embodiment, the setting unit 103 sets the designated timing specified by the user by associating the invoice ID of the invoice for which the user reserves payment with the designated timing specified by the user and storing them in the payment service database DB. The setting unit 103 may also associate and store the invoice ID with the designated timing specified by the user in a database other than the payment service database DB. Associating the invoice ID with the designated timing specified by the user is equivalent to setting the designated timing for the invoice indicated by the invoice ID. Note that the setting unit 103 is capable of identifying the designated timing by obtaining data indicating the designated timing specified by the user from the user terminal 40. The setting unit 103 is also assumed to obtain the invoice ID of the invoice for which the designated timing is to be set from the user terminal 40.

[0061] In this embodiment, a suggested charge timing is proposed as the suggested timing for payment, and the setting unit 103 sets the designated charge timing specified by the user when the suggested charge timing is proposed. For example, the setting unit 103 sets the designated charge timing specified by the user by associating the invoice ID of the invoice read by the user with the designated charge timing specified on the reservation screen SC3 in the upper right of FIG. 3 and storing them in the payment service database DB. When the user instructs to change the designated charge timing, the setting unit 103 updates the designated charge timing associated with the invoice ID to the changed designated charge timing specified by the user. When the user specifies multiple designated charge timings for a certain invoice, the setting unit 103 associates the multiple designated charge timings with the invoice ID of the invoice.

[0062] [Executive Department] The execution unit 104 executes payment-related processing based on the specified timing specified by the user. Payment-related processing is processing that is directly or indirectly related to payment. In this embodiment, payment-related processing is a concept that encompasses payment processing for payment and charge processing for charging a payment source that is directly used in payment. Charge processing is executed in preparation for invoice payment and is somehow related to invoice payment, so it corresponds to payment-related processing. In this embodiment, when simply describing payment-related processing (i.e., processing executed by the execution unit 104), it means both payment processing and charge processing. Payment-related processing may be processing other than payment processing and charge processing. For example, payment-related processing may be processing that uses a payment method in combination with payment.

[0063] The payment process is a payment based on a directly used payment means that is directly used for payment. In this embodiment, the case where electronic money is the directly used payment means is taken as an example, so the payment process is a process of reducing the balance of electronic money. If the directly used payment means is another payment means, the payment process may be a payment process based on the other payment means. For example, if the directly used payment means is a credit card, the payment process is a payment process based on the credit card. If the directly used payment means is an account such as a bank account, the payment process is a debit process from the account. If the directly used payment means is another payment means, the payment process may be a payment process based on the other payment means. Note that the payment process may also be performed using multiple directly used payment means.

[0064] The charge process is a payment based on a charge means, which is an example of a payment means indirectly used for payment. The payment process and the charge process themselves may be the same as known processes. For example, if the charge means is a credit card, the charge process is a charge process using the credit card as the source of funds. If the charge means is an account such as a bank account, the charge process is a charge process using the account as the source of funds. If the charge means is another payment means, the charge process may be a charge process based on another payment means. The charge process also includes a process of increasing the balance of the electronic money to be charged.

[0065] In this embodiment, the execution unit 104 executes a charge process related to charging as a payment process based on the designated charge timing designated by the user. For example, the execution unit 104 acquires the current date and time and determines whether the designated charge timing has arrived. The method for acquiring the current date and time may be a known method. For example, the execution unit 104 may acquire the current date and time using a real-time clock, a GPS, or the like. If the execution unit 104 does not determine that the designated charge timing has arrived, it does not execute the charge process, but if it determines that the designated charge timing has arrived, it executes the charge process. The arrival of the designated charge timing serves as a condition (trigger) for executing the charge process.

[0066] The execution unit 104 may refer to the reservation history information in the payment service database DB to identify the designated charging timing. The execution unit 104 may refer to the charging method information in the payment service database DB to identify the charging method to be used in the charging process. If a charging method other than the default charging method is used to pay the bill, information on the charging method is assumed to be indicated in the reservation history information. In this case, the execution unit 104 may refer to the reservation history information in the payment service database DB to identify the charging method. Similarly, when a payment process is executed instead of a charging process, the execution unit 104 may refer to the reservation history information, etc. in the payment service database DB and execute the payment process. Similarly, when a process other than a payment process and a charging process is executed as a payment-related process, the execution unit 104 may refer to the reservation history information, etc. in the payment service database DB and execute the payment-related process.

[0067] [3-2. Functions implemented by the card company server] For example, the card company server 20 includes a data storage unit 200 and a service providing unit 201. The data storage unit 200 is realized by the storage unit 22. The service providing unit 201 is realized by the control unit 21.

[0068] [Data storage section] The data storage unit 200 stores data necessary for the card services provided by the card company. For example, the data storage unit 200 stores a database that stores various information related to users in the card services. For example, the database stores credit card numbers, expiration dates, cardholder names, credit card usage history, payment methods such as lump-sum payment or installment payments, and other information. The data storage unit 200 only needs to store data according to the card services.

[0069] [Service Provision Department] The service providing unit 201 provides card services to the user based on the data stored in the data storage unit 200. For example, when a credit card is specified as the charging method, the service providing unit 201 executes a charging process using the credit card's limit as the source of funds. The charging process may be a process that is employed as a known charging process. When a credit card is used to pay a bill, the service providing unit 201 executes a payment process using the credit card's limit as the source of funds.

[0070] [3-3. Functions realized by the receiving organization server] For example, the receiving organization server 30 includes a data storage unit 300 and a storage unit 301. The data storage unit 300 is realized by the storage unit 32. The storage unit 301 is realized by the control unit 31.

[0071] [Data storage section] The data storage unit 300 stores data necessary for the collection service provided by the collection organization. For example, the data storage unit 300 stores a database that stores various information related to invoices. The database stores the invoice ID, the name of the payee, the payee's account information, the name of the collection organization, the payment amount, and the payment deadline. The information stored in the database may be information used in known collection services. For example, when a new invoice is issued, information related to the invoice is added to the database. The database may also store information indicating whether the invoice has been paid.

[0072] [Storage section] The receiving unit 301 executes various processes in the payment service. For example, when the receiving unit 301 receives a deposit from a payment service provider, it determines whether or not the invoice, whose information is stored in the database stored in the data storage unit 300, has been paid, and updates the database. The processes executed by the receiving unit 301 may be processes adopted in well-known payment services. For example, when the receiving unit 301 receives an invoice ID from the payment service provider server 10 or the user terminal 40, it may transmit information such as the payment amount associated with the invoice ID to the payment service provider server 10 or the user terminal 40.

[0073] [3-4. Functions implemented on user devices] For example, the user terminal 40 includes a data storage unit 400, an operation reception unit 401, and a display control unit 402. The data storage unit 400 is realized by the storage unit 42. The operation reception unit 401 and the display control unit 402 are realized by the control unit 41.

[0074] [Data storage section] Data storage unit 400 stores data necessary for a user to use a payment service. For example, data storage unit 400 stores a payment app. When a user uses a payment service from a browser rather than a payment app, data storage unit 400 stores the browser.

[0075] [Operation reception section] The operation acceptance unit 401 accepts various operations from the user. For example, the operation acceptance unit 401 accepts operations for the payment application. The operation acceptance unit 401 transmits data indicating the content of the user's operation to the payment business operator server 10.

[0076] [Display control section] The display control unit 402 displays various screens on the display unit 45. For example, the display control unit 402 displays each of a photography screen SC1, a details screen SC2, and a reservation screen SC3 on the display unit 45. The display control unit 402 communicates with the payment service provider server 10 or another computer, receives data necessary to display these screens, and displays these screens on the display unit 45.

[0077] [4. Processes performed by the bill payment system] Figure 6 is a diagram showing an example of the processing executed in bill payment system 1. The processing in Figure 6 is executed by control units 11, 21, 31, and 41 executing programs stored in storage units 12, 22, 32, and 42, respectively. The processing in Figure 6 is executed when the payment app is running and the user performs an operation to use the bill payment service (for example, an operation to select the bill payment service from the menu of the payment app).

[0078] As shown in FIG. 6, the user terminal 40 activates the photographing unit 46 to display the photographed screen SC1 on the display unit 45 and reads the invoice code (S1). The user terminal 40 executes processing between the payment service provider server 10 and the receiving organization server 30 to display the details screen SC2 on the display unit 45 based on information acquired from the invoice code (S2). In S2, the user terminal 40 reads the invoice ID from the invoice code. The user terminal 40 transmits the invoice ID to the payment service provider server 10. The payment service provider server 10 queries the receiving organization server 30 for details of the invoice indicated by the invoice ID. The payment service provider server 10 generates display data for the details screen SC2 based on the invoice details acquired from the receiving organization server 30 and transmits it to the user terminal 40.

[0079] The following describes the process when a user makes a payment reservation. When the user selects button B21, the user terminal 40 executes a process with the payment business operator server 10 to display a reservation screen SC3 for specifying the designated payment timing on the display unit 45 (S3). In S3, the user terminal 40 requests the payment business operator server 10 to display the reservation screen SC3. Upon receiving the request from the user terminal 40, the payment business operator server 10 generates display data for the reservation screen SC3 and sends it to the user terminal 40. The reservation screen SC3 will appear as shown in the lower left of FIG. 2.

[0080] When the user specifies a designated payment timing on the calendar on the reservation screen SC3 and selects button B30, the user terminal 40 executes processing with the payment service provider server 10 to display the reservation screen SC3 for payment reservation on the display unit 45 (S4). In S4, the user terminal 40 transmits data indicating the designated payment timing specified by the user to the payment service provider server 10. Based on that data, the payment service provider server 10 generates display data for the reservation screen SC3 and transmits it to the user terminal 40. The reservation screen SC3 will appear as shown in the lower right of FIG. 2.

[0081] The following describes the process when a user makes a reservation for a charge. When the user selects the charge button B33 on the reservation screen SC3 at the bottom right of Fig. 2, the user terminal 40 executes processing with the payment service provider server 10 to display the reservation screen SC3 for specifying the charge amount on the display unit 45 (S5). In S5, the payment service provider server 10 generates display data for the reservation screen SC3 for specifying the charge amount and transmits it to the user terminal 40. The reservation screen SC3 will appear as shown in the upper left of Fig. 3.

[0082] When the user selects the button B36 for reserving a charge, the user terminal 40 requests the payment service provider server 10 to reserve a charge (S6). When the payment service provider server 10 accepts the request (S7), it references the payment service database DB and acquires charge method information associated with the user ID of the logged-in user (S8). The payment service provider server 10 proposes a proposed charge timing to the user based on the charge method information (S9). In S9, the payment service provider server 10 determines, as the proposed charge timing to be proposed, a proposed timing that is earlier than the specified payment timing specified by the user and the deposit period corresponding to the charge method indicated by the charge method information. The payment service provider server 10 generates display data for a reservation screen SC3 showing the determined proposed charge timing and sends it to the user terminal 40. The reservation screen SC3 will appear as shown in the upper right of Figure 3.

[0083] When the user specifies the designated charge timing and selects button B37, the user terminal 40 executes processing with the payment service provider server 10 to display a reservation screen SC3 for payment reservations and charge reservations on the display unit 45 (S10). In S10, the payment service provider server 10 generates display data for the reservation screen SC3 for payment reservations and charge reservations based on the designated payment timing and designated charge timing specified by the user, and transmits it to the user terminal 40. The reservation screen SC3 will appear as shown in the lower left of Figure 3.

[0084] When the user selects the payment reservation and charge reservation button B39, the user terminal 40 requests a payment reservation and charge reservation from the payment service provider server 10 (S11). Upon receiving the request (S12), the payment service provider server 10 sets the designated charge timing, etc. (S13). In S13, the payment service provider server 10 associates the invoice ID of the invoice to be reserved with reservation history information indicating the designated payment timing and designated charge timing specified by the user and stores them in the payment service database DB. After that, a reservation screen SC3 like the one shown in the lower right of Figure 3 is displayed.

[0085] The payment service provider server 10 determines whether the designated charge time specified by the user has arrived based on the payment service database DB, and if it determines that the designated charge time has arrived, executes a charge process with the card company server 20 (S14). In S14, the payment service provider server 10 requests the card company server 20 to make a payment based on the charge amount specified by the user. The card company server 20 executes a payment using the user's credit card based on the request from the payment service provider server 10. When the payment service provider server 10 receives the result of the payment execution from the card company server 20, it executes a process to increase the user's electronic money balance.

[0086] The payment service provider server 10 determines whether the designated payment timing specified by the user has arrived based on the payment service database DB. If it determines that the designated payment timing has arrived, it executes payment processing for the invoice read by the user with the receiving organization server 30 (S15), and this processing ends. In S15, the payment service provider server 10 executes processing to reduce the user's electronic money balance by the amount of the invoice payment. The payment service provider server 10 transmits data to the receiving organization server 30 indicating that payment of the invoice read by the user has been completed. This data includes the invoice ID of the invoice to be paid. By receiving this data from the payment service provider server 10, the receiving organization server 30 can determine that payment of the invoice has been completed. After that, after a certain period of time (e.g., two days) has passed, the payment service provider deposits the money into the receiving organization.

[0087] [5. Summary of embodiments] The bill payment system 1 of this embodiment proposes a suggested timing for payment to the user based on payment source information. When a suggested timing is proposed, the bill payment system 1 sets the specified timing specified by the user. The bill payment system 1 executes payment processing based on the specified timing. This allows the user to understand what specified timing to specify, so the bill payment system 1 can increase user convenience. For example, the bill payment system 1 can allow the user to specify the optimal specified timing for paying the bill, thereby increasing the likelihood that the bill payment will be completed accurately.

[0088] Furthermore, based on the payment source information, the bill payment system 1 proposes to the user a proposed timing that corresponds to the payment period for the payment source. This allows the user to understand that they only need to specify a designated timing that corresponds to the payment period for the payment source, thereby enabling the bill payment system 1 to improve user convenience. The bill payment system 1 can also improve convenience for payment service providers. For example, if the payment source is a credit card, there may be a certain period (e.g., one week) for the card company to deposit funds into the payment service provider. If the payment service provider deposits funds into the receiving organization before the card company deposits funds into the payment service provider, the payment service provider may run out of funds. In this regard, by proposing a proposed timing that corresponds to the payment period for the card company to deposit funds into the payment service provider, the bill payment system 1 can prevent the payment service provider from running out of funds and improve convenience for the payment service provider.

[0089] In addition, the payment source in this embodiment is a charging method. The bill payment system 1 acquires charging method information as payment source information. Based on the charging method information and the designated payment timing specified by the user, the bill payment system 1 proposes to the user a proposed charging timing corresponding to the deposit period from the administrator of the charging method to the administrator of the payment method as a proposed timing. When the proposed charging timing is proposed, the bill payment system 1 sets the designated charging timing specified by the user. The bill payment system 1 executes a charging process as a payment-related process based on the designated charging timing specified by the user. This allows the user to understand the proposed charging timing corresponding to the deposit period from the administrator of the charging method (e.g., a card company) to the administrator of the payment method (e.g., a payment service provider), thereby improving user convenience. In addition, the bill payment system 1 can also improve convenience for payment service providers. For example, if the charging method is a credit card, there may be a certain period (e.g., one week) for the card company to deposit the amount equivalent to the charge amount to the payment service provider. If a payment provider makes a payment to a collection organization before the card company makes a payment to the payment provider, the payment provider may run out of funds. In this regard, the bill payment system 1 can prevent the payment provider from running out of funds by proposing a proposed charge timing based on the period for the card company to make a charge equivalent to the amount to be charged to the payment provider.

[0090] [6. Modifications] The present disclosure is not limited to the above-described embodiments, and may be modified as appropriate without departing from the spirit of the present disclosure.

[0091] 7 is a diagram showing an example of functions realized in the modified example. For example, the payment service provider server 10 includes a bonus granting unit 105, a type information acquisition unit 106, an other invoice information acquisition unit 107, an expiration date information acquisition unit 108, a determination unit 109, and a display control unit 110. The bonus granting unit 105, the type information acquisition unit 106, the other invoice information acquisition unit 107, the expiration date information acquisition unit 108, the determination unit 109, and the display control unit 110 are realized by the control unit 11.

[0092] [6-1. Variation 1] For example, in the embodiment, a case is given in which a suggested charge timing according to the deposit period is proposed after the user specifies a designated payment timing. In variant 1, a case is described in which a suggested payment timing according to the deposit period is proposed after the user specifies a designated charge timing. As in the embodiment, the payment source in variant 1 is a charge means for charging a directly used payment means that is directly used in payment, and is a charge means that is indirectly used in payment. As in the embodiment, the payment source information acquisition unit 101 acquires charge means information related to the charge means as payment source information.

[0093] In variant 1, a reservation screen SC3 (reservation screen SC3 in the upper right of Figure 3) that accepts the designation of the designated charge timing is displayed before a reservation screen SC3 (reservation screen SC3 in the lower left of Figure 2) that accepts the designation of the designated payment timing is displayed. In variant 1, the reservation screen SC3 that accepts the designation of the designated charge timing does not propose a suggested charge timing. The user specifies any designated charge timing. For example, the user specifies a designated charge timing that is earlier than the invoice payment due date. The reservation screen SC3 may propose a suggested charge timing that is earlier than the invoice payment due date. The payment service provider server 10 acquires data indicating the designated charge timing designated by the user from the user terminal 40. The proposal unit 102 identifies the designated charge timing designated by the user based on the data.

[0094] The suggestion unit 102 of the first modification proposes to the user a proposed payment timing according to the deposit period from the administrator of the charge method to the administrator of the payment method, as the proposed timing for payment, based on the charge method information and the designated charge timing specified by the user. For example, the suggestion unit 102 proposes a timing when the deposit period from the administrator of the charge method to the administrator of the payment method has elapsed from the designated charge timing specified by the user, or a timing thereafter, as the proposed payment timing according to the deposit period. As described above, data indicating the deposit period is stored in the data storage unit 100, and the suggestion unit 102 calculates the proposed payment timing to be proposed based on that data.

[0095] For example, suppose the charging method is a credit card, and the payment period from the card company to the payment service provider for the amount of the charge is one week. Furthermore, suppose the designated charge timing specified by the user is January 12, 2024. In this case, the proposal unit 102 proposes January 19, 2024, one week after the designated charge timing of January 12, 2024, or a later date (for example, January 22, 2024), as the proposed payment timing corresponding to the payment period.

[0096] For example, suppose the charging method is a bank account, and the period for depositing the amount of the charge from the bank that manages the charging method to the payment service provider is two days. Furthermore, suppose the designated charging timing specified by the user is January 16, 2024. In this case, the proposal unit 102 proposes January 18, 2024, two days after the designated charging timing of January 16, 2024, or a later date (for example, January 19, 2024), as the proposed payment timing corresponding to the deposit period.

[0097] In the first modification, the setting unit 103 sets the designated payment timing specified by the user when a proposed payment timing is proposed. For example, the setting unit 103 associates the invoice ID of the invoice read by the user with the designated payment timing specified on the reservation screen SC3 in the lower left of Figure 2 and stores them in the payment service database DB, thereby setting the designated payment timing specified by the user. The setting unit 103 stores reservation history information indicating the designated payment timing specified by the user in the payment service database DB.

[0098] The execution unit 104 of the first modification executes a payment process for payment as a payment-related process based on the designated payment timing designated by the user. For example, the execution unit 104 acquires the current date and time and determines whether the designated payment timing has arrived. The method for acquiring the current date and time may be a known method. For example, the execution unit 104 may acquire the current date and time using a real-time clock, a GPS, or the like. If the execution unit 104 determines that the designated payment timing has not arrived, it does not execute the payment process, but if it determines that the designated payment timing has arrived, it executes the payment process. The arrival of the designated payment timing serves as a condition (trigger) for executing the payment process.

[0099] The bill payment system 1 of Variation 1 proposes to the user a proposed payment timing based on the period of time it takes for the administrator of the charging method to deposit funds into the administrator of the payment method, as a proposed timing for payment, based on the charging method information and the designated charging timing specified by the user. When the proposed payment timing is proposed, the bill payment system 1 sets the designated payment timing specified by the user. The bill payment system 1 executes the payment process for payment as a payment-related process based on the designated payment timing specified by the user. This allows the user to understand the proposed payment timing based on the period of time it takes for the administrator of the charging method to deposit funds into the administrator of the payment method, thereby improving user convenience. In addition, for example, the bill payment system 1 can also improve the convenience of payment service providers. For example, when the charging method is a credit card, there may be a certain period of time (e.g., one week) for the card company to deposit the amount equivalent to the charge amount into the payment service provider. If the payment service provider deposits funds into the collection organization before the card company deposits funds into the payment service provider, the payment service provider may run out of funds. In this regard, the bill payment system 1 can prevent the payment service provider from running out of funds by proposing a proposed payment timing based on the deposit period for the deposit equivalent to the charge amount from the card company to the payment service provider.

[0100] [6-2. Variation 2] For example, the user may be allowed to specify any one of a plurality of payment methods as the payment source. The proposal unit 102 of the second modification example identifies the payment method the user has specified as the payment source from among the plurality of payment methods available to the user based on the payment source information, and proposes to the user a proposal timing based on the deposit period of the identified payment method.

[0101] In Variation 2, as in the embodiment and Variation 1, an example is taken of a case where a charging method is the payment source. Furthermore, an example is taken of a case where a credit card and a bank account correspond to two payment methods. A user can designate either a credit card or a bank account as the payment source. The payment methods that a user can designate as the payment source are not limited to two as in Variation 2. For example, a user may designate any payment method from among three or more payment methods as the payment source. Furthermore, the payment methods that a user can designate as the payment source are not limited to a credit card and a bank account. A user may designate other payment methods, such as sales proceeds from an online shopping mall, as the payment source.

[0102] The data storage unit 100 of the second modification stores deposit period data indicating the relationship between payment methods that a user can specify as payment sources and deposit periods. The deposit period data may be in any format. For example, the deposit period data may be in table format, mathematical formula format, part of a program, or a machine learning model. In the second modification, since a user can specify two payment methods as payment sources, a first deposit period (e.g., one week) is defined in the deposit period data for a first payment method (e.g., a credit card). A second deposit period (e.g., two days) is defined in the deposit period data for a second payment method (e.g., a bank account).

[0103] For example, the suggestion unit 102 identifies the deposit period of the payment method designated by the user as the payment source based on the deposit period data. The suggestion unit 102 proposes to the user a proposed timing according to the identified deposit period. For example, if the payment method designated by the user as the payment source is a first payment method (e.g., a credit card), the suggestion unit 102 proposes to the user a proposed timing according to the first deposit period (e.g., one week). If the payment method designated by the user as the payment source is a second payment method (e.g., a bank account), the suggestion unit 102 proposes to the user a proposed timing according to the second deposit period (e.g., two days).

[0104] The bill payment system 1 of Variation 2 identifies a payment method designated by the user as the payment source from among multiple payment methods available to the user, based on payment source information, and proposes to the user a proposed timing based on the deposit period for the identified payment method. This allows the user to understand the proposed timing based on the deposit period for the payment method designated by the user, thereby improving user convenience. For example, if the payment source is a credit card, the user can understand the proposed timing based on the credit card deposit period. If the payment source is a bank account, the user can understand the proposed timing based on the bank account deposit period. In other examples, the bill payment system 1 can also improve convenience for payment service providers. For example, the deposit period from the card company or bank to the payment service provider may differ when the payment source is a credit card and when the payment source is a bank account. In this regard, the bill payment system 1 more reliably prevents payment service providers from running out of funds by proposing a proposed timing based on the payment source designated by the user.

[0105] [6-3. Variation 3] For example, a benefit may be granted to a user when the user specifies the proposed timing proposed by the suggestion unit 102 or a designated timing corresponding to the proposed timing. For example, the designated timing corresponding to the proposed timing proposed by the suggestion unit 102 is a designated timing that is earlier or later than the proposed timing proposed by the suggestion unit 102. A benefit is a benefit for a user. A benefit can also be called a reward. For example, a benefit may be points, electronic money, coupons, free coupons, product vouchers, content such as videos, lottery tickets, or other benefits. A benefit may be granted to a user in any manner. For example, the benefit granting unit 105 described below may grant a benefit by associating benefit information indicating the benefit to be granted to the user with a user ID, or may grant a benefit by increasing the user's balance of points, electronic money, or the like.

[0106] FIG. 8 is a diagram showing an example of a reservation screen SC3 of Modification Example 3. As shown in FIG. 8, the suggestion unit 102 may display, on the reservation screen SC3, a benefit that will be granted to the user when the proposed timing or a designated timing corresponding to the proposed timing is specified, along with a proposed timing for payment. Data indicating the benefit is stored in the data storage unit 100. The suggestion unit 102 identifies what benefit will be granted to the user based on the data, and displays a reservation screen SC3 indicating the benefit on the user terminal 40. In the example of FIG. 8, the suggestion unit 102 informs the user on the reservation screen SC3 that the benefit will be granted when the proposed charge timing or a designated charge timing earlier than the proposed charge timing is specified.

[0107] The method of notifying the user of the benefit is not limited to the message and speech bubble shown in FIG. 8 , and any method may be used. For example, the suggestion unit 102 may notify the user of the benefit based on an image other than a speech bubble. The suggestion unit 102 may notify the user of the benefit by displaying dates on the calendar of the reservation screen SC3, on which the benefit is granted, differently from dates on which the benefit is not granted (for example, by displaying these dates in different colors). The suggestion unit 102 may notify the user of the benefit on a screen other than the reservation screen SC3 on which the designated charge timing is accepted. For example, the suggestion unit 102 may notify the user of the benefit on the reservation screen SC3 on which the designated payment timing is accepted, or on a screen other than the reservation screen SC3. The suggestion unit 102 may notify the user of the benefit using a method such as a pop-up, a window, or a modal.

[0108] The bill payment system 1 of the third modification includes a reward granting unit 105. The reward granting unit 105 grants a reward to the user based on the proposed timing proposed by the proposal unit 102 and the specified timing specified by the user. For example, the reward granting unit 105 determines whether the proposed timing proposed by the proposal unit 102 is the same as the specified timing specified by the user. If the reward granting unit 105 determines that the proposed timing proposed by the proposal unit 102 is different from the specified timing specified by the user, it does not grant a reward to the user, and if it determines that the proposed timing proposed by the proposal unit 102 is the same as the specified timing specified by the user, it grants a reward to the user.

[0109] For example, the benefit granting unit 105 may grant a first benefit to the user when it is determined that the proposed timing proposed by the proposal unit 102 is different from the specified timing specified by the user, and may grant a second benefit that is better than the first benefit to the user when it is determined that the proposed timing proposed by the proposal unit 102 is the same as the specified timing specified by the user. A better benefit means that the value of the benefit is high. For example, a higher number of points, a higher amount of electronic money, a higher coupon discount amount, a higher number of free tickets, a higher number of product exchange coupons, a higher number of lottery tickets, or a higher number of content such as videos corresponds to a better benefit.

[0110] For example, the reward granting unit 105 may determine whether the specified timing specified by the user is earlier than the proposed timing proposed by the proposing unit 102. If it is determined that the specified timing specified by the user is later than the proposed timing proposed by the proposing unit 102, the reward granting unit 105 may not grant a reward to the user, and if it is determined that the specified timing specified by the user is earlier than the proposed timing proposed by the proposing unit 102, the reward granting unit 105 may grant a first reward to the user if it is determined that the specified timing specified by the user is later than the proposed timing proposed by the proposing unit 102, and may grant a second reward to the user if it is determined that the specified timing specified by the user is earlier than the proposed timing proposed by the proposing unit 102.

[0111] For example, the reward granting unit 105 may determine whether the specified timing specified by the user is later than the proposed timing proposed by the proposing unit 102. If it is determined that the specified timing specified by the user is earlier than the proposed timing proposed by the proposing unit 102, the reward granting unit 105 may not grant a reward to the user, and if it is determined that the specified timing specified by the user is later than the proposed timing proposed by the proposing unit 102, the reward granting unit 105 may grant a first reward to the user, if it is determined that the specified timing specified by the user is earlier than the proposed timing proposed by the proposing unit 102, and may grant a second reward to the user, if it is determined that the specified timing specified by the user is later than the proposed timing proposed by the proposing unit 102.

[0112] The bill payment system 1 of the third modification provides a benefit to the user based on the proposed timing suggested to the user and the specified timing specified by the user. This allows the user to acquire a benefit, and the bill payment system 1 can motivate the user to specify the proposed timing suggested to the user or a timing corresponding to the proposed timing.

[0113] [6-4. Variation 4] For example, a user may make payments for multiple bills. In this case, the user may schedule payments for each bill using the same procedure as in the embodiment. However, if the designated payment timing and designated charge timing are the same, the user will need to perform the same process multiple times, which is time-consuming. Therefore, the bill payment system 1 of variant 4 allows the user to schedule reservations for multiple bills all at once. Variation 4 gives an example of a case where both the designated payment timing and the designated charge timing are specified all at once, but it is also possible to specify only either the designated payment timing or the designated charge timing all at once.

[0114] FIG. 9 is a diagram showing an example of a reservation screen SC3 when multiple invoices are reserved at once. For example, when a user selects a bill payment service in a payment app, the user terminal 40 displays a selection screen SC0 on the display unit 45, as shown in the upper left of FIG. 9, for the user to select a method for reserving invoices. In the fourth modification, two methods of reserving invoices are provided: one in which the user reserves a single invoice, and another in which the user reserves multiple invoices at once. For example, when a user selects button B00, the capture screen SC1 in the upper left of FIG. 2 is displayed, and invoices are reserved in the same manner as in the embodiment.

[0115] For example, when the user selects button B01, the user terminal 40 displays a capture screen SC1 on the display unit 45, as shown in the upper right of FIG. 9. The capture screen SC1 is generally similar to that of the embodiment, but displays a button B10 that allows the user to complete reading the invoice. While the capture screen SC1 is displayed, the user sequentially reads multiple invoices with the capture unit 46. The user terminal 40 records the information read from each of the multiple invoices (e.g., invoice ID) in the memory unit 42. For example, when the user selects button B10, the user terminal 40 displays details of each of the multiple invoices read with the capture unit 46 on a detail screen SC2, as shown in the lower left of FIG. 9.

[0116] The process by which the user terminal 40 acquires details of individual invoices may be the same as in the embodiment. For example, the user terminal 40 transmits the invoice ID of each of the multiple invoices to the payment service provider server 10. The payment service provider server 10 receives the invoice ID of each of the multiple invoices from the user terminal 40. The payment service provider server 10 acquires details of each of the multiple invoices from the collection organization server 30 based on the invoice ID of each of the multiple invoices. The payment service provider server 10 displays a details screen SC2 on the user terminal 40, showing details of each of the multiple invoices. The example at the bottom left of Figure 9 shows the details screen SC2 when the user scans two invoices with the photographing unit 46. The user may also scan three or more invoices at once from the photographing screen SC1 at the top right of Figure 9. A maximum limit may be set for the number of invoices that can be reserved at one time.

[0117] The user then specifies the designated payment timing and designated charge timing in the same manner as in the embodiment. In the embodiment, the designated payment timing and designated charge timing were specified for one invoice, but in variant 4, the designated payment timing and designated charge timing for multiple invoices are specified all at once. The user does not need to specify the designated payment timing and designated charge timing for each invoice; specifying the designated payment timing and designated charge timing once will result in specifying the designated payment timing and designated charge timing for each of multiple invoices.

[0118] For example, when a user completes a reservation, the user terminal 40 displays on the reservation screen SC3 that the reservation for each of the multiple invoices has been completed, as shown in the lower right of FIG. 9. In the example in the lower right of FIG. 9, the reservation for each of the two invoices scanned by the user with the photographing unit 46 has been completed. The designated payment timing and designated charge timing for the first invoice are the same as the payment timing and designated charge timing for the second invoice. The user does not make reservations for these two invoices separately, but makes them all at once. This allows the user to specify the designated payment timing and designated charge timing in one go.

[0119] The suggestion unit 102 in Variation 4 suggests to the user a suggested timing common to multiple invoices. For example, as in the embodiment, if the suggested charging timing corresponds to a suggested timing for payment, the suggestion unit 102 suggests a suggested charging timing common to multiple invoices. As in the embodiment, the suggestion unit 102 determines the suggested charging timing to be suggested to the user and displays a reservation screen SC3 similar to the one in the upper right of Figure 3 on the user terminal 40. In the embodiment, the reservation screen SC3 in the upper right of Figure 3 was a screen on which the user specified the specified charging timing for one invoice, but in Variation 4, it becomes a screen on which the user specifies the specified charging timing common to multiple invoices. In other words, in Variation 4, the reservation screen SC3 in the upper right of Figure 3 is a screen common to multiple invoices.

[0120] As in Variation 1, when the proposed payment timing corresponds to a proposed timing for payment, the proposal unit 102 may propose a proposed payment timing common to multiple invoices. As in Variation 1, the proposal unit 102 determines the proposed payment timing to be proposed to the user and displays a reservation screen SC3 similar to Variation 1 on the user terminal 40. In Variation 1, the reservation screen SC3 on which the proposed payment timing is proposed was a screen on which the user specified the designated payment timing for one invoice, but in Variation 4, it becomes a screen on which the user specifies the designated payment timing common to multiple invoices. In other words, in Variation 4, the reservation screen SC3 on which the proposed payment timing is proposed is a screen common to multiple invoices.

[0121] The proposal unit 102 may propose a proposed timing based on the payment deadlines of each of multiple invoices. For example, suppose the payment deadline of the first invoice is January 15, 2024. Suppose the payment deadline of the second invoice is January 28, 2024. In this case, the proposal unit 102 may propose a proposed timing (e.g., January 14, 2024) that comes before the earlier payment deadline of these two invoices. Furthermore, the proposal unit 102 may propose a proposed charging timing according to the payment source information based on the designated payment timing specified by the user. For example, if the designated payment timing is January 14, 2024, the proposal unit 102 may propose January 7, 2024, one week earlier, as the proposed charging timing according to the payment source information.

[0122] Furthermore, the proposing unit 102 may propose a proposed timing that is not common to multiple invoices. For example, the proposing unit 102 may propose a proposed timing for each of multiple invoices on the same screen using the method described in the embodiment. This allows the user to make reservations for multiple invoices at once on the same screen.

[0123] The setting unit 103 of the fourth modification sets a designated timing common to multiple invoices. For example, as in the embodiment, when the designated charge timing corresponds to the designated timing for payment, the setting unit 103 associates the invoice IDs of each of the multiple invoices read by the user with the designated charge timings designated by the user all at once (designated charge timings designated by the user for multiple invoices with a single operation) and stores them in the payment service database DB, thereby setting the designated charge timings designated by the user all at once.

[0124] As in variant 1, when the designated payment timing corresponds to the designated timing for payment, the setting unit 103 associates the invoice ID of each of the multiple invoices read by the user with the designated payment timing specified by the user all at once (the designated payment timing specified by the user for multiple invoices with a single operation) and stores them in the payment service database DB, thereby setting the designated payment timing specified by the user all at once.

[0125] The execution unit 104 of Modification 4 executes processing for each of the multiple invoices based on a specified timing common to the multiple invoices. The processing executed for each invoice may be the same as that of the embodiment or Modification 1. That is, when a user makes reservations for multiple invoices at once, the execution unit 104 executes the processing described in the embodiment for each of the invoices. For example, for each of the invoices, the execution unit 104 executes charging processing when the specified charging timing arrives, and executes payment processing when the specified payment timing arrives.

[0126] The bill payment system 1 of variant 4 proposes to the user a suggested timing common to multiple invoices. The bill payment system 1 sets a designated timing common to multiple invoices. The bill payment system 1 executes processing for each of the multiple invoices based on the designated timing common to the multiple invoices. This eliminates the need for the user to perform similar reservation tasks multiple times, thereby reducing the burden on the user.

[0127] Note that the bill payment system 1 of Variation 4 may include the configuration of Variation 4 without including at least some of the features described in the embodiments (the feature of proposing suggested timing for payment based on payment source information). That is, the bill payment system 1 may not include the payment source information acquisition unit 101 and the proposal unit 102. In this case, the bill payment system 1 includes a configuration that accepts reservations for multiple invoices at once without specifically proposing suggested timing for payment. Such a bill payment system 1 can solve the problem of reducing the user's workload by eliminating the need to perform similar reservation tasks multiple times. In this way, aspects of the bill payment system 1 that solve the problem but do not solve the problem described in the embodiments are also included in the scope of this disclosure. That is, the problem solved by the bill payment system 1 is not limited to the problem described in the section titled "Problems to be Solved by the Invention" in this disclosure.

[0128] [6-5. Variation 5] For example, the timing of the proposal to the user may differ depending on the type of invoice, so the timing of the proposal may be suggested according to the type of invoice. The type of invoice can also be said to be the format or form of the invoice. Variation 5 takes as an example a case where the type of code printed on the invoice corresponds to the type of invoice. The type of invoice is not limited to the code printed on the invoice. For example, the type of invoice may be whether the invoice is paper or electronic data. The type of invoice may also be whether it is a tax or public money invoice. Another example is that the type of invoice may be the issuer of the invoice (e.g., the collection organization). The type of invoice may be anything that allows invoices to be classified from some perspective.

[0129] The bill payment system 1 of Variation 5 includes a type information acquisition unit 106. The type information acquisition unit 106 acquires type information relating to the type of bill. For example, the type information acquisition unit 106 identifies which code has been analyzed based on the results of reading the bill, and acquires the identification result as type information. The type information acquisition unit 106 may acquire the type information itself from the user terminal 40, or may acquire the type information based on information acquired from the user terminal 40.

[0130] As in Variation 5, when the type of code printed on the invoice corresponds to the type of invoice, the type information acquisition unit 106 acquires type information based on information acquired from the user terminal 40. For example, the size of information included in a barcode is smaller than the size of information included in a two-dimensional code. If a bill ID is encoded in the barcode and the bill ID and other information are encoded in the two-dimensional code, the type information acquisition unit 106 may acquire type information by determining whether the information received from the user terminal 40 also includes other information. If the information received from the user terminal 40 does not include other information, the type information acquisition unit 106 acquires type information indicating that the invoice has a barcode printed on it. If the information received from the user terminal 40 includes other information, the type information acquisition unit 106 acquires type information indicating that the invoice has a two-dimensional code printed on it.

[0131] The determination of whether an invoice has a barcode printed on it or a two-dimensional code printed on it may be performed on the user terminal 40 side. In this case, the user terminal 40 transmits the type information itself to the payment service provider server 10. The type information acquisition unit 106 acquires the type information from the user terminal 40. The method of determining the type of invoice is not limited to the above example. The type of invoice may be determined based on a predetermined determination method. For example, if the invoice ID can be used to distinguish between paper and electronic data, the type information acquisition unit 106 may determine the type of invoice based on the invoice ID and acquire the type information. If the issuer of the invoice corresponds to the type of invoice, the type information acquisition unit 106 may determine the type of invoice and acquire the type information by inquiring about the issuer from the receiving organization server 30 or by referring to the issuer included in the information acquired from the user terminal 40.

[0132] The suggestion unit 102 of the fifth modification proposes a suggested timing to the user based on the payment source information and the type information. For example, the suggestion unit 102 identifies a deposit period (e.g., a deposit period for deposits from a card company to a payment service provider) according to the payment source indicated by the payment source information, in the same manner as in the embodiment or the first modification. The method for identifying this deposit period is as described in the embodiment. The suggestion unit 102 identifies a deposit period (e.g., a deposit period for deposits from a payment service provider to a collection organization) according to the type of invoice indicated by the type information.

[0133] For example, an invoice printed with a barcode has a first period (e.g., two days) for payment to the collection organization. An invoice printed with a two-dimensional code has a second period (e.g., a period until two predetermined days each month). The second period is different from the first period. Data indicating the relationship between the invoice type and the payment period is stored in the data storage unit 100. The data may be in any format, such as a table format, a mathematical formula format, part of a program, or a machine learning model. The suggestion unit 102 identifies the payment period according to the invoice type indicated by the type information based on the data. When a barcode is read, the suggestion unit 102 may propose a date that is further away from the designated payment timing as the proposed charge timing than when a two-dimensional code is read.

[0134] For example, when the proposal unit 102 identifies a payment period according to the payment source and a payment period according to the type of invoice, it proposes a proposed timing for payment based on these two payment periods. When the user first specifies the designated payment timing as in the embodiment, the proposal unit 102 determines, as the proposed payment timing to be proposed to the user, a proposed charge timing that is the longer of the two specified payment periods before the designated payment timing specified by the user. When the user first specifies the designated charge timing as in Variation 1, the proposal unit 102 determines, as the proposed payment timing to be proposed to the user, a proposed payment timing that is the longer of the two specified payment periods after the designated charge timing specified by the user.

[0135] The bill payment system 1 of Variation 5 proposes suggested timings to the user based on the payment source information and type information. This allows the user to understand the suggested timings based not only on the payment source indicated by the payment source information but also on the type of bill indicated by the type information, so the bill payment system 1 can effectively improve user convenience.

[0136] The proposing unit 102 may propose a proposed timing based on the payment due date and type information. For example, assume that the payment due date is January 31, 2024. Assume that the payment period for a two-dimensional code is the 15th and 30th of each month (for example, January 15, 2024 and January 30, 2024). Assume that the payment period for a barcode is two days from payment. In this case, the proposing unit 102 may propose a proposed timing that is before the payment due date and that delays the payment period (the date on which the payment is withdrawn from the payment service provider). For example, in the case of a two-dimensional code, the proposing unit 102 may propose January 16, 2024 to January 30, 2024 as the proposed payment timing. In the case of a barcode, the proposing unit 102 may propose January 30, 2024 as the proposed payment timing. The proposing unit 102 may propose a proposed timing that is earlier than the payment due date in case of an error. The proposal unit 102 may propose the proposed charging timing so that the proposed charging timing is a certain period before the designated payment timing.

[0137] Furthermore, the bill payment system 1 of Variation 5 may include the configuration of Variation 5 without including at least some of the features described in the embodiment (the feature of proposing a proposed timing for payment based on payment source information). That is, the bill payment system 1 may not include the payment source information acquisition unit 101. In this case, the bill payment system 1 may propose a proposed timing based on type information, rather than specifically based on payment source information. Such a bill payment system 1 allows the user to understand the proposed timing according to the type of bill, thereby solving the problem of increasing user convenience. In this way, aspects of the bill payment system 1 that solve the problem but do not solve the problem described in the embodiment are also included in the scope of this disclosure. That is, the problem solved by the bill payment system 1 is not limited to the problem described in the section on problems to be solved by the invention in this disclosure.

[0138] [6-6. Variation 6] For example, the bill payment system 1 may execute a series of processes, such as proposing payment timing, when a user changes the reservation details of a reserved bill, rather than when a user reserves a new bill. A reserved bill is a bill that a user has completed reservation for, but has not yet paid.

[0139] FIG. 10 is a diagram showing an example of the flow in which a user changes the reservation details of a reserved invoice. For example, when a user performs an operation to display a list of reserved invoices from the payment app, the user terminal 40 causes the display unit 45 to display a list screen SC4 showing a list of invoices reserved by the user, as shown in the upper left of FIG. 10. The display data for the list screen SC4 is generated by the payment service provider server 10. The payment service provider server 10 identifies the details of the invoices reserved by the user based on the reservation history information stored in the payment service database DB, and generates the display data for the list screen SC4.

[0140] In the example in the upper left of FIG. 10 , there are two reserved invoices. The user selects the invoice for which they wish to change the reservation details from the reserved invoices displayed on the list screen SC4. The user may change the reservation details of multiple reserved invoices at once. In this case, as in Variation 4, a common proposed timing may be proposed for multiple invoices, or different proposed timings may be proposed for each invoice on the same screen. For example, the user selects an invoice for which they wish to change at least one of the set payment timing and charge timing. When the user selects an invoice, the user terminal 40 displays a reservation screen SC3 on the display unit 45, as shown in the upper right of FIG. 10 , which accepts changes to the set payment timing for that invoice. The reservation screen SC3 in the upper right of FIG. 10 differs from the reservation screen SC3 in the lower left of FIG. 2 described in the embodiment in that it accepts changes to the payment timing of reserved invoices. However, the processing required for displaying the screen is the same as in the embodiment.

[0141] In the sixth modification, the suggestion unit 102 proposes a proposed payment timing to the user when the user changes the timing already set for the invoice. For example, when the user specifies a designated payment timing on the reservation screen SC3 in the upper right of FIG. 10, the suggestion unit 102 proposes a proposed payment timing on the reservation screen SC3 for accepting the specification of the changed designated timing, as shown in the lower left of FIG. 10. The reservation screen SC3 in the lower left of FIG. 10 differs from the reservation screen SC3 in the upper right of FIG. 3 described in the embodiment in that it is a screen for accepting changes to the charge timing of a reserved invoice, but the processing required for displaying it is the same as in the embodiment. When the user completes the changes to the reservation details, the user terminal 40 displays the reservation screen SC3 indicating that the changes to the reservation details have been completed on the display unit 45, as shown in the lower right of FIG. 10.

[0142] The method for proposing the proposed timing for payment may be the same as in the embodiment or Variation 1. For example, in the case where the proposed charge timing corresponds to the proposed timing for payment as in the embodiment, when the user changes the set charge timing, the proposing unit 102 proposes to the user, as the proposed timing for payment, a proposed charge timing according to the deposit period from the administrator of the charge method (e.g., a card company) to the administrator of the directly used payment method directly used for payment (in this embodiment, the payment service provider), based on the charge method information and the designated payment timing specified by the user. The process for specifying the charge timing to be proposed by the proposing unit 102 may be the same as in the embodiment.

[0143] For example, as in Modification 1, when the proposed payment timing corresponds to the proposed timing for payment, the proposal unit 102 proposes to the user, as the proposed timing for payment, a proposed payment timing according to the deposit period from the administrator of the charge method (e.g., a card company) to the administrator of the directly used payment method directly used for payment (in this embodiment, the payment service provider), based on the charge method information and the designated charge timing specified by the user, when the user changes the set payment timing. The process for specifying the proposed payment timing to be proposed by the proposal unit 102 may be the same as in Modification 1.

[0144] The setting unit 103 of the sixth modification example changes the timing already set for an invoice to a specified timing designated by the user. Changing the set timing means changing the set timing to a new timing. Changing the set timing can also be called updating the set timing. For example, the setting unit 103 changes the set timing associated with the invoice ID of the invoice to be changed, among the set timings stored in the payment service database DB, to the specified timing designated by the user.

[0145] For example, as in the embodiment, when the proposed charge timing corresponds to the proposed timing for payment, the setting unit 103 changes the set charge timing to the designated charge timing designated by the user. As in the first modification, when the proposed payment timing corresponds to the proposed timing for payment, the setting unit 103 changes the set payment timing to the designated payment timing designated by the user.

[0146] The bill payment system 1 of variant 6 proposes a suggested timing to the user when the user changes the timing already set for the invoice. The bill payment system 1 changes the timing already set for the invoice to the specified timing specified by the user. This allows the user to know what specified timing to specify as the specified timing for payment when changing the timing of a reserved invoice, thereby enabling the bill payment system 1 to increase user convenience.

[0147] [6-7. Variation 7] For example, as explained in Modification 2, a user may be allowed to select any payment method from among a plurality of payment methods as the payment source. When the payment source is a predetermined payment method, it may be necessary to propose a timing for payment. For example, when the payment source is a payment method that takes a certain amount of time for the payment to be deposited with the payment service provider (e.g., a credit card), it may be necessary to propose a timing for payment more than when the payment source is a payment method that does not take much time for the payment to be deposited with the payment service provider (e.g., sales proceeds from an online shopping mall).

[0148] Therefore, the suggestion unit 102 may determine whether the user has designated a predetermined payment method as the payment source based on the payment source information, and if it is determined that the user has designated a predetermined payment method as the payment source, may suggest to the user a proposed timing for payment. Predetermined identification information that can identify the predetermined payment method is assumed to be stored in advance in the data storage unit 100. In Variation 7, an example is given in which the predetermined payment method is a credit card. The predetermined payment method may be any payment method. The predetermined payment method is not limited to a credit card. For example, the predetermined payment method may be a bank account, a debit card, cryptocurrency, or other payment method.

[0149] For example, the suggestion unit 102 determines whether the payment source indicated by the payment source information is a predetermined payment method (e.g., a credit card) indicated by the predetermined identification information. If the suggestion unit 102 determines that the payment source is not a predetermined payment method, the suggestion unit 102 does not suggest a suggested timing for payment, and if the suggestion unit 102 determines that the payment source is a predetermined payment method, the suggestion unit 102 suggests a suggested timing for payment. The suggested timing for payment may be a suggested charge timing as in the embodiment, or a suggested payment timing as in Modification 1.

[0150] For example, as in the embodiment, when the payment source is a charging method, the suggestion unit 102 determines whether the charging method indicated by the payment source information is the predetermined payment method (e.g., a credit card) indicated by the predetermined identification information. If the suggestion unit 102 determines that the charging method is not the predetermined payment method, it does not suggest a suggested timing for payment, and if it determines that the charging method is the predetermined payment method, it suggests a suggested timing for payment.

[0151] For example, if the payment source is a directly used payment means that is directly used for payment, the suggestion unit 102 determines whether the directly used payment means indicated by the payment source information is a predetermined payment means (e.g., a credit card) indicated by the predetermined identification information. If the suggestion unit 102 determines that the directly used payment means is not a predetermined payment means, it does not suggest a proposed timing for payment, and if it determines that the directly used payment means is a predetermined payment means, it suggests a proposed timing for payment.

[0152] The bill payment system 1 of Variation 7 determines whether the user has designated a predetermined payment method as the payment source based on the payment source information. If it is determined that the user has designated a predetermined payment method as the payment source, the bill payment system 1 suggests a suggested timing for payment to the user. This allows the user to know what timing to specify as the designated timing for payment when the payment source is a predetermined payment method, thereby allowing the bill payment system 1 to increase user convenience.

[0153] [6-8. Variation 8] For example, when there is a reserved invoice, the user may specify the timing of designating the invoice to be reserved, taking into consideration the timing of designating the reserved invoice. Therefore, when the user specifies the timing of designating the invoice to be reserved, a suggestion may be made according to the timing of designating the reserved invoice.

[0154] The bill payment system 1 of variant 8 includes an other invoice information acquisition unit 107. The other invoice information acquisition unit 107 acquires other invoice information related to other invoices that the user has reserved. The other invoice information is information that indicates the reservation details of the other invoices. In variant 8, all or part of the reservation history information stored in the payment service database corresponds to the other invoice information. The other invoice information acquisition unit 107 may acquire other invoice information for all other reserved invoices, or may acquire other invoice information for some of the other invoices. For example, the other invoice information acquisition unit 107 may acquire other invoice information only for other invoices for which payment has not been completed.

[0155] The suggestion unit 102 of Variation 8 suggests a suggested timing for payment to the user based on the payment source information and other invoice information. For example, on reservation screen SC3 showing the reservation details of other invoices indicated by the other invoice information, the suggestion unit 102 suggests a suggested timing for payment to the user based on the payment source information. In this way, the other invoice information is not used in determining the suggested timing to be suggested, but the use of the other invoice information in displaying the screen suggesting the suggested timing also corresponds to the suggestion unit 102 suggesting a suggested timing for payment to the user based on the payment source information and other invoice information.

[0156] FIG. 11 is a diagram showing an example of a reservation screen SC3 of Variation 8. For example, as shown on the left side of FIG. 11, the user terminal 40 displays the designated payment timing of another invoice on the reservation screen SC3 that accepts the designation of the designated payment timing of a certain invoice. The display data for the reservation screen SC3 is generated by the payment service provider server 10. For example, the payment service provider server 10 identifies the designated payment timing of the other invoice based on the other invoice information. The payment service provider server 10 generates display data for the reservation screen SC3 that shows the designated payment timing of the other invoice.

[0157] In the example on the left side of Fig. 11, the payment service provider server 10 generates display data for a reservation screen SC3 in which a speech bubble indicating the designated payment timing of another invoice is placed on a calendar that accepts the user's designation of the designated payment timing of the invoice to be reserved. The designated payment timing of the other invoice may be notified to the user in any manner, and is not limited to the speech bubble shown on the left side of Fig. 11. The payment service provider server 10 may notify the user of the designated payment timing of the other invoice using an image other than a speech bubble, or a message indicating the designated payment timing of the other invoice.

[0158] For example, when the user selects button B30, the suggestion unit 102 suggests a suggested charge timing on a reservation screen SC3, as shown on the right side of Fig. 11, in which a balloon indicating the suggested charge timing for another invoice is placed on a calendar that accepts the user's specification of the suggested charge timing for the invoice they are about to reserve. In variant example 6, the suggested charge timing to be suggested to the user is determined in the same manner as in the embodiment. That is, the suggestion unit 102 does not use other invoice information to determine the suggested charge timing to be suggested to the user, but rather uses other invoice information to generate information to be displayed together with the suggested charge timing to be suggested to the user (in the example on the right side of Fig. 11, a balloon indicating the suggested charge timing for the other invoice).

[0159] The proposal unit 102 may use other invoice information to determine the proposed charging timing to be proposed to the user. For example, the proposal unit 102 may identify the designated charging timing of another invoice based on the other invoice information, and propose a proposed charging timing that is the same as the designated charging timing of another invoice, among the designated charging timings corresponding to the payee indicated by the payee information. Conversely, the proposal unit 102 may propose a proposed charging timing that is different from the designated charging timing of another invoice, among the designated charging timings corresponding to the payee indicated by the payee information, based on the other invoice information.

[0160] Also, as in Variation 1, the proposal unit 102 may propose a proposed payment timing instead of a proposed charge timing. In this case, the proposal unit 102 may also propose a proposed payment timing for the invoice the user is about to reserve, along with the designated payment timings for the other invoices. The processing of the proposal unit 102 in this case may be similar to the processing described as the processing required to display the reservation screen SC3 on the left side of FIG. 11. The proposal unit 102 may identify the designated payment timing for the other invoice based on the other invoice information, and propose a proposed payment timing that is the same as the designated payment timing for the other invoice, among the designated payment timings corresponding to the payee indicated by the payee information. Conversely, the proposal unit 102 may propose a proposed payment timing that is different from the designated payment timing for the other invoice, among the designated payment timings corresponding to the payee indicated by the payee information, based on the other invoice information.

[0161] The bill payment system 1 of variant 8 acquires other invoice information related to other invoices reserved by the user. The bill payment system 1 proposes a suggested timing to the user based on the payment source information and the other invoice information. This allows the user to specify the designated timing for the invoice to be reserved while taking into consideration the reservation details of the other reserved invoices, thereby allowing the bill payment system 1 to increase user convenience. For example, the user can specify a designated charge timing that is different from the designated charge timing of the other reserved invoices, or can specify a designated charge timing that is the same as the designated charge timing of the other reserved invoices. The user can specify a designated payment timing that is different from the designated payment timing of the other reserved invoices, or can specify a designated payment timing that is the same as the designated payment timing of the other reserved invoices.

[0162] [6-9. Variation 9] For example, a payment method designated as a payment source may have an expiration date. As in the embodiment, when the directly used payment method used for payment is electronic money, points may be used in combination with electronic money. In this case, points are also one of the payment sources. The user may set whether or not points may be used in combination when paying an invoice. The expiration date is the time when the asset value of the payment method becomes invalid. The expiration date can also be said to be the time when the expiration date passes. The expiration date may be expressed as a date only, or as a date and time including not only the date but also the time.

[0163] The bill payment system 1 of variant 9 includes an expiration information acquisition unit 108. The expiration information acquisition unit 108 acquires expiration information regarding the expiration date of the payment source. Variation 9 takes as an example a case where the payment source is points. For example, an expiration date is set for all or some of the points held by the user. Variation 9 takes as an example a case where expiration information regarding the expiration date of points is stored in the payment service database DB. In this case, the expiration information acquisition unit 108 acquires the expiration information of the payment source from the payment service database DB.

[0164] The expiration time information may be stored in a database other than the payment service database DB. In this case, the expiration time information acquisition unit 108 acquires the payment source's expiration time information from the other database. The expiration time information may be stored in a computer or external information storage medium other than the payment service provider server 10. In this case, the expiration time information acquisition unit 108 acquires the expiration time information from the other computer or external information storage medium.

[0165] The suggestion unit 102 of the ninth modification proposes a proposed timing to the user based on the payment source information and the expiration time information. For example, when the payment source indicated by the payment source information is a predetermined payment method (e.g., points), the suggestion unit 102 proposes to the user a proposed timing that is equal to or earlier than the expiration time indicated by the expiration time information. Although the method of determining the proposed timing to be proposed to the user differs from the embodiment, the processing of the proposal after the proposed timing is determined may be the same as in the embodiment. The same applies when a proposed payment timing is proposed, as in the first modification. For example, the suggestion unit 102 may propose to the user a proposed payment timing that is earlier than the expiration time of the points that are the payment source.

[0166] The proposal unit 102 may propose a proposed timing based on the payment deadline of the invoice and the expiration time information. For example, the proposal unit 102 may compare the payment deadline of the invoice with the expiration time indicated by the expiration time information, and propose a proposed timing based on the result of the comparison. If the expiration time is before the payment deadline, the proposal unit 102 may propose a proposed timing according to the expiration time. If the expiration time is after the payment deadline, the proposal unit 102 may propose a proposed timing according to the payment deadline.

[0167] The bill payment system 1 of Variation 9 proposes a suggested timing to the user based on payment source information and expiration date information. This allows the user to specify the suggested timing for payment while taking into account the expiration date of the payment source, so the bill payment system 1 can improve user convenience. For example, the user can use points to pay a bill before the points expire.

[0168] Note that the bill payment system 1 of Variation 9 may include the configuration of Variation 9 without including at least some of the features described in the embodiment (the feature of proposing a proposed timing for payment based on payment source information). That is, the bill payment system 1 may not include the payment source information acquisition unit 101. In this case, the bill payment system 1 may propose a proposed timing based on expiration date information, rather than based specifically on payment source information. Such a bill payment system 1 allows the user to understand the proposed timing based on the expiration date of points, etc., thereby solving the problem of improving user convenience. In this way, aspects of the bill payment system 1 that solve the problem but do not solve the problem described in the embodiment are also included in the scope of this disclosure. That is, the problem solved by the bill payment system 1 is not limited to the problem described in the section titled "Problems to be Solved by the Invention" in this disclosure.

[0169] [6-10. Variation 10] For example, a user may be able to use multiple payment methods in combination to pay a bill. Variation 10 takes as an example a case where a user pays a bill using both electronic money and points. The user may be free to choose whether or not to use these methods in combination. However, depending on the bill, the user may be able to use electronic money but not points.

[0170] For example, when an invoice is used to pay taxes, the user may be able to use electronic money but not points. Another example is when an invoice with a printed barcode is used, the user may be able to use electronic money but not points. Therefore, the invoice payment system 1 of variant 10 determines whether points can be used to pay the invoice. The invoice payment system 1 increases user convenience by displaying a reservation screen SC3 according to the result of this determination.

[0171] The bill payment system 1 of variant 10 includes a determination unit 109 and a display control unit 110. The determination unit 109 determines whether a specified payment method can be used to pay a bill. The specified payment method is at least one of the payment methods that the user can use in the payment service. In variant 10, an example is taken where the specified payment method is points. The specified payment method may be a payment method that is determined in advance. For example, the specified payment method may be a payment method that the user cannot use to pay certain bills. Conversely, the specified payment method may be a payment method that the user can use to pay only certain bills. Data that can identify the specified payment method is assumed to be pre-stored in the data storage unit 100.

[0172] The determination unit 109 may determine whether a predetermined payment method can be used to pay the invoice based on a predetermined determination method. In Variation 10, examples of the predetermined determination method include a method using an invoice ID or payee and a method using an invoice code. The predetermined determination method may be other methods and is not limited to these methods. The determination unit 109 may make a determination based on other methods. For example, the determination unit 109 may determine whether a predetermined payment method can be used to pay the invoice by determining whether the payment amount of the invoice is equal to or greater than a predetermined amount. The determination unit 109 may determine whether a predetermined payment method can be used to pay the invoice by determining whether the payment deadline for the invoice is a predetermined deadline.

[0173] For example, the determination unit 109 determines whether a predetermined payment method can be used in conjunction with a payment in which another payment method is used. The other payment method is a payment method that the user uses together with the predetermined payment method. For example, the other payment method is a directly used payment method. The other payment method can also be the user's main payment method. In variant example 10, the other payment method is electronic money. The other payment method may be any payment method other than the predetermined payment method and is not limited to electronic money. For example, the other payment method may be a credit card, an account such as a bank account, or any other payment method exemplified in the embodiments.

[0174] For example, the determination unit 109 determines whether a specified payment method can be used to pay an invoice based on invoice information acquired by the user terminal 40 reading the invoice. In variant example 10, the payee corresponds to the invoice information, but the invoice information is not limited to the payee as long as it is information somehow related to the invoice. For example, the invoice information may be other information such as an invoice ID, payment amount, or payment deadline. For example, the determination unit 109 acquires the invoice information from the user terminal 40. The determination unit 109 may inquire about the invoice information from the receiving organization server 30 based on the invoice ID acquired from the user terminal 40. The determination unit 109 may acquire the invoice information from the receiving organization server 30.

[0175] For example, the data storage unit 100 stores determination method data indicating at least one of invoice information for invoices for which a specified payment method can be used and invoice information for invoices for which the specified payment method cannot be used. The determination method data may be in any format, such as a mathematical formula, a table, part of a program, or a machine learning model. The determination unit 109 determines whether a specified payment method can be used to pay the invoice based on the determination method data and the invoice information for the invoice read by the user terminal 40.

[0176] For example, suppose the determination method data indicates that a specified payment method cannot be used if the payee of an invoice is an institution that receives taxes. In this case, the determination unit 109 determines, based on the determination method data, whether the payee indicated in the invoice information of the invoice read by the user terminal 40 is the institution. If the determination unit 109 determines that the payee is the institution, it determines that the specified payment method cannot be used, and if it determines that the payee is not the institution, it determines that the specified payment method can be used.

[0177] For example, the determination unit 109 may determine whether a predetermined payment method can be used to pay an invoice based on the type of invoice read by the user terminal 40. The invoice type is as described in Variation 5. Variation 10 takes as an example a case where the invoice type is the type of code printed on the invoice. For example, the determination method data indicates that if a barcode is printed on the invoice, the predetermined payment method cannot be used. The determination unit 109 determines whether the code indicated in the invoice information of the invoice read by the user terminal 40 is a barcode based on the determination method data. If the determination unit 109 determines that the code is a barcode, it determines that the predetermined payment method cannot be used, and if it determines that the code is not a barcode, it determines that the predetermined payment method can be used.

[0178] In addition, when both a barcode and a two-dimensional code are printed on the same invoice, the determination unit 109 may make a determination based on which code the user reads. Furthermore, the determination unit 109 may make a determination based on both the invoice information acquired by the user terminal 40 reading the invoice and the type of invoice read by the user terminal 40. For example, when both a barcode and a two-dimensional code are printed on a tax invoice, the determination unit 109 may determine whether the payee is an institution that receives tax and whether the two-dimensional code has been read. In this case, if the payee is an institution that receives tax and the two-dimensional code has been read, a predetermined payment method may be available. In other words, if the payee is not an institution that receives tax or if the barcode has been read, the predetermined payment method may not be available.

[0179] When a user makes a reservation for payment of an invoice, the display control unit 110 displays a reservation screen SC3 that accepts the reservation for payment based on the determination result of the determination unit 109. The display control unit 110 generates display data for the reservation screen SC3 and transmits it to the user terminal 40, thereby displaying the reservation screen SC3. The meaning of the display data is as explained in the embodiment. The display control unit 110 reflects the determination result of the determination unit 109 in the display of the reservation screen SC3.

[0180] FIG. 12 is a diagram showing an example of a reservation screen SC3 of Modification Example 10. For example, as shown in the upper left of FIG. 12, when a bill is read from the photographed screen SC1, a determination is made by the determination unit 109. For example, if the display control unit 110 determines that a predetermined payment method (e.g., points) can be used to pay the bill, it displays a reservation screen SC3 on which the predetermined payment method can be selected, as shown in the upper right of FIG. 12. In the example in the upper right of FIG. 12, the display control unit 110 displays a button B41 (the second button from the top in the example in the upper right of FIG. 12) on the reservation screen SC3 indicating that points ("AAA Points" in the example in the upper right of FIG. 12) which are an example of a predetermined payment method can be used, along with electronic money ("AAA Cash" in the example in the upper right of FIG. 12).

[0181] For example, if the display control unit 110 determines that a predetermined payment method (e.g., points) cannot be used to pay the bill, the display control unit 110 displays a reservation screen SC3 in which the predetermined payment method cannot be selected, as shown in the lower right of FIG. 12. The reservation screen SC3 in which the predetermined payment method cannot be selected may be a screen in which the predetermined payment method is displayed but grayed out so that it cannot be selected, or the predetermined payment method may not be displayed at all. In the example in the lower right of FIG. 12, the display control unit 110 displays a button B41 (the grayed-out button second from the top in the example in the upper right of FIG. 12) on the reservation screen SC3, indicating that points (e.g., "AAA Points" in the example in the upper right of FIG. 12) that are an example of a predetermined payment method cannot be used, along with electronic money (e.g., "AAA Cash" in the example in the upper right of FIG. 12). The display control unit 110 may not display the button B41 on the reservation screen SC3.

[0182] The selection of the payment method to be used as the payment source may be performed by a method other than the button B41. The display control unit 110 can display the reservation screen SC3 on the user terminal 40, from which a predetermined payment method can be selected, using a method adopted in various known user interfaces. For example, the display control unit 110 can display the reservation screen SC3 on the user terminal 40, from which a predetermined payment method can be selected, using an input form other than the button B41, text, a slide bar, or other methods.

[0183] The setting unit 103 of the tenth modification performs settings related to reservations based on user operations on the reservation screen SC3. For example, the setting unit 103 sets the payment source to be used for paying an invoice. The setting unit 103 stores reservation history information indicating the payment method specified by the user on the reservation screen SC3 as the payment source in the payment service database DB. For example, if the user selects a specific payment method, the setting unit 103 stores reservation history information indicating the specific payment method as the payment source in the payment service database DB. If the user does not select a specific payment method, the setting unit 103 stores reservation history information indicating a payment method other than the specific payment method as the payment source in the payment service database DB.

[0184] The execution unit 104 of the tenth modification executes payment-related processing based on the reservation-related settings. For example, the execution unit 104 executes payment-related processing with the payment method specified by the user as the payment source. When the user selects a predetermined payment method, the execution unit 104 executes payment-related processing with the predetermined payment method as the payment source. When the user does not select a predetermined payment method, the execution unit 104 executes payment-related processing with a payment method other than the predetermined payment method as the payment source. Note that the determination of whether a predetermined payment method can be used to pay an invoice may be made when the invoice payment is executed, rather than when the invoice payment is scheduled.

[0185] The bill payment system 1 of Variation 10 displays a reservation screen SC3 based on the determination result of whether a specified payment method can be used to pay the bill. This allows the user to check the reservation screen SC3 according to the determination result and then perform reservation-related settings, so the bill payment system 1 can improve user convenience. For example, the bill payment system 1 can prevent an error from occurring when a user accidentally specifies points as the payment source for an invoice for which points cannot be used. For example, because the form of a code may change depending on whether a specified payment method can be used, the bill payment system 1 can improve user convenience by controlling whether points can be used depending on the form of the code.

[0186] Note that the bill payment system 1 may include the configuration of variant 10 without including at least some of the features described in the embodiment (the feature of providing suggested timing for payment based on payment source information). That is, the bill payment system 1 may not include the payment source information acquisition unit 101 and the suggestion unit 102. Furthermore, the bill payment system 1 may not include the function of the setting unit 103 to set a specified timing for payment and the function of the execution unit 104 to execute processing for payment based on the specified timing.

[0187] For example, the bill payment system 1 may include the determination unit 109 and the display control unit 110, and may also include the functions of the setting unit 103 and the execution unit 104 described in Modification 10. Such a bill payment system 1 can solve the problem of improving user convenience by displaying the reservation screen SC3 based on the determination result of the determination unit 109. In this way, the scope of the present disclosure also includes aspects in which the bill payment system 1 solves the problem but does not solve the problems described in the embodiments. In other words, the problems solved by the bill payment system 1 are not limited to the problems described in the "Problems to be Solved by the Invention" section of this disclosure. Therefore, it would be obvious to one skilled in the art upon reading this disclosure that the present disclosure includes the configurations (20) to (23) described below and detailed descriptions of those configurations.

[0188] [6-11. Other variations] For example, the above modifications may be combined.

[0189] For example, when paying an invoice, no particular charge may be required. In this case, the user does not specify the designated charge timing. Furthermore, the payment source is a directly used payment method that is directly used to pay the invoice. For example, when the user specifies a credit card as the directly used payment method, the suggestion unit 102 may suggest to the user a suggested timing according to the credit card that is the directly used payment method. For example, the suggestion unit 102 may suggest to the user a suggested timing according to the period for depositing funds from the credit card company to the payment service provider. When the user specifies a bank account as the directly used payment method, the suggestion unit 102 may suggest to the user a suggested timing according to the bank account that is the directly used payment method. For example, the suggestion unit may suggest to the user a suggested timing according to the period for depositing funds from the bank to the payment service provider.

[0190] For example, in S14 of Fig. 6, the case where the charging process is executed in cooperation between the payment service provider server 10 and the card company server 20 has been described, but the charging process may also be executed by another computer. If the charging means is a bank account, the charging process may be executed by a bank server. If the charging means is crypto assets, the charging process may be executed by a server that manages crypto assets. If the charging means is cash inserted into an ATM, the charging process may be executed by a server that can communicate with the ATM.

[0191] For example, the functions described as being realized by the payment service provider server 10 may be realized by the card company server 20, the receiving organization server 30, the user terminal 40, or another computer. The processing described as being realized by the payment service provider server 10 may be shared among multiple computers.

[0192] [7. Notes] For example, a bill payment system can be configured as follows: (1) a payment source information acquisition unit that acquires payment source information regarding payment sources that are used directly or indirectly in paying bills; a proposal unit that proposes a proposed timing for the payment to the user who reserves the payment based on the payment source information; a setting unit that sets the designated timing designated by the user when the proposed timing is proposed; an execution unit that executes processing related to the payment based on the specified timing; Bill payment system including. (2) the proposal unit proposes to the user the proposed timing according to a deposit period related to the payment source based on the payment source information; (1) A bill payment system as described in (1). (3) The payment source is a charging means for charging a directly used payment means that is directly used in the payment, and is a charging means that is indirectly used in the payment, the payment source information acquisition unit acquires charging means information relating to the charging means as the payment source information, The suggestion unit proposes to the user, as the proposed timing, a proposed charging timing according to the deposit period from the manager of the charging means to the manager of the directly used payment means, based on the charging means information and the designated payment timing designated by the user; the setting unit sets a designated charge timing designated by the user when the proposed charge timing is proposed; the execution unit executes, as the processing, a charging process related to the charging based on the specified charging timing. (2) A bill payment system as described in (2). (4) The payment source is a charging means for charging a directly used payment means that is directly used in the payment, and is a charging means that is indirectly used in the payment, the payment source information acquisition unit acquires charging means information relating to the charging means as the payment source information, The proposal unit proposes to the user, as the proposed timing, a proposed payment timing according to the deposit period from the administrator of the charging means to the administrator of the directly used payment means, based on the charging means information and the designated charging timing specified by the user; the setting unit sets a designated payment timing designated by the user when the proposed payment timing is proposed; the execution unit executes, as the processing, a payment process for the payment based on the specified payment timing. (2) or (3) above, a bill payment system. (5) the proposal unit identifies the payment means designated by the user as the payment source from among the plurality of payment means available to the user based on the payment source information, and proposes to the user the proposal timing according to the deposit period of the identified payment means; A bill payment system according to any one of (2) to (4). (6) The bill payment system further includes a benefit granting unit that grants a benefit to the user based on the proposed timing and the specified timing. A bill payment system according to any one of (1) to (5). (7) the proposal unit proposes to the user the proposal timing common to the plurality of invoices, the setting unit sets the designated timing common to the plurality of invoices, the execution unit executes the processing for each of the plurality of invoices based on the specified timing common to the plurality of invoices. A bill payment system according to any one of (1) to (6). (8) The bill payment system further includes a type information acquisition unit that acquires type information regarding the type of the bill, the suggestion unit suggests the suggested timing to the user based on the payment source information and the type information. A bill payment system according to any one of (1) to (7). (9) the suggestion unit suggests the suggested timing to the user when the user changes the timing already set for the invoice; The setting unit changes the set timing to the designated timing designated by the user. A bill payment system according to any one of (1) to (8). (10) the suggestion unit determines whether the user has designated a predetermined payment means as the payment source based on the payment source information, and when it is determined that the user has designated the predetermined payment means as the payment source, suggests the suggestion timing to the user; A bill payment system according to any one of (1) to (9). (11) The bill payment system further includes an other bill information acquisition unit that acquires other bill information related to other bills reserved by the user, the proposal unit proposes the proposed timing to the user based on the payment source information and the other invoice information; A bill payment system according to any one of (1) to (10). (12) The bill payment system further includes an expiration information acquisition unit that acquires expiration information regarding the expiration time of the payment source, the suggestion unit suggests the suggested timing to the user based on the payment source information and the expiration time information. A bill payment system according to any one of (1) to (11). (13) The bill payment system comprises: a determination unit that determines whether a predetermined payment method can be used for the payment; a display control unit that, when the user reserves the payment, displays a reservation screen that accepts the reservation of the payment based on a determination result of the determination unit; A bill payment system according to any one of (1) to (12), further comprising:

[0193] For example, a bill payment system can be configured as follows: (20) a determination unit that determines whether a predetermined payment method can be used to pay a bill; a display control unit that, when a user reserves the payment, displays a reservation screen that accepts the reservation for the payment based on a determination result of the determination unit; a setting unit that performs settings related to the reservation based on an operation by the user on the reservation screen; an execution unit that executes processing related to the payment based on the setting; Bill payment system including. (twenty one) the determination unit determines whether the predetermined payment method can be used in combination with another payment method for the payment in which another payment method is used; (20) A bill payment system as described in (20). (twenty two) the determination unit determines whether the predetermined payment method can be used for the payment based on bill information acquired by reading the bill with the user terminal of the user; A bill payment system according to (20) or (21). (twenty three) the determination unit determines whether the predetermined payment method can be used for the payment based on the type of the bill read by the user terminal of the user; A bill payment system according to any one of (20) to (22). [Explanation of symbols]

[0194] 1 bill payment system, 10 payment service provider server, 11, 21, 31, 41 control unit, 12, 22, 32, 42 memory unit, 13, 23, 33, 43 communication unit, 20 card company server, 30 collection organization server, 40 user terminal, 44 operation unit, 45 display unit, 46 photography unit, N network, DB payment service database, 100, 200, 300, 400 data storage unit, 101 payment source information acquisition unit, 102 proposal unit, 103 setting unit, 104 execution unit, 105 privilege granting unit, 106 type information acquisition unit, 107 other bill information acquisition unit, 108 expiration time information acquisition unit, 109 judgment unit, 110 display control unit, 201 service provision unit, 301 collection unit, 401 operation reception unit, 402 Display control section, B00, B01, B10, B20, B21, B30, B31, B32, B33, B35, B36, B37, B38, B39, B40, B41 buttons, F34 input form, SC0 selection screen, SC1 shooting screen, SC2 details screen, SC3 reservation screen, SC4 list screen.

Claims

1. a payment source information acquisition unit that acquires payment source information regarding payment sources that are used directly or indirectly in paying bills; a proposal unit that proposes a proposed timing for the payment to the user who reserves the payment based on the payment source information; a setting unit that sets a designated timing designated by the user when the proposed timing is proposed; an execution unit that executes processing related to the payment based on the specified timing; Bill payment system including.

2. the proposal unit proposes to the user the proposed timing according to a deposit period related to the payment source based on the payment source information; 10. The bill payment system of claim 1.

3. The payment source is a charging means for charging a directly used payment means that is directly used in the payment, and is a charging means that is indirectly used in the payment, the payment source information acquisition unit acquires charging means information relating to the charging means as the payment source information, The suggestion unit proposes to the user, as the proposed timing, a proposed charging timing according to the deposit period from the manager of the charging means to the manager of the directly used payment means, based on the charging means information and the designated payment timing designated by the user; the setting unit sets a designated charge timing designated by the user when the proposed charge timing is proposed; the execution unit executes, as the processing, a charging process related to the charging based on the specified charging timing.

3. The bill payment system of claim 2.

4. The payment source is a charging means for charging a directly used payment means that is directly used in the payment, and is a charging means that is indirectly used in the payment, the payment source information acquisition unit acquires charging means information relating to the charging means as the payment source information, The proposal unit proposes to the user, as the proposed timing, a proposed payment timing according to the deposit period from the administrator of the charging means to the administrator of the directly used payment means, based on the charging means information and the designated charging timing specified by the user; the setting unit sets a designated payment timing designated by the user when the proposed payment timing is proposed; the execution unit executes, as the processing, a payment process for the payment based on the specified payment timing.

4. A bill payment system according to claim 2 or 3.

5. the proposal unit identifies the payment means designated by the user as the payment source from among the plurality of payment means available to the user based on the payment source information, and proposes to the user the proposal timing according to the deposit period of the identified payment means; 4. A bill payment system according to claim 2 or 3.

6. The bill payment system further includes a benefit granting unit that grants a benefit to the user based on the proposed timing and the specified timing. A bill payment system according to any one of claims 1 to 3.

7. the proposal unit proposes to the user the proposal timing common to the plurality of invoices, the setting unit sets the designated timing common to the plurality of invoices, the execution unit executes the processing for each of the plurality of invoices based on the specified timing common to the plurality of invoices. A bill payment system according to any one of claims 1 to 3.

8. The bill payment system further includes a type information acquisition unit that acquires type information regarding the type of the bill, the suggestion unit suggests the suggested timing to the user based on the payment source information and the type information. A bill payment system according to any one of claims 1 to 3.

9. the suggestion unit suggests the suggested timing to the user when the user changes the timing already set for the invoice; The setting unit changes the set timing to the designated timing designated by the user. A bill payment system according to any one of claims 1 to 3.

10. the suggestion unit determines whether the user has designated a predetermined payment means as the payment source based on the payment source information, and when it is determined that the user has designated the predetermined payment means as the payment source, suggests the suggestion timing to the user; A bill payment system according to any one of claims 1 to 3.

11. The bill payment system further includes an other bill information acquisition unit that acquires other bill information related to other bills reserved by the user, the proposal unit proposes the proposed timing to the user based on the payment source information and the other invoice information; A bill payment system according to any one of claims 1 to 3.

12. The bill payment system further includes an expiration information acquisition unit that acquires expiration information regarding the expiration time of the payment source, the suggestion unit suggests the suggested timing to the user based on the payment source information and the expiration time information. A bill payment system according to any one of claims 1 to 3.

13. The bill payment system comprises: a determination unit that determines whether a predetermined payment method can be used for the payment; a display control unit that, when the user reserves the payment, displays a reservation screen that accepts the reservation for the payment based on a determination result of the determination unit; 4. The bill payment system of claim 1, further comprising:

14. a payment source information acquisition step of acquiring payment source information relating to a payment source used directly or indirectly in paying the invoice; a proposing step of proposing a proposed timing for the payment to the user who reserves the payment based on the payment source information; a setting step of setting a designated timing designated by the user when the proposed timing is proposed; an execution step of executing a process related to the payment based on the specified timing; Bill payment methods including.

15. a payment source information acquisition unit that acquires payment source information regarding payment sources that are used directly or indirectly in paying bills; a proposal unit that proposes a proposed timing for the payment to the user who reserves the payment based on the payment source information; a setting unit that sets the designated timing designated by the user when the proposed timing is proposed; an execution unit that executes processing related to the payment based on the specified timing; A program that allows a computer to function as a

Images