Invoice payment system, invoice payment method, and program

Abstract

To enhance user convenience.SOLUTION: An invoice payment system (1) includes: a reservation history information acquisition unit (101) configured to acquire reservation history information regarding the reservation history of reserved invoices for which a user has reserved payments; a proposal unit (102) configured to propose to the user a proposal timing related to payment of a target invoice to be reserved by the user on the basis of the reservation history information; 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 of the target invoice to be reserved 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 reservation history information acquisition unit that acquires reservation history information regarding the reservation history of a reserved invoice for which a user has reserved payment; a proposal unit that proposes to the user a proposed timing for payment of the reserved invoice for which the user has reserved payment based on the reservation history 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 for payment of the reserved invoice 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. 13 is a diagram showing an example of a reservation screen according to a fourth modified example. [Figure 9] FIG. 13 is a diagram showing an example of a reservation screen according to a fifth modified example. [Figure 10] FIG. 20 is a diagram showing an example of a reservation screen according to a sixth modification. [Figure 11] FIG. 10 is a diagram showing an example of a reservation screen when multiple invoices are reserved at once. [Figure 12]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. 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 of FIG. 3. The recommended charge timing may differ depending on the user's past reservation trends. For example, if the user tends to set the designated charge timing with a margin of at least one week from the designated payment timing, a designated charge timing more than one week before the designated payment timing is suggested. Conversely, if the user tends to set the designated charge timing just before the designated payment timing, a charge timing just before the designated payment timing is suggested. Hereinafter, the charge timing suggested to the user is referred to as the suggested charge timing. When there is no need to distinguish between the designated charge timing and the suggested charge timing, they are simply referred to as the charge timing.

[0030] For example, if the user tends to spread out the designated charge timings, a designated charge timing different from the designated charge timings set on other invoices is suggested. Conversely, if the user tends to aggregate the designated charge timings rather than spreading them out, a designated charge timing close to the designated payment timings set on other invoices is suggested. If the user's designated charge timings tend to have other trends, a designated charge timing in line with those trends is suggested to the user. In this way, in this embodiment, a charge timing is suggested based on the user's past trends.

[0031] In the example in the upper right of FIG. 3, users tend to set the designated charge timing more than one week before the designated payment timing. For this reason, the proposed charge timing is more than one week before the designated payment timing specified by the user. The user specifies the designated charge timing based on the proposal 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 select button B38 to cancel the charge reservation.

[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 recommended suggested charging times on the reservation screen SC3 based on the user's past reservation trends. Even if the user does not have a clear understanding of their own past trends, they can check which designated charging time suits them and then specify the designated charging time on the reservation screen SC3, so the bill payment system 1 can improve user convenience. The bill payment system 1 will be described in detail 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 reservation history 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. The reservation history information acquisition unit 101, the proposal unit 102, the setting unit 103, and the execution unit 104 are each 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 any 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 registered by the user as a bill payment pattern. In this case, the proposal unit 102, described below, may make proposals based on the payment pattern registered by the user.

[0045] [Reservation history information acquisition section] The reservation history information acquisition unit 101 acquires reservation history information relating to the reservation history of reserved invoices for which a user has reserved payment. A reserved invoice is an invoice for which a reservation has been completed. In other words, a reserved invoice is an invoice for which reservation history information has been created. Since reservation history information is stored in the payment service database DB, the reservation history information acquisition unit 101 acquires reservation history information from the payment service database DB. For example, when a user makes a reservation, the reservation history information acquisition unit 101 acquires reservation history information associated with the user ID of that user.

[0046] In this embodiment, an example is given of a case where a reserved invoice is a concept that encompasses both invoices that have not yet been paid and reserved invoices that have already been paid. For this reason, the reservation history information acquisition unit 101 acquires reservation history information for reserved invoices that have not yet been paid. If all of a user's reserved invoices have been paid, the reservation history information for reserved invoices that have not yet been paid is not stored in the payment service database DB, so the reservation history information acquisition unit 101 does not acquire reservation history information for reserved invoices that have not yet been paid. Even if the reservation history information for reserved invoices that have not yet been paid is stored in the payment service database DB, the reservation history information acquisition unit 101 may not acquire reservation history information for reserved invoices that have not yet been paid.

[0047] For example, the reservation history information acquisition unit 101 acquires reservation history information for reserved invoices that have already been paid. If the user has not yet paid the reserved invoice, the reservation history information for reserved invoices that have already been paid is not stored in the payment service database DB, and therefore the reservation history information acquisition unit 101 does not acquire the reservation history information for reserved invoices that have already been paid. Even if the reservation history information for reserved invoices that have already been paid is stored in the payment service database DB, the reservation history information acquisition unit 101 may not acquire the reservation history information for reserved invoices that have already been paid.

[0048] In this embodiment, an example is given in which the reservation history information acquisition unit 101 acquires reservation history information for all reserved invoices reserved by the user, but the reservation history information acquisition unit 101 may acquire reservation history information for some of the reserved invoices. For example, the reservation history information acquisition unit 101 may acquire reservation history information for reserved invoices reserved by the user within the most recent predetermined period (e.g., the most recent one year) or the most recent predetermined number of payments (e.g., the most recent 10 payments). Data indicating the period or the number of pieces of reservation history information that the reservation history information acquisition unit 101 will acquire is assumed to be predetermined in the data storage unit 100. The reservation history information acquisition unit 101 acquires reservation history information for the period or number of pieces of reservation history information indicated by the data.

[0049] For example, the reservation history information acquisition unit 101 may acquire reservation history information for reserved invoices that have the same or similar content as the reservation target invoice described below. The content of the reservation target invoice is the payee, payment amount, payment object (e.g., taxes or public utility charges), payment deadline (e.g., the month or time of the payment deadline), the type of code printed on the invoice, or a combination of these. The content of the reservation target invoice is similar when the difference between the content of the reservation target invoice and the content of the reserved invoice is within a specified range. For example, a difference in payment amount less than a threshold corresponds to these contents being similar. For example, when the payees are different but the payee classification (e.g., industry or business scale) is the same, these contents are similar.

[0050] The reservation history information may be stored in a database other than the payment service database DB. In this case, the reservation history information acquisition unit 101 acquires the reservation history information from the other database. The reservation history information may be stored in a computer or external information storage medium other than the payment business operator server 10. In this case, the reservation history information acquisition unit 101 acquires the reservation history information from the other computer or external information storage medium.

[0051] [Proposal Department] Based on the reservation history information, the suggestion unit 102 proposes to the user a proposed timing for payment of the reservation target invoice for which the user reserves payment. The reservation target invoice is an invoice that the user is about to reserve. In other words, the reservation target invoice is an invoice for which reservation history information is about to be created or updated. In the examples of Figures 2 and 3, the invoice read by the user with the user terminal 40 corresponds to the reservation target invoice. If no physical invoice is read and only electronic data is exchanged, the invoice indicated by the data received by the user terminal 40 corresponds to the reservation target invoice. When the reservation of the reservation target invoice is completed, the reservation target invoice becomes a reserved invoice.

[0052] 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 charging 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, they will simply be referred to as the payment timing.

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

[0054] In this embodiment, since reservation history information for reserved invoices that have not yet been paid may be acquired, the proposal unit 102 proposes a proposed timing for payment to the user based on the reservation history information for reserved invoices that have not yet been paid. Also, since reservation history information for reserved invoices that have already been paid may be acquired, the proposal unit 102 proposes a proposed timing for payment to the user based on the reservation history information for reserved invoices that have already been paid. The proposal unit 102 proposes a proposed timing for payment to the user based on at least one of the reservation history information for reserved invoices that have not yet been paid and the reservation history information for reserved invoices that have already been paid.

[0055] In this embodiment, an example is given in which the proposed charging timing corresponds to the proposed timing for payment, so the proposal unit 102 proposes to the user, as the proposed timing for payment, a proposed charging timing for a charging means for charging a directly used payment means that is directly used in paying the invoice to be reserved, and a charging means that is indirectly used in paying the invoice to be reserved.

[0056] A direct-use payment method is a payment method through which payment is made. In other words, a direct-use payment method 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 direct-use payment method. Therefore, any description of electronic money used for payment can be read as a direct-use payment method. A direct-use payment method 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 the direct-use payment method is a rechargeable payment method, but a directly used payment source does not have to be rechargeable.

[0057] A charge means can also be referred to as an indirectly used payment source. An indirectly used payment source is a payment means that serves as the source of funds for a directly used payment source. An indirectly used payment source is a payment means that is different from a directly used payment source. In other words, an indirectly used payment source is a means by which payment (also referred to as charge, 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 means 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. The payment source used directly or indirectly may be one that the user can set in the payment app.

[0058] For example, the proposal unit 102 calculates the time difference between the designated payment timing for a reserved invoice and the designated charge timing for the reserved invoice based on the reservation history information. When the proposal unit 102 acquires reservation history information for each of multiple reserved invoices, it calculates the average value of the time difference between the designated payment timing and the designated charge timing for each reserved invoice as the overall time difference. The average value may be a simple average or a weighted average in which weight is given to times closer to the current time. The proposal unit 102 may calculate the overall time difference using a formula other than the average value. For example, the proposal unit 102 proposes to the user a proposed charge timing that is the calculated time difference before the designated payment timing specified by the user for the reserved invoice.

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

[0060] [Settings section] The setting unit 103 sets the specified timing specified by the user when a suggested timing is proposed by the proposing unit 102. 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 well-known invoices. The setting unit 103 sets the specified timing specified by the user after the proposed timing is proposed by the proposing unit 102.

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

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

[0063] [Executive Department] The execution unit 104 executes processing related to the payment of the reserved invoice based on the specified timing designated by the user. The payment processing is processing directly or indirectly related to payment. In this embodiment, the payment processing is a concept that encompasses payment processing for payment and charge processing for charging the payment source 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 processing. In this embodiment, the phrase "payment processing" (i.e., processing executed by the execution unit 104) simply refers to both payment processing and charge processing. The payment processing may be processing other than payment processing and charge processing. For example, the payment processing may be processing that uses a payment method in combination with payment. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0083] 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). Upon receiving the request (S7), the payment service provider server 10 references the payment service database DB and acquires reservation history information associated with the user ID of the currently logged-in user (S8). The payment service provider server 10 proposes a proposed charge timing to the user based on the reservation history information (S9). In S9, the payment service provider server 10 calculates the time difference between the designated payment timing in the reserved invoice and the designated charge timing in the reserved invoice based on the reservation history information. The payment service provider server 10 determines the proposed charge timing to be the timing that precedes the designated payment timing specified by the user by the time difference. The payment service provider server 10 generates display data for a reservation screen SC3 showing the proposed proposed charge timing and transmits it to the user terminal 40. The reservation screen SC3 appears as shown in the upper right corner of FIG. 3.

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

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

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

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

[0088] [5. Summary of embodiments] The bill payment system 1 of this embodiment acquires reservation history information regarding the reservation history of reserved invoices for which a user has reserved payment. Based on the reservation history information, the bill payment system 1 proposes to the user a proposed timing for payment of the reserved invoice for which the user has reserved payment. When a proposed timing for payment is proposed, the bill payment system 1 sets the specified timing specified by the user. The bill payment system 1 executes processing for payment of the reserved invoice based on the specified timing specified by the user. This allows the user to understand what proposed timing to specify as the proposed timing for payment, thereby allowing the bill payment system 1 to improve user convenience. For example, the bill payment system 1 allows the user to specify the optimal specified timing for invoice payment, thereby increasing the likelihood that invoice payment will be completed accurately.

[0089] The bill payment system 1 also acquires reservation history information for reserved invoices that have not yet been paid. Based on the reservation history information for reserved invoices that have not yet been paid, the bill payment system 1 proposes payment timing to the user. Reserved invoices that have not yet been paid are reservations that are close in time and strongly reflect the user's recent trends, so the bill payment system 1 can make proposals that reflect the user's recent trends.

[0090] The bill payment system 1 also acquires reservation history information for reserved invoices that have already been paid. Based on the reservation history information for reserved invoices that have already been paid, the bill payment system 1 proposes payment timing to the user. While the reservation details of reserved invoices that have not yet been paid may be subject to change, reserved invoices that have already been paid reliably reflect the user's tendencies, so the bill payment system 1 can make proposals that reliably reflect the user's tendencies.

[0091] Furthermore, the bill payment system 1 proposes to the user, as a suggested timing for payment, a proposed charging timing for a charging means for charging a directly used payment means that is directly used to pay the reserved invoice, and a charging means that is indirectly used to pay the reserved invoice. This allows the user to check the trend of their own suggested charging timing on the reservation screen SC3 even if they are not aware of it, so the bill payment system 1 can improve user convenience. For example, by making a charging reservation at the suggested charging timing proposed on the reservation screen SC3, the user can make an appropriate charging reservation that suits their own tendency.

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

[0093] 7 is a diagram showing an example of functions realized in the modified example. For example, the payment service provider server 10 includes a reservation target information acquisition unit 105, a benefit granting unit 106, a notification unit 107, a reflection unit 108, and an expiration time information acquisition unit 109. Each of the reservation target information acquisition unit 105, the benefit granting unit 106, the notification unit 107, the reflection unit 108, and the expiration time information acquisition unit 109 is realized by the control unit 11.

[0094] [6-1. Variation 1] For example, the reservation details of an invoice specified by a user may have several characteristics. Hereinafter, such characteristics will be referred to as user characteristics. User characteristics are characteristics of the user's reservation details. User characteristics can also be considered classifications that indicate trends in the user's reservation details. In variant example 1, the user characteristic is taken as an example of a case where the user characteristic is a characteristic of the length of the period from the specified charge time to the specified payment time. Furthermore, take as an example a case where there are two user characteristics: the length of this period being less than a threshold, or the length of this period being equal to or greater than a threshold. Users are classified into one of these two user characteristics.

[0095] The number of user characteristics is not limited to two as in the first modification. The number of user characteristics may be two or more. The number of user characteristics may be three or more. For example, there may be three user characteristics, such as the length of the period from the designated charge time to the designated payment time being less than one day, less than one week, and one week or more. Furthermore, the user characteristics may be subdivided into four or more. Furthermore, the user characteristics are not limited to the length of the period from the designated charge time to the designated payment time. The user characteristics may be information that can classify the trends in the user's reservation content from some perspective. For example, the user characteristics may indicate whether each of the multiple designated charge times is concentrated or dispersed. The user characteristics may also indicate whether each of the multiple designated payment times is concentrated or dispersed. The user characteristics may also indicate the trend in the charge amount. For example, the user characteristics may indicate whether the amount of a single charge is equal to or greater than a threshold.

[0096] The suggestion unit 102 of the first modification estimates user characteristics related to the reservation of a reserved invoice based on the reservation history information, and proposes a proposed timing for payment to the user based on the user characteristics. The suggestion unit 102 identifies a user characteristic to which the user belongs from among multiple user characteristics based on the reservation history information. It is assumed that each user characteristic has predetermined conditions for the user to belong to that user characteristic. The suggestion unit 102 determines whether the conditions are satisfied based on the reservation history information, and estimates the user characteristics.

[0097] In the first modification, characteristic condition data indicating conditions for a user to belong to a certain user characteristic is assumed to be stored in advance in the data storage unit 100. The characteristic condition data may be in any format, for example, a table format, a mathematical formula format, part of a program, or a machine learning model. For example, the suggestion unit 102 estimates the user characteristics of a certain user based on the reservation history information of the user and the characteristic condition data. The suggestion unit 102 determines whether the reservation history information satisfies the conditions defined in the characteristic condition data. The suggestion unit 102 estimates the user characteristics associated with the conditions determined to be satisfied by the reservation history information as the user characteristics of the user.

[0098] In the first modification, since the user characteristics indicate the length of the period from the designated charge timing to the designated payment timing, the suggestion unit 102 calculates the length of the period from the designated charge timing to the designated payment timing previously designated by a certain user based on the reservation history information of the user. The method of calculating this length may be the same as in the embodiment. A threshold value for this period is set in the characteristic condition data. The suggestion unit 102 estimates the user characteristics by determining whether the length of this period is equal to or greater than the threshold value. Similarly, when the user characteristics indicate classification from other perspectives, the suggestion unit 102 may estimate the user characteristics based on the characteristic condition data.

[0099] In the first modification, characteristic timing data indicating the relationship between user characteristics and the proposed timing to be proposed to the user is assumed to be stored in advance in the data storage unit 100. The characteristic timing data may be in any format, for example, a table format, a mathematical formula format, part of a program, or a machine learning model. The suggestion unit 102 suggests a proposed timing for payment to the user based on the user characteristics estimated for the user and the characteristic timing data. The suggestion unit 102 makes a suggestion to the user based on the proposed timing associated with the user characteristics estimated for the user, among the user characteristics indicated in the characteristic timing data.

[0100] In the first modification, the user characteristic indicates the length of the period from the designated charge timing to the designated payment timing, and the characteristic timing data associates a first proposed timing (e.g., a timing a first time before the designated payment timing) with a user characteristic indicating that the length of this period is less than a threshold. The characteristic timing data associates a second proposed timing (e.g., a timing a second time before the designated payment timing that is longer than the first time) with a user characteristic indicating that the length of this period is equal to or greater than a threshold.

[0101] For example, when a user characteristic is estimated indicating that the length of the period from the designated charge time to the designated payment time is less than a threshold, the suggestion unit 102 makes a suggestion to the user based on the first suggested timing. If the first suggested timing is two days before the designated payment time, the suggestion unit 102 suggests the timing two days before the designated payment time specified by the user as the suggested charge time. The first suggested timing is not limited to two days before the designated payment time, and may be any timing. For example, the first suggested timing may be based on the bill payment deadline.

[0102] For example, when a user characteristic is estimated indicating that the length of the period from the designated charge timing to the designated payment timing is equal to or greater than a threshold, the suggestion unit 102 makes a suggestion to the user based on the second suggested timing. If the second suggested timing is one week before the designated payment timing, the suggestion unit 102 suggests one week before the designated payment timing specified by the user as the suggested charge timing. The second suggested timing is not limited to one week before the designated payment timing, and may be any timing. For example, the second suggested timing may be based on the bill payment deadline.

[0103] The bill payment system 1 of Variation 1 estimates user characteristics related to reservations for reserved invoices based on reservation history information, and then suggests suggested timing for payment to the user based on the user characteristics. This allows the user to understand the suggested timing according to their own user characteristics, so the bill payment system 1 can improve user convenience. For example, the user can make a reservation after understanding the suggested timing similar to that of other users with similar reservation tendencies.

[0104] [6-2. Variation 2] For example, some reserved invoices have payment details (e.g., payment amount, payee, or payment deadline) similar to the reserved invoice, while others have payment details dissimilar to the reserved invoice. For example, if the reserved invoice is an invoice for payment of a specific tax, it may be more appropriate to propose a proposed charge timing, etc. based on the reservation details of a reserved invoice for payment of a similar tax, rather than on a reserved invoice for a product purchased by the user on an e-commerce service. For this reason, the proposal unit 102 may make a proposal to the user taking into consideration not only reservation history information but also reservation target information related to the reserved invoice.

[0105] The bill payment system 1 of variant 2 includes a reservation target information acquisition unit 105. The reservation target information acquisition unit 105 acquires reservation target information related to the reserved invoice. The reservation target information is information indicating the payment details of the reserved invoice. Variation 2 takes as an example a case where the reservation target information indicates the payee of the reserved invoice. The reservation target information may be information that is somehow related to the payment details of the reserved invoice, and is not limited to the payee of the reserved invoice. For example, the reservation target information may indicate the payment target, payment deadline, or payment amount of the reserved invoice.

[0106] For example, the reservation target information acquisition unit 105 may acquire the reservation target information itself from the user terminal 40, or may acquire the reservation target information based on information acquired from the user terminal 40. In the second modification, since the reservation target information indicates the payee of the invoice, if the user terminal 40 can also acquire the payee of the invoice by reading the invoice code, the reservation target information acquisition unit 105 acquires the reservation target information itself from the user terminal 40. If the user terminal 40 can only acquire the invoice ID of the invoice by reading the invoice code, the reservation target information acquisition unit 105 may acquire the invoice ID from the user terminal 40 and query the receiving organization server 30 for reservation target information based on the invoice ID. The reservation target information acquisition unit 105 acquires the reservation target information associated with the invoice ID from the receiving organization server 30.

[0107] The suggestion unit 102 of the second modification example identifies a reserved invoice related to the reserved invoice from among multiple reserved invoices based on the reservation target information, and proposes a proposed timing for payment to the user based on the reservation history information of the identified reserved invoice. A reserved invoice related to the reserved invoice is a reserved invoice with the same or similar reservation content as the reserved invoice. Similar reservation content means that the difference in reservation content is within a specified range. For example, if the payees are technically different but are the same in the sense of being public institutions, this corresponds to similar reservation content. If the payment deadlines are different but the time difference is less than a threshold, this corresponds to similar reservation content. If the payment amounts are different but the monetary difference is less than a threshold, this corresponds to similar reservation content. Even if the reservation target information indicates other information, it is sufficient to determine whether the reservation content is similar based on the other information.

[0108] In variant example 2, the reservation target information indicates the payee of the reserved invoice, and the proposal unit 102 identifies, from among multiple reserved invoices, a reserved invoice with the same or similar payee as the reserved invoice based on the reservation target information. The payee of the reserved invoice is assumed to be indicated in the reservation history information. The proposal unit 102 identifies a reserved invoice with the same or similar payee as the reserved invoice based on the reservation history information of each of the multiple reserved invoices. The proposal unit 102 proposes a proposed timing for payment to the user based on the reservation history information of the reserved invoice. Although the proposal unit 102 identifies a reserved invoice to be used in the proposal, which differs from the embodiment, the processing for making a proposal based on the reservation history information is the same as in the embodiment.

[0109] In addition, if the reservation target information indicates information other than the payee of the reserved invoice, the proposal unit 102 may identify the reserved invoice according to the other information. For example, if the reservation target information indicates the payment deadline of the reserved invoice, the proposal unit 102 may identify, from among multiple reserved invoices, a reserved invoice with the same or similar payment deadline as the reserved invoice, based on the reservation target information. If the reservation target information indicates the payment amount of the reserved invoice, the proposal unit 102 may identify, from among multiple reserved invoices, a reserved invoice with the same or similar payment amount as the reserved invoice, based on the reservation target information. The proposal unit 102 may propose a proposed timing for payment to the user based on the reservation history information of the reserved invoice identified in this way.

[0110] The bill payment system 1 of Variation 2 identifies a reserved invoice related to the reserved invoice from among multiple reserved invoices based on the reservation target information, and proposes a suggested timing for payment to the user based on the reservation history information of the identified reserved invoice. This allows the user to understand the suggested timing according to the reserved invoice related to the reserved invoice that the user is about to reserve payment for, so the bill payment system 1 can effectively improve user convenience.

[0111] [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 timing before or after 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 106 (described later) 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.

[0112] The bill payment system 1 of the third modification further includes a reward granting unit 106. The reward granting unit 106 grants a reward to the user based on the proposed timing proposed by the proposal unit and the specified timing specified by the user. For example, the reward granting unit 106 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 106 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, but 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.

[0113] For example, the benefit granting unit 106 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.

[0114] For example, the reward granting unit 106 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 106 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 106 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.

[0115] For example, the reward granting unit 106 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 106 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 106 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.

[0116] The bill payment system 1 of Variation 3 grants a benefit to the user based on the suggested timing proposed to the user and the specified timing specified by the user. This allows the user to obtain a benefit, and the bill payment system 1 can motivate the user to specify the suggested timing proposed to the user or the specified timing corresponding to the suggested timing.

[0117] [6-4. Variation 4] For example, the user may be notified of the benefits described in Variation 3 at least at the time of making a reservation and / or after making a reservation. The bill payment system 1 of Variation 4 includes a notification unit 107. The notification unit 107 notifies the user of the benefits granted by the benefit granting unit 106. Notification of the benefits can also be referred to as notification of the benefits. The notification unit 107 may notify the user of the benefits visually or audibly. Variation 4 exemplified a method in which the notification unit 107 notifies the user of the benefits on the calendar on the reservation screen SC3. The notification unit 107 may also notify the user of the benefits on a screen other than the reservation screen SC3. The notification unit 107 may also notify the user of the benefits by voice.

[0118] FIG. 8 is a diagram showing an example of a reservation screen SC3 according to Modification 4. As shown in FIG. 8, the information unit 107 may display, on the reservation screen SC3, a benefit that will be granted to the user when the proposed timing for payment or a designated timing corresponding to the proposed timing is specified, along with the proposed timing for payment. Data indicating the benefit is stored in the data storage unit 100. The information unit 107 identifies the benefit that 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 information unit 107 notifies the user on the reservation screen SC3 that the benefit will be granted when the proposed charge timing proposed to the user or a designated charge timing earlier than the proposed charge timing is specified.

[0119] 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 notification unit 107 may notify the user of the benefit based on an image other than a speech bubble. The notification unit 107 may notify the user of the benefit by differentiating the display of dates on which the benefit is granted from dates on which the benefit is not granted (for example, by using different colors for these dates) among the dates shown on the calendar of the reservation screen SC3. The notification unit 107 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 notification unit 107 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 notification unit 107 may notify the user of the benefit using a method such as a pop-up, a window, or a modal.

[0120] The bill payment system 1 of Variation 4 informs the user of the benefits that will be granted to the user. This allows the user to understand what benefits will be granted to them, so the bill payment system 1 can increase user convenience. For example, when benefits are announced on the reservation screen SC3, the bill payment system 1 can motivate the user to specify the proposed timing suggested to the user or a specified timing corresponding to the proposed timing on the reservation screen SC3.

[0121] [6-5. Variation 5] For example, the payment schedule for a reservation made by the user may be reflected on a calendar within the payment app. In Variation 5, a calendar within the reservation screen SC3 will be described as an example of a calendar that reflects the payment schedule. The calendar that reflects the payment schedule may also be a calendar on a screen other than the reservation screen SC3. For example, the calendar that reflects the payment schedule may be a calendar within a screen that shows a list of reservations made by the user.

[0122] The bill payment system 1 of Variation 5 includes a reflecting unit 108. The reflecting unit 108 reflects the user's scheduled payment in a calendar related to the scheduled payment. For example, the reflecting unit 108 displays information about the user's scheduled payment on the calendar on or near the date indicated by the scheduled payment. The information about the scheduled payment may be any information that the user can visually recognize, and may be an image such as a speech bubble or icon, or a message indicating that a payment is scheduled. The scheduled payment may also be announced to the user by voice.

[0123] FIG. 9 is a diagram showing an example of a reservation screen SC3 according to Variation 5. For example, as shown on the left side of FIG. 9, the reflection unit 108 reflects the payment schedule on a calendar by displaying the designated payment timing of other invoices on the reservation screen SC3, which accepts the designation of the designated payment timing of a certain reserved invoice. The display data for the reservation screen SC3 is generated by the reflection unit 108. For example, the reflection unit 108 identifies the designated payment timing of the other invoice based on the other invoice information. The reflection unit 108 generates display data for the reservation screen SC3, which includes a calendar showing the designated payment timing of the other invoice.

[0124] In the example on the left side of FIG. 9, the reflection unit 108 generates display data for the 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 specification 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 by any method, and is not limited to the speech bubble shown on the left side of FIG. 9. The payment service provider server 10 may notify the user of the designated payment timing of the other invoice by an image other than a speech bubble or a message indicating the designated payment timing of the other invoice. For example, when the user selects button B30, as shown on the right side of FIG. 9, the reflection unit 108 reflects a speech bubble indicating the designated charge timing of the other invoice on the calendar that accepts the user's specification of the designated charge timing of the invoice to be reserved.

[0125] The bill payment system 1 of Variation 5 reflects the payment schedule on the user's calendar, allowing the user to keep track of the payment schedule on the calendar, thereby effectively improving user convenience.

[0126] [6-6. Variation 6] For example, the proposal unit 102 may propose to the user, as the proposed timing for payment, a proposed payment timing for a directly used payment method that will be directly used to pay the invoice to be reserved. In Variation 6, before the reservation screen SC3 (reservation screen SC3 at the bottom left of FIG. 2) that accepts the designation of the designated payment timing is displayed, the reservation screen SC3 (reservation screen SC3 at the top right of FIG. 3) that accepts the designation of the designated charge timing is displayed. In Variation 6, the reservation screen SC3 that accepts the designation of the designated charge timing does not propose a designated 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 designated 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.

[0127] FIG. 10 is a diagram showing an example of the reservation screen SC3 of Variation 6. For example, the proposal unit 102 proposes a proposed payment timing that is a timing corresponding to the reservation history information or a timing later than the designated charge timing specified by the user. As in the embodiment, the proposal unit 102 calculates the time difference between the designated payment timing for the reserved invoice and the designated charge timing for the reserved invoice based on the reservation history information. The proposal unit 102 proposes to the user a proposed payment timing that is the calculated time difference after the designated charge timing specified by the user for the invoice to be reserved. In the example of FIG. 10, the proposal unit 102 proposes to the user a proposed payment timing that is one week after the designated charge timing specified by the user.

[0128] The bill payment system 1 of Variation 6 proposes to the user the proposed payment timing for the directly used payment method that will be used directly to pay the reserved invoice. This allows the user to check the trend of their own designated payment timing on the reservation screen SC3 even if they are not aware of the trend, so the bill payment system 1 can improve user convenience.

[0129] [6-7. Variation 7] 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 7 allows the user to schedule reservations for multiple bills all at once. Variation 7 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.

[0130] FIG. 11 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. 11, for the user to select a method for reserving invoices. In Variation 7, two methods of reserving invoices are provided: one in which the user reserves a single invoice, and one 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.

[0131] 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. 11. 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 (e.g., invoice ID) read from each of the multiple invoices 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. 11.

[0132] 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 11 shows the details screen SC2 when the user scans two invoices with the photographing unit 46. The user may scan three or more invoices at once from the photographing screen SC1 at the top right of Figure 11. A maximum number may be set for the number of invoices that can be reserved at one time.

[0133] 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 7, 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.

[0134] 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. 11. In the example in the lower right of FIG. 11, 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 designated 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.

[0135] The suggestion unit 102 in Variation 7 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 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 designated charging timing for one invoice, but in Variation 7, it becomes a screen on which the user specifies the designated charging timing common to multiple invoices. In other words, in Variation 7, the reservation screen SC3 in the upper right of Figure 3 is a screen common to multiple invoices.

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

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

[0138] As in Variation 6, 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 6, the proposal unit 102 determines the proposed payment timing to be proposed to the user and displays a reservation screen SC3 similar to Variation 6 on the user terminal 40. In Variation 6, 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 7, it becomes a screen on which the user specifies the designated payment timing common to multiple invoices. In other words, in Variation 7, the reservation screen SC3 on which the proposed payment timing is proposed is a screen common to multiple invoices.

[0139] The setting unit 103 of the seventh modified example 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 with a single operation for multiple invoices) and stores them in the payment service database DB, thereby setting the designated charge timings designated by the user all at once.

[0140] As in variant example 6, 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.

[0141] The execution unit 104 in Modification 7 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 in the embodiment or Modification 6. 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.

[0142] The bill payment system 1 of variant 7 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.

[0143] The bill payment system 1 of Variation 7 may include the configuration of Variation 7 without including at least some of the features described in the embodiment (the feature of proposing payment timing based on reservation history information). That is, the bill payment system 1 may not include the reservation history 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 payment timing suggestions. 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 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.

[0144] [6-8. Variation 8] 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.

[0145] FIG. 12 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. 12. 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.

[0146] In the example in the upper left of FIG. 12, 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 7, 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 on the display unit 45 a reservation screen SC3, as shown in the upper right of FIG. 12, which accepts changes to the set payment timing for that invoice. The reservation screen SC3 in the upper right of FIG. 12 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.

[0147] In the eighth 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. 12, 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. 12. The reservation screen SC3 in the lower left of FIG. 12 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 display 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. 12.

[0148] The method for proposing the proposed timing for payment may be the same as in the embodiment or variant example 6. 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 proposal unit 102 proposes to the user, as the proposed timing for payment, a proposed charge timing that is an amount of time before the specified payment timing specified by the user according to the tendency of the reservation contents of the user's past reserved invoices, based on the reservation history information and the specified payment timing specified by the user. The process for identifying the proposed charge timing to be proposed by the proposal unit 102 may be the same as in the embodiment.

[0149] For example, as in Modification Example 6, when the proposed payment timing corresponds to a proposed timing for payment, the proposal unit 102, when the user changes the set payment timing, proposes to the user a proposed payment timing that is a time period after the designated charge timing specified by the user according to the trends in the reservation contents of the user's past reserved invoices, based on the reservation history information and the designated charge timing specified by the user, as the proposed timing for payment. The process for the proposal unit 102 to identify the proposed payment timing to be proposed may be the same as in Modification Example 6.

[0150] The setting unit 103 of variant 8 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 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.

[0151] 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 Variation 6, 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.

[0152] The bill payment system 1 of variant 8 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.

[0153] [6-9. Variation 9] For example, a user may be allowed to specify any payment method from among multiple payment methods as the payment source. If the payment source is a predetermined payment method, it may be necessary to propose a proposed timing for payment. Therefore, the proposal unit 102 may determine whether the user has specified a predetermined payment method as the payment source to be used directly or indirectly in paying the invoice to be reserved, and if it is determined that the user has specified a predetermined payment method as the payment source, the proposal unit 102 may propose a proposed timing for payment to the user.

[0154] The predetermined identification information that can identify the predetermined payment method is assumed to be stored in advance in the data storage unit 100. In the ninth variant, the predetermined payment method is a credit card as an example. 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, a cryptocurrency, or other payment method.

[0155] For example, the suggestion unit 102 determines whether the payment source designated by the user 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 Example 6.

[0156] For example, as in the embodiment, when the payment source is a charging method, the suggestion unit 102 determines whether the charging method designated by the user is a 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 a predetermined payment method, it does not suggest a suggested timing for payment, and if the suggestion unit 102 determines that the charging method is a predetermined payment method, it suggests a suggested timing for payment.

[0157] 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 designated by the user 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.

[0158] The bill payment system 1 of variant 9 determines whether the user has designated a predetermined payment method as the payment source. 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.

[0159] [6-10. Variation 10] 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.

[0160] The bill payment system 1 of variant 10 includes an expiration information acquisition unit 109. The expiration information acquisition unit 109 acquires expiration information regarding the expiration of the payment source that is used directly or indirectly in paying the reserved invoice. Variation 10 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 10 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 109 acquires the expiration information of the payment source from the payment service database DB.

[0161] 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 109 acquires the expiration time information of the payment source 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 109 acquires the expiration time information from the other computer or external information storage medium.

[0162] The suggestion unit 102 of the tenth modification proposes a proposed timing for payment to the user based on the reservation history information and the expiration time information. For example, when the payment source designated by the user 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 sixth 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.

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

[0164] The bill payment system 1 of the tenth modification proposes a proposed timing for payment to the user based on reservation history information and expiration time information. This allows the user to specify the designated timing for payment while taking into account the expiration time 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.

[0165] The bill payment system 1 of Variation 10 may include the configuration of Variation 10 without including at least some of the features described in the embodiment (the feature of proposing payment timing based on reservation history information). That is, the bill payment system 1 may not include the reservation history information acquisition unit 101. In this case, the bill payment system 1 may propose a proposed timing based on expiration information, rather than based specifically on reservation history 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 the present 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.

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

[0167] For example, when paying a bill, no special charge may be required. In this case, the user does not specify a designated charge timing. Furthermore, the payment source is a directly used payment method that is directly used to pay the bill. For example, if the user specifies a credit card as a directly used payment method, the suggestion unit 102 may suggest a suggested timing for payment to the user based on the reservation history information.

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

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

[0170] [7. Notes] For example, a bill payment system can be configured as follows: (1) a reservation history information acquisition unit that acquires reservation history information regarding the reservation history of reserved invoices for which a user has reserved payment; a proposal unit that proposes to the user, based on the reservation history information, a proposed timing for payment of the reservation target invoice that the user is reserving payment for; 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 payment of the reserved invoice based on the specified timing; Bill payment system including. (2) the reservation history information acquisition unit acquires the reservation history information of the reserved invoice that has not yet been paid, the proposal unit proposes the proposed timing to the user based on the reservation history information of the reserved invoice that has not yet been paid; (1) A bill payment system as described in (1). (3) the reservation history information acquisition unit acquires the reservation history information of the reserved invoice that has already been paid, the proposal unit proposes the proposed timing to the user based on the reservation history information of the reserved invoice that has already been paid; A bill payment system according to (1) or (2). (4) the suggestion unit estimates user characteristics related to the reservation of the reserved invoice based on the reservation history information, and suggests the suggestion timing to the user based on the user characteristics; A bill payment system according to any one of (1) to (3). (5) The bill payment system further includes a reservation target information acquisition unit that acquires reservation target information related to the reservation target invoice, the proposal unit identifies the reserved invoice related to the reserved invoice from among the plurality of reserved invoices based on the reservation target information, and proposes the proposal timing to the user based on the reservation history information of the identified reserved invoice; A bill payment system according to any one of (1) 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 bill payment system further includes a guide unit that guides the user about the benefit granted by the benefit granting unit. (6) A bill payment system as described in (6). (8) The bill payment system further includes a reflection unit that reflects the payment schedule in a calendar related to the user's payment schedule. A bill payment system according to any one of (1) to (7). (9) the proposal unit proposes to the user, as the proposed timing, a proposed charging timing for a charging means for charging a directly used payment means that is directly used in paying the invoice to be reserved, and the charging means that is indirectly used in paying the invoice to be reserved; A bill payment system according to any one of (1) to (8). (10) the proposal unit proposes to the user, as the proposed timing, a proposed payment timing for a directly used payment means to be directly used in paying the invoice to be reserved; A bill payment system according to any one of (1) to (9). (11) the proposal unit proposes to the user the proposed timing common to the plurality of invoices to be reserved, 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 reservation target invoices based on the specified timing common to the plurality of invoices. A bill payment system according to any one of (1) to (10). (12) the suggestion unit proposes the proposed timing to the user when the user changes the timing already set for the reservation target 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 (11). (13) the proposal unit determines whether the user has designated a predetermined payment method as the payment source to be used directly or indirectly in paying the invoice to be reserved, and if it is determined that the user has designated the predetermined payment method as the payment source, proposes the proposal timing to the user; A bill payment system according to any one of (1) to (12). (14) The bill payment system further includes an expiration information acquisition unit that acquires expiration information regarding the expiration of a payment source that is used directly or indirectly in paying the reserved bill, the suggestion unit suggests the suggested timing to the user based on the reservation history information and the expiration time information. A bill payment system according to any one of (1) to (13). [Explanation of symbols]

[0171] 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 reservation history information acquisition unit, 102 proposal unit, 103 setting unit, 104 execution unit, 105 reservation target information acquisition unit, 106 benefit granting unit, 107 guidance unit, 108 reflection unit, 109 expiration time information acquisition 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 buttons, F34 input form, SC0 selection screen, SC1 shooting screen, SC2 details screen, SC3 reservation screen, SC4 list screen.

Claims

1. a reservation history information acquisition unit that acquires reservation history information regarding the reservation history of reserved invoices for which a user has reserved payment; a proposal unit that proposes to the user, based on the reservation history information, a proposed timing for payment of the reservation target invoice that the user is reserving payment for; 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 payment of the reserved invoice based on the specified timing; Bill payment system including.

2. the reservation history information acquisition unit acquires the reservation history information of the reserved invoice that has not yet been paid, the proposal unit proposes the proposed timing to the user based on the reservation history information of the reserved invoice that has not yet been paid; 10. The bill payment system of claim 1.

3. the reservation history information acquisition unit acquires the reservation history information of the reserved invoice that has already been paid, the proposal unit proposes the proposed timing to the user based on the reservation history information of the reserved invoice that has already been paid; 3. A bill payment system according to claim 1 or 2.

4. the suggestion unit estimates user characteristics related to the reservation of the reserved invoice based on the reservation history information, and suggests the suggestion timing to the user based on the user characteristics; 3. A bill payment system according to claim 1 or 2.

5. The bill payment system further includes a reservation target information acquisition unit that acquires reservation target information related to the reservation target invoice, the proposal unit identifies the reserved invoice related to the reserved invoice from among the plurality of reserved invoices based on the reservation target information, and proposes the proposal timing to the user based on the reservation history information of the identified reserved invoice; 3. A bill payment system according to claim 1 or 2.

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.

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

7. The bill payment system further includes a guide unit that guides the user about the benefit granted by the benefit granting unit.

7. The bill payment system of claim 6.

8. The bill payment system further includes a reflection unit that reflects the payment schedule in a calendar related to the user's payment schedule.

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

9. the proposal unit proposes to the user, as the proposed timing, a proposed charging timing for a charging means for charging a directly used payment means that is directly used in paying the invoice to be reserved, and the charging means that is indirectly used in paying the invoice to be reserved; 3. A bill payment system according to claim 1 or 2.

10. the proposal unit proposes to the user, as the proposed timing, a proposed payment timing for a directly used payment means to be directly used in paying the invoice to be reserved; 3. A bill payment system according to claim 1 or 2.

11. the proposal unit proposes to the user the proposed timing common to the plurality of invoices to be reserved, 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 reservation target invoices based on the specified timing common to the plurality of invoices.

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

12. the suggestion unit proposes the proposed timing to the user when the user changes the timing already set for the reservation target invoice; The setting unit changes the set timing to the designated timing designated by the user.

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

13. the proposal unit determines whether the user has designated a predetermined payment method as the payment source to be used directly or indirectly in paying the invoice to be reserved, and if it is determined that the user has designated the predetermined payment method as the payment source, proposes the proposal timing to the user; 3. A bill payment system according to claim 1 or 2.

14. The bill payment system further includes an expiration information acquisition unit that acquires expiration information regarding the expiration of a payment source that is used directly or indirectly in paying the reserved bill, the suggestion unit suggests the suggested timing to the user based on the reservation history information and the expiration time information.

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

15. A reservation history information acquisition step of acquiring reservation history information regarding the reservation history of reserved invoices for which the user has reserved payment; a proposing step of proposing to the user a proposed timing for payment of a reservation target invoice for which the user reserves payment based on the reservation history 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 payment of the reserved invoice based on the specified timing; Bill payment methods including.

16. a reservation history information acquisition unit that acquires reservation history information regarding the reservation history of reserved invoices for which the user has reserved payment; a proposal unit that proposes to the user, based on the reservation history information, a proposed timing for payment of the reservation target invoice for which the user reserves payment; 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 payment of the reserved invoice based on the specified timing; A program that allows a computer to function as a

Images