Information processing device, information processing system, information processing method, and program

Abstract

To improve user convenience by providing a centralized view of information regarding multiple recurring subscription services used by a user. [Solution] An information processing device that can communicate with a user terminal device operated by a user, comprising: an information acquisition unit that acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the user; a screen generation unit that generates a management screen, including the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services, based on the recurring billing information; and a display control unit that transmits the management screen to the user terminal device for display.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing system, an information processing method, and a program.

Background Art

[0002] Conventionally, when a user uses a continuous billing service such as a subscription, a billing method that continuously bills a certain amount has been applied to the user. For example, Patent Document 1 proposes an information processing apparatus that performs electronic settlement for a user's continuous billing in response to a settlement request from a franchise store that provides a continuous billing service (subscription service).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the information processing apparatus in the above prior art cannot unify and visualize information on a plurality of continuous billing services used by a user, so there are cases where convenience is low.

[0005] The present invention has been made in consideration of such circumstances, and one of the purposes is to provide an information processing apparatus, an information processing system, an information processing method, and a program that can improve convenience by unifying and visualizing information on a plurality of continuous billing services used by a user.

Means for Solving the Problems

[0006] One aspect of the present invention is an information processing device that can communicate with a user terminal device operated by a user, comprising: an information acquisition unit that acquires recurring billing information, including the scheduled payment date and scheduled payment amount, relating to a plurality of recurring billing services used by the user; a screen generation unit that generates a management screen, including the total scheduled payment amount and individual scheduled payment lists for the plurality of recurring billing services, based on the recurring billing information; and a display control unit that transmits the management screen to the user terminal device for display. [Effects of the Invention]

[0007] According to one aspect of the present invention, it is possible to provide an information processing device, an information processing system, an information processing method, and a program that can improve convenience by centrally visualizing information regarding multiple recurring billing services used by a user. [Brief explanation of the drawing]

[0008] [Figure 1] This diagram shows an example of a configuration for implementing an electronic payment service. [Figure 2] This is a sequence diagram (part 1) illustrating the general flow of electronic payments. [Figure 3] This is a sequence diagram (part 2) illustrating the general flow of electronic payments. [Figure 4] This is a diagram showing the configuration of payment server 100. [Figure 5] This figure shows an example of the contents of user information 171. [Figure 6] This diagram shows an example of the contents of merchant / store information 173. [Figure 7] This figure shows an example of the contents of recurring billing information 174. [Figure 8] This diagram shows an example of the content of campaign information 175. [Figure 9] This is an example of the IM1 top screen of payment app 20. [Figure 10] This figure shows the first example of a recurring billing management screen, IM2-1. [Figure 11] This figure shows IM2-2, a second recurring billing management screen, which is another example of a recurring billing management screen. [Figure 12] This figure shows an example of the recurring billing details screen IM3. [Figure 13] This is an example of the standby screen IM4 when a push notification is received. [Figure 14] This flowchart shows an example of the processing flow performed by the payment server 100. [Modes for carrying out the invention]

[0009] The following describes embodiments of the information processing apparatus, information processing system, information processing method, and program of the present invention with reference to the drawings. Various devices such as "servers" that appear below, which provide services to users or perform internal analysis, may be implemented by a distributed group of devices, and the operators of each device may be different. Furthermore, the owner of the hardware of the devices (the provider of the cloud server) and the operator that actually operates them may also be different. An electronic payment service is a service that supports payment for the purchase of goods and services at a store. A store is, for example, a physical store (a real store) that exists in the real world, but it may also include a virtual store for e-commerce. A virtual store may include one provided by an entity different from the electronic payment service provider. In that case, when settling a purchase at a virtual store, the user is controlled to transition to the interface screen of the electronic payment service. In an electronic payment service, a store is treated as belonging to, for example, a merchant (brand), and processing such as payment when a purchase is made at a store is mainly carried out between the user and the merchant. Alternatively, processing such as payment may be carried out between the user and the store.

[0010] [Electronic payment service] FIG. 1 is a diagram showing an example of a configuration for realizing an electronic payment service. The electronic payment service is realized centering around a payment server 100. The payment server 100 communicates with each of, for example, one or more user terminal devices 10, one or more first store terminal devices 50, one or more second store terminal devices 70, a financial institution server 200, and a credit server 300 via a network NW. The network NW includes, for example, the Internet, a LAN (Local Area Network), a wireless base station, a provider device, and the like.

[0011] Part or all of the functional configurations included in the electronic payment system may be distributed among a plurality of devices in any form or integrated into any device. For example, part or all of the functional configuration of the payment server 100 may be included in other devices.

[0012] [User Terminal Device] The user terminal device 10 is, for example, a portable terminal device such as a smartphone or a tablet terminal. The user terminal device 10 is a computer device having at least an optical reading function, a communication function, a display function, an input reception function, and a program execution function. In the following description, the configurations for realizing these functions are respectively referred to as a camera, a communication device, a touch panel, a CPU (Central Processing Unit), etc. In the user terminal device 10, a payment application (hereinafter referred to as a payment app) 20 is executed by a processor such as a CPU, and operates to provide an electronic payment service to the user in cooperation with the payment server 100. The payment app 20 is installed in the user terminal device 10 from, for example, an application store, and controls a camera, a communication device, a touch panel, etc.

[0013] [First Store Terminal Device] The first store terminal device 50 is installed in a store, for example. The first store terminal device 50 is a computer device having at least a product price acquisition function, an optical reading function, a program execution function, and a communication function. The first store terminal device 50 includes a so-called POS (Point of Sale) device, and the product price acquisition function and the optical reading function may be realized by the POS device. The store code image 60 is placed in the store and is a code image such as a QR code (registered trademark) printed on a paper or plastic medium. Note that the store code image 60 may be displayed by a display placed in the store (which may be the display of a terminal device such as a smartphone).

[0014] [Second Store Terminal Device] The second store terminal device 70 is used by the operator of the franchise store. The second store terminal device 70 is a smartphone, a tablet terminal, a personal computer, or the like. In the second store terminal device 70, an interface 72 for franchise stores operates. The interface 72 for franchise stores may be an application for franchise stores or a browser. The interface 72 for franchise stores accepts settings of coupons, etc. by the operator of the franchise store and transmits them to the settlement server 100. The second store terminal device 70, which is a smartphone, has a function of displaying a code image corresponding to the store code image or reading the code image displayed by the user terminal device 10 by executing an application for franchise stores.

[0015] [Settlement Server] The payment server 100 implements electronic payment based on payment information received from the user terminal device 10 or the first store terminal device 50. The first store terminal device 50 may include a POS device and a merchant server, in which case payment information is transmitted from the POS device to the payment server 100 via the merchant server. In the following description, these will not be specifically distinguished, and it will be assumed that payment information is transmitted from the first store terminal device 50. As will be described in detail later, the payment server 100 has an interface for receiving information necessary for recurring billing from a merchant terminal (e.g., a second store terminal device 70) or a merchant server (not shown) via at least one of an API (Application Programming Interface) request and file transmission.

[0016] [Financial institution server] The financial institution server 200 is a computer that manages accounts at a financial institution and communicates with the settlement server 100 via a network NW. The financial institution may be a financial institution that is part of the group of an electronic payment service provider. The financial institution may be, for example, an institution that provides financial services such as a bank or a securities company. In this embodiment, an example in which the financial institution is a bank will be described.

[0017] [Credit Server] Credit Server 300 is a server for providing card payment services to users. Card payment services are services that allow payments to be made using credit cards. Credit Server 300 may be a server operated by, for example, a group company (affiliated credit card company) of the electronic payment service provider that operates Payment Server 100. The affiliated credit card company may be a different business from the external credit card company that provides credit cards as a fund source for charging the charge balance.

[0018] Figures 2 and 3 are sequence diagrams illustrating the general flow of electronic payments. There may be two patterns for electronic payments: Pattern 1 and Pattern 2.

[0019] In the case of Pattern 1 shown in Figure 2 (hereinafter referred to as User Scan), the user terminal device 10, with the payment application 20 running, decodes the store code image 60 using its optical reading function (S1). The store code image 60 contains information about the store URL (Uniform Resource Locator). This store URL is an electronic payment service domain to which information that can identify the store has been added, and is associated with the merchant ID and store ID, etc., at the payment server 100 (described later). The payment application 20 sends the first payment information, including the store URL and account ID, to the payment server 100 (S2). The payment server 100 searches for store information (described later) from the merchant ID and store ID corresponding to the store URL, obtains the merchant name and store name information (S3), and sends it to the payment application 20 (S4). The user enters the payment amount into the user terminal device 10 on the screen where the merchant name and store name are displayed (S5). The user terminal device 10 then generates second payment information, including at least the payment amount, and sends it to the payment server 100 (S6). The payment server 100 performs electronic payment based on the received second payment information (S7). The payment server 100 then sends a payment completion notification (information for displaying the payment completion screen) to the payment application 20 (S8), and the payment application 20 displays the payment completion screen (S9). If the store code image 60 is displayed on a display placed in the store, the store code image 60 may include payment amount information as well as the store URL. In this case, the procedure for the user to enter the payment amount is omitted, and the payment amount information is included in the first payment information and sent to the payment server 100. Merchant name and store name information may be included and displayed on the payment completion screen.

[0020] In the case of Pattern 2 shown in Figure 3 (hereinafter referred to as Store Scan), when the payment app 20 is launched, when a payment operation is performed in the payment app 20, when it is time for an automatic update (for example, every minute), and at other times, the payment app 20 sends a request to the payment server 100 to issue a one-time code (S11). The payment server 100 generates a one-time code (S12) and sends it to the payment app 20 (S13). The payment app 20 displays a code image such as a QR code (registered trademark) or barcode generated based on the one-time code (S14). The user holds the display surface of the user terminal device 10 over the first store terminal device 50 (presents it), and the first store terminal device 50 decodes the code image using its optical reading function and obtains the one-time code, etc. (S15). Then, the first store terminal device 50 generates payment information including the one-time code, payment amount, merchant ID, store ID, etc., and sends it to the payment server 100 (S16). The payment amount information is obtained in advance by barcode scanning or manual input. Based on the received information, the payment server 100 identifies the user corresponding to the one-time code and performs the electronic payment (S17). The payment server 100 then sends a payment completion notification to the payment app 20 (S18), and the payment app 20 displays a payment completion screen (S19).

[0021] Furthermore, electronic payment may be performed using only one of the above patterns. Also, the "account ID" explained in Figure 2 may be other information that can be used as user identification information (for example, a phone number). In addition, the issuance of a one-time code may be omitted during store scanning, and the payment app 20 may display a code image generated based on the user's account ID. In that case, the payment server 100 identifies the user corresponding to the account ID instead of identifying the user corresponding to the one-time code.

[0022] [Payment Server] Figure 4 is a diagram of the configuration of the payment server 100. The payment server 100 includes, for example, a communication unit 110, a payment content provision unit 115, a payment processing unit 120, an information management unit 125, an information acquisition unit 130, a screen generation unit 135, a display control unit 140, a notification unit 145, a timing determination unit 150, a payment method setting unit 155, a proposal unit 160, and a storage unit 170. Components other than the communication unit 110 and the storage unit 170 are realized, for example, by a hardware processor such as a CPU executing a program (software). Some or all of these components may be realized by hardware (including circuitry) such as LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array), and GPU (Graphics Processing Unit), or by the cooperation of software and hardware. The program may be stored in advance on a storage device such as an HDD (Hard Disk Drive) or flash memory (a storage device equipped with a non-transient storage medium), or it may be stored on a removable storage medium such as a DVD or CD-ROM (a non-transient storage medium) and installed on the storage device when the storage medium is inserted into the drive device.

[0023] The storage unit 170 can be an HDD, flash memory, RAM (Random Access Memory), etc. The storage unit 170 may also be a NAS (Network Attached Storage) device that can be accessed by the payment server 100 via the network. The storage unit 170 stores information such as user information 171, payment content information 172, merchant / store information 173, recurring billing information 174, and campaign information 175.

[0024] The communication unit 110 is a communication interface for connecting to a network NW. The communication unit 110 is, for example, a network interface card.

[0025] The payment content provision unit 115, for example, has the functionality of a web server and provides information (content) for displaying various screens of the electronic payment service to the user terminal device 10. The payment content provision unit 115 reads the necessary content from the payment content information 172 as appropriate and provides it to the user terminal device 10. The user terminal device 10 receives various inputs from the user while the content is being played by the payment application 20 and transmits the aforementioned payment information, etc., to the payment server 100.

[0026] The payment processing unit 120 performs payment processing based on payment information transmitted by the user terminal device 10 or the first store terminal device 50. The payment processing unit 120 performs payment processing while referring to the user information 171. The payment processing unit 120 also has the function of causing the financial institution server 200 to perform account balance settlement and the credit server 300 to perform credit card payment.

[0027] [User information] Figure 5 shows an example of the contents of User Information 171. User Information 171 is an example of user registration information. User Information 171 includes, for example, user URL, account ID, telephone number, password, as well as information such as email address, user ID, name, address, date of birth, registration date, electronic money balance, credit payment settings, credit payment limit, credit payment amount, available credit payment amount, payment method settings, bank account, credit card, charge history information, payment history information, points, reminder settings, and auto-charge settings. The user URL is used for money transfer processing between users. When registering for a new electronic payment service, registration of a telephone number and password is mandatory. The account ID is issued to the user by the payment server 100, and the user ID is an ID that the user can set at will (or not set). Similarly, the email address and name, address, and date of birth are also information that the user can set at will (or not set). The registration date is the date the user registered for the electronic payment service (the date the account was created). Hereafter, the user instance (electronic payment account) to which this information is associated will be referred to as an account.

[0028] The electronic money balance is information indicating the balance of electronic money that has been set up by the user by sending money to their account in advance. Methods of sending money include sending from an ATM (Automatic Teller Machine) of a designated provider (bank), sending from a registered bank account, etc. Sending from a bank account may also be done via direct debit. When charging electronic money, the charge amount is automatically debited from the user's bank account and transferred to the electronic payment service provider's account. The electronic payment service provider then charges the user's electronic money upon receipt of the funds into their account. Users may register multiple bank accounts. In this case, the user may select the bank account from which to send the funds when charging. The credit payment setting indicates whether or not the user has completed the settings to enable electronic payments via credit card, and is set to either "Completed" or "Not Completed". The credit limit is the monthly limit on credit payments that can be made. The credit payment amount is the amount already used for credit payments during the current month. The available credit payment amount is the amount available for credit payments during the current month, calculated by subtracting the credit payment amount from the credit limit. Although the diagram shows only one credit limit, in reality there are also daily limits, etc., and the lower of these may be set as the credit limit. Further details on credit payments will be described later. The payment method setting is setting information that indicates whether the user will make an electronic payment using their electronic money balance, an electronic payment using a credit card, or an account balance payment using their bank account deposit balance at that time. The bank account is information about a bank account that can be used to deposit funds into the electronic payment service (branch number, account number, etc.). The credit card is information about a credit card that can be used to deposit funds into the electronic payment service (card number, etc.). The charge history information is a history of when the user has previously sent money to the electronic payment service to increase their electronic money balance. Payment history information is data that shows the details of each payment made by the user (date and time, store ID of the store where the purchase was made, payment amount, payment method, etc.).

[0029] Points are information indicating the number of points a user possesses. Points can be used in the same way as electronic money in electronic payments, and for example, 1 point may be equivalent to 1 yen. Reminder settings are settings related to reminders for payment schedules of recurring billing services (e.g., subscription services). For example, it may be possible to set whether or not to send reminders, and how many days before the scheduled payment date the reminder should be sent. Auto-charge settings are information indicating whether auto-charge is enabled or disabled. Auto-charge is a function that automatically charges electronic money to the user's account in the electronic payment service. Note that the account ID in user information 171 may be associated with a one-time code issued to the user (for example, the most recently issued one-time code).

[0030] [Franchise / Store Information] Figure 6 shows an example of the contents of the merchant / store information 173. The merchant / store information 173 includes, for example, a first table 173A in which the merchant ID and store ID are associated with the store URL, a second table 173B in which the merchant name and sales amount (as described above) are associated with the merchant ID, and a third table 173C in which the store name is associated with the store ID. In addition to this information, the merchant / store information 173 may also include information such as the merchant or store category, store location, and payment pattern.

[0031] [Electronic payment] When the payment processing unit 120 obtains payment information from the user terminal device 10 or the first store terminal device 50, it refers to the user information 171 to obtain the user's "payment method setting". For users whose "payment method setting" is set to "electronic money balance", the payment processing unit 120 performs electronic payment as follows. For example, the payment processing unit 120 performs electronic payment by decreasing the electronic money balance managed in association with the account ID in the user information 171 and increasing the value of the merchant's sales amount managed in association with the merchant ID in the second table 173B of the merchant / store information 173. The value of the merchant's sales amount is not used as electronic money itself, for example, but rather the amount corresponding to the value of the merchant's sales amount is transferred to the merchant's bank account in a cycle according to the agreement between the merchant and the electronic payment service. The merchant may receive the sales amount as electronic money. In this case, the information management unit 125 may store the merchant wallet information, in which the merchant's electronic money balance is recorded, in the storage unit 170.

[0032] The payment processing unit 120 performs electronic payment for users whose "payment method setting" is set to "credit card payment" as follows. Credit card payment is a payment method that cooperates with a credit card company, which is a separate entity from the electronic payment service provider, and allows electronic payment that does not depend on the electronic money balance within the credit limit. In order to use the credit card payment service, it may be required to obtain a credit card provided by the electronic payment service provider. The amount used by credit card payment is settled by requesting it from the credit server 300. In this case, the payment processing unit 120 sends the payment amount to the credit card company to process the credit card payment and updates the credit card payment information in the user information 171. Specifically, the payment processing unit 120 adds the payment amount to the credit card usage amount in the user information 171 and subtracts the same amount from the available credit card payment amount. If the payment amount exceeds the available credit card payment amount, an error notification is sent back to the payment application 20.

[0033] The settlement processing unit 120 performs electronic payment as follows for users whose "payment method setting" is set to "account balance payment". Account balance payment is a payment method that cooperates with a financial institution (bank), which is a separate entity from the electronic payment service provider, and performs electronic payment by deducting the payment amount from the user's bank account balance. Note that in order to use the account balance payment service, the user may be required to open an account with a bank designated by the electronic payment service provider. The amount used for account balance payment is settled by requesting the financial institution server 200. In this case, the financial institution server 200 transfers the payment amount from the user's account to the electronic payment service provider's account and performs electronic payment by increasing the value of the sales amount item managed in association with the merchant ID in the second table 173B. This makes it possible to temporarily move the merchant's sales amount to the electronic payment service provider's account. As mentioned above, the merchant's sales amount will be sent to the merchant's bank account in a cycle according to the agreement between the merchant and the electronic payment service.

[0034] [Recurring billing information] Figure 7 shows an example of the contents of recurring billing information 174. Recurring billing information 174 is information about recurring billing services such as subscription services that the user has contracted. A subscription service is a service in which the user periodically purchases the right to use goods or services for a certain period of time.

[0035] The recurring billing information 174 is information that associates, for example, the account ID, merchant ID, service name, payment cycle, scheduled payment date, scheduled payment amount, and payment method. The account ID is the same information as the account ID included in user information 171 (Figure 5) and is identification information for identifying the user. The merchant ID is the same information as the merchant ID included in merchant / store information 173 (Figure 6) and is identification information for identifying the merchant that provides the recurring billing service used by the user. The service name is the name of the recurring billing service. The payment cycle is information that indicates the cycle for which payments for the recurring billing service are made (for example, the ○th of every month, the ○th of every year, etc.). The scheduled payment date is information that indicates the next scheduled payment date for the recurring billing service. The scheduled payment amount is information that indicates the payment amount that the user should pay on the next scheduled payment date. The payment method is information that indicates the payment method used for settling the recurring billing service.

[0036] The payment method may include, for example, electronic money balance, credit card payment, and bank account balance. Furthermore, multiple payment methods and their priority levels may be set. For example, if electronic money balance (first priority) and bank account balance (second priority) are set as payment methods, the electronic money balance will be used first for settling recurring billing services, and if the electronic money balance is insufficient, the bank account balance may be used to cover the shortfall.

[0037] [Campaign Information] Figure 8 shows an example of the contents of campaign information 175. Campaign information 175 includes information about campaigns being conducted at participating stores. Campaign information 175 is, for example, information that associates a campaign ID, the target period, the conditions, and the reward. The campaign ID is identification information for identifying the campaign. The target period is information indicating the period during which the campaign is conducted. The conditions are information indicating the conditions under which users can receive the campaign reward. The reward is information indicating the reward for the campaign.

[0038] [Processing related to recurring billing services] Next, the processing related to the recurring billing service of this embodiment will be described. In conventional recurring billing services, existing payment functions such as credit cards, bank account transfers, or electronic payment services were used. Users had to individually check which recurring billing service they were registered for on the website of each service provider (merchant), on their credit card statements, on their bank account withdrawal history, or on the transaction history screen of the electronic payment service. While the transaction history screen of the electronic payment service allowed users to check the history after payment completion, there was no function to check a list of pending "future payment schedules," nor were there any links to top up or change the payment method associated with them.

[0039] Therefore, with conventional technology, users could not comprehensively grasp the "scheduled payment date" and "scheduled payment amount" for multiple recurring billing services that they were paying for with their electronic money balance in one place, resulting in low convenience. In addition, if a payment failed, it was time-consuming to identify which recurring billing service and which payment method failed.

[0040] Therefore, the payment server 100 of this embodiment adds a "recurring billing management screen" within the payment application 20, centrally visualizing information on all recurring billing services that the user is using via the electronic payment service, and providing integrated preventative action pathways to prevent payment failures due to insufficient funds. Furthermore, based on the recurring billing information 174 it possesses, the payment server 100 of this embodiment sends advance notifications (push notifications) to the user terminal device 10 prompting the user to charge their electronic money balance or switch payment methods before the scheduled payment date, and dynamically provides a dedicated recurring billing management screen. As a result, the payment server 100 of this embodiment can minimize the payment failure rate due to insufficient funds, improve convenience for users, and increase sales for merchants.

[0041] [Payment app home screen] Figure 9 shows an example of the top screen IM1 of the payment app 20. As shown in Figure 9, the top screen IM1 of the payment app 20 includes areas A1 to A4 and button B1. Area A1 displays code images such as barcodes and QR codes (registered trademarks) used for smartphone payments. Area A2 displays icons for instructing major smartphone payment operations such as scanning, sending money, charging, and setting payment methods. Area A3 displays the user's electronic money balance or bank account balance. If electronic money balance is selected as the payment method, the user's electronic money balance is displayed in area A3. On the other hand, if bank account balance payment is selected as the payment method, the user's bank account balance is displayed in area A3. If credit card payment is selected as the payment method, the user's available credit card payment amount may be displayed in area A3.

[0042] Area A4 displays various icons for launching various mini-applications that can be executed with the payment application 20. Specifically, area A4 displays eight icons IC1 to IC8. Icons IC1 to IC6 are icons for launching mini-applications. When the user selects (taps) any of icons IC1 to IC6, the payment application 20 launches the mini-application corresponding to the selected icon. Icon IC7 is the favorites icon. When the user selects (taps) icon IC7, the payment application 20 displays a favorites screen on the display unit of the user terminal device 10, showing a list of the user's pre-set favorite mini-applications. Icon IC8 is the function list icon. When the user selects (tap) icon IC8, the payment application 20 displays a function list screen on the display unit of the user terminal device 10, showing a list of all mini-applications.

[0043] For example, icon IC1 is an icon for launching a mini-application for a recurring billing service. When a user selects (tap) icon IC1, the payment application 20 displays the recurring billing management screen, which will be described later, on the display unit of the user terminal device 10.

[0044] At the bottom of the top screen IM1, a payment button B1 is displayed. When the user selects (tap) the payment button B1, the payment screen is displayed. By the user taking a picture of the store code image 60 from the payment screen, the user scan electronic payment is performed as described above. Alternatively, when the first store terminal device 50 reads the code image displayed on the payment screen, the store scan electronic payment is performed as described above.

[0045] The payment application 20 may also obtain a payment history screen, including payment history information, from the payment server 100 and display it on the display unit of the user terminal device 10. This allows the user to easily check their payment history.

[0046] [Subscription management screen] Figure 10 shows an example of a recurring billing management screen, specifically the first recurring billing management screen IM2-1. The first recurring billing management screen IM2-1 is an example of a recurring billing management screen when no errors such as payment failures have occurred. As shown in Figure 10, the first recurring billing management screen IM2-1 includes multiple areas A5 to A9.

[0047] Area A5 is the area where payment schedule information is displayed. In the example shown in Figure 10, the message "You are scheduled to pay a total of 6,000 yen for three services" is displayed in area A5. By checking area A5, users can easily understand the total amount of payments scheduled for multiple recurring billing services.

[0048] Areas A6-A8 are areas where various information about multiple recurring billing services subscribed to by the user is displayed. This information may include, for example, status, service name, expected payment amount, and expected payment date.

[0049] Specifically, area A6 displays that the status is "Payment Scheduled," the service name is "Service A," the payment amount is "1000 yen," and the payment date is "May 1, 2026." Area A7 displays that the status is "Payment Scheduled," the service name is "Service B," the payment amount is "3000 yen," and the payment date is "May 5, 2026." Area A8 displays that the status is "Payment Scheduled," the service name is "Service C," the payment amount is "2000 yen," and the payment date is "May 10, 2026." By checking areas A6 to A8, users can easily grasp information about multiple recurring billing services scheduled for payment.

[0050] Area A9 is where various settings related to the recurring billing service are displayed. These settings may include, for example, reminder settings, auto-charge, bank account registration, and payment method priority settings. Users can configure these settings by selecting (tapping) any of the settings displayed in Area A9.

[0051] In this embodiment, the first recurring billing management screen IM2-1 displays the "scheduled payment date" for each of the multiple recurring billing services, but the "final payment date" may be displayed instead. The payment server 100 may not actually be able to know the scheduled payment date in advance. In this case, the payment server 100 can allow the user to anticipate the scheduled payment date to some extent by presenting the final payment date to the user.

[0052] When a user selects (tap) "Set Reminder" in area A9, the payment app 20 displays the reminder setting screen (not shown). When a reminder is set from this screen, the information management unit 125 records information such as whether or not to notify the user of the reminder, and the timing of the notification (for example, information such as notifying the user a certain number of days before the scheduled payment date) in the "Set Reminder" field of the user information 171.

[0053] When a user selects (tap) "Auto-charge settings" in area A9, the payment app 20 displays the auto-charge settings screen (not shown). When auto-charge settings are made from this screen, the information management unit 125 records information such as whether auto-charge is enabled or disabled in the "Auto-charge settings" field of the user information 171.

[0054] When a user selects (tap) "Bank Account Registration" in area A9, the payment app 20 displays a bank account registration screen (not shown). Once a bank account is registered from this screen, the information management unit 125 records information about the user's bank account used for payment (e.g., store number, account number, etc.) in the "Bank Account" field of the user information 171.

[0055] When a user selects (tap) "Payment Method Priority" in area A9, the payment app 20 displays a payment method priority setting screen (not shown). Once the payment method priority is set from this screen, the information management unit 125 records the priority of the payment method to be used for payment in the "Payment Method" field of the recurring billing information 174.

[0056] Figure 11 shows the second recurring billing management screen IM2-2, which is another example of a recurring billing management screen. The second recurring billing management screen IM2-2 shows an example of a recurring billing management screen when an error such as a payment failure occurs. As shown in Figure 11, the second recurring billing management screen IM2-2 also contains multiple areas A5 to A9, similar to the first recurring billing management screen IM2-1 (Figure 10).

[0057] In the example shown in Figure 11, a payment failure occurs due to insufficient electronic money balance. Therefore, the message "Electronic payment for Service A failed due to insufficient electronic money balance" is displayed in area A5. By checking area A5, users can easily understand the reason for the payment failure and the service that experienced the failure.

[0058] Area A6 displays that the status is "Payment Failed," the service name is "Service A," the payment amount is "1000 yen," and the payment date is "May 1, 2026." For example, if the electronic payment fails for reasons such as the electronic money balance being insufficient to cover the payment amount, or the payment amount exceeding the available credit limit, the status will be "Payment Failed." By checking Area A6, users can easily find information about recurring billing services for which electronic payments have failed.

[0059] Area A7 displays that the status is "Pending," the service name is "Service B," the payment amount is "3000 yen," and the payment date is "May 5, 2026." For example, if an irregular situation occurs, such as when an electronic payment for a recurring billing service has been made but the merchant has not been able to confirm the payment, the status will be "Pending." By checking Area A7, users can easily understand information about recurring billing services where an irregular situation has occurred. Note that the "Pending" status may not be displayed in the second recurring billing management screen IM2-2. In this case, the payment processing unit 120 may invalidate the session for an electronic payment if the merchant has not executed the payment for a certain period of time despite the electronic payment for the recurring billing service having been made. For example, the payment processing unit 120 may invalidate the session for an electronic payment if the merchant has not executed the payment even after a predetermined number of days have passed since the payment date.

[0060] Area A8 displays the same information as the first recurring billing management screen IM2-1 (Figure 10), showing that the status is "Payment Scheduled," the service name is "Service C," the payment amount is "2000 yen," and the payment date is "May 10, 2026." By checking Area A8, users can easily understand the information about recurring billing services scheduled for payment.

[0061] In the following explanation, unless we specifically distinguish between the first recurring billing management screen IM2-1 and the second recurring billing management screen IM2-2, we will simply refer to it as "recurring billing management screen IM2".

[0062] As shown in Figures 11 and 12, the screen generation unit 135 generates a recurring billing management screen IM2 that includes the status of each of the multiple recurring billing services. The status may indicate payment failed, pending, or payment scheduled. This allows users to easily understand the status of each of the multiple recurring billing services (payment failed, pending, payment scheduled, etc.).

[0063] Furthermore, if the screen generation unit 135 is insufficient to cover the total payment amount (the sum of the payment amounts for multiple recurring billing services), it may generate a recurring billing management screen IM2 that includes a message indicating that there is a shortfall. For example, the screen generation unit 135 may display the message "Your electronic money balance is insufficient" on the recurring billing management screen IM2. This allows the payment server 100 in this embodiment to prompt the user to top up their electronic money balance.

[0064] Furthermore, the screen generation unit 135 may generate a recurring billing management screen IM2 that includes a link to transition to a charge screen (not shown) for charging the insufficient amount, or a link to transition to an auto-charge settings screen (not shown) for setting up auto-charge for electronic money. For example, in the recurring billing management screen IM2, the screen generation unit 135 may display a message indicating that an insufficient amount has occurred, along with a link to the charge screen as a charge button, or a link to the auto-charge settings screen as a fixed banner. This allows the payment server 100 of this embodiment to prompt the user to take action to prevent insufficient balance in electronic money at the time of payment.

[0065] Furthermore, the screen generation unit 135 may generate a recurring billing management screen IM2 that includes the payment methods set for each of the multiple recurring billing services, and a path to transition to a priority setting screen (not shown) for setting the priority of payment methods. This allows users to easily switch to other payment methods (e.g., credit card payment, bank account balance, etc.) if, for example, they are concerned about insufficient balance in their electronic money account.

[0066] [Subscription Details Screen] When a user selects (tap) any of areas A6 to A8 on the recurring billing management screen IM2, the screen generation unit 135 generates a recurring billing details screen that shows the details of the recurring billing service corresponding to the selected area. The display control unit 140 then sends the generated recurring billing details screen to the user terminal device 10 (payment application 20) for display.

[0067] Figure 12 shows an example of the recurring billing details screen IM3. The recurring billing details screen IM3 is a screen that displays detailed information regarding the payment of recurring billing services. Note that the recurring billing details screen IM3 shown in Figure 12 is an example of the screen that appears when the user selects (tap) area A8 in the second recurring billing management screen IM2-2 (Figure 11). As shown in Figure 12, the recurring billing details screen IM3 contains multiple areas A10 to A14.

[0068] Area A10 is where the service name and payment cycle of a recurring billing service are displayed. In the example shown in Figure 12, area A10 displays that the service name is "Service C" and the payment cycle is "the 10th of every month".

[0069] Area A11 is where the payment status, scheduled payment date, and scheduled payment amount for the recurring billing service are displayed. In the example shown in Figure 12, Area A11 displays that the status is "Scheduled Payment," the scheduled payment date is "May 10, 2026," and the scheduled payment amount is "2000 yen."

[0070] Area A12 is the area where the payment method for the recurring billing service is displayed. In the example shown in Figure 12, area A12 displays that the payment method is "electronic money balance". When the user selects (tap) area A12, the payment app 20 displays a payment method change screen (not shown) on the display unit of the user terminal device 10. On the payment method change screen, the user can change the payment method for the recurring billing service (for example, electronic money balance, credit card payment, bank account balance, etc.).

[0071] Areas A13 and A14 are where the payment history for recurring subscription services is displayed. In the example shown in Figure 13, area A13 displays that the service name for the recurring subscription service for which payment has been completed is "Service C", the payment amount is "2000 yen", the status is "Payment Complete", and the payment date is "April 10, 2026". Also, area A14 displays that the service name for the recurring subscription service for which payment has been completed is "Service C", the payment amount is "2000 yen", the status is "Payment Complete", and the payment date is "March 10, 2026". By checking the recurring subscription details screen IM3, users can easily grasp both information about upcoming recurring subscription services and their past payment history.

[0072] [Push notifications] The notification unit 145 sends a pre-notification to the user terminal device 10, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date. For example, the notification unit 145 may send a pre-notification if the user has set the reminder setting to "notify". The pre-notification may be a push notification to the user terminal device 10.

[0073] Figure 13 shows an example of the standby screen IM4 when a push notification is sent. As shown in Figure 13, the standby screen IM4 includes an area A15 where the content of the push notification is displayed. In the example shown in Figure 13, the message "You are scheduled to pay 1000 yen to Service A within 3 days" is displayed in area A15. By checking area A15, the user can easily understand their upcoming payment schedule for recurring billing services.

[0074] Furthermore, the notification unit 145 may send a pre-notification (push notification) to the user terminal device 10 that includes a link to transition to the recurring billing management screen IM2 or the charge screen (not shown) for charging the user's electronic money balance. This improves convenience because the user can transition directly from the pre-notification (push notification) to the recurring billing management screen IM2 or the charge screen (not shown).

[0075] Furthermore, the timing determination unit 150 may use machine learning to analyze at least one of the user's past electronic money charging frequency, charging amount, electronic money balance changes, and past payment failure history, and determine the timing to send a pre-notification (push notification) to the user terminal device 10 according to the results of the machine learning analysis. For example, the timing determination unit 150 may generate a trained model by using machine learning with at least one of the user's past electronic money charging frequency, charging amount, electronic money balance changes, and past payment failure history as explanatory variables, and the timing to send a pre-notification (push notification) to the user terminal device 10 as the objective variable. The timing determination unit 150 may derive at least one of the user's past electronic money charging frequency, charging amount, electronic money balance changes, and past payment failure history by referring to user information 171 (in particular, charging history information, payment history information, electronic money balance, etc.). Furthermore, the timing determination unit 150 may determine the timing obtained by inputting the derived information into the trained model as the timing to send a pre-notification (push notification) to the user terminal device 10. Thus, according to the payment server 100 of this embodiment, instead of a uniform "3-day advance notice," for example, it is possible to dynamically determine the optimal reminder timing for each user, such as "7 days in advance," "10 days in advance," or "when the balance falls below ○ yen" for users with a high risk of insufficient balance.

[0076] [Change payment method settings] The payment method setting unit 155 individually sets the payment method for regular electronic payments and the payment method for recurring billing services in response to instructions from the user (payment app 20). Furthermore, even if the electronic money balance is set as the payment method for regular electronic payments, the payment method setting unit 155 may allow the setting of a different payment method (e.g., credit card payment, bank account balance, etc.) as the payment method for recurring billing services. This allows the payment server 100 in this embodiment to execute a payment using another payment method even if, for example, the user's electronic money balance is insufficient, thereby preventing a payment error.

[0077] The payment method setting unit 155 predicts the probability that the user's electronic money balance will be insufficient to cover the payment amount by the scheduled payment date. Furthermore, if the predicted probability exceeds a pre-set threshold, the payment method setting unit 155 may temporarily change the user's default payment method to another payment method. For example, the payment method setting unit 155 may generate a trained model by machine learning with at least one of the user's past electronic money charge frequency, charge amount, electronic money balance trend, and past payment failure history as explanatory variables, and the probability that the user's electronic money balance will be insufficient to cover the payment amount by the scheduled payment date as the dependent variable. The method for deriving the user's past electronic money charge frequency, charge amount, electronic money balance trend, and past payment failure history is as described above. Furthermore, if the probability obtained by inputting the derived information into the trained model exceeds a pre-set threshold (e.g., 80%), the payment method setting unit 155 may temporarily change the user's default payment method (electronic money balance) to another payment method (credit card payment or bank account balance). This allows the payment server 100 of this embodiment to reduce the risk of payment errors due to insufficient electronic money balance.

[0078] Furthermore, if the predicted probability exceeds a preset threshold, the payment method setting unit 155 may prompt the user to temporarily change their default payment method to another payment method. For example, the payment method setting unit 155 may display a pop-up message on the user terminal device 10 recommending that the user temporarily change their default payment method (electronic money balance) to another payment method (credit card payment or bank account balance). This reduces the risk of payment errors due to insufficient electronic money balance in the payment server 100 of this embodiment.

[0079] [Bulk registration for unregistered recurring billing services] The proposal unit 160 analyzes the payment history information of the user's electronic payment service to identify recurring billing services used by the user that are not managed in the recurring billing management screen IM2. The proposal unit 160 also proposes to the user that they manage the identified recurring billing services in the recurring billing management screen IM2. For example, the proposal unit 160 may identify a recurring payment pattern (for example, a transaction where payments are made to the same merchant on the same day each month but are not registered in the recurring billing information 174) and propose to the user that they manage the recurring billing services corresponding to the identified payment pattern in the recurring billing management screen IM2. If the information management unit 125 obtains the user's consent to the proposal, it may add information about the recurring billing services to the recurring billing information 174. For example, the proposal unit 160 may display a list of recurring billing services not managed in the recurring billing management screen IM2 on the payment application 20. If the user checks a box on the list, the information management unit 125 may add information about the checked recurring billing services to the recurring billing information 174 all at once. As a result, the payment server 100 of this embodiment can automatically register unregistered recurring billing services in bulk without requiring any action from the user.

[0080] Furthermore, once registration for the recurring billing service is complete, the proposal unit 160 may perform ID linking between the electronic payment service and the recurring billing service by calling the electronic payment service's recurring billing API (Application Programming Interface) or by transitioning the screen to the recurring billing service's merchant site. This allows the user's account ID in the electronic payment service to be linked and managed with the ID of the recurring billing service the user is using.

[0081] [Processing based on the campaign] The information acquisition unit 130 acquires campaign information 175, which is information about campaigns being conducted in the electronic payment service, from the storage unit 170. Based on the campaign information 175 (e.g., target period and conditions), the screen generation unit 135 determines that another payment method offers greater economic benefits to the user than the currently set payment method for the recurring billing service, and generates a recurring billing management screen IM2 that includes a message recommending that the user change to another payment method. For example, if, in a particular recurring billing service, another payment method (e.g., credit card payment) offers greater economic benefits (e.g., point redemption rate) to the user than the currently set payment method (e.g., electronic money balance), the screen generation unit 135 may generate a recurring billing management screen IM2 that includes a message such as, "If you change the payment method for this service to credit card payment, you will save XX points this month." This allows the user to easily identify the payment method that offers greater economic benefits.

[0082] [Registering / Updating Recurring Billing Information] In this embodiment, there are two methods for registering and updating the recurring billing information 174: the API linkage method and the file transmission method. These methods will be described below.

[0083] (1) API integration method The API integration method allows a merchant terminal (e.g., a second store terminal device 70) or a merchant server (not shown) to directly execute the recurring billing API provided by the payment server 100 to register or update recurring billing information 174. The API integration method has the advantage of enabling immediate (real-time) reflection on the recurring billing management screen IM2.

[0084] Specifically, in the API integration method, the information acquisition unit 130 of the payment server 100 receives registration / update requests for recurring billing information 174 from the merchant terminal or merchant server via the recurring billing API. The registration / update requests include account ID, merchant ID, service name, payment cycle, scheduled payment date, and scheduled payment amount. The information management unit 125 registers or updates the recurring billing information 174 based on the registration / update requests. This allows the payment server 100 to register or update the recurring billing information 174 based on the registration / update requests received via the API.

[0085] (2) File transmission method The file transmission method involves registering or updating recurring billing information 174 by transmitting a "billing file" in a predetermined format in bulk via file transfer (such as SFTP). For merchants for whom API implementation is difficult, the aforementioned API integration method cannot be applied, and therefore the file transmission method is used. The file transmission method reduces the system development burden on merchants and facilitates collaboration with merchants operating systems that do not have APIs implemented.

[0086] Specifically, in the file transmission method, the information acquisition unit 130 of the payment server 100 receives invoice files transmitted in bulk from the merchant terminal or merchant server via file transfer (SFTP, etc.). The invoice files include account ID, merchant ID, service name, payment cycle, scheduled payment date, and scheduled payment amount. The information management unit 125 registers or updates the recurring billing information 174 in bulk based on the invoice files. This allows the payment server 100 to register or update the recurring billing information 174 based on the invoice files transmitted in bulk via file transfer.

[0087] In the file transmission method, if the payment server 100 fails to withdraw the payment amount included in the billing file, it may send a payment request to the payment app 20 within the billing date of the payment amount and display a message indicating that the withdrawal failed, or it may notify the user via push notification. This allows the user to understand that the payment process has failed and to proactively make the payment. After the payment process is completed, the payment server 100 sends a result file indicating that the payment process was successful to the merchant terminal or merchant server.

[0088] The aforementioned API integration method is a real-time integration method, so the merchant controls the monthly billing timing and sends payment requests to the payment server 100. On the other hand, with the file transmission method, the payment server 100 can receive the billing file in advance, making it possible to display the scheduled payment date and payment amount on the recurring billing management screen IM2 of the payment application 20 in advance. Furthermore, the payment server 100 may accept payment of the payment amount from the user on the recurring billing management screen IM2 without waiting for the scheduled payment date.

[0089] [flowchart] Figure 14 is a flowchart illustrating an example of the processing flow performed by the payment server 100. First, when the user selects (taps) icon IC1 on the top screen IM1 (Figure 9), the payment application 20 sends a screen generation request to the payment server 100. The screen generation request includes the user's account ID. Subsequently, the communication unit 110 of the payment server 100 receives the screen generation request from the payment application 20 (S101).

[0090] Next, the information acquisition unit 130 acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the user (S102). Specifically, the information acquisition unit 130 acquires recurring billing information (merchant ID, service name, payment cycle, scheduled payment date, scheduled payment amount, and payment method) linked to the account ID included in the screen generation request received in S101 by referring to the recurring billing information 174.

[0091] Next, the screen generation unit 135 generates a first recurring billing management screen IM2-1 (Figure 10) which includes the total scheduled payment amount for multiple recurring billing services and a list of individual scheduled payments, based on the recurring billing information acquired in S102 (S103). If an error such as a payment failure occurs, the screen generation unit 135 generates a second recurring billing management screen IM2-2 (Figure 11) which includes information regarding the error, based on the recurring billing information acquired in S102. The screen generation unit 135 may determine whether or not an error such as a payment failure has occurred by referring to the payment history information item in the user information 171.

[0092] Next, the display control unit 140 sends the recurring billing management screen IM2 (first recurring billing management screen IM2-1 or second recurring billing management screen IM2-2) generated in S103 to the payment application 20 (user terminal device 10) for display. In this way, the payment server 100 of this embodiment improves convenience by providing centralized visualization of information regarding multiple recurring billing services used by the user.

[0093] [Effects of this embodiment] According to this embodiment, the following effects (1) to (4) can be achieved. (1) Improved convenience Because payment status and next payment schedules for multiple recurring billing services can be centrally managed within the payment app 20, users no longer need to check individual merchant websites, reducing the stress of managing recurring billing services. (2) Improving the payment success rate By providing advance notifications (push notifications) and guidance before the scheduled payment date to address "insufficient electronic money balance," which is a major cause of payment failure, the success rate of electronic money balance payments can be improved, and the collection of payment amounts can be prevented. (3) Improvement of GMV and revenue Improving the payment success rate directly leads to an increase in the GMV (Gross Merchandise Volume) of electronic payment services. Furthermore, it encourages an expansion of merchants adopting recurring billing services, contributing to overall revenue growth for electronic payment services. (4) Promoting the use of electronic payment services Since users tend to check their transaction history in the payment app 20 when a payment fails, strengthening the link to the recurring billing management screen can increase opportunities for regular visits and contact with the payment app 20, thereby enhancing engagement.

[0094] As described above, the information processing device (payment server 100) of this embodiment is a device that can communicate with a user terminal device 10 operated by a user, and comprises an information acquisition unit 130, a screen generation unit 135, and a display control unit 140. The information acquisition unit 130 acquires recurring billing information 174, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the user. The screen generation unit 135 generates a recurring billing management screen IM2, which includes the total scheduled payment amount and individual scheduled payment lists for multiple recurring billing services, based on the recurring billing information 174. The display control unit 140 transmits the recurring billing management screen IM2 to the user terminal device 10 for display. In this way, the information processing device (payment server 100) of this embodiment can improve convenience by centrally visualizing information regarding multiple recurring billing services used by the user.

[0095] Furthermore, the information processing system of this embodiment includes a payment application 20 installed on a user terminal device 10 operated by the user, and an information processing device (payment server 100) capable of communicating with the payment application 20. The information processing device (payment server 100) includes an information acquisition unit 130, a screen generation unit 135, and a display control unit 140. The information acquisition unit 130 acquires recurring billing information 174, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the user. The screen generation unit 135 generates a recurring billing management screen IM2, which includes the total scheduled payment amount and individual scheduled payment lists for multiple recurring billing services, based on the recurring billing information 174. The display control unit 140 transmits the recurring billing management screen IM2 to the payment application 20 for display. As a result, the information processing system of this embodiment can improve convenience by centrally visualizing information regarding multiple recurring billing services used by the user.

[0096] In this embodiment, the information processing device is defined as a payment server 100, but it is not limited to this. For example, each function of the payment server 100 (such as the information acquisition unit 130, screen generation unit 135, display control unit 140, notification unit 145, timing determination unit 150, payment method setting unit 155, and proposal unit 160) may be installed on a financial institution server 200 or a credit server 300, and the financial institution server 200 or the credit server 300 may be used as the information processing device in this embodiment. Furthermore, the information processing device in this embodiment may be an integrated server that combines multiple servers from among the payment server 100, financial institution server 200, and credit server 300.

[0097] The above explanation uses the example of a bank as the financial institution, but this is not the only example. For example, the financial institution could be a securities company. In this case, the account at the financial institution could be a securities account for an MRF (Money Reserve Fund). This allows the securities account to be used as a payment method for recurring subscription services.

[0098] Although embodiments for carrying out the present invention have been described above using examples, the present invention is not limited in any way to these embodiments, and various modifications and substitutions can be made without departing from the spirit of the present invention. [Explanation of symbols]

[0099] 10. User terminal device 20 Payment Apps 50. First store terminal device 70. Second store terminal device 100 Payment Servers 110 Communications Department 115 Payment Content Provision Department 120 Payment Processing Unit 125 Information Management Department 130 Information Acquisition Department 135 Screen generation section 140 Display Control Unit 145 Notification Department 150 Timing determination unit 155 Payment Method Settings Section 160 Proposal Department 170 Storage section 200 Financial Institution Servers 300 credit server

Claims

1. An information processing device that can communicate with a user terminal device operated by a user, An information acquisition unit that acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user, A screen generation unit generates a management screen that includes the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services based on the aforementioned recurring billing information. A display control unit that transmits the management screen to the user terminal device for display, A notification unit that transmits a prior notification to the user terminal device, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date. A timing determination unit determines the timing for sending the advance notification to the user terminal device based on the results of analyzing at least one of the user's past electronic money charging frequency, charging amount, electronic money balance changes, and past payment failure history. An information processing device equipped with the following features.

2. The screen generation unit generates the management screen which further includes the status of each of the multiple recurring billing services. The information processing apparatus according to claim 1.

3. The aforementioned status indicates one of the following: payment failed, pending, or payment scheduled. The information processing apparatus according to claim 2.

4. The notification unit transmits the prior notification, which includes a link to transition to the management screen or the charge screen for charging the user's electronic money balance, to the user terminal device. The information processing apparatus according to claim 1.

5. The screen generation unit generates the management screen, which includes a message indicating that a deficit has occurred, if the user's electronic money balance is insufficient to cover the total scheduled payment amount. The information processing apparatus according to claim 1.

6. The screen generation unit generates the management screen which includes a path to transition to a charge screen for charging the insufficient amount, or a path to transition to an auto-charge settings screen for setting up auto-charge for electronic money. The information processing apparatus according to claim 5.

7. The screen generation unit generates the management screen which includes the payment method set for each of the multiple recurring billing services and a path to transition to a priority setting screen for setting the priority of the payment method. The information processing apparatus according to claim 1.

8. The system further includes a payment method setting unit that individually sets the payment method for regular electronic payments and the payment method for recurring billing services in response to instructions from the user. The payment method setting unit allows the setting of a payment method different from the electronic money balance as the payment method for the recurring billing service, even when the electronic money balance is set as the payment method for a regular electronic payment. The information processing apparatus according to claim 1.

9. The system further includes a payment method setting unit that predicts the probability that the user's electronic money balance will be insufficient to cover the scheduled payment amount by the scheduled payment date, and if the probability exceeds a predetermined threshold, temporarily changes the user's default payment method to another payment method. The information processing apparatus according to claim 1.

10. The system further includes a payment method setting unit that predicts the probability that the user's electronic money balance will be insufficient to cover the scheduled payment amount by the scheduled payment date, and prompts the user to temporarily change their default payment method to another payment method if the probability exceeds a predetermined threshold. The information processing apparatus according to claim 1.

11. The system further includes a proposal unit that analyzes the payment history information of the user's electronic payment service to identify recurring billing services used by the user that are not managed on the management screen, and proposes to the user that they manage the identified recurring billing services on the management screen. The information processing apparatus according to claim 1.

12. The aforementioned information acquisition unit acquires campaign information, which is information regarding campaigns being conducted in the electronic payment service. The screen generation unit, based on the campaign information, determines that another payment method would be more economically beneficial to the user than the currently set payment method for the recurring billing service, and generates the management screen which includes a message recommending that the user switch to the other payment method. The information processing apparatus according to claim 1.

13. An information processing device capable of communicating with a user terminal device operated by a user, An information acquisition unit that acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user, A screen generation unit generates a management screen that includes the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services based on the aforementioned recurring billing information. A display control unit that transmits the management screen to the user terminal device for display, A notification unit that transmits a prior notification to the user terminal device, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date. A timing determination unit analyzes at least one of the user's past electronic money charging frequency, charging amount, electronic money balance trends, and past payment failure history using machine learning, and determines the timing for sending the advance notification to the user terminal device according to the results of the machine learning analysis. An information processing device equipped with the following features.

14. An application program installed on a user terminal device operated by the user, An information processing device capable of communicating with the aforementioned application program, An information processing system comprising, The aforementioned information processing device is An information acquisition unit that acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user, A screen generation unit generates a management screen that includes the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services based on the aforementioned recurring billing information. A display control unit that transmits the aforementioned management screen to the application program for display, A notification unit that transmits a prior notification to the user terminal device, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date. A timing determination unit determines the timing for sending the advance notification to the user terminal device based on the results of analyzing at least one of the user's past electronic money charging frequency, charging amount, electronic money balance changes, and past payment failure history. An information processing system equipped with the following features.

15. An application program installed on a user terminal device operated by a user, An information processing device capable of communicating with the aforementioned application program, An information processing system comprising, The aforementioned information processing device is An information acquisition unit that acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user, A screen generation unit generates a management screen that includes the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services based on the aforementioned recurring billing information. A display control unit that transmits the aforementioned management screen to the application program for display, A notification unit that transmits a prior notification to the user terminal device, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date. A timing determination unit analyzes at least one of the user's past electronic money charging frequency, charging amount, electronic money balance trends, and past payment failure history using machine learning, and determines the timing for sending the advance notification to the user terminal device according to the results of the machine learning analysis. An information processing system equipped with the following features.

16. A user terminal device operated by a user and an information processing device capable of communicating with each other, The system acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user. Based on the aforementioned recurring billing information, an administration screen is generated that includes the total scheduled payment amount for the multiple recurring billing services and a list of individual scheduled payments. The aforementioned management screen is transmitted to the user terminal device for display. Prior to the scheduled payment date, the user terminal device is instructed to send a prior notification including the scheduled payment amount and the name of the recurring billing service. Based on the results of analyzing at least one of the user's past electronic money charging frequency, charging amount, electronic money balance trends, and past payment failure history, the timing of sending the prior notification to the user terminal device is determined. Information processing methods.

17. An information processing device capable of communicating with a user terminal device operated by a user, The system acquires recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user. Based on the aforementioned recurring billing information, an administration screen is generated that includes the total scheduled payment amount for the multiple recurring billing services and a list of individual scheduled payments. The aforementioned management screen is transmitted to the user terminal device for display. Prior to the scheduled payment date, a prior notification including the scheduled payment amount and the name of the recurring billing service is sent to the user terminal device. The system uses machine learning to analyze at least one of the user's past electronic money charging frequency, charging amount, electronic money balance trends, and past payment failure history, and determines the timing for sending the advance notification to the user terminal device based on the results of the machine learning analysis. Information processing methods.

18. A user terminal device operated by a user and an information processing device that can communicate with each other, A process for obtaining recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user, A process to generate an administration screen that includes the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services based on the aforementioned recurring billing information, The process of sending the aforementioned management screen to the user terminal device for display, A process to send a prior notification to the user terminal device, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date, A process to determine the timing for sending the advance notice to the user terminal device based on the results of analyzing at least one of the user's past electronic money charging frequency, charging amount, electronic money balance changes, and past payment failure history. A program that executes the command.

19. An information processing device that can communicate with a user terminal device operated by a user, A process for obtaining recurring billing information, including the scheduled payment date and scheduled payment amount, for multiple recurring billing services used by the aforementioned user, A process to generate an administration screen that includes the total scheduled payment amount and individual scheduled payment lists for the multiple recurring billing services based on the aforementioned recurring billing information, The process of sending the aforementioned management screen to the user terminal device for display, A process to send a prior notification to the user terminal device, including the scheduled payment amount and the name of the recurring billing service, at a time prior to the scheduled payment date, The process involves using machine learning to analyze at least one of the user's past electronic money charging frequency, charging amount, electronic money balance trends, and past payment failure history, and determining the timing for sending the advance notification to the user terminal device according to the results of the machine learning analysis. A program that executes the command.

Images