System for handling non-payments in recurring payments

Abstract

To make it possible to fairly impose a burden of a collection cost on a customer at the time of non-payment, and to generate an incentive for a customer to avoid non-payment.SOLUTION: If a given customer does not make a payment by a given payment due date and such non-payment is recorded in a payment status file 12, an accident information output program 42 constituting an accident information output means refers to a customer information file 11, and does not output accident information if a non-payment option contract has been made with the customer, but outputs accident information if the non-payment option contract has not been made therewith. If accident information was not output because the non-payment option contract has been made, an option-use output program 51 constituting an option-use output means outputs, to a customer terminal, option-use information, which is information indicating that the benefit of the non-payment option contract has been applied, or outputs the option-use information to a printer that prints same on paper to be sent to the customer.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] The invention of this application relates to a system used when a recipient of a fee responds to non-payment of a fee in a periodic payment contract where a fee is paid at regular intervals.

Background Art

[0002] When purchasing services or goods, a periodic payment contract for paying a fee at regular intervals is often concluded. For example, in various communication services such as mobile phones and providers, a monthly fee is determined, and the service is provided by paying this fee. In fitness clubs and other membership services, membership services are provided by paying a monthly membership fee. Even in product sales, a delivery method of regularly delivering products by paying a fixed fee every month is often adopted, and it is abbreviated as "subscription". Also, in the field of installment sales, payments are made by installment, such as by credit card, lease fee, various repayment payments, etc. Furthermore, for real estate rentals and payment of certain royalty fees, etc., a periodic payment method is adopted.

[0003] In the case where such a periodic payment contract is made, a customer (broadly referring to a person who pays a periodic payment fee in this specification) is required to pay the fee on a fixed date, but there may be cases where the payment is not made due to some reason. The reason may be simply forgetting, or in the case of automatic debit from a bank account, not noticing insufficient balance.

[0004] In any case, if the payment is not made on a certain date, the recipient (broadly referring to a person on the receiving side of the fee in a periodic payment contract in this specification) takes some measures. When the periodic payment contract relates to the provision of a membership service, the recipient is the business entity providing the membership service, but if the payment is not made, a measure of stopping the provision of the membership service is taken. In the field of installment sales, the person may be put on a defaulter list (so-called blacklist), or a claim for late damages may be made according to the contract. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2020-38467 [Patent Document 2] Japanese Patent Publication No. 2018-45300 [Overview of the project] [Problems that the invention aims to solve]

[0006] If those who defaulted on payments subsequently make payments as a result of the measures described above, the debt will be recovered and there will be no loss. However, the internal costs (effort) incurred by implementing these measures remain. The regular payment fee is determined and contracted based on these costs, but it can be argued that this is unfair as even those who do not default on payments bear these costs. To account for the recovery costs associated with such non-payments, recipients sometimes take out a type of insurance. The insurance company calculates the risk of non-payment, and the recipient pays a premium to the insurance company based on that calculation. If non-payment actually occurs, the insurance company pays the predetermined insurance amount to the recipient. However, even in this case, the premium is included in the overall cost of the regular payments, and the unfairness remains that even those who do not default bear this cost. The present invention was made with this problem in mind, and aims to provide a technology that makes it possible to fairly distribute the collection costs in the event of non-payment to the customer, and also creates an incentive for customers to avoid non-payment.

[0007] Furthermore, the applicant of this application has disclosed an invention for a guarantee and compensation system for periodic payments in Patent Document 1. The problem addressed by the present invention differs from that of the invention in Patent Document 1 in the following respects. First, Patent Document 1 discloses a system in which there is a recipient and a compensation provider, and the compensation provider pays compensation to the recipient in the event of non-payment, with the compensation fee paid by the customer being received by the compensation provider. The recipient receives compensation for the first non-payment if there are two consecutive non-payments, but the compensation is for the fee of a single non-payment and is not intended to cover the overall recovery cost of non-payments. In industries where non-payments occur regularly, even if only a few percent of the total number of customers, it is necessary to always secure (pool) a certain amount of funds to cover the recovery costs in the event of non-payment, and the technology of Patent Document 1 is not suitable for such industries. This invention also aims to address this issue, and aims to provide a technology that makes it possible to prepare for the costs that may arise in the event of non-payment. [Means for solving the problem]

[0008] To solve the above problems, this specification discloses an invention of a non-payment response system. The non-payment response system according to the disclosed invention is a non-payment response system used when taking action when a fee is not paid on the due date, in a periodic payment contract entered into between a customer and a recipient, in which a fee is paid at predetermined intervals and measures are taken in the event of non-payment. Memory unit and, Accident information output means, Option usage output means and It is equipped with. The memory unit stores a customer information file containing information about each customer with whom a recurring payment contract has been concluded, and a payment status file containing records of each customer's payment status on each payment due date. The customer information file records whether a non-payment option agreement was entered into with the recipient for each customer, on the condition that the option fee is paid to the recipient. A non-payment option agreement is a contract that stipulates that if a regular payment is not made on a certain payment due date, measures will be taken at a predetermined time if there is no non-payment option agreement, whereas if there is a non-payment option agreement, measures will be taken at a grace period before the predetermined time, or measures that are more favorable to the customer than those taken if there is no non-payment option agreement. The accident information output means is a means for outputting information as accident information that is necessary to take action at a predetermined time or information that is unfavorable to the customer compared to when there is a non-payment option contract. The accident information output means, when a customer fails to make a payment on a certain payment due date and that non-payment is recorded in the payment status file, refers to the customer information file and, if a non-payment option agreement has been concluded for that customer, does not output accident information, but outputs accident information if a non-payment option agreement has not been concluded. The option usage output means is a means of outputting option usage information, which is information indicating that the benefits of the non-payment option agreement have been used, when a customer fails to make a payment on a certain payment due date and incident information is not output because a non-payment option agreement has been concluded for that customer. The option usage output means is a means for outputting option usage information along with information that can identify the customer related to the option usage information. Furthermore, in order to solve the above problems, the disclosed non-payment handling system is: The information regarding whether a non-payment option agreement exists is information about the date the non-payment option agreement was concluded and the date it was terminated. The accident information output means is a program that determines that a non-payment option agreement exists if the date the non-payment option agreement was concluded is recorded but the termination date is not recorded, and determines that a non-payment option agreement does not exist if the date the non-payment option agreement was concluded is not recorded, or if the date the non-payment option agreement was concluded and the termination date of the said non-payment option agreement is also recorded. It can have this kind of structure. Furthermore, in order to solve the above problems, the disclosed non-payment handling system is: The memory unit stores an option contract history information file that records the history of unpaid option contracts for each customer. This option contract history information file contains information about the date of conclusion and termination of unpaid option contracts that the recipient has concluded with each customer. It can have this kind of structure. Furthermore, in order to solve the above problems, the disclosed non-payment handling system is: The customer information file contains information regarding whether a non-payment option agreement is valid or invalid for customers with whom a non-payment option agreement has been concluded with the recipient. The option usage output means is a means for outputting option usage information to a customer information file, and is a means for recording in the customer information file that the effect of the unpaid option contract for that customer is invalid. After the option usage output means outputs option usage information, when the non-payment that caused the output of said option usage information is repaid, an option validity restoration means is provided in the customer information file to restore the validity of the non-payment option contract for that customer. The accident information output means, when a customer fails to make a payment on a certain payment due date and that non-payment is recorded in the payment status file, refers to the customer information file and does not output accident information if a non-payment option agreement has been concluded and is valid for that customer, but outputs accident information if no non-payment option agreement has been concluded or if it has been concluded but is invalid. The option usage output means is a means of outputting option usage information, which is information indicating that the benefits of a non-payment option agreement have been used, when a customer fails to make a payment on a certain payment due date and a non-payment option agreement has been concluded and is valid for that customer, and therefore no incident information is output. It can have this kind of structure. Furthermore, in order to solve the above problems, the non-payment response system relating to the disclosed invention is The option reactivation measure is a measure that is executed by the next payment due date if repayment is made by the next payment due date following the non-payment due date that caused the output of the option usage information. It can have this kind of structure. Furthermore, in order to solve the above problems, in the non-payment response system according to the disclosed invention, the option usage output means may be a means for outputting option usage information to a customer terminal which is a terminal operated by the customer, or a means for outputting option usage information to a printer which prints the option usage information on paper sent to the customer. Furthermore, in order to solve the above problems, the non-payment response system relating to the disclosed invention is The memory unit stores an option usage history information file that records the history of option usage information for each customer. The option usage output means is a means for recording option usage information for the customer in question in an option usage history information file. It can have this kind of structure. Furthermore, in order to solve the above problems, the non-payment response system according to the disclosed invention may be provided with an option fee modification means that modifies the option fee according to the history of option usage recorded in the option usage history information file. [Effects of the Invention]

[0009] As explained below, the non-payment handling system related to the disclosed invention provides customers with peace of mind knowing that, even if non-payment occurs for any reason, a single instance of non-payment will not trigger a default notification, provided they pay an optional fee to enter into a non-payment option contract. On the other hand, for the recipient, there is a risk that non-payment will occur again at the next payment due date, making it impossible to collect the debt completely. While the recipient cannot take appropriate measures regarding non-payment in a timely manner or with appropriate content, they receive an optional fee as compensation for this. Therefore, they can earn additional income that is commensurate with the overall debt collection costs, allowing them to confidently conduct their periodic payment contract business. Furthermore, for customers, the availability and option to choose and use the non-payment option service improves the impression of the recipient's business and leads to increased sales. In addition, since the optional fee is borne only by customers who are aware that they are likely to default, it ensures a fair cost burden. Furthermore, if the option usage information is output along with information that can identify the customer involved in that usage, the option usage information can be used and optimized for various purposes. Furthermore, if the option usage output means is a means of recording in the customer information file that an unpaid option contract has been temporarily invalidated, and an option revival means is provided to record that the unpaid option contract for the customer has been reinstated after the unpaid amount that caused the output of the option usage information has been repaid, then an incentive will be created for the customer to repay the unpaid amount as soon as possible, and the early recovery of the unpaid amount can be expected. In this case, if the outstanding amount is repaid by the next payment due date following the defaulted payment due date, the option reinstatement mechanism is executed by that next payment due date. This configuration is preferable because even if a payment is defaulted once, if it is repaid by the next payment due date, the benefits of the default option contract can be obtained again on the next payment due date. This further incentivizes early repayment of outstanding amounts. In addition, when the option usage output means is a means for outputting option usage information to a customer terminal which is a terminal operated by the customer, or a means for outputting option usage information to a printing machine that prints on paper sent to the customer, it is possible to notify the customer that a non-payment option is being used. Therefore, in this regard, the probability of early repayment of non-payment amounts increases. Also, according to a configuration in which the option usage output means is a means for recording option usage information in an option usage history information file for the customer, it is possible to effectively utilize the information on the usage history of non-payment options. At this time, according to a configuration in which option fee change means for changing the option fee according to the option usage history recorded in the option usage history information file is provided, the option fee is changed according to the amount of use of non-payment options. Therefore, the burden of the option fee for each customer becomes fairer.

Brief Description of Drawings

[0010] [Figure 1] It is a schematic diagram of a non-payment response system according to the first embodiment. [Figure 2] It is a schematic diagram showing an example of a more specific configuration of the non-payment response system shown in FIG. 1. [Figure 3] It is a schematic diagram showing an example of the structure of a customer information file. [Figure 4] It is a schematic diagram showing an example of the structure of a payment status file for a certain payment due date. [Figure 5] It is a flowchart showing an outline of a payment monitoring program. [Figure 6] It is a flowchart showing an outline of a repayment recording program. [Figure 7] It is a schematic diagram showing an example of a customer registration page provided by a management server. [Figure 8] It is a schematic diagram showing an example of the structure of an option usage history information file. [Figure 9]This is a flowchart illustrating the outline of the option usage output program in the second embodiment. [Figure 10] An example of a customer's personal page provided by the management server is shown. [Modes for carrying out the invention]

[0011] Next, embodiments for carrying out the invention of this application will be described. Figure 1 is a schematic diagram of a non-payment response system according to the first embodiment. The non-payment handling system of this embodiment is a system used when taking measures in the event of non-payment in a periodic payment contract between a customer and a recipient, where the customer and the recipient have a contract for payment of fees at predetermined intervals and measures are taken in the event of non-payment. The measures in the event of non-payment may be stipulated in the periodic payment contract, or they may be taken in accordance with civil law or other laws even if they are not in the contract, or they may be taken as a matter of course according to common social practice. As shown in Figure 1, the non-payment handling system of this embodiment comprises a storage unit 1, a non-payment information receiving means 2, a non-payment information recording means 3, an incident information output means 4, and an option usage output means 5.

[0012] Figure 2 is a schematic diagram showing a more specific example of the configuration of the non-payment response system shown in Figure 1. As shown in Figure 2, the non-payment response system includes a server 10 and terminals 7 and 8. The non-payment information receiving means 2, non-payment information recording means 3, incident information output means 4, and optional information recording means 5 are all configured by a single server 10. Hereinafter, this server 10 will be referred to as the management server. The storage unit 1 is a storage device such as an HDD provided by the management server 10, but it may also be provided by other servers such as a storage server or by a client. The management server 10 does not have to be a single server; multiple servers may be integrated to function as the management server 10. For example, separate servers may be provided for the non-payment information receiving means 2, the non-payment information recording means 3, the accident information output means 4, and the option usage output means 5, or a server may be provided that partially integrates several of these means.

[0013] First, let me explain the non-payment information receiving method 2. The non-payment information receiving means 2 is a means for receiving information that a customer has failed to make a payment on a certain payment due date. In this embodiment, for each customer, the non-payment information receiving means 2 receives either information that payment was made on the payment due date or information that payment was not made. That is, it is a means for receiving information that payment has been made if payment has been made, and information that payment was not made if payment was not made. The management server 10 is connected via network 9 to each server (hereinafter referred to as payment servers) 61-63 used by each customer when making recurring payments. In this embodiment, network 9 is the internet.

[0014] In this embodiment, the recurring payment is made by either automatic withdrawal from a bank account, credit card payment, or bank transfer. Therefore, the management server 10 which constitutes the non-payment information receiving means 2 against , a server 61 for performing automatic bank withdrawals (hereinafter referred to as the withdrawal server) and a server 62 for credit card companies that manage credit card payments (hereinafter referred to as the card company server) is connectedIn addition, bank transfers using payment slips at convenience stores, etc., are also possible. When a transfer is made using a payment slip, the payment collection agency collects the payment, deducts a fee from it, and then transfers the amount to the recipient's bank account. The payment collection agency operates a server (hereinafter referred to as the transfer intermediary server) 63 for this purpose, and thus, in this embodiment, the withdrawal server 61, the card company server 62, and the transfer intermediary server 63 each correspond to payment servers. In addition, the servers of companies that provide so-called prepaid payment services may also be used as payment servers.

[0015] Meanwhile, the memory unit 1 stores various files for managing recurring payments. One of these is the customer information file 11. Figure 3 is a schematic diagram showing an example of the structure of the customer information file 11. As shown in Figure 3, each record in the customer information file 11 has fields such as "Customer ID," "Password," "Name," "Address," "Payment Type," "Payment ID," "Option Contract Status," "Option Validity," "Option in Use," and "Service Suspended." The Customer ID is information that identifies each customer who has a recurring payment contract with the recipient in this embodiment. If the fees for a membership service are based on a recurring payment contract, the Member ID may be recorded as the Customer ID, and in the case of a mobile phone service, the mobile phone number may be recorded as the Customer ID. The password is information recorded to enhance security when identifying individual customers for purposes such as viewing and editing their My Page.

[0016] The "Payment Type" field records the type of payment method for recurring payments. For example, a value of 1 might indicate automatic withdrawal, a value of 2 might indicate credit card payment, and a value of 3 might indicate payment by bank transfer slip. The "Payment ID" is used to verify the payment and non-payment of recurring payments. While it may sometimes be the same as the Customer ID, if a separate ID is used, it will be recorded here. For example, in the case of credit card payments, all or part of the credit card number will be recorded as the ID.

[0017] The "Option Agreement Existence" field records whether a non-payment option agreement has been concluded as an ancillary agreement in the periodic payment agreement. In this embodiment, the measures to be taken in the event of non-payment on a certain payment due date are stipulated in the periodic payment agreement. The non-payment option agreement is an ancillary agreement that provides preferential treatment regarding the measures taken. Preferential treatment can mean preferential treatment regarding the timing of taking the measures or preferential treatment regarding the content of the measures, but in this embodiment, it is preferential treatment regarding the timing. That is, in this embodiment, if there is no non-payment option agreement, the measures will be taken immediately, whereas if there is a non-payment option agreement, the measures will not be taken immediately. Hereinafter, the main periodic payment agreement will be referred to as the main agreement. For the non-payment option agreement, a fee must be paid separately from the fee of the main agreement (periodic payment fee) (hereinafter referred to as the option fee).

[0018] The "Option Validity" field records whether a default option agreement is valid or invalid, if one exists. Normally, it is valid (true), but if the benefit of the default option agreement has been used (i.e., a default occurred but no immediate action was taken due to the default option agreement), it is temporarily invalidated. In that case, a false value is recorded in "Option Validity." Hereafter, the use of the benefit of a default option agreement will be abbreviated as "use of default option." The "Option in Use" field records whether an unpaid option is in use. A true value means the unpaid option is in use, while a false value means it is not in use. The "Suspended Due to Incident" field records whether the validity of a periodic payment contract (provision of services or goods) has been suspended due to non-payment. A true value means it is suspended, and a false value means it is not suspended.

[0019] The storage unit 1 stores a payment status file 12 as a separate file for managing periodic payments. The payment status file 12 is a file that records the payment status of charges for each payment due date in a periodic payment contract. In this embodiment, the payment status file 12 is created and stored as a separate file for each payment due date. Figure 4 is a schematic diagram showing an example of the structure of the payment status file 12 for a certain payment due date.

[0020] As shown in Figure 4, the payment status file 12 is a database file having fields such as "Customer ID," "Payment Type," "Payment ID," "Individual Payment ID," "Amount," and "Payment Status." The Customer ID, Payment Type, Payment ID, and Payment Status are copied from the information recorded in the Customer Information File 11. The Individual Payment ID is an ID that is generated and recorded to identify the payment obligation on each payment due date. For example, it may be an ID generated by combining the Customer ID and a number indicating the payment due date. In the case of bank withdrawal, the Individual Payment ID is agreed upon in advance with the bank (automatic withdrawal server 61), and the withdrawal server 61 sends the status of the withdrawal along with the ID to the management server 10. In the case of a collection agency that sends a payment slip for bank transfer, the Individual Payment ID is incorporated into the code symbol (barcode, etc.) printed on the payment slip. In the case of credit card payments, an ID is also generated for each payment (each use of the credit card), and it is common to monitor whether the bank withdrawal was successfully completed for that ID. In this case, the credit card company (card company server 62) notifies the recipient of each individual payment ID in advance and sends a message to the recipient (management server 10) indicating whether the bank withdrawal for that ID has been completed. In this case, the individual payment IDs that were notified in advance are recorded.

[0021] The payment status file 12 is created in advance of the payment due date for the recorded payment status, and the values ​​of each field except "Payment Status" are pre-recorded. That is, for all customers with a recurring payment contract, the values ​​are pre-recorded except for "Payment Status". For "Amount", in the case of a fixed amount such as a membership fee, the amount is recorded at the same time as the file is created. In the case of variable expenses such as mobile phone usage fees, the fee is determined on the closing date and notified or billed to the customer, so the determined fee is recorded in the "Amount" field after the closing date. Normally, a fee determination program that determines the fee is implemented on the management server 10, and the value is recorded in the "Amount" field when it is executed. Note that there is no default value for the "Payment Status" field.

[0022] The management server 10, which serves as the non-payment information receiving means 2 and the non-payment information recording means 3, functions as a server that receives payment status information (hereinafter referred to as "due date status information") for each payment due date from each payment server 61 to 63. The management server 10 has a program (hereinafter referred to as the "payment status recording program") 31 implemented that communicates with each payment server 61 to 63 to receive due date status information and records the transmitted due date status information in the payment status file 12. When the payment status recording program 31 receives due date status information from each payment server 61 to 63 via inter-server communication, it opens the payment status file 12 for that due date, searches the payment status file 12 using the individual payment ID included in the due date status information, and records the payment status in the payment status file 12 for the corresponding record. The due date status information transmitted from each payment server 61 to 63 includes information on whether payment has been made in addition to the individual payment ID, so the payment status recording program 31 records that information (whether payment has been made) in the "payment status" field. If the due date information includes payment amount information, the payment status recording program 31 may also verify that the value recorded in the "Amount" field of the payment status file 12 matches the payment amount included in the due date information. In addition, instead of the payment status recording program 31, a program that records that payment has not been made (non-payment recording program) may be implemented. In this case, the default value of the "Payment Status" field in the payment status file 12 is true (paid), and the non-payment recording program is implemented to change it to false (not paid) if payment has not been made.

[0023] As shown in Figure 2, a management terminal 7, operated by the recipient's representative, is provided as a terminal with access rights to the payment status file 12 of the storage unit 1. In addition to receiving due date status information from each of the payment servers 61 to 63 mentioned above, there are exceptional cases where due date status information is recorded in the payment status file 12 by the management terminal 7. If a customer makes a transfer to the recipient's bank account at an ATM or counter without using a transfer slip, the representative confirms this and records that payment has been made in the "Payment Status" section of the customer's record on the management terminal 7.

[0024] Next, we will explain the accident information output means. The management server 10, which functions as an accident information output means, has a payment monitoring program 41 and an accident information output program 42 implemented on it. The accident information output program 42 is a program that is called and executed by the payment monitoring program 41. In this embodiment, the management server 10 also has an accident reminder output program 43, an option usage output program 51, and an option usage reminder output program 44 implemented on it as programs that are called and executed by the payment monitoring program 41.

[0025] Figure 5 is a flowchart illustrating the overview of the payment monitoring program 41. The payment monitoring program 41 is a program that is automatically executed each time a recurring payment due date has passed. For example, if the recurring payment is a monthly payment with the due date being the end of each month, the program is automatically executed at a fixed time on the 1st of the following day (for example, 12:00 a.m.). The execution time of the payment monitoring program 41 is set to the time after all payment servers 61-63 have sent due date status information and the payment status recording program 31 has been executed. Recipients have agreements with each collection agency and each credit card company to send due date status information by a certain time on the day following the payment due date. The time after this certain time is set as the automatic execution time of the payment monitoring program 41. Even when an employee operates the management terminal 7 to record payment in the payment status file 12, it is agreed within the company that this should be completed before the automatic execution time.

[0026] When the payment monitoring program 41 is started at the automatic execution time, as shown in Figure 5, the payment monitoring program 41 opens the payment status file 12 created for the most recent payment due date. Then, it obtains the customer ID from the first record in the customer information file 11, searches the payment status file 12 using that customer ID, and obtains the "payment status" value for the corresponding record. If this value is false (no payment), it first executes the non-payment recording program (not shown). The storage unit 1 stores a non-payment information file 13 that records each non-payment, and the non-payment recording program is a program that records the fact of non-payment in the non-payment information file 13.

[0027] As shown in Figure 5, after recording a non-payment, the payment monitoring program 41 refers to the value of the "Non-payment Option Contract Existence" field in the relevant record in the customer information file 11. If this value is false (no non-payment option contract), the accident information output program 42 is executed as a subroutine for accident information output. At the same time, the customer information file 11 is searched using the customer ID, and the "Accident Suspended" value of the corresponding record is changed to true. Furthermore, the accident reminder output program 43 is executed as a subroutine. If "Payment Status" is false and "Non-payment Option Contract Existence" is true, the program further refers to "Option Validity," and if this is false, the payment monitoring program 41 similarly executes the accident information output program 42 and the accident reminder output program 43. In this case, if the value of "Option in Use" is true, it is changed to false. If "Option Validity" is true, the accident information output program 42 is not executed, and instead the option usage output program 51 is executed. Furthermore, the option usage reminder output program 44 is executed as a subroutine.

[0028] If "Payment Status" is true (payment made), the payment monitoring program 41 moves the pointer to the next record in the customer information file 11 without performing the above processing and obtains the customer ID. Even after executing the accident reminder output program 43 or the option usage reminder output program 44 in the case of no payment, the payment monitoring program 41 obtains the next customer ID and repeats the same process. The program terminates when it has repeated the process up to the last record in the customer information file 11.

[0029] Furthermore, payment monitoring program 41 may be executed immediately after the payment due date (for example, at 0:00 AM or 0:10 AM the following day). Automatic bank withdrawals and credit card payments are usually processed at a certain time during the day, and if the withdrawal or payment fails at that time, non-payment is confirmed. In the case of bank transfers using a payment slip, even if the payment is made just before noon, it will be reflected within a few minutes because it is processed by the server. Therefore, it may also be automatically executed at times such as 0:00 AM or 0:10 AM.

[0030] To further explain the non-payment information file 13, it is a database file created for each customer, and by using the customer ID in the filename, the file for that customer can be identified by the customer ID. Each record in the non-payment information file 13 has fields such as "Individual Payment ID," "Payment Due Date," "Amount," and "Repayment Date," and is a record for each individual payment ID that has been overdue. The "Payment Due Date" is the payment due date on which the payment was overdue, and the "Amount" is the amount of the overdue payment. This amount includes the fee for the main contract, as well as the option fee if there is a non-payment option contract.

[0031] To further explain the accident information output program 42, as shown in Figure 2, the storage unit 1 stores an accident information file 14 separately from the non-payment information file 13. The accident information file 14 is also a file created for each customer and can be identified by the customer ID. The accident information file 14 has fields such as "Accident Information Output Date" and "Suspension Release Date," and is a database file in which a record is added each time accident information is output. The configuration of the accident information output program 42 varies depending on the service or product covered by the recurring payment contract, but in any configuration, the accident information output program 42 usually includes recording to the accident information file 14 as a common process. Specifically, it opens the accident information file 14 corresponding to the customer using the customer ID and records the program execution date as the accident information output date.

[0032] Regarding the configuration of the accident information output program 42 other than recording in the accident information file 14, for example, if the recurring payment contract is a contract for the use of a communication terminal such as a smartphone, the accident information output program 42 will include code for taking measures to disable the communication service. Specifically, the telephone number or terminal identification number related to the customer ID will be added to the information (database) registered at each base station as telephone numbers or terminal identification numbers for which communication is not permitted.

[0033] If a recurring payment contract is for the provision of some kind of membership service and a member ID is issued, the accident information output program 42 processes the member ID to be invalid. For example, if a fitness club uses a system where members pass through a gate using a membership card, the program stores in the storage unit 1 on the gate that the member ID is invalid, and prevents the member from passing through the gate if the member card with that member ID is read.

[0034] Furthermore, if credit card payments are set up for recurring payments, the system will add the member's information related to that customer ID to a database file that records the information of members to whom reminder notices are sent. In addition, the system will add the member's information related to that customer ID to a database file (a so-called blacklist) that stores information on defaulters, which is operated by credit card companies, as needed. Furthermore, if the regular delivery of goods is covered by a recurring payment contract, the accident information output program 42 deletes the delivery address associated with the customer ID from the database file where the delivery address information is recorded. Then, it executes a program as a subroutine that prints a postcard stating that the goods will not be shipped due to non-payment.

[0035] Next, the option usage output program 51, which constitutes the option usage output means 5, will be described. In this embodiment, the option usage output program 51 is a program that outputs to a file on the storage unit 1. Several configurations for outputting to a file are possible, but in this embodiment, the program outputs the fact that an option has been used to the customer information file 11 and performs a process of rewriting the "Option Effectiveness" field. Specifically, the option usage output program 51 is executed with the customer ID as an argument and performs a process of changing the "Option Effectiveness" of the record related to the customer ID to a false value (no effect).

[0036] Next, the two debt collection output programs 43 and 44 will be explained in more detail. In this embodiment, two debt collection output programs 43 and 44 are provided in order to use different methods of debt collection depending on whether there is a non-payment and incident information is output, or whether there is a non-payment option contract and incident information is not output. Even if there is a non-payment option contract, it is still a non-payment, so debt collection is necessary. In this case, since the provision of the service or goods has not been stopped, the debtor may be suspicious of the debt collection. It is also necessary to clearly warn that incident information will be output if there is a non-payment on the next payment due date. For this reason, the option usage debt collection program 44 is implemented as a configuration for outputting debt collection information when the non-payment option is used.

[0037] Both the debt collection output programs 43 and 44 may be programs that output a debt collection notice in the form of an email to the customer terminal 8, which is the terminal operated by the customer (i.e., send a debt collection email), or programs that print a debt collection notice (output the debt collection notice to a printer). In addition, if the regular payment is by automatic bank withdrawal or credit card payment, there may be an arrangement in which a payment slip is issued and payment is made separately using the payment slip if payment is not made. In this case, both the debt collection output programs 43 and 44 are programs that print a payment slip for the payment of the unpaid amount. Furthermore, if the regular payment contract is a smartphone usage contract or an internet service provider usage contract and the sending and receiving of emails with the customer terminal 8 becomes impossible due to the output of accident information, the debt collection output programs 43 and 44 are configured to output for printing a debt collection notice.

[0038] The accident-in-time reminder output program 43 is configured to output a reminder stating that the provision of the service or goods has been discontinued due to non-payment and requesting immediate payment of the outstanding amount. The option-in-time reminder output program 44 is configured to output a reminder stating that there was non-payment and that the provision of the service or goods has not been discontinued because a non-payment option contract had been concluded, and requesting payment of the outstanding amount by the next payment due date.

[0039] Furthermore, if a non-payment option agreement is in place, the agreement may stipulate that it is sufficient to pay the outstanding amount, including the outstanding amount, on the next payment due date. In this case, an option usage notification output program may be implemented to notify the customer that the option is in use without including any demand for payment. The option usage notification output program is a program that outputs a notification stating that although payment was outstanding, the provision of the service or product will not be suspended because a non-payment option agreement is in place, and that the next payment due date will cover two installments. The option usage notification program may also be a program that outputs to the customer terminal 8 via email, or a program that prints on a notification postcard.

[0040] Furthermore, the aforementioned option usage reminder program 44 and option usage notification output program can also be considered types of option usage output programs. That is, they output information about option usage to the customer terminal 8 or to a printer, and can therefore be considered types of option usage output programs.

[0041] In this embodiment of the non-payment response system, several programs are implemented to record when a payment (repayment) is made regarding a non-payment. These programs are described below. First, the management server 10 has a repayment record program 101 implemented that records when a repayment has been made in the event of non-payment. Figure 6 is a flowchart showing an overview of the repayment record program 101.

[0042] If payment is not made, the recipient typically mails the customer a special payment slip instructing them to pay the outstanding amount via bank transfer. The payment slip has a code symbol (e.g., a barcode) printed on it that includes the customer ID of the customer who made the nonpayment and an individual payment ID that identifies the outstanding amount (payment due date). The customer uses the payment slip to pay the outstanding amount at a convenience store or similar location. Once payment is made, repayment information (that repayment has been made, the customer ID, and the individual payment ID) is sent from payment servers 61-63, operated by collection agents, etc., to the management server 10, and the repayment record program 101 on the management server 10 is executed. The repayment record program 101 opens the non-payment information file for the customer according to the customer ID included in the repayment information and searches using the individual payment ID. Then, it records the program execution date in the "Repayment Date" field of the corresponding record.

[0043] The management server 10 records the following programs, which can be called and executed by the repayment record program 101: the default suspension resolution program 102 and the option effect reinstatement program 103. The default suspension resolution program 102 is a program that restores the provision of services or goods under the main contract when all nonpayments have been repaid. The option effect reinstatement program 103 constitutes the option effect reinstatement means and is a program that restores the effect of an option when a nonpayment option has been used and repayment has been made by the next payment due date or at the next payment due date.

[0044] After recording the repayment date in the record related to a specific individual payment ID as described above, the repayment record program 101 refers to the value of "Accepted" for the corresponding record in the customer information file 11. If this is true, the repayment record program 101 refers to the payment status file 12 again and determines whether the "Repayment Date" is not a Null value for all records. If it is determined that a date is recorded in the "Repayment Date" for all records and that it is not a Null value, the repayment record program 101 executes the Accepted Account Resolution program 102. If even one record has a Null value, the repayment record program 101 does not execute the Accepted Account Resolution program 102.

[0045] The accident suspension recovery program 102 opens the accident information file 14 related to the customer according to the customer ID. It then records the program execution date in the "Suspension Release Date" of the last record. It also opens the customer information file 11 and resets the "Accident Suspended" value of the record related to the customer ID to false. Furthermore, if the "Option Contract Existence" value of the record is true, it resets the "Option Valid" value to true (valid). After that, the accident suspension recovery program 102 performs the necessary processing to resume the provision of the service or product. For example, if the smartphone usage contract is subject to a recurring payment contract, it performs processing to remove the telephone number or terminal identification number for the customer ID from the list of prohibited communications at each base station. In the fitness club example mentioned above, it performs processing to remove the customer's member ID from the list of invalid member IDs stored in the memory unit 1 on the gate. In addition, appropriate processing is performed depending on the content of the recurring payment contract.

[0046] Next, the repayment record program 101 refers to the values ​​of "Option contract existence," "Option validity," "Option in use," and "Account suspended due to default" for the relevant record in the customer information file 11. If "Option contract existence" is true, "Option validity" is false, "Option in use" is true, and "Account suspended due to default" is false, the repayment record program 101 executes the option validity restoration program 103 as a subroutine. If these conditions are not met, the option validity restoration program 103 is not executed.

[0047] Option Activation Restoration Program 103 is a program designed to restore an option that has become invalid even if it is not suspended due to an accident, in addition to the case where the accident suspension is lifted for customers with unpaid option contracts. In other words, it is a program that restores the validity of an option after it has been changed to invalid due to the option usage output, by the next payment due date or payment date. If the unpaid amount is to be paid separately by bank transfer, the condition for option restoration is that it is paid (repaid) by the next payment date. If the unpaid amount is to be added to the next payment date and paid, the condition for option restoration is that it is repaid at the next payment date.

[0048] In either case, the record for the customer in the customer information file 11 has "Option in Use" as the true value and "Option Effective" as the false value. When the option effectiveness restoration program 103 is started, it confirms that "Option in Use" is the true value and "Option Effective" is the false value, and then performs the process of changing "Option in Use" back to the false value and changing "Option Effective" back to the true value. This returns the system to its original state, that is, a state in which the non-payment option is not in use and the non-payment option contract is valid.

[0049] Furthermore, if the outstanding amount is not repaid by the next payment due date and remains unpaid at the next payment due date, or if the total amount including the additional amount (the amount for two installments) is not paid at the next payment due date, the "Option Effectiveness" will remain at a false value (invalid), and the accident information output program 42 will be executed. In this case, "Option in Use" will be reset to a false value, but "Option Effectiveness" will remain at a false value.

[0050] As mentioned above, the non-payment option contract is a paid contract attached to the main contract and is optional. When concluding this contract, the customer chooses whether or not to enter into the non-payment option contract. If the customer chooses to enter into the contract, as described above, a value indicating "yes" is recorded in the "Non-payment Option" field of the customer information file 11. The configuration for this will be explained in more detail below. The following explanation uses the example of a recurring payment contract entered into for the purpose of providing a membership service. The recipient also operates a server for providing such a membership service. This server may be a separate server from management server 10, or they may be the same server. In the following explanation, we will assume they are the same server.

[0051] The management server 10 provides the web page required for member registration when providing member services. Figure 7 is a schematic diagram showing an example of a customer registration page provided by the management server 10. The customer registration page displays not only a description (text) of the membership service, but also a description of the non-payment option. In this example, the option fee is added to the main contract fee and paid on each payment due date, and this is also explained. As shown in Figure 7, the customer registration page has fields for entering personal information, a button to confirm entered information, and a non-payment option selection field 104.

[0052] The management server 10 has a customer registration program (not shown) implemented on it. In the customer registration page shown in Figure 7, the confirmation button 105 is linked to a page for confirming the input information, and the submit button on this page is the button to execute the customer registration program. The customer registration program is a program that records each piece of information entered on the customer registration page in the customer information file 11, and records a value in the "Existence of Non-Payment Option Contract" field according to the selection in the Non-Payment Option Selection field 104.

[0053] The customer registration page described above is an example where the customer enters and submits the information themselves, which is then recorded in the customer information file 11. However, there are also configurations where the recipient's representative or a representative of the recipient's sales agent enters the information. For example, if the recipient is a smartphone telecommunications carrier, the service contract may be concluded at the sales agent's store. In this case, the management server 10 is equipped with a customer information registration page for the sales agent, and a terminal installed at the sales agent's store accesses the management server 10 to display the customer registration page, where the information is entered and recorded in the customer information file 11. The information entered and recorded includes whether or not the above-mentioned option contract exists. Of course, there are also cases where a terminal is installed at a counter directly operated by the recipient, rather than a sales agent, and the customer information registration page is displayed and entered there.

[0054] The operation of the non-payment response system in this embodiment will be briefly described below. When the recipient enters into a periodic payment agreement with each customer, they explain to each customer that an optional non-payment option agreement can be entered into. The customer chooses to enter into the non-payment option agreement. At this time, the information is recorded in the customer information file 11, either by entering information in the non-payment option selection field 104 on the customer registration page as shown in Figure 7, or on the customer information registration page for sales agents. This information includes whether or not the option agreement exists.

[0055] Customers who have selected the non-payment option contract pay the fee for the non-payment option contract in addition to the fee for the main contract on each payment due date. After each payment due date has passed, each payment server 61-63 sends due date status information to the management server 10, and the management server 10 records each due date status information in the payment status file 12.

[0056] After a predetermined time has elapsed since the payment due date, the payment monitoring program 41 is automatically executed to check whether payment has been made for each customer ID. Specifically, it refers to the value of "Payment Status" for the relevant record, and if it is false, it refers to the value of "Option Contract Status". If this value is false, there is no unpaid option contract, so the incident information output program 42 is executed. If the value of "Option Contract Status" is true, it refers to the value of "Option Validity". If this value is false, an unpaid option contract was concluded, but it has already been used and expired (the benefits of the option have been exhausted due to past nonpayment), so the incident information output program 42 is executed in the same manner. If both "Option Contract Status" and "Option Validity" are true, the payment monitoring program 41 does not execute the incident information output program 42, but instead executes the option usage output program 51. As a result, the "Option in Use" value for the relevant record in the customer information file 11 is changed to true. When the incident information output program 42 is executed, the true value is recorded in the "Incident Stopped" field of the relevant record in the customer information file 11.

[0057] In this manner, after each payment due date has passed and a predetermined time has elapsed, the payment monitoring program 41 is automatically executed, and if no payment has been made, the non-payment recording program is executed. If "Option contract existence" is a false value, or if "Option contract existence" is true and "Option validity" is a false value, the incident information output program 42 is executed. Furthermore, the incident reminder output program 43 is executed. If the incident information output program 42 is not executed because "Option validity" is true when no payment has been made, the option usage output program 51 is executed. Furthermore, in this case, the option usage reminder output program 44 is executed.

[0058] Then, when a customer who has defaulted on payments makes the outstanding amount, the repayment record program 101 is executed. The repayment record program 101 searches the default information file 13 using the individual payment ID included in the repayment information and records the program execution date in the "Repayment Date" field of the corresponding record. Next, it searches the customer information file 11 using the customer ID and determines whether "Account Suspended" is true in the corresponding record. If it is true, it determines whether "Repayment Date" is recorded in all records in the payment status file 12. If it is recorded, it executes the account suspension resolution program 102. The account suspension resolution program 102 opens the account information file 14 corresponding to the customer ID and records the program execution date in the "Account Resolution Date" field of the last record. At the same time, it changes the "Account Suspended" field in the customer information file 11 for the corresponding customer ID to a false value. Also, if "Option Contract Existence" is true, it returns "Option Validity" to true (valid).

[0059] Next, if the repayment record program 101 finds that the "Option contract existence" value is true, the "Option validity" value is false, and the "Account suspended due to accident" value is false for the customer ID included in the repayment information, the repayment record program 101 executes the option validity restoration program 103. This changes the "Option validity" value to true. If the payment for the outstanding amount is due before the next payment due date, the "option effect" will be true at that next payment due date. Therefore, if payment is still outstanding at that time, the payment monitoring program 41 will not execute the incident information program, but will instead execute the option usage output program 51. As a result, the provision of services or goods will continue without interruption.

[0060] With this type of non-payment handling system, customers have peace of mind knowing that even if they fail to pay for any reason, the provision of services or goods will not be suspended for the first time. On the other hand, recipients continue to provide services or goods despite the risk of non-payment at the next payment due date, potentially resulting in the inability to collect the debt completely, but they receive an option fee in return for this. As a result, they can earn income separate from the revenue from the main payment that is sufficient to cover the overall debt collection costs, allowing them to confidently conduct their recurring payment business. Furthermore, customers will have a better impression of the recipient's business because they can choose to use the non-payment option service, which can lead to increased sales. In addition, since the option fee is only borne by customers who are aware that they are likely to fail to pay, it ensures a fair cost burden.

[0061] Furthermore, the non-payment handling system of this embodiment outputs option usage information along with information that can identify the customer involved in the usage, so the option usage information can be used for various purposes. The above example shows output to a file and is an example of invalidating the "option effect" in customer information file 11. This is because once the benefits of the non-payment option contract are used, the benefits of the non-payment option contract cannot be used for a second consecutive non-payment, and this configuration is implemented in the system to address this point.

[0062] In relation to the above points, a configuration in which the management server 10 implements an option usage output program 51 that temporarily disables the option's effectiveness when the non-payment option is used, and an option effectiveness restoration program 103 that then re-enables the option, is particularly beneficial. As a configuration to prevent the use of the benefits of the non-payment option contract for a second non-payment in the event of two consecutive non-payments, one could consider a configuration in which, when a non-payment occurs on a certain payment due date, the payment status on the previous payment due date is referenced, and if there was also a non-payment on that payment due date, default information is immediately output even if a non-payment option contract is in place. While this configuration is acceptable, if a payment is made before the next payment due date after an initial non-payment, the non-payment option should be made available for non-payment on the next payment due date. A configuration that references the payment status on the previous payment due date cannot handle this (restoring the benefits of the non-payment option contract). The option effectiveness restoration program 103 is a program that records that the use of the non-payment option has ended due to a repayment on or before the next payment due date, and is a program that makes the non-payment option available again if a non-payment occurs thereafter. Therefore, even if a customer has defaulted on a payment, they will have an incentive to repay the outstanding amount by the next payment due date or earlier, thereby reviving the benefits of the non-payment option contract and encouraging payment of the outstanding amount.

[0063] The output of option usage information can be used in various ways other than those described above. Below, we will describe a second embodiment in which the method of using option usage information differs. In the second embodiment, a configuration of the option usage output means 5 that is not included in the first embodiment is adopted. That is, in the second embodiment, although the option usage output means 5 is configured to output and record unpaid option usage to a file, a configuration is adopted in which all option usage is recorded as history information. For this purpose, the storage unit 1 stores an option usage history information file 52.

[0064] Figure 8 is a schematic diagram showing an example of the structure of the option usage history information file 52. In this embodiment, the option usage history information file 52 is a file created for each customer (each customer ID), and the file can be identified by the customer ID, for example, by using the customer ID in the file name. As shown in Figure 8, the option usage history information file 52 is a database file that records records consisting of fields such as "Usage ID," "Start Date and Time of Use," "End Date and Time of Use," and "Reason for Termination." The option usage history information file 52 is a file in which one record is recorded for each instance of an unpaid option being used, and the "Usage ID" is a field in which information identifying these records is recorded. For example, a sequential number is recorded as the Usage ID.

[0065] The "Start Date and Time" field records the execution date and time of the optional output program 51. The "End Date" field records the date and time when the non-payment option was no longer in use. The “Reason for Termination” field records the reason why the use of the non-payment option has ended. In this embodiment, there are two types of use of the non-payment option. One is the aforementioned repayment termination, which occurs when the non-payment option is used after a payment is not made on a certain payment due date, and then terminates when the outstanding amount is paid before or on the next payment due date. Hereinafter, this termination will be referred to as repayment termination. The other is a pattern where the option is used and terminated without payment being made on or before the next payment due date, and the benefits of the non-payment option have been used up, so it terminates there. Hereinafter, this termination will be referred to as used-up termination. As can be understood from the above explanation, in the case of used-up termination, the payment monitoring program 41 will execute the incident information output program 42.

[0066] Figure 9 is a flowchart illustrating the outline of the option usage output program 51 in the second embodiment. In this embodiment as well, the option usage output program 51 is read from the payment monitoring program 41 and executed with the customer ID as an argument. That is, if the "payment status" in a record in the payment information file 12 is false, and the option validity recorded in the customer information file 11 for that customer ID is true, the payment monitoring program 41 does not execute the incident information output program 42, but instead executes the option usage output program 51 with the customer ID as an argument.

[0067] In the second embodiment, the option usage output program 51 similarly searches the customer information file 11 using the customer ID, changes the "Option Effectiveness" value of the corresponding record to a false value, and changes the "Option in Use" value to a true value. Next, the option usage output program 51 determines whether an option usage history information file 52 exists with the customer ID as the filename, and if not, creates a new one with the customer ID as the filename. The option usage output program 51 adds a new record to the option usage history information file 52 with the customer ID as the filename and records a sequential number (the value in the last record + 1) in "Usage ID" (1 if newly created). Next, it records the program execution date and time in "Usage Start Date and Time". It also records the next payment due date as the default value in "Usage End Date" and records "Used and terminated" as the default value in "Termination Reason". After updating the file, the program terminates. In this way, a new record is added and the usage start date and time are recorded each time an unpaid option is used for a specific customer ID.

[0068] In the second embodiment, the configuration of the option validity restoration program 103 is slightly modified. In the second embodiment as well, if the outstanding amount is repaid before or at the next payment due date after the non-payment option has been used, the option validity restoration program 103 is executed, and the value of "Option Validity" in the customer information file 11 is returned to true. After performing this process, the option validity restoration program 103 in the second embodiment opens the option usage history information file 52 created for the customer according to the customer ID, records the program execution date in the "Usage End Date" of the last record, and records the completion of repayment in the "Reason for Termination".

[0069] According to the non-payment handling system of the second embodiment, the usage history of non-payment options for each customer is recorded in the option usage history information file 52, so this information can be effectively utilized. For example, if there is no use of a non-payment option for a predetermined period, or if there is use but it is infrequent, the option fee can be reduced or made free. In this case, the management server 10 implements an option fee change program. The option fee change program is a program that is executed periodically (for example, after each payment period has passed, after the payment status monitoring program has been executed, etc.), and it opens the option usage history information file 52 and counts the number of records (number of times the option was used) within the period. If the number is below a predetermined level, it performs a process to reduce the option fee. The storage unit 1 stores a billing information file that records the payment amount (billing amount) for each customer on each payment due date, and the management server 10 implements a payment amount notification program that notifies each payment server 61 to 63 of the billing amount recorded in the billing information file according to each customer's payment method type. In this case, the option fee modification program is a program that ensures that when the billing amount is recorded in this billing information file, the option fee is reduced or set to zero.

[0070] Furthermore, when counting the number of times the non-payment option has been used, usage history where repayment has been completed may be given priority. Repayment completion is proof that the non-payment was repaid by or on the next payment due date, and does not mean that the payment was significantly delayed. On the other hand, used and completed indicates that two non-payments have occurred and default information has been generated. If all outstanding amounts are repaid after the default information is generated, the "option effect" will be changed to "yes," but this means that a considerable payment delay has occurred. Therefore, the option fee may be reduced or waived even if there are a certain number of instances when repayment is completed, while for used and completed, the fee may not be reduced or waived unless it is one or a few times or less. For example, in the case of monthly regular payments, repayment completion may result in a reduction or waiver up to once a year, but for used and completed, the fee may not be reduced or waived unless it is once every two years or less. Furthermore, if the non-payment option is not used at all in a year, the option fee will be waived thereafter, and if it is used once in a year, the fee will be reduced thereafter. In other words, the conditions for reduction and waiving the fee may be differentiated.

[0071] Conversely, the system may be configured so that the option fee increases depending on how often the non-payment option is used. For example, initially, only 100 yen is added to the monthly payment, but after using the non-payment option once, the fee increases to 110 yen, and after using it twice, it increases to 120 yen. In this case, the option fee change program may also be implemented so that if the non-payment option is not used for a certain period (for example, one year), the fee is reduced back to the original 100 yen. In any case, these measures create an incentive for each customer to avoid non-payment as much as possible, resulting in a reduction in non-payment among customers as a whole. Thus, by recording the usage history of options in a file, usage history can be used effectively.

[0072] Furthermore, while the above explanation states that the accident suspension resolution program 102 or the option validity restoration program 103 will activate and the non-payment option contract will be made valid again once all non-payments have been repaid, in cases where the non-payment option is used frequently, the accident suspension resolution program 102 or the option validity restoration program 103 may be implemented to delay the reactivation (re-activation) for a short period of time. For example, for customers who frequently use the non-payment option, it may be reactivated after one month, and for customers who use it even more frequently, it may be reactivated after two months, or even three months. This configuration provides an incentive to avoid non-payment as much as possible. It should also be said that the accident suspension resolution program 102 constitutes a means of restoring option validity.

[0073] Furthermore, the option fee change program may be configured to run periodically (based on time-based conditions) or based on conditions other than time. Typically, if circumstances arise at the recipient's end that require a change in option fees, the option fee change program is executed accordingly. In this case, the option area change program is executed upon request from the management terminal 7. Separately, the option fee change program may also be executed after being read by the option usage output program 51. When the option usage output program 51 outputs option usage, it refers to the option usage history information file 52 for that customer to obtain the total number of option usages. If that number reaches a certain limit, it automatically calls and executes the option fee change program. Such a configuration may also be adopted.

[0074] In the embodiments described above, the benefit of the non-payment option contract was preferential treatment regarding the timing of taking action, but it may also be preferential treatment regarding the content of the action. For example, in the case of non-payment, penalties may be imposed in the form of interest or late payment penalties, but if a non-payment option contract is in place and is valid, the amount of such penalties may be reduced or even eliminated. In the case of credit services such as credit cards, the benefit of the option contract may be that if a non-payment option contract is in place, the customer will not be placed on a so-called blacklist due to a single instance of non-payment.

[0075] Furthermore, if the installment payment is a recurring payment contract, there may be a clause stating that non-payment will result in an obligation to repay the entire amount in a lump sum. In this case, if there is a non-payment option contract, it may be stipulated that the obligation to repay the entire amount in a lump sum does not arise from the second non-payment onwards. In addition, if the regular delivery of goods (subscription) is subject to recurring payments, benefits such as discounts, free shipping, and free return shipping may be provided as standard, and these benefits may be forfeited in the event of non-payment. In this case, the benefit of the non-payment option contract may be that these benefits will continue to be provided without being canceled by a single non-payment. In any of these cases, the configuration of each embodiment described above can be applied.

[0076] In the embodiments described above, the option fee was paid by adding it to the base price on each payment due date, but it may also be paid in a lump sum at the time of contract. In this case, if a non-payment occurs and the non-payment option is used once, the option fee may be added to the next payment due date and paid again in a lump sum, thereby executing the option activation program 103.

[0077] Furthermore, in each of the above embodiments, the non-payment option contract was configured to be decided at the time of concluding the main contract, and if it was decided to use it, this fact was recorded in the customer information file 11. However, it is preferable to allow the non-payment option contract to be added retrospectively after the conclusion of the main contract. An example of this configuration is shown in Figure 10. Figure 10 shows an example of a My Page provided to each customer by the management server. My Page is a webpage provided to each customer by the management server 10, allowing them to check their contract details, change their registered personal information, and modify some contract details. To use My Page, the recipient issues a password to each customer. By pressing (tapping or clicking) the login button on the top page provided by the management server on the customer terminal 8, and entering the customer ID and password on the login screen, the My Page shown in Figure 10 is displayed on the customer terminal 8.

[0078] As shown in Figure 10, the My Page has an input field 106 for changing the presence or absence of an option contract. In this example, the input field 106 for changing the presence or absence of an option contract is a radio button. The HTML file that displays the My Page has embedded code that searches the customer information file 11 using the customer ID, retrieves the value of "Option Contract Presence / absence" for the corresponding record, and displays the default value (Yes or No) for the input field 106 for changing the presence or absence of an option contract accordingly.

[0079] As shown in Figure 10, a confirmation button 107 is provided on the My Page. The confirmation button 107 is linked to a confirmation page, and the OK button on the confirmation page is the execution button for the My Page change registration program (not shown). When the option contract change input field 106 is changed and the confirmation button 107 is pressed, and the OK button is pressed on the confirmation page, the My Page change registration program changes the value of "Option Contract Existence" in the customer information file 11. Therefore, it is possible to change from "No unpaid option contracts" to "Yes," or from "Yes unpaid option contracts" to "No." Furthermore, if a configuration is adopted in which option fees are added to the main contract fee and paid on each payment due date, when the option contract existence status is changed, it is reflected in the program that calculates the payment amount on each payment due date, and the management server 10 notifies each payment server 61-63 so that payment is made with the changed amount.

[0080] In each of the embodiments described above, the non-payment option agreement was an ancillary agreement attached to the main agreement, but it may also be included in the main agreement. That is, it is possible that both a main agreement with a non-payment option clause and a main agreement without a non-payment option clause are available, and the customer can choose to enter into either one. Furthermore, the non-payment option clause may exist as a standard clause in the main contract, and it may remain in effect unless the customer cancels it. In this case, the non-payment option contract may be checked by default on the My Page mentioned above (indicating the contract exists), and it may continue unless the customer unchecks it. The same applies to other input fields; they may continue unless the customer makes a cancellation decision. In this case, if the customer cancels the contract, the non-payment option fee will be deducted from subsequent regular payments.

[0081] In each of the above embodiments, it is possible that a configuration is adopted in which different grades of non-payment option contracts are available, and the customer chooses one grade to enter into a non-payment option contract. The grade of the non-payment option contract refers to, for example, the length of the grace period for measures taken in the event of non-payment. A higher grade means a longer grace period. For example, as mentioned above, a normal non-payment option contract is until the next payment due date, but a higher grade is until the payment due date after that, and the highest grade is until the payment due date after that. The fee for the non-payment option is higher for higher grades. The customer information file 11 also records information on the grade of the non-payment option contract, and the incident information output program 42 determines whether the grace period has expired by referring to the grade information, and outputs incident information if it has. In addition, the grade of the non-payment option contract may also refer to the degree of the measures taken in the event of non-payment (the degree to which it is more favorable compared to not having a non-payment option contract).

[0082] In each of the above embodiments, the periodic payment fee may be paid in various forms of goods. That is, the periodic payment fee may be paid in goods such as crypto assets (virtual currencies), tokens, prepaid money or other electronic money, or currency-denominated assets. Alternatively, a configuration may be adopted in which points (goods that are discounted on future purchases) given in accordance with the purchase amount of goods or services are used to pay the periodic payment fee. [Explanation of Symbols]

[0083] 1 Storage section 11. Customer Information File 12 Payment Status File 13. Accident Information File 2. Means for receiving information on non-payments 3. Means for recording non-payment information 31 Payment Status Record Program 4. Accident Information Output Means 41 Payment Monitoring Program 42. Accident Information Output Program 5. Optional Output Means 51 Option-Using Output Program 52 Option Usage History Information File 61-63 Payment Server 7. Management terminal 8 Customer terminals 9 Network

Claims

1. In a contract between a customer and a recipient for periodic payments, in which a fee is to be paid at predetermined intervals and measures are taken in the event of non-payment, the non-payment handling system is used when taking such measures if the fee is not paid on the due date. Memory unit and, Accident information output means, Option usage output means and It is equipped with, The memory unit stores a customer information file that records the information of each customer with whom the recipient has a recurring payment contract, and a payment status file that records the payment status of each customer on each payment due date. The customer information file records information on whether a non-payment option agreement has been entered into with the recipient for each customer, on the condition that the customer pays an option fee to the recipient. Each non-payment option agreement is an agreement entered into on the condition that each customer pays an option fee to the recipient in the periodic payment agreement. A non-payment option agreement is a contract that stipulates that if a regular payment is not made on a certain payment due date, measures will be taken at a predetermined time if there is no non-payment option agreement, whereas if there is a non-payment option agreement, measures will be taken at a grace period before the predetermined time, or measures that are more favorable to the customer than those taken if there is no non-payment option agreement. The accident information output means is a means that outputs as accident information information for taking measures at the predetermined time or for taking measures that are less favorable to the customer than if there were a non-payment option contract. The accident information output means, when a customer fails to make a payment on a certain payment due date and that non-payment is recorded in the payment status file, refers to the customer information file and, if a non-payment option agreement has been concluded for that customer, does not output accident information, but outputs accident information if a non-payment option agreement has not been concluded. The option usage output means is a means of outputting option usage information, which is information indicating that the benefits of the non-payment option agreement have been used, when a customer fails to make a payment on a certain payment due date and no incident information is output because a non-payment option agreement has been concluded for that customer. A non-payment handling system for periodic payments, characterized in that the option usage output means outputs option usage information along with information that can identify the customer related to the option usage information (except when outputting for the purpose of making a monetary payment to a third party).

2. The information regarding whether the aforementioned non-payment option agreement has been concluded is information regarding the date of conclusion and termination of the aforementioned non-payment option agreement. The accident information output means is a program that determines that a non-payment option contract has been concluded if the date of conclusion of the non-payment option contract is recorded but the date of termination is not recorded, and determines that a non-payment option contract has not been concluded if the date of conclusion of the non-payment option contract is not recorded, or if the date of conclusion of the non-payment option contract is recorded and the date of termination of the non-payment option contract is also recorded, characterized in that the non-payment handling system for periodic payments according to claim 1.

3. The aforementioned storage unit stores an option contract history information file that records the history of unpaid option contracts for each customer. The non-payment handling system for periodic payments according to claim 2, characterized in that the option contract history information file is a file that records information about the date of conclusion and the date of termination of the non-payment option contract concluded by the recipient with each customer.

4. The aforementioned customer information file contains information regarding whether the non-payment option agreement is valid or invalid for customers with whom the non-payment option agreement has been concluded with the recipient. The option usage output means is a means for outputting the option usage information to the customer information file, and is a means for recording in the customer information file that the effect of the unpaid option contract for the customer is invalid, After the option usage output means outputs option usage information, when the non-payment that caused the output of the option usage information is repaid, an option validity restoration means is provided in the customer information file to restore the validity of the non-payment option contract for the customer in question. The aforementioned accident information output means, when a customer fails to make a payment on a certain payment due date and the non-payment is recorded in the payment status file, refers to the customer information file and does not output accident information if a non-payment option agreement has been concluded and is valid for that customer, but outputs accident information if no non-payment option agreement has been concluded or if it has been concluded but is invalid. The non-payment handling system for periodic payments according to claim 1, characterized in that the option usage output means is a means for outputting option usage information, which is information indicating that the benefits of the non-payment option agreement have been used, when a customer fails to make a payment on a certain payment due date and a non-payment option agreement has been concluded for that customer and is valid, and therefore no incident information has been output.

5. The non-payment handling system for periodic payments according to claim 4, characterized in that the option activation means is a means to be executed by the next payment due date if the repayment is made by the next payment due date following the non-payment due date that caused the output of the option usage information.

6. The non-payment handling system for periodic payments according to claim 1, characterized in that the option usage output means is a means for outputting the option usage information to a customer terminal which is a terminal operated by the customer, or a means for outputting the option usage information to a printer which prints the option usage information on paper sent to the customer.

7. The storage unit stores an option usage history information file that records the history of option usage information for each customer. The non-payment handling system for periodic payments according to claim 1, characterized in that the option usage output means is a means for recording the option usage information for the customer in an option usage history information file.

8. The non-payment handling system for periodic payments according to claim 7 is characterized in that it is provided with an option fee changing means that changes the option fee according to the history of option usage recorded in the option usage history information file.

Images