Non-payment assistance system for 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 in the event of non-payment in a periodic payment contract where a fee is paid at predetermined intervals. [Background technology]

[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 due 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 the payment is automatically debited from the customer's bank account.

[0004] In any 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. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Publication No. 2020-38467 [Patent Document 2] JP 2018-45300 A Summary of the Invention [Problem to be solved by the invention]

[0006] If a party who defaulted on payments due to the measures described above subsequently makes a payment, the debt will be recovered and there will be no loss, but the issue of internal costs (effort) involved in implementing these measures remains. The contract is made after the periodic payment fee is determined with these costs taken into account, but this means that those who do not default also bear these costs, which could be said to be unfair. In anticipation of the costs of recovering from such non-payment, recipients may take out some 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 specified amount to the recipient. However, even in this case, the insurance premium is included in the regular payment fee as an overall cost, and there is still an unfairness in that those who do not default also 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 burden the recovery costs in the event of non-payment on customers, and that makes it possible to create an incentive for customers to avoid non-payment.

[0007] The applicant of the present application has disclosed an invention of a guarantee and compensation system for periodic payments in Patent Document 1. The problem awareness of the present invention differs from that of the invention of Patent Document 1 in the following points. 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. If the recipient fails to pay twice in a row, compensation is paid for the first non-payment, but 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, and the technology of Patent Document 1 is not suitable for such industries. The present invention also aims to solve this problem, and has as its object to provide a technology that makes it possible to prepare for the overall costs that will arise in the event of non-payment. [Means for solving the problem]

[0008] In order to solve the above problems, this specification discloses an invention of a non-payment handling system. The non-payment handling system of the disclosed invention is a non-payment handling system used to take measures when a fee is not paid by the due date in a periodic payment contract in which a customer and a receiver enter into a contract to pay a fee at predetermined intervals and measures are taken in the event of non-payment, and the system: A memory unit; accident information output means; Optional output means It is equipped with: The storage unit stores a customer information file recording information on each customer who has a periodic payment contract with the recipient, and a payment status file recording the payment status of each customer on each payment due date. The customer information file records information on whether or not a non-payment option agreement has been concluded with the receiver on the condition that the customer pays the option fee to the receiver, and A non-payment option contract is a contract that stipulates that if a regular payment fee is not paid on a certain payment due date, measures will be taken at a specified time if there is no non-payment option contract, whereas if there is a non-payment option contract, measures will be taken at a later time than the specified time, or measures that are more favorable to the customer than those that would be taken if there was no non-payment option contract. The accident information output means is means for outputting, as accident information, information for taking measures at the predetermined time or information for taking measures that are more disadvantageous to the customer than when there is a non-payment option contract. The accident information output means is a means for, when a certain customer does not make a payment on a certain payment due date and the non-payment is recorded in a payment status file, referring to a customer information file, not outputting the accident information if a non-payment option contract has been concluded for the customer, and outputting the accident information if a non-payment option contract has not been concluded. The option use output means is a means for outputting option use information which is information indicating that the profit of the non-payment option contract has been used when a certain customer does not make a payment on a certain payment due date and the accident information is not outputted because a non-payment option contract has been concluded for the customer. The option use output means is means for outputting the option use information together with information capable of identifying the customer related to the option use information. In addition, in order to solve the above problems, the disclosed non-payment handling system includes: 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 recorded, 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. It can have the following configuration. In addition, in order to solve the above problems, the disclosed non-payment handling system includes: The storage unit stores an option contract history information file that records the history of non-payment option contracts for each client, and the option contract history information file is a file that records information on the conclusion date and termination date of non-payment option contracts that the receiver has concluded with each client. It can have the following configuration. In addition, in order to solve the above problems, the disclosed non-payment handling system includes: The customer information file records information on whether the non-payment option agreement is valid or invalid for customers who have a non-payment option agreement 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 non-payment option contract for the customer is invalid, an option effect restoration means for restoring the effect of the non-payment option contract for the customer to a valid state in a customer information file when the non-payment that caused the output of the option use information is repaid after the option use output means has output the option use information; The accident information output means is a means for, when a certain 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 the accident information if a non-payment option contract has been concluded for the customer and is valid, and outputting the accident information if a non-payment option contract has not been concluded or has been concluded but is invalid, The option use output means is a means for outputting option use information, which is information indicating that the profit of the non-payment option contract has been used, when a certain customer does not make a payment on a certain payment due date and the non-payment option contract is valid and therefore the accident information is not output. It can have the following configuration. In order to solve the above problem, the non-payment handling system according to the disclosed invention comprises: The option revival effect means is a means that is executed by the next payment due date if repayment is made by the payment due date next to the payment due date of the non-payment that caused the output of the option use information. It can have the following configuration. In addition, in order to solve the above problem, in the non-payment handling system of 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 printing machine that prints it 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 comprises: The storage 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 an option usage history information file. It can have the following configuration. In addition, in order to solve the above problem, the non-payment handling system of the disclosed invention may be 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. [Effects of the Invention]

[0009] As explained below, the non-payment response system of 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, on the other hand, faces the risk of not being able to take appropriate timely or substantial measures to address non-payment, even though they run the risk of not paying again in the next payment period and being unable to fully collect on their debt. However, they can receive the option fee in return. This allows them to earn additional revenue that covers the overall debt collection costs, allowing them to conduct their regular payment contract business with peace of mind. Furthermore, knowing that a non-payment option service is available and available to customers improves the recipient's business image and leads to increased sales. Furthermore, the option fee is borne only by customers who are aware that they are likely to default, resulting in a fair cost burden. Furthermore, with a configuration in which option use information is output together with information that can identify the customer involved in the use, the option use information can be utilized for various purposes and optimized. In addition, if the option usage output means is a means for recording the invalidation of an unpaid option contract in the customer information file, and an option revival means is provided for recording the invalidation of the unpaid option contract for the customer after the unpaid amount that caused the option usage information to be output has been repaid, the customer will have an incentive to repay the unpaid amount early, and early recovery of the unpaid amount can be expected. In this case, if the unpaid amount is repaid by the next payment due date after the payment due date of the default, the option revival means is executed by the next payment due date. Therefore, even if a payment is defaulted once, if the payment is made by the next payment due date, the profit of the non-payment option contract can be obtained again on the next payment due date, which creates an additional incentive to repay the unpaid amount early, which is preferable in this respect. Furthermore, if the option usage output means is a means for outputting option usage information to a customer terminal that is a terminal operated by the customer, or a means for outputting option usage information to a printer that prints the information on paper that is sent to the customer, the customer can be notified that an unpaid option has been used, which increases 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 non-payment options can be effectively utilized. In this case, if an option fee changing means is provided to change the option fee according to the history of option use recorded in the option use history information file, the option fee is changed according to the amount of use of the non-payment option, so that the burden of the option fee on each customer becomes more equitable. [Brief explanation of the drawings]

[0010] [Figure 1] 1 is a schematic diagram of a non-payment handling system according to a first embodiment. [Figure 2] FIG. 2 is a schematic diagram showing an example of a more specific configuration of the non-payment handling system shown in FIG. 1. [Figure 3] FIG. 2 is a schematic diagram showing an example of the structure of a customer information file. [Figure 4] FIG. 10 is a schematic diagram showing an example of the structure of a payment status file for a certain payment due date. [Figure 5] 10 is a flowchart outlining a payment monitoring program. [Figure 6] 10 is a flowchart showing an outline of a repayment record program. [Figure 7] FIG. 2 is a schematic diagram illustrating an example of a customer registration page provided by a management server. [Figure 8] FIG. 10 is a schematic diagram showing an example of the structure of an option use history information file. [Figure 9]10 is a flowchart showing an outline of an option use output program according to the second embodiment. [Figure 10] An example of a personal page provided to each customer by the management server is shown. DETAILED DESCRIPTION OF THE INVENTION

[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 of this 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 fees are paid at specified 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 may be taken as a matter of course in accordance with social conventions. As shown in Figure 1, the non-payment handling system of this embodiment includes a memory unit 1, a non-payment information receiving means 2, a non-payment information recording means 3, an accident information output means 4, and an option usage output means 5.

[0012] Figure 2 is a schematic diagram showing an example of a more specific configuration of the non-payment handling system shown in Figure 1. As shown in Figure 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 by one server 10. Hereinafter, this server 10 will be referred to as the management server. The memory unit 1 is a storage such as an HDD provided in the management server 10, but may also be provided in another server such as a storage server or in a client. Management server 10 does not have to be a single server, and multiple servers may be integrated to function as management server 10. For example, a server may be provided for each of the non-payment information receiving means 2, non-payment information recording means 3, accident information output means 4, and option usage output means 5, or a server may be provided that partially integrates several means.

[0013] First, the non-payment information receiving means 2 will be described. The non-payment 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 non-payment 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 a payment has been made, and if a payment has not been made, the means receives information that a payment has not been made. The management server 10 is connected to each server (hereinafter referred to as payment server) 61 to 63 used when each customer pays a regular fee via a network 9. In this embodiment, the network 9 is the Internet.

[0014] In this embodiment, the recurring payment fee is paid by automatic debit from a bank account, credit card payment, or bank transfer. For this reason, the management server 10 constituting the non-payment information receiving means 2 is connected to a server for automatic bank debit (hereinafter referred to as the debit server) 61 and a server of the credit card company that manages credit card payments (hereinafter referred to as the card company server) 62. 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 fee, 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, the card company server 62, and the 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, various files for managing regular payments are stored in the storage unit 1. One of these files is a 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 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 Suspended." The customer ID is information that identifies each customer who has a regular payment contract with the recipient in the embodiment. If the fee for a membership-based service is a regular 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 individual customers for viewing and editing their personal pages.

[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 recurring payments. In some cases, the customer ID is also used, but if an ID other than the customer ID is used, it is recorded here. For example, in the case of credit card payments, all or part of the credit card number is recorded as the ID.

[0017] "Option contract presence / absence" is a field for recording 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 in addition to the fee for the main contract (periodic payment fee) (hereinafter referred to as the option fee).

[0018] The "Option Effect" field is a field in which a value indicating whether the effect of a non-payment option contract is valid or invalid is recorded when a non-payment option contract is made. Normally, it is valid (true value), but once the profit of a non-payment option contract has been used (when there has been a non-payment but no action was taken immediately due to the non-payment option contract), it becomes invalid. In that case, a false value is recorded in "Option Effect." Hereinafter, the use of the profit of a non-payment option contract will be abbreviated as the use of a 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 validity of a recurring payment contract (provision of services or products) 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 with 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 along with the completion status of the debit 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 embedded in 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 each individual payment ID in advance and sends a notification to the recipient (management server 10) 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. When the payment status recording program 31 receives due date status information from each payment server 61-63 through inter-server communication, it 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 of the payment status file 12 matches the payment amount included in the due date status information. It should be noted that a program that records that a payment has not been made (non-payment recording program) may be implemented instead of the payment status recording program 31. 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 the value to a false value (no payment) 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, apart from receiving due date status information from each of the payment servers 61-63, due date status information may be recorded in the payment status file 12 by the management terminal 7. 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. The management server 10, which functions as the accident information output means, is equipped with a payment monitoring program 41 and an accident information output program 42. 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 is also equipped with 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 a program that 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 has been sent from all payment servers 61-63 and the payment status recording program 31 has been executed. The recipient has agreed with each collection agent and each credit card company that due date status information must be sent by a fixed time on the day after the payment 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 agreed within the company that this should 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 presence / absence" 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 "Suspended 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 presence / absence" is false and "Non-payment option contract presence / absence" 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 false. 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 obtains 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 obtains the next customer ID. Then, the same processing is repeated. When the processing has been repeated up to the last record in the customer information file 11, the program ends.

[0029] It should be noted that 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 non-payment is confirmed. Also, even if a transfer is made using a transfer slip, even if the payment is made just before 12:00 PM, the transfer is reflected within a few minutes because it is processed by the server. Therefore, it may also be executed automatically at midnight or 12:10 AM.

[0030] To provide further explanation 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 as 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 a file created for each customer and can be identified by a 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 and recorded each time accident information is output. The configuration of the accident information output program 42 differs depending on the service or product that is the subject of the fixed-term payment contract, but in any configuration, the accident information output program 42 usually includes, as a common process, recording to the accident information file 14. 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 a 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 configuration 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 member cannot pass through the gate.

[0034] Furthermore, if the credit card payment is a regular payment, the information of the member related to the customer ID can be added to a database file that records the information of the member to whom a reminder letter is to be sent. Also, if necessary, the information of the member related to the customer ID can be added to a database file (a so-called blacklist) that stores information on people who have in trouble and is mutually operated by credit card companies. Furthermore, if the periodic delivery of goods is covered by a fixed-term payment contract, the accident information output program 42 deletes the delivery address associated with the customer ID from the database file in which the delivery address information is recorded.Then, it executes a subroutine that prints on a postcard a message stating that the goods will not be delivered 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 performs processing to rewrite 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 when there is a non-payment and accident information is output, and when there is a 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 a 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 customer that accident information will be output if there is also 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 reminder 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 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 contract or a provider contract, even if sending and receiving emails to and from the customer terminal 8 is disabled due to the output of accident information, the dunning output programs 43 and 44 are configured to output data for printing 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 usage notification output program may be implemented to notify the customer that the option is being used without including any reminder content. The option usage 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 usage 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 the non-payment handling system of this embodiment, several programs are implemented to record payments (repayments) when non-payments are made. These programs will be described below. First, a repayment record program 101 that records the fact that a repayment has been made in the event of non-payment is installed in the management server 10. 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 to request payment of the defaulted amount by bank transfer. The transfer slip is printed with a code symbol (e.g., a barcode) that includes the customer ID of the defaulted customer and an individual payment ID that identifies the defaulted amount (payment due date). The customer uses the transfer slip to pay the defaulted amount at a convenience store or other location. When payment is made, repayment information (indicating that repayment has been made, the customer ID, and the individual payment ID) is sent to the management server 10 from the payment servers 61-63 operated by collection agents or the like, 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, searches for the individual payment ID, and records the execution date of the program in the "repayment date" of the corresponding 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 the next payment due date or at the next payment due 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 of the record is true, 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 service contract is subject to a fixed-term subscription contract, it deletes the telephone number or terminal identification number for the customer ID from the list of communication denials 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 subscription contract.

[0046] Next, the repayment record program 101 refers to the values of "option contract existence / nonexistence," "option validity," "option in use," and "discontinued due to an 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 an 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 reactivation 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, it is a program that processes the reactivation of an option when the option is invalidated by the option usage output and then 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 reactivation is that the payment is made (repayment 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 reactivation is that the repayment is made at the next payment time.

[0048] In either case, "Option in use" is a true value and "Option validity" is a false value in the record for that customer in the customer information file 11. When the option validity revival program 103 is started, it confirms that "Option in use" is a true value and "Option validity" is a false value, and then performs processing to return "Option in use" to a false value and "Option validity" 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 fee-based contract that is attached to the main contract and is optional. The customer chooses whether or not to enter into the non-payment option contract when concluding the main contract, and if they do, a value indicating that it is available 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 will be given by way of example of a case where a subscription contract is concluded for the purpose of providing a certain membership service. The recipient also operates a server for providing such membership service. 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 for 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 member service, but also a description of the non-payment option. In this example, the option fee is paid on each payment due date in addition to the fee for the main contract, and this explanation is also included. As shown in Figure 7, the customer registration page has a non-payment option selection field 104 in addition to a personal information input field and a button to confirm the input information.

[0052] A customer registration program (not shown) is installed in the management server 10. On the customer registration page shown in Fig. 7, the confirmation button 105 links to a confirmation page for the input information, and the send button provided there serves as a button for executing 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 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 management server 10, and a terminal installed at the sales agency's storefront accesses management server 10 to display the customer registration page, where various pieces of information are entered and recorded in 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 concluding a periodic payment contract with each customer, the receiver explains to each customer that they can also conclude a non-payment option contract, which is an optional ancillary contract. The customer chooses to conclude a non-payment option contract. In this case, the customer enters information in the non-payment option selection field 104 on the customer registration page as shown in FIG. 7, or enters information in the non-payment option selection field 104 on the customer information registration page for sales agents, and the information is recorded in the customer information file 11. The information includes whether or not the option contract is concluded.

[0055] A customer who selects a 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-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 program references the value of the "payment status" field for the corresponding record. If this value is false, the program references the value of the "option contract status." If this value is false, there is no non-payment option contract, and the accident information output program 42 is executed. If the value of the "option contract status" field is true, the program references the value of the "option validity." 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), and the accident information output program 42 is similarly executed. If both the "option contract status" and the "option validity" fields 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 suspension" 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 false, or if "option contract existence / non-existence" is true and "option effectiveness" is false, the accident information output program 42 is executed. Furthermore, the accident reminder output program 43 is executed. If no payment has been made and "option effectiveness" is true, the accident information output program 42 is not executed, and therefore the option use output program 51 is executed. Furthermore, in this case, the option use reminder output program 44 is executed.

[0058] Then, when the unpaid amount is paid by a customer who has defaulted on a payment, 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" of the corresponding record. Then, it 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, it determines whether "repayment date" is recorded in all records in the payment status file 12. If it is recorded, it executes the accident suspension resolution program 102. The accident suspension resolution program 102 opens the accident information file 14 corresponding to the corresponding customer ID and records the program execution date in the "accident resolution date" of the last record. At the same time, it changes "suspended due to an accident" to a false value in the record for that customer ID in the customer information file 11. Furthermore, if "option contract existence / non-existence" is a true value, it returns "option validity" to a true value (valid).

[0059] Next, if the "option contract existence" is a true value, the "option effect" is a false value, and the "suspended due to accident" is a false value for the customer ID included in the repayment information, the repayment record program 101 executes the option effect restoration program 103. This changes the "option effect" to a true value. If the payment of the unpaid amount is made before the next payment due date, the "option effect" will be a true value at the next payment due date, so if the payment is also unpaid at the next payment due date, the payment monitoring program 41 will not execute the accident information program but will execute the option usage output program 51. As a result, the provision of the service or product will continue 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 this regard, a configuration in which the management server 10 is equipped with an option usage output program 51 that temporarily disables the option when the default 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 benefit of a default option contract for the second default after two consecutive defaults is to refer to the payment status on the previous payment date when a default occurs on a certain payment date, and if there is also a default on that payment date, immediately output contingency information even if a default option contract has been concluded. While this configuration is acceptable, if a default occurs and then a repayment is made before the next payment date, the default option should be available for the default on the next payment date. A configuration that refers to the payment status on the previous payment date does not allow for this response (reactivating the benefit of a default option contract). The option reactivation program 103 is a program that records that the use of the default option has ended with repayment at or before the next payment date, and allows the default option to be used again if a subsequent default 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 the option usage information can be used in various ways other than those described above. A second embodiment in which the option usage information is used in a different way will be described below. 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, the option usage output means 5 is used in a form that outputs and records non-payment option usage to a file, but 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] 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 by using the customer ID as the file name, for example. 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," "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 use. For example, a sequential number is recorded as the usage ID.

[0065] The "use start date and time" is a field in which the execution date and time of the option use output program 51 is recorded. The "end date of use" is a field in which the date and time when the use of the no-payment option ended is recorded. "Reason for termination" is a field in which the reason for the termination of the use of the non-payment option is recorded. In this embodiment, there are two types of use of the non-payment option. One is the aforementioned repayment termination, which is a pattern in which the use of the non-payment option is initiated by defaulting on a certain payment due date, and then terminates 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 non-payment option is terminated by using the option without making any payments on or before the next payment due date, and the benefit of the non-payment option has been used up, so the option terminates at that point. 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" in a certain 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 whose file name is the customer ID, and if there is not, 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 whose file name is the customer ID, and records a sequential number (the value of the last record + 1) in the "usage ID" (1 if a new record is created). Next, the program execution date and time are recorded in the "usage start date and time." In addition, the next payment due date is recorded as a default value in the "usage end date," and the "termination reason" is recorded as the default value, indicating that the option has been used and has been terminated. 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 as well, if an unpaid option is used and the unpaid amount is repaid before or at the next payment time, 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 that information. For example, if a non-payment option is not used for a predetermined 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 value, the option fee is reduced. The storage unit 1 stores a billing information file that records the payment amount (billed 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 billed amount recorded in the billing information file according to the payment method type of each customer. 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 resulting 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, while the option fee may be reduced or waived for a completed repayment even if there are a certain number of defaults, a used-up option 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 a used-up option fee may not be reduced or waived unless it occurs no more than once every two years. In addition, the conditions for reduction and waiver may be different, such that if the non-payment option is used zero times in a year, the option fee will be free thereafter, and if it is used once in a year, the fee will be reduced thereafter.

[0071] Conversely, the system may be configured so that the option fee increases depending on the frequency of use of the no-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 no-payment option is used once, the fee increases to 110 yen, and if used twice, the fee increases to 120 yen. In this case, an option change program may be implemented so that if the no-payment option is not used for a certain period of time (for example, one year), the fee is reduced to the original 100 yen. In any case, these measures will give each customer an incentive to avoid paying as much as possible, which will have the effect of reducing non-payment for customers as a whole. In this way, by recording the usage history of options in a file, the usage history can be used effectively.

[0072] In the above explanation, it was stated that when all unpaid payments are paid, the accident suspension elimination program 102 or the option effect revival 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 effect revival program 103 may be implemented to wait a short time before reviving (reactivating) the option. For example, a customer who uses the unpaid option frequently may be reactivated after one month, and for a customer who uses the unpaid option even more frequently, two or even three months later. This configuration creates an incentive to make as many unpaid payments as possible. It can also be said that the accident suspension elimination program 102 constitutes an option effect revival 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, when circumstances arise at the recipient that require a change in option fee, the option fee change program is executed based on that situation. 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. Then, 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 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 may be executed.

[0077] In addition, in the above embodiments, whether or not to use the non-payment option contract is decided when the main contract is concluded, and if it is decided to use it, this is recorded in the customer information file 11. However, it is preferable to be able to change to using the non-payment option contract after the main contract is concluded. 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 web page provided to each customer by the management server 10, and is a page that enables the customer to check the contract details, change registered personal information, change some of the contract details, etc. In order to use My Page, the recipient issues a password to each customer, and when the customer presses (tap or clicks) the login button on the top page provided by the management server on the customer terminal 8 and enters the customer ID and password on the login screen, My Page shown in Figure 10 is displayed on the customer terminal 8.

[0078] As shown in Fig. 10, My Page is provided with 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 a user makes changes to the option contract change input field 106, presses the confirmation button 107, and then presses the OK button on the confirmation page, the My Page change registration program changes the value of "option contract presence / absence" in the customer information file 11. Therefore, it is possible to change an initial status of no non-payment option contract to one with a non-payment option contract, or change an initial status of no non-payment option contract to one with a non-payment option contract. If an option fee is added to the base 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 in the changed amount.

[0080] In the above embodiments, the non-payment option contract is an ancillary contract attached to the main contract, but it may also be included in the main contract. In other words, there may be a main contract with a clause for the non-payment option and a main contract without a clause for the non-payment option, and the customer may choose either contract. In addition, the non-payment option clause may exist as a standard clause in the main contract, and remain in effect unless the customer cancels (terminates) it. In this case, the non-payment option contract may be checked by default (contract status) on the above-mentioned My Page, and the contract may continue unless the check box is unchecked. The same applies to other input fields, which may continue unless an entry to cancel is made. In this case, if the cancellation operation is performed, the amount of the non-payment option fee will be deducted from subsequent regular 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, a configuration may be adopted in which the periodic fee is paid using various forms 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. [Explanation of symbols]

[0083] 1 Storage section 11 Customer Information File 12 Payment Status File 13 Accident Information File 2. Means of receiving non-payment information 3. Means of recording non-payment information 31 Payment Status Recording Program 4. Accident information output means 41 Payment Monitoring Program 42 Accident information output program 5 Optional output means 51 Optional output program 52 Option usage history information file 61~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 the due date in a periodic payment contract in which a fee is paid at predetermined intervals and measures are taken in the event of non-payment between a customer and a receiver, A memory unit; accident information output means; Optional output means It is equipped with The storage unit stores a customer information file that records information on each customer who has a periodic payment contract with the recipient, 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 or not a non-payment option agreement has been concluded with the receiver on the condition that the customer pays the option fee to the receiver, and A non-payment option contract is a contract that stipulates that if a customer does not pay a regular payment fee on a certain payment due date, measures will be taken at a specified time if there is no non-payment option contract, whereas if there is a non-payment option contract, measures will be taken at a later time than the specified time, or measures that are more favorable to the customer than measures that would be taken if there was no non-payment option contract. the accident information output means is means for outputting, as accident information, information for taking measures at the predetermined time or information for taking measures that are disadvantageous to the customer compared to when there is a non-payment option contract; the accident information output means is a means for, when a certain 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 the accident information if a non-payment option contract has been concluded for the customer, and outputting the accident information if a non-payment option contract has not been concluded for the customer; The option use output means is a means for outputting option use information, which is information indicating that the profit of the non-payment option contract has been used, when a certain 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, A non-payment handling system for regular 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 information on whether a non-payment option contract has been concluded is information on the conclusion date and termination date of the non-payment option contract, The system for dealing with non-payment in periodic payments as described in claim 1, characterized in that 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 recorded, and that 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 storage unit stores an option contract history information file that records the history of non-payment option contracts for each customer, 3. The system for handling non-payment in periodic payments as described in claim 2, wherein the option contract history information file is a file in which information regarding the conclusion date and cancellation date of the non-payment option contract concluded by the receiver with each customer is recorded.

4. The customer information file records information about whether the non-payment option contract is valid or invalid for the customer who has concluded the non-payment option contract 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, an option effect restoration means is provided for restoring the effect of the non-payment option contract for the customer in the customer information file when the non-payment that caused the output of the option use information is repaid after the option use output means outputs the option use information, The accident information output means is a means for, when a certain customer fails to 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 the accident information if a non-payment option contract has been concluded for the customer and is valid, and outputting the 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. The system for handling non-payment in periodic payments described in claim 4, characterized in that the option validity revival 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 output of the option usage information.

6. A non-payment handling system for regular 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 storage unit stores an option usage history information file that records the history of option usage information for each customer, 2. The system for handling non-payment in fixed term payments according to claim 1, wherein said option usage output means is means for recording said option usage information in an option usage history information file for said customer.

8. 8. A system for handling non-payment in periodic payments as described in claim 7, further comprising 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