Non-payment assistance system for recurring payments

Abstract

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

Description

Non-payment response system for regular payments

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

[0002] When purchasing services or products, periodic payment contracts are often concluded, whereby a fee is paid at set intervals. For example, various communication services, such as mobile phones and internet service providers, have a set monthly fee, and the service is provided by paying this fee. Fitness clubs and other membership services also provide membership services by paying a monthly fee. In the sale of products, too, a delivery method whereby products are delivered periodically in exchange for a fixed monthly fee is increasingly being adopted, and this method is abbreviated to "subscription." In the field of credit sales, periodic payments are also used for credit card payments, lease fees, various repayments, etc. Furthermore, periodic payment methods are also used for real estate rentals and certain types of royalties.

[0003] In such a contract for recurring payments, the customer (in this specification, this broadly refers to the person who pays the recurring fee) is required to pay the fee on the specified date, but there are cases where the customer fails to make the payment for various reasons, such as simply forgetting to pay, or not realizing that there are insufficient funds in the account when automatic deductions are made from the customer's bank account.

[0004] In either case, if payment is not made on a certain date, the recipient (in this specification, this broadly refers to the party receiving the fee in a recurring payment contract) will take some kind of action. If the recurring payment contract is for the provision of a membership service, the recipient is the business entity providing the membership service, and if payment is not made, they will take measures such as suspending the provision of the membership service. In the credit sales field, they may add the recipient to a list of insolvent parties (so-called blacklists) or charge late payment penalties depending on the contract.

[0005] JP 2020-38467 A JP 2018-45300 A

[0006] If a defaulter subsequently makes a payment after taking the above measures, the debt is considered recovered and there is no loss. However, the internal costs (effort) involved in implementing these measures remain. While these costs are included in the contractual fee for regular payments, non-payment recipients also bear these costs, which could be considered unfair. In anticipation of such non-payment recovery costs, recipients may purchase certain types of insurance. The insurance company calculates the risk of non-payment, and the recipient pays a premium to the insurance company based on this calculation. If non-payment actually occurs, the insurance company pays the specified insurance benefit to the recipient. However, even in this case, the premium is included in the overall cost of the regular payment, and the non-payment recipient also bears this cost, creating an unfair situation. The present invention was developed with this problem in mind and aims to provide a technology that enables customers to fairly bear the recovery costs in the event of non-payment and creates an incentive for customers to avoid non-payment.

[0007] The applicant of the present application has disclosed an invention for a guarantee and compensation system for recurring payments in Patent Document 1. The problem addressed by the present invention differs from that of the invention of Patent Document 1 in the following respects. First, Patent Document 1 discloses a system in which a recipient and a compensation provider exist, and the compensation provider pays compensation to the recipient in the event of non-payment. The compensation fee paid by the customer is received by the compensation provider. Although the recipient is paid compensation for the first non-payment if two consecutive non-payments occur, the compensation is for the fee for one non-payment and is not intended to cover the overall recovery costs for non-payment. In industries where non-payments occur regularly, even if only by a few percent of the total number of customers, it is necessary to constantly secure (pool) a certain amount of funds to cover the recovery costs in the event of non-payment. The technology of Patent Document 1 is not suitable for such industries. The present invention addresses this issue and aims to provide a technology that enables the overall preparation of costs incurred in the event of non-payment.

[0008] To solve the above-mentioned problems, this specification discloses a non-payment handling system. The disclosed non-payment handling system is used to take measures when a fee is not paid by the due date when a customer and a receiver enter into a periodic payment contract in which fees are paid at predetermined intervals and measures are taken in the event of non-payment. The system comprises a memory unit, an accident information output means, and an option usage output means. The memory unit stores a customer information file containing information about each customer who has a periodic payment contract with the receiver, and a payment status file containing payment status information for each customer on each payment due date. The customer information file contains information about whether a non-payment option contract has been concluded with the receiver on the condition that the customer pays an option fee to the receiver. The non-payment option contract stipulates that if a periodic payment is not made by a certain payment due date, measures are taken at a predetermined time if there is no non-payment option contract, but if there is a non-payment option contract, measures are taken at a later time than the predetermined time, or measures that are more favorable to the customer than those taken if there is no non-payment option contract. The accident information output means is means for outputting, as accident information, information for taking measures at the specified time or information for taking measures that are more disadvantageous to the customer than if there were a non-payment option contract.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, the accident information output means is means for referencing the customer information file, and not outputting accident information if a non-payment option contract has been concluded for the customer, and outputting accident information if a non-payment option contract has not been concluded.The option usage output means is means for outputting option usage information, which is information indicating that the profits of the non-payment option contract have been used, when a customer fails to make a payment on a certain payment due date and the accident information is not output because a non-payment option contract has been concluded for the customer.The option usage output means is means for outputting option usage information together with information that can identify the customer related to the option usage information.Furthermore, in order to solve the above problem, the disclosed non-payment handling system may have the following configuration: The information on whether a non-payment option contract has been concluded is information on the conclusion date and cancellation date of the non-payment option contract, and the accident information output means is a program that determines that a non-payment option contract has been concluded if the conclusion date of the non-payment option contract is recorded but the cancellation date is not, and determines that a non-payment option contract has not been concluded if the conclusion date of the non-payment option contract is not recorded or if the conclusion date of the non-payment option contract is recorded and the cancellation date of the non-payment option contract is also recorded. Furthermore, in order to solve the above problem, the disclosed non-payment handling system may have the following configuration: The storage unit stores an option contract history information file that records the history of non-payment option contracts for each customer, and the option contract history information file is a file that records information on the conclusion date and cancellation date of non-payment option contracts concluded by the recipient with each customer.Furthermore, in order to solve the above-mentioned problems, the disclosed non-payment handling system has: a customer information file that records information on whether a non-payment option contract is valid or invalid for a customer who has concluded a non-payment option contract with a recipient; an option usage output means that outputs option usage information to the customer information file and records in the customer information file that the non-payment option contract for that customer is invalid; an option effect restoration means that, after the option usage output means outputs the option usage information, records in the customer information file that the non-payment that caused the option usage information to be output is repaid, restores the validity of the non-payment option contract for that customer; and an accident information output means that, when a customer does not 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 contract for that customer has been concluded and is valid, and outputs accident information if a non-payment option contract has not been concluded or has been concluded but is invalid. The option usage output means may be configured as: "A means for outputting option usage information, which is information indicating that the profits of the non-payment option contract have been used, when a customer fails to make a payment on a certain payment due date and the non-payment option contract is concluded and valid for the customer, so that the accident information is not output." Furthermore, in order to solve the above problem, the non-payment handling system according to the disclosed invention may be configured as: "The option revival effect means is a means executed by the next payment due date if repayment is made by the next payment due date following the payment due date for the non-payment that caused the output of the option usage information." Furthermore, in order to solve the above problem, in the non-payment handling system according to the disclosed invention, the option usage output means may be 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 that prints the option usage information on paper to be sent to the customer."In order to solve the above problem, the non-payment handling system according to the disclosed invention may have the following configuration: the storage unit stores an option usage history information file that records the history of option usage information for each customer, and the option usage output means is a means for recording the option usage information for the customer in the option usage history information file. In order to solve the above problem, the non-payment handling system according to the disclosed invention may be provided with option fee change means that changes the option fee in accordance with the option usage history recorded in the option usage history information file.

[0009] As explained below, the non-payment response system according to the disclosed invention provides customers with peace of mind by paying an option fee and entering into a non-payment option contract, knowing that even if a non-payment occurs for some reason, a single non-payment will not result in the output of an incident report. Meanwhile, the recipient, while risking the risk of a subsequent non-payment and the inability to fully recover the debt, is unable to take appropriate measures to address the non-payment, receives the option fee in return. This allows the recipient to earn additional revenue to cover the overall debt collection costs and to conduct its periodic payment contract business with peace of mind. Furthermore, knowing that a non-payment option service is available and available for customers to select and use improves the recipient's business image and leads to increased sales. Furthermore, the option fee is borne only by customers who recognize their risk of non-payment, ensuring fair cost sharing. Furthermore, by outputting option usage information together with information identifying the customer involved, the option usage information can be used and optimized for various purposes. Furthermore, if the option usage output means is a means for recording the invalidation of an unpaid option contract in the customer information file, and if an option revival means is provided for recording the validity of the unpaid option contract for the customer after the non-payment that caused the output of the option usage information has been made, an incentive will be created for the customer to repay the unpaid amount early, and early recovery of the unpaid amount will be expected.In this case, if the option revival means is executed by the next payment due date if the unpaid amount is repaid by the next payment due date after the payment due date of the defaulted payment, even if the customer has defaulted once, as long as the payment is made by the next payment due date, the customer will be able to reap the benefits of the unpaid option contract again at the next payment due date, which will further create an incentive for the customer to repay the unpaid amount early, and this is preferable in this respect.Furthermore, if the option usage output means is a means for outputting option usage information to a customer terminal operated by the customer, or a means for outputting option usage information to a printer that prints the option usage information on paper to be sent to the customer, the customer can be notified that an unpaid option has been used, thereby increasing the probability that the unpaid amount will be repaid early. Furthermore, if the option usage output means is a means for recording option usage information for the customer in an option usage history information file, the information on the usage history of unpaid options can be effectively utilized. In this case, if an option fee change means is provided that changes the option fee in accordance with the option usage history recorded in the option usage history information file, the option fee will be changed depending on the amount of unpaid option usage, thereby making the option fee burden for each customer more equitable.

[0010] FIG. 1 is a schematic diagram of a non-payment handling system according to a first embodiment. FIG. 2 is a schematic diagram showing an example of a more specific configuration of the non-payment handling system shown in FIG. 1. FIG. 3 is a schematic diagram showing an example of the structure of a customer information file. FIG. 4 is a schematic diagram showing an example of the structure of a payment status file for a certain payment due date. FIG. 5 is a flowchart showing an overview of a payment monitoring program. FIG. 6 is a flowchart showing an overview of a repayment record program. FIG. 7 is a schematic diagram showing an example of a customer registration page provided by the management server. FIG. 8 is a schematic diagram showing an example of the structure of an option usage history information file. FIG. 9 is a flowchart showing an overview of an option usage output program in a second embodiment. An example of a My Page provided to each customer by the management server is shown.

[0011] Next, a description will be given of a mode (embodiment) for carrying out the invention of this application. FIG. 1 is a schematic diagram of a non-payment handling system according to a first embodiment. The non-payment handling system according to the embodiment is a system used to take measures in the event of non-payment when a customer and a recipient enter into a periodic payment contract in which a fee is paid at predetermined intervals and measures are taken in the event of non-payment. The measures in the event of non-payment may be specified in the periodic payment contract, or may be measures taken under the Civil Code or other laws even if not specified in the contract, or measures taken as a matter of course according to social convention. As shown in FIG. 1, the non-payment handling system according to this embodiment includes a memory unit 1, non-payment information receiving means 2, non-payment information recording means 3, accident information output means 4, and option usage output means 5.

[0012] FIG. 2 is a schematic diagram showing an example of a more specific configuration of the non-payment handling system shown in FIG. 1. As shown in FIG. 2, the non-payment handling system includes a server 10 and terminals 7 and 8. The non-payment information receiving means 2, the non-payment information recording means 3, the accident information output means 4, and the option information recording means 5 are configured on a single server 10. Hereinafter, this server 10 will be referred to as the management server. The memory unit 1 is a storage device such as a HDD provided on the management server 10, but may also be provided on another server such as a storage server or on 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, a server may be provided for each of 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 means.

[0013] First, the nonpayment information receiving means 2 will be described. The nonpayment information receiving means 2 is a means for receiving information that a customer has not made a payment on a certain payment due date. In this embodiment, the nonpayment information receiving means 2 is configured to receive, for each customer, either information that a payment has been made on the payment due date or information that a payment has not been made. In other words, if a payment has been made, the means receives information that the payment has been made, and if a payment has not been made, the means receives information that the payment has not been made. The management server 10 is connected via a network 9 to each server (hereinafter referred to as the payment server) 61-63 used by each customer when paying their regular fees. In this embodiment, the network 9 is the Internet.

[0014] In this embodiment, recurring payments are made by automatic bank debit, credit card payment, or bank transfer. To this end, a server for automatic bank debit (hereinafter referred to as the debit server) 61 and a credit card company server for managing credit card payments (hereinafter referred to as the card company server) 62 are connected to the management server 10, which constitutes the non-payment information receiving means 2. Bank transfers at convenience stores and other locations using a transfer slip are also possible. When a transfer is made using a transfer slip, the collection agent first collects the payment, then deducts a handling fee and transfers the money to the recipient's bank account. The collection agent operates a server for this purpose (hereinafter referred to as the transfer intermediary server) 63. Thus, in this embodiment, the debit server 61, card company server 62, and transfer intermediary server 63 each correspond to a payment server. Alternatively, the server of a company that handles so-called prepaid payments may also be used as a payment server.

[0015] Meanwhile, the storage unit 1 stores various files for managing periodic payments. One of these is the customer information file 11. FIG. 3 is a schematic diagram showing an example of the structure of the customer information file 11. As shown in FIG. 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 "Accident Suspension." The customer ID is information that identifies each customer who has a periodic payment contract with the recipient in this embodiment. In the case of a membership-based service where the fee is paid on a periodic payment contract, the member ID may be recorded as the customer ID, and in the case of a mobile phone service, a mobile phone number may be recorded as the customer ID. The password is information recorded to enhance security when identifying an individual customer for viewing or editing their personal page.

[0016] "Payment Type" is a field in which the type of payment method for the recurring payment fee is recorded; for example, values ​​such as 1 for automatic debit, 2 for credit card payment, and 3 for transfer by transfer slip are recorded. "Payment ID" is an ID used to confirm payment or non-payment of the recurring payment fee; although the customer ID may also be used, if an ID separate from the customer ID is used, it is recorded here. For example, in the case of credit card payment, all or part of the credit card number is recorded as the ID.

[0017] "Option contract presence / absence" is a field that records whether a non-payment option contract has been concluded as an ancillary contract to a periodic payment contract. In this embodiment, the periodic payment contract specifies the measures to be taken in the event of non-payment on a certain payment due date. The non-payment option contract is an ancillary contract that provides preferential treatment for that measure. Preferential treatment can mean preferential treatment regarding the timing or content of the measure, and in this embodiment, it is preferential treatment regarding timing. In other words, in this embodiment, the ancillary contract provides preferential treatment in that the measure is taken immediately if there is no non-payment option contract, but not immediately if there is a non-payment option contract. Hereinafter, the main periodic payment contract will be referred to as the main contract. For the non-payment option contract, a fee must be paid (hereinafter referred to as the option fee) in addition to the fee for the main contract (periodic payment fee).

[0018] The "Option Effect" field is a field that records a value indicating whether a non-payment option contract is valid or invalid when a non-payment option contract is concluded. Normally, it is valid (true value), but once the benefit of the non-payment option contract has been used (when there is a non-payment but no immediate action is taken due to the non-payment option contract), it is invalidated. In this case, a false value is recorded in "Option Effect." Hereinafter, the use of the benefit of a non-payment option contract will be abbreviated as "use of non-payment option." "Option in Use" is a field that records whether the non-payment option is in use. A true value means that the non-payment option is in use, and a false value means that it is not in use. "Accidentally Suspended" is a field that records whether the effectiveness of a periodic payment contract (provision of a service or product) has been suspended due to non-payment. A true value means that it has been suspended, and a false value means that it has not been suspended.

[0019] The memory unit 1 stores a payment status file 12 as a separate file for managing regular payments. The payment status file 12 is a file that records the payment status of fees for each payment due date in a regular payment contract. In this embodiment, a 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 FIG. 4 , the payment status file 12 is a database file containing 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 customer information file 11. The individual payment ID is generated and recorded to identify the payment obligation for each payment due date. For example, it may be generated by combining the customer ID and a number indicating the payment due date. In the case of direct debit, the individual payment ID is determined in advance with the bank (automatic debit server 61), and the debit server 61 transmits the ID and the status of the debit completion to the management server 10. In the case of a collection agent that sends a transfer slip to perform a bank transfer, the individual payment ID is incorporated into a code symbol (e.g., a barcode) printed on the transfer slip. In the case of credit card payments, an ID is generated for each payment (each use of a credit card), and the ID is often used to monitor whether the direct debit has been successfully completed. In this case, the credit card company (card company server 62) notifies the recipient (management server 10) of each individual payment ID in advance and sends a notification as to whether or not the bank withdrawal for that ID has been completed. In this case, the individual payment ID notified in advance is recorded.

[0021] The payment status file 12 is created in advance before the payment due date for the payment status to be recorded, and values ​​for each field except for "Payment status" are recorded in advance. In other words, values ​​are recorded in advance for all customers with whom the recipient has a fixed-term payment contract, except for "Payment status." For "Amount," in the case of a fixed membership fee, the amount is recorded at the same time as the file is created. For variable expenses such as mobile phone usage fees, the fee is determined on the closing date and notified or invoiced to the customer, so the determined fee is recorded in the "Amount" field after the closing date. Typically, a fee determination program that determines the fee is installed in the management server 10, and a value is recorded in the "Amount" field by executing this program. There is no default value for the "Payment status" field.

[0022] The management server 10, which functions 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 for each payment due date (hereinafter referred to as due date status information) from each payment server 61-63. The management server 10 is equipped with a program (hereinafter referred to as the payment status recording program) 31 that receives due date status information through inter-server communication with each payment server 61-63 and records the transmitted due date status information in the payment status file 12. Upon receiving due date status information from each payment server 61-63 through inter-server communication, the payment status recording program 31 opens the payment status file 12 for that due date, searches the payment status file 12 for the individual payment ID contained in the due date status information, and records the payment status in the corresponding record in the payment status file 12. The due date status information transmitted from each payment server 61-63 includes payment status information in addition to the individual payment ID, so the payment status recording program 31 records this information (payment status) in the "payment status" field. If the due date information status includes payment amount information, the payment status recording program 31 may also confirm that the value recorded in the "amount" field in the payment status file 12 matches the payment amount included in the due date status information. Instead of the payment status recording program 31, a program that records whether a 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 set to a true value (paid), and the non-payment recording program is implemented to change this to a false value (not paid) if a payment has not been made.

[0023] As shown in Figure 2, a management terminal 7 operated by a person in charge at the recipient is provided as a terminal with access rights to the payment status file 12 in the storage unit 1. In exceptional cases, due date status information may be recorded in the payment status file 12 by the management terminal 7, separate from the receipt of due date status information from each of the payment servers 61 to 63. When a customer transfers money to the recipient's bank account at an ATM or over the counter without using a transfer slip, the person in charge confirms this and records that a payment has been made in the "Payment" field of the customer's record on the management terminal 7.

[0024] Next, the accident information output means will be described. A payment monitoring program 41 and an accident information output program 42 are implemented on the management server 10, which functions as the accident information output means. 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 implemented thereon an accident reminder output program 43, an option use output program 51, and an option use reminder output program 44, which are programs that are called and executed by the payment monitoring program 41.

[0025] FIG. 5 is a flowchart outlining the payment monitoring program 41. The payment monitoring program 41 is automatically executed each time a payment due date for a regular payment passes. For example, if the regular payment is a monthly payment and the due date is the end of each month, the program is automatically executed at a fixed time (e.g., 12:00 AM) on the first day of the following month. The execution time of the payment monitoring program 41 is set to the time after due date status information is transmitted from all payment servers 61-63 and the payment status recording program 31 is executed. The recipient has agreed with each collection agent and each credit card company that due date status information must be transmitted by a fixed time on the day following the due date. The automatic execution time of the payment monitoring program 41 is set to a time after this fixed time. Even when a person in charge operates the management terminal 7 to record the payment in the payment status file 12, it is also agreed within the company that the process must be completed before the automatic execution time.

[0026] When the payment monitoring program 41 starts at the automatic execution time, as shown in Figure 5, it opens the payment status file 12 created for the most recent payment due date. It then obtains the customer ID from the first record in the customer information file 11, searches the payment status file 12 for that customer ID, and obtains the "payment status" value for the corresponding record. If this value is false (no payment), it first executes a non-payment recording program (not shown). The memory 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 non-payment in the non-payment information file 13.

[0027] As shown in FIG. 5, after recording the non-payment, the payment monitoring program 41 references the value of the "Non-payment Option Contract" field of the corresponding 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 outputting accident information. At the same time, the customer information file 11 is searched for the customer ID, and the "Stopped Due to Accident" field of the corresponding record is changed to a true value. Furthermore, the accident reminder output program 43 is executed as a subroutine. If "Payment" is false and "Non-payment Option Contract" is true, the program further references "Option Effectiveness." If this is false, the payment monitoring program 41 similarly executes the accident information output program 42 and the accident reminder output program 43. At this time, if the value of "Option in Use" is true, it is changed to a false value. If "Option Effectiveness" is true, the accident information output program 42 is not executed, and instead the option use output program 51 is executed. Furthermore, the option use reminder output program 44 is executed as a subroutine.

[0028] If "payment or no payment" is a true value (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 acquires the customer ID. Even if no payment has been made and the accident reminder output program 43 or the option use reminder output program 44 has been executed, the payment monitoring program 41 acquires the next customer ID. The same processing is then repeated. When the processing has been repeated up to the last record in the customer information file 11, the program ends.

[0029] The payment monitoring program 41 may also be executed immediately after the payment due date (for example, at midnight or 12:10 AM the following day). Automatic bank withdrawals and credit card payments are usually made at a certain time during the day, and if the withdrawal or payment is not made at that time, the payment is confirmed as non-payment. Also, even if a payment is made by bank transfer slip, even if it is made just before 12:00 PM, the payment is reflected within a few minutes because it is processed by the server. Therefore, the program may also be executed automatically at midnight or 12:10 AM.

[0030] To provide further information about the non-payment information file 13, the non-payment information file 13 is a database file created for each customer, and by using the customer ID in the file name, 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 for which a payment has not been made. The "payment due date" is the payment due date for which the payment was not made, and the "amount" is the amount of the non-payment. This amount includes the fee for the main contract as well as the option fee if a non-payment option contract is in place.

[0031] To further explain the accident information output program 42, as shown in FIG. 2, the storage unit 1 stores an accident information file 14 in addition to the non-payment information file 13. The accident information file 14 is also created for each customer and can be identified by a customer ID. The accident information file 14 is a database file that has fields such as "accident information output date" and "suspension release date," and records 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 fixed-term payment contract, but regardless of the configuration, the accident information output program 42 typically includes recording to the accident information file 14 as a common process. That is, the accident information file 14 corresponding to the customer is opened using the customer ID, and the date the program was executed is recorded 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 fixed-term payment contract is a contract for using 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 is added to the information (database) registered at each base station as the telephone number or terminal identification number for which communication is not permitted, and then registered.

[0033] If the fixed-term payment contract is for the provision of some kind of membership service and a membership ID has been issued, the accident information output program 42 performs processing to invalidate the membership ID. For example, if a fitness club employs a system in which members pass through a gate using a membership card, the fact that the member ID is invalid is stored in the memory unit 1 on the gate, and if the membership card with that member ID is read, the gate will not allow passage.

[0034] Furthermore, if the credit card payment is a regular payment, the program allows the information of the member associated with the customer ID to be added to a database file recording the information of the member to whom a reminder letter is to be sent. Also, if necessary, the program adds the information of the member associated with the customer ID to a database file (a so-called blacklist) that stores information on accident victims shared among credit card companies. Furthermore, if a regular payment contract covers regular product deliveries, the accident information output program 42 deletes the delivery address associated with the customer ID from the database file recording the delivery address information. Then, the program executes a subroutine to print a postcard stating that the product will not be shipped due to non-payment.

[0035] Next, the option usage output program 51 constituting 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. There are several possible configurations for outputting to a file, but in this embodiment, the option usage output program 51 is a program that outputs information about option usage to the customer information file 11 and rewrites the "option effect" field. Specifically, the option usage output program 51 is executed with a customer ID as an argument, and performs processing to change the "option effect" of the record related to that customer ID to a false value (no effect).

[0036] Next, a supplementary explanation will be given of the two dunning output programs 43, 44. In this embodiment, the two dunning output programs 43, 44 are provided in order to provide different dunning methods for cases where there is non-payment and accident information is output, and cases where there is non-payment but accident information is not output because there is a non-payment option contract. Even if there is a non-payment option contract, there is still non-payment, so dunning is necessary. In this case, since the provision of the service or product has not been suspended, the dunning may be suspicious. It is also necessary to clearly warn the user that accident information will be output if there is non-payment on the next payment due date. For this reason, the option usage dunning program 44 is implemented as a configuration for outputting dunning information when the non-payment option is used.

[0037] Both of the dunning output programs 43 and 44 can be programs that output a dunning notice in the form of an email to the customer terminal 8, which is a terminal operated by the customer (i.e., send a dunning email), or programs that print a dunning notice (output a dunning notice on a printer). Furthermore, when regular payments are made by automatic bank withdrawal or credit card payment, there may be an agreement that in the event of a default, a transfer slip is issued and the payment is to be made using a separate transfer slip. In this case, both of the dunning output programs 43 and 44 are configured to print a transfer slip for the default amount. Furthermore, when the fixed-term payment contract is a smartphone service contract or a provider service contract, even if email transmission and reception with the customer terminal 8 is disabled due to the output of accident information, the dunning output programs 43 and 44 are configured to output a dunning notice.

[0038] The accident prompt output program 43 is configured to output a prompt including a message that the provision of the service or product has been discontinued due to non-payment and a request to pay the unpaid amount immediately. The option use prompt output program 44 is configured to output a prompt including a message that the payment has been discontinued and that the provision of the service or product has not been discontinued because a non-payment option contract has been concluded, and a request to pay the unpaid amount by the next payment due date.

[0039] In addition, when a non-payment option contract is concluded, the contract may stipulate that payment, including the unpaid amount, on the next payment due date is sufficient. In this case, an option use notification output program may be implemented to notify the customer that the option is being used without including any reminder content. The option use notification output program is a program that outputs a notification that, although payment has not been made, the provision of the service or product will not be suspended because a non-payment option contract has been concluded, and that the next payment due date will be the payment for two installments. The option use notification program may also be a program that outputs the notification to the customer terminal 8 via email or a program that prints it on a notification postcard.

[0040] The option use prompting program 44 and the option use notification output program described above can also be considered to be a type of option use output program. That is, they output information about the use of an option to the customer terminal 8 or to the printer, and can be considered to be a type of option use output program.

[0041] In this embodiment of the non-payment handling system, several programs are implemented to record payments (repayments) made in relation to non-payments. These programs are described below. First, the management server 10 is implemented with a repayment record program 101 that records repayments made in relation to non-payments. Figure 6 is a flowchart showing an outline of the repayment record program 101.

[0042] In the event of a default, the recipient typically mails a special transfer slip to the customer, instructing them to make a bank transfer to pay the outstanding amount. The transfer slip is printed with a code symbol (e.g., a barcode) containing the customer ID of the defaulting customer and an individual payment ID that identifies the defaulted amount (payment due date). The customer then uses the transfer slip to pay the outstanding amount at a convenience store or other location. When payment is made, repayment information (indicating that the repayment has been made, the customer ID, and the individual payment ID) is sent from the payment servers 61-63 operated by a collection agent or similar 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 default information file for the customer according to the customer ID included in the repayment information and searches for the individual payment ID. The program then records the execution date of the program in the "repayment date" field of the relevant record.

[0043] The management server 10 stores an accident suspension resolution program 102 and an option reinstatement program 103 as programs that can be called and executed from the repayment recording program 101. The accident suspension resolution program 102 is a program for reinstating the provision of services or products based on the main contract when all unpaid amounts have been repaid. The option reinstatement program 103 constitutes an option reinstatement means, and is a program for reinstating an option when repayment is made by or at the next payment date after the unpaid option has been used.

[0044] After recording the repayment date in the record associated with a specific individual payment ID as described above, the repayment record program 101 references the value of "Accidental suspension" for the corresponding record in the customer information file 11. If this is a true value, the repayment record program 101 references the payment status file 12 again to determine whether the "Repayment date" is a null value for all records. If it is determined that the "Repayment date" for all records has a date recorded and is not a null value, the repayment record program 101 executes the accidental suspension resolution program 102. If there is even one record with a null value, the repayment record program 101 does not execute the accidental suspension resolution program 102.

[0045] The accident suspension resolution program 102 opens the accident information file 14 for the customer according to the customer ID. Then, it records the program execution date in the "Suspension Release Date" field of the last record. It also opens the customer information file 11 and resets "Accident Suspension" in the record for the customer ID to a false value. Furthermore, if the "Option Contract Status" field for the record is a true value, it resets the "Option Effectiveness" field to a true value (valid). The accident suspension resolution program 102 then performs the processing necessary to resume the provision of the service or product. For example, if the smartphone usage contract is subject to a fixed-term payment contract, it deletes the telephone number or terminal identification number for the customer ID from the communication denial list at each base station. In the fitness club example mentioned above, it deletes the customer's membership ID from the list of invalid membership IDs stored in the memory unit 1 on the gate. Other appropriate processing is performed depending on the content of the fixed-term payment contract.

[0046] Next, the repayment record program 101 references the values ​​of "option contract existence / nonexistence," "option validity," "option in use," and "discontinued due to accident" for the corresponding record in the customer information file 11. If "option contract existence / nonexistence" is true, "option validity" is false, "option in use" is true, and "discontinued due to accident" is false, the repayment record program 101 executes the option validity revival program 103 as a subroutine. If this condition is not met, the option validity revival program 103 is not executed.

[0047] The option reinstatement program 103 is a program for reviving an option that has been invalidated but is not in an accident suspension state, separate from the case where a customer with a non-payment option contract has cancelled the accident suspension. That is, this program processes the reinstatement of an option when the option is invalidated by the option usage output and repayment is made by the next payment due date or at the next payment time. If the unpaid amount is to be paid separately by bank transfer slip, the condition for option reinstatement is that the payment is made by the next payment time. If the unpaid amount is to be paid in addition to the next payment time, the condition for option reinstatement is that repayment is made at the next payment time.

[0048] In either case, "Option in use" is a true value and "Option effect" is a false value in the record for that customer in the customer information file 11. When the option effect restoration program 103 is started, it confirms that "Option in use" is a true value and "Option effect" is a false value, and then performs processing to reset "Option in use" to a false value and "Option effect" to a true value. This returns to the original state, i.e., a state in which the non-payment option is not being used and the non-payment option contract is valid.

[0049] If the unpaid amount is not repaid by the next payment due date and the next payment due date also becomes unpaid, or if the amount including the additional amount (the amount for two periods) is not paid at the next payment due date, "option effect" will remain false (invalid), and the accident information output program 42 will be executed. In this case, "option in use" will be reset to false, but "option effect" will remain false.

[0050] As mentioned above, the non-payment option contract is a paid contract that is ancillary to the main contract and is optional. When concluding the main contract, the customer chooses whether or not to enter into the non-payment option contract. If the customer enters into the non-payment option contract, a value indicating the existence of the non-payment option is recorded in the "non-payment option" field of the customer information file 11, as mentioned above. The configuration for this will be explained in more detail below. The following explanation uses as an example a periodic payment contract concluded for the purpose of providing a certain membership service. The recipient also operates a server for providing such membership services. This server may be a separate server from the management server 10, or they may share the same server. In the following explanation, it is assumed that they share the same server.

[0051] The management server 10 provides a web page for member registration, which is required to provide member services. FIG. 7 is a schematic diagram showing an example of a customer registration page provided by the management server 10. The customer registration page displays a description (text) of the member services as well as a description of the non-payment option. In this example, the option fee is paid on each payment due date in addition to the base contract fee, and this description is also included. As shown in FIG. 7, the customer registration page includes a personal information input field, a confirmation button for input information, and a non-payment option selection field 104.

[0052] A customer registration program (not shown) is installed in the management server 10. In the customer registration page shown in Figure 7, the confirmation button 105 links to a confirmation page for the input information, and the send button provided there serves as an execution button for 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 "Non-payment option contract presence / absence" field according to the selection made in the non-payment option selection field 104.

[0053] The above customer registration page was an example in which information is recorded in the customer information file 11 by the customer entering and submitting it themselves. However, a configuration is also possible in which the information is entered by a person in charge at the recipient or a person in charge at a sales agency in the recipient's business. For example, if the recipient is a smartphone telecommunications provider, a service contract may be concluded at the sales agency's storefront. In this case, a customer information registration page for the sales agency is prepared in the management server 10, and a terminal installed at the sales agency's storefront accesses the management server 10 to display the customer registration page, where 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 is purchased. Of course, a terminal may be installed at a counter directly operated by the recipient, rather than at a sales agency, and the customer information registration page may be displayed and input.

[0054] The operation of the non-payment handling system of this embodiment will be briefly described below. When the receiver enters into a periodic payment contract with each customer, the receiver explains to each customer that an optional supplemental non-payment option contract can be entered into. The customer chooses to enter into the non-payment option contract. In this case, the non-payment option selection field 104 on the customer registration page shown in FIG. 7 is entered into, or the non-payment option selection field 104 on the customer information registration page for the sales agent is entered into, and the information is recorded in the customer information file 11. This information includes whether or not the option contract is entered into.

[0055] A customer who selects the non-payment option contract pays the fee for the non-payment option contract in addition to the fee for the main contract on each payment due date. When each payment due date has passed, each payment server 61 to 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 passed 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, the "Payment Status" value of the corresponding record is referenced, and if it is false, the "Option Contract Status" value is referenced. If this value is false, there is no non-payment option contract, so the accident information output program 42 is executed. If the "Option Contract Status" value is true, the "Option Effectiveness" value is referenced. If this value is false, a non-payment option contract has been concluded but has already been used and expired (a state in which the option benefit has been exhausted due to past non-payment), so the accident information output program 42 is also executed. If both the "Option Contract Status" and the "Option Effectiveness" values ​​are true, the payment monitoring program 41 does not execute the accident information output program 42, but instead executes the option usage output program 51. This changes the "Option in Use" field of the corresponding record in the customer information file 11 to a true value. Note that when the accident information output program 42 is executed, a true value is recorded in the "Accident Suspended" field of the corresponding record in the customer information file 11.

[0057] In this way, after each payment deadline 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. Then, if "option contract existence / non-existence" is a false value, or if "option contract existence / non-existence" is a true value and "option effectiveness" is a false value, the accident information output program 42 is executed. Furthermore, the accident reminder output program 43 is executed. If no payment has been made and the "option effectiveness" is a true value, the accident information output program 42 is not executed, and the option use output program 51 is executed. Furthermore, in this case, the option use reminder output program 44 is executed.

[0058] When a customer who has defaulted pays the unpaid 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. The program then searches the customer information file 11 using the customer ID and determines whether "Suspended due to an accident" is a true value in the corresponding record. If it is a true value, the program determines whether "Repayment date" is recorded in all records in the payment status file 12. If it is recorded, the program executes the accident suspension resolution program 102. The accident suspension resolution program 102 opens the accident information file 14 corresponding to the customer ID and records the program execution date in the "Accident Resolution Date" field of the last record. At the same time, the program changes "Suspended due to an accident" in the record for the customer ID in the customer information file 11 to a false value. Furthermore, if "Option Contract Existence" is a true value, the program resets "Option Effectiveness" to a true value (valid).

[0059] Next, if "option contract existence" is true, "option validity" is false, and "suspended due to accident" 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 "option validity" to a true value. If the payment for the unpaid amount is before the next payment due date, "option validity" will be true at the next payment due date, so if the next payment due date also becomes unpaid, the payment monitoring program 41 does not execute the accident information program but executes the option usage output program 51. As a result, the provision of the service or product continues without being stopped.

[0060] This non-payment handling system provides customers with peace of mind, knowing that even if a non-payment occurs for some reason, the provision of the service or product will not be suspended for the first time. Meanwhile, the recipient continues to provide the service or product despite the risk of defaulting on the next payment due date and being unable to fully collect the debt, but receives an option fee in return. This allows the recipient to earn revenue that covers the overall debt collection costs, separate from the base fee, and allows the recipient to conduct its periodic payment contract business with peace of mind. Furthermore, knowing that a non-payment option service is available and can be selected for use by customers improves the recipient's business impression and leads to increased sales. Furthermore, the option fee is borne only by customers who are aware that they are likely to default, ensuring fair cost sharing.

[0061] Furthermore, in the non-payment handling system of the embodiment, option usage information is output together with information that can identify the customer involved in the usage, so that the option usage information can be used for various purposes. The above example is an example of outputting to a file, and an example of invalidating the "option effect" in the customer information file 11. This is a configuration to implement in the system the fact that once the profits of a non-payment option contract are used, they cannot be used for a second consecutive non-payment.

[0062] In relation to the above, a configuration in which the management server 10 is equipped with an option usage output program 51 that temporarily disables the option when the non-payment option is used, and an option reactivation program 103 that subsequently reactivates the option, is particularly beneficial. A possible configuration for preventing the use of the benefits of a non-payment option contract for the second non-payment after two consecutive non-payments is to refer to the payment status on the previous payment date when a non-payment occurs on a certain payment due date, and if there is also a non-payment on that payment due date, immediately output accident information even if a non-payment option contract has been concluded. While this configuration is acceptable, if a non-payment is followed by repayment before the next payment due date, the non-payment option should be available for the non-payment on the next payment due date. A configuration that refers to the payment status on the previous payment due date would not be able to address this issue (reactivate the benefits of a non-payment option contract). The option reactivation program 103 is a program that records that the use of the non-payment option has ended with repayment at or before the next payment date, and allows the non-payment option to be used again if a subsequent non-payment occurs. Therefore, even if a customer defaults on a payment, the customer will have an incentive to repay the payment on or before the next payment due date to restore the benefit of the non-payment option contract, which is significant in encouraging payment of the unpaid amount.

[0063] The output of option usage information can be used in various ways other than those described above. A second embodiment will be described below, which uses the option usage information in a different way. In the second embodiment, the option usage output means 5 has a configuration that is not included in the first embodiment. That is, in the second embodiment, although the option usage output means 5 has a configuration that outputs and records non-payment option usage in a file, a configuration is adopted in which all option usage is recorded as history information. To achieve this configuration, an option usage history information file 52 is stored in the storage unit 1.

[0064] FIG. 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 as the file name. As shown in FIG. 8, the option usage history information file 52 is a database file that records records consisting of fields such as "usage ID," "usage start date and time," "usage end date and time," and "termination reason." The option usage history information file 52 is a file that records one record for each use of a non-payment option, and the "usage ID" is a field that records information that identifies the record. For example, a sequential number is recorded as the usage ID.

[0065] The "use start date and time" field records the date and time the option use output program 51 was executed. The "use end date" field records the date and time the use of the non-payment option ended. The "termination reason" field records the reason for the termination of the non-payment option. In this embodiment, there are two types of non-payment option usage. One is the aforementioned repayment termination, in which the use of the non-payment option begins with a default on a certain payment due date, and then ends when the default 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 in which the option is used and terminated without making a payment on or before the next payment due date, in which the benefit of the non-payment option has been used up and the option is terminated. Hereinafter, this termination will be referred to as "used termination." As can be understood from the above explanation, in the case of "used termination," the payment monitoring program 41 will execute the accident information output program 42.

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

[0067] The option usage output program 51 in the second embodiment similarly searches the customer information file 11 by customer ID, changes the "option validity" of the corresponding record to a false value, and changes the "option in use" to a true value. Next, the option usage output program 51 determines whether there is an option usage history information file 52 with the customer ID as the file name. If there is not, it creates a new one with the customer ID as the file name. The option usage output program 51 adds a new record to the option usage history information file 52 with the customer ID as the file name, and records a sequential number (the value of the last record + 1) in the "usage ID" (1 if a new record is created). Next, it records the program execution date and time in the "usage start date and time." It also records the next payment due date as the default value in the "usage end date," and records the default value as "used and terminated" in the "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 a non-payment option is used for a specific customer ID.

[0068] In the second embodiment, the configuration of the option effect revival program 103 is slightly modified. In the second embodiment, too, if an unpaid option is used and the unpaid amount is repaid before or at the next payment due date, the option effect revival program 103 is executed, and the value of "option effect" in the customer information file 11 is returned to a true value. After performing this process, the option effect revival program 103 in the second embodiment opens the option use history information file 52 created for the customer in accordance with the customer ID, records the program execution date in the "use end date" of the last record, and records the end of repayment in the "termination reason."

[0069] According to the second embodiment of the non-payment handling system, the option usage history information file 52 records the usage history of each non-payment option for each customer, allowing for effective use of this information. For example, if a non-payment option is not used for a specified period of time, or if it is used only infrequently, the option fee can be reduced or waived. In this case, an option fee change program is implemented in the management server 10. The option fee change program is executed periodically (e.g., after each payment deadline has passed, after the payment status monitoring program has been executed, etc.), opens the option usage history information file 52, and counts the number of records (number of times the option was used) within that period. If the number is below a predetermined number, the option fee is reduced. The memory unit 1 stores a billing information file that records the payment amount (billing amount) for each customer on each payment due date. The management server 10 also includes a payment amount notification program that notifies each payment server 61-63 of the billing amount recorded in the billing information file according to each customer's payment method. The option fee change program in this case is a program that reduces or sets to zero the amount of the option fee when recording the billing amount in this billing information file.

[0070] When counting the number of uses of the default option, it is possible to give preferential treatment to usage history where repayment has been completed. A completed repayment indicates that the default was repaid by or on the next payment due date, and does not indicate a significant delay in payment. On the other hand, a used-up option indicates that two defaults occurred and the accident information was output. If all defaults are repaid after the accident information is output, the "option valid" status will change to "Yes," but this indicates a significant payment delay. Therefore, the option fee may be reduced or waived for a completed repayment even if there are a certain number of defaults, while for a used-up option, the fee may not be reduced or waived unless the default occurs once or a few times. For example, in the case of monthly fixed-term payments, a completed repayment may be reduced or waived up to once a year, but for a used-up option, the fee may not be reduced or waived unless it occurs once every two years or less. In addition, the conditions for reduction and waiver may be differentiated, such that if the non-payment option is used zero times in a year, the option fee thereafter is free, and if it is used once in a year, the fee is reduced thereafter.

[0071] Conversely, systems can also be configured so that option fees increase depending on the frequency of use of the non-payment option. For example, an option fee change program may be implemented so that initially, only 100 yen is added to the monthly payment, but if the non-payment option is used once, the price increases to 110 yen, and if used twice, the price increases to 120 yen. In this case, an option fee change program may be implemented so that if the non-payment option is not used for a certain period of time (e.g., one year), the price is reduced to the original 100 yen. In either case, this treatment creates an incentive for each customer to avoid paying as much as possible, resulting in a reduction in non-payment for the customer as a whole. In this way, by recording the option usage history in a file, the usage history can be used effectively.

[0072] In the above explanation, it was stated that when all unpaid amounts are paid, the accident suspension elimination program 102 or the option reactivation program 103 operates to reactivate the unpaid option contract. However, if the unpaid option is used frequently, the accident suspension elimination program 102 or the option reactivation program 103 may be implemented to wait a short time before reactivating (reactivating). For example, a customer who frequently uses an unpaid option may be reactivated after one month, and for a customer who uses an unpaid option even more frequently, the option may be reactivated after two or even three months. This configuration creates an incentive to make as many unpaid amounts as possible. The accident suspension elimination program 102 can also be said to constitute an option reactivation means.

[0073] Furthermore, the option fee change program may be configured to be executed periodically (based on time), or may be executed based on conditions other than time. Typically, the option fee change program is executed when circumstances arise at the recipient that require a change to the option fee. In this case, the option area change program is executed in response to a request from the management terminal 7. Separately, the option fee change program may be read from the option usage output program 51 and executed. When the option usage output program 51 outputs the option usage, it references the option usage history information file 52 for the customer to obtain the total number of option usages. If the number of options has reached a certain limit, it automatically calls and executes the option fee change program. Such a configuration may also be adopted.

[0074] In the above embodiments, the benefit of a non-payment option contract is the preferential treatment of the timing of the measure, but it may also be the preferential treatment of the content of the measure. For example, in the case of non-payment, penalties may be imposed in the form of interest or late damages, but if a non-payment option contract is in place and valid, the amount of the penalty may be reduced or even eliminated. Also, in the case of credit services such as credit cards, the benefit of an option contract may be that if a non-payment option contract is in place, a single non-payment will not result in being placed on a so-called blacklist.

[0075] Furthermore, when installment payments are made on a periodic basis, there may be a clause stipulating that failure to pay results in a lump-sum repayment. In this case, if there is a non-payment option contract, it may be agreed that a single non-payment does not necessitate a lump-sum repayment, but a second non-payment will trigger a lump-sum repayment. In addition, when a regular product delivery (subscription) is subject to periodic payments, there may be cases where benefits such as discounts, free shipping, and free shipping on returns are offered as standard, and such benefits are lost in the event of non-payment. In this case, the benefit of a non-payment option contract is that these benefits will continue to be offered without being canceled by a single non-payment. In any of these cases, the configurations of the above embodiments can be applied.

[0076] In the above embodiments, the option fee is paid by adding it to the main fee on each payment due date, but it may be paid in a lump sum at the time of signing the 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 main fee again and paid in a lump sum on the next payment due date, so that the option effect restoration program 103 is executed.

[0077] Furthermore, in the above-described embodiments, whether or not to use the non-payment option contract is determined when the main contract is concluded, and if so, this is recorded in the customer information file 11. However, it is preferable to be able to change the non-payment option contract to be included after the main contract is concluded. An example of this configuration is shown in FIG. 10 . FIG. 10 shows an example of a My Page provided to each customer by the management server. My Page is a web page provided to each customer by the management server 10, and allows the customer to confirm the contract details, change registered personal information, change some of the contract details, etc. 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, My Page shown in FIG. 10 is displayed on the customer terminal 8.

[0078] As shown in Fig. 10, My Page has an option contract availability change input field 106. In this example, the option contract availability change input field 106 is a radio button. The HTML file that displays My Page has embedded therein a code that searches the customer information file 11 using the customer ID, obtains the value of "option contract availability" for the corresponding record, and displays the default value (yes or no) for the option contract availability change input field 106 accordingly.

[0079] As shown in FIG. 10 , My Page has a confirmation button 107. The confirmation button 107 links to a confirmation page, and the OK button on the confirmation page functions as an execution button for a My Page change registration program (not shown). When changes are entered into the option contract change input field 106, the confirmation button 107 is pressed, and the OK button on the confirmation page is pressed, the My Page change registration program changes the value of the "option contract presence / absence" in the customer information file 11. Therefore, it is possible to change an initial non-payment option contract from not having one to having one, or to change an initial non-payment option contract from having one to not having one. Note that, if an option fee is added to the main contract fee and paid on each payment due date, when the option contract presence / absence is changed, the change is reflected in the program that calculates the payment amount for each payment due date, and the management server 10 notifies each payment server 61-63 so that the payment is made at the changed amount.

[0080] In the above embodiments, the non-payment option contract was an ancillary contract attached to the main contract, but it may also be included in the main contract. That is, a main contract with a non-payment option clause and a main contract without a non-payment option clause may be available, and the customer may choose either one. Alternatively, the non-payment option clause may be included as a standard clause in the main contract, remaining in effect unless the customer cancels (terminates) it. In this case, the non-payment option contract may be checked by default (in the contract state) on the My Page, and the contract may continue unless the customer unchecks it. The same applies to other input fields, and the contract may continue unless a cancellation entry is made. In this case, canceling the contract will result in a deduction of the non-payment option fee from subsequent periodic payments.

[0081] In each of the above embodiments, a configuration may be adopted in which different grades of non-payment option contracts are available, and the customer selects one grade to enter into the non-payment option contract. The grade of the non-payment option contract, for example, refers to the length of the grace period for measures in the event of non-payment. Higher grades provide a longer grace period. For example, while a standard non-payment option contract, as described above, provides a grace period until the next payment, higher grades provide a grace period until the next payment, and the highest grade provides a grace period until the next payment. The fee for the non-payment option is higher for higher grades. The customer information file 11 also records information about the grade of the non-payment option contract, and the accident information output program 42 determines whether the grace period has elapsed by referring to the grade information and outputs accident information if it has elapsed. Additionally, the grade of the non-payment option contract may refer to the level of the measures in the event of non-payment (the degree of advantage compared to when there is no non-payment option contract).

[0082] In each of the above embodiments, the periodic fee may be paid using various types of goods. That is, the periodic fee may be paid using goods such as crypto assets (virtual currencies), tokens, prepaid money or other electronic money, currency-denominated assets, etc. Also, a configuration may be adopted in which points (goods that are used as a discount on subsequent purchases) awarded according to the purchase amount of a product or service are used to pay the periodic fee.

[0083] REFERENCE SIGNS LIST 1 Storage unit 11 Customer information file 12 Payment status file 13 Accident information file 2 Non-payment information receiving means 3 Non-payment information recording means 31 Payment status recording program 4 Accident information output means 41 Payment monitoring program 42 Accident information output program 5 Option usage output means 51 Option usage output program 52 Option usage history information file 61 to 63 Payment server 7 Management terminal 8 Customer terminal 9 Network

Claims

1. A non-payment response system used to take measures when a fee is not paid on a due date when a customer and a receiver have entered into a periodic payment contract under which a fee is paid at specified intervals and measures are taken in the event of non-payment, the system comprising: a storage unit; an accident information output means; and an option usage output means, the storage unit storing a customer information file that records information about each customer who has entered into a periodic payment contract with the receiver, and a payment status file that records the payment status of each customer on each payment due date, the customer information file storing information about whether a non-payment option contract has been concluded with the receiver on the condition that each customer pays an option fee to the receiver, the non-payment option contract being a contract stipulating that when a periodic payment fee is not paid on a certain payment due date, measures are taken at a specified time if there is no non-payment option contract, whereas if there is a non-payment option contract, measures are taken at a grace period relative to the specified time or measures that are more favorable to the customer than measures taken in the event that there is no non-payment option contract, The accident information output means is a means for outputting as accident information information for taking measures at the specified time or information for taking measures that are more disadvantageous to the customer than if there were a non-payment option contract; when a customer does not make a payment on a certain payment due date and the non-payment is recorded in the payment status file, the accident information output means is a means for referring to a customer information file and not outputting accident information if a non-payment option contract has been concluded for the customer, and outputting accident information if a non-payment option contract has not been concluded; the option usage output means is a means for outputting option usage information which is information that the benefits of the non-payment option contract have been used when a customer does not make a payment on a certain payment due date and the accident information is not output because a non-payment option contract has been concluded for the customer; and a system for dealing with non-payment in periodic payments characterized in that the option usage output means is a means for outputting option usage information together with information that can identify the customer related to the option usage information.

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

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

4. The customer information file records information on whether the non-payment option contract is valid or invalid for a customer with whom the non-payment option contract is concluded with the recipient, the option usage output means is a means for outputting the option usage information to the customer information file and for recording in the customer information file that the non-payment option contract for the customer is invalid, and after the option usage output means outputs the option usage information, option effect restoration means is provided for recording in the customer information file that the non-payment contract for the customer is restored to valid when repayment is made for the non-payment that caused the option usage information to be output, and the accident information output means is a means for, when a customer does not make a payment on a certain payment due date and the non-payment is recorded in the payment status file, referring to the customer information file, not outputting accident information if a non-payment option contract for the customer is concluded and is valid, and outputting accident information if a non-payment option contract has not been concluded or has been concluded but is invalid, The system for handling non-payment in periodic payments as described in 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 a non-payment option contract have been used, when a customer fails to make a payment on a certain payment due date and an accident information is not output because a non-payment option contract has been concluded and is valid for the customer.

5. A system for dealing with non-payment in periodic payments as described in claim 4, characterized in that the option reinstatement means is a means that is executed by the next payment due date if the repayment is made by the payment due date following the payment due date for the non-payment that caused the option usage information to be output.

6. A non-payment handling system for periodic payments as described in 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 which is sent to the customer.

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

8. A system for handling non-payment in periodic payments as described in claim 7, characterized in that it is provided with an option fee change means for changing the option fee in accordance with the option usage history recorded in the option usage history information file.

Images