Systems, methods, and programs

Abstract

This improves user convenience when regular payments to different payees occur on multiple payment dates. [Solution] The storage unit (101) of the auto-charge system (1) stores, in association with each of several payment dates on which regular payments to different payees occur, and the auto-charge settings related to the auto-charge of the payment method available for the regular payments. The auto-charge execution unit (102) executes auto-charge based on the auto-charge settings associated with each of the several payment dates.

Description

Technical Field

[0001] The present disclosure relates to an auto - charge system, an auto - charge method, and a program.

Background Art

[0002] In recent years, improving the convenience of users who use payment services has been considered. For example, in Patent Document 1, when a user purchases a product at a store, instead of deducting the price of the product from the balance of a payment means such as electronic money, on the monthly settlement date, the total settlement amount of the usage amount up to that point is deducted in a lump sum as a regular balance payment. In the regular balance payment, when the balance of the payment means is insufficient, auto - charge is executed to supplement the shortage of the balance.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] For example, if payment means such as electronic money can be used for regular payments such as subscriptions, it is considered that the convenience of users will be improved. This also applies to regular payments other than subscriptions. For example, when regular payments to different payees occur on each of a plurality of payment dates, the user needs to manage the balance of the payment means so as not to be short of balance on each of the plurality of payment dates, so it is considered that the management burden on the user increases.

[0005] However, the technology described in Patent Document 1 does not assume multiple payment dates where regular payments to different payees occur, but merely performs an auto-charge to cover any balance shortage on the monthly settlement date. Therefore, the conventional technology has not been able to improve user convenience when regular payments to different payees occur on each of the multiple payment dates.

[0006] One of the purposes of this disclosure is to improve user convenience when periodic payments to different payees occur on multiple payment dates. [Means for solving the problem]

[0007] The auto-charge system relating to this disclosure includes a storage unit that stores in association each of a plurality of payment dates on which periodic payments occur to different payees, and auto-charge settings relating to auto-charge of payment methods available for the periodic payments, and an auto-charge execution unit that performs the auto-charge based on the auto-charge settings associated with each of the plurality of payment dates. [Effects of the Invention]

[0008] This disclosure improves user convenience when periodic payments to different payees occur on multiple payment dates. [Brief explanation of the drawing]

[0009] [Figure 1] This diagram shows an example of the overall configuration of an auto-charge system. [Figure 2] This diagram shows an example of the registration process for a music streaming service. [Figure 3] This figure shows an example of a user's monthly payment schedule. [Figure 4] This is a functional block diagram showing an example of the functions implemented in the auto-charge system. [Figure 5] This is a diagram showing an example of an electronic money database. [Figure 6] This figure shows an example of a service database. [Figure 7] This figure shows an example of the process performed by the auto-charge system. [Figure 8] This figure shows an example of a functional block in a modified example. [Figure 9] This figure shows an example of the calendar screen displayed on the user terminal in Modification Example 4. [Figure 10] This figure shows an example of a payment screen. [Modes for carrying out the invention]

[0010] [1. Overall configuration of the auto-charge system] An example of an embodiment of the auto-charge system relating to this disclosure will be described. In this embodiment, electronic money will be described as an example of a payment method that is subject to auto-charge. For this reason, any section describing electronic money can be read as a payment method. The payment method is not limited to electronic money and can be any method that has a rechargeable balance. For example, the payment method may be called points, an account, a wallet, or other names. The payment method may also be called a payment method, with prepaid payment methods being one example.

[0011] Figure 1 shows an example of the overall configuration of an auto-charge system. For example, 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. In Figure 1, two service provider servers 20 are shown, but there may be one or more service provider servers 20.

[0012] The electronic money server 10 is a server computer of a payment service provider. The 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 storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

[0013] The service provider server 20 is the service provider's server computer. The service provider is a business that provides services that incur periodic payments. Hereafter, this service will be referred to as a periodic payment service. A periodic payment is a payment that occurs repeatedly at a predetermined interval. In this embodiment, the periodic payment interval is given as an example of one month, but the periodic payment interval may be of any length and is not limited to one month. For example, the periodic payment interval may be one day, several days, one week, several weeks, several months, or one year.

[0014] In this embodiment, subscription-based music distribution services, video distribution services, and e-book services are described as examples of recurring payment services. When it is not necessary to distinguish between music distribution services, video distribution services, and e-book services, they are collectively referred to as recurring payment services. Recurring payment services may be any service and are not limited to the examples in this embodiment. For example, recurring payment services may be communication services, electricity services, e-commerce services, or financial services. Examples of applying the auto-charge system 1 to other recurring payment services will be described in the modifications described later.

[0015] In this embodiment, each of the music distribution service, the video distribution service, and the e-book service is provided by different service providers. 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 the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively.

[0016] The user terminal 30 is the 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 storage unit 32, a communication unit 33, an operation unit 34, and a display unit 35. The physical configurations of the control unit 31, the storage unit 32, and the communication unit 33 may be the same as those of the control unit 11, the storage 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.

[0017] Note that the programs stored in the storage units 12, 22, and 32 may be supplied via the network N. Also, a program 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) for inputting and outputting data to and from an external device.

[0018] Also, the auto-charge system 1 may include at least one computer and is not limited to the example of FIG. 1. For example, the auto-charge 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 auto-charge system 1. The auto-charge system 1 may include the electronic money server 10 and another server computer of the settlement operator.

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

[0020] Online electronic money is electronic money that can be used with internet services such as e-commerce services or travel booking services. Online electronic money may also be usable at physical stores. For example, online electronic money may be the type that can be used by scanning a barcode or QR code at a physical store. Hereafter, online electronic money will simply be referred to as electronic money.

[0021] In this embodiment, we will take as an example a case where a user uses a payment service, a music distribution service, a video distribution service, and an e-book service from a dedicated application installed on the user terminal 30. However, the user may also use these services from the browser on the user terminal 30. For example, the user completes membership registration for the payment service and then registers for each of the music distribution service, video distribution service, and e-book service. Here, we will take the membership registration process for the music distribution service as an example.

[0022] Figure 2 shows an example of the registration process for a music distribution service. For example, when the music distribution service application installed on the user terminal 30 is launched, the music distribution service's top screen G1 is displayed on the display unit 35. As shown on the top screen G1, the music distribution service is a monthly subscription service costing 1,000 yen. For example, when the user selects button B10, the registration screen G2 is displayed on the display unit 35. If the user is already registered, they can log in to the music distribution service via link L11.

[0023] For example, the user enters information necessary for membership registration, such as their name and email address, into input forms F20 and F21. The user selects one of several payment methods available for the music distribution service by selecting radio button B22. For example, if the user selects radio button B22 for electronic money (XXX Cash in Figure 2) and proceeds with the membership registration process, the payment service application will launch. Once the user logs into the payment service, the auto-charge settings screen G3 is displayed on display unit 35.

[0024] In this embodiment, users can utilize the electronic money auto-charge function to prevent monthly payments for music distribution services from failing due to insufficient electronic money balance. For example, when a user uses the auto-charge function for the first time, they perform a prescribed 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 balance after charge as auto-charge settings from input forms F30 to F32.

[0025] The charging method is the payment method used for auto-charging. Various payment methods are available for charging, including credit cards, bank accounts, accounts at other financial institutions, cryptocurrencies, points, other electronic money, debit cards, or proceeds from a flea market service. In the example in Figure 2, the user's credit card is specified as the charging method.

[0026] The charge threshold is the balance used to determine whether or not to perform an auto-charge. In this embodiment, an auto-charge is performed when the balance falls below the charge threshold, but an auto-charge may also be performed when the balance falls below the charge threshold. Users can specify any charge threshold. For example, a user can specify a value of 1,000 yen or more, which is required for the monthly payment of the music distribution service, as the charge threshold.

[0027] The balance after charging is the balance after auto-charging. It can also be described as the balance permanently stored in the electronic money account. Users can specify any balance after charging. For example, a user can specify a balance of 1,000 yen or more, which is necessary for the monthly payment of a music streaming service. Alternatively, a user can specify a balance above a certain charge threshold.

[0028] 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 the member registration completion screen G4 is displayed on the display unit 35. As shown on the member registration completion screen G4, on the 5th of each month, which is the payment date for the music distribution service, auto-charge is executed to "bring the balance to 1,100 yen if it falls below 1,000 yen," and 1,000 yen, which is required for the monthly payment of the music distribution service, is automatically deducted from the electronic money balance.

[0029] In this embodiment, registration for both the video streaming service and the e-book service follows the same procedure as for the music streaming service. For example, the user makes monthly payments for both the video streaming service and the e-book service using electronic money. The user specifies auto-charge settings for both the video streaming service and the e-book service. On the payment dates for each of the music streaming service, video streaming service, and e-book service, auto-charging is performed based on the auto-charge settings associated with those payment dates.

[0030] Figure 3 shows an example of a user's monthly payment schedule. 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, an auto-charge is executed based on the auto-charge setting for the music distribution service, which states that "when the balance falls below 1,000 yen, the balance will be increased to 1,100 yen." On the 5th of each month, 1,000 yen, which is required for payment of the music distribution service, is deducted from the electronic money balance.

[0031] For example, let's say a video streaming service charges 2,500 yen on the 13th of every month. On the 13th of each month, an auto-charge is executed based on the auto-charge setting for the video streaming service, which states that "when the balance falls below 2,500 yen, it will be increased to 3,000 yen." On the 13th of each month, 2,500 yen, the amount required for the video streaming service payment, is deducted from the electronic money balance.

[0032] For example, let's say an e-book service incurs 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 "when the balance falls below 1,200 yen, it will be restored to 1,200 yen." On the 25th of each month, 1,200 yen, the amount required for payment of the e-book service, is deducted from the e-money balance.

[0033] As described above, in this embodiment, auto-charge settings for music distribution services, video distribution services, and e-book services are specified. When the payment date for each of the music distribution services, video distribution services, and e-book services arrives, auto-charging is performed based on the auto-charge settings for that payment date. This increases user convenience because the user does not have to worry about running out of balance on the payment date. The details of the auto-charge system 1 will be described below.

[0034] [3. Functions realized by the auto-charge system] Figure 4 is a functional block diagram showing an example of the functions implemented by the auto-charge system 1.

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

[0036] [Data Storage Unit] The data storage unit 100 stores the data necessary to provide payment services. For example, the data storage unit 100 stores the electronic money database DB1.

[0037] Figure 5 shows an example of the electronic money database DB1. As shown in Figure 5, the electronic money database DB1 is a database that stores information about the electronic money held by a user. For example, the electronic money database DB1 stores the user ID of the payment service, the password of the payment service, the balance of the electronic money, payment method information regarding the payment methods that can be used for charging, the name of the recurring payment service in which regular payments occur, the user ID of the recurring payment service, the payment date, the payment amount, and the auto-charge settings.

[0038] A user ID is an example of identification information that can identify a user. In this embodiment, since one user possesses one electronic money account, the identification information can also be said to be information that can identify the electronic money account. The identification information may also be other information such as an email address, telephone number, or electronic money ID. In this embodiment, we give an example where a unique user ID and password are used for each of the payment service and the recurring payment service, but a common user ID and password may also be used.

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

[0040] The electronic money database DB1 stores the name of the recurring payment service that a user pays for with electronic money, and the user ID of that recurring payment service. For example, when a user registers for a recurring payment service and specifies electronic money as the payment method, the electronic money server 10 receives the user ID of the recurring payment service from the service provider server 20. The electronic money server 10 stores the name of the recurring payment service and the received user ID of the recurring payment service in the electronic money database DB1.

[0041] The payment date is the day on which a regular payment is made. The payment date can also be called the settlement date. The payment date occurs repeatedly at predetermined intervals. In this embodiment, we will explain the case where the day a user registers for a recurring payment service becomes the user's monthly payment date. In the example in Figure 3, the user registered for the music distribution service on the 5th of a certain month, so the 5th of each month becomes the payment date for the music distribution service. Similarly, the user registered for the video distribution service and the e-book service on the 13th and 25th of a certain month, respectively, so the 13th and 25th of each month become the payment dates for the video distribution service and the e-book service, respectively. The payment date may be the same for all users, regardless of the registration date.

[0042] The payment amount is the amount required for regular payments. The payment amount can also be called the settlement amount. In this embodiment, we describe a case where the payment amount for a certain recurring payment service is the same for all users of this recurring payment service, but the payment amount may be an amount that varies depending on the user. For example, if the recurring payment service has multiple pricing plans, the payment amount may be set according to the pricing plan selected by the user.

[0043] Auto-charge settings are settings related to automatic charging. In this embodiment, we will describe a case where the auto-charge settings indicate the charging method, charging threshold, and balance after charging, but the auto-charge settings may also indicate only the charging threshold and balance after charging without indicating the charging method. In this case, a common charging method is used for multiple auto-charge settings. The common charging method is stored in the electronic money database DB1 as a setting separate from the auto-charge settings.

[0044] For example, the auto-charge setting may specify either the charge threshold or the balance after charging, but not both. If the auto-charge setting specifies only the charge threshold, the balance after charging may be a fixed value that the user cannot specify, or it may be the same value as the charge threshold. If the auto-charge setting specifies only the balance after charging, the charge threshold may be the same value as the balance after charging.

[0045] Auto-charge settings only need to indicate what kind of auto-charge should be performed, and may include information other than the charging method, charging threshold, and balance after charging. For example, auto-charge settings may indicate the charge amount instead of the balance after charging. That is, instead of an auto-charge setting like in this embodiment, which states "when the balance falls below 1,000 yen, the balance will be increased to 1,100 yen," there may be an auto-charge setting like "when the balance falls below 1,000 yen, charge 1,100 yen."

[0046] For example, the auto-charge setting may also indicate the period during which the auto-charge setting applies. In this embodiment, we describe the case where the auto-charge setting applies on the payment date of the fixed-rate payment service, but if the auto-charge setting applies on other days as well, the period during which the auto-charge setting applies may be indicated in the auto-charge setting. For example, if the auto-charge setting shown in Figure 3, "When the balance falls below 1,000 yen, reset the balance to 1,100 yen," is applied from the 1st to the 5th of each month, this auto-charge setting may indicate a period such as "the 1st to the 5th of each month."

[0047] Furthermore, the data storage unit 100 can store any data. The data stored by the data storage unit 100 is not limited to the electronic money database DB1. As in this embodiment, information such as the balance of electronic money and information regarding periodic payments are not combined into a single database; they may be stored in separate databases. For example, there may be a separate database for each periodic payment service to store information regarding periodic payments.

[0048] [Storage Department] The storage unit 101 stores auto-charge settings corresponding to periodic payments. Storing auto-charge settings means recording the auto-charge settings in memory. In this embodiment, storing auto-charge settings in the electronic money database DB1 is described as equivalent to storing auto-charge settings; however, auto-charge settings may also be stored in other databases, other computers other than the electronic money server 10, or information storage media outside the electronic money server 10.

[0049] In this embodiment, the storage unit 101 will describe a case in which it stores an auto-charge setting in association with each of several payment dates on which regular payments occur to different payees. Multiple payment dates exist within a certain period. In this embodiment, we will describe a case where this period is every month from January to December, but this period can be any period corresponding to the payment cycle. As mentioned above, the cycle is not limited to one month.

[0050] The payee is the party receiving the payment. The payee is the party to whom the user makes the payment. In this embodiment, we take the example of a case where the service provider is the payee. Therefore, any section describing the service provider can be read as referring to the payee. The payee may be any party, and is not limited to the service provider. For example, the payee may be the national government, a local government, an administrative agency, a non-profit organization, or an individual.

[0051] In this embodiment, the payee on one payment date is different from the payee on another payment date. Therefore, the multiple payment dates include a first payment date on which periodic payments to a first payee occur, and a second payment date on which periodic payments to a second payee different from the first payee occur, and which is different from the first payment date. In the example in Figure 3, there are three payment dates: the 5th of each month on which periodic payments to a music distribution service occur, the 13th of each month on which periodic payments to a video distribution service occur, and the 25th of each month on which periodic payments to an e-book service occur.

[0052] Associating and saving means saving information in a way that allows one piece of information to be searched for from another. For example, the storage unit 101 stores the payment date and auto-charge setting pair in the electronic money database DB1, thereby associating and saving the payment date and auto-charge setting. In this embodiment, when a member registers for the recurring payment service, the auto-charge setting is specified on the auto-charge setting screen G3, so the storage unit 101 associates and saves the payment date for this recurring payment service with the auto-charge setting specified on the auto-charge setting screen G3.

[0053] In this embodiment, the storage unit 101 associates and stores each of a plurality of payment dates with an auto-charge setting that shows a post-charge balance equal to or greater than the payment amount for the regular payment on that payment date. For example, the storage unit 101 stores the auto-charge setting so that it shows the post-charge balance specified in 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.

[0054] In the example shown in Figure 3, the storage unit 101 stores the payment date for the music distribution service and the auto-charge setting indicating the balance after charging, which was specified by the user when registering for the music distribution service, in association with each other. Similarly, the storage unit 101 stores the payment dates for video distribution services and e-book services, and the auto-charge settings indicating the balance after charging, which were specified by the user, in association with each other. The balance after charging may be automatically determined to be a value corresponding to the payment amount.

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

[0056] In this embodiment, the storage unit 101 saves the auto-charge settings when a member registers for the recurring payment service, but the storage unit 101 can save the auto-charge settings at any time. For example, the storage unit 101 may save the auto-charge settings after the member registers for the recurring payment service. If the user changes the auto-charge settings after registering, the storage unit 101 may save the modified auto-charge settings specified by the user. For example, the auto-charge settings may not be set at the time of member registration for the recurring payment service, but may be set after registration.

[0057] [Auto-charge execution unit] The auto-charge execution unit 102 performs auto-charge based on the auto-charge settings saved by the storage unit 101. Performing auto-charge means automatically charging electronic money. Since the auto-charge settings are configured to ensure that the balance is equal to or greater than the amount paid in regular payments, the auto-charge execution unit 102 performs auto-charge based on the auto-charge settings so that the balance is equal to or greater than the amount paid in regular payments.

[0058] Auto-charging itself can utilize various known processes. For example, the auto-charging execution unit 102 performs auto-charging based on the charging method indicated in the auto-charging settings. For example, if a credit card is specified as the charging method, the auto-charging execution unit 102 performs credit card authorization and, if the authorization is successful, performs auto-charging so that the electronic money balance increases.

[0059] For example, if a bank account is specified as the charging method, the auto-charge execution unit 102 will perform an auto-charge so that the balance in the bank account decreases and the balance in the electronic money increases. For example, if cryptocurrency is specified as the charging method, the auto-charge execution unit 102 will perform an auto-charge so that the balance in the cryptocurrency decreases and the balance in the electronic money increases. If another charging method is specified, the auto-charge execution unit 102 should perform an auto-charge according to the other charging method.

[0060] In this embodiment, the case in which the auto-charge execution unit 102 performs auto-charging based on the auto-charge settings associated with each of multiple payment dates is described. However, since an auto-charge setting may be associated with only one payment date, the auto-charge execution unit 102 may also perform auto-charging based on the auto-charge settings associated with one payment date.

[0061] For example, the auto-charge execution unit 102 obtains the current date and time using a real-time clock or GPS signal, etc. Based on the current date and time, the auto-charge execution unit 102 determines whether each of the multiple payment dates stored in the electronic money database DB1 has arrived. If the auto-charge execution unit 102 determines that a payment date has arrived, it performs an auto-charge based on the auto-charge setting associated with that payment date. The auto-charge for this payment date does not refer to the auto-charge settings associated with other payment dates.

[0062] In this embodiment, auto-charge is not performed on days other than the payment date. However, as shown in the modified examples below, auto-charge may be performed on other days based on the default auto-charge settings. For example, auto-charge may be performed based on the auto-charge settings associated with a certain payment date until that payment date has passed. For example, auto-charge may be performed based on the auto-charge settings associated with a certain payment date for a certain period including that payment date.

[0063] 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 has fallen below the charge threshold. If the auto-charge execution unit 102 determines that the balance of the electronic money has not fallen below the charge threshold, it does not perform auto-charge, and if it determines that the balance of the electronic money has fallen below the charge threshold, it performs auto-charge. In particular, if no charge threshold is used, the auto-charge execution unit 102 may determine whether auto-charge is necessary by determining whether the balance of the electronic money is less than the payment amount.

[0064] In this embodiment, the balance after charging is indicated in the auto-charge settings, so the auto-charge execution unit 102 performs auto-charging so that the balance after charging becomes the balance indicated in the auto-charge settings associated with each of the multiple payment dates. For example, on a certain payment date, the auto-charge execution unit 102 determines the difference between the balance after charging indicated in the auto-charge settings associated with that payment date and the current balance of the electronic money as the charge amount. The auto-charge execution unit 102 performs auto-charging so that the balance increases by the determined charge amount.

[0065] In this embodiment, the auto-charge execution unit 102 performs an auto-charge based on the auto-charge setting associated with each of the multiple payment dates, before the payment time arrives for that payment date. The payment time is the time when the payment is made on each individual payment date. In this embodiment, for the sake of simplicity, we take the example of a case where the payment time is fixed at 10:00 a.m. regardless of the payment date, but the payment time may be any time and is not limited to 10:00 a.m. For example, the payment time may be any time other than 10:00 a.m., and the payment times for one payment date may be different from those for another payment date.

[0066] In this embodiment, since the payment time is 10:00 AM on a certain payment date, there is a possibility that auto-charge will be performed at least once between 0:00 AM and 10:00 AM on that payment date. Auto-charge is not required to be performed, and may not be performed if there is a sufficient balance in the electronic money. The description explains that auto-charge based on the auto-charge setting associated with a payment date will not be performed after the payment time arrives and the payment is completed, but auto-charge based on this auto-charge setting may be performed even after the payment time arrives and the payment is completed.

[0067] For example, when each of the multiple payment dates arrives, the auto-charge execution unit 102 determines whether auto-charge is necessary at predetermined time intervals until the payment time, based on the auto-charge setting associated with that payment date. The predetermined time is the time for determining whether auto-charge is necessary. In this embodiment, the predetermined time is given as an example when it is 1 hour, but the predetermined time can be any time and is not limited to 1 hour. For example, the predetermined time may be 1 minute, 5 minutes, 30 minutes, 2 hours, or 4 hours.

[0068] In the example shown in Figure 3, the auto-charge execution unit 102 determines whether the balance is less than 1,000 yen every hour from 0:00 AM to 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 perform an auto-charge. If the auto-charge execution unit 102 determines that the balance is less than 1,000 yen, it performs an auto-charge to bring the balance to 1,100 yen.

[0069] For example, the auto-charge execution unit 102 determines whether the balance is less than 2,500 yen every hour from 0:00 AM to 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 perform an auto-charge. If the auto-charge execution unit 102 determines that the balance is less than 2,500 yen, it performs an auto-charge to bring the balance up to 3,000 yen.

[0070] For example, the auto-charge execution unit 102 determines whether the balance is less than 1,200 yen every hour from 0:00 AM to 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 perform an auto-charge. If the auto-charge execution unit 102 determines that the balance is less than 1,200 yen, it performs an auto-charge to bring the balance up to 1,200 yen.

[0071] Furthermore, the necessity of auto-charging may not be determined at predetermined intervals, but rather each time the electronic money balance changes. In this case, the auto-charging execution unit 102 only needs to determine whether the electronic money balance is below the charge threshold when the electronic money balance changes on the payment date. Alternatively, for example, as shown in the modified example below, the auto-charging execution unit 102 may perform auto-charging immediately before the payment time on each payment date, based on the auto-charging settings associated with that payment date.

[0072] Furthermore, in this embodiment, since the payment date and auto-charge settings differ for each user, the storage unit 101 stores, for each user who makes regular payments, the payment date for that user's payment and the auto-charge setting for that payment in association with each user. The auto-charge execution unit 102 can then perform an auto-charge for each individual user, when the payment date for that user's payment arrives, based on the auto-charge setting for that user associated with that payment date, so that the user's electronic money balance increases.

[0073] [Payment Execution Department] The payment execution unit 103 executes periodic payments. Executing a payment can also be described as executing a settlement. Various known processing methods can be used for the payment process itself. In this embodiment, when electronic money is used, the payment execution unit 103 simply deducts the payment amount from the electronic money balance. When other payment methods such as points or bank accounts are used, the payment execution unit 103 simply deducts the payment amount from the balance of the other payment method.

[0074] For example, the payment execution unit 103 determines, based on the current date and time, whether or not the payment date stored in the electronic money database DB1 has arrived. If the payment execution unit 103 determines that the payment date has not arrived, it does not execute the payment. If it determines that the payment date has arrived, it executes the payment so that the balance of the electronic money of the user to be paid decreases by a predetermined payment amount. The payment execution unit 103 only needs to refer to the electronic money database DB1 to identify the user to be paid and the payment amount for each user.

[0075] 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 date arrives. For example, the payment execution unit 103 determines whether or not the payment time for each payment date has arrived. In this embodiment, the payment time is 10:00 AM, so the payment execution unit 103 determines whether or not 10:00 AM on the payment date has arrived. If the payment execution unit 103 determines that 10:00 AM on the payment date has not arrived, it does not execute the payment, and if it determines that 10:00 AM on the payment date has arrived, it executes the payment.

[0076] In the example shown in Figure 3, the payment execution unit 103 executes the payment by deducting 1,000 yen from the remaining balance when it determines that 10:00 AM has arrived on the 5th of each month. The payment execution unit 103 executes the payment by deducting 2,500 yen from the remaining balance when it determines that 10:00 AM has arrived on the 13th of each month. The payment execution unit 103 executes the payment by deducting 1,200 yen from the remaining balance when it determines that 10:00 AM has arrived on the 25th of each month.

[0077] The payment execution unit 103 may also execute a payment based on a request from the service provider server 20. In this case, when the payment time arrives on the payment date, the service provider server 20 requests the electronic money server 10 to execute the payment by sending 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 balance of the users included in the list decreases by a predetermined payment amount.

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

[0079] For example, when payment for a recurring payment service is completed, the payment execution unit 103 sends a list of users whose payments have been completed to the service provider server 20 corresponding to that recurring payment service. This list may include the user IDs of the settlement service or the user IDs of the recurring payment service. By receiving the list, the service provider server 20 can identify which users' payments have been completed.

[0080] [3-2. Functions implemented on the service provider server] In this embodiment, we will describe a case where the service provider servers 20 for music distribution services, video distribution services, and e-book services each have similar functions to one another, and therefore, these will be described collectively as the functions of the service provider server 20 for a recurring payment service. The data storage unit 200 is implemented by the storage unit 22. The service provision unit 201 is implemented by the control unit 21.

[0081] [Data Storage Unit] The data storage unit 200 stores the data necessary to provide the periodic payment service. For example, the data storage unit 200 stores the service database DB2.

[0082] Figure 6 shows 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 recurring 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 recurring payment service, the payment date, the payment amount, payment method information related to the payment method used for recurring payments, payment status information related to the payment status, and the user ID of the payment service. When a member registers for the recurring payment service, the service provider server 20 generates various information such as the user ID of the recurring payment service and stores it in the service database DB2. The payment status information is updated by the service provision unit 201.

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

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

[0085] [Data Storage Unit] The data storage unit 300 stores the data necessary to use the payment service and the recurring payment service, respectively. For example, the data storage unit 300 stores the applications for the payment service and the recurring payment service, respectively.

[0086] [Display Control Unit] The display control unit 301 displays each of the screens described in Figure 2 on the display unit 35.

[0087] [Operation Reception Section] The operation reception unit 302 receives operations on each screen as described in Figure 2.

[0088] [4. Processes performed by the auto-charge system] Figure 7 shows an example of the process performed by the auto-charge system 1. This process is performed by the control units 11, 21, and 31 operating according to the programs stored in the memory units 12, 22, and 32, respectively. In this embodiment, the process related to auto-charging will be described in particular among the processes performed by the auto-charge system 1.

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

[0090] When the user terminal 30 selects button B33, it sends the auto-charge settings specified for input forms F30-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 performs processing with the service provider server 20 to display the member registration completion screen G4 (S6). Through the above processing S1-S6, member registration for the recurring payment service is completed. Once member registration is complete, the user can use the recurring payment service.

[0091] In addition, when registering for the recurring payment service, an autocharge may be performed for the first payment. In this case, the electronic money server 10 determines whether an autocharge is necessary based on the autocharge settings specified on the autocharge setting screen G3 during member registration. If an autocharge is not necessary, the electronic money server 10 performs the first payment. If an autocharge is necessary, the electronic money server 10 performs the autocharge and then the first payment. Once the first payment is completed, the member registration completion screen G4 is displayed on the display unit 35 by the process in S6.

[0092] The service provider server 20 creates a list of users eligible for payment based on the service database DB2 (S7). The process in S7 may be executed daily or when the payment date approaches. The service provider server 20 sends 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 list of users eligible for payment is updated (S10). Since the payment method may be changed on the recurring payment service side, the execution of processes S7 to S10 ensures that the latest information is sent to the electronic money server 10. For example, information on users who have changed their payment method from another payment method to electronic money, or from electronic money to another payment method, is shared with the electronic money server 10.

[0093] The electronic money server 10 determines, based on the electronic money database DB1, whether or not the payment date for any of the regular payment services of any of the users has arrived (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 (n is a natural number) users who have set up auto-charge among the users subject to payment (S12).

[0094] 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 auto-charge is necessary for each user based on the charge threshold indicated by the user's auto-charge setting and the balance of the electronic money held by the user. The electronic money server 10 performs auto-charge based on the auto-charge settings of users for whom auto-charge is deemed necessary.

[0095] The electronic money server 10 determines whether or not the payment time has arrived (S14). If it is determined that the payment time has not arrived (S14:N), it returns to the process in S13 and, every hour, determines whether or not auto-charging is necessary for n users and performs auto-charging as needed. If it is determined that the payment time has arrived (S14:Y), the electronic money server 10 performs payment for the recurring payment service (S15). In S15, if there are multiple recurring payment services for which payment should be performed, the electronic money server 10 performs payment for each of the multiple recurring payment services.

[0096] The electronic money server 10 sends a list of users who have made payments to the service provider server 20 (S16). Upon receiving the list (S17), the service provider server 20 updates the service database DB2 to reflect the latest information on users' payment status (S18), and this process ends.

[0097] The auto-charge system 1 of this embodiment associates and stores auto-charge settings with each of multiple payment dates. The auto-charge system 1 performs auto-charging based on the auto-charge settings associated with each of the multiple payment dates. This improves user convenience because it prevents insufficient funds even if regular payments to different payees occur on multiple payment dates, without the user having to be aware of their balance around each individual payment date. Furthermore, by saving auto-charge settings for each payment date rather than using a common auto-charge setting for multiple payment dates, flexible auto-charging according to the payment date becomes possible.

[0098] Furthermore, the auto-charge system 1 performs auto-charges so that the balance after charging matches the balance specified in the auto-charge settings associated with each of the multiple payment dates. By setting the balance after charging to be greater than or equal to the payment amount on each payment date, insufficient funds can be more reliably prevented, thus improving user convenience. In addition, setting a balance after charging prevents excessive charges from being performed unintentionally, further improving user convenience. For example, suppose a malicious third party illegally logs into a recurring payment service and the service is misused. With conventional technology, if an auto-charge is performed to cover the shortfall, a large payment will be incurred due to the misuse, and an auto-charge will be performed to cover that payment, resulting in a large payment. However, by setting a balance after charging, even if such misuse occurs, payments will, in principle, only be made within the range of the balance after charging, thus preventing large payments from being made. There is a possibility that the recurring payment service may be suspended if the payment fails, but the user will be able to notice the misuse. In addition to preventing misuse, it is also possible to prevent large payments from being made without the user's knowledge.

[0099] Furthermore, the auto-charge system 1 performs an auto-charge based on the auto-charge settings associated with each payment date, before the payment time arrives for each of the multiple payment dates. This improves user convenience by performing an auto-charge before the payment time arrives, more reliably preventing insufficient funds. While it is also conceivable to perform an auto-charge as part of the process when the payment time arrives and the payment is executed, in this case, a large number of auto-charges may concentrate, potentially increasing the processing load on the electronic money server 10. By performing auto-charges in advance, the timing of auto-charge executions can be distributed. As a result, the processing load on the electronic money server 10 can be reduced.

[0100] Furthermore, when each of the multiple payment dates arrives, the auto-charge system 1 determines whether auto-charging is necessary at predetermined intervals until the payment time, based on the auto-charge settings associated with that payment date. If the insufficient amount is auto-charged at the time of payment execution, there is a possibility that auto-charging will be concentrated, increasing the processing load on the electronic money server 10. By determining whether auto-charging is necessary at predetermined intervals in advance and executing auto-charging accordingly, the timing of auto-charging can be distributed. As a result, the processing load on the electronic money server 10 can be reduced.

[0101] Furthermore, the auto-charge system 1 associates and saves each of the multiple payment dates with an auto-charge setting that indicates the selected charging method from among multiple charging methods. This allows for flexible auto-charging methods to be used for each payment date, thus increasing user convenience.

[0102] [5. Variant] This disclosure is not limited to the embodiments described above. It may be modified as appropriate without departing from the spirit of this disclosure.

[0103] Figure 8 shows an example of a functional block in a modified example. The first display control unit 104, prediction unit 105, determination unit 106, receiving unit 107, and second display control unit 108 are each implemented by the control unit 11.

[0104] [5-1. Variation 1] For example, in the embodiment, a case was described in which the payment dates for the music distribution service, video distribution service, and e-book service are all different. However, multiple recurring payments may occur on a single payment date. In Modification 1, in the example in Figure 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.

[0105] In the modified example 1, if multiple recurring payments occur on a single payment date, the storage unit 101 stores the single payment date and the auto-charge settings corresponding to the total amount of each of the multiple recurring payments in association with each other. That is, the storage unit 101 may store multiple auto-charge settings for the same payment date as a single auto-charge setting.

[0106] For example, the storage unit 101 calculates the sum of the charge threshold and balance after charging for the music distribution service and the charge threshold and balance after charging for the video distribution service, and saves an auto-charge setting that shows the calculated sum. The storage unit 101 saves an auto-charge setting that is the sum of the auto-charge setting for the music distribution service, "When the balance falls below 1,000 yen, set the balance to 1,100 yen," and the auto-charge setting for the video distribution service, "When the balance falls below 2,500 yen, set the balance to 3,000 yen," resulting in "When the balance falls below 3,500 yen, set the balance to 4,100 yen."

[0107] The storage unit 101 may similarly calculate the total value of the charge threshold and the balance after charging if three or more payments occur on a given payment date, and save the auto-charge setting indicating the calculated total value in association with that payment date. In Modification 1, the process for saving the auto-charge setting differs from the embodiment, but the auto-charge itself should be performed in the same manner as in the embodiment.

[0108] In the modified version 1 of the auto-charge system 1, if multiple recurring payments occur on a single payment date, the system associates and saves the single payment date with the auto-charge settings corresponding to the total amount of each of the multiple recurring payments. When multiple recurring payments occur on a single payment date, the user's management burden increases proportionally to the number of payments. However, by setting the auto-charge amount according to the total amount, the system can reliably maintain the necessary amount on a single payment date, thus preventing insufficient funds from occurring for individual payments and improving user convenience. Since the auto-charge settings are integrated within a single payment date, there is no need to manage multiple auto-charge settings, thus reducing the burden of managing auto-charge settings.

[0109] [5-2. Variation 2] For example, even if multiple recurring payments occur on the same payment date, if the payment times for each payment are different, separate auto-charge settings may be saved for each payment time. In Modification 2, in the example described in Modification 1, the payment time for the music distribution service is 10:00 AM on the 5th of each month, and the payment time for the video provision service is 3:00 PM on the 5th of each month. In this case, the auto-charge setting for the music distribution service may be applied until 10:00 AM on the 5th of each month, and the auto-charge setting for the video provision service may be applied from 10:00 AM on the 5th of each month until 3:00 PM.

[0110] In Modification 2, the storage unit 101 stores separate auto-charge settings for each payment time when multiple periodic payments occur on a single payment day, and the payment times for each of these periodic payments differ from one another on that single payment day. In Modification 2, the electronic money database DB1 stores not only the payment date but also the payment time information. For example, the payment time may be notified by the service provider server 20, or it may be manually registered by the administrator of the payment service.

[0111] For example, if multiple recurring payments occur on a given payment date, the storage unit 101 compares the payment times of each other. If the payment times are the same, the storage unit 101 integrates the multiple auto-charge settings into one, as shown in Modification Example 1. If the payment times are different, the storage unit 101 saves each payment time within a single payment date as a separate auto-charge setting. The auto-charge execution unit 102 performs auto-charging based on the auto-charge setting associated with a predetermined payment time among the multiple recurring payments until that payment time has elapsed. Once that payment time has elapsed, it performs auto-charging based on the auto-charge setting associated with the next payment time among the multiple recurring payments. The auto-charge execution unit 102 performs auto-charging based on the auto-charge setting associated with a certain payment time until that payment time has elapsed. Once that payment time has elapsed, the auto-charge execution unit 102 performs auto-charging based on the auto-charge setting associated with the next payment time.

[0112] The auto-charge system 1 in Modification 2 saves separate auto-charge settings for each payment time when multiple recurring payments occur on a single payment day, and the payment times for each of these recurring payments differ within that payment day. The auto-charge system 1 performs auto-charging based on the auto-charge setting associated with a predetermined payment time for any of the multiple recurring payments, and once that payment time has elapsed, it performs auto-charging based on the auto-charge setting associated with the next payment time among the multiple recurring payments. This allows for more flexible auto-charging when payment times differ within a single payment day. For example, it can prevent the balance from being charged unnecessarily high through auto-charging.

[0113] [5-3. Modified Example 3] For example, the embodiment describes a case where auto-charge is not performed on days other than those when regular payments do not occur. However, auto-charge may be performed on other days based on the default auto-charge settings. The default auto-charge settings are assumed to be stored in the electronic money database DB1. The default auto-charge settings may be specified by the user, or they may be automatically determined by the payment service based on the user's past charging history, etc. For example, the default auto-charge settings may indicate the charging method, charging threshold, and balance after charging, similar to the auto-charge settings associated with the payment date.

[0114] In Modification 3, the auto-charge execution unit 102 performs auto-charge on days other than the multiple payment dates, based on an auto-charge setting different from the auto-charge setting associated with each of the multiple payment dates. These other days are days when no regular payments occur. In the example in Figure 3, these other days are days other than the 5th, 13th, and 25th of each month. In Modification 3, the other auto-charge setting is assumed to be the default auto-charge setting, but there may be multiple other auto-charge settings depending on the timing of the other days. For example, there may be separate default auto-charge settings for the first half of the month and for the second half of the month.

[0115] In the modified version 3, the auto-charge system 1 performs auto-charging on days other than the multiple payment dates, based on different auto-charge settings than those associated with each of the multiple payment dates. This allows for more flexible auto-charging on days when no regular payments occur, thereby increasing user convenience.

[0116] [5-4. Modification 4] For example, if a user registers for many recurring payment services, managing auto-charge settings can become complicated. Therefore, it may be possible to make it possible to view auto-charge settings associated with individual payment dates in a calendar format. The auto-charge system 1 of Modification 4 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 the multiple payment dates. Various layouts are available for the calendar itself.

[0117] Figure 9 shows an example of the calendar screen displayed on the user terminal 30 in Modification 4. Modification 4 describes a case where the first display control unit 104 displays the calendar screen G5 using a payment service application, but the first display control unit 104 may also display the calendar screen G5 using a browser. For example, the first display control unit 104 obtains the 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.

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

[0119] The auto-charge system 1 in Modification 4 displays a calendar screen G5 that shows the auto-charge settings associated with each of the multiple payment dates. This makes it easier for the user to manage their monthly auto-charge settings through intuitive images such as the calendar screen G5.

[0120] [5-5. Variation 5] For example, in the embodiment, the need for auto-charging is determined every hour on the payment date, but the auto-charging execution unit 102 may perform auto-charging immediately before the payment time on each of the multiple payment dates, based on the auto-charging setting associated with that payment date. In Modification 5, the need for auto-charging is determined only immediately before the payment time on the payment date, but by combining the embodiment and Modification 5, the need for auto-charging may be determined every hour on the payment date, and also immediately before the payment time.

[0121] "Immediately before the payment time" refers to a time within a specified time frame of the payment time. In Modification 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 can be any length and is not limited to 5 minutes. For example, these time intervals may be a few seconds to tens of seconds, one minute to several minutes, or longer than 5 minutes. However, if these time intervals are too long, the balance after auto-charging may be used up, potentially resulting in insufficient funds, so they should be kept relatively short.

[0122] The auto-charge execution unit 102 determines whether the time immediately preceding the payment time (in the modified example 5, 9:55 a.m. on the payment day) has arrived for each of the multiple payment days. If the auto-charge execution unit 102 determines that the time immediately preceding the payment time has not arrived, it does not perform auto-charge. If it determines that the time immediately preceding the payment time has arrived, it performs auto-charge. Only the timing at which auto-charge is performed differs from the embodiment; the method of performing auto-charge itself is the same as described in the embodiment.

[0123] The auto-charge system 1 in Modification 5 performs an auto-charge immediately before the payment time on each of the multiple payment dates, based on the auto-charge setting associated with that payment date. As a result, since the auto-charge is performed immediately before the payment time, it is possible to more reliably prevent insufficient funds at the time of payment. For example, it becomes easier to prevent situations where a user uses electronic money for shopping on e-commerce services after the auto-charge has been performed, resulting in insufficient funds at the time of payment.

[0124] [5-6. Variation 6] For example, with regular payments, the payment amount is not fixed and may vary from month to month. In Modification Example 6, electricity services and communication services are described as examples of regular payment services with inconsistent payment amounts. In electricity services, a monthly payment for electricity charges occurs, which varies depending on the amount of electricity used. In communication services, a monthly payment for communication charges occurs, which varies depending on the amount of telephone or data usage. In such regular payment services, since the payment amount varies depending on the user's usage, it may be possible to predict the monthly payment amount in advance and save auto-charge settings based on the predicted value.

[0125] The auto-charge system 1 in Modification 6 includes a prediction unit 105 and a decision unit 106. The electronic money database DB1 in Modification 6 stores the past payment history of individual users. The payment history is the result of payments made in the past. For example, the past payment date and payment amount for each recurring payment service are stored in the electronic money database DB1 as payment history. When the payment execution unit 103 executes a payment for a recurring payment service for a user, it stores the user's user ID, the name of the recurring payment service, the payment date, and the payment amount in association with each other in the electronic money database DB1.

[0126] The prediction unit 105 predicts the next payment amount for a periodic payment, based on the payment history of periodic payments whose payment amounts are not fixed, among the periodic payments on each of multiple payment dates. For example, the prediction unit 105 predicts the next payment amount for a user by calculating the average of past payment amounts based on the user's payment history. The average may be a simple average or a weighted average where the weight coefficient increases as the date approaches the present. The payment history used to predict the next payment amount may be the entire past period or a recent predetermined period (for example, about six months). Furthermore, the prediction unit 105 may predict the next payment amount as the payment amount for the same month of the previous year, rather than the average.

[0127] The determination unit 106 determines the content of the auto-charge setting to be associated with the payment date of a regular payment for which the 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 balance after charging is equal to or greater than the next payment amount predicted by the prediction unit 105. This balance after charging may be the same as the next payment amount, or it may be an amount specified by the user or a predetermined amount with a margin. The storage unit 101 of Modification 6 stores the auto-charge setting determined by the determination unit 106. The method of executing auto-charge itself may be the same as in Embodiment and Modifications 1 to 5.

[0128] The auto-charge system 1 in Modification 6 predicts the next payment amount for a recurring payment based on the payment history of the recurring payment, which does not have a fixed payment amount. Based on the predicted next payment amount, the auto-charge system 1 determines the content of the auto-charge setting to associate with the payment date of the recurring payment, which does not have a fixed payment amount. This makes it possible to create an auto-charge setting that is less likely to result in insufficient balance, even if the payment amount is not fixed, thus improving user convenience.

[0129] [5-7. Variation 7] For example, recurring payments may be made using a combination of electronic money and other payment methods. These other payment methods may be any payment method other than the electronic money eligible for auto-charge. For example, these other payment methods may include credit cards, bank accounts, accounts at other financial institutions, cryptocurrencies, points, other electronic money, debit cards, or proceeds from a flea market service. For instance, if a user requests to use electronic money in combination with other payment methods when registering for a recurring payment service, these two methods will be used together. The user may also specify which other payment methods to use in combination with electronic money from among several options. The payment amount stored in the electronic money database DB1 will be the portion of the recurring payment service payment that is paid using electronic money.

[0130] In Modification 7, the storage unit 101 can store, in association with a payment date for a recurring payment that can be made using both electronic money and other payment methods, and an auto-charge setting corresponding to a portion of the payment amount for that recurring payment. The portion of the payment amount refers to the portion of the payment that is made using electronic money. The remaining portion of the payment amount is paid using other payment methods. In Modification 7, a credit card is described as an example of other payment methods. There may be two or more other payment methods. The user can arbitrarily specify how much of the payment amount is to be paid using electronic money.

[0131] For example, if a payment of 1,000 yen is paid by electronic money for 700 yen and the remaining 300 yen by credit card, then 700 yen is considered part of the payment. For example, the storage unit 101 stores an auto-charge setting that shows the balance after charging, which is more than a portion of the payment amount. Only the content of the auto-charge setting differs from the embodiment; the format of the auto-charge setting and the method of executing auto-charge are the same as in the embodiment. The payment execution unit 103 may execute credit card settlement processing to pay the remaining portion of the payment amount by credit card, or the payment portion by other payment methods may be processed on the service provider server 20 side. It is not necessary for all payments on payment dates to be executed in combination with other payment methods; payments on some payment dates may be executed in combination with other payment methods.

[0132] The auto-charge system 1 in Modification 7 can associate and save payment dates for recurring payments that can be made using both electronic money and other payment methods, and auto-charge settings corresponding to a portion of the payment amount for those recurring payments. This allows for payments using multiple payment methods, thereby increasing user convenience. Even when payments are made using multiple payment methods, it is possible to ensure that the electronic money payment portion is not insufficient.

[0133] [5-8. Variation 8] For example, in Modification 6, we described a case where the next payment amount for a regular payment, where the payment amount is not fixed, is predicted. However, there may be a certain amount of time between the determination of the next payment amount and the arrival of the payment date and time. If the electronic money server 10 can receive the determined next payment amount from the service provider server 20 during this time, 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.

[0134] In the modified example 8, the storage unit 101 stores, for recurring payments among multiple payment dates where the payment amount is not fixed, an auto-charge setting corresponding to the determined payment amount after the payment amount for the recurring payment has been determined. When the payment amount for the recurring payment service that it 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 it may be automatically determined according to the user's usage of the recurring payment service.

[0135] For example, the service provider server 20 sends a list to the electronic money server 10 of the users to whom payment is to be made and the confirmed next payment amount. 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 individual user. The storage unit 101 saves the auto-charge settings so that the balance after charging becomes equal to or greater than the received payment amount. The method of executing auto-charge itself is the same as in the embodiment.

[0136] In the modified version 8, the auto-charge system 1, for recurring payments where the payment amount is not fixed among multiple payment dates, associates and saves an auto-charge setting corresponding to the confirmed payment amount after the payment amount for the recurring payment has been determined. This makes it more reliable to prevent insufficient funds for the next payment, thereby improving user convenience.

[0137] [5-9. Modification 9] For example, in this embodiment, we have described a case where the auto-charge setting is specified on the auto-charge setting screen G3 displayed on the payment service side, but the auto-charge setting may also be specified on a screen displayed on the recurring 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 details of the auto-charge setting specified by the user.

[0138] In Modification 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 for the recurring payment service. For example, the auto-charge setting screen G3 is displayed on the application of the recurring payment service. If a browser is used, the auto-charge setting screen G3 is displayed as a page on the domain of the recurring payment service. If 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.

[0139] The auto-charge system 1 of Modification 9 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 to consent to the auto-charge setting in the payment destination's recurring payment service. This operation can be any predetermined operation that indicates consent to the auto-charge setting. For example, the operation of selecting button B33 with the charge method, charge threshold, and balance after charge specified corresponds to the operation to consent to the auto-charge setting.

[0140] The specified notification is a notification indicating that the user has agreed to the auto-charge setting on the recurring payment service side. The specified notification is made by transmitting data in a specified format. The specified notification shall include the auto-charge setting specified by the user. When the storage unit 101 receives the specified notification, it saves the auto-charge setting. The notification shall include the user ID of the payment service. The storage unit 101 can identify which user's auto-charge setting it is by this user ID. The storage unit 101 saves the auto-charge setting included in the notification. The content of the auto-charge setting itself may be the same as in the embodiment.

[0141] The auto-charge system 1 in Modification 9 saves the auto-charge settings when it receives a predetermined notification that is sent when an operation to agree to the auto-charge settings is performed in the recurring payment service. This improves user convenience because the auto-charge settings can be completed seamlessly on the recurring payment service side. For example, the auto-charge settings can be completed without the payment service application launching midway or the user being redirected to the payment service's page.

[0142] [5-10. Variation 10] For example, electronic money can be used for payments other than recurring payments. In this case, it becomes difficult for the user to manage how much electronic money they are using for recurring payments. Therefore, a screen that distinguishes between the payment amount for recurring payments and the payment amount for other payments may be displayed. The auto-charge 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 for recurring payments and the payment amount for other payments different from recurring payments for each of the multiple payment dates. Distinguishing means displaying each payment amount separately.

[0143] Figure 10 shows an example of a payment amount screen. For example, on the payment amount screen G6, the total amount of payments for recurring payments and the total amount of payments for other payments are displayed separately. In the example in Figure 10, both the total amount and the individual breakdown are displayed on the payment amount screen G6, but either the total amount or the individual breakdown may be displayed on the payment amount screen G6. The total amount is aggregated on a monthly basis, but the user may be able to specify any aggregation period. For example, the total amount may be displayed on the payment amount screen G6 on a weekly or semi-annual basis.

[0144] In Modification 10, the electronic money usage history is stored in the electronic money database DB1. The usage history includes information that can identify whether it is a regular payment or another type of payment. The electronic money server 10 stores the usage history in the electronic money database DB1 each time electronic money is used. The second display control unit 108 aggregates the total amount of payments for regular payments and the total amount of payments for other types of payments based on the electronic money usage history. Based on these aggregated results, the second display control unit 108 generates the display data for the payment amount screen G6 and sends it to the user terminal 30.

[0145] The auto-charge system 1 of the modified version 10 displays a payment amount screen G6 that distinguishes between the payment amount for recurring payments on each of multiple payment dates and the payment amount for other payments that are not recurring payments. This reduces the administrative burden on the user to manage the payment amounts for recurring payments.

[0146] [5-11. Variation 11] For example, although the embodiment described a case where auto-charging is performed based on one charging method, auto-charging may be performed by using multiple charging methods in combination. The charging methods that can be used in combination with auto-charging may be combinations of the various methods described in the embodiment. The storage unit 101 of the modified example 11 can store each of multiple payment dates in association with an auto-charging setting that indicates a combination of multiple charging methods.

[0147] In the auto-charge setting of Modification 11, multiple charging methods are indicated. The charge amount for each charging method may be specified separately, or the multiple charging methods may be given priority. In the auto-charge execution unit 102 of Modification 11, if the auto-charge setting indicates a combination of multiple charging methods, it will perform auto-charging based on the multiple charging methods. Whether or not to use multiple charging methods in combination is at the user's discretion.

[0148] In the example shown in Figure 3, suppose the auto-charge setting for the 5th of each month is to use both a credit card and a bank account. For example, if the auto-charge setting indicates that 70% of the charge will be made by credit card and 30% by bank account, the auto-charge execution unit 102 will execute the auto-charge by charging 70% of the required amount by credit card and 30% of the required amount by bank account.

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

[0150] For example, in the example shown in Figure 3, suppose that the automatic charge setting for the 5th of each month has designated credit card as the first priority and bank account as the second priority. If the automatic charge execution unit 102 attempts to perform an automatic charge using the credit card and succeeds, it will not perform an automatic charge using the bank account. If the automatic charge fails, for example, due to insufficient credit card limits, the automatic charge execution unit 102 will then perform an automatic charge using the bank account, which has the next priority.

[0151] The auto-charge system 1 of the modified version 11 can associate and save each of multiple payment dates with an auto-charge setting that indicates a combination of multiple charging methods. If the auto-charge setting indicates a combination of multiple charging methods, the auto-charge system 1 performs auto-charging based on those multiple charging methods. This enables flexible auto-charging that combines multiple charging methods.

[0152] [5-12. Variations regarding other configurations] For example, this disclosure includes configurations that solve problems other than those that solve the problem of "improving user convenience when periodic payments to different payees occur on each of multiple payment dates." Therefore, this disclosure also includes configurations among those described in Modifications 1 to 11 that do not presuppose the configurations described in the embodiments. Hereafter, configurations that do not presuppose the configurations described in the embodiments will be described as modifications relating to Modifications 1 to 11.

[0153] [Differences related to Difference 1] For example, in Modification Example 1, there do not necessarily have to be multiple payment dates where regular payments to different payees occur. Multiple regular payments to different payees may occur on a single payment date. In the example described in Modification Example 1, the payment for the e-book service on the 25th of each month does not need to occur. In this case, the only monthly payments would be for the music and video streaming services on the 5th of each month, so there is only one payment date in a month.

[0154] For example, the storage unit 101 saves an auto-charge setting for the 5th of each month, which is based on the total amount of payments for music streaming services and video streaming services. The setting is to "restore the balance to 4,100 yen when the balance falls below 3,500 yen." Auto-charge settings do not need to be saved on days other than the 5th of each month. In this case, auto-charging will only be performed once a month.

[0155] Furthermore, within a single payment date, multiple recurring payments to the same payee may occur. For example, the service provider for a music distribution service and the service provider for a video distribution service may be the same. In this case, on the 5th of each month, payments will occur for multiple recurring payment services provided by the same payee. The storage unit 101 may also store auto-charge settings such as "when the balance falls below 3,500 yen, the balance will be increased to 4,100 yen" based on the total amount of multiple recurring payments to the same payee.

[0156] The modified auto-charge system 1 of Modification 1 enhances user convenience by saving auto-charge settings based on the total amount of multiple recurring payments occurring on a single payment date. This ensures that insufficient funds are prevented even if multiple recurring payments occur on a single payment date. Since the auto-charge settings are integrated within a single payment date, there is no need to manage multiple auto-charge settings, thus reducing the burden of managing auto-charge settings.

[0157] [Differences related to Difference 2] For example, the configuration of Modification 2, like the modification relating to Modification 1, does not necessarily have to have multiple payment dates where regular payments to different payees occur. For example, the monthly payments may consist only of music distribution services and video distribution services on the 5th of each month. In this case as well, if the payment times for the music distribution service and the video distribution service are different, the storage unit 101 may save the auto-charge settings up to each payment time separately, as in Modification 2.

[0158] For example, in Modification 2, as with Modification 1, multiple periodic payments to the same payee may occur on a single payment date. For example, even if the same service provider provides both a music distribution service and a video distribution service, the storage unit 101 may store separate auto-charge settings for the respective payment times of the music distribution service and the video distribution service provided by the same service provider, as in Modification 2.

[0159] In the modified auto-charge system 1 relating to Modification 2, flexible auto-charge is possible when multiple recurring payments occur on a single payment day, and the payment times for each of these multiple recurring payments are different from each other, by saving separate auto-charge settings for each payment time.

[0160] [Differences related to Difference 3] For example, the configuration of Modification 3, like the modifications relating to Modifications 1 and 2, does not necessarily have multiple payment dates that result in regular payments to different payees. For example, there may only be a music distribution service on the 5th of each month as a monthly payment. In this case, the auto-charge execution unit 102 may perform auto-charge on days other than the 5th of each month based on the default auto-charge settings.

[0161] For example, in Modification 3, regular payments to the same payee may occur on multiple payment dates. The service providers for 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 be the same. In this case, the auto-charge execution unit 102 may perform auto-charge on days other than the 5th, 13th, and 25th of each month based on the default auto-charge settings.

[0162] The auto-charge system 1 of the modified version 3 allows for more flexible auto-charge and increased user convenience because it can perform auto-charge based on the default auto-charge settings even if there are days within a certain period when no regular payments occur.

[0163] [Differences related to Difference 4] For example, the configuration of Modification 4, like the modifications related to Modifications 1-3, does not necessarily require multiple payment dates for recurring payments to different payees. For example, a calendar display like that in Modification 4 may be possible even if there is only one payment date each month. Alternatively, a calendar display like that in Modification 4 may also be possible even if there are multiple payment dates for recurring payments to the same payee.

[0164] The modified auto-charge system 1 relating to Modification 4 makes it easier to manage monthly auto-charge settings by displaying a calendar screen G5 that shows auto-charge settings associated with at least one payment date.

[0165] [Differences related to Variation 5] For example, the configuration of Modification 5, like the modifications relating to Modifications 1 to 4, does not necessarily require multiple payment dates in which regular payments are made to different payees. For example, even if there is only one payment date each month, the auto-charge execution unit 102 may perform an auto-charge immediately before the payment time, based on the auto-charge setting associated with the single payment date each month, as in Modification 5.

[0166] For example, even if recurring payments to the same payee occur on multiple payment dates, the auto-charge execution unit 102 may perform an auto-charge immediately before the payment time on each payment date, based on the auto-charge setting associated with that payment date, as shown in Modification 5. If multiple recurring payments occur within a single day, and the payment times for each payment are different, the auto-charge execution unit 102 may perform an auto-charge immediately before the payment time of each payment, based on the auto-charge setting associated with that payment time.

[0167] The modified auto-charge system 1 in Modification 5 performs an auto-charge immediately before the payment time on at least one payment date, based on the auto-charge setting associated with that payment date. Because the auto-charge is performed immediately before the payment time, insufficient balance at the time of payment can be prevented more reliably.

[0168] [Differences related to Difference 6] For example, the configuration of Modification 6, like the modifications relating to Modifications 1 to 5, does not necessarily have to have multiple payment dates in which regular payments are made to different payees. 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 history. Even if there is only one payment date each month, the decision unit 106 may determine the content of the auto-charge setting based on the next payment amount predicted by the prediction unit 105.

[0169] For example, even if regular payments to the same payee occur on multiple payment dates, the forecasting unit 105 may forecast the next payment amount based on past payment history. The decision unit 106 may also determine the content of the auto-charge setting based on the next payment amount forecasted by the forecasting unit 105, even if regular payments to the same payee occur on multiple payment dates.

[0170] The modified auto-charge system 1 in Modification 6 predicts the next payment amount and determines the auto-charge settings when the payment amount for regular payments on at least one payment date is not fixed. This makes it possible to set up auto-charge settings that are less likely to result in insufficient balance even if the payment amount is not fixed, thus improving user convenience.

[0171] [Differences related to Difference 7] For example, the configuration of Modification 7, like the modifications relating to Modifications 1 to 6, does not necessarily have to have multiple payment dates in which regular payments are made to different payees. 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 that one payment each month. The storage unit 101 may store the payment date that occurs only once a month in association with the auto-charge setting corresponding to a portion of the payment amount for payments using electronic money and other payment methods in combination.

[0172] For example, even if regular payments to the same payee occur on multiple payment dates, the storage unit 101 may associate and store the payment date and the auto-charge setting corresponding to a portion of the payment amount for payments made using electronic money and other payment methods, provided that combined payment is possible on at least one payment date.

[0173] The modified auto-charge system 1 of Modification 7 saves an auto-charge setting corresponding to the electronic money payment amount when payment using electronic money and other payment methods is possible on at least one payment day, thereby ensuring that the electronic money payment amount does not become insufficient even when multiple payment methods are used for payment.

[0174] [Differences related to Difference 8] For example, the configuration of Modification 8, like the modifications relating to Modifications 1 to 7, does not necessarily require multiple payment dates for regular payments to different payees. For example, even if there is only one payment date each month, the storage unit 101 may save the auto-charge setting corresponding to the determined payment amount after the payment amount for the regular payment has been determined.

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

[0176] The auto-charge system 1 of the modified version 8, if the payment amount for at least one payment date is not fixed, saves the auto-charge setting according to the confirmed payment amount after the payment amount has been confirmed. This makes it more reliable to prevent insufficient funds for the next payment, thereby improving user convenience.

[0177] [Variations related to Variation 9] For example, the configuration of Modification 9, like the modifications relating to Modifications 1 to 8, does not necessarily have to have multiple payment dates on which regular payments occur to different payees. For example, the receiving unit 107 may receive a notification even if there is only one payment date per month, when the payee's service provider server 20 performs an operation to agree to the auto-charge setting. For example, the receiving unit 107 may similarly receive a notification even if regular payments to the same payee occur on multiple payment dates.

[0178] Furthermore, automatic top-up settings may be enabled on the recurring payment service side, provided that the user information registered with the payment service matches the user information registered with the recurring payment service. User information can be any information relating to the user, such as name, email address, address, telephone number, or user ID. In this case, automatic top-up settings will not be enabled at the time of registration for the recurring payment service, but rather after registration for the recurring payment service.

[0179] In the modified auto-charge system 1 of Modification 9, the auto-charge setting associated with at least one payment date is performed on the recurring payment service side. This allows the auto-charge setting to be completed seamlessly on the recurring payment service side, thus increasing user convenience.

[0180] [Differences related to Difference 10] For example, the configuration of Modification 10, like the modifications relating to Modifications 1 to 9, does not necessarily have to have multiple payment dates in which regular payments occur to different payees. For example, even if 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 a month and the payment amounts for other payments. For example, the second display control unit 108 may similarly display the payment amount screen G6 even if regular payments to the same payee occur on multiple payment dates.

[0181] Furthermore, if electronic money is selected as the payment method for a recurring payment service and points are accumulated by the user, the second display control unit 108 may display on the payment amount screen G6 how many points were acquired as a result of selecting electronic money as the payment method. In this case, the second display control unit 108 may display the points earned for each recurring payment service on the payment amount screen G6. Points generated from payments for recurring payment services are stored in the electronic money database DB1.

[0182] The modified auto-charge system 1 relating to Modification 10 can reduce the user's management burden by displaying a payment amount screen G6 that distinguishes between the payment amount on at least one payment date and the payment amount in other payments.

[0183] [Differences related to Difference 11] For example, the configuration of Modification 11, like the modifications relating to Modifications 1 to 10, does not necessarily require multiple payment dates in which regular payments occur to different payees. For example, even if there is only one payment date each month, the storage unit 101 may save auto-charge settings so that multiple charging methods are used in combination on the single payment date each month. Similarly, even if there are multiple payment dates in which regular payments occur to the same payee, the storage unit 101 may save auto-charge settings so that multiple charging methods are used in combination.

[0184] The modified auto-charge system 1 of Modification 11 stores, in association with at least one payment date and an auto-charge setting indicating that multiple charging methods are used in combination. This enables flexible auto-charge combining multiple charging methods.

[0185] [5-13. Other variations] For example, the modified examples described above may be combined.

[0186] For example, a recurring payment service may be a service where paying members are required to pay a regular membership fee. For example, if there is a limit set for auto-charges in each month, the relationship between the current auto-charge amount and the limit may be displayed on the payment screen G6 or another screen. For example, if an auto-charge is to be disabled for a certain period after it has been executed, this restriction may be lifted immediately before the payment time.

[0187] For example, a recurring payment may not be a payment to a service provider, but rather a payment between individuals. In this case, the recurring payment could also be described as a regular remittance. For instance, a similar auto-charge mechanism could be used when a user sends money to their parents using electronic money. Furthermore, the recurring payment may not be executed automatically, but rather when the user initiates the payment. In this case, the user would perform the payment operation periodically.

[0188] For example, instead of having an auto-charge setting for each payment date, there may be an auto-charge setting for each payee. In this case, for payments to a specific payee, the auto-charge will be executed based on the auto-charge setting associated with that payee. For example, there may be types of electronic money that allow withdrawals and types that do not. The auto-charge setting may indicate which type of electronic money to auto-charge.

[0189] For example, a function described as being implemented on the electronic money server 10 may be implemented on the service provider server 20 or another server computer. A function described as being implemented on the service provider server 20 may be implemented on the electronic money server 10 or another server computer. For example, a function described as being implemented on the electronic money server 10 or the service provider server 20 may be shared among multiple computers. Each function should be implemented on at least one computer.

[0190] [6. Addendum] For example, the auto-charge system related to this disclosure can also be configured as follows: (1) A storage unit that stores, in association with each of several payment dates for which regular payments occur to different payees, and the auto-charge settings for the auto-charge of the payment method available for the said regular payments, An auto-charge execution unit that performs the auto-charge based on the auto-charge setting associated with each of the aforementioned multiple payment dates, An auto-charge system including this. (2) The storage unit stores, in association with the payment date and the auto-charge setting corresponding to the total amount of each of the multiple periodic payments, when multiple periodic payments occur on the payment date. (1) The auto-charge system described above. (3) The storage unit stores separate auto-charge settings for each payment time when multiple periodic payments occur on the payment date and the payment times for each of these periodic payments differ from one another on the payment date. The auto-charge execution unit performs the auto-charge based on the auto-charge setting associated with a predetermined payment time among the multiple periodic payments until that payment time has elapsed, and then performs the auto-charge based on the auto-charge setting associated with the next payment time among the multiple periodic payments. The auto-charge system described in (1) or (2). (4) The auto-charge execution unit executes the auto-charge on 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 auto-charge system described in any 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. The auto-charge system described in any of (1) to (4). (6) The storage unit stores each of the multiple payment dates in association with the auto-charge setting that indicates the balance after charging that is equal to or greater than the payment amount for the periodic payment on that payment date. The auto-charge execution unit performs the auto-charge so that the balance after charging becomes as indicated in the auto-charge setting associated with each of the plurality of payment dates. The auto-charge system described in any 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 multiple payment dates before the payment time arrives for that payment date. An auto-charge system as described in any of (1) to (6). (8) The auto-charge execution unit, when each of the multiple payment dates arrives, determines whether or not to perform the auto-charge at predetermined intervals until the payment time, based on the auto-charge setting associated with that payment date. (7) The auto-charge system described above. (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 that payment date. The auto-charge system described in (7) or (8). (10) The aforementioned auto-charge system is A prediction unit predicts the next payment amount for each of the aforementioned periodic payments on each of the aforementioned multiple payment dates, based on the payment history of the periodic payments for which the payment amount is not fixed. A determination unit determines the content of the auto-charge setting associated with the payment date of the periodic payment for which the payment amount is not fixed, based on the next payment amount predicted by the prediction unit, An auto-charge system as described in any of (1) to (9), further including the above. (11) The storage unit is capable of storing, in association with, the payment date of the periodic payment in which the payment method can be used in combination with other payment methods, and the auto-charge setting corresponding to a portion of the payment amount in the periodic payment. The auto-charge system described in (1) to (10). (12) The storage unit, for the payment date of a periodic payment among the multiple payment dates for which the payment amount is not fixed, stores the auto-charge setting associated with the determined payment amount after the payment amount for the periodic payment has been determined. The auto-charge system described in any of (1) to (11). (13) The auto-charge system further includes a receiving unit that receives a predetermined notification when an operation is performed to agree to the auto-charge setting at the payment destination service, The storage unit saves the auto-charge setting when it receives the notification. The auto-charge system described in any of (1) to (12). (14) The auto-charge system further includes a second display control unit that displays a payment amount screen that distinguishes between the payment amount for the periodic payment and the payment amount for other payments different from the periodic payment on each of the plurality of payment dates. The auto-charge system described in any of (1) to (13). (15) The storage unit stores each of the multiple payment dates and the auto-charge setting indicating the charge method selected from among the multiple charge methods, in association with each of them. The auto-charge system described in any of (1) to (14). (16) The storage unit is capable of storing each of the multiple payment dates and the auto-charge settings indicating a combination of multiple charging methods in association with each of them. If the auto-charge setting indicates a combination of the multiple charging methods, the auto-charge execution unit will perform the auto-charge based on the multiple charging methods. The auto-charge system described in any of (1) to (15). [Explanation of symbols]

[0191] 1 Auto-charge system, N network, 10 electronic money server, 11,21,31 control unit, 12,22,32 storage unit, 13,23,33 communication unit, 20 service provider server, 30 user terminal, 34 operation unit, 35 display unit, G1 top screen, G2 member registration screen, G3 auto-charge setting screen, G4 member 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 buttons, B22 radio buttons, DB1 Electronic money database, DB2 service database, F20, F30, F31, F32, input form, F50 input form, L11 link.

Claims

1. A system comprising an application installed on a user's user terminal, which allows registration for use of a service that generates recurring payments that can be used in combination with electronic money and points, and which includes a display control unit that displays a calendar screen showing the payment schedule.

2. An auto-charge setting for the electronic money that can be used for the aforementioned periodic payments, comprising a storage unit that stores the auto-charge setting specified in the application, An auto-charge execution unit that performs the auto-charge based on the auto-charge setting, The system according to claim 1, further comprising:

3. The system further includes a granting unit that grants the points generated in the payment to the user when the electronic money is selected as the payment method for the periodic payment. The system according to claim 1 or 2.

4. The aforementioned system, A reception unit that accepts the selection of any of the multiple payment methods available for the aforementioned periodic payments, including the aforementioned electronic money and the aforementioned points, A payment execution unit that performs the periodic payment based on the selected payment method from among the plurality of payment methods, The system according to claim 1 or 2, further comprising:

5. The display control unit displays the calendar screen showing the schedule for the periodic payments in the financial services. The storage unit stores the auto-charge settings for the electronic money available for use in the periodic payments in the financial service. The system according to claim 2.

6. The storage unit stores the charge amount in the auto-charge as the auto-charge setting. The auto-charge execution unit performs the auto-charge based on the charge amount. The system according to claim 2.

7. The display control unit displays the calendar screen showing the schedule for each of the multiple periodic payments that occur within a month. The system according to claim 1 or 2.

8. The display control unit causes the calendar screen to display the schedule for each of the multiple periodic payments, each with a different period. The system according to claim 1 or 2.

9. A method for performing a display control step in which a computer performs a display control step in which a calendar screen showing the payment schedule is displayed in an application installed on a user's user terminal that allows registration for use of a service that generates regular payments that can be used in combination with electronic money and points.

10. A program for causing a computer to function as a display control unit that displays a calendar screen showing the payment schedule, for an application installed on a user's terminal that allows registration for use of a service that generates regular payments that can be used in combination with electronic money and points.

Images