Bill payment system, bill payment method, and program

Abstract

To improve user convenience.SOLUTION: In a bill payment system (1) disclosed herein, a notification unit (102) generates a notification that enables reception of a payment-related operation to a user before a payment deadline related to bill payment, and a process execution unit (103) executes a payment-related process when the operation is performed.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 balance in their electronic money account at the time of the scheduled payment, the payment will fail. If the payment fails, the user must make a new reservation or pay a late fee. While it is conceivable to send a notification to the user before the payment date and time to prompt them to check their electronic money balance, this requires the user to close the notification screen, launch the electronic money application, or access the website of the business that manages the electronic money in order to check the balance, which is time-consuming. This issue is not limited to balance confirmation, but also applies to other notifications related to bill payments. Therefore, conventional technologies have not been able to 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 of the present disclosure includes a notification unit that notifies the user before the payment timing for the bill arrives that an operation related to the payment can be accepted, and a processing execution unit that executes processing related to the payment when the operation is performed. [Effects of the Invention]

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

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example of the hardware configuration of a bill payment system. [Figure 2] FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal. [Figure 3] FIG. 10 is a diagram illustrating an example of a screen displayed on a user terminal. [Figure 4] FIG. 1 is a diagram illustrating an example of functions implemented in a bill payment system. [Figure 5] FIG. 10 is a diagram illustrating an example of a payment service database. [Figure 6] FIG. 1 is a diagram illustrating an example of processing performed in a bill payment system. [Figure 7] FIG. 10 is a diagram illustrating an example of a function realized in a modified example. [Figure 8] FIG. 13 is a diagram showing an example of a screen transition in Modification 3. [Figure 9] FIG. 10 is a diagram showing an example of a notification of insufficient balance. [Figure 10] FIG. 10 is a diagram illustrating an example of a charge notification. [Figure 11] FIG. 20 is a diagram showing an example of a notification in Modification 6. 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] In this embodiment, when the time for payment approaches, a notification regarding payment is sent to the user. For example, the payment service provider server 10 notifies the user using a notification function on the payment app. When the user selects icon I11 on the top screen SC1, the user terminal 40 displays a notification screen SC4 on the display unit 45, which shows the content of the notification, as shown in the upper left of Figure 3.

[0029] In this embodiment, the notification displayed on the notification screen SC4 can accept operations related to bill payment. In the example at the top left of FIG. 3, the notification includes a button B40 that allows the user to change the reservation details. The button B40 includes a link to a bill payment service. The user checks the notification and determines whether or not the reservation details need to be changed. In the example at the top left of FIG. 3, the user uses electronic money after auto-charge, resulting in an insufficient balance in the electronic money. For example, the user changes the payment timing to just before the payment deadline, allowing time for electronic money charge.

[0030] For example, when the user selects button B40, the user terminal 40 displays a list screen SC5 on the display unit 45, which shows a list of reservations made by the user, as shown in the upper right corner of FIG. 3. The user selects button B50 to change the reservation details indicated in the notification. Changes to the reservation details can be made from a screen similar to the reservation screen SC3. 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.

[0031] As described above, the bill payment system 1 of this embodiment notifies the user on the payment app before the payment timing arrives. The user can perform operations to change the reservation details from the notification. This allows the user to view the list screen SC5 directly from the notification and change the reservation details without having to perform operations such as returning to the top screen SC1 and displaying the list screen SC5 after checking the notification. This allows the bill payment system 1 to reduce the operational burden on the user and increase user convenience. The bill payment system 1 will be described in detail below.

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

[0033] [3-1. Functions realized by the payment service provider server] For example, the payment processor server 10 includes a data storage unit 100, a reservation acceptance unit 101, a notification unit 102, and a process execution unit 103. The data storage unit 100 is realized by the memory unit 12. The reservation acceptance unit 101, the notification unit 102, and the process execution unit 103 are each realized by the control unit 11.

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

[0035] 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, and reservation history information. The payment service database DB may also store other data. For example, the payment service database DB may store information related to payment methods used by users when making payments using codes displayed on the payment app, charge history information related to the history of past charge attempts, and bill payment history information related to the history of past bill payments.

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

[0037] The notification destination information is information about 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 corresponding to the notification means used by the notification unit 102 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.

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

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

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

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

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

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

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

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

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

[0047] 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 102 (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.

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

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

[0050] [Notification Department] The notification unit 102 notifies the user that a payment operation is acceptable before the payment timing for the bill payment arrives. The payment operation may be any operation related to the payment of a reservation made by the user. For example, the payment operation may be an operation for changing the reservation details, an operation for canceling the reservation, an operation for charging a directly used payment method, an operation for transitioning to a bill payment service screen, or other operations. In this embodiment, an example is given in which the notification unit 102 notifies the user between the time the reservation is made and the time the payment arrives. However, the notification unit 102 may also notify the user before the reservation is made. For example, as in Variation 6 described below, if the payment timing is predicted based on the reservation history or the like, the notification unit 102 may notify the user based on the predicted payment timing.

[0051] A notification that can accept a payment-related operation is a notification that includes user interface parts for accepting the operation. The parts included in the notification may be known parts. For example, the parts included in the notification may be buttons, icons, images other than buttons and icons, text, or other parts. The parts may include a link to the destination screen. In the example in the upper left of Figure 3, a notification that includes button B40 with an embedded link to list screen SC5 corresponds to a notification that can accept a payment-related operation. The operation for transitioning to list screen SC5 to change the reservation details for payment corresponds to a payment-related operation.

[0052] In this embodiment, the notification unit 102 can notify the user at any notification timing before the payment timing arrives. For example, the user may specify the notification timing himself. The notification timing specified by the user is indicated in the reservation history information. The notification timing may be on the same day as the payment timing or on a day before the payment timing. In this embodiment, the time difference between the notification timing and the payment timing is predefined. Data indicating this difference is predefined in the data storage unit 100. If the user does not specify the payment timing, the payment timing may be the invoice payment deadline.

[0053] For example, the notification unit 102 identifies the payment timing for a reservation made by the user based on the reservation history information stored in the payment service database DB. The notification unit 102 acquires the current date and time using a known method such as a real-time clock or GPS, and determines whether the notification timing has arrived a predetermined time before the payment timing. If the notification unit 102 determines that the notification timing has arrived, it does not notify the user. If the notification unit 102 determines that the notification timing has arrived, it notifies the user. The notification unit 102 notifies the user based on the notification destination information stored in the payment service database DB.

[0054] In this embodiment, the notification function of the payment app is used. When the notification unit 102 determines that the time for notification has arrived, it inserts information about the reservation details to be notified into the template indicated by the template data, based on the reservation history information stored in the payment service database DB. In the example in the upper left of FIG. 3, the notification unit 102 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 indicated by the notification screen SC4 in the upper left of FIG. 3 (e.g., a sentence such as "The following payment is coming up..."). The notification unit 102 inserts information such as the payee and payment amount after the standard phrase.

[0055] For example, the notification unit 102 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 102 may identify the link to be embedded in the button B40 based on the data. The notification unit 102 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 102 generates notification information indicating the notification generated as described above, associates the notification information with the user ID of the user to send the notification, and stores the notification information in the payment service database DB.

[0056] The method by which the notification unit 102 notifies is not limited to the above example. The notification unit 102 may notify the user in a method appropriate to the notification means. For example, the 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 notification on the payment app may be a pop-up, a banner, or other notification. As another example, when email is used for notification, the notification unit 102 may send email as a notification to the user's email address indicated by the notification destination information. The notification unit 102 may generate email in the same manner as the notification on the payment app. For example, the notification unit 102 may send email to the user's email address including the reservation details of the reservation to be notified and a link to the list screen SC5.

[0057] For example, when SMS is used for notification, the notification unit 102 may send an SMS message as a notification to the user's telephone number indicated by the notification destination information. The notification unit 102 may generate the SMS message in the same manner as an email. For example, the notification unit 102 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 list screen SC5.

[0058] For example, when a message app is used for notification, the notification unit 102 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 102 may generate a message of the message app in the same manner as an email. For example, the notification unit 102 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 list screen SC5. Similarly, when another notification means is used, the notification unit 102 may notify the user in a manner appropriate to the other notification means.

[0059] [Processing execution section] The process execution unit 103 executes a payment-related process when a payment-related operation is performed. A payment-related process is a process that is directly or indirectly related to payment. A payment-related process is a process that is executed when a payment-related operation is performed as a condition (trigger). In this embodiment, the process execution unit 103 executes a screen transition process that transitions to a list screen SC5 as a payment-related process, as an example. The list screen SC5 is an example of a payment-related screen. Therefore, any description of the list screen SC5 can be read as a payment-related screen. Furthermore, any description of the screen transition process can be read as a payment-related process. Note that the payment-related process may be both a reservation and a payment, or either a reservation or a payment.

[0060] The payment-related screen is a screen related to a payment scheduled by the user. For example, the payment-related screen may be a screen showing the details of a payment scheduled by the user, a screen for charging a directly used payment means, a screen for changing the details of a payment scheduled by the user, a screen for canceling a payment scheduled by the user, or another screen. The screen transition process is a process for displaying a payment-related screen, such as these examples, on the user terminal 40. The display data for the payment-related screen is assumed to be 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.

[0061] In the example in the upper left of Fig. 3, the operation of the user selecting button B40 corresponds to an operation related to payment, so when the user selects button B40, the user terminal 40 accesses the URL of the list screen SC5 indicated by the link embedded in button B40. When the payment business operator server 10 accepts access from the user terminal 40, the process execution unit 103 generates display data for the list screen SC5 based on the payment service database DB. The process execution unit 103 executes the payment-related process by transmitting the display data for the list screen SC5 to the user terminal 40.

[0062] Note that payment-related processing may be a concept that encompasses payment processing for making a payment and charging processing for charging a payment source that is directly used in the payment. Charge processing is executed as preparation for invoice payment and is somehow related to the payment of the invoice, and therefore corresponds to payment-related processing. In this embodiment, the phrase "payment-related processing" (i.e., processing executed by the processing execution unit 103) simply refers to both payment processing and charge processing. Payment-related processing may also be processing other than payment processing and charge processing. For example, payment-related processing may be processing that uses a payment method in combination with payment.

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

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

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

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

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

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

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

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

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

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

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

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

[0075] [4. Processes performed by the bill payment system] Figure 6 is a diagram showing an example of the processing executed in the bill payment system 1. Figure 6 shows the processing for notification among the processing executed in the bill payment system 1. The processing in Figure 6 is executed by the control units 11 and 41 executing programs stored in the storage units 12 and 42, respectively.

[0076] As shown in FIG. 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 FIG. 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. The payment service provider server 10 determines whether the notification timing has arrived based on the reservation history information stored in the payment service database DB (S2). In S2, the payment service provider server 10 may determine whether the notification timing has arrived based on the reservation history information of all or part of the reservations for which payment has not been completed.

[0077] If it is determined in S2 that the notification timing has not arrived (S2: N), the process returns to S2. If it is determined in S2 that the notification timing has arrived (S2: Y), the payment service provider server 10 generates a notification including a button B40 with an embedded link to a list screen SC5 (S3). The payment service provider server 10 provides the notification generated in S3 based on the notification destination information stored in the payment service database DB (S4). In this embodiment, in S4, the payment service provider server 10 generates notification information and stores it in the payment service database DB. When the user launches the payment app, selects icon I11, and selects notification S4 from the list of notifications, the user terminal 40 displays a notification screen SC4 on the display unit 45 (S5). When the user selects button B40, the user terminal 40 transmits a request to access the list screen SC5 to the payment service provider server 10 based on the link embedded in button B40 (S6).

[0078] When the payment processor server 10 receives an access request from the user terminal 40 (S7), it generates display data for the list screen SC5 based on the payment service database DB (S8). For example, assume that the link of the button B40 includes the invoice ID of the payment that is the subject of the notification. The access request includes the invoice ID. In S8, 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 is issued as an ID for each reservation, the reservation whose reservation details are displayed on the list screen SC5 may be identified by the reservation ID. Furthermore, the reservation details related to the invoice ID of the payment that is the subject of the notification may be displayed directly from the invoice ID without going through the list screen SC5.

[0079] The payment provider server 10 transmits display data for the list screen SC5 to the user terminal 40 (S9). The series of processes from S7 to S9 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 (S10) and displays the list screen SC5 on the display unit 45 (S11). The user terminal 40 executes processing with the payment provider server 10 to allow the user to change the reservation details (S12), and this processing ends. In S12, 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.

[0080] [5. Summary of embodiments] The bill payment system 1 of this embodiment accepts reservations for bill payments. Before the payment timing arrives, the bill payment system 1 notifies the user that payment operations are available. When a payment operation is performed, the bill payment system 1 executes payment processing. This allows the user to perform payment operations from the notification, so the bill payment system 1 reduces the operational burden on the user and increases user convenience. For example, after checking the notification screen SC4, the user does not have to perform the cumbersome operation of returning to the top screen SC1 and displaying the list screen SC5; instead, the user can simply select the notification button B40 shown on the notification screen SC4, so the bill payment system 1 can reduce the operational burden on the user.

[0081] Furthermore, the bill payment system 1 executes a screen transition process to transition to the list screen SC5 as a payment-related process. This allows the bill payment system 1 to reduce the operational burden on the user for transitioning to the list screen SC5, thereby improving user convenience. Similarly, when executing a screen transition process to a screen other than the list screen SC5, the bill payment system 1 also reduces the operational burden on the user for transitioning to another screen, thereby improving user convenience.

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

[0083] 7 is a diagram showing an example of functions realized in the modified example. For example, the payment service provider server 10 includes a payment source information acquisition unit 104, a notification timing determination unit 105, a balance insufficiency determination unit 106, a reservation history information acquisition unit 107, a prediction unit 108, and an auto-charge setting determination unit 109. Each of the payment source information acquisition unit 104, the notification timing determination unit 105, the balance insufficiency determination unit 106, the reservation history information acquisition unit 107, the prediction unit 108, and the auto-charge setting determination unit 109 is realized by the control unit 11.

[0084] [6-1. Variation 1] For example, in the embodiment, the notification timing is a predetermined time before the payment timing. The notification timing is not limited to the example in the embodiment. For example, the appropriate notification timing may differ depending on the payment source used for the payment of the reservation made by the user. Therefore, in Modification 1, an example is given in which a notification regarding payment is made at a notification timing according to the payment source.

[0085] The bill payment system 1 of variant 1 includes a payment source information acquisition unit 104. The payment source information acquisition unit 104 acquires payment source information relating to payment sources used directly or indirectly in payment. For example, the payment source information acquisition unit 104 acquires payment source information from a payment service database DB. In the example embodiment, 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 104 acquires the payment source information by acquiring the reservation history information stored in the payment service database DB.

[0086] In the example embodiment, 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 104 acquires the payment source information by acquiring the reservation history information stored in the payment service database DB. If the reservation history information does not indicate information on the charging method, the payment source information acquisition unit 104 may acquire the payment source information by acquiring the charging method information stored in the payment service database DB.

[0087] The payment source information may be stored in a database other than the payment service database DB. The payment source information acquisition unit 104 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 104 may acquire the payment source information from another database or external information storage medium. The payment source information acquisition unit 104 may acquire all of the payment source information, or may acquire only part of the payment source information. The payment source information acquisition unit 104 only needs to acquire the payment source information of the payment for which the notification timing is to be determined.

[0088] The notification timing determination unit 105 determines the notification timing for notification, which is before the payment timing, based on the payment source information. For example, notification timing data in which the payment source information and notification timing information for the notification timing are associated is stored in the data storage unit 100. The notification timing data may be in any format, such as a table format, a mathematical formula format, a part of a program, a machine learning model, or another format. The notification timing determination unit 105 determines the notification timing based on the notification timing information associated with the payment source information acquired by the payment source information acquisition unit 104, based on the notification timing data.

[0089] For example, the notification timing information indicates the time difference between the payment timing and the notification timing. The time difference is how far in advance the notification timing is from the payment timing. The time difference can also be referred to as the time difference between the payment timing and the notification timing. Based on the notification timing data, the notification timing determination unit 105 identifies the time difference indicated by the notification timing information associated with the payment source information acquired by the payment source information acquisition unit 104, and determines the notification timing to be the timing that is the time difference before the payment timing.

[0090] For example, payment source information indicating a credit card or bank account that does not need to be recharged as the payment source may be associated with notification timing information that indicates a first time (e.g., the previous day) as the time difference. When the payment source information acquired by the payment source information acquisition unit 104 indicates a credit card or a bank account, the notification timing determination unit 105 identifies the first time as the time difference indicated by the notification timing information associated with the credit card or bank account based on the notification timing data, and determines the timing that is the first time before the payment timing (e.g., the day before the payment timing) as the notification timing.

[0091] For example, payment source information indicating electronic money that needs to be topped up as a payment source may be associated with notification timing information indicating a second time period (e.g., three days) longer than the first time period as a time difference to ensure a period for topping up. The difference between the first time period and the second time period may be any value. For example, the difference between the first time period and the second time period may be one day, several days, one week, or any other length of time. When the payment source information acquired by the payment source information acquisition unit 104 indicates electronic money, the notification timing determination unit 105 identifies the second time period as the time difference indicated by the notification timing information associated with the electronic money based on the notification timing data, and determines the second time period before the payment timing period (e.g., three days before the payment timing period) as the notification timing period.

[0092] The notification unit 102 of the first modification notifies the user based on the notification timing determined by the notification timing determination unit 105. Although the method of determining the notification timing differs from that of the embodiment, the process by which the notification unit 102 notifies when the notification timing arrives may be the same as that of the embodiment. For example, the notification timing determined by the notification timing determination unit 105 is stored in the payment service database DB or another database. The notification unit 102 may obtain the current date and time using a real-time clock, GPS, or the like, and determine whether the notification timing stored in the payment service database DB or another database has arrived.

[0093] The bill payment system 1 of Variation 1 determines the notification timing based on payment source information. The bill payment system 1 notifies the user based on the determined notification timing. This allows the bill payment system 1 to notify the user at an appropriate notification timing depending on the payment source, thereby further improving user convenience. For example, if the payment source is a credit card or bank account that does not need to be topped up, the bill payment system 1 can make the user aware that the payment time is approaching just before payment by setting the notification timing to be just before the payment time. If the payment source is electronic money that needs to be topped up, the bill payment system 1 can give the user time to top up by setting the notification timing to be a time that is some grace period from the payment time.

[0094] [6-2. Variation 2] For example, in variant 1, the notification timing determination unit 105 may determine the notification timing based on a deposit period according 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 to deposit until the deposit is completed, but the period from when the deposit, which is the source of funds for the deposit, is received from the administrator of the deposit means after the deposit is completed. The deposit period occurs when the administrator of the deposit means (the card company in variant 2) deposits money to the administrator of the directly used payment means (the payment service provider in variant 2) 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.

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

[0096] In the second modification, an example is given in which the payment source is a charging method indirectly used for payment. Therefore, the notification timing determination unit 105 determines the notification timing based on the deposit period corresponding to the charging method. For example, the data storage unit 100 stores data indicating the deposit period required for a card company to deposit funds into the payment service provider. The data storage unit 100 may also store data indicating the deposit period required for a business that handles payment methods other than credit cards to deposit funds into the payment service provider. The data storage unit 100 may also store data indicating the deposit period required for a payment service provider to deposit funds into the receiving organization.

[0097] The notification timing data of Modification 2 associates payment source information with notification timing information determined based on the deposit period corresponding to the payment source indicated by the payment source information. When the charge source corresponds to the payment source, the notification timing information indicates a time difference determined based on the deposit period corresponding to the charge source, so the notification timing determination unit 105 determines the timing that is before the payment timing by the time difference corresponding to the charge source as the notification timing.

[0098] For example, payment source information indicating a bank account with a relatively short deposit period as the payment source may be associated with notification timing information indicating a third time period (e.g., two days) corresponding to the deposit period as the time difference. When the payment source information acquired by the payment source information acquisition unit 104 indicates a bank account, the notification timing determination unit 105 identifies the third time period as the time difference indicated by the notification timing information associated with the bank account based on the notification timing data, and determines the timing that is the third time period before the payment timing (e.g., two days before the payment timing) as the notification timing.

[0099] For example, payment source information indicating a credit card with a relatively long deposit period as the payment source may be associated with notification timing information indicating a fourth time period (e.g., one week) corresponding to the deposit period as the time difference. When the payment source information acquired by the payment source information acquisition unit 104 indicates a credit card, the notification timing determination unit 105 identifies the fourth time period as the time difference indicated by the notification timing information associated with the credit card based on the notification timing data, and determines the timing that is the fourth time period before the payment timing (e.g., one week before the payment timing) as the notification timing.

[0100] In addition, in the second modification, the payment source may also be a directly used payment method. In this case, the notification timing information indicates a time difference determined based on the deposit period corresponding to the directly used payment method, and the notification timing determination unit 105 determines the notification timing to be a time that precedes the payment timing by the time difference determined based on the deposit period corresponding to the directly used payment method. For example, the notification timing determination unit 105 may determine the notification timing based on the deposit period from the credit card company to the payment service provider. For example, the notification timing determination unit 105 may propose the notification timing based on the deposit period from the bank to the payment service provider.

[0101] The bill payment system 1 of Variation 2 determines the timing of notification based on the payment period corresponding to the payment source. This allows the bill payment system 1 to notify the user at a notification timing appropriate for the payment period corresponding to the payment source, thereby further improving user convenience. The bill payment system 1 can also improve convenience for payment service providers. For example, if the payment source is a credit card, there may be a certain amount of time (e.g., one week) for the card company to deposit funds into the payment service provider. If the payment service provider deposits funds into the receiving organization before the card company deposits funds into the payment service provider, the payment service provider may run out of funds. In this regard, the bill payment system 1 can notify the user at a more flexible notification timing by notifying the user at a notification timing according to the payment period from the card company to the payment service provider.

[0102] Furthermore, the bill payment system 1 determines the timing of notification based on the deposit period corresponding to the charging method. This allows the bill payment system 1 to notify the user at a timing appropriate for the deposit period corresponding to the charging method, thereby further improving user convenience. For example, by notifying at a timing corresponding to the deposit period from the card company to the payment service provider, the bill payment system 1 can encourage the user to deposit funds earlier, making it easier to avoid a situation where the deposit from the card company to the payment service provider is delayed after the deposit from the payment service provider to the collection organization. As a result, the bill payment system 1 can prevent the payment service provider from running out of funds and improve convenience for the payment service provider.

[0103] [6-3. Variation 3] For example, in the embodiment, the list screen SC5 was described as a payment-related screen transitioned by the screen transition process. The payment-related screen is not limited to the list screen SC5. The payment-related screen may be any screen that is somehow related to payment. The processing execution unit 103 of the third modification executes screen transition processing to transition the payment-related screen to a charge screen for charging the directly used payment means that is directly used for payment.

[0104] FIG. 8 is a diagram showing an example of screen transitions in Modification Example 3. As shown in the upper left of FIG. 8, the general layout of the notification screen SC4 is the same as that in the upper left of FIG. 3. However, in the example in the upper left of FIG. 8, the button B41 on the notification screen SC4 includes a link to the charge screen SC6 in the upper right of FIG. 8, rather than a link to the list screen SC5. The message in the notification screen SC4 may also include content related to charging. For example, the notification screen SC4 may include information about checking the balance of electronic money, charging electronic money, making a reservation for charging electronic money, transitioning from the notification to the charge screen SC6, or other content.

[0105] For example, when a user selects button B41, user terminal 40 accesses the URL of charge screen SC6 indicated by the link embedded in button B41. When payment service provider server 10 accepts access from user terminal 40, processing execution unit 103 generates display data for charge screen SC6 based on payment service database DB. Processing execution unit 103 executes screen transition processing by transmitting the display data for charge screen SC6 to user terminal 40.

[0106] For example, when a user performs an operation to charge on the spot from the charge screen SC6, the payment service provider server 10 charges the electronic money. The charging of electronic money may be performed by a known process. When a user performs an operation to reserve a charge from the charge screen SC6, the payment service provider server 10 reserves the charge of electronic money. The payment service provider server 10 updates the user's reservation history information to indicate the charge reservation details specified by the user. When the charge timing specified by the user arrives, the payment service provider server 10 charges the electronic money based on conditions such as the charge amount specified by the user.

[0107] The payment-related screens are not limited to the list screen SC5 and the charge screen SC6. For example, when a notification of a payment that occurs periodically, such as a utility bill or tax, is made, the photographing screen SC2 for photographing (scanning) the invoice may correspond to the payment-related screen. The processing execution unit 103 may execute screen transition processing to transition the payment-related screen to the photographing screen SC2 for photographing the invoice for a periodically occurring payment. In addition, for example, the processing execution unit 103 may execute screen transition processing to transition the payment-related screen to a cancellation screen for canceling a scheduled payment.

[0108] The bill payment system 1 of Variation 3 executes a screen transition process that transitions to the charge screen SC6 as the payment-related screen. This allows the bill payment system 1 to reduce the operational burden on the user for transitioning to the charge screen SC6 and improve user convenience. For example, after checking the notification screen SC4, the user can display the charge screen SC6 by selecting the notification button B41 shown on the notification screen SC4, without having to perform the cumbersome operation of returning to the top screen SC1 to display the charge screen SC6. This allows the bill payment system 1 to reduce the operational burden on the user.

[0109] [6-4. Variation 4] For example, in the embodiment and variants 1 and 2, the case where the notification timing is determined based on the payment timing has been described. The notification timing does not have to be determined based on the payment timing. For example, a notification may be given in advance when the balance of the directly used payment instrument is insufficient. Furthermore, if multiple payments are scheduled for a certain payment timing, a notification may be given in advance when the balance is insufficient to cover the total amount of the multiple payments.

[0110] The bill payment system 1 of Variation 4 includes a balance insufficiency determination unit 106. When multiple payments are scheduled for a payment timing, the balance insufficiency determination unit 106 determines whether the balance of the directly used payment means directly used for each of the multiple payments is insufficient, based on the total payment amount for each of the multiple payments. For example, the balance insufficiency determination unit 106 identifies multiple payments scheduled by a user for a certain payment timing (e.g., a certain day) based on the reservation history information stored in the payment service database DB. The balance insufficiency determination unit 106 obtains the payment amount for each of the multiple payments based on the reservation history information, and calculates the total of the obtained payment amounts.

[0111] For example, the balance insufficiency determination unit 106 refers to the payment service database DB or another database to obtain the balance of electronic money. For example, if electronic money and points can be used in combination, the balance insufficiency determination unit 106 may obtain the total amount of the electronic money balance and the point balance as the balance of the directly used payment method. The electronic money balance and the point balance may each be stored in the payment service database DB or another database. The balance insufficiency determination unit 106 may obtain the electronic money balance and the point balance from the payment service database DB or another database. The balance insufficiency determination unit 106 determines whether the balance is insufficient based on the calculated total amount.

[0112] For example, the balance insufficiency determination unit 106 may determine that the balance is not insufficient if the total payment amount is less than the balance of electronic money, and may determine that the balance is insufficient if the total payment amount is more than the balance of electronic money. If the balance of electronic money after payment is to have some margin, the balance insufficiency determination unit 106 may determine that the balance is not insufficient if the value obtained by subtracting the total payment amount from the balance of electronic money is more than a threshold value (for example, any value greater than 1), and may determine that the balance is insufficient if the value is less than the threshold value.

[0113] FIG. 9 is a diagram illustrating an example of a balance shortage notification. When the notification unit 102 of the fourth modification example determines that the balance is insufficient, the notification unit 102 sends a balance shortage notification to the user as a payment notification. The balance shortage notification includes a message or image indicating that the balance is insufficient. Similar to the template data of the embodiment, the template data for the balance shortage notification is also stored in the data storage unit 100. The notification unit 102 inserts the amount of the shortage into the template indicated by the template data for the balance shortage notification. The notification unit 102 may include a button B41 embedded with a link to a charge screen SC6 in the notification. The notification unit 102 sends the notification generated as described above to the user. In this case, a notification screen SC4 as shown in the upper left of FIG. 9 is displayed on the user terminal 40. When the user selects the button B41, the user terminal 40 displays the charge screen SC6 indicated by the link embedded in the button B41 as shown in the upper right of FIG. 9. The notification unit 102 may send, as the notification regarding the payment, a notification including a button B41 in which a link to a screen for checking the balance of electronic money is embedded, instead of the charge screen SC6.

[0114] The notification unit 102 may not provide the user with a link to the charge screen SC6, but may provide a balance shortage notification including a button B41 that allows the user to instruct a charge without any particular screen transition. In this case, when the user selects the button B41, the user terminal 40 sends a charge execution request to the payment service provider server 10 to request that a charge be executed. The balance shortage notification may also accept input of conditions such as the charge amount. The conditions entered by the user are included in the charge execution request. Upon receiving the charge execution request, the payment service provider server 10 may execute the charge. If the charge execution request includes charge conditions, the payment service provider server 10 executes the charge based on those conditions. If the charge execution request does not include charge conditions, the payment service provider server 10 may execute the charge based on conditions specified in advance by the user.

[0115] The notification unit 102 may also provide a balance shortage notification that includes a button that allows the user to charge electronic money by the difference between the payment amount and the balance, or by more than the difference. For example, the notification unit 102 may provide a balance shortage notification that includes a button B41 that reads, "Your electronic money is 3,000 yen short. Would you like to charge 3,000 yen?" When the user selects the button B41, the payment service provider server 10 charges 3,000 yen. This allows the user to complete the charge without switching to a charge screen, improving user convenience.

[0116] As another example, the notification unit 102 may issue a balance shortage notification that includes a button B41 for auto-charge. For example, the notification unit 102 may issue a balance shortage notification that includes a button B41 that reads, "You don't have enough electronic money. Would you like to auto-charge?" When the user selects the button B41, the payment service provider server 10 sets up auto-charge. The payment service provider server 10 executes auto-charge based on the auto-charge settings. This allows the user to execute auto-charge without having to switch to a screen for setting up auto-charge, thereby improving user convenience. For example, the payment service provider server 10 may auto-charge the shortfall when there is a shortage of electronic money at the time of payment.

[0117] The balance insufficiency determination unit 106 may perform the same determination whether the directly used payment means for each of the multiple invoices is different or the directly used payment means for each of the multiple invoices is the same. For example, suppose four payments A to D are scheduled for the same payment timing. The directly used payment means for payment A is electronic money, the directly used payment means for payment B is electronic money, the directly used payment means for payment C is points, and the directly used payment means for payment D are points and electronic money. However, points are prioritized for payment D. In this case, the balance insufficiency determination unit 106 may determine the insufficient balance of electronic money based on the total amount of payments A and B, and may determine the insufficient balance of points based on the total amount of payments C and D. In other words, when the directly used payment means are the same or partially the same, the balance insufficiency determination unit 106 may compare the total payment amount with the balance of the directly used payment means.

[0118] In the bill payment system 1 of Variation 4, when multiple payments are scheduled for a payment timing, the bill payment system 1 determines whether the balance of the directly used payment means is insufficient based on the total payment amount for each of the multiple payments. If the bill payment system 1 determines that the balance is insufficient, it sends a balance insufficiency notification to the user as a notification regarding the payment. This allows the bill payment system 1 to inform the user that the balance of the directly used payment means is insufficient, thereby improving user convenience.

[0119] [6-5. Variation 5] For example, in the fourth modification, when it is determined that the balance of electronic money is insufficient, a notification of the insufficient balance is given to the user. The notification when it is determined that the balance of electronic money is insufficient is not limited to a notification of the insufficient balance. In the fifth modification, an example will be described in which a charge notification is given when it is determined that the balance of electronic money is insufficient.

[0120] The bill payment system 1 of the fifth modification includes a balance insufficiency determination unit 106. The balance insufficiency determination unit 106 may be the same as in the fourth modification, but in the fifth modification, there may be only one payment reserved for a certain payment timing. The balance insufficiency determination unit 106 determines whether the balance of the directly used payment means directly used for the payment is insufficient based on the payment amount related to the payment. The balance insufficiency determination unit 106 identifies a payment reserved by a certain user for a certain payment timing (for example, a certain day) based on the reservation history information stored in the payment service database DB. The balance insufficiency determination unit 106 may determine whether the balance is insufficient based on the payment amount of the identified payment based on the reservation history information. The method of obtaining the balance is as described in the fourth modification.

[0121] FIG. 10 is a diagram showing an example of a charge notification. When it is determined that the balance is insufficient, the notification unit 102 of Modification 5 sends a charge notification to the user as a payment notification that a charge operation for charging the directly used payment means can be accepted as an operation. The charge operation may be an operation for transitioning to a charge screen SC6 for charging, but Modification 5 takes as an example a case where the charge operation is an operation for instructing the charge itself. In the example of FIG. 10, the charge operation is an operation for accepting input of conditions such as the charge amount and instructing the payment service provider server 10 to charge.

[0122] In the example of Fig. 10, the notification screen SC4 includes an input form F41 for accepting input of conditions such as the charge amount, and a button B42 for instructing execution of the charge. The user inputs conditions such as the charge amount into the input form F41 and then selects the button B42. The user terminal 40 transmits a charge execution request including the conditions entered into the input form F41 to the payment service provider server 10. The payment service provider server 10 receives the charge execution request.

[0123] When a charge operation is performed, the processing execution unit 103 of the fifth modification executes a charge process related to charging as a payment-related process. The charge process is as described in the embodiment. The charge process of the fifth modification may be a process for displaying the charge screen SC6. For example, the processing execution unit 103 executes a charge based on a charge execution request using the charge means indicated in the charge means information stored in the payment service database DB as a source of funds. If the user is allowed to specify the charge means from the notification screen SC4, the charge means specified by the user is assumed to be indicated in the charge execution request. The processing execution unit 103 may execute a charge based on the charge execution request using the charge means indicated in the charge execution request as a source of funds.

[0124] When the bill payment system 1 of Variation 5 determines that the balance of a directly used payment means is insufficient, it sends a charge notification to the user as a payment notification that allows the user to accept a charge operation to charge the directly used payment means. The bill payment system 1 can reduce the operational burden on the user when the balance of a directly used payment means is insufficient. For example, after checking the notification screen SC4, the user does not have to perform the complicated operation of returning to the top screen SC1 and displaying the charge screen SC6. Instead, the user can simply enter conditions such as the charge amount in the notification input form F41 shown on the notification screen SC4 and select button B42, thereby reducing the operational burden on the user.

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

[0126] The bill payment system 1 of the sixth 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 reservations. In the sixth variant, the reservation history information indicates the acceptance timing of a 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. A user can make a reservation at any acceptance timing. However, if a payment deadline is set on the invoice, the user will, in principle, make a reservation at an acceptance timing up to the payment deadline.

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

[0128] 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 102, which will be described later.

[0129] 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 between the payment timings of multiple past reservations 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 102 obtains the predicted payment timing for each user from the payment service database DB or another database.

[0130] FIG. 11 is a diagram showing an example of a notification in Modification 6. The notification unit 102 in Modification 6 provides a notification before the payment timing predicted by the prediction unit 108 arrives. In the example of FIG. 11, the notification unit 102 provides a notification to the user using a notification function on the payment app. For example, the notification unit 102 acquires the current date and time using a real-time clock or GPS and determines whether the reservation time predicted 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 102 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 102 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 102 provides a notification to the user.

[0131] 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 102 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 11, the notification unit 102 inserts information such as the payee and payment amount of the past recurring payment into the template.

[0132] For example, the notification unit 102 generates a link to the shooting screen SC2 and inserts a button B43 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 102 may identify the link to be embedded in the button B43 based on the data. The notification unit 102 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 B43. The notification unit 102 displays a notification screen SC4 indicating the notification generated as described above to the user.

[0133] The method by which the notification unit 102 notifies the user is not limited to the above example. The notification unit 102 may notify the user by a method appropriate to the notification means. For example, if email is used for the notification, the notification unit 102 may send email as a notification to the user's email address indicated by the notification destination information. The notification unit 102 may generate the email in the same manner as notifications sent on the payment app. For example, the notification unit 102 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.

[0134] For example, when SMS is used for notification, the notification unit 102 may send an SMS message as notification to the user's telephone number indicated by the notification destination information. The notification unit 102 may generate the SMS message in the same manner as email. For example, the notification unit 102 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.

[0135] For example, when a message app is used for notification, the notification unit 102 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 102 may generate a message of the message app in the same manner as an email. For example, the notification unit 102 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 102 may notify the user in a manner appropriate to the other notification means.

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

[0137] [6-7. Variation 7] For example, if the user has set up auto-charge, there is a high possibility that the balance for payment will be secured by auto-charge, so the user may not be notified or may be notified infrequently. On the other hand, if the user has not set up auto-charge, there is a possibility that the balance for payment will be insufficient, so the user may be notified or may be notified somewhat frequently.

[0138] The bill payment system 1 of Variation 7 includes an auto-charge setting determination unit 109. The auto-charge setting determination unit 109 determines whether an auto-charge setting has been made for the auto-charge of a directly used payment method that is directly used for payment. The auto-charge setting can also be considered a condition for auto-charge. For example, the auto-charge setting may be the charge timing for auto-charge, the charge amount, charge method information, or other settings. If auto-charge is to be made when a certain balance falls below a threshold, the auto-charge setting may indicate that threshold.

[0139] For example, the auto-charge setting determination unit 109 determines whether or not an auto-charge setting has been made based on the reservation history information stored in the payment service database DB. The auto-charge setting may be stored in a database other than the payment service database DB. In this case, the auto-charge setting determination unit 109 may determine whether or not an auto-charge setting has been made based on the other database. The auto-charge setting may be made for each invoice reservation, or may be made regardless of any particular invoice reservation.

[0140] The notification unit 102 of the seventh modification notifies the user about the payment based on the determination result of the auto-charge setting determination unit 109. For example, if it is determined that the auto-charge setting is enabled, the notification unit 102 does not notify the user, and if it is determined that the auto-charge setting is not enabled, the notification unit 102 notifies the user. The notification unit 102 may determine the frequency of notifications to the user based on the determination result of the auto-charge setting determination unit 109. For example, if it is determined that the auto-charge setting is not enabled, the notification unit 102 may notify the user more frequently than if it is determined that the auto-charge setting is enabled. If it is determined that the auto-charge setting is not enabled, the notification unit 102 may notify the user more frequently than if it is determined that the auto-charge setting is enabled.

[0141] The bill payment system 1 of variant 7 notifies the user about payment based on the result of determining whether auto-charge settings have been made for auto-charge of the directly used payment method. By making a notification according to the result of the determination, the bill payment system 1 can further improve user convenience. For example, since a user who has set up auto-charge may not need a notification, the bill payment system 1 can prevent such users from receiving a notification, thereby improving user convenience. Since a user who has set up auto-charge may need a notification, the bill payment system 1 can improve user convenience by notifying such users.

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

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

[0144] [7. Notes] For example, a bill payment system can be configured as follows: (1) a notification unit that notifies a user before a payment timing for a bill arrives that an operation related to the payment is available; a processing execution unit that executes processing related to the payment when the operation is performed; Bill payment system including. (2) The bill payment system comprises: a payment source information acquisition unit that acquires payment source information regarding a payment source that is directly or indirectly used in the payment; a notification timing determination unit that determines a notification timing regarding the notification based on the payment source information, the notification timing being before the payment timing arrives; Further comprising: The notification unit notifies the user based on the notification timing. (1) A bill payment system as described in (1). (3) The notification timing determination unit determines the notification timing based on a payment period corresponding to the payment source. (2) A bill payment system as described in (2). (4) The payment source is a charging means for charging a directly used payment means that is directly used in the payment, and is a charging means that is indirectly used in the payment, the notification timing determination unit determines the notification timing based on the deposit period corresponding to the charging means. (3) A bill payment system as described in (3). (5) the processing execution unit executes, as the processing, a screen transition process for transitioning to a payment-related screen regarding the payment. A bill payment system according to any one of (1) to (4). (6) the processing execution unit executes the screen transition processing to transition the payment-related screen to a charge screen for charging a directly used payment means that is directly used for the payment. (5) A bill payment system as described in (5). (7) The bill payment system further includes a balance insufficiency determination unit that, when multiple payments are scheduled for the payment timing, determines whether the balance of the directly used payment means directly used for each of the multiple payments is insufficient based on the total payment amount for each of the multiple payments, When it is determined that the balance is insufficient, the notification unit issues a balance insufficiency notification regarding the insufficient balance to the user as the notification. A bill payment system according to any one of (1) to (6). (8) The bill payment system further includes a balance insufficiency determination unit that determines whether the balance of the directly used payment means directly used for the payment is insufficient based on the payment amount related to the payment, when it is determined that the balance is insufficient, the notification unit issues a charge notification to the user, as the notification, indicating that a charge operation for charging the directly used payment means can be accepted as the operation; the processing execution unit executes, as the processing, a charging process related to the charging when the charging operation is performed; A bill payment system according to any one of (1) to (7). (9) The bill payment system comprises: a reservation history information acquisition unit that acquires reservation history information relating to the history of reservations related to the payment; 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 (8). (10) The bill payment system further includes an auto-charge setting determination unit that determines whether auto-charge settings are configured for auto-charge of the directly used payment method that is directly used for the payment, The notification unit notifies the user based on the determination result of the auto-charge setting determination unit. A bill payment system according to any one of (1) to (9). [Explanation of symbols]

[0145] 1 bill payment system, 10 payment service provider server, 11, 21, 31, 41 control unit, 12, 22, 32, 42 memory unit, 13, 23, 33, 43 communication unit, 20 card company server, 30 collection organization server, 40 user terminal, 44 operation unit, 45 display unit, 46 photography unit, N network, DB payment service database, 100, 200, 300, 400 data storage unit, 101 reservation reception unit, 102 notification unit, 103 processing execution unit, 104 payment source information acquisition unit, 105 notification timing determination unit, 106 balance insufficiency determination unit, 107 reservation history information acquisition unit, 108 prediction unit, 109 auto-charge setting determination unit, 201 service provision unit, 301 collection unit, 401 operation reception unit, 402 Display control section, B10, B30, B31, B40, B41, B42, B43, B50 buttons, F41 input form, I11 icon, SC1 top screen, SC2 shooting screen, SC3 reservation screen, SC4 notification screen, SC5 list screen, SC6 charge screen.

Claims

1. A payment source information acquisition unit that acquires payment source information regarding payment sources that are used directly or indirectly to pay invoices reserved by a user; a notification timing determination unit that identifies the payment timing based on reservation history information indicating the payment timing related to the payment, and determines the notification timing before the payment timing arrives based on notification timing data in which the payment source information and notification timing information related to the notification timing when the operation related to the payment can be accepted are associated; a notification unit that notifies the user based on the notification timing; a processing execution unit that executes processing related to the payment when the operation is performed; Bill payment system including.

2. the notification timing determination unit determines the notification timing based on the notification timing data associated with the notification timing information determined based on a deposit period corresponding to the payment source; 10. The bill payment system of claim 1.

3. A charging means for charging a directly used payment means that is directly used in paying an invoice reserved by a user, the charging means comprising: a charging means information acquisition unit that acquires charging means information regarding the charging means that is indirectly used in the payment; a notification timing determination unit that determines the timing of payment based on reservation history information indicating the timing of payment, and determines the timing of notification regarding a notification at which an operation regarding the payment can be accepted based on a deposit period corresponding to the charging means indicated by the charging means information, the notification timing being before the timing of payment; a notification unit that notifies the user based on the notification timing; a processing execution unit that executes processing related to the payment when the operation is performed; Bill payment system including.

4. A notification unit that identifies the timing of payment based on reservation history information indicating the timing of payment of an invoice reserved by a user, and notifies the user before the timing of payment that the payment is approaching, the notification being capable of accepting an operation to change the reservation details of the invoice; a processing execution unit that executes processing to change the reservation content when the operation is performed; Bill payment system including.

5. A notification unit that identifies the timing of payment for an invoice reserved by a user based on reservation history information indicating the timing of payment for the invoice, and notifies the user before the timing of payment that the user can accept an operation for the payment; a processing execution unit that, when the operation is performed, executes a screen transition process to transition to the screen showing the details of the payment reservation, the screen for changing the details of the payment reservation, the screen for canceling the payment reservation, or the screen for photographing the invoice by transmitting display data of the screen to the user terminal of the user; Bill payment system including.

6. A balance deficiency determination unit that identifies the payment timing for an invoice reserved by a user based on reservation history information indicating the payment timing for the payment, and if multiple payments are reserved for the payment timing before the payment timing arrives, determines whether the balance of the directly used payment means directly used for each of the multiple payments is insufficient based on the total payment amount for each of the multiple payments; a notification unit that, when it is determined that the balance is insufficient before the payment timing arrives, issues a balance insufficiency notification to the user regarding the insufficient balance as a notification that an operation regarding the payment can be accepted; a processing execution unit that executes processing related to the payment when the operation is performed; Bill payment system including.

7. The bill payment system further includes a balance insufficiency determination unit that determines whether the balance of the directly used payment means directly used for the payment is insufficient based on the payment amount related to the payment, when it is determined that the balance is insufficient, the notification unit issues a charge notification to the user, as the notification, indicating that a charge operation for charging the directly used payment means can be accepted as the operation; the processing execution unit executes a charging process related to the charging when the charging operation is performed. A bill payment system according to any one of claims 1 to 6.

8. A reservation history information acquisition unit that acquires reservation history information indicating payment timings for invoices reserved by a 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; a notification unit that notifies a user that an operation related to the payment can be accepted before the payment timing predicted by the prediction unit arrives; a processing execution unit that executes processing related to the payment when the operation is performed; Bill payment system including.

9. An auto-charge setting determination unit that determines whether or not auto-charge settings have been made for auto-charge of a directly used payment method that is directly used to pay an invoice reserved by a user; a notification unit that identifies the timing of payment based on reservation history information indicating the timing of payment, and determines the frequency of notifications that allow operations related to the payment to be accepted based on the determination result of the auto-charge setting determination unit before the timing of payment arrives, and notifies the user based on the frequency; a processing execution unit that executes processing related to the payment when the operation is performed; Bill payment system including.

10. A computer comprising: a payment source information acquisition step of acquiring payment source information regarding a payment source that is used directly or indirectly to pay an invoice reserved by the user; a notification timing determination step of identifying the payment timing based on reservation history information indicating the payment timing regarding the payment, and determining the notification timing before the payment timing arrives based on notification timing data in which the payment source information and notification timing information regarding the notification timing at which the operation regarding the payment can be accepted are associated; a notification step of notifying the user based on the notification timing; a processing execution step of executing processing related to the payment when the operation is performed; Bill payment methods to perform.

11. A computer comprising: a notification step of identifying the timing of payment for an invoice reserved by a user based on reservation history information indicating the timing of payment for the invoice, and notifying the user before the timing of payment that the user is ready to accept an operation for the payment; a processing execution step of executing a screen transition process to transition to a screen showing the details of the payment reservation, a screen for changing the details of the payment reservation, a screen for canceling the payment reservation, or a screen for photographing the invoice, by transmitting display data of the screen to the user terminal of the user when the operation is performed; Bill payment methods to perform.

12. A payment source information acquisition unit that acquires payment source information regarding payment sources that are used directly or indirectly to pay invoices reserved by a user; a notification timing determination unit that identifies the payment timing based on reservation history information indicating the payment timing regarding the payment, and determines the notification timing before the payment timing arrives based on notification timing data in which the payment source information and notification timing information regarding the notification timing at which the operation regarding the payment can be accepted are associated; a notification unit that notifies the user based on the notification timing; a processing execution unit that executes processing related to the payment when the operation is performed; A program that allows a computer to function as a

13. A notification unit that identifies the timing of payment for an invoice reserved by a user based on reservation history information indicating the timing of payment for the invoice, and notifies the user before the timing of payment that the user can accept an operation for the payment; a processing execution unit that, when the operation is performed, executes a screen transition process to transition to the screen by transmitting display data of a screen showing the details of the payment reservation, a screen for changing the details of the payment reservation, a screen for canceling the payment reservation, or a screen for photographing the invoice to the user terminal of the user; A program that allows a computer to function as a

Images