Bill payment system, bill payment method, and program

Abstract

To improve user convenience.SOLUTION: In a bill payment system (1) disclosed herein, a failure cause information acquisition unit (103) acquires failure cause information related to a cause of payment failure when a user experiences bill payment failure, and a notification unit (104) generates, to the user, a payment failure notification regarding a cause of the payment failure based on the failure cause information.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, if the user does not have enough electronic money on the scheduled payment date and time, the payment will fail. If the payment fails, the user must make another reservation or pay a late fee. It is possible to notify the user of a failed payment, but simply notifying the user will only let them know that the payment has failed, which does not sufficiently improve user convenience.

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

[0006] The bill payment system according to the present disclosure includes a failure cause information acquisition unit that acquires failure cause information regarding the cause of a payment failure when a user's bill payment fails, and a notification unit that sends a payment failure notification to the user regarding the cause of the payment failure based on the failure cause information. [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. 10 is a diagram showing an example of a payment failure notice according to the first modification. [Figure 9] FIG. 13 is a diagram showing an example of a payment failure notice in Modification 3. [Figure 10] FIG. 13 is a diagram showing an example of a payment failure notice in Modification 4. [Figure 11] FIG. 13 is a diagram showing an example of a payment failure notice in Modification 5. [Figure 12] FIG. 20 is a diagram showing an example of a notification in Modification 7. 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 the user terminal 40. For example, when a user launches a payment app, the user terminal 40 displays a top screen SC1, which corresponds to the first view of the payment app, on the display unit 45. The payment app allows the user to perform various operations to use a payment service. In this embodiment, an operation for a user to use a bill payment service, which is one of the payment services, is described. For example, when a user selects a button B10 for using the bill payment service in the payment app, the user terminal 40 launches the image capture unit 46. As shown in the upper right corner of FIG. 2, the user terminal 40 displays a capture screen SC2, which shows a captured image generated by the image capture unit 46, on the display unit 45. The user terminal 40 reads the code of the bill shown in the captured 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 may display a reservation screen SC3 showing the details of the invoice on the display unit 45 based on this information, as shown in the lower left of Figure 2.

[0023] In this embodiment, an example is taken of a case where a user pays a bill using online electronic money. For example, the user's electronic money balance is displayed on the user terminal 40. The user can make an immediate payment by selecting button B30. The process in this case may be similar to the process employed in known bill payment services. The user can schedule a payment by selecting button B31 instead of making an immediate payment.

[0024] For example, when a user selects button B31, the user terminal 40 executes a reservation process with the payment service provider server 10, allowing the user to reserve payment of an invoice. The reservation process may be similar to known processes. For example, the user specifies the payment timing. 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.

[0025] For example, when a user makes a payment using electronic money, if the balance of the electronic money is insufficient at the time of payment, the payment will result in an error. For this reason, the user needs to manage the balance of the electronic money so that the balance does not run out. In this embodiment, the user can perform operations to charge the electronic money from the reservation screen SC3. Furthermore, the user can reserve a charge of the electronic money. The charge reserved by the user is carried out automatically, so it is a type of auto-charge.

[0026] For example, the user can specify the charge amount, the charge method, which is the payment method used to fund the charge, and the charge timing from the reservation screen SC3. The charge timing is the timing at which the charge is performed. In this embodiment, an example is given in which the charge timing is expressed only by the 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.

[0027] For example, when the user completes all reservation operations, the user terminal 40 displays on the reservation screen SC3 that the payment reservation and charge reservation have been completed, as shown in the lower right of Fig. 2. When the payment reservation and charge reservation are completed, the charge is executed at the charge timing specified by the user, and the payment is executed at the payment timing specified by the user. In the example in the lower right of Fig. 2, the charge is executed some time before the payment timing.

[0028] For example, bill payments can fail for a variety of reasons. Payments can fail due to insufficient electronic money balance, insufficient points balance, suspension of credit card use, errors in the payment service provider server 10, errors in the card company server 20, errors in the collection organization server 30, communication failures, or other reasons. Payments can fail for a variety of reasons not only when a user schedules a payment, but also when a user selects button B30 to make an immediate payment. In this embodiment, if bill payment fails, the user is notified according to the cause of the payment failure. Hereinafter, this notification will be referred to as a payment failure notification.

[0029] For example, when a user selects icon I11 on the top screen SC1 and selects a payment failure notification, the user terminal 40 displays a notification screen SC4 indicating the contents of the payment failure notification on the display unit 45, as shown in the upper left of FIG. 3. In this embodiment, the payment failure notification is displayed on the notification screen SC4 by the notification function of the payment app. In the example in the upper left of FIG. 3, the payment failure notification indicates that the payment failed because the user's electronic money balance was insufficient. The reason indicated in the payment failure notification varies depending on the cause of the payment failure. For example, if the cause is an insufficient points balance, the payment failure notification indicates that cause. If the cause is a suspended credit card, the payment failure notification indicates that cause. Similarly, for other causes, the payment failure notification indicates that other cause.

[0030] In this embodiment, the payment failure notification can accept operations related to bill payment. In the example at the top left of FIG. 3, the payment failure notification includes a button B40 that allows the user to change the reservation details. Button B40 includes a link to the bill payment service. The user checks the payment failure notification and determines whether or not the reservation details need to be changed. When the user checks the payment failure notification, the reserved payment has failed, so the user can determine whether or not a new reservation is necessary. In the example at the top left of FIG. 3, the user used electronic money after auto-charging, resulting in a shortage of electronic money balance, causing the payment to fail. For example, the user changes the payment timing to just before the payment deadline, allowing time for electronic money charging. That is, the user books another payment so that it occurs just before the payment deadline.

[0031] For example, when a user selects button B40, the user terminal 40 displays a list screen SC5 showing a list of reservations made by the user on the display unit 45, as shown in the upper right corner of FIG. 3. The user selects button B50 to change the reservation details indicated in the payment failure notification. Changes to the reservation details may be made from a screen similar to the reservation screen SC3. Button B50 may include information indicating that the payment failed. The user can change any item in the reservation details. For example, the user can change the payment timing to just before the payment deadline. The user can also change the reservation details so that payment is made by a payment method other than electronic money. The user terminal 40 may display the reservation screen SC3 instead of the list screen SC5, and have the user make a new reservation for the failed payment.

[0032] As described above, in the bill payment system 1 of this embodiment, if a payment fails, a payment failure notification is sent to the user on the payment app. The payment failure notification allows the user to understand not only the fact that the payment failed, but also the cause of the failure. This allows the user to take action according to the cause of the payment failure after checking the payment failure notification. In the example in the upper left of Figure 3, the user selects the payment failure notification button B40 to change the reservation details and prevent the payment from failing again for the same reason. In this way, the bill payment system 1 can improve user convenience. The bill payment system 1 will be described in detail below.

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

[0034] [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 acceptance unit 101, a payment execution unit 102, a failure cause information acquisition unit 103, and a notification unit 104. The data storage unit 100 is realized by the memory unit 12. The reservation acceptance unit 101, the payment execution unit 102, the failure cause information acquisition unit 103, and the notification unit 104 are each realized by the control unit 11.

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

[0036] 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, notification destination information, notification information, payment method information, payment history information, charge method information, reservation history information, and payment result 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 to make payments using codes displayed on the payment app, and charge history information related to the history of past charge attempts.

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

[0038] The notification destination information is information relating to the notification destination. The notification destination is the destination to which the notification is sent. The notification destination can also be referred to as the destination of the notification. The notification destination information may be information according to the notification means used by the notification unit 104 described below. The notification means is the means used for notification. The notification means can also be referred to as notification media or contact means. The notification means may be a notification function on an application such as a payment app, email, SMS, a messaging app, SNS, push notification, banner notification, pop-up, window, modal, or other means. Notification may be performed by combining multiple notification means.

[0039] In this embodiment, the notification function of the payment app is used as the notification means, so the notification destination information does not need to be stored in the payment service database DB. If email is used as the notification means, the notification destination information indicates the user's email address. For example, if SMS is used as the notification means, the notification destination information indicates the user's phone number. If a message app is used as the notification means, the notification destination information indicates an account in the message app. If an SNS is used as the notification means, the notification destination information indicates an account in the SNS. Similarly, if another means is used as the notification means, the notification destination information only needs to be information that can identify the user in some way when that other means is used.

[0040] Notification information is information related to a notification to a user. The notification information indicates the content of the notification. For example, the notification information may include a character string, an image such as a button or icon, a link, unread / read information, the importance of the notification, the time the notification was made, or other information. In this embodiment, a case where the notification function of a payment app is used is taken as an example, so when the payment app needs to notify the user of something, the payment business operator server 10 generates notification information indicating the content of the notification. The payment business operator server 10 associates the notification information with the user ID of the user and stores it in the payment service database DB.

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

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

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

[0044] A directly used payment source is a payment method through which payment is made. In other words, a directly used payment source is a payment method that serves as the source of funds at the time of payment. In this embodiment, electronic money is described as an example of a directly used payment source. Therefore, any description of electronic money used for payment can be read as a directly used payment source. A directly used payment source may be a credit card, points, cryptocurrency, debit card, wallet, account such as a bank account, sales proceeds from an online flea market service, or other means. In this embodiment, an example is given in which a directly used payment source is a rechargeable payment method, but a directly used payment source does not have to be rechargeable.

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

[0046] Reservation history information is information related 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 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 conditions such as the 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. Reservation history information may also include information on invoice details such as at least one of the payee, payment amount, and payment deadline.

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

[0048] The payment result information is information about the result of the payment. The payment result information can also be referred to as information about the processing results of the payment execution unit 102, which will be described later. For example, the payment result information includes the success or failure of the payment, the reason for the payment failure, the date and time of the payment execution, or other information. In this embodiment, failure cause codes that can identify the cause of the payment failure are predefined. For example, a failure cause code of 1 means that the payment failed due to an insufficient balance of electronic money. A failure cause code of 2 means that the payment failed due to an insufficient balance of points. Similarly, failure cause codes corresponding to other causes are prepared for other causes. Data indicating which failure cause code means which cause is assumed to be pre-stored in the data storage unit 100. The payment execution unit 102, which will be described later, generates payment result information based on the result of the payment execution and stores it in the payment service database DB.

[0049] The data stored in the data storage unit 100 is not limited to the above example. 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 the payment app. The data storage unit 100 may store template data indicating a template for a notification made by the notification unit 104 (described below). For example, when a notification is made on the payment app, the data storage unit 100 displays a default message for the notification on the payment app. When email is used for the notification, the data storage unit 100 stores template data indicating an email template. When another notification means is used, the data storage unit 100 may store template data indicating a template for the other notification means.

[0050] [Reservations Department] The reservation reception unit 101 accepts reservations for bill payments. For example, the reservation reception unit 101 accepts reservations by obtaining reservation content information regarding the reservation content of bill payments from the user terminal 40. The reservation content information indicates at least one of a payment reservation and a charge reservation. The items included in the reservation content information may be the same as the reservation history information. For example, the reservation content information indicates the bill ID, payment timing, information on the directly used payment method, charge timing, information on the charge method, charge conditions, or a combination of these. The items included in the reservation content information may be the same as the reservation history information.

[0051] The reservation reception unit 101 is only required to receive a reservation for payment of at least one invoice, and may also receive reservations for payment of each of a plurality of invoices. The user terminal 40 generates reservation content information regarding the reservation content entered by the user on the reservation screen SC3, and transmits the reservation content information to the payment business operator server 10. The user terminal 40 also transmits the user's user ID to the payment business operator server 10. For example, when the reservation reception unit 101 receives a reservation, it associates the reservation content information received from the user terminal 40 with the user ID and stores it in the payment service database DB as reservation history information.

[0052] [Payment Execution Department] The payment execution unit 102 executes payment processing. The payment processing is a payment based on a directly used payment means that is directly used for payment. In this embodiment, since electronic money is used as the directly used payment means, the payment processing is a process of reducing the balance of electronic money. If the directly used payment means is another payment means, the payment processing may be a payment processing based on the other payment means. For example, if the directly used payment means is a credit card, the payment processing is a payment processing based on the credit card. If the directly used payment means is an account such as a bank account, the payment processing is a process of debiting the account. If the directly used payment means is another payment means, the payment processing may be a payment processing based on the other payment means. Note that payment processing may also be performed using multiple directly used payment means.

[0053] The payment execution unit 102 may refer to the reservation history information in the payment service database DB to determine the timing of payment. The payment execution unit 102 may refer to the reservation history information in the payment service database DB to determine the timing of payment. The payment execution unit 102 may refer to the reservation history information, etc. in the payment service database DB to execute the payment process. The payment execution unit 102 may execute not only payments reserved by the user, but also payments instructed by the user when they read the invoice. The only difference is when the payment is executed, and the processing for payment is the same.

[0054] In this embodiment, if a payment fails, the payment execution unit 102 stores payment result information including failure cause information indicating the cause in the payment service database DB. For example, if the electronic money balance is less than the payment amount, the payment execution unit 102 determines that the payment has failed, generates payment result information including payment cause information indicating that the cause was an insufficient balance (for example, 1, meaning that the electronic money balance is insufficient), and stores the payment result information in the payment service database DB. If the points balance is less than the payment amount, the payment execution unit 102 determines that the payment has failed, generates payment result information including payment cause information indicating that the cause was an insufficient balance (for example, 2, meaning that the points balance is insufficient), and stores the payment result information in the payment service database DB.

[0055] For example, suppose the directly used payment method is a credit card, and the payment execution unit 102 requests the card company server 20 to make a credit card payment and receives a notification from the card company server 20 that the credit card has been suspended. In this case, the payment execution unit 102 generates payment result information including payment cause information indicating that the suspension of the credit card is the cause (for example, 3, meaning that the credit card has been suspended), and stores the payment result information in the payment service database DB. If an error occurs within the payment service provider server 10 during payment, the payment execution unit 102 determines that the payment has failed, generates payment result information including payment cause information indicating that the error in the payment service provider server 10 is the cause (for example, 4, meaning that the error in the payment service provider server 10 is the cause), and stores the payment result information in the payment service database DB.

[0056] In addition, if the payment fails for another reason, the payment execution unit 102 may similarly generate payment result information including payment cause information indicating the other reason and store the payment result information in the payment service database DB. The payment execution unit 102 may also obtain other information from the payment result information other than the payment cause information using a known method. The payment cause information may be separate data from the payment result information. In this case, the payment execution unit 102 may generate payment cause information and store it in the payment service database DB as separate data from the payment result information.

[0057] [Failure cause information acquisition part] When a user's payment of a bill fails, the failure cause information acquisition unit 103 acquires failure cause information regarding the cause of the payment failure. In this embodiment, the failure cause information is stored in the payment service database DB, so the failure cause information acquisition unit 103 acquires the failure cause information from the payment service database DB. In this embodiment, the failure cause information is included in the payment result information, so the failure cause information acquisition unit 103 acquires the failure cause information included in the payment result information stored in the payment service database DB.

[0058] Note that if the failure cause information is separate data from the payment result information (i.e., if the failure cause information is not included in the payment result information), the failure cause information is stored separately from the payment result information in the payment service database DB. The failure cause information acquisition unit 103 simply acquires the failure cause information stored separately from the payment result information from the payment service database DB. The failure cause information may be stored in a database other than the payment service database DB. In this case, the failure cause information acquisition unit 103 acquires the failure cause information from the other database. The failure cause information may be stored in a computer other than the payment operator server 10 or in an external information storage medium. In this case, the failure cause information acquisition unit 103 acquires the failure cause information from the other computer or external information storage medium.

[0059] [Notification Department] The notification unit 104 issues a payment failure notification to the user regarding the cause of the payment failure based on the failure cause information. The payment failure notification is a notification indicating the cause of the payment failure. The cause of the payment failure is indicated by a character string or an image. The cause of the payment failure is not limited to a form understandable to the user in natural language, but may also be indicated by a failure cause code. Data necessary for the payment failure notification is stored in the data storage unit 100. The data may be a character string in natural language indicating the cause of the payment failure or an image indicating the cause of the payment failure. The notification unit 104 issues a payment failure notification to the user based on the data. In this embodiment, an example is given in which the notification unit 104 issues a payment failure notification to the user after the payment timing arrives and the payment fails. However, the notification unit 104 may also issue a notification other than a payment failure notification. For example, the notification unit 104 may issue another notification to the user before a reservation is made. As in Variation 7 described below, when the payment timing is predicted based on the reservation history or the like, the notification unit 104 may issue another notification based on the predicted payment timing.

[0060] In this embodiment, the notification unit 104 can notify the user of the payment failure at any timing after the payment has failed. For example, the notification unit 104 may notify the user of the payment failure immediately after the payment has failed, or may notify the user of the payment failure after a certain amount of time has passed since the payment has failed. The notification unit 104 may notify the user based on notification destination information stored in the payment service database DB.

[0061] In this embodiment, the notification unit 104 determines whether the payment is successful or not based on the processing result of the payment execution unit 102. For example, the notification unit 104 determines whether the payment is successful or not based on the success or failure of the payment indicated by the payment result information stored in the payment service database DB. The notification unit 104 determines that the payment is successful if the payment result information indicates success of the payment, and determines that the payment is unsuccessful if the payment result information indicates failure of the payment. The method for determining whether the payment is successful or not may be a known method. For example, the notification unit 104 may determine whether the payment is successful or not based on the results of communication with the card company server 20 and the receiving organization server 30.

[0062] In this embodiment, the notification function of the payment app is used, so when a payment fails, the notification unit 104 inserts information about the payment to be notified into the template indicated by the template data based on the payment result information stored in the payment service database DB. In the example in the upper left of FIG. 3, the notification unit 104 inserts information such as the payee and payment amount into the template. For example, the template indicates a standard phrase at the beginning of the notification shown on the notification screen SC4 in the upper left of FIG. 3 (e.g., a sentence such as "The following payment failed..."). The notification unit 104 inserts information such as the payee and payment amount after the standard phrase.

[0063] For example, the notification unit 104 generates a link to the list screen SC5 and inserts a button B40 including the link into the template. Data related to the link of the list screen SC5 is assumed to be stored in advance in the data storage unit 100. The notification unit 104 may identify the link to be embedded in the button B40 based on the data. The notification unit 104 may insert information such as an argument specific to the user into the link indicated by the data, and then generate the link to be embedded in the button B40. The notification unit 104 generates notification information indicating the payment failure notification generated as described above, associates the notification information with the user ID of the user to whom the payment failure notification is sent, and stores the notification information in the payment service database DB.

[0064] The method by which the notification unit 104 notifies the user of the payment failure is not limited to the above example. The notification unit 104 may notify the user of the payment failure in a manner appropriate to the notification means. For example, the payment failure notification on the payment app is not limited to the notification displayed on the notification screen SC4 when the user selects the icon I11 on the top screen SC1. The payment failure notification on the payment app may also be a pop-up or banner notification. For example, if email is used for the payment failure notification, the notification unit 104 may send an email as a payment failure notification to the user's email address indicated in the notification destination information. The notification unit 104 may generate the email in the same manner as the notification on the payment app. For example, the notification unit 104 may send an email to the user's email address containing details of the payment that is the subject of the payment failure notification and a link to the list screen SC5.

[0065] For example, if SMS is used for the payment failure notification, the notification unit 104 may send an SMS message as a payment failure notification to the user's telephone number indicated by the notification destination information. The notification unit 104 may generate the SMS message in the same manner as an email. For example, the notification unit 104 may send an SMS message to the user's telephone number that includes the reservation details of the reservation for which the payment failure notification is sent and a link to the list screen SC5.

[0066] For example, when a message app is used for the payment failure notification, the notification unit 104 may send a message of the message app as a payment failure notification to the user's account indicated by the notification destination information. The notification unit 104 may generate a message of the message app in the same manner as an email. For example, the notification unit 104 may send a message of the message app to the user's account that includes the reservation details of the reservation that is the subject of the payment failure notification and a link to the list screen SC5. Similarly, when another notification means is used, the notification unit 104 may notify the user of the payment failure in a manner appropriate to the other notification means.

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

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

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

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

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

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

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

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

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

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

[0077] [4. Processes performed by the bill payment system] Figure 6 is a diagram showing an example of the processing executed by the bill payment system 1. Figure 6 shows the processing for notifying a payment failure, which is one of the processing executed by the bill payment system 1. The processing of Figure 6 is executed by the control units 11 and 41 executing programs stored in the memory units 12 and 42, respectively.

[0078] As shown in Figure 6, the payment service provider server 10 executes processing to accept a reservation for bill payment with the user terminal 40 (S1). In S1, the processing flow described with reference to Figure 2 is executed. The user terminal 40 transmits reservation content information regarding the reservation content entered by the user on the reservation screen SC3 to the payment service provider server 10. The payment service provider server 10 associates the reservation content information received from the user terminal 40 with the user's user ID and stores it as reservation history information in the payment service database DB.

[0079] The payment service provider server 10 determines whether the payment timing specified by the user has arrived based on the payment service database DB, and if it determines that the payment timing has arrived, executes payment processing for the invoice read by the user between at least one of the card company server 20 and the receiving organization server 30 (S2). In S2, the payment service provider server 10 executes payment of the invoice based on the directly used payment method. 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. If the payment fails, this series of processes is not executed.

[0080] In the processing of S2, the payment business operator server 10 stores payment result information in the payment service database DB based on the execution result of the payment processing. If the payment is successful, the payment business operator server 10 stores payment result information indicating the success of the payment in the payment service database DB. If the payment fails, the payment business operator server 10 stores payment result information indicating the payment failure and the cause of the payment failure in the payment service database DB. The method for generating payment result information is as described above. The payment business operator server 10 determines whether the payment has failed based on the payment result information stored in the payment service database DB (S3). If it is determined in S3 that the payment has succeeded (S3:N), this processing ends. In this case, a payment failure notification is not sent.

[0081] If it is determined in S3 that the payment has failed (S3: Y), the payment service provider server 10 acquires information about the cause of failure based on the payment service database DB (S4). The payment service provider server 10 notifies the user of the payment failure based on the information about the cause of failure (S5). When the user launches the payment app, selects icon I11, and selects a payment failure notification from a list of notifications, the user terminal 40 displays a notification screen SC4 on the display unit 45 (S6). When the user selects button B40, the user terminal 40 sends a request to the payment service provider server 10 to access the list screen SC5 based on the link embedded in button B40 (S7).

[0082] When the payment processor server 10 receives an access request from the user terminal 40 (S8), it generates display data for the list screen SC5 based on the payment service database DB (S9). For example, assume that the link of button B40 includes the invoice ID of the payment that is the subject of the payment failure notification. The access request includes the invoice ID. In S9, the payment processor server 10 obtains reservation history information, including the invoice ID included in the access request, from the payment service database DB. The payment processor server 10 generates display data for the list screen SC5 based on the reservation history information. Note that individual reservations may be identified by information other than the invoice ID. For example, if a reservation ID, which is an ID for each individual reservation, is issued, the reservation whose reservation details are displayed on the list screen SC5 may be identified by the reservation ID.

[0083] The payment provider server 10 transmits display data for the list screen SC5 to the user terminal 40 (S10). The series of processes from S8 to S10 is an example of screen transition processing. The user terminal 40 receives display data for the list screen SC5 from the payment provider server 10 (S11) and displays the list screen SC5 on the display unit 45 (S12). The user terminal 40 executes processing with the payment provider server 10 to allow the user to change the reservation details (S13), and this processing ends. In S13, the user terminal 40 transmits data indicating the changes entered by the user to the payment provider server 10. The payment provider server 10 updates the reservation history information stored in the payment service database DB based on the data.

[0084] [5. Summary of embodiments] In this embodiment, the bill payment system 1 acquires failure cause information when a user's bill payment fails. Based on the failure cause information, the bill payment system 1 sends the user a payment failure notification regarding the cause of the payment failure. This allows the user to take appropriate action based on the payment failure notification after confirming the payment failure, thereby improving user convenience. For example, if the payment failure is due to insufficient electronic money balance, the user can charge electronic money and then schedule a second payment, or make the payment immediately. If the payment failure is due to insufficient points balance, the user can change the payment method to be used directly to another payment method other than points, and then schedule a second payment, or make the payment immediately.

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

[0086] 7 is a diagram showing an example of functions realized in the modified example. For example, the payment service provider server 10 includes a screen transition unit 105, a payment deadline information acquisition unit 106, a reservation history information acquisition unit 107, a prediction unit 108, a payment source information acquisition unit 109, and a future payment information acquisition unit 110. Each of the screen transition unit 105, the payment deadline information acquisition unit 106, the reservation history information acquisition unit 107, the prediction unit 108, the payment source information acquisition unit 109, and the future payment information acquisition unit 110 is realized by the control unit 11.

[0087] [6-1. Variation 1] For example, the notification unit 104 may send the user a payment failure notification that includes content according to the cause of the payment failure and that can accept a payment-related operation. The content is an element (part) included in the payment failure notification. For example, the content is a button, an icon, an image other than a button or an icon, text, or other part. The payment-related operation may be any operation related to paying a bill. For example, the payment-related operation may be an operation to change the reservation details, an operation to make a new reservation, an operation to cancel a reservation, an operation to charge a directly used payment means, an operation to transition to a screen for a bill payment service, or another operation.

[0088] Content that can accept operations related to payment is content that corresponds to a part of a user interface for accepting such operations. The parts included in the notification may be publicly known parts. The parts may also include a link to the screen to which the user transitions. In the example at the top left of FIG. 3, the notification that includes button B40 with an embedded link to list screen SC5 corresponds to a notification that can accept operations related to payment. The operation for transitioning to list screen SC5 to change the reservation details for payment corresponds to an operation related to payment.

[0089] The data storage unit 100 of the first modification stores content data indicating the relationship between the failure cause information and the content included in the payment failure notice. The content data may be in any format, such as a table, a mathematical formula, part of a program, a machine learning model, or another format. The notification unit 104 identifies content associated with the failure cause information based on the content data and sends the user a payment failure notice including the identified content. The actual data of the content is also assumed to be stored in the data storage unit 100. The actual data of the content may be included in template data indicating a template for the failure cause notice.

[0090] For example, the notification unit 104 may send a payment failure notification to the user based on the content data, the payment failure notification including content corresponding to the cause indicated by the failure cause information. For example, if the failure cause information indicates a first cause, the notification unit 104 sends a payment failure notification to the user including first content corresponding to the first cause. If the failure cause information indicates a second cause, the notification unit 104 sends a payment failure notification to the user including second content corresponding to the second cause. The second cause is different from the first cause. The second content is different from the first content. The second content may be visually identical to the first content, but may have an internally embedded link that is different from that of the first content.

[0091] FIG. 8 is a diagram showing an example of a payment failure notification of Variation 1. In FIG. 8, the content included in the payment failure notification displayed on notification screen SC4 when the user selects icon I11 is shown for each cause of the payment failure. The notification screen SC4 in the upper right of FIG. 8 shows a payment failure notification for a payment that failed due to insufficient balance. The notification screen SC4 in the lower left of FIG. 8 shows a payment failure notification for a payment that failed due to a system error by the payment service provider server 10 or the like. The notification screen SC4 in the lower right of FIG. 8 shows a payment failure notification for a payment that failed due to the deadline having passed.

[0092] For example, suppose the content data includes failure cause information indicating insufficient balance and content for top-up. If the failure cause information indicates insufficient balance, the notification unit 104 sends the user a payment failure notification including a top-up button B41 as content corresponding to the insufficient balance, as shown in the upper right of FIG. 8. When the user selects button B41, the payment service provider server 10 displays on the user terminal 40 a top-up screen for top-up of the directly used payment method used directly in the payment. A link to the top-up screen is embedded in button B41. When the user performs a top-up operation on the top-up screen, the payment service provider server 10 performs top-up of electronic money. Top-up of electronic money may be performed using a known process. It is assumed that the data necessary to display the top-up screen is stored in the data storage unit 100.

[0093] If the failure cause information indicates insufficient balance, the notification unit 104 may provide the user with a payment failure notification including content for charging without transitioning from the notification screen SC4, rather than a button B41 with an embedded link to a charge screen. For example, the notification unit 104 may provide the user with a payment failure notification including an input form for accepting input of conditions such as the charge amount, as content corresponding to the insufficient balance. The user terminal 40 transmits a charge execution request to the payment service provider server 10, including the conditions entered in the input form for the payment failure notification. The payment service provider server 10 executes the charge process based on the charge execution request.

[0094] For example, assume that the content data includes failure cause information indicating a system error by the payment service provider server 10 or the like and content for rescheduling. When the failure cause information indicates a system error, the notification unit 104 sends a payment failure notification to the user, including a button B42 for rescheduling as content corresponding to the system error, as shown in the lower left of FIG. 8 . The button B42 may be a button for the user to make an immediate payment. When the user selects the button B42, the payment service provider server 10 displays a reservation screen SC3 for rescheduling on the user terminal 40. A link to the reservation screen SC3 is embedded in the button B42. When the user performs an operation to reschedule on the reservation screen SC3, the reservation acceptance unit 101 accepts the rescheduling. The processing executed when rescheduling may be similar to the processing executed by the reservation acceptance unit 101 described in the embodiment. Instead of making a new reservation, the details of the reservation that failed due to the system error may be changed. Therefore, the notification unit 104 may send a payment failure notification including a button B42 for changing the details of the failed reservation. Even if the payment failed due to a system error, the reservation operation may be accepted again without changing the screen, just like with charging. In this case, the notification screen SC4 may suggest an appropriate payment timing within the payment deadline.

[0095] For example, suppose the content data includes failure cause information indicating that the payment deadline specified by the user has passed, and content with an embedded link to a solution screen showing how to deal with the missed deadline. A missed payment deadline occurs when the payment timing is later than the payment deadline. A missed payment deadline also occurs when the payment deadline has passed at the time the user scans the invoice with the image capture unit 46. If the failure cause information indicates a missed deadline, the notification unit 104 sends the user a payment failure notification, including a button B43 with an embedded link to the solution screen, as content corresponding to the missed deadline, as shown in the lower right of FIG. 8. When the user selects button B43, the payment service provider server 10 displays a solution screen on the user terminal 40 showing how to deal with the missed deadline. The user reviews the solution screen and considers future actions. The data required to display the solution screen is stored in the data storage unit 100. The solution screen may correspond to a help page.

[0096] Note that the content corresponding to the cause of payment failure is not limited to the example in FIG. 8. The notification unit 104 may send the user a payment failure notification including content corresponding to the cause indicated by the failure cause information. For example, even if the error is a system error, the notification unit 104 may send the user a payment failure notification including different content for each of an error in the payment service provider server 10, an error in the card company server 20, and an error in the receiving organization server 30. If the failure cause information indicates a credit card error, the notification unit 104 may send a payment failure notification including a button with an embedded link to the card company's help page. In these cases, too, the relationship between the failure cause information and the content to be included in the payment failure notification is assumed to be indicated in the content data.

[0097] The bill payment system 1 of Variation 1 sends the user a payment failure notification that includes content corresponding to the cause of the payment failure and that can accept payment-related operations. This allows the user to check the content corresponding to the cause of the payment failure, thereby further improving user convenience. Because the user can perform payment-related operations from the payment failure notification, the bill payment system 1 reduces the user's operational burden and improves user convenience. For example, after checking the notification screen SC4, the user does not have to perform complicated operations such as returning to the top screen SC1 to display a charge screen, but can simply select the content of the payment failure notification shown on the notification screen SC4, thereby reducing the user's operational burden.

[0098] [6-2. Variation 2] For example, as explained somewhat in the first modification, when an operation is performed on the content included in the payment failure notification, the user terminal 40 may transition to a payment-related screen related to the payment. The payment-related screen is a screen related to the payment reserved by the user. For example, the payment-related screen may be a screen showing the reservation details of the payment reserved by the user, a screen for charging the directly used payment means, a screen for changing the reservation details of the payment reserved by the user, a screen for canceling the reservation of the payment reserved by the user, or another screen.

[0099] The bill payment system 1 of Variation 2 includes a screen transition unit 105. When an operation on content is performed, the screen transition unit 105 transitions to a payment-related screen related to payment. An operation on content is a user selecting content. For example, an operation on content may be a click, double-click, tap, long press, or other operation on the content. In the example of Figure 8, an operation on content is equivalent to a user selecting one of buttons B41 to B43. The screen transition process executed by the screen transition unit 105 is a process for displaying the payment-related screen described above on the user terminal 40. It is assumed that display data for the payment-related screen is stored in the data storage unit 100. The display data may be any data required to display a screen on the user terminal 40. For example, the display data may be HTML data or image data.

[0100] In the example of Figure 8, when a user selects one of buttons B41 to B43, the user terminal 40 accesses the URL of a payment-related screen indicated by the link embedded in one of buttons B41 to B43. When the payment business operator server 10 accepts access from the user terminal 40, the screen transition unit 105 generates display data for the payment-related screen based on data from the payment service database DB, etc. The screen transition unit 105 transmits the display data for the payment-related screen to the user terminal 40, thereby transitioning to the payment-related screen.

[0101] When an operation on content is performed, the bill payment system 1 of Variation 2 transitions to a payment-related screen related to payment. This allows the bill payment system 1 to reduce the operational burden on the user for transitioning to a payment-related screen, thereby improving user convenience. For example, after checking notification screen SC4, the user does not have to perform the cumbersome operation of returning to the top screen SC1 to display a payment-related screen; instead, the user can simply select the content of the payment failure notification shown on notification screen SC4, so the bill payment system 1 can reduce the operational burden on the user.

[0102] [6-3. Variation 3] For example, if payment of a certain invoice fails, the appropriate notification to the user may differ depending on whether there is sufficient time before the payment deadline or not. When there is sufficient time before the payment deadline, the user needs to be urged to make the payment immediately, whereas when there is not sufficient time before the payment deadline, the user may be urged to make a new reservation rather than make the payment immediately. Variation 3 takes as an example a case where a payment failure notification is sent according to the payment deadline.

[0103] The bill payment system 1 of Variation 3 includes a payment deadline information acquisition unit 106. The payment deadline information acquisition unit 106 acquires payment deadline information related to the payment deadline. In Variation 3, the payment deadline information is included in the reservation history information stored in the payment service database DB, so the payment deadline information acquisition unit 106 acquires the payment deadline information from the payment service database DB. The payment deadline information may be stored in a database other than the payment service database DB. In this case, the payment deadline information acquisition unit 106 acquires the payment deadline information from the other database. The payment deadline information may be stored in a computer other than the payment business operator server 10 (for example, the collection organization server 30) or in an external information storage medium. In this case, the payment deadline information acquisition unit 106 acquires the payment deadline information from the other computer or external information storage medium.

[0104] FIG. 9 is a diagram showing an example of a payment failure notification in Modification 3. The notification unit 104 in Modification 3 sends a payment failure notification to the user based on the payment deadline information, the payment failure notification including content corresponding to the payment deadline and content that can accept payment-related operations. The meaning of the content may be the same as in Modification 1. The data storage unit 100 in Modification 3 stores content data indicating the relationship between the conditions related to the payment deadline information and the content included in the payment failure notification. The notification unit 104 identifies the conditions satisfied by the payment deadline information based on the content data. The notification unit 104 identifies the content associated with the identified conditions and sends the user a payment failure notification including the identified content.

[0105] For example, suppose the content data indicates that the time remaining until the payment deadline is less than a threshold and includes content encouraging the user to make the payment immediately. As shown in the upper right corner of FIG. 9 , when the notification unit 104 determines that the time remaining until the payment deadline is less than the threshold based on the payment deadline information, it sends the user a payment failure notification including a button B44 encouraging the user to make the payment immediately, as content associated with the condition indicating that the time remaining until the payment deadline is less than the threshold. The button B44 includes an embedded link to a reservation screen SC3 including a button B30 for making the payment immediately. This reservation screen SC3 does not necessarily include the button B31 for making a payment reservation. When the user selects the button B44, the payment service provider server 10 displays a reservation screen SC3 on the user terminal 40 for the user to make the payment immediately, rather than making a payment reservation. The reservation screen SC3 may be a known screen. The payment service provider server 10 executes the payment process based on information such as the direct payment method specified by the user on the reservation screen SC3.

[0106] For example, suppose the content data indicates that the time remaining until payment is equal to or greater than a threshold and includes content encouraging the user to make a new reservation. As shown in the lower right of FIG. 9 , when the notification unit 104 determines that the time remaining until payment is equal to or greater than the threshold based on the payment deadline information, the notification unit 104 sends the user a payment failure notification including a button B45 for encouraging the user to make a new reservation, as content associated with the condition indicating that the time remaining until payment is equal to or greater than the threshold. The button B45 includes an embedded link to a reservation screen SC3 including a button B31 for making a new reservation. This reservation screen SC3 does not necessarily include the button B30 for making an immediate payment. When the user selects the button B45, the payment service provider server 10 displays on the user terminal 40 a reservation screen SC3 for the user to make a new reservation. Since the failed reservation may be modified rather than a new reservation being made, the notification unit 104 may send a payment failure notification including a button B45 for modifying the failed reservation.

[0107] The bill payment system 1 of Variation 3 sends the user a payment failure notification based on the payment deadline information, which notification includes content corresponding to the payment deadline and content that can accept payment-related operations. This allows the user to check the content corresponding to the payment deadline, further improving user convenience. For example, if there is not enough time until the payment deadline, the bill payment system 1 can urge the user to make the payment immediately. If there is still time until the payment deadline, the bill payment system 1 can urge the user to make a new reservation without rushing.

[0108] [6-4. Variation 4] For example, in Variation 3, an example is given of a case where a payment failure notification including content according to the payment deadline is sent. Variation 4 is given of an example where the notification unit 104 sends a payment failure notification to the user in a manner according to the payment deadline, further based on the payment deadline information. The manner is how the notification unit 104 sends the payment failure notification. Variation 4 is given of an example where the notification means corresponds to the manner. The manner is not limited to the notification means. For example, the manner may be the color, size, frequency of notification, timing of notification, or other elements of the payment failure notification. It is assumed that data necessary for each manner of payment failure notification is stored in the data storage unit 100. The notification unit 104 can send a payment failure notification in any manner based on the data.

[0109] The bill payment system 1 of Variation 4 includes a payment deadline information acquisition unit 106 similar to that of Variation 3. The data storage unit 100 of Variation 4 stores mode data indicating the relationship between conditions related to the payment deadline information and the mode of the payment failure notification. The notification unit 104 identifies the conditions satisfied by the payment deadline information based on the mode data. The notification unit 104 notifies the user of the payment failure in the mode associated with the identified conditions.

[0110] For example, the notification unit 104 may provide the user with a payment failure notification in a manner corresponding to the cause indicated by the failure cause information based on the manner data. For example, if the failure cause information indicates a first cause, the notification unit 104 provides the user with a payment failure notification in a first manner. If the failure cause information indicates a second cause, the notification unit 104 provides the user with a payment failure notification in a second manner. The second cause is different from the first cause. The second manner is different from the first manner.

[0111] FIG. 10 is a diagram showing an example of a payment failure notification according to Variation 4. For example, assume that the content data indicates that the time remaining until the payment deadline is less than a threshold and that a payment failure notification should be sent via a pop-up P on the payment app. As shown in the upper right corner of FIG. 10, when the notification unit 104 determines that the time remaining until the payment deadline is less than the threshold based on the payment deadline information, it sends the user a payment failure notification via a pop-up P associated with the condition indicating that the time remaining until the payment deadline is less than the threshold. The notification unit 104 may display the payment failure notification pop-up P on the top screen SC1 instead of the notification screen SC4 that is displayed after the icon I11 is selected.

[0112] For example, suppose the content data indicates that the time remaining until the payment deadline is greater than or equal to a threshold and that a payment failure notification should be sent by email. As shown in the lower right of FIG. 10 , when the notification unit 104 determines that the time remaining until the payment deadline is greater than or equal to the threshold based on the payment deadline information, it notifies the user of the payment failure by sending an email associated with the condition indicating that the time remaining until the payment deadline is greater than or equal to the threshold to the user's email address. When the user operates the user terminal 40 to launch an email application or logs into an email service from a browser, the user terminal 40 displays an email screen SC6 on the display unit 45, which displays the email notification of the payment failure. When the user selects the email payment failure notification button B60, the user terminal 40 launches the payment application and displays the screen linked to the button B60.

[0113] The bill payment system 1 of Variation 4 notifies the user of the payment failure in a manner appropriate to the payment deadline, further based on the payment deadline information. This allows the user to check the payment failure notification in a manner appropriate to the payment deadline, thereby further improving user convenience. For example, if there is not much time left until the payment deadline, the bill payment system 1 notifies the user of the payment failure in a pop-up P that is easy for the user to notice, making it easier for the user to realize that they need to take action to address the payment failure. However, some users may find the display of the pop-up P cumbersome, so if there is still time left until the payment deadline, the bill payment system 1 can notify the user of the payment failure by email, which is less likely to be cumbersome for the user.

[0114] [6-5. Variation 5] For example, when multiple payments by a user fail, the failure cause information acquisition unit 103 may acquire failure cause information for each of the multiple payments. When multiple payments by a user are made at a certain payment timing, the failure cause information acquisition unit 103 determines whether each of the multiple payments has failed. The method of determining each individual payment may be the same as in the embodiment. When it is determined that multiple payments have failed, the failure cause information acquisition unit 103 acquires failure cause information for each of the multiple payments. The method of acquiring each individual failure cause information may be the same as in the embodiment.

[0115] FIG. 11 is a diagram showing an example of a payment failure notification according to Variation 5. Based on the failure cause information for each of the multiple payments, the notification unit 104 of Variation 5 sends a single payment failure notification to the user, consolidating notifications regarding the causes of each of the multiple payments. In the example of FIG. 11, two payments fail at a certain payment timing. In this case, the notification unit 104 does not send two payment failure notifications, but instead sends a single payment failure notification indicating that the two payments failed. For example, the notification unit 104 obtains at least one of the reservation history information and payment result information for the two failed payments from the payment service database DB, and generates a single payment failure notification by inserting details of each of the two payments into a template indicated by the template data. The notification unit 104 sends the single payment failure notification to the user.

[0116] The notification unit 104 may issue a single notification whether the causes indicated by the failure cause information for each of the multiple payments are different or the same. If the causes indicated by the failure cause information for each of the multiple payments are the same, the notification unit 104 may issue a single notification. If the causes indicated by the failure cause information for each of the multiple payments are different, the notification unit 104 may issue a notification for each individual cause. For example, if the causes indicated by the failure cause information for each of the multiple payments are different and multiple payments failed due to a single cause, the notification unit 104 may combine the multiple payments into a single notification. For example, suppose three payments were made on the same day. Of the three payments, two failed due to insufficient balance and one failed due to a system error. In this case, the notification unit 104 may issue a first notification indicating that two payments failed due to insufficient balance and a second notification indicating that one payment failed due to a system error. For example, the first notification may include content for charging depending on the cause of the insufficient balance. The second notification may include content for rebooking depending on the cause of the system error. In this way, by grouping notifications by cause, the user can perform operations (for example, charging all at once) for each cause.

[0117] In the fifth variation, when a user's multiple payments fail, the bill payment system 1 acquires information on the cause of the failure for each of the multiple payments. Based on the information on the cause of the failure for each of the multiple payments, the bill payment system 1 sends the user a single payment failure notice that consolidates information on the causes of the failure of each of the multiple payments. This eliminates the need for the user to receive multiple payment failure notices, thereby improving user convenience. For example, if a user receives multiple payment failure notices, one payment failure notice may be buried under other payment failure notices. However, because the user can view the multiple failed payments together through a single payment failure notice, they are less likely to overlook a failed payment.

[0118] [6-6. Variation 6] For example, if multiple payments are scheduled for a certain payment timing, the payment execution unit 102 executes each of the multiple payments at that payment timing. In this case, depending on the directly used payment means, some of the payments may fail. For example, if the directly used payment means is electronic money, some of the payments may fail due to insufficient balance. The payment execution unit 102 executes as many of the multiple payments as possible based on the electronic money balance. The payments to be executed may be prioritized. When a certain payment timing arrives, the payment execution unit 102 executes each of the multiple payments one after another based on the priority associated with each of the multiple payments. For example, the payment execution unit 102 may execute payments in descending order of payment amount, or in order of the nearest payment deadline. If the directly used payment means is electronic money, if the balance runs out midway, subsequent payments will fail.

[0119] In Modification 6, when some of multiple payments fail at a specific payment timing, the failure cause information acquisition unit 103 acquires failure cause information for the part of the payment. When multiple payments are made by a user at a certain payment timing, the failure cause information acquisition unit 103 determines whether each of the multiple payments has failed. The method of determining each individual payment may be the same as in the embodiment. When it is determined that some of the multiple payments have failed, the failure cause information acquisition unit 103 acquires failure cause information for the part of the payment. The part of the payment that fails may be only one, or may be multiple. The method of acquiring failure cause information may be the same as in the embodiment.

[0120] The notification unit 104 in the sixth modification notifies the user of a payment failure based on the failure cause information of the failed partial payment. For example, if only one partial payment has failed, the notification unit 104 notifies the user of the payment failure of that single payment, in the same manner as in the embodiment. If the failed partial payment consists of multiple payments, the notification unit 104 may notify the user of a payment failure that consolidates notifications regarding the causes of failure of each of the multiple payments, in the same manner as in the fifth modification. In the sixth modification, the notification unit 104 may notify the user of a separate payment failure notification for each of the multiple payments. The method of notifying each individual payment failure notification may be the same as in the embodiment and any of the first to fourth modifications.

[0121] In variant 6, when one of multiple payments fails at a specified payment timing, the bill payment system 1 obtains information about the cause of the failure of that payment. Based on the information about the cause of the failure of that payment, the bill payment system 1 notifies the user of the payment failure. This allows the user to know the cause of the failure of a payment, even if that payment fails at a time when multiple payments are made, thereby further improving user convenience.

[0122] [6-7. Variation 7] For example, in the embodiment, a case where a user makes a reservation for payment has been described. When the payment reserved by the user fails, the failure cause information acquisition unit 103 acquires failure cause information. When the payment reserved by the user fails, the notification unit 104 notifies the user of the payment failure. These processes are as described in the embodiment.

[0123] For example, the bill payment system 1 may be able to predict future payments a user will make. Suppose a user regularly pays utility bills, taxes, or the like. In this case, the bill payment system 1 may be able to predict the user's future tendencies based on the user's past reservation history. For example, a user may make a reservation well before the due date of a regular payment, or may make a reservation just before the due date. If the bill payment system 1 can predict such user tendencies, it can predict whether the user will forget to make a reservation for a regular payment. In other words, if the user has not yet made a reservation even when the time has come for the user to make the reservation, the bill payment system 1 can predict that the user has forgotten to make the reservation. This point is not limited to regular payments. Even if the payment is not regular, if the user has made similar payments in the past, the bill payment system 1 can predict future payments from that history. The bill payment system 1 may use this prediction to notify the user about future payments.

[0124] The bill payment system 1 of the seventh variant includes a reservation history information acquisition unit 107 and a prediction unit 108. The reservation history information acquisition unit 107 acquires reservation history information relating to the history of payments made by the user. In the seventh variant, the reservation history information indicates the acceptance timing of the reservation. The acceptance timing is the timing at which the reservation is accepted. The acceptance timing may be expressed not only as a date but also as a time and date including the time. The user can make a reservation at any acceptance timing. However, if a payment deadline is set on the invoice, the user will, as a general rule, make a reservation at an acceptance timing up to the payment deadline.

[0125] For example, the reservation history information acquisition unit 107 acquires the reservation history information from the payment service database DB. Note that 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 107 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 service provider server 10. In this case, the reservation history information acquisition unit 107 acquires the reservation history information from the other computer or external information storage medium.

[0126] The prediction unit 108 predicts the timing of future payments made by the user based on the reservation history information. For example, the prediction unit 108 calculates the average value of the time intervals between the payment timings of multiple payments made by the user in the past based on the reservation history information. The prediction unit 108 predicts the timing of future payments made by the user to be the timing that is the calculated average value after the payment timing of the most recent payment. This payment may be a payment made periodically by the user. In this case, the prediction unit 108 may determine whether the payment is periodic based on at least one of whether there has been a predetermined number of reservation histories in the past and whether the payment is a periodic payment based on the bill attributes, such as utility bills or taxes. The prediction unit 108 may predict the timing of future payments made by the user based on the user's payment timing patterns for periodic payments. For example, if a user's reservation history information includes a history of an electronic payment made on December 30, 2023, and similar history exists every month, the prediction unit 108 predicts that the next payment will be made one month later, on January 30, 2024. In this case, a notification such as "Would you like to make a reservation for electricity payment?" may be sent some time before January 30, 2024 (for example, one week before) by processing by the notification unit 104, which will be described later.

[0127] The method for predicting the payment timing is not limited to the above example. For example, the prediction unit 108 may predict the future payment timing based on a value obtained by substituting the time interval into another calculation formula, rather than the average value of the time interval between the payment timings of multiple past reservations. Alternatively, the prediction unit 108 may predict the payment timing based on a model prepared using machine learning techniques that predicts the payment timing based on reservation history information. The payment timing predicted by the prediction unit 108 is stored in the payment service database DB or another database. The notification unit 104 obtains the predicted payment timing for each user from the payment service database DB or another database.

[0128] FIG. 12 is a diagram showing an example of a notification in Modification 7. The notification unit 104 in Modification 7 provides a notification before the payment timing predicted by the prediction unit 108 arrives. In the example of FIG. 12, the notification unit 104 provides a notification to the user using a notification function on the payment app. For example, the notification unit 104 acquires the current date and time using a real-time clock or GPS and determines whether the predicted reservation time for each user has arrived. For example, when it is determined that the reservation time for the regular payment predicted by the prediction unit 108 has arrived, the notification unit 104 determines whether a reservation for the regular payment has been made based on the reservation history information stored in the payment service database DB. The notification unit 104 may also determine whether the payee is the target of the regular payment based on the payee indicated in the reservation history information. When it is determined that a reservation for the regular payment has not been made, the notification unit 104 provides a notification to the user.

[0129] For example, it is assumed that the data storage unit 100 stores template data for notifications. The template for notifications may be generally similar to the template for notifications, but differs in that it includes content for notifications. For example, the template for notifications indicates a character string indicating the content of the notification. The notification unit 104 inserts information about the recurring payment to be notified into the template indicated by the template data based on reservation history information for past recurring payments stored in the payment service database DB. In the example of Figure 12, the notification unit 104 inserts information such as the payee and payment amount of the past recurring payment into the template.

[0130] For example, the notification unit 104 generates a link to the shooting screen SC2 and inserts a button B46 including the link into the template. Data related to the link of the shooting screen SC2 is assumed to be stored in advance in the data storage unit 100. The notification unit 104 may identify the link to be embedded in the button B46 based on the data. The notification unit 104 may insert information such as an argument specific to the user into the link indicated by the data, and then generate the link to be embedded in the button B46. The notification unit 104 displays a notification screen SC4 indicating the notification generated as described above to the user.

[0131] The method by which the notification unit 104 notifies the user is not limited to the above example. The notification unit 104 may notify the user by a method appropriate to the notification means. For example, if email is used for the notification, the notification unit 104 may send email as a notification to the user's email address indicated by the notification destination information. The notification unit 104 may generate the email in the same manner as notifications sent on the payment app. For example, the notification unit 104 may send an email message to the user's email address that includes the reservation details of the reservation that is the subject of the notification and a link to the shooting screen SC2.

[0132] For example, when SMS is used for notification, the notification unit 104 may send an SMS message as notification to the user's telephone number indicated by the notification destination information. The notification unit 104 may generate the SMS message in the same manner as an email. For example, the notification unit 104 may send an SMS message to the user's telephone number, the SMS message including the reservation details of the reservation to be notified and a link to the shooting screen SC2.

[0133] For example, when a message app is used for notification, the notification unit 104 may send a message of the message app as a notification to the user's account indicated by the notification destination information. The notification unit 104 may generate a message of the message app in the same manner as an email. For example, the notification unit 104 may send a message of the message app to the user's account, the message including the reservation details of the reservation to be notified and a link to the shooting screen SC2. Similarly, when another notification means is used, the notification unit 104 may notify the user in a manner appropriate to the other notification means.

[0134] The bill payment system 1 of variant 7 acquires reservation history information. Based on the reservation history information, the bill payment system 1 predicts the timing of future payments made by the user. The bill payment system 1 notifies the user before the predicted payment timing arrives. This prevents the bill payment system 1 from forgetting to make a reservation for a future payment, thereby improving user convenience.

[0135] [6-8. Variation 8] For example, the appropriate payment failure notification may differ depending on the payment source used for the payment scheduled by the user. If it is necessary to convey to the user content specific to a certain payment source, the bill payment system 1 may issue a payment failure notification that includes that specific content. If it is necessary to issue a payment failure notification at a timing specific to a certain payment source, the bill payment system 1 may issue the payment failure notification at that timing. Therefore, Variation 8 provides an example of a case where a payment failure notification is issued depending on the payment source.

[0136] The bill payment system 1 of variant 8 includes a payment source information acquisition unit 109. The payment source information acquisition unit 109 acquires payment source information relating to payment sources used directly or indirectly in payment. For example, the payment source information acquisition unit 109 acquires payment source information from the payment service database DB. For example, if the payment method used directly in payment corresponds to the payment source, the reservation history information directly indicates information on the payment method used (i.e., payment source information), so the payment source information acquisition unit 109 acquires the payment source information by acquiring the reservation history information stored in the payment service database DB.

[0137] For example, when a charging method indirectly used for payment corresponds to the payment source, the reservation history information indicates information on the charging method (i.e., payment source information), so the payment source information acquisition unit 109 acquires the payment source information by acquiring the reservation history information stored in the payment service database DB. When the reservation history information does not indicate information on the charging method, the payment source information acquisition unit 109 may acquire the payment source information by acquiring the charging method information stored in the payment service database DB.

[0138] The payment source information may be stored in a database other than the payment service database DB. The payment source information acquisition unit 109 may acquire the payment source information from another database. The payment source information may be stored in a computer other than the payment service provider server 10 or in an external information storage medium. The payment source information acquisition unit 109 may acquire the payment source information from another database or external information storage medium. The payment source information acquisition unit 109 may acquire all of the payment source information, or may acquire only part of the payment source information. The payment source information acquisition unit 109 only needs to acquire the payment source information of the payment for which the notification timing is to be determined.

[0139] The notification unit 104 further notifies the user of payment failure based on the payment source information and the deposit period related to the payment source. The deposit period is the period required for deposit. The deposit period is not the period from when the user instructs charging to when charging is completed, but the period from when charging is completed to when the deposit, which is the source of funds for charging, is received from the administrator of the charging method. The deposit period occurs when the administrator of the charging method (in variant 8, the card company) deposits money to the administrator of the directly used payment method (in variant 8, the payment service provider) that is directly used for payment. Any deposit method, such as bank transfer, may be used for the deposit. Data indicating the length of the deposit period is stored in the data storage unit 100.

[0140] The administrator of a charging means is a business that manages the charging means. For example, if the charging means is a credit card, the card company that issued the credit card corresponds to the administrator of the charging means. If the charging means is an account such as a bank account, the financial institution that manages the account corresponds to the administrator of the charging means. The administrator of a directly used payment means is a business that manages the directly used payment means. For example, if the directly used payment means is electronic money, the business that manages the electronic money corresponds to the administrator of the directly used payment means. If the directly used payment means is an account such as a bank account, the financial institution that manages the account corresponds to the administrator of the directly used payment means.

[0141] The data storage unit 100 of Variation 8 stores deposit period relationship data indicating the relationship between payment source information and notification methods corresponding to deposit periods. The deposit period relationship data may be in any format, such as a table, a mathematical formula, part of a program, a machine learning model, or another format. The notification unit 104 identifies the notification method associated with the payment source information based on the deposit period relationship data and notifies the user of the payment failure using the identified notification method. The notification method may be the content included in the payment failure notification, the notification timing, the notification means, or any other method.

[0142] For example, the notification unit 104 may issue a payment failure notification that suggests at least one of the payment timing and charge timing according to the payment period for a new reservation. Here, it is assumed that the payment source is a charge method. Furthermore, it is assumed that the payment period (e.g., two days) when the payment source is a bank account is shorter than the payment period (e.g., one week) when the payment source is a credit card. When the payment source is a bank account with a relatively short payment period, the notification unit 104 issues a payment failure notification that suggests a charge timing according to the payment period. In this case, the charge timing may be a deadline that is at least the payment period (e.g., two days) before the payment deadline.

[0143] For example, if the payment source is a credit card with a relatively long deposit period, the notification unit 104 issues a payment failure notification proposing a charge timing that corresponds to the deposit period. In this case, the charge timing may be a deadline that precedes the payment deadline by the deposit period (for example, one week). Similarly, when the notification unit 104 proposes a payment timing, the notification unit 104 may issue a payment failure notification that proposes a payment timing that corresponds to the deposit period of the payment source indicated by the payment source information. The notification unit 104 may also issue a payment failure notification that proposes both a payment timing and a charge timing that correspond to the deposit period of the payment source indicated by the payment source information.

[0144] The bill payment system 1 of Variation 8 further uses the payment source information to notify the user of a payment failure according to the payment source's deposit period. This allows the bill payment system 1 to provide an appropriate payment failure notification according to the payment source. For example, by providing a payment failure notification that suggests a charge timing based on the payment period from the card company to the payment service provider, the bill payment system 1 can encourage the user to charge earlier, making it easier to avoid the card company's deposit to the payment service provider being delayed after the deposit to the collection organization at the time of payment. As a result, the bill payment system 1 can prevent payment service providers from running out of funds and increase convenience for payment service providers.

[0145] [6-9. Variation 9] For example, if a payment fails, future payments scheduled after it may also fail. A future payment is a payment that occurs in the future. If the directly used payment method is electronic money, if a payment fails due to insufficient balance, other payments scheduled after it may also fail due to insufficient balance. Therefore, a payment failure notification may be sent taking into account whether or not there are any future payments.

[0146] The bill payment system 1 of Variation 9 includes a future payment information acquisition unit 110. When a payment fails, the future payment information acquisition unit 110 acquires future payment information related to a future payment reserved by the user. In Variation 9, the future payment information is included in the reservation history information stored in the payment service database DB. Among the reservation history information, reservation history information in which at least one of the payment timing or payment deadline is in the future corresponds to future payment information. The future payment information acquisition unit 110 acquires the future payment information from the payment service database DB. The future payment information may be stored in a database other than the payment service database DB. In this case, the future payment information acquisition unit 110 acquires the future payment information from the other database. The future payment information may be stored in a computer other than the payment service provider server 10 (for example, the receiving organization server 30) or in an external information storage medium. In this case, the future payment information acquisition unit 110 acquires the future payment information from the other computer or external information storage medium. Note that the future payment information acquisition unit 110 may acquire future payment information for a future payment for which the same payment source as the payment source of the failed payment is specified.

[0147] The notification unit 104 of the ninth modification notifies the user of a payment failure based on the future payment information. For example, when a payment fails, the notification unit 104 notifies the user of a payment failure that includes not only the failed payment but also information about future payments indicated by the future payment information. In an example similar to the embodiment, the notification screen SC4 in the upper left of FIG. 3 includes not only the payment that failed due to insufficient balance but also information about future payments scheduled thereafter. The notification unit 104 generates a payment failure notification by embedding the content indicated by the future payment information (e.g., payment amount, payment deadline, payment timing, and charge timing) into a template indicated by the template data. The notification unit 104 notifies the user of the generated payment failure notification.

[0148] The bill payment system 1 of Variation 9 notifies the user of a payment failure based on the future payment information. This allows the user to be aware of future payments that may fail in advance, thereby further enhancing user convenience. For example, if a payment fails, the user will be aware of future payments due to the payment failure notification, and will be able to charge more money with future payments in mind.

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

[0150] For example, the embodiment exemplifies a payment failure notification when a payment scheduled by the user fails. If a payment made by the user on the spot by selecting button B30 on the reservation screen SC3 fails, rather than a payment scheduled by the user, the notification unit 104 may issue a payment failure notification to the user indicating the cause of the payment failure. The payment failure notification in this case differs in that it is a notification for a payment made by the user on the spot, rather than a payment scheduled by the user, but the processing for the payment failure notification may be similar to that in the embodiment. The bill payment system 1 may not include a function that allows the user to schedule a payment. In this case, the bill payment system 1 may not include the reservation acceptance unit 101. The bill payment system 1 may include a function for issuing a payment failure notification when a payment made on the spot by the user fails, but may not include a function for issuing a payment failure notification when a payment scheduled by the user fails.

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

[0152] [7. Notes] For example, a bill payment system can be configured as follows: (1) a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails; a notification unit that notifies the user of a payment failure regarding the cause of the payment failure based on the failure cause information; Bill payment system including. (2) the notification unit issues the payment failure notification to the user, the payment failure notification including content corresponding to the cause of the payment failure and accepting an operation related to the payment. (1) A bill payment system as described in (1). (3) The bill payment system further includes a screen transition unit that transitions to a payment-related screen regarding the payment when the operation is performed. (2) A bill payment system as described in (2). (4) The bill payment system further includes a payment deadline information acquisition unit that acquires payment deadline information regarding a payment deadline for the payment, the notification unit issues a payment failure notification to the user based on the payment deadline information, the payment failure notification including the content corresponding to the payment deadline and accepting an operation related to the payment. A bill payment system according to any one of (1) to (3). (5) The bill payment system further includes a payment deadline information acquisition unit that acquires payment deadline information regarding a payment deadline for the payment, the notification unit issues the payment failure notification to the user in a manner corresponding to the payment deadline, further based on the payment deadline information. A bill payment system according to any one of (1) to (4). (6) the failure cause information acquisition unit acquires the failure cause information for each of the plurality of payments when the plurality of payments by the user fail; the notification unit issues to the user the payment failure notification, which is a single notification regarding the cause of failure of each of the plurality of payments, based on the failure cause information for each of the plurality of payments; A bill payment system according to any one of (1) to (5). (7) the failure cause information acquisition unit acquires the failure cause information of a part of the payment when the part of the plurality of payments fails at a predetermined payment timing; the notification unit notifies the user of the payment failure based on the failure cause information of the partial payment. A bill payment system according to any one of (1) to (6). (8) the failure cause information acquisition unit acquires the failure cause information when the payment for the reservation made by the user fails, the notification unit notifies the user of the payment failure when the payment for the reservation made by the user fails, The bill payment system comprises: a reservation history information acquisition unit that acquires reservation history information relating to the history of the payment for the reservation made by the user; a prediction unit that predicts a payment timing regarding the payment to be made by the user in the future based on the reservation history information; Further comprising: The notification unit issues the notification before the payment timing predicted by the prediction unit arrives. A bill payment system according to any one of (1) to (7). (9) The bill payment system further includes a payment source information acquisition unit that acquires payment source information regarding a payment source that is directly or indirectly used in the payment, The notification unit sends the user the payment failure notification according to the payment period related to the payment source further based on the payment source information. A bill payment system according to any one of (1) to (8). (10) The bill payment system further includes a future payment information acquisition unit that acquires future payment information regarding a future payment scheduled by the user when the payment fails; the notification unit notifies the user of the payment failure further based on the future payment information. A bill payment system according to any one of (1) to (9). [Explanation of symbols]

[0153] 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, P pop-up, 100, 200, 300, 400 data storage unit, 101 reservation reception unit, 102 payment execution unit, 103 failure cause information acquisition unit, 104 notification unit, 105 screen transition unit, 106 payment deadline information acquisition unit, 107 reservation history information acquisition unit, 108 reservation time prediction unit, 109 payment source information acquisition unit, 110 future payment information acquisition unit, 201 service provision unit, 301 collection unit, 401 operation reception unit, 402 Display control section, B10, B30, B31, B40, B41, B42, B43, B44, B45, B46, B50, B60 buttons, I11 icon, SC1 top screen, SC2 shooting screen, SC3 reservation screen, SC4 notification screen, SC5 list screen, SC6 email screen.

Claims

1. a failure cause information acquisition unit that acquires failure cause information regarding the cause of the payment failure from among a plurality of causes of the payment failure when the user's bill payment fails; a notification unit that issues a payment failure notification to the user based on content data indicating a relationship between the failure cause information and content included in a payment failure notification related to the cause, the payment failure notification including the content that allows the user to perform an operation to deal with the cause indicated by the failure cause information among the plurality of causes; Bill payment system including.

2. The bill payment system further includes a screen transition unit that, when the operation is performed, transitions to a payment-related screen related to the payment, the payment-related screen corresponding to the cause of the payment failure.

10. The bill payment system of claim 1.

3. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails; a payment deadline information acquisition unit that acquires payment deadline information regarding the payment deadline; a notification unit that identifies a condition satisfied by the payment deadline information based on content data indicating a relationship between a condition related to the payment deadline information and a content included in a payment failure notification related to the cause indicated by the failure cause information, the content accepting an operation related to the payment, identifies content associated with the identified condition, and sends the payment failure notification including the identified content to the user; Bill payment system including.

4. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails; a payment deadline information acquisition unit that acquires payment deadline information regarding the payment deadline; a notification unit that identifies conditions satisfied by the payment deadline information based on mode data indicating the relationship between conditions related to the payment deadline information and a mode that is one of a plurality of notification means, and notifies the user of a payment failure related to the cause indicated by the failure cause information in a mode associated with the identified conditions; Bill payment system including.

5. a failure cause information acquisition unit that acquires failure cause information regarding the cause of each of a plurality of payments failures of a user when the user fails to pay the plurality of bills; a notification unit that, when it is determined based on the failure cause information for each of the plurality of payments that the cause of failure for each of the plurality of payments is the same, issues to the user a single payment failure notification relating to the cause, and when it is determined that the causes of failure for each of the plurality of payments are different, issues to the user a payment failure notification for each individual cause; Bill payment system including.

6. the failure cause information acquisition unit acquires the failure cause information of a part of the payment when the part of the plurality of payments fails at a predetermined payment timing; the notification unit notifies the user of the payment failure based on the failure cause information of the partial payment. A bill payment system according to any one of claims 1 to 5.

7. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a payment failure when a payment of an invoice reserved by a user fails; a notification unit that, when the payment for the reservation made by the user fails, issues a payment failure notification to the user regarding the cause of the payment failure based on the failure cause information; a reservation history information acquisition unit that acquires reservation history information relating to the history of the payment for the reservation made by the user; a prediction unit that predicts a payment timing regarding the payment to be made by the user in the future based on the reservation history information; Including, the notification unit determines whether or not a reservation for the payment has been made before the payment timing predicted by the prediction unit arrives, and if it is determined that the reservation has not been made, issues a reservation notification to urge the user to make the reservation. Bill payment system.

8. a failure cause information acquisition unit that acquires failure cause information regarding the cause of a user's bill payment failure when the user's bill payment fails; a future payment information acquisition unit that acquires future payment information regarding future payments reserved by the user when the payment fails; a notification unit that generates the payment failure notification by embedding information regarding the future payment indicated by the future payment information into the template based on template data indicating a template of a payment failure notification related to the cause indicated by the failure cause information, and sends the generated payment failure notification to the user; Bill payment system including.

9. The computer a failure cause information acquisition step of acquiring failure cause information regarding the cause of the payment failure among a plurality of causes of the payment failure when the user's payment of the bill fails; a notification step of sending a payment failure notification to the user based on content data indicating a relationship between the failure cause information and content included in a payment failure notification related to the cause, the payment failure notification including the content allowing the user to perform an operation to deal with the cause indicated by the failure cause information among the plurality of causes; Bill payment methods to perform.

10. a failure cause information acquisition unit that acquires failure cause information regarding the cause of the payment failure among a plurality of causes of the payment failure when the user's bill payment fails; a notification unit that issues a payment failure notification to the user based on content data indicating a relationship between the failure cause information and content included in a payment failure notification related to the cause, the payment failure notification including the content allowing the user to perform an operation to deal with the cause indicated by the failure cause information among the plurality of causes; A program that allows a computer to function as a

Images