JP7514268B2 - Auto-charge system, auto-charge method, and program - Google Patents

Description

This disclosure relates to an auto-charge system, an auto-charge method, and a program.

In recent years, efforts have been made to improve the convenience of users of payment services. For example, Patent Document 1 describes a periodic balance payment in which, when a user purchases an item at a store, the price of the item is not deducted from the balance of the payment method such as electronic money, but instead, on the monthly settlement date, the total amount of the amount used up to that point is deducted in one lump sum. With periodic balance payment, if the balance of the payment method is insufficient, an auto-charge is performed to make up for the shortfall.

JP 2021-096746 A

For example, if payment methods such as electronic money could be used for periodic payments such as subscriptions, it is believed that user convenience would increase. The same applies to periodic payments other than subscriptions. For example, if periodic payments to different payees occur on multiple payment dates, the user would need to manage the balance of the payment method so as not to run out of balance on each of the multiple payment dates, which is likely to increase the management burden on the user.

However, the technology in Patent Document 1 does not anticipate multiple payment dates on which regular payments are made to different payees, but merely performs an auto-charge to make up for any shortfall in the balance on the settlement date, which occurs once a month. For this reason, conventional technology has not been able to improve user convenience in cases where regular payments are made to different payees on each of multiple payment dates.

One of the objectives of the present disclosure is to improve user convenience when periodic payments to different payees occur on multiple payment dates.

The auto-charge system according to the present disclosure includes a storage unit that associates and stores each of a plurality of payment dates on which periodic payments to different payees occur with an auto-charge setting for auto-charge of a payment method that can be used for the periodic payments, and an auto-charge execution unit that executes the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates.

The present disclosure improves user convenience when periodic payments to different payees occur on multiple payment dates.

FIG. 1 is a diagram showing an example of the overall configuration of an auto-charging system. FIG. 1 is a diagram showing an example of a flow of membership registration for a music distribution service. FIG. 1 is a diagram showing an example of a monthly payment schedule for a certain user. FIG. 2 is a functional block diagram showing an example of functions realized in the auto-charge system. FIG. 2 is a diagram illustrating an example of an electronic money database. FIG. 4 illustrates an example of a service database. FIG. 2 is a diagram illustrating an example of a process executed in the auto-charge system. FIG. 13 is a diagram illustrating an example of a functional block according to a modified example. FIG. 13 is a diagram showing an example of a calendar screen displayed on a user terminal in the fourth modified example. FIG. 13 is a diagram showing an example of a payment amount screen.

[1. Overall configuration of the auto-charge system]
An example of an embodiment of the auto-charge system according to the present disclosure will be described. In this embodiment, electronic money will be described as an example of a payment means that is subject to auto-charge. Therefore, the description of electronic money can be read as payment means. The payment means is not limited to electronic money as long as it has a rechargeable balance. For example, the payment means may be called points, an account, a wallet, or other names. The payment means may also be called a payment means, with a prepaid payment means being one example.

Figure 1 is a diagram showing an example of the overall configuration of an auto-charge system. For example, the auto-charge system 1 includes an electronic money server 10, a service provider server 20, and a user terminal 30. Each of the electronic money server 10, the service provider server 20, and the user terminal 30 can be connected to a network N such as the Internet or a LAN. Although two service provider servers 20 are shown in Figure 1, the number of service provider servers 20 may be one or three or more.

The electronic money server 10 is a server computer of a payment service provider. A payment service provider is a business that provides payment services related to electronic money. For example, the electronic money server 10 includes a control unit 11, a memory unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The memory unit 12 includes a volatile memory such as a RAM, and a non-volatile memory such as a flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

The service provider server 20 is a server computer of a service provider. A service provider is a business that provides a service in which periodic payments are made. Hereinafter, this service will be referred to as a periodic payment service. Periodic payments are payments that occur repeatedly at a specified cycle. In this embodiment, an example will be given in which the periodic payment cycle is one month, but the periodic payment cycle may be of any length and is not limited to one month. For example, the periodic payment cycle may be one day, several days, one week, several weeks, several months, or one year.

In this embodiment, a subscription music distribution service, a video distribution service, and an e-book service are described as examples of periodic payment services. When there is no need to distinguish between music distribution services, video distribution services, and e-book services, they are collectively referred to as periodic payment services. The periodic payment service may be any service and is not limited to the example of this embodiment. For example, the periodic payment service may be a communication service, an electricity service, an e-commerce service, or a financial service. Examples of application of the auto-charge system 1 to other periodic payment services will be described in the modified examples described below.

In this embodiment, the music distribution service, video distribution service, and e-book service are each provided by a different service provider. Therefore, it is assumed that there are three service provider servers 20. For example, the service provider server 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The physical configurations of the control unit 21, the storage unit 22, and the communication unit 23 may be similar to those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

The user terminal 30 is a user's computer. For example, the user terminal 30 is a smartphone, a personal computer, a tablet terminal, or a wearable terminal. For example, the user terminal 30 includes a control unit 31, a memory unit 32, a communication unit 33, an operation unit 34, and a display unit 35. The physical configurations of the control unit 31, the memory unit 32, and the communication unit 33 may be similar to those of the control unit 11, the memory unit 12, and the communication unit 13, respectively. The operation unit 34 is an input device such as a touch panel or a mouse. The display unit 35 is a liquid crystal display or an organic EL display.

The programs stored in the storage units 12, 22, and 32 may be supplied via the network N. Also, the programs stored in a computer-readable information storage medium may be supplied via a reading unit (e.g., an optical disk drive or a memory card slot) that reads the information storage medium, or an input/output unit (e.g., a USB port) that inputs and outputs data to and from an external device.

The autocharge system 1 only needs to include at least one computer, and is not limited to the example of FIG. 1. For example, the autocharge system 1 may include only the electronic money server 10, without including the service provider server 20 and the user terminal 30. In this case, the service provider server 20 and the user terminal 30 exist outside the autocharge system 1. The autocharge system 1 may also include the electronic money server 10 and other server computers of the payment service provider.

[2. Overview of the Auto-Charge System]
In this embodiment, online electronic money will be described as an example of electronic money, but the electronic money may be of any type and is not limited to online electronic money. For example, the electronic money may be a type that uses an IC card, a type that uses an IC chip in the user terminal 30, a type that uses a magnetic card, or a type that uses short-distance wireless communication.

Online-type electronic money is electronic money that can be used for Internet services such as electronic commerce services or travel reservation services. Online-type electronic money may also be usable in physical stores. For example, online-type electronic money may be of a type that can be used by reading a barcode or two-dimensional code in a physical store. Hereinafter, online-type electronic money will be simply referred to as electronic money.

In this embodiment, an example is given of a case where a user uses a payment service, music distribution service, video distribution service, and e-book service from a dedicated application installed on the user terminal 30, but the user may also use these services from a browser on the user terminal 30. For example, after completing membership registration for the payment service, the user registers as a member for each of the music distribution service, video distribution service, and e-book service. Here, the flow of membership registration for the music distribution service is given as an example.

Figure 2 shows an example of the flow of membership registration for a music distribution service. For example, when an application for the music distribution service installed on the user terminal 30 is launched, the top screen G1 of the music distribution service is displayed on the display unit 35. As shown in the top screen G1, the music distribution service is a subscription service that costs 1,000 yen per month. For example, when the user selects button B10, the membership registration screen G2 is displayed on the display unit 35. If the user has already registered as a member, they can log in to the music distribution service from link L11.

For example, the user inputs information required for membership registration, such as name and email address, into input forms F20 and F21. The user selects one of the multiple payment methods available for the music distribution service by selecting radio button B22. For example, when the user selects radio button B22 for electronic money (XXX Cash in FIG. 2) and proceeds with the membership registration procedure, the payment service application is launched. When the user logs in to the payment service, an auto-charge setting screen G3 is displayed on the display unit 35.

In this embodiment, the user can use the auto-charge function of electronic money to prevent monthly payments for music distribution services from failing due to insufficient electronic money balance. For example, when the user uses the auto-charge function for the first time, the user performs a predetermined application procedure. Here, it is assumed that the user has already completed the application procedure for the auto-charge function. For example, the user can specify the charge method, charge threshold, and post-charge balance as auto-charge settings from input forms F30 to F32.

The charge method is the payment method used for auto-charge. The charge method can use various payment methods, such as a credit card, a bank account, an account at another financial institution, crypto assets, points, other electronic money, a debit card, or sales from a flea market service. In the example of Figure 2, the user's credit card is specified as the charge method.

The charge threshold is the balance that serves as the criterion for determining whether or not to perform auto-charge. In this embodiment, auto-charge is performed when the balance falls below the charge threshold, but auto-charge may also be performed when the balance falls below the charge threshold. The user can specify any charge threshold. For example, the user specifies a value of 1,000 yen or more, which is required for monthly payments for a music distribution service, as the charge threshold.

The post-charge balance is the balance after auto-charge. The post-charge balance can also be said to be the balance that is always kept in the electronic money. The user can specify any post-charge balance. For example, the user specifies a figure of 1,000 yen or more, which is required for monthly payments for a music distribution service, as the post-charge balance. The user specifies a figure of 1,000 yen or more, which is required for monthly payments for a music distribution service, as the post-charge balance. The user specifies a figure of 1,000 yen or more, which is required for monthly payments for a music distribution service, as the post-charge balance.

For example, when the user selects button B33, the auto-charge setting and member registration are completed, the music distribution service application returns to the foreground, and a member registration completion screen G4 is displayed on the display unit 35. As shown in the member registration completion screen G4, on the 5th of each month, which is the payment date for the music distribution service, an auto-charge is executed so that "if the balance falls below 1,000 yen, the balance will be set to 1,100 yen," and the 1,000 yen required for the monthly payment for the music distribution service is automatically deducted from the electronic money balance.

In this embodiment, membership registration for the video distribution service and the e-book service is performed in the same manner as for the music distribution service. For example, the user uses electronic money to make monthly payments for each of the video distribution service and the e-book service. The user specifies an auto-charge setting for the video distribution service and an auto-charge setting for the e-book service. On the payment date for each of the music distribution service, the video distribution service, and the e-book service, auto-charge is performed based on the auto-charge setting associated with that payment date.

Figure 3 is a diagram showing an example of a schedule for a certain user's monthly payments. In this embodiment, monthly payments are made according to the schedule shown in Figure 3. For example, the 5th of each month is the payment date for the music distribution service. On the 5th of each month, auto-charge is performed based on the auto-charge setting for the music distribution service, such as "when the balance falls below 1,000 yen, the balance will be set to 1,100 yen." On the 5th of each month, the 1,000 yen required to pay for the music distribution service is deducted from the electronic money balance.

For example, a video distribution service requires a payment of 2,500 yen on the 13th of every month. On the 13th of every month, an auto-charge is executed based on the auto-charge setting for the video distribution service, which states that "if the balance falls below 2,500 yen, the balance will be set to 3,000 yen." On the 13th of every month, the 2,500 yen required to pay for the video distribution service is deducted from the electronic money balance.

For example, the e-book service requires a payment of 1,200 yen on the 25th of each month. On the 25th of each month, an auto-charge is executed based on the auto-charge setting for the e-book service, which states that "if the balance falls below 1,200 yen, the balance will be set to 1,200 yen." On the 25th of each month, the 1,200 yen required to pay for the e-book service is deducted from the electronic money balance.

As described above, in this embodiment, an auto-charge setting for the music distribution service, an auto-charge setting for the video distribution service, and an auto-charge setting for the e-book service are specified. When the payment date for each of the music distribution service, video distribution service, and e-book service arrives, auto-charge is executed based on the auto-charge setting for that payment date. This increases user convenience because the balance will not run short even if the user is not conscious of the balance of electronic money on the payment date. Details of the auto-charge system 1 will be explained below.

[3. Functions realized by the auto-charge system]
FIG. 4 is a functional block diagram showing an example of functions realized by the auto-charge system 1. As shown in FIG.

[3-1. Functions realized by the electronic money server]
The data storage unit 100 is realized by the storage unit 12. The saving unit 101, the auto-charge execution unit 102, and the payment execution unit 103 are realized by the control unit 11.

[Data storage unit]
The data storage unit 100 stores data necessary for providing a payment service. For example, the data storage unit 100 stores an electronic money database DB1.

Figure 5 is a diagram showing an example of electronic money database DB1. As shown in Figure 5, electronic money database DB1 is a database that stores information about electronic money owned by a user. For example, electronic money database DB1 stores a user ID for a payment service, a password for the payment service, the balance of electronic money, payment method information related to payment methods available for recharge, the name of a periodic payment service for which periodic payments occur, the user ID for the periodic payment service, the payment date, the payment amount, and auto-recharge settings.

The user ID is an example of identification information that can identify a user. In this embodiment, one user holds one electronic money, so the identification information can also be said to be information that can identify electronic money. The identification information may be other information such as an email address, a telephone number, or an electronic money ID. In this embodiment, an example is given in which a unique user ID and password are used for each of the settlement service and the periodic payment service, but a common user ID and password may also be used.

Payment method information is information that can identify the payment method used for top-up. For example, if a credit card is used for top-up, the payment method information includes the card number, expiration date, and cardholder name. For example, if a bank account is used for top-up, the payment method information includes the financial institution code, branch code, and account number. Similarly, for other payment methods, the payment method information only needs to include information that can identify the other payment method. The payment method information for the payment method specified by the user is registered in the electronic money database DB1. The payment methods indicated in the payment method information can be used not only for auto-top-up, but also for manual top-up by the user.

The electronic money database DB1 stores the name of the periodic payment service for which the user pays with electronic money, and the user ID of the periodic payment service. For example, when a user specifies electronic money as the payment method when registering as a member of the periodic payment service, the electronic money server 10 receives the user ID of the periodic payment service from the service provider server 20. The electronic money server 10 stores the name of the periodic payment service and the received user ID of the periodic payment service in the electronic money database DB1.

The payment date is the date on which periodic payments are made. The payment date can also be called the settlement date. The payment date occurs repeatedly at a predetermined cycle. In this embodiment, a case will be described in which the day on which a user registers as a member of a periodic payment service becomes the monthly payment date for this user. In the example of FIG. 3, the user registers as a member of a music distribution service on the 5th of a certain month, so the payment date for the music distribution service is the 5th of each month. Similarly, the user registers as a member of a video distribution service and an e-book service on the 13th and 25th of a certain month, respectively, so the payment dates for the video distribution service and the e-book service are the 13th and 25th of each month, respectively. The payment date may be the same for all users, regardless of the date of membership registration.

The payment amount is the amount required for periodic payment. The payment amount can also be called the settlement amount. In this embodiment, a case is described in which the payment amount for a certain periodic payment service is the same for all users who use this periodic payment service, but the payment amount may be an amount according to the user. For example, if multiple fee plans are available for the periodic payment service, the payment amount may be set according to the fee plan selected by the user.

The auto-charge setting is a setting related to auto-charge. In this embodiment, the case where the auto-charge setting indicates the charge method, charge threshold, and post-charge balance is described, but the auto-charge setting may indicate only the charge threshold and post-charge balance without indicating the charge method. In this case, a common charge method is used for multiple auto-charge settings. The common charge method is stored in the electronic money database DB1 as a setting separate from the auto-charge setting.

For example, the auto-charge setting may indicate only either the charge threshold or the post-charge balance. If the auto-charge setting indicates only the charge threshold, the post-charge balance may be a fixed value that cannot be specified by the user, or may be the same numerical value as the charge threshold. If the auto-charge setting indicates only the post-charge balance, the charge threshold may be the same numerical value as the post-charge balance.

The auto-charge setting may be any information indicating what type of auto-charge is to be performed, and may be information other than the charge method, charge threshold, and post-charge balance. For example, the auto-charge setting may indicate the charge amount rather than the post-charge balance. That is, instead of the auto-charge setting in this embodiment of "when the balance falls below 1,000 yen, the balance will be set to 1,100 yen," the auto-charge setting may be "when the balance falls below 1,000 yen, 1,100 yen will be charged."

For another example, the auto-charge setting may indicate the period during which the auto-charge setting applies. In this embodiment, the case where the auto-charge setting is applied on the payment date of the flat-rate payment service is described, but if the auto-charge setting is also applied on other days, the auto-charge setting may indicate the period during which the auto-charge setting applies. For example, if the auto-charge setting in FIG. 3, such as "When the balance falls below 1,000 yen, set the balance to 1,100 yen," is applied on the 1st to 5th of each month, this auto-charge setting may indicate a period such as "1st to 5th of each month."

The data storage unit 100 can store any data. The data stored in the data storage unit 100 is not limited to the electronic money database DB1. Instead of combining information such as electronic money balance and information regarding periodic payments in a single database as in this embodiment, these may be stored in separate databases. As another example, a database for storing information regarding periodic payments may exist for each periodic payment service.

[Storage section]
The storage unit 101 stores auto-charge settings according to periodic payments. Storing the auto-charge settings means recording the auto-charge settings in memory. In this embodiment, a case will be described in which storing the auto-charge settings in the electronic money database DB1 corresponds to storing the auto-charge settings, but the auto-charge settings may be stored in another database, another computer other than the electronic money server 10, or an information storage medium outside the electronic money server 10.

In this embodiment, the storage unit 101 stores multiple payment dates on which periodic payments to different payees occur in association with the auto-charge settings. There are multiple payment dates within a certain period. In this embodiment, the period is every month from January to December, but this period may be any period that corresponds to the payment cycle. As mentioned above, the cycle is not limited to one month.

A payee is a person who receives a payment. A payee is a person to whom a user makes a payment. In this embodiment, a case is taken as an example in which a service provider corresponds to the payee. Therefore, any section describing a service provider can be read as a payee. A payee can be any person and is not limited to a service provider. For example, a payee can be a country, a local government, a government agency, a non-profit organization, or an individual.

In this embodiment, the payee on a certain payment date is different from the payee on other payment dates. Therefore, the multiple payment dates include a first payment date on which a periodic payment is made to a first payee, and a second payment date on which a periodic payment is made to a second payee different from the first payee and different from the first payment date. In the example of FIG. 3, there are three payment dates: the 5th of each month on which a periodic payment is made to a music distribution service, the 13th of each month on which a periodic payment is made to a video distribution service, and the 25th of each month on which a periodic payment is made to an e-book service.

To store information in association means to store one piece of information in a state in which the other piece of information can be searched for. For example, the storage unit 101 stores a pair of a payment date and an auto-charge setting in the electronic money database DB1, thereby storing the payment date and the auto-charge setting in association with each other. In this embodiment, the auto-charge setting is specified on the auto-charge setting screen G3 when registering as a member for the periodic payment service, and the storage unit 101 stores the payment date of this periodic payment service in association with the auto-charge setting specified on the auto-charge setting screen G3.

In this embodiment, the storage unit 101 associates each of a plurality of payment dates with an auto-charge setting that indicates a post-charge balance equal to or greater than the payment amount for the periodic payment on that payment date, and stores the associated setting. For example, the storage unit 101 stores the auto-charge setting so as to indicate a post-charge balance specified for the input form F32 of the auto-charge setting screen G3. The auto-charge setting screen G3 may be restricted so that only a post-charge balance equal to or greater than the payment amount can be specified, or an error message may be displayed if a post-charge balance less than the payment amount is specified.

In the example of FIG. 3, the storage unit 101 stores the payment date for the music distribution service in association with the auto-charge setting indicating the post-charge balance specified by the user when registering as a member of the music distribution service. Similarly, the storage unit 101 stores the payment date for the video distribution service and the e-book service in association with the auto-charge setting indicating the post-charge balance specified by the user. The post-charge balance may be automatically determined to be a value according to the payment amount.

In this embodiment, the charge method specified by the user is also included in the auto-charge settings, so the storage unit 101 associates and stores each of the multiple payment dates with the auto-charge setting that indicates the charge method selected from the multiple charge methods. For example, the storage unit 101 stores the auto-charge setting so that it indicates the charge method specified in the input form F30 of the auto-charge setting screen G3. Since a payment method whose payment method information is stored in the electronic money database DB1 can be specified as the charge method, the information on this payment method is displayed in a selectable manner in the input form F30.

In this embodiment, the storage unit 101 stores the auto-charge setting when registering as a member of the periodic payment service, but the storage unit 101 can store the auto-charge setting at any time. For example, the storage unit 101 may store the auto-charge setting after registering as a member of the periodic payment service. If the user changes the auto-charge setting after registering as a member, the storage unit 101 may store the changed auto-charge setting specified by the user. For example, the auto-charge setting may not be set when registering as a member of the periodic payment service, but may be set after registering as a member.

[Auto Charge Execution Unit]
The auto-charge execution unit 102 executes auto-charge based on the auto-charge setting stored by the storage unit 101. Executing auto-charge means automatically charging electronic money. Since the auto-charge setting is set so that the balance will be equal to or greater than the payment amount for periodic payments, the auto-charge execution unit 102 executes auto-charge based on the auto-charge setting so that the balance will be equal to or greater than the payment amount for periodic payments.

The auto-charge itself can use various known processes. For example, the auto-charge execution unit 102 executes the auto-charge based on the charge method indicated in the auto-charge setting. For example, if a credit card is specified as the charge method, the auto-charge execution unit 102 executes the credit card authorization, and executes the auto-charge so that the balance of electronic money increases if the authorization is successful.

For example, when a bank account is specified as the charge method, the auto-charge execution unit 102 executes auto-charge so that the balance of the bank account decreases and the balance of the electronic money increases. For example, when a crypto asset is specified as the charge method, the auto-charge execution unit 102 executes auto-charge so that the balance of the crypto asset decreases and the balance of the electronic money increases. When another charge method is specified, the auto-charge execution unit 102 executes auto-charge according to the other charge method.

In this embodiment, the case where the auto-charge execution unit 102 executes auto-charge based on the auto-charge setting associated with each of multiple payment dates is described, but since the auto-charge setting may be associated with only one payment date, the auto-charge execution unit 102 may execute auto-charge based on the auto-charge setting associated with one payment date.

For example, the auto-charge execution unit 102 obtains the current date and time using a real-time clock or a GPS signal, etc. The auto-charge execution unit 102 determines whether each of the multiple payment dates stored in the electronic money database DB1 has arrived based on the current date and time. When the auto-charge execution unit 102 determines that a certain payment date has arrived, it executes an auto-charge based on the auto-charge setting associated with this payment date. When auto-charging for this payment date, the auto-charge settings associated with other payment dates are not referenced.

In this embodiment, auto-charge is not performed on days other than payment dates, but as in the modified example described below, auto-charge may be performed on other days based on the default auto-charge settings. For example, until a certain payment date has passed, auto-charge may be performed based on the auto-charge settings associated with that payment date. For example, auto-charge may be performed for a certain period of time including a certain payment date based on the auto-charge settings associated with that payment date.

In this embodiment, since a charge threshold is indicated in the auto-charge setting, the auto-charge execution unit 102 determines whether the balance of the electronic money stored in the electronic money database DB1 is below the charge threshold. If the auto-charge execution unit 102 does not determine that the balance of the electronic money is below the charge threshold, it does not execute auto-charge, and if it determines that the balance of the electronic money is below the charge threshold, it executes auto-charge. In particular, if a charge threshold is not used, the auto-charge execution unit 102 may determine whether auto-charge is necessary by determining whether the balance of the electronic money is below the payment amount.

In this embodiment, since the auto-charge setting indicates the post-charge balance, the auto-charge execution unit 102 executes auto-charge so that the post-charge balance becomes the post-charge balance indicated in the auto-charge setting associated with each of the multiple payment dates. For example, on a certain payment date, the auto-charge execution unit 102 determines the charge amount to be the difference between the post-charge balance indicated in the auto-charge setting associated with that payment date and the current balance of electronic money. The auto-charge execution unit 102 executes auto-charge so that the balance increases by the determined charge amount.

In this embodiment, the auto-charge execution unit 102 executes auto-charge before the payment time on each of the multiple payment dates arrives, based on the auto-charge settings associated with that payment date. The payment time is the time at which payment is executed on each payment date. In this embodiment, for the sake of simplicity, an example is given in which the payment time is fixed at 10:00 AM regardless of the payment date, but the payment time may be any time and is not limited to 10:00 AM. For example, the payment time may be a time other than 10:00 AM, and the payment time on one payment date may be different from the payment time on another payment date.

In this embodiment, the payment time is 10:00 AM on a certain payment date, so auto-charge may be performed at least once between midnight and 10:00 AM on this payment date. Auto-charge does not necessarily have to be performed, and may not be performed if there is a sufficient balance of electronic money. We will explain a case where auto-charge based on the auto-charge setting associated with a certain payment date is not performed after the payment time arrives on that payment date and payment is completed, but auto-charge based on this auto-charge setting may be performed even after the payment time arrives and payment is completed.

For example, when each of multiple payment dates arrives, the auto-charge execution unit 102 determines whether or not auto-charge is necessary for each specified time period until the payment time based on the auto-charge setting associated with that payment date. The specified time is the time for determining whether or not auto-charge is necessary. In this embodiment, an example is given in which the specified time is one hour, but the specified time may be any time period and is not limited to one hour. For example, the specified time may be other times such as one minute, five minutes, 30 minutes, two hours, or four hours.

In the example of FIG. 3, the auto-charge execution unit 102 determines whether the balance is less than 1,000 yen every hour between midnight and 10:00 am on the 5th of each month. If the auto-charge execution unit 102 determines that the balance is 1,000 yen or more, it does not execute auto-charge. If the auto-charge execution unit 102 determines that the balance is less than 1,000 yen, it executes auto-charge to bring the balance to 1,100 yen.

For example, the auto-charge execution unit 102 determines whether the balance is less than 2,500 yen every hour between midnight and 10:00 am on the 13th of each month. If the auto-charge execution unit 102 determines that the balance is 2,500 yen or more, it does not execute auto-charge. If the auto-charge execution unit 102 determines that the balance is less than 2,500 yen, it executes auto-charge to bring the balance to 3,000 yen.

For example, the auto-charge execution unit 102 determines whether the balance is less than 1,200 yen every hour between midnight and 10:00 am on the 25th of each month. If the auto-charge execution unit 102 determines that the balance is 1,200 yen or more, it does not execute auto-charge. If the auto-charge execution unit 102 determines that the balance is less than 1,200 yen, it executes auto-charge to bring the balance to 1,200 yen.

The need for auto-charge may be determined each time the balance of the electronic money changes, rather than at a predetermined time interval. In this case, the auto-charge execution unit 102 may determine whether the balance of the electronic money is less than the charge threshold when the balance of the electronic money changes on the payment date. As another example, the auto-charge execution unit 102 may execute auto-charge immediately before the payment time on each payment date, based on the auto-charge setting associated with that payment date, as in a modified example described below.

In addition, in this embodiment, since the payment date and auto-charge settings differ depending on the user, the storage unit 101 stores, for each user who makes periodic payments, the payment date for that user's payment in association with the auto-charge settings for that payment. When the payment date for that user arrives, the auto-charge execution unit 102 executes auto-charge for each individual user based on the auto-charge settings for that user associated with the payment date so that the electronic money balance of that user increases.

[Payment Execution Department]
The payment execution unit 103 executes periodic payments. Executing a payment can also be said to execute settlement. The payment process itself can utilize various known processes. When electronic money is used as in this embodiment, the payment execution unit 103 only needs to execute a process of deducting the payment amount from the balance of the electronic money. When another payment method such as points or an account is used, the payment execution unit 103 only needs to execute a process of deducting the payment amount from the balance of the other payment method.

For example, the payment execution unit 103 determines whether the payment date stored in the electronic money database DB1 has arrived based on the current date and time. If it is determined that the payment date has not arrived, the payment execution unit 103 does not execute the payment, and if it is determined that the payment date has arrived, the payment execution unit 103 executes the payment so that the electronic money balance of the user to whom the payment is made is reduced by a predetermined payment amount. The payment execution unit 103 can refer to the electronic money database DB1 to identify the users to whom the payment is made and the payment amount for each user.

In this embodiment, since there are multiple payment dates within a month, the payment execution unit 103 executes the payment on each of the multiple payment dates based on the electronic money when that payment date arrives. For example, the payment execution unit 103 determines whether the payment time for each payment date has arrived. In this embodiment, since the payment time is 10:00 AM, the payment execution unit 103 determines whether 10:00 AM on the payment date has arrived. If it is not determined that 10:00 AM on the payment date has arrived, the payment execution unit 103 does not execute the payment, and if it is determined that 10:00 AM on the payment date has arrived, the payment execution unit 103 executes the payment.

In the example of FIG. 3, when it is determined that 10:00 AM on the 5th of each month has arrived, the payment execution unit 103 executes the payment by deducting 1,000 yen from the payment amount. When it is determined that 10:00 AM on the 13th of each month has arrived, the payment execution unit 103 executes the payment by deducting 2,500 yen from the payment amount. When it is determined that 10:00 AM on the 25th of each month has arrived, the payment execution unit 103 executes the payment by deducting 1,200 yen from the payment amount.

The payment execution unit 103 may execute a payment based on a request from the service provider server 20. In this case, when the payment time on the payment date arrives, the service provider server 20 requests the electronic money server 10 to execute the payment by transmitting a list of users to be paid. When the payment execution unit 103 receives the list, it executes the payment so that the electronic money balances of the users included in the list are reduced by a specified payment amount.

The list may include a user ID of the periodic payment service. Since the relationship between the user ID of the payment service and the user ID of the periodic payment service is stored in the electronic money database DB1, the payment execution unit 103 can identify which user of the payment service corresponds to the user indicated by the user ID of the periodic payment service included in the list. The list may include a user ID of the payment service instead of the user ID of the periodic payment service. In this case, the service provider server 20 stores the relationship between the user ID of the payment service and the user ID of the periodic payment service.

For example, when payment for a certain periodic payment service is completed, the payment execution unit 103 transmits a list of users whose payments have been completed to the service provider server 20 corresponding to this periodic payment service. This list may include the user ID of the settlement service, or may include the user ID of the periodic payment service. By receiving the list, the service provider server 20 can identify which users have completed payments.

[3-2. Functions realized by the service provider server]
In this embodiment, the service provider servers 20 for the music distribution service, video distribution service, and electronic book service each have similar functions, so these will be collectively described as the functions of the service provider server 20 for the periodic payment service. The data storage unit 200 is realized by the storage unit 22. The service providing unit 201 is realized by the control unit 21.

[Data storage section]
The data storage unit 200 stores data necessary for providing the periodic payment service. For example, the data storage unit 200 stores a service database DB2.

Figure 6 is a diagram showing an example of the service database DB2. The service database DB2 is a database that stores information about users who have registered as members of the periodic payment service. Figure 6 shows an example of data storage for a music distribution service. For example, the service database DB2 stores the user ID of the periodic payment service, the payment date, the payment amount, payment method information related to the payment method used for the periodic payment, payment status information related to the payment status, and the user ID of the payment service. When a user registers as a member of the periodic payment service, the service provider server 20 generates various information such as the user ID of the periodic payment service and stores it in the service database DB2. The payment status information is updated by the service providing unit 201.

[Service Provision Department]
The service providing unit 201 provides a periodic payment service. The method of providing the periodic payment service itself can use various known methods. For example, the service providing unit 201 provides the periodic payment service to a user who has completed payment. The service providing unit 201 identifies users who have completed payment based also on the list received from the electronic money server 10 when a payment is executed by the payment execution unit 103. The service providing unit 201 updates the payment status information in the service database DB2 to indicate that the payment of the users included in the list has been completed.

[3-3. Functions realized by user terminal]
The data storage unit 300 is realized by the storage unit 32. The display control unit 301 and the operation receiving unit 302 are realized by the control unit 31.

[Data storage section]
The data storage unit 300 stores data necessary for using each of the settlement service and the periodic payment service. For example, the data storage unit 300 stores applications for each of the settlement service and the periodic payment service.

[Display control unit]
The display control unit 301 causes the display unit 35 to display each screen described with reference to FIG.

[Operation reception section]
The operation reception unit 302 receives operations on each screen described with reference to FIG.

[4. Processing performed by the autocharge system]
7 is a diagram showing an example of a process executed in the autocharge system 1. This process is executed by the control units 11, 21, and 31 operating in accordance with the programs stored in the storage units 12, 22, and 32, respectively. In this embodiment, of the processes executed in the autocharge system 1, mainly processes related to autocharge will be described.

As shown in FIG. 7, the user terminal 30 executes processing between the service provider server 20 and the service provider server 20 based on the application for the periodic payment service to display the top screen G1 and the member registration screen G2 (S1). The user selects electronic money as the payment method using the radio button B22 and proceeds with the member registration procedure. The user terminal 30 executes processing between the electronic money server 10 and the service provider server 20 based on the application for the payment service to display the auto-charge setting screen G3 (S2).

When the user selects button B33, the user terminal 30 transmits the auto-charge settings specified for the input forms F30 to F32 to the electronic money server 10 (S3). When the electronic money server 10 receives the auto-charge settings from the user terminal 30 (S4), it saves the auto-charge settings in the electronic money database DB1 (S5). In S5, the electronic money server 10 also receives information such as the payment date from the service provider server 20 or the user terminal 30, and saves it in association with the auto-charge settings. The user terminal 30 executes processing between the service provider server 20 and the user terminal 30 to display a member registration completion screen G4 (S6). Through the above processing of S1 to S6, member registration for the periodic payment service is completed. Once member registration is completed, the user will be able to use the periodic payment service.

When registering as a member for the periodic payment service, auto-charge may be performed for the first payment. In this case, the electronic money server 10 determines whether auto-charge is necessary or not based on the auto-charge settings specified on the auto-charge settings screen G3 when registering as a member. If auto-charge is not necessary, the electronic money server 10 performs the first payment. If auto-charge is necessary, the electronic money server 10 performs auto-charge and then performs the first payment. When the first payment is completed, the member registration completion screen G4 is displayed on the display unit 35 by the process of S6.

The service provider server 20 creates a list of users who are the subject of payment based on the service database DB2 (S7). The process of S7 may be performed every day, or when the payment date approaches. The service provider server 20 transmits the list created in S7 to the electronic money server 10 (S8). When the electronic money server 10 receives the list from the service provider server 20 (S9), it updates the electronic money database DB1 so that the users who are the subject of payment are updated (S10). Since the payment method may be changed on the regular payment service side, the latest information is transmitted to the electronic money server 10 by executing the processes of S7 to S10. For example, information on users who have changed the payment method of the regular payment service from another payment method to electronic money, or from electronic money to another payment method, is shared with the electronic money server 10.

The electronic money server 10 determines whether the payment date for any of the regular payment services of any of the users has arrived based on the electronic money database DB1 (S11). If it is determined that the payment date has not arrived (S11:N), this process ends. If it is determined that the payment date has arrived (S11:Y), the electronic money server 10 identifies, based on the electronic money database DB1, n users (n is a natural number) who have set up auto-charge among the users who are subject to payment (S12).

The electronic money server 10 performs auto-charge every hour based on the auto-charge settings of the n users identified in S12 (S13). In S13, the electronic money server 10 determines whether or not auto-charge is necessary for each user based on the charge threshold indicated by the auto-charge setting of the user and the balance of electronic money held by the user. The electronic money server 10 performs auto-charge based on the auto-charge setting of the user for which it has been determined that auto-charge is necessary.

The electronic money server 10 judges whether the payment time has arrived (S14). If it is not judged that the payment time has arrived (S14:N), the process returns to S13, and judges every hour whether auto-charge is necessary for n users, and executes auto-charge if necessary. If it is judged that the payment time has arrived (S14:Y), the electronic money server 10 executes the payment for the periodic payment service (S15). In S15, if there are multiple periodic payment services for which payment should be executed, the electronic money server 10 executes the payment for each of the multiple periodic payment services.

The electronic money server 10 transmits a list of users who have made payments to the service provider server 20 (S16). When the service provider server 20 receives the list (S17), it updates the service database DB2 so that the user's payment status is up to date (S18), and this process ends.

The autocharge system 1 of this embodiment associates each of a plurality of payment dates with an autocharge setting and stores it. The autocharge system 1 executes autocharge based on the autocharge setting associated with each of the plurality of payment dates. This increases user convenience because it is possible to prevent insufficient balances without having to be aware of the balance around each payment date, even if periodic payments to different payees occur on a plurality of payment dates. In addition, by saving autocharge settings for each payment date, rather than using a common autocharge setting for a plurality of payment dates, flexible autocharge according to the payment date is possible.

In addition, the auto-charge system 1 performs auto-charge so that the post-charge balance is set to the post-charge balance indicated in the auto-charge setting associated with each of the multiple payment dates. As a result, if the post-charge balance is set to be equal to or greater than the payment amount on each payment date, it is possible to more reliably prevent a balance shortage, thereby improving user convenience. Furthermore, by setting the post-charge balance, it is possible to prevent an unintended amount of charge from being performed by the user, which also improves user convenience in this respect. For example, suppose that a malicious third party illegally logs into the periodic payment service and the periodic payment service is fraudulently used. As in the conventional technology, when an auto-charge is performed to make up for the shortage, if a large payment amount occurs due to fraudulent use, an auto-charge is performed to make up for the payment amount, and a large payment is made. However, by setting the post-charge balance, even if such fraudulent use occurs, in principle, payment is only made within the post-charge balance, so it is possible to prevent a large payment from being made. Although there is a possibility that the payment will fail and the periodic payment service will be suspended, the user can notice the fraudulent use. In addition to fraudulent use, it is possible to prevent large payments from being made that the user would not notice.

Furthermore, the auto-charge system 1 executes auto-charge before the payment time arrives on each of the multiple payment dates, based on the auto-charge settings associated with that payment date. This increases user convenience by executing auto-charge before the payment time arrives and more reliably preventing insufficient balance. When the payment time arrives and payment is executed, it is possible to execute auto-charge as part of that process, but in this case, there is a possibility that a large number of auto-charges will be concentrated, increasing the processing load on the electronic money server 10. By completing auto-charges in advance, the timing of execution of auto-charges can be dispersed. As a result, the processing load on the electronic money server 10 can be reduced.

Furthermore, when each of multiple payment dates arrives, the auto-charge system 1 determines whether or not auto-charge is necessary at each specified time until the payment time, based on the auto-charge setting associated with that payment date. If the shortfall is auto-charged when a payment is made, auto-charges may be concentrated, increasing the processing load on the electronic money server 10. By determining in advance at each specified time whether or not auto-charge is necessary and then executing auto-charge, the timing of auto-charge execution can be dispersed. As a result, the processing load on the electronic money server 10 can be reduced.

The auto-charge system 1 also associates and stores each of the multiple payment dates with an auto-charge setting that indicates a charge method selected from the multiple charge methods. This allows auto-charge to be performed using a flexible charge method for each payment date, improving user convenience.

5. Modifications
The present disclosure is not limited to the above-described embodiment, and may be modified as appropriate without departing from the spirit and scope of the present disclosure.

Figure 8 is a diagram showing an example of a functional block in the modified example. Each of the first display control unit 104, the prediction unit 105, the determination unit 106, the receiving unit 107, and the second display control unit 108 is realized by the control unit 11.

[5-1. Modification 1]
For example, in the embodiment, the payment dates for the music distribution service, the video distribution service, and the electronic book service are different from one another, but a number of periodic payments may occur on a certain payment date. In the first modification, in the example of Fig. 3, the payment date for the video distribution service is the 5th of each month, the same as the music distribution service, instead of the 13th of each month.

In the case where multiple periodic payments occur on one payment date, the storage unit 101 of the first modified example stores the one payment date in association with an auto-charge setting corresponding to the total payment amount for each of the multiple periodic payments. In other words, the storage unit 101 may integrate and store multiple auto-charge settings for the same payment date as a single auto-charge setting.

For example, the storage unit 101 calculates the sum of the charge threshold and post-charge balance for the music distribution service and the charge threshold and post-charge balance for the video distribution service, and stores an auto-charge setting indicating the calculated sum. The storage unit 101 stores an auto-charge setting "When the balance falls below 3,500 yen, the balance will be set to 4,100 yen" which is the sum of an auto-charge setting for the music distribution service "When the balance falls below 1,000 yen, the balance will be set to 1,100 yen" and an auto-charge setting for the video distribution service "When the balance falls below 2,500 yen, the balance will be set to 3,000 yen."

The storage unit 101 similarly calculates the total value of the charge threshold and the post-charge balance when three or more payments occur on a certain payment date, and stores the auto-charge setting indicating the calculated total value in association with the payment date. In the first modification, the process for saving the auto-charge setting differs from that of the embodiment, but the auto-charge itself can be executed in the same manner as in the embodiment.

In the case where multiple periodic payments occur on one payment date, the autocharge system 1 of the first modification stores the one payment date in association with an autocharge setting according to the total amount of each of the multiple periodic payments. When multiple periodic payments occur on one payment date, the user's management burden increases in proportion to the number of payments, but by setting the autocharge setting according to the total amount, the necessary amount can be reliably maintained on one payment date.
This will reliably prevent insufficient balances from occurring for individual payments, improving user convenience. Auto-charge settings are integrated within a single payment date, eliminating the need to manage multiple auto-charge settings, reducing the burden of managing auto-charge settings.

[5-2. Modification 2]
For example, even if multiple periodic payments occur on one payment date, if the payment times of the individual payments are different from each other, a separate auto-charge setting may be saved for each payment time. In the example described in the first modification, the payment time for the music distribution service is 10:00 a.m. on the 5th of each month, and the payment time for the video provision service is 3:00 p.m. on the 5th of each month. In this case, the auto-charge setting for the music distribution service may be applied until 10:00 a.m. on the 5th of each month, and the auto-charge setting for the video provision service may be applied from 10:00 a.m. to 3:00 p.m. on the 5th of each month.

In the second modified example, the storage unit 101 stores separate auto-charge settings for each payment time when multiple periodic payments occur on one payment date and the payment times for each of the multiple periodic payments are different from one another on the same payment date. In the second modified example, the electronic money database DB1 and the electronic money database DB1 store information on not only the payment date but also the payment time. For example, the payment time may be notified by the service provider server 20, or may be manually registered by the administrator of the payment service.

For example, when multiple periodic payments occur on a certain payment date, the storage unit 101 compares the payment times of the multiple payments. If the payment times are the same, the storage unit 101 integrates the multiple auto-charge settings into one as in variant example 1. If the payment times are different, the storage unit 101 saves each payment time on a single payment date as a separate auto-charge setting. The auto-charge execution unit 102 executes auto-charge based on the auto-charge setting associated with a specific payment time of the multiple periodic payments until the specific payment time, and when the specific payment time has passed, executes auto-charge based on the auto-charge setting associated with the next payment time of the multiple periodic payments. The auto-charge execution unit 102 executes auto-charge based on the auto-charge setting associated with this payment time until a certain payment time. When the payment time has passed, the auto-charge execution unit 102 executes auto-charge based on the auto-charge setting associated with the next payment time.

The autocharge system 1 of variant 2 stores separate autocharge settings for each payment time when multiple periodic payments occur on one payment date and the payment times for each of the multiple periodic payments are different from each other on one payment date. The autocharge system 1 executes autocharge based on the autocharge setting associated with a specific payment time of the multiple periodic payments until that specific payment time, and when that payment time has passed, executes autocharge based on the autocharge setting associated with the next payment time of the multiple periodic payments. This allows for more flexible autocharge when the payment times are different from each other on one payment date. For example, it is possible to prevent an unnecessarily large balance from being charged by autocharge.

[5-3. Modification 3]
For example, in the embodiment, a case has been described in which auto-charge is not performed on other days when no periodic payment occurs, but on other days, auto-charge may be performed based on the default auto-charge setting. The default auto-charge setting is assumed to be stored in the electronic money database DB1. The default auto-charge setting may be specified by the user, or may be automatically determined by the payment service side based on the user's past charge history, etc. For example, the default auto-charge setting indicates the charge method, charge threshold, and post-charge balance, similar to the auto-charge setting associated with the payment date.

The auto-charge execution unit 102 of the third modified example executes auto-charge on other days other than the multiple payment dates based on other auto-charge settings that are different from the auto-charge settings associated with each of the multiple payment dates. The other days are days on which no regular payments occur. In the example of FIG. 3, the other days are days other than the 5th, 13th, and 25th of each month. In the third modified example, the other auto-charge setting is the default auto-charge setting, but there may be multiple other auto-charge settings depending on the time of the other days. For example, a default auto-charge setting for the first half of the month and a default auto-charge setting for the second half of the month may be defined separately.

The autocharge system 1 of variant example 3 performs autocharge on days other than the multiple payment dates based on autocharge settings other than the autocharge settings associated with each of the multiple payment dates. This allows for more flexible autocharge on days when no regular payments occur, improving user convenience.

[5-4. Modification 4]
For example, when a user registers as a member of many periodic payment services, management of auto-charge settings may become cumbersome. Therefore, the auto-charge settings associated with each payment date may be made available in a calendar format. The auto-charge system 1 of the fourth modification includes a first display control unit 104. The first display control unit 104 displays a calendar screen showing the auto-charge settings associated with each of a plurality of payment dates. Various layouts may be used for the calendar layout itself.

Figure 9 is a diagram showing an example of a calendar screen displayed on the user terminal 30 in variant example 4. In variant example 4, a case is described in which the first display control unit 104 uses a payment service application to display the calendar screen G5, but the first display control unit 104 may also use a browser to display the calendar screen G5. For example, the first display control unit 104 obtains auto-charge settings associated with the user's monthly payment date based on the electronic money database DB1. The first display control unit 104 identifies the user's monthly payment schedule based on the electronic money database DB1.

For example, the first display control unit 104 generates display data for a calendar screen G5 that includes the user's monthly auto-charge settings and the user's monthly payment schedule. The calendar screen G5 shows the relationship between the user's payment date, auto-charge settings, and payment details. The display data may be data in any format defined by the application. When a browser is used, the display data may be in HTML format. The first display control unit 104 displays the calendar screen G5 by transmitting display data for the calendar screen G5 to the user terminal 30. The auto-charge settings may be changeable from the calendar screen G5.

The autocharge system 1 of variant example 4 displays a calendar screen G5 showing autocharge settings associated with each of a number of payment dates. This makes it easier for the user to manage monthly autocharge settings using an intuitive image such as the calendar screen G5.

[5-5. Modification 5]
For example, in the embodiment, a case has been described in which the need for auto-charge is determined every hour on a payment date, but the auto-charge execution unit 102 may execute auto-charge just before the payment time on each of a plurality of payment dates based on the auto-charge setting associated with that payment date. In variant 5, a case has been described in which the need for auto-charge is determined only just before the payment time on a payment date, but by combining the embodiment and variant 5, the need for auto-charge may be determined every hour on a payment date, and also just before the payment time.

"Immediately before the payment time" refers to a time within a specified time of the payment time. In variant 5, as in the embodiment, the payment time is assumed to be 10:00 AM. Furthermore, "immediately before the payment time" is assumed to be 9:55 AM. The time interval between the payment time and the time immediately before the payment time may be any length and is not limited to five minutes. For example, these time intervals may be several seconds to several tens of seconds, one minute to several minutes, or longer than five minutes. However, if these time intervals are too long, the balance after auto-charge may be used, resulting in a shortage of balance, so they are set to be relatively short.

The auto-charge execution unit 102 determines whether the timing immediately before the payment time has arrived on each of the multiple payment dates (9:55 a.m. on the payment date in variant 5). If the auto-charge execution unit 102 determines that the timing immediately before the payment time has not arrived, it does not execute auto-charge, and if it determines that the timing immediately before the payment time has arrived, it executes auto-charge. Only the timing at which auto-charge is executed differs from the embodiment, and the method of executing auto-charge itself is as described in the embodiment.

The auto-charge system 1 of variant 5 executes auto-charge immediately before the payment time on each of multiple payment dates, based on the auto-charge settings associated with that payment date. This allows auto-charge to be executed immediately before the payment time, making it possible to more reliably prevent insufficient balance at the time of payment. For example, it becomes easier to prevent a situation in which, after auto-charge is executed, the user uses electronic money for shopping at an e-commerce service, resulting in insufficient balance at the time of payment.

[5-6. Modification 6]
For example, in periodic payments, the payment amount is not fixed and may vary from month to month. In variant example 6, an electricity service and a communication service will be described as examples of periodic payment services in which the payment amount is not fixed. In an electricity service, a payment for electricity that varies depending on the amount of electricity used is made every month. In a communication service, a payment for communication that varies depending on the amount of telephone or packet use is made every month. In such periodic payment services, the payment amount varies depending on the amount of use by the user, so the monthly payment amount may be predicted in advance and an auto-charge setting according to the predicted value may be saved.

The autocharge system 1 of variant 6 includes a prediction unit 105 and a determination unit 106. The electronic money database DB1 of variant 6 stores past payment records by individual users. The payment records are the results of payments made in the past. For example, the past payment dates and payment amounts are stored in the electronic money database DB1 as payment records for each regular payment service. When the payment execution unit 103 executes a payment for a regular payment service for a certain user, it associates the user ID of the user, the name of the regular payment service, the payment date, and the payment amount and stores them in the electronic money database DB1.

The prediction unit 105 predicts the next payment amount for a periodic payment based on the payment history of the periodic payment for each of multiple payment dates for which the payment amount is not fixed. For example, the prediction unit 105 predicts the next payment amount of a certain user by calculating the average of past payment amounts based on the payment history of the user. The average value may be a simple average, or a weighted average in which the weight coefficient is higher the closer to the present. The payment history used in predicting the next payment amount may be the entire past period, or may be the most recent specified period (e.g., about six months). Furthermore, the prediction unit 105 may predict the payment amount for the same month last year as the next payment amount, instead of the average value.

The determination unit 106 determines the content of the auto-charge setting to be associated with the payment date of a periodic payment whose payment amount is not fixed, based on the next payment amount predicted by the prediction unit 105. For example, the determination unit 106 determines the content of the auto-charge setting so that the post-charge balance is equal to or greater than the next payment amount predicted by the prediction unit 105. This post-charge balance may be the same as the next payment amount, or may be an amount specified by the user or an amount with a predetermined margin. The storage unit 101 of the sixth modification stores the auto-charge setting determined by the determination unit 106. The method of executing the auto-charge itself may be the same as in the embodiment and the first to fifth modifications.

The autocharge system 1 of variant 6 predicts the next payment amount for a periodic payment that does not have a fixed payment amount based on the payment history of the periodic payment. The autocharge system 1 determines the content of the autocharge setting to be associated with the payment date of the periodic payment that does not have a fixed payment amount based on the predicted next payment amount. This makes it possible to set the autocharge setting to be less likely to result in insufficient balance even if the payment amount is not fixed, thereby improving user convenience.

[5-7. Modification 7]
For example, periodic payments may be made using electronic money in combination with other payment means. The other payment means may be any payment means other than electronic money that is subject to auto-charge. For example, the other payment means may be a credit card, a bank account, an account at another financial institution, crypto assets, points, other electronic money, a debit card, or proceeds from a flea market service. For example, if a user wishes to use electronic money in combination with other payment means when registering as a member of the periodic payment service, the electronic money and other payment means are used in combination. The user may specify one of multiple other payment means to be used in combination with the electronic money. The payment amount stored in the electronic money database DB1 is the portion of the payment amount for the periodic payment service that is paid with electronic money.

The storage unit 101 of the seventh modified example is capable of storing, among multiple payment dates, a payment date for a periodic payment for which electronic money can be used in combination with other payment means, in association with an auto-charge setting corresponding to a portion of the payment amount for the periodic payment. The portion of the payment amount is the portion of the payment amount that is paid with electronic money. The remaining portion of the payment amount is paid with other payment means. In the seventh modified example, a credit card is described as an example of the other payment means. There may be two or more other payment means. The user can specify at his/her discretion how much of the payment amount is paid with electronic money.

For example, if 700 yen of a payment amount of 1,000 yen is paid with electronic money and the remaining 300 yen is paid with a credit card, then part of the payment amount is 700 yen. For example, the storage unit 101 stores an auto-charge setting that indicates a post-charge balance of at least part of the payment amount. Only the content of the auto-charge setting differs from the embodiment, and the format of the auto-charge setting and the method of executing the auto-charge are the same as the embodiment. The payment execution unit 103 may execute a credit card payment process so that the remaining part of the payment amount is paid with a credit card, or the payment amount of another payment method may be executed as a process on the service provider server 20 side. It is not necessary that all payments on all payment dates are executed in combination with another payment method, and payments on some payment dates may be executed in combination with another payment method.

The autocharge system 1 of variant 7 can associate and save, among multiple payment dates, a payment date for a periodic payment that can use electronic money in combination with other payment methods, with an autocharge setting that corresponds to a portion of the payment amount for that periodic payment. This allows payments using multiple payment methods in combination, improving user convenience. Even when multiple payment methods are used in combination for a payment, it is possible to ensure that there is no shortage of electronic money to pay.

[5-8. Modification 8]
For example, in the sixth modification, a case has been described in which the next payment amount of a periodic payment in which the payment amount is not fixed is predicted, but there may be a certain amount of time between the determination of the next payment amount and the arrival of the payment time on the payment date. If the electronic money server 10 can receive the determined next payment amount from the service provider server 20 during this period, the auto-charge setting may be saved based on the next payment amount received from the service provider server 20 without predicting the next payment amount.

In variant 8, the storage unit 101 associates and stores an auto-charge setting corresponding to a periodic payment amount determined on a payment date for which the payment amount is not fixed among multiple payment dates after the payment amount of the periodic payment is determined. When the payment amount of the periodic payment service that the service provider server 20 provides is determined, the service provider server 20 stores the payment amount in the service database DB2. For example, the payment amount may be uploaded to the service provider server 20 by a person related to the service provider, or may be automatically determined according to the user's usage of the periodic payment service.

For example, the service provider server 20 transmits a list of users who are to receive payment and the confirmed next payment amount to the electronic money server 10. When the electronic money server 10 receives the list from the service provider server 20, it refers to the list to identify the next payment amount for each user. The storage unit 101 stores the auto-charge settings so that the post-charge balance is equal to or greater than the received payment amount. The method of executing the auto-charge itself is the same as in the embodiment.

In the autocharge system 1 of variant 8, on a payment date for a periodic payment where the payment amount is not fixed among multiple payment dates, after the payment amount for the periodic payment is determined, the autocharge setting corresponding to the determined payment amount is associated and saved. This makes it possible to more reliably prevent insufficient balance for the next payment, thereby improving user convenience.

[5-9. Modification 9]
For example, in the embodiment, the case where the auto-charge setting is specified on the auto-charge setting screen G3 displayed on the payment service side has been described, but the auto-charge setting may be specified on a screen displayed on the periodic payment service side. In this case, the electronic money server 10 may receive a notification from the service provider server 20 indicating that the user has agreed to the auto-charge setting. This notification may include the contents of the auto-charge setting specified by the user.

In variant example 9, after the member registration screen G2 is displayed, the auto-charge setting screen G3 is displayed on the display unit 35 as a screen on the periodic payment service side. For example, the auto-charge setting screen G3 is displayed on the application of the periodic payment service. When a browser is used, the auto-charge setting screen G3 is displayed as a page of the domain of the periodic payment service. When it is necessary to display the electronic money balance on the auto-charge setting screen G3, the user may log in to the payment service, and the user's electronic money balance may be sent to the service provider server 20.

The autocharge system 1 of the 9th variant includes a receiving unit 107. The receiving unit 107 further includes a receiving unit 107 that receives a predetermined notification when an operation is performed in the payee's regular payment service to agree to the autocharge setting. This operation may be a predetermined operation that indicates agreement to the autocharge setting. For example, when the charge method, charge threshold, and post-charge balance are specified, the operation of selecting button B33 corresponds to the operation of agreeing to the autocharge setting.

The specified notification is a notification indicating that the user has agreed to the auto-charge setting on the periodic payment service side. The specified notification is sent by sending data in a specified format. The specified notification includes the auto-charge setting specified by the user. When the storage unit 101 receives the specified notification, it stores the auto-charge setting. The notification includes the user ID of the payment service. The storage unit 101 can identify which user's auto-charge setting is based on this user ID. The storage unit 101 stores the auto-charge setting included in the notification. The content of the auto-charge setting itself may be the same as in the embodiment.

The auto-charge system 1 of variant example 9 saves the auto-charge setting when it receives a specified notification that is sent when an operation to consent to the auto-charge setting is performed in the regular payment service. This allows the auto-charge setting to be completed seamlessly on the regular payment service side, improving user convenience. For example, it becomes possible to complete the auto-charge setting without the payment service application launching midway or being redirected to a payment service page.

[5-10. Modification 10]
For example, electronic money can be used for payments other than periodic payments. In this case, it becomes difficult for the user to manage the extent to which electronic money is used for periodic payments. Therefore, a screen that distinguishes between the payment amount of periodic payments and the payment amount of other payments may be displayed. The autocharge system 1 includes a second display control unit 108. The second display control unit 108 displays a payment amount screen that distinguishes between the payment amount of periodic payments on each of a plurality of payment dates and the payment amount of other payments other than periodic payments. Distinguishing between them means displaying each payment amount separately.

Figure 10 is a diagram showing an example of a payment amount screen. For example, the payment amount screen G6 displays the total payment amount for periodic payments and the total payment amount for other payments separately. In the example of Figure 10, a case is described in which both the total amount and individual details are displayed on the payment amount screen G6, but only either the total amount or the individual details may be displayed on the payment amount screen G6. The total amount is calculated monthly, but the user may be allowed to specify any calculation period. For example, the weekly or semi-annual total amount may be displayed on the payment amount screen G6.

In variant 10, the electronic money usage history is stored in the electronic money database DB1. The usage history includes information that can identify whether the payment is a regular payment or other payment. The electronic money server 10 stores the usage history in the electronic money database DB1 each time the electronic money is used. The second display control unit 108 tallies the total payment amount for regular payments and the total payment amount for other payments based on the electronic money usage history. The second display control unit 108 generates display data for the payment amount screen G6 based on these tallying results and transmits it to the user terminal 30.

The autocharge system 1 of variant example 10 displays a payment amount screen G6 that distinguishes between the payment amount for regular payments on each of multiple payment dates and the payment amount for payments other than regular payments. This reduces the management burden on the user to manage the payment amounts for regular payments.

[5-11. Modification 11]
For example, in the embodiment, the case where auto-charge is executed based on one charge method has been described, but auto-charge may be executed using multiple charge methods in combination. The charge methods that can be used in combination for auto-charge may be a combination of the various methods described in the embodiment. The storage unit 101 of the eleventh modification example is capable of storing each of multiple payment dates in association with an auto-charge setting that indicates a combination of multiple charge methods.

The auto-charge setting of variant 11 indicates multiple charge methods. The charge amount for each charge method may be specified separately, or multiple charge methods may be prioritized. When the auto-charge setting indicates a combination of multiple charge methods, the auto-charge execution unit 102 of variant 11 executes auto-charge based on the multiple charge methods. The user can specify at his/her discretion whether or not to use multiple charge methods in combination.

In the example of FIG. 3, the auto-charge setting for the 5th of each month indicates the use of both a credit card and a bank account. For example, if the auto-charge setting indicates that the credit card is to be charged at 70% and the bank account is to be charged at 30%, the auto-charge execution unit 102 executes auto-charge so that 70% of the required charge amount is charged to the credit card and 30% of the required charge amount is charged to the bank account.

For example, if multiple charging methods are prioritized, the auto-charge execution unit 102 attempts auto-charge in descending order of priority. If auto-charge fails using a charging method with a certain priority, the auto-charge execution unit 102 attempts auto-charge using the charging method with the next priority. In the same manner, the auto-charge execution unit 102 continues to attempt auto-charge in descending order of priority until auto-charge is successful.

For example, in the example of FIG. 3, assume that the auto-charge settings for the 5th of each month are set so that a credit card is the first priority, and a bank account is the second. If the auto-charge execution unit 102 attempts auto-charge using a credit card and is successful, it will not execute auto-charge using a bank account. If auto-charge fails due to insufficient credit card credit limit, for example, the auto-charge execution unit 102 will execute auto-charge using a bank account, which is the next priority.

The autocharge system 1 of variant example 11 can associate and save each of multiple payment dates with an autocharge setting that indicates a combination of multiple charge methods. When the autocharge setting indicates a combination of multiple charge methods, the autocharge system 1 executes autocharge based on the multiple charge methods. This allows for flexible autocharge that combines multiple charge methods.

[5-12. Modifications regarding other configurations]
For example, the present disclosure includes configurations for solving other problems in addition to configurations for solving the problem of "improving user convenience when periodic payments to different payees occur on each of a plurality of payment dates." For this reason, the present disclosure also includes configurations among the configurations described in Modifications 1 to 11 that do not assume the configurations described in the embodiment. Hereinafter, configurations that do not assume the configurations described in the embodiment will be described as modifications related to Modifications 1 to 11.

[Modification regarding Modification 1]
For example, in the first modification, there may not be multiple payment dates on which periodic payments to different payees occur. Multiple periodic payments to different payees may occur on one payment date. In the example described in the first modification, payment for the e-book service on the 25th of each month may not be required. In this case, the only monthly payments are for the music distribution service and video distribution service on the 5th of each month, so there is only one payment date in a month.

For example, the storage unit 101 stores an auto-charge setting for the 5th of each month, such as "when the balance falls below 3,500 yen, the balance will be set to 4,100 yen" according to the total amount of the payment for the music distribution service and the payment for the video distribution service. The auto-charge setting does not need to be stored on days other than the 5th of each month. In this case, auto-charge will be executed only once a month.

Furthermore, multiple periodic payments may occur to the same payee on one payment date. For example, the service provider of the music distribution service and the service provider of the video distribution service may be the same. In this case, payments are made to multiple periodic payment services provided by the same payee on the 5th of each month. The storage unit 101 may store an auto-charge setting such as "when the balance falls below 3,500 yen, set the balance to 4,100 yen" according to the total amount of multiple periodic payments to the same payee.

The autocharge system 1 of the modified example related to the modified example 1 stores autocharge settings according to the total amount of multiple regular payments that occur on one payment date, thereby reliably preventing insufficient balances even if multiple regular payments occur on one payment date, thereby increasing user convenience. Since autocharge settings are integrated within one payment date and there is no need to manage multiple autocharge settings, the burden of managing autocharge settings can be reduced.

[Modification regarding Modification 2]
For example, the configuration of the modified example 2 does not need to have multiple payment dates on which periodic payments are made to different payees, as in the modified example related to the modified example 1. For example, monthly payments may be made only on the 5th of each month for the music distribution service and the video distribution service. In this case, too, if the payment time for the music distribution service and the payment time for the video distribution service are different, the storage unit 101 may store the auto-charge settings up to each payment time separately, as in the modified example 2.

For example, in variant 2, similar to the variant related to variant 1, multiple periodic payments to the same payee may occur on one payment date. For example, even when the same service provider provides a music distribution service and a video distribution service, the storage unit 101 may store separate auto-charge settings at the respective payment times for the music distribution service and the video distribution service provided by the same service provider, as in variant 2.

The modified autocharge system 1 relating to modified example 2 enables flexible autocharge by storing separate autocharge settings for each payment time when multiple periodic payments occur on one payment date and the payment times for each of the multiple periodic payments are different from each other.

[Modification regarding Modification 3]
For example, the configuration of the third modification, like the modifications related to the first and second modifications, may not have multiple payment dates on which periodic payments are made to different payees. For example, there may only be a music distribution service on the fifth day of each month as a monthly payment. In this case, the auto-charge execution unit 102 may execute auto-charge based on the default auto-charge setting for days other than the fifth day of each month.

For example, in variant example 3, periodic payments to the same payee may occur on multiple payment dates. The music distribution service on the 5th of each month, the video distribution service on the 13th of each month, and the e-book service on the 25th of each month may have the same service provider. In this case, the auto-charge execution unit 102 may execute auto-charge based on the default auto-charge setting on days other than the 5th, 13th, and 25th of each month.

The modified autocharge system 1 relating to modification 3 can perform autocharge based on the default autocharge settings when there are days during a period when no regular payments occur, allowing for more flexible autocharge and improving user convenience.

[Modification regarding Modification 4]
For example, the configuration of Modification 4, like the modifications related to Modifications 1 to 3, does not necessarily require that there are multiple payment dates on which periodic payments to different payees occur. For example, even if there is only one payment date each month, it may be possible to display a calendar like Modification 4. In addition, for example, even if periodic payments to the same payee occur on multiple payment dates, it may be possible to display a calendar like Modification 4.

The modified autocharge system 1 relating to modification 4 makes it easier to manage monthly autocharge settings by displaying a calendar screen G5 showing autocharge settings associated with at least one payment date.

[Modification regarding Modification 5]
For example, the configuration of Modification 5 does not need to have multiple payment dates on which periodic payments to different payees occur, as in the modifications related to Modifications 1 to 4. For example, even if there is only one payment date each month, the auto-charge execution unit 102 may execute auto-charge just before the payment time, as in Modification 5, based on the auto-charge setting associated with the only payment date each month.

For example, even when periodic payments to the same payee occur on multiple payment dates, the auto-charge execution unit 102 may execute auto-charge immediately before the payment time on each payment date based on the auto-charge setting associated with that payment date, as in variant example 5. When multiple periodic payments occur in a single day and the payment times for each payment are different, the auto-charge execution unit 102 may execute auto-charge immediately before each payment time based on the auto-charge setting associated with that payment time.

The auto-charge system 1 of the modified example related to the modified example 5 executes auto-charge immediately before the payment time on at least one payment date, based on the auto-charge setting associated with that payment date. Since auto-charge is executed immediately before the payment time, it is possible to more reliably prevent insufficient balance at the payment time.

[Modification regarding Modification 6]
For example, the configuration of the sixth modification, like the modifications related to the first to fifth modifications, does not need to include a plurality of payment dates on which periodic payments to different payees occur. For example, even if there is only one payment date each month, the prediction unit 105 may predict the next payment amount based on past payment records. Even if there is only one payment date each month, the determination unit 106 may determine the contents of the auto-charge settings based on the next payment amount predicted by the prediction unit 105.

For example, even when periodic payments to the same payee occur on multiple payment dates, the prediction unit 105 may predict the next payment amount based on past payment records. Even when periodic payments to the same payee occur on multiple payment dates, the determination unit 106 may determine the content of the auto-charge settings based on the next payment amount predicted by the prediction unit 105.

In the modified autocharge system 1 according to the sixth modification, when the payment amount for a periodic payment on at least one payment date is not fixed, the autocharge setting is determined by predicting the next payment amount. This allows the autocharge setting to be set in a way that is less likely to result in insufficient balance even if the payment amount is not fixed, thereby improving user convenience.

[Modification regarding Modification 7]
For example, the configuration of the seventh modification, like the modifications related to the first to sixth modifications, does not need to have a plurality of payment dates on which periodic payments to different payees occur. For example, even if there is only one payment date each month, it may be possible to use electronic money and other payment methods in combination for a payment that occurs only once a month. The storage unit 101 may store the payment date that occurs only once a month in association with an auto-charge setting that corresponds to a portion of the payment amount in a payment that uses electronic money in combination with other payment methods.

For example, even if periodic payments to the same payee occur on multiple payment dates, if a combined payment is possible on at least one payment date, the storage unit 101 may store the payment date in association with an auto-charge setting that corresponds to a portion of the payment amount in a payment using electronic money and another payment method in combination.

The autocharge system 1 of the modified example related to modified example 7 can prevent a shortage of electronic money payment even when multiple payment methods are used in combination by saving autocharge settings according to the amount of electronic money payment when a payment using electronic money in combination with other payment methods is possible on at least one payment date.

[Modification regarding Modification 8]
For example, the configuration of Modification 8 does not need to have a plurality of payment dates on which periodic payments to different payees occur, as in the modifications related to Modifications 1 to 7. For example, even if there is only one payment date each month, the storage unit 101 may store an auto-charge setting according to the periodic payment amount after the payment amount has been determined.

For example, even when periodic payments to the same payee occur on multiple payment dates, if the payment amount for at least one payment date is not fixed, the storage unit 101 may store the payment date in association with the auto-charge setting corresponding to the determined payment amount after the payment amount for that payment has been determined.

In the modified autocharge system 1 according to the modified example 8, if the payment amount for at least one payment date is not fixed, after the payment amount for that payment is determined, the autocharge setting corresponding to the determined payment amount is saved. This makes it possible to more reliably prevent insufficient balance for the next payment, thereby improving user convenience.

[Modification regarding Modification 9]
For example, the configuration of the 9th modification, like the modifications related to the 1st to 8th modifications, does not need to include a plurality of payment dates on which periodic payments to different payees occur. For example, even if there is only one monthly payment date, the receiving unit 107 may receive a notification when an operation for consenting to the auto-charge setting is performed on the payee's service provider server 20. For example, the receiving unit 107 may receive a notification in a similar manner even if periodic payments to the same payee occur on a plurality of payment dates.

Furthermore, auto-charge settings may be made available on the periodic payment service side, provided that the user information registered in the settlement service matches the user information registered in the periodic payment service. The user information may be any information about the user, such as name, email address, address, telephone number, or user ID. In this case, auto-charge settings are not made when registering as a member of the periodic payment service, but rather after registering as a member of the periodic payment service.

In the modified autocharge system 1 related to the modified example 9, the periodic payment service sets up the autocharge setting associated with at least one payment date. This allows the periodic payment service to seamlessly complete the autocharge setting, improving user convenience.

[Modification regarding Modification 10]
For example, the configuration of variant 10, like the variants relating to variants 1 to 9, does not need to have a plurality of payment dates on which periodic payments to different payees occur. For example, even when there is only one payment date each month, the second display control unit 108 may display a payment amount screen G6 that distinguishes between the payment amount for the payment that occurs only once each month and the payment amounts for the other payments. For example, the second display control unit 108 may display the payment amount screen G6 in a similar manner even when periodic payments to the same payee occur on a plurality of payment dates.

Furthermore, if electronic money is selected as the payment method for a periodic payment service and the user is able to accumulate points, the second display control unit 108 may display on the payment amount screen G6 how many points have been acquired by selecting electronic money as the payment method. In this case, the second display control unit 108 may display on the payment amount screen G6 the points acquired for each periodic payment service. The points generated by the payment of the periodic payment service are assumed to be stored in the electronic money database DB1.

The modified autocharge system 1 relating to modification 10 can reduce the management burden on the user by displaying a payment amount screen G6 that distinguishes between the payment amount for at least one payment date and the payment amount for other payments.

[Modification regarding Modification 11]
For example, the configuration of variant 11, like the variants relating to variants 1 to 10, does not require that there be multiple payment dates on which periodic payments to different payees occur. For example, even if there is only one payment date each month, the storage unit 101 may store an auto-charge setting so that multiple charge methods are used in combination on the payment date that exists only once each month. For example, the storage unit 101 may similarly store an auto-charge setting so that multiple charge methods are used in combination even if periodic payments to the same payee occur on multiple payment dates.

The autocharge system 1 of the modified example related to the modified example 11 associates and stores at least one payment date with an autocharge setting that indicates that multiple charging methods are to be used in combination. This allows for flexible autocharge that combines multiple charging methods.

[5-13. Other Modifications]
For example, the above-described modifications may be combined.

For example, the periodic payment service may be a service in which, when a paying member becomes a member, regular membership fees are paid. For example, if an upper limit is set for auto-charge in each month, the relationship between the current auto-charge amount and the upper limit may be displayed on the payment amount screen G6 or another screen. For example, if auto-charge is to be prevented from being performed for a certain period of time after it is performed, this restriction may be lifted immediately before the payment time.

For example, a periodic payment may be a payment between individuals, rather than a payment to a service provider. In this case, the periodic payment may also be a periodic remittance. For example, a similar auto-charge mechanism can be used when a user uses electronic money to send money to their parents. Furthermore, a periodic payment may not be performed automatically, but may be performed when the user performs a payment operation. In this case, the user performs a payment operation on a regular basis.

For example, instead of having an auto-charge setting for each payment date, an auto-charge setting may exist for each payee. In this case, if a payment is made to a specific payee, auto-charge will be performed based on the auto-charge setting associated with that payee. For example, there may be types of electronic money that can be withdrawn and types that cannot be withdrawn. The auto-charge setting may indicate which type of electronic money is to be auto-charged.

For example, the functions described as being realized by the electronic money server 10 may be realized by the service provider server 20 or another server computer. The functions described as being realized by the service provider server 20 may be realized by the electronic money server 10 or another server computer. For example, the functions described as being realized by the electronic money server 10 or the service provider server 20 may be shared among multiple computers. Each function may be realized by at least one computer.

[6. Notes]
For example, the auto-charging system according to the present disclosure can be configured as follows.
(1)
a storage unit that stores, in association with each of a plurality of payment dates on which periodic payments to different payees occur, an auto-charge setting for auto-charge of a payment method that can be used for the periodic payments;
an auto-charge execution unit that executes the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates;
Includes an auto-charge system.
(2)
When a plurality of periodic payments occur on one payment date, the storage unit stores the one payment date in association with the auto-charge setting corresponding to the total amount of each of the plurality of periodic payments.
An auto-charge system as described in (1).
(3)
The storage unit stores the auto-charge setting separately for each payment time when a plurality of periodic payments occur on one payment date and the payment times of the plurality of periodic payments are different from each other on the one payment date,
The auto-charge execution unit executes the auto-charge based on the auto-charge setting associated with a predetermined payment time of the plurality of periodic payments until the predetermined payment time of the plurality of periodic payments, and when the predetermined payment time has passed, executes the auto-charge based on the auto-charge setting associated with the next payment time of the plurality of periodic payments.
An auto-charge system according to (1) or (2).
(4)
The auto-charge execution unit executes the auto-charge on another day different from the plurality of payment dates based on another auto-charge setting different from the auto-charge setting associated with each of the plurality of payment dates.
An auto-charge system according to any one of (1) to (3).
(5)
The auto-charge system further includes a first display control unit that displays a calendar screen showing the auto-charge settings associated with each of the plurality of payment dates.
An autocharge system according to any one of (1) to (4).
(6)
The storage unit stores each of the plurality of payment dates in association with the auto-charge setting indicating a post-charge balance equal to or greater than the payment amount in the periodic payment on the corresponding payment date;
the auto-charge execution unit executes the auto-charge so as to achieve the post-charge balance indicated in the auto-charge setting associated with each of the plurality of payment dates;
An auto-charge system according to any one of (1) to (5).
(7)
the auto-charge execution unit executes the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates before the payment time on each of the plurality of payment dates arrives;
An auto-charge system according to any one of (1) to (6).
(8)
the auto-charge execution unit, when each of the plurality of payment dates arrives, determines whether or not the auto-charge is necessary at each predetermined time until the payment time based on the auto-charge setting associated with the payment date;
An auto-charge system as described in (7).
(9)
the auto-charge execution unit executes the auto-charge immediately before the payment time on each of the plurality of payment dates based on the auto-charge setting associated with the payment date;
An auto-charge system according to (7) or (8).
(10)
The autocharge system includes:
a prediction unit that predicts a next payment amount in the periodic payment based on a payment record of the periodic payment in which the payment amount is not fixed, among the periodic payments on each of the plurality of payment dates;
A determination unit that determines the content of the auto-charge setting to be associated with the payment date of the periodic payment in which the payment amount is not fixed, based on the next payment amount predicted by the prediction unit; and
The autocharge system according to any one of (1) to (9), further comprising:
(11)
The storage unit is capable of storing, in association with each other, the payment date of the periodic payment for which the payment means can be used in combination with another payment means, among the plurality of payment dates, and the auto-charge setting corresponding to a portion of the payment amount of the periodic payment.
An autocharge system according to any one of (1) to (10).
(12)
The storage unit stores the auto-charge setting corresponding to the determined payment amount in association with the payment date of the periodic payment on which the payment amount is not fixed among the plurality of payment dates, after the payment amount of the periodic payment is determined.
An auto-charge system according to any one of (1) to (11).
(13)
The auto-charge system further includes a receiving unit that receives a predetermined notification when an operation for agreeing to the auto-charge setting is performed in the service of the payee,
The storage unit stores the auto-charge setting when the notification is received.
An auto-charge system according to any one of (1) to (12).
(14)
The autocharge system further includes a second display control unit that displays a payment amount screen that distinguishes between the periodic payment amount on each of the plurality of payment dates and the payment amount of another payment different from the periodic payment.
An auto-charge system according to any one of (1) to (13).
(15)
The storage unit stores each of the plurality of payment dates in association with the auto-charge setting indicating a charge method selected from a plurality of charge methods.
An autocharge system according to any one of (1) to (14).
(16)
The storage unit is capable of storing each of the plurality of payment dates in association with the auto-charge setting indicating a combination of a plurality of charging methods,
When the auto-charge setting indicates a combination of the plurality of charging methods, the auto-charge execution unit executes the auto-charge based on the plurality of charging methods.
An autocharge system according to any one of (1) to (15).

1 Auto-charge system, N Network, 10 Electronic money server, 11, 21, 31 Control unit, 12, 22, 32 Memory unit, 13, 23, 33 Communication unit, 20 Service provider server, 30 User terminal, 34 Operation unit, 35 Display unit, G1 Top screen, G2 Membership registration screen, G3 Auto-charge setting screen, G4 Membership registration completion screen, G5 Calendar screen, G6 Payment amount screen, 100 Data storage unit, 101 Storage unit, 102 Auto-charge execution unit, 103 Payment execution unit, 104 First display control unit, 105 Prediction unit, 106 Decision unit, 107 Reception unit, 108 Second display control unit, 200 Data storage unit, 201 Service provision unit, 300 Data storage unit, 301 Display control unit, 302 Operation reception unit, B10, B33 Button, B22 Radio button, DB1 Electronic money database, DB2 service database, F20, F30, F31, F32, input form, F50 input form, L11 link.

Claims (18)

a storage unit that associates and stores each of a plurality of payment dates on which periodic payments to mutually different payment destinations occur with an auto-charge setting for auto-charge of a payment method that can be used for the periodic payments, the auto-charge setting being different for each of the plurality of payment dates and specified by a user;
an auto-charge execution unit that executes the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates;
Includes an auto-charge system. When a plurality of periodic payments occur on one payment date, the storage unit stores the one payment date in association with the auto-charge setting corresponding to the total amount of each of the plurality of periodic payments.
The autocharge system according to claim 1. The storage unit stores the auto-charge setting separately for each payment time when a plurality of periodic payments occur on one payment date and the payment times of the plurality of periodic payments are different from each other on the one payment date,
The auto-charge execution unit executes the auto-charge based on the auto-charge setting associated with a predetermined payment time of the plurality of periodic payments until the predetermined payment time of the plurality of periodic payments, and when the predetermined payment time has passed, executes the auto-charge based on the auto-charge setting associated with the next payment time of the plurality of periodic payments.
3. The auto-charging system according to claim 1 or 2. The auto-charge execution unit executes the auto-charge on another day different from the plurality of payment dates based on another auto-charge setting different from the auto-charge setting associated with each of the plurality of payment dates.
3. The auto-charging system according to claim 1 or 2. The auto-charge system further includes a first display control unit that displays a calendar screen showing the auto-charge settings associated with each of the plurality of payment dates.
3. The auto-charging system according to claim 1 or 2. The storage unit stores each of the plurality of payment dates in association with the auto-charge setting indicating a post-charge balance equal to or greater than the payment amount in the periodic payment on the corresponding payment date;
the auto-charge execution unit executes the auto-charge so as to achieve the post-charge balance indicated in the auto-charge setting associated with each of the plurality of payment dates;
3. The auto-charging system according to claim 1 or 2. the auto-charge execution unit executes the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates before the payment time on each of the plurality of payment dates arrives;
3. The auto-charging system according to claim 1 or 2. the auto-charge execution unit, when each of the plurality of payment dates arrives, determines whether or not the auto-charge is necessary at each predetermined time until the payment time based on the auto-charge setting associated with the payment date;
The autocharge system according to claim 7. the auto-charge execution unit executes the auto-charge immediately before the payment time on each of the plurality of payment dates based on the auto-charge setting associated with the payment date;
The autocharge system according to claim 7. The autocharge system includes:
a prediction unit that predicts a next payment amount in the periodic payment based on a payment record of the periodic payment in which the payment amount is not fixed, among the periodic payments on each of the plurality of payment dates;
A determination unit that determines the content of the auto-charge setting to be associated with the payment date of the periodic payment in which the payment amount is not fixed, based on the next payment amount predicted by the prediction unit; and
The autocharge system according to claim 1 or 2, further comprising: The storage unit is capable of storing, in association with each other, a payment date of the periodic payment for which the payment means can be used in combination with another payment means among the plurality of payment dates, and the auto-charge setting corresponding to a portion of the payment amount of the periodic payment.
3. The auto-charging system according to claim 1 or 2. The storage unit stores the auto-charge setting corresponding to the determined payment amount in association with the payment date of the periodic payment on which the payment amount is not fixed among the plurality of payment dates, after the payment amount of the periodic payment is determined.
3. The auto-charging system according to claim 1 or 2. The auto-charge system further includes a receiving unit that receives a predetermined notification when an operation for agreeing to the auto-charge setting is performed in the service of the payee,
The storage unit stores the auto-charge setting when the notification is received.
3. The auto-charging system according to claim 1 or 2. The autocharge system further includes a second display control unit that displays a payment amount screen that distinguishes between the periodic payment amount on each of the plurality of payment dates and the payment amount of another payment different from the periodic payment.
3. The auto-charging system according to claim 1 or 2. The storage unit stores each of the plurality of payment dates in association with the auto-charge setting indicating a charge method selected from a plurality of charge methods.
3. The auto-charging system according to claim 1 or 2. The storage unit is capable of storing each of the plurality of payment dates in association with the auto-charge setting indicating a combination of a plurality of charging methods,
When the auto-charge setting indicates a combination of the plurality of charging methods, the auto-charge execution unit executes the auto-charge based on the plurality of charging methods.
3. The auto-charging system according to claim 1 or 2. The computer
a storage step of associating and storing each of a plurality of payment dates on which periodic payments to mutually different payees occur with an auto-charge setting for auto-charge of a payment means available for the periodic payments, the auto-charge setting being different for each of the plurality of payment dates and specified by a user;
an auto-charge execution step of executing the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates;
An auto-charge method that performs the following: a storage unit that associates and stores each of a plurality of payment dates on which periodic payments to mutually different payment destinations occur with an auto-charge setting for auto-charge of a payment method that can be used for the periodic payments, the auto-charge setting being different for each of the plurality of payment dates and specified by a user;
an auto-charge execution unit that executes the auto-charge based on the auto-charge setting associated with each of the plurality of payment dates;
A program that makes a computer function as a

Images