JP7399334B1 - Information processing device, information processing method, and information processing program - Google Patents

Abstract

[Problem] To improve the convenience of services related to digital salary payments. An information processing device according to the present application is an information processing device that executes processing related to an electronic payment service provided to users through an online system, and has a prepayment unit. When the prepayment department receives a notice of payment schedule information from a partner bank indicating the schedule for payment to a predetermined bank account linked to the user in advance, the prepayment department shall, in response to the user's request, Before the money arrives at the bank account of the user, the electronic payment service executes processing related to the prepayment service that adds a predetermined amount of electronic money to the electronic wallet held by the user. [Selection diagram] Figure 16

Description

The present invention relates to an information processing device, an information processing method, and an information processing program.

Recently, the government has begun considering the introduction of so-called ``digital payment of salaries,'' which would allow fund transfer companies operating funds transfer businesses to pay salaries using digital money such as electronic money or virtual currency. In this regard, technologies related to digital payment of salaries have also been proposed.

Japanese Patent Application Publication No. 2022-151873

However, with the above-mentioned conventional technology, there is room for improvement in improving the convenience of services related to digital salary payment. For example, currently there is not much demand for people to receive their entire salary in electronic money. For this reason, for example, if a company that pays salaries allows employees to transfer their salary to multiple accounts designated by the employee at the request of the employee, the employee may It will also be possible to receive part of your salary in electronic money and the rest in cash through your traditional bank account.

However, if employees designate multiple accounts to have their salaries transferred to, the burden of transfer fees and other charges increases, so it is unlikely that this system will be actively adopted by companies. For this reason, it is unlikely that an employee can receive a portion of his salary in electronic money by specifying multiple accounts to which his salary will be transferred. On the other hand, the amount of salary that an employee wishes to receive in electronic money may vary depending on the employee's circumstances, the amount of salary paid, etc. For this reason, if the amount received in electronic money is fixed, it is difficult to hope for improvements in the usability of services related to digital salary payments. Furthermore, there is still room for expansion in the method of receiving salaries in electronic money.

The present application has been made in view of the above, and aims to provide an information processing device, an information processing method, and an information processing program that improve the convenience of services related to digital salary payment.

The information processing device according to the present application is an information processing device that executes processing related to electronic payment services provided to users through an online system, and has a prepayment section. When the prepayment department receives a notice of payment schedule information from a partner bank indicating the schedule for payment to a predetermined bank account linked to the user in advance, the prepayment department shall, in response to the user's request, Before the money arrives at the bank account of the user, the electronic payment service executes processing related to the prepayment service that adds a predetermined amount of electronic money to the electronic wallet held by the user in advance.

According to one aspect of the embodiment, it is possible to improve the convenience of services related to digital salary payment.

FIG. 1 is a diagram showing an overview of information processing according to an embodiment. FIG. 2 is a diagram showing an example of a screen display when setting distribution according to the embodiment. FIG. 3 is a diagram showing an example (part 1) of providing information in the distribution service according to the embodiment. FIG. 4 is a diagram showing an example (part 2) of providing information in the distribution service according to the embodiment. FIG. 5 is a diagram illustrating an example of the use of financial services through the distribution service according to the embodiment. FIG. 6 is a diagram illustrating an example of information management in the distribution service according to the embodiment. FIG. 7 is a diagram illustrating a configuration example of a payment server according to an embodiment. FIG. 8 is a diagram illustrating an example of information stored in the account information storage unit according to the embodiment. FIG. 9 is a diagram illustrating an example of information regarding distribution settings stored in the distribution settings storage unit according to the embodiment. FIG. 10 is a diagram illustrating an example of the distribution history stored in the distribution history storage unit according to the embodiment. FIG. 11 is a diagram illustrating an example of user information stored in the user information storage unit according to the embodiment. FIG. 12 is a flowchart illustrating an example of a processing procedure of a payment schedule provision process executed by the payment server according to the embodiment. FIG. 13 is a flowchart illustrating an example of the processing procedure of the distribution process executed by the payment server according to the embodiment. FIG. 14 is a diagram showing an overview of information processing regarding a prepaid service according to a modification. FIG. 15 is a diagram illustrating an overview of information provision accompanying implementation of a prepayment scheme according to a modification. FIG. 16 is a diagram illustrating a configuration example of a payment server according to a modification. FIG. 17 is a diagram illustrating an example of user information stored in a user information storage unit according to a modification. FIG. 18 is a diagram illustrating an example of information regarding the usage history of prepaid services stored in the prepaid history storage unit according to the modification. FIG. 19 is a flowchart illustrating an example of a processing procedure of a prepayment process executed by a payment server according to a modification. FIG. 20 is a flowchart illustrating an example of a processing procedure of prepayment processing for a registered user, which is executed by a payment server according to a modification. FIG. 21 is a flowchart illustrating an example of a processing procedure of a collection process executed by a payment server according to a modification. FIG. 22 is a hardware configuration diagram showing an example of a computer that implements the functions of the payment server according to the embodiment.

DESCRIPTION OF THE PREFERRED EMBODIMENTS An information processing apparatus, an information processing method, and an information processing program according to the present application (hereinafter referred to as "embodiments") will be described in detail below with reference to the drawings. Note that the information processing apparatus, information processing method, and information processing program according to the present application are not limited to this embodiment. Further, in each of the embodiments below, the same parts are given the same reference numerals, and redundant explanations will be omitted.

[1. Embodiment]
Information processing realized by the information processing apparatus and the like according to the embodiment will be described using FIG. 1. FIG. 1 is a diagram showing an overview of information processing according to an embodiment. Note that in FIG. 1, it is assumed that information processing and the like according to the embodiment are realized by a payment server 100, which is an example of an information processing apparatus according to the embodiment.

(1-1. System configuration)
As shown in FIG. 1, the information processing system SYS according to the embodiment includes a user terminal 10, a bank server 20, a partner bank server 30, and a payment server 100. The user terminal 10, the bank server 20, the partner bank server 30, and the payment server 100 are connected to be able to communicate with each other by wire or wirelessly via a network N (for example, see FIG. 7). The network N is, for example, a WAN (Wide Area Network) such as the Internet. For convenience of explanation, FIG. 1 illustrates a case where the information processing system SYS includes a single user terminal 10, bank server 20, partner bank server 30, and payment server 100, but the information processing system The SYS may include a plurality of user terminals 10, bank servers 20, partner bank servers 30, and payment servers 100.

A payment server 100 shown in FIG. 1 is an information processing device that executes information processing according to the embodiment, and is realized by a server device, a cloud system, or the like. For example, the payment server 100 provides an electronic payment service related to electronic payment using the user terminal 10 (a service that provides a predetermined transaction means for controlling the exchange of electronic money by code payment) to a service user (for example, in FIG. It is operated and managed by business operator UA, which provides services to service users UB).

Further, the payment server 100 executes various information processing related to electronic payments using the user terminal 10. Specifically, the payment server 100 distributes an application program for a user terminal (hereinafter appropriately referred to as a "payment application") for realizing code payment to general consumers who are service users. When the payment server 100 receives a transaction request from a payment application via an interface dedicated to the payment application, the payment server 100 executes information processing including electronic money transfer processing between accounts in accordance with the transaction request. The payment application transmits transaction information including information such as a payment destination, a payment source, and a payment amount to the payment server 100. In addition to the above information, transaction information includes information such as transaction codes to identify individual transactions and date and time information (time stamps) to identify the date and time of transactions. It's okay.

Further, the payment server 100 provides a transfer payment service using electronic money as one of the cooperative services linked to the above-mentioned electronic payment service. For example, the payment server 100 provides a service that accepts payments such as salary transfers using electronic money. The specific details of the information processing related to the money transfer service will be described in detail later. Note that the service that accepts salary transfers, etc. may be configured as a mini-app that is launched within the payment app to realize code payments, or may be a unique application program prepared independently of the payment app. It may be.

The payment server 100 also provides a distribution service that distributes funds transferred to a virtual account linked to a service user according to instructions from the service user, as one of the linked services linked to the electronic payment service described above. provide. The details of the specific information processing regarding the distribution service will be described in detail later. Note that the distribution service may be configured as a mini-app that is launched within a payment application for realizing code payment, or may be a unique application program prepared independently of this payment application. .

The user terminal 10 shown in FIG. 1 is an information processing device used by a service user UB, who is a general consumer who receives transactions from a store or the like, and who uses services provided by the payment server 100. The user terminal 10 is realized by, for example, a smartphone, a tablet terminal, a notebook PC (Personal Computer), a desktop PC, a mobile phone, a PDA (Personal Digital Assistant), or the like. Further, the user terminal 10 displays information distributed by the payment server 100 using a web browser or an application. Note that in FIG. 1, a smartphone is illustrated as the user terminal 10.

Note that when the user terminal 10 receives control information for implementing predetermined information processing from the payment server 100, it implements the information processing in accordance with the control information. Here, the control information may be a script language such as JavaScript (registered trademark), a style sheet language such as CSS (Cascading Style Sheets), a programming language such as Java (registered trademark), or a markup such as HTML (HyperText Markup Language). Described by language etc. Note that the predetermined application itself distributed from the payment server 100 may be regarded as the control information.

The bank server 20 shown in FIG. 1 is, for example, an information processing device belonging to Bank X that manages bank accounts opened by applicants such as companies that employ the service user UB, and is realized by a server device, a cloud system, etc. be done. For example, the bank server 20 stores, as the usage history of the bank account, information regarding withdrawals from the bank account by each card company and various service providers (such as the amount withdrawn and the date and time of the withdrawal), the current account balance, etc. Manage account information, etc., by associating it with the account holder. Furthermore, the bank server 20 executes processing such as remittances and transfers according to instructions from each user.

The partner bank server 30 shown in FIG. 1 is an information processing device operated and managed by Bank Y, which has an account with the business operator UA, and is realized by a server device, a cloud system, or the like. The affiliated bank server 30 manages the usage history of bank accounts for each user, including the business UA, and performs processing such as remittances and transfers according to instructions from each user.

(1-2. Regarding payment using user terminal 10)
Here, an example of code payment (electronic payment) using the user terminal 10 will be described. In the following explanation, for example, a two-dimensional code (QR code (registered trademark)) placed at store X, which indicates store identification information for identifying store An example will be described in which a service user UB who receives the service performs payment using the user terminal 10. Note that an example of code payment described below can be applied to a case where any user makes a payment at any store using any user terminal 10. Further, the two-dimensional code indicating store identification information may be not only a QR code but also a bar code, a predetermined mark, a number, etc. Further, the two-dimensional code is not limited to the example of being physically configured by printed matter printed on a medium such as paper, but may be configured by image information displayed on an arbitrary terminal.

For example, when service user UB makes a payment for the purchase or use of transaction objects such as various products and services at store . Then, the service user UB photographs the two-dimensional code installed at the store X via the payment application. In such a case, the user terminal 10 displays a screen for inputting the price of the transaction object, and accepts input of the payment amount from the service user UB or the clerk of the store X. Then, the user terminal 10 includes user identification information that identifies the service user UB, store identification information (or information indicated by the store identification information, that is, information indicating store X (for example, store ID)), Transaction information including the payment amount is transmitted to the payment server 100.

When the payment server 100 receives transaction information from the user terminal 10, the payment server 100 transfers electronic money equivalent to the payment amount from the account of the service user UB indicated by the user identification information to the account of the store X indicated by the store identification information. Transfer money. At this time, the payment server 100 may deduct a predetermined fee to be charged to the store X from the electronic money equivalent to the payment amount, and then transfer the electronic money to the store X's account. The payment server 100 then sends a notification to the user terminal 10 that the transaction has been completed. In such a case, the user terminal 10 notifies the service user UB that the transaction using electronic money has been completed by outputting a screen or a predetermined sound indicating that the transaction has been completed. Alternatively, the payment server 100 withdraws electronic money equivalent to the payment amount from the account of the service user UB indicated by the user identification information, manages it as sales information of store may be transferred to the bank account held by store X. In this case, the payment server 100 may notify the service user UB that the transaction using electronic money is completed at the timing when the electronic money corresponding to the payment amount is withdrawn from the service user UB's account.

Note that payment using the user terminal 10 is not limited to the processing described above. For example, the payment using the user terminal 10 may be made using a terminal device installed at the store X (hereinafter referred to as a "store terminal"). Specifically, first, the user terminal 10 displays on the screen code information indicating user identification information for identifying the service user UB. In such a case, the store terminal reads the user identification information from the code information displayed on the user terminal 10, and stores the read user identification information (or the information indicated by the user identification information, that is, the service user UB transaction information including information indicating (for example, user ID), the payment amount, and information identifying store X is transmitted to payment server 100.

Upon receiving the transaction information from the store terminal, the payment server 100 transfers electronic money equivalent to the payment amount from the account of the service user UB indicated by the user identification information to the account of the store X. The payment server 100 then sends a notification to the store terminal or user terminal 10 that the transaction has been completed. The store terminal or user terminal 10 notifies the service user UB that the transaction using electronic money has been completed by outputting a screen or a predetermined sound indicating that the transaction has been completed. In addition, the payment server 100 withdraws electronic money equivalent to the payment amount from the account of the service user UB indicated by the user identification information, manages it as sales information of store may be transferred to the bank account held by store X. In this case, the payment server 100 may notify the clerk or the service user UB that the electronic money transaction has been completed at the timing when the electronic money corresponding to the payment amount is withdrawn from the service user UB's account. good.

In addition, payment using the user terminal 10 is not limited to the process of transferring electronic money from an account to which service user UB has previously charged electronic money to an account at store Payment may be made using a credit card. In such a case, for example, the user terminal 10 transfers the amount of electronic money indicated by the payment amount to the account of store You may request an amount.

In addition, the payment using the user terminal 10 is not limited to the process of transferring electronic money from the account of service user UB to the account of store X, but also, for example, from the account of service user UB to the account of another user. It may also be a payment that transfers electronic money (that is, remittance between users). For example, the user terminal 10 used by the service user UB who is the remittance source uses user identification information that identifies the remittance destination user (for example, user identification information displayed on the terminal device used by the remittance destination user). ), receives the input of the remittance amount from the service user UB, and transmits information indicating the read identification information, the remittance amount, and user identification information identifying the service user UB to the payment server 100. In such a case, the payment server 100 transfers the amount of electronic money indicated by the remittance amount from the account of the service user UB to the account of the remittance user, and the electronic money is transferred to the user terminal 10 or the remittee user's account. The notification that the remittance has been made may be notified by causing the terminal device to output a screen or a predetermined voice indicating that the remittance has been completed.

Note that remittance using the user terminal 10 is not limited to the above-described processing. For example, remittance using the user terminal 10 may be performed by inputting the telephone number of the user to whom the remittance is to be made or information indicating the user to whom the remittance is to be made (e.g., user ID) into the user terminal 10. . To give a specific example, the user terminal 10 receives input from the service user UB of the telephone number or user ID of the remittance user and the remittance amount, and inputs the input telephone number or user ID. , transmits the remittance amount and user identification information for identifying the service user UB to the payment server 100. Then, the payment server 100 transfers the amount of electronic money indicated by the remittance amount from the account of the service user UB to the account of the user linked to the transmitted telephone number or user ID.

Here, the telephone number and user ID of the user who is the remittance destination may be registered in advance in the payment application in association with information regarding the user. In this case, the user terminal 10 receives from the service user UB the designation of the user (remittance destination) registered in the payment application and the input of the remittance amount to the user, and the The telephone number or user ID, the remittance amount, and user identification information for identifying the service user UB are transmitted to the payment server 100.

Further, for example, remittance using the user terminal 10 may be performed by providing link information for receiving the remittance amount to the user of the remittance destination. To give a specific example, the user terminal 10 receives an input of the remittance amount from the service user UB, generates link information for receiving the remittance amount, sends an e-mail containing the link information, or sends an e-mail containing the link information. By posting posted information including the information on SNS (Social Networking Service), link information is provided to the terminal device used by the user of the remittance destination. Then, when the remittance destination user selects the link information and performs a receiving operation, the payment server 100 transfers electronic money in the amount indicated by the remittance amount from the service user UB's account to the remittance destination user's account. to migrate.

Note that the payment means and payment services described above are not limited to those for providing consideration for purchasing products or providing services (settlement of debts). For example, as described above, the payment means or payment service may have a function related to remittance between accounts owned by multiple users. That is, the above-mentioned payment means and payment service may be any service that controls the transmission and reception of electronic money between the accounts of arbitrary owners linked to the owner of electronic money, such as users and stores. In other words, the payment means and payment services according to the embodiments include various controls for realizing electronic money exchange (not only various inter-account remittance controls via electronic money, but also control regarding exchanges between electronic money accounts and bank accounts). Transaction methods and transaction services that carry out various types of debt processing such as control, processing related to splits and bonus payments, and various other controls related to the exchange of assets, including electronic money, may be provided in any format. Good too. Further, the various controls realized by such transaction means and transaction services may include both payment-related control and remittance-related control, or only one of them may be included. That is, the term "transaction" is a concept that includes not only "settlement" related to electronic money, but also "remittance" of electronic money and various other types of processing. That is, the payment server 100 may be an information processing device that implements a transaction means that controls the exchange of electronic money between arbitrary owners.

(1-3. About bank transfer service)
The transfer payment service that the payment server 100 provides to the service user UB will be described below. When the payment server 100 receives a request for registering to use the money transfer service from the service user UB through a payment application, it allocates a virtual account to the service user UB and registers user information. For example, the payment server 100 arbitrarily selects an unused virtual account from among a plurality of virtual accounts borrowed in advance from a partner bank. Further, the payment server 100 completes virtual account assignment by associating and registering account information (account number) for specifying the selected virtual account and identification information unique to the service user UB. Note that the payment server 100 can use, for example, a user ID that the payment server 100 individually assigns to each user when registering to use the electronic payment service, as identification information unique to the service user UB.

In addition, in the registration of user information, the payment server 100 determines that the amount of money deposited into the virtual account that exceeds a predetermined amount will Information on a refund bank account for refunding cash to the service user UB is obtained from the service user UB. The payment server 100 completes the initial registration of user information by registering the refund bank account information acquired from the service user UB in association with the above-mentioned unique information.

When the assignment of the virtual account and the registration of the user information are completed, the payment server 100 sends the account information (account number) for identifying the virtual account for the transfer payment service to the user terminal 10. 10, the account information is provided to the service user UB. The service user UB notifies the account information provided by the payment server 100 to the transfer request destination, such as the company where the user works, as the transfer destination for salary, miscellaneous expenses, etc. The recipient of the transfer request, such as a company, which has received account information from the service user UB, uses this account information as the transfer destination (remittance destination) from the bank account it owns, and makes a predetermined transfer, such as salary or miscellaneous expenses, for example. conduct. When the payment server 100 detects the arrival of money into the virtual account, it charges the electronic wallet (electronic money account) of the service user UB to which the virtual account is allocated with electronic money equivalent to the amount deposited into the virtual account. . In this way, the service user UB can receive the receivables he/she owns in electronic money by informing the transfer requestee of the account information.

(1-4. Information processing according to embodiment)
(1-4-1. Information processing regarding distribution service)
Information processing related to the distribution service according to the embodiment will be described below using FIG. 1. In the following explanation, information processing will be explained when the object to be distributed by the distribution service is the salary of the service user UB. Note that the information processing according to the embodiment is not limited to the case where salary is to be allocated, but can be applied to various types of funds transferred to a predetermined account linked in advance to the service user UB.

Furthermore, in the following description, the service user UB and the user terminal 10 may be equated. That is, in the following description, service user UB can also be read as user terminal 10.

As shown in FIG. 1, the service user UB executes salary distribution settings, for example, through a payment application (step S01). An example of a screen displayed on the user terminal 10 when setting salary allocation will be described with reference to FIG. 2. FIG. 2 is a diagram showing an example of a screen display when setting distribution according to the embodiment. The payment server 100 includes an electronic wallet owned by the service user UB in the electronic payment service as a destination for allocating the salary deposited to a predetermined bank account linked to the service user UB in advance through the payment application. A distribution setting specifying multiple distribution destinations is received from the service user UB.

As explained below, prior to setting up salary distribution, a procedure for issuing a receiving account for receiving at least a portion of salary in electronic money is performed. For example, as shown in FIG. 2, the top screen G1-1 of the payment application is displayed on the user terminal 10 in response to the operation of the service user UB (display example EX1-1). In addition, on the user terminal 10, an explanation screen (tutorial screen) G1-2 for using the salary distribution settings is displayed in response to the operation of the service user UB on the top screen G1-1 (table Example EX1-2). The distribution setting explanation screen G1-2 shown in FIG. 2 is provided with a button B-1 for starting the salary distribution setting.

In addition, in response to the service user UB's operation on the button B-1 provided on the explanation screen G1-2, the user terminal 10 displays the amount of salary received in electronic money and the current salary received. A setting screen G1-3 for setting information regarding the bank account is displayed (display example EX1-3). The setting screen G1-3 shown in FIG. 2 is provided with a button B1-2 for receiving a request from the service user UB to issue a receiving account for receiving salary in both electronic money and cash. This receiving account is a virtual account, and is issued using the same procedure as the above-mentioned money transfer service. For example, the payment server 100 arbitrarily selects an unused virtual account number from among a plurality of virtual account numbers borrowed in advance from Bank Y, which is a partner bank, and uses the selected virtual account number as the receiving account number. , is assigned to the service user UB. The virtual account is linked to the real account held by business UA at Bank Y.

Additionally, in response to the service user UB's operation on the button B1-2 provided on the setting screen G1-3, the payment server 100 determines whether or not user authentication of the service user UB is required. be done. If it is determined that user authentication is necessary, user authentication is performed between payment server 100 and service user UB. If the user authentication is successful, the payment server 100 executes a receiving account issuing process, and a receiving account number notification screen G1-4 is displayed on the user terminal 10 (display example EX1-4). On the other hand, if it is determined that user authentication is not required, the payment server 100 executes a receiving account issuing process on the condition that the service user UB agrees to the terms of service, and the user terminal 10 stores the receiving account number. A notification screen G1-4 is displayed. Information on the receiving account number is displayed on the notification screen G1-4 shown in FIG. The payment server 100 registers information on the receiving account number in the account information storage unit 121 in association with the user ID of the service user UB.

In addition, when the receiving account issuance procedure is completed, as shown in FIG. G2 (an example of a "predetermined user interface") is displayed (display example EX2). The distribution setting screen G2 shown in FIG. 2 includes a screen switching tab display area A1-1, a received amount setting area A1-2, and a distribution setting area A1-3.

The screen switching tab display area A1-1 includes a tab for displaying a settings screen G3 (for example, see Figure 5) for accepting settings regarding the operation of salaries received as electronic money, and a tab for accepting settings regarding salary distribution. It includes a tab for displaying the distribution setting screen G2 and a tab for displaying a management screen (for example, see FIG. 6) for managing user information of the service user UB. For example, the user terminal 10 displays a screen corresponding to the tab operated by the service user UB. FIG. 2 shows an example in which the tab corresponding to the distribution setting screen G2 is enabled.

Further, the received amount setting area A1-2 includes a slide bar that accepts an intuitive operation from the service user UB to set the received amount indicating the amount to be received in electronic money from the salary. The slide bar is configured to be movable according to the operation of the service user UB on a line connecting the lowest amount (for example, 0 yen) and the highest amount (for example, 1 million yen) that can be set as the amount to be received. In FIG. 2, an example is shown in which the slide bar specifies 50,000 yen as the amount to be received. Note that the payment server 100 may, for example, set the amount that can be received as electronic money at that time as the maximum amount. For example, the amount that can be received at that time is the amount obtained by subtracting the amount of electronic money held at that time from the upper limit of 1 million yen that can be held as electronic money. Further, the amount that can be received at that time may be indicated numerically as a guideline, or the amount may be displayed by changing the line or the color on the line. When the payment server 100 receives the pre-setting of the amount to be received from the service user UB, the payment server 100 transfers the information indicating the amount to be received pre-set by the service user UB in association with the user ID of the service user UB. It is registered and managed in the distribution setting storage unit 122 as information regarding the minutes.

In addition, in the received amount setting area A1-2 shown in FIG. 2, an example is shown in which the setting of the received amount to be received as electronic money out of the salary is accepted, but instead of the received amount, for example, 10% or 15% of the salary can be set. %, which indicates the ratio of the amount received to the salary, may be accepted. In this case, a slide bar included in the receiving amount setting area A1-2 may be configured to allow setting of the receiving ratio. Further, the payment server 100 calculates the amount to be received based on the reception ratio set for the service user UB and the amount deposited into the receiving account as a salary (the amount included in the payment notification).

In addition, the allocation setting area A1-3 includes at least one allocation account to which the salary will be allocated, the amount to be transferred to the allocation account, the purpose of use of the allocation account, or the purpose of allocating the salary. The distribution settings including the nominal settings indicating the distribution purpose are accepted. In FIG. 2, an example is shown in which the account number of M-1 Bank's ordinary account, the remittance amount of 220,000 yen, and nominal living expenses are displayed as one of the recipients. Further, in FIG. 2, an example is shown in which the account number of the M-2 Bank ordinary account, the remittance amount of 30,000 yen, and the nominal home loan are displayed as one of the destinations. The distribution setting area A1-3 accepts new settings or changes to the distribution destination in response to operations from the service user UB. When the payment server 100 receives the pre-settings for the destination account, remittance amount, and nominal name from the service user UB, the payment server 100 stores the pre-set transfers by the service user UB in association with the user ID of the service user UB. Information indicating the destination account, remittance amount, and nominal name is registered in the distribution setting storage unit 122 as information related to distribution settings that specify the destination of funds. The payment server 100 can accept nominal setting for each destination account. Note that the distribution setting area A1-3 may accept settings for a remittance ratio, which indicates the ratio of the remittance amount to the salary, from the service user instead of the remittance amount. In this case, the payment server 100 calculates the remittance amount based on the remittance ratio set for the service user UB and the deposit amount deposited into the receiving account as salary (deposit amount included in the payment notification). .

Note that the payment server 100 may receive a setting for remittance of the money balance to another service user of the electronic payment service from the service user UB as a salary allocation destination. In this case, the payment server 100 stores the distribution settings corresponding to the service user UB by associating the user ID for identifying another service user who is the remittance destination with the remittance amount. 122. Then, the payment server 100 adds the money balance equivalent to the remittance amount to other service users to the money balance of the e-wallet held by the service user UB, and then transfers the money from the e-wallet of the service user UB to the other service user UB. Transfer funds to an electronic wallet owned by the service user.

Returning to FIG. 1, for example, a company that employs service user UB makes a transfer reservation to the bank server 20 of Bank X for the receiving account number notified by service user UB. When the transfer execution date in the transfer reservation is reached, the bank server 20 remits the amount specified in the transfer reservation (for example, 300,000 yen) from the remittance source bank account linked to the company to the recipient account number (step S02).

When the partner bank server 30 detects the receipt of money from Bank X, it sends a notice of receipt of the money to the payment server 100, which is the lending destination of the virtual account specified by the receiving account number where the money was received ( Step S03). For example, the payment notification includes information indicating the receiving account number and the amount paid.

Upon receiving the payment notification from the affiliated bank server 30, the payment server 100 identifies the distribution settings of the service user UB to be processed based on the payment notification (step S04). For example, the payment server 100 identifies the user ID associated with the receiving account number included in the payment notification from among the information stored in the account information storage unit 121. Further, the payment server 100 identifies the distribution setting associated with the identified user ID from among the information stored in the distribution setting storage unit 122.

Further, the payment server 100 transmits a remittance instruction to the partner bank server 30 according to the specified allocation settings (step S05-1). For example, the payment server 100 stores the remittance source account number, which is the account number of the real account linked to the receiving account, the remittance account number, which is the distribution destination account included in the distribution settings, and the remittance account number, which is the distribution destination account included in the distribution settings. Send remittance instructions including the amount. Note that the remittance source account is not necessarily limited to a bank account, and may be an account that allows remittance of electronic money.

Further, the payment server 100 adds the money balance of the electronic wallet held by the service user UB according to the specified allocation setting (step S05-2). For example, the payment server 100 adds (charges) an amount of electronic money corresponding to the received amount included in the distribution settings to the electronic wallet linked to the service user UB.

In addition, the payment server 100 adds the amount of electronic money equivalent to the received amount to the electronic wallet owned by the service user UB, and the balance after the addition can be secured in the electronic wallet by the service user UB. An amount of electronic money equivalent to the received amount may be added to the electronic wallet, provided that the amount does not exceed a predetermined amount that is predetermined as the upper limit amount. For example, the payment server 100 obtains the money balance of the electronic wallet held by the service user UB from the user information storage unit 124. In addition, the payment server 100 calculates the balance after adding electronic money equivalent to the received amount to the electronic wallet owned by the service user UB (also referred to as balance addition or charging). A comparison is made with a predetermined amount. Then, if the balance after addition is less than or equal to a predetermined amount, the payment server 100 adds an amount of electronic money equivalent to the received amount to the electronic wallet held by the service user UB. On the other hand, if the balance after addition exceeds a predetermined amount, the payment server 100 provides the service user UB with information to the effect that the electronic wallet cannot be charged because the balance exceeds the balance.

Furthermore, the payment server 100 adds electronic money equivalent to an amount not exceeding the predetermined amount to the e-wallet based on the amount equivalent to the received amount, the predetermined amount, and the money balance of the service user UB at that time. The remaining amount may be paid out from the service user UB to a preset bank account. Additionally, the payment server 100 temporarily adds electronic money equivalent to the received amount to the electronic wallet, and if the money balance after addition exceeds a predetermined amount, the payment server 100 adds the amount of electronic money equivalent to the received amount to the electronic wallet. The amount may be paid out from the service user UB to a preset bank account.

Furthermore, the payment server 100 may perform either remittance to a bank account or charge to an electronic wallet first. For example, if the service user UB has set up only a bank account for receiving the received amount and salary, the payment server 100 adds electronic money equivalent to the received amount to the electronic wallet held by the service user UB. Charge (balance addition) to the e-wallet first, provided that the balance after addition does not exceed a predetermined amount, and the remaining amount after subtracting the received amount from the salary is transferred to the real account linked to the receiving account. You can also send money to the bank account used to receive your salary. In addition, the payment server 100 executes the remittance of the remittance amount set in the allocation settings to the bank account set as the allocation destination account in the allocation settings, and then subtracts the remittance amount from the salary. An amount of electronic money corresponding to the remaining balance may be added to the electronic wallet held by the service user UB.

The payment server 100 also provides the service user UB with proposal information regarding the setting of the next payment amount by transmitting it to the user terminal 10 based on the usage history of the electronic payment service by the service user UB. Good too. For example, the usage amount is calculated on a monthly basis, and the average usage amount for a certain period based on the calculated usage amount or the usage amount for the next month estimated from the calculated usage amount is proposed as the amount to be received in electronic money. Note that the timing at which the payment server 100 provides the service user UB with the proposal information regarding the setting of the next amount to be received may be any timing at which the next amount to be received can be changed.

In addition, the payment server 100 calculates, for example, a monthly decrease in the balance of the bank account that is the distribution destination account set by the service user UB, and transfers the amount equivalent to the calculated decrease amount. Proposal information proposing the remittance amount to be remitted to the destination account may be provided to the service user UB by transmitting it to the user terminal 10. In this case, the payment server 100 uses an API for accessing the partner bank server 30 provided by the partner bank Y to access the bank account that is the transfer account set by the service user UB as the transfer destination. You can obtain information on the balance of. Note that the timing at which the payment server 100 provides the service user UB with the proposal information regarding the proposal for the remittance amount may be any timing at which the next remittance amount can be changed.

Further, the payment server 100 may receive in advance the setting of the scheduled date for depositing (receiving) money into the receiving account from the service user UB. In this case, the payment server 100 registers and manages information indicating the scheduled payment date set by the service user UB in association with the user ID of the service user UB in the user information storage unit 124, for example. do. Note that multiple settings of information on the scheduled payment date may be accepted. For example, in addition to a regular salary, a temporary salary may be transferred from the company where the service user UB works. In this case, the service user UB realizes the distribution of the salary by presetting the scheduled date of deposit (receipt) in the receiving account. For example, the payment server 100 checks whether the scheduled payment date preset by the service user UB matches the transfer date on which the company transferred the money to the receiving account, and executes the distribution process. . Or, if there are multiple distribution settings linked to the service user UB, check if there is a distribution setting with a matching transfer date, and if there is, the distribution will be processed based on the corresponding distribution setting. Execute. On the other hand, if the preset scheduled payment date and the transfer date do not match, the payment server 100 notifies the service user UB and determines whether or not to distribute the funds deposited into the receiving account. The service user UB may make an inquiry and receive an instruction from the service user UB. Further, the payment server 100 may receive the setting of the name information of the transfer source in advance from the service user UB. For example, when service user UB has a side job, salary may be transferred from multiple companies, and it is possible to set different distribution settings for transfers from each company. For example, the payment server 100 checks whether there is a distribution setting in which the name preset by the service user UB matches the name of the transfer source for the receiving account, and if there is, Execute distribution processing based on On the other hand, if the name preset by the service user UB and the name of the transfer source do not match, the payment server 100 notifies the service user UB and arranges for the distribution of the funds deposited into the receiving account. An inquiry may be made as to whether or not to implement the service, and if so, which distribution settings to apply, and instructions from the service user UB may be accepted.

Furthermore, in the allocation setting, the payment server 100 may accept a pre-setting of a date for remittance or a setting of a date for adding a money balance.

(1-4-2. Information provision in distribution service)
Hereinafter, an example of providing information regarding the distribution service according to the embodiment will be described using FIGS. 3 and 4. FIG. 3 is a diagram showing an example (part 1) of providing information in the distribution service according to the embodiment. FIG. 4 is a diagram showing an example (part 2) of providing information in the distribution service according to the embodiment.

FIG. 3 shows an example of providing the service user UB with information regarding the scheduled payment for the receiving account. As shown in FIG. 3, upon receiving a transfer reservation from a company, the bank server 20 transmits transfer reservation information to the affiliated bank server 30 (step S11). For example, the transfer reservation information includes information indicating a scheduled transfer date, a transfer destination account number, and a scheduled transfer amount.

When the affiliated bank server 30 receives the transfer reservation information from the bank server 20, it transmits it to the payment server 100 as payment schedule information (step S12). For example, the scheduled payment information includes information indicating the scheduled payment date corresponding to the scheduled transfer date, the target account number corresponding to the transfer destination account number, and the scheduled payment amount corresponding to the scheduled transfer amount. There is. Note that the transfer reservation information may include information indicating the transfer source. In this case, the partner bank server 30 may include information indicating the transfer source in the payment schedule information and transmit it to the payment server 100.

Upon receiving the payment schedule information from the partner bank server 30, the payment server 100 refers to the information stored in the account information storage unit 121 and identifies the target person corresponding to the payment schedule information (step S13). ). For example, the payment server 100 searches for a recipient account number that matches the target account number from among the recipient account numbers stored in the account information storage unit 121, and selects a user who is associated with the searched recipient account number. By specifying the ID, the target person (for example, service user UB) corresponding to the payment schedule information is specified.

Further, after specifying the target person, the payment server 100 provides the target person with money payment schedule information by transmitting the money payment schedule information to the user terminal 10 of the specified target person (step S14). At this time, the payment server 100 may transmit payment schedule information including the scheduled payment date and the scheduled payment amount to the user terminal 10.

When the user terminal 10 receives the payment schedule information from the payment server 100, it notifies the service user UB, for example, by displaying the payment schedule information J-1 in a pop-up format through the payment application. Note that the display format of the payment schedule information J-1 on the user terminal 10 is not limited to the pop-up format, and any display format can be adopted. The payment schedule information J-1 shown in FIG. 3 shows an example in which information regarding the salary receipt schedule including the scheduled date of salary receipt and the scheduled amount of salary is displayed.

Further, the payment server 100 may check the distribution settings corresponding to the service user UB, and display information indicating the distribution processing schedule in the payment schedule information J-1.

Further, the payment server 100 may include, in the payment schedule information J-1, an object that transitions to processing for setting salary allocation in response to an operation by the service user UB.

Furthermore, if the payment schedule information includes information indicating the transfer source, the payment server 100 may include and display the information indicating the transfer source in the payment schedule information.

Further, the payment server 100 determines whether the scheduled payment date included in the scheduled payment information received from the affiliated bank server 30 is in the past, based on the reception history of scheduled payment information including information indicating the same transfer source. If it is different from the scheduled payment date, this fact may be included and displayed in the payment schedule information J-1.

In addition, if the payment server 100 receives in advance the setting of the scheduled payment (arrival) date for the receiving account from the service user UB, the payment server 100 sets the scheduled payment (arrival) date set in advance by the service user UB. It is also possible to check whether the scheduled money arrival dates included in the money arrival schedule information match and, if they match, to display information indicating a schedule for distribution processing. In addition, if the payment server 100 receives in advance the setting of the payer's name for the receiving account from the service user UB, the payment server 100 includes the payer's name preset by the service user UB and the payment schedule information. It is also possible to check whether the name of the transferee and the transferee name match, and if they match, information indicating the schedule for distribution processing may be displayed.

In addition, the payment server 100 refers to the usage history of the electronic payment service corresponding to the service user UB to be processed, and determines whether the service user UB has debts that need to be settled in the electronic payment service (for example, deferred payment or public payment). payment of fees, etc.). If the payment server 100 determines that the service user UB has a debt, the payment server 100 provides the service user UB with payment schedule information J-1 as well as proposal information for proposing payment of the debt. You may. Further, the payment server 100 proposes debt settlement only when the service user UB has a debt and the debt is less than the amount included in the payment schedule information (if the debt can be paid). It's okay.

FIG. 4 shows an example of notification when information regarding the distribution process is notified to the service user UB. The processing procedure from step S21 to step S23-1, 2 shown in FIG. 4 is similar to the processing procedure from step S03 to step S05-1, 2 shown in FIG. That is, the partner bank server 30 transmits a payment notification to the payment server 100 (step S21). Upon receiving the payment notification from the partner bank server 30, the payment server 100 specifies the distribution settings (step S22), sends a remittance instruction to the partner bank server 30 (step S23-1), and updates the balance in the electronic wallet. Addition (step S23-2) is performed.

When the payment server 100 completes the distribution process (steps S22 to S23-1, 2), the payment server 100 sends information J-2 to J-4 regarding the distribution process to the user terminal 10. Information regarding the distribution process is notified to the service user UB who is a party to the process (step S24). When the user terminal 10 receives the information J-2 to J-4 regarding the distribution process from the payment server 100, the user terminal 10 displays the information J-2 to J-4 regarding the distribution process in a pop-up format, for example, through the payment application. Accordingly, the service user UB is notified. Note that the display format of the information J-2 to J-4 regarding the distribution process on the user terminal 10 is not limited to the pop-up format, and any display format can be adopted.

For example, information J-2 regarding the distribution process sent from the payment server 100 to the user terminal 10 is used to notify the service user UB that a remittance has been made to M-1 bank in the name of living expenses. This corresponds to information. Information J-3 regarding the distribution process sent from the payment server 100 to the user terminal 10 is used to notify the service user UB that the remittance has been made to M-2 Bank in the name of a mortgage loan. This information corresponds to Information J-4 regarding the distribution process sent from the payment server 100 to the user terminal 10 is used to notify the service user UB that the money balance of the electronic wallet held by the service user UB has been added (charged). This information corresponds to

(1-4-3. Use of financial services through distribution services)
Hereinafter, an example of the use of financial services through the allocation service according to the embodiment will be described using FIG. 5. FIG. 5 is a diagram illustrating an example of the use of financial services through the distribution service according to the embodiment.

As described above, the payment server 100 receives from the service user UB at least one account to which the salary will be allocated, the amount to be transferred to the account, and the purpose of use of the account or the transfer. Accepts distribution settings including a nominal setting indicating the purpose of the minute. Thereby, the payment server 100 allows the service user UB to understand at a glance how the salary will be used.

The payment server 100 can receive from the service user UB the setting of a financial service linked to the electronic payment service as one of the destinations to which the salary will be allocated. For example, as shown in FIG. 5, the service user UB executes financial service usage settings through the payment application running on the user terminal 10 (step S31).

Upon receiving the financial service usage settings from the service user UB, the payment server 100 registers the financial service usage settings in association with the user ID of the service user UB (step S32). Then, the payment server 100 receives, for example, a payment notification from the partner bank server 30, and executes the same distribution process as in FIG. 1 (step S33).

Hereinafter, an overview of the financial service usage settings according to the embodiment will be described with reference to FIG. 5. For example, when the tab included in the screen switching tab display area A1-1 is switched to a predetermined tab by the service user UB, as shown in FIG. A setting screen G3-1 for accepting settings related to the above is displayed (display example EX3-1).

The setting screen G3-1 is provided with an automatic allocation setting reception area A2-1 for receiving a selection of automatic allocation settings for salary by the payment server 100 from the service user UB. In the automatic allocation setting reception area A2-1 shown in FIG. 5, there are three examples of automatic allocation setting methods that can be selected by the service user UB: "considerable type", "balanced type", and "aggressive type". has been done. Furthermore, in the automatic allocation setting reception area A2-1 shown in FIG. Information indicating the ratio is displayed.

In addition, the user terminal 10 displays an operation screen G3-2 when the automatic salary allocation setting is selected in response to the service user UB's operation on the button B2-1 on the setting screen G3-1 ( Display example EX3-2). The operation screen G3-2 shown in FIG. , referred to as "asset management amount"), and an area A3-3 where information regarding payments and remittances from salary is displayed. The savings amount information displayed in area A3-1 and the asset management amount information displayed in area A3-2 are based on the "balanced" distribution selected by service user UB on setting screen G3-1. For example, the amount is automatically calculated by the payment server 100 and displayed on the user terminal 10 through the payment application. Additionally, the information regarding payments and remittances from the salary displayed in area A3-3 may include information such as fixed costs that are paid at predetermined timings, which may be manually registered by the service user UB. However, it may be automatically displayed based on the prior registration of the service user UB. Note that an editing function may be associated with the area A3-3. In this case, the area A3-3 is configured such that information regarding payments and remittances from the salary can be edited as desired in accordance with the operations of the service user UB.

In addition, the operation screen G3-3 is displayed on the user terminal 10 when manual setting of the salary operation amount is selected in response to the service user UB's operation on the button B2-2 on the setting screen G3-1. (Display example EX3-3). The operation screen G3-3 shown in Figure 5 includes an area A4-1 where information on savings amount is displayed, an area A4-2 where information on asset management amount is displayed, and information regarding payments and remittances from salary. It includes the displayed area A4-3. Information on the amount saved from salary displayed in area A4-1 and information on asset management amount displayed in area A4-2 are manually set by the service user UB on the operation screen G3-3. Further, a setting function is associated with the area A4-1 and the area A4-2, and the setting function can be activated in response to an operation by the service user UB. Further, the setting function associated with area A4-1 and area A4-2 may be configured to accept settings for savings amount or asset management amount by specifying the amount, or the ratio to (total amount of) salary. The configuration may be such that it is possible to accept settings for savings amounts and asset management amounts by specifying . The operation screen G3-3 shown in FIG. 5 shows an example in which the amount of savings and the amount of asset management are set by specifying the ratio to (the total amount of) salary. In addition, when accepting settings for savings amount or asset management amount by specifying a ratio to (total amount of) salary, payment server 100 may accept specification of the ratio for each type of savings or asset management product.

In addition, as a condition for using the financial service, the payment server 100 provides the service user UB with a predetermined account for transferring funds to a business that provides financial services linked to the electronic payment service. You can request that it be opened. For example, service user UB can be requested to open a bank account for receiving and managing savings from salary at Bank Y, which is a partner bank of business operator UA that provides electronic payment services. Further, the service user UB can be requested to open a securities account for remittance of managed assets from salary to a securities company affiliated with the business UA that provides the electronic payment service.

(1-4-4. Information management in distribution service)
Hereinafter, an example of information management in the distribution service according to the embodiment will be described using FIG. 6. FIG. 6 is a diagram illustrating an example of information management in the distribution service according to the embodiment.

The payment server 100 can grasp the payment and disbursement status of the service user UB's salary based on the history of the distribution process executed according to the distribution settings corresponding to the service user UB, the usage history of the electronic payment service, and the like. Thereby, the payment server 100 can provide information to the service user UB based on the payment and payment status of the salary. Specifically, the payment server 100 links to the user ID of one payment service (for example, user identification information for identifying the service user UB), and records the salary deposit history and the electronic payment service. Usage history, history of remittances of transferred salaries to other bank accounts, history of deposits and withdrawals of transferred salaries to other financial services, and electronic money exchanges with other service users who use electronic payment services. Manage each piece of information that shows the transmission and reception history of. By managing the above-mentioned various information for each service user, the payment server 100 can provide each service user with information based on the payment and payment status of their salary.

For example, as shown in FIG. 6, the service user UB transmits a request to provide expenditure information through the payment application running on the user terminal 10 (step S41). Upon receiving the request for provision of expenditure information from the service user UB, the payment server 100 acquires the expenditure information corresponding to the service user UB (step S42). Then, the payment server 100 provides the acquired expenditure information to the service user UB (step S43).

Hereinafter, with reference to FIG. 6, an example of expenditure information provided to the service user UB in the allocation service according to the embodiment will be described. For example, when the tab included in the screen switching tab display area A1-1 is switched to a predetermined tab by the service user UB, as shown in FIG. An expenditure information display screen G4-1 that displays expenditure information is displayed (display example EX4-1).

In addition, the user terminal 10 also displays the history of the service user UB's allocation process and the history of the use of the electronic payment service of the service user UB in accordance with the operation of the service user UB on the expenditure information display screen G4-1. A household account book information display screen G4-2 is displayed that displays household account book information in which expenditures from the service user UB's salary are organized by expense item based on (display example EX4-2).

The household account book information displayed on the household account book information display screen G4-2 can be displayed on a monthly basis, for example, in response to a request from the service user UB. In addition, the household account book information shown in Figure 6 displays expenditure information corresponding to each expense item such as "living expenses," "savings," "investments," "tuition/education," and "insurance." . Expense items are identification information given to each item of expenditure in order to organize expenditures in household account book information, and may be the same as the information indicating the purpose of use or purpose of allocation in allocation settings, or may partially overlap. You may also do so. The payment item is automatically determined by the payment server 100 based on the expenditure information included in the service user UB's allocation processing history and the service user UB's electronic payment service usage history, according to predefined registration information. Alternatively, a tag set for the expenditure information included in the service user UB's allocation process history and the service user UB's electronic payment service usage history may be used. The payment server 100 stores expenditure information based on the tag indicating the expense item assigned to the expenditure information included in the service user UB's allocation processing history and the service user UB's electronic payment service usage history. Generate household account book information by organizing by expense item. Then, the payment server 100 provides the generated household account book information to the service user UB by transmitting it to the user terminal 10. Note that the payment server 100 can also receive the setting of a tag to be added to the expenditure information from the service user UB when the allocation setting is performed. In this case, when executing the distribution process, the payment server 100 can automatically attach a tag to the expenditure information based on the tag settings received from the service user UB. Thereby, the payment server 100 does not need to attach tags to the expenditure information by itself, and can improve convenience for the service user UB.

Further, the payment server 100 may receive information indicating a nominal name for identifying funds deposited into a receiving account as income for each of a plurality of receiving accounts. In this case, the payment server 100 automatically attaches a tag indicating whether or not the deposit (receipt) is a payment using a salary as the name of the payment information for the receiving account using the salary as the name. Good too. Further, when the payment server 100 returns the funds that were used for asset management to electronic money, it may automatically add a tag indicating that the funds were used for asset management. The payment server 100 may also tag receipts of electronic money such as personal electronic money remittances from other service users. In this way, the payment server 100 can also include deposit information (that is, information regarding the income of the service user UB) in the household account book information.

In addition, the payment server 100 may associate and display information indicating the amount from which history, that is, the history from which the information was acquired, in addition to the expense items, as the generated household account book information. For example, the payment server 100 associates the expenditure amount with the expense item and also with the withdrawal route such as account transfer, electronic money remittance, use of electronic payment service, and financial service deposit. As a breakdown of the living expenses of 123,000 yen displayed on the household account book information display screen G4-2 shown in FIG. 3, information for each withdrawal route, such as 50,000 yen for account transfer and 20,000 yen for electronic money transfer, may be displayed.

[2. Payment server configuration]
Next, the configuration of the payment server 100 will be described using FIG. 7. FIG. 7 is a diagram showing a configuration example of the payment server 100 according to the embodiment. As shown in FIG. 7, payment server 100 includes a communication section 110, a storage section 120, and a control section 130.

(About communication department 110)
The communication unit 110 is realized by, for example, a NIC (Network Interface Card). The communication unit 110 is connected to the network N by wire or wirelessly, and transmits and receives information to and from the user terminal 10, the partner bank server 30, and the like.

(About storage unit 120)
The storage unit 120 is realized by, for example, a semiconductor memory element such as a RAM (Random Access Memory) or a flash memory, or a storage device such as a hard disk or an optical disk. As shown in FIG. 7, the storage unit 120 includes an account information storage unit 121, an allocation setting storage unit 122, an allocation history storage unit 123, and a user information storage unit 124.

(About account information storage unit 121)
The account information storage unit 121 stores information indicating the correspondence between a service user (eg, service user UB) and a receiving account. FIG. 8 is a diagram showing an example of information stored in the account information storage unit 121 according to the embodiment. As shown in FIG. 8, the information indicating the correspondence relationship stored in the account information storage unit 121 includes an item of "user ID" and an item of "receipt account number."

The "user ID" item stores a user ID, which is unique identification information given to each service user in order to uniquely identify the service user in the electronic payment service. The "receiving account number" item stores a receiving account number for specifying the receiving account issued to the service user. The receiving account is a virtual account for receiving salary in both electronic money and cash.

For example, according to FIG. 8, an example is shown in which the receiving account number for specifying the receiving account assigned to the service user identified by the user ID "U#001" is "VA#001". has been done.

(About the distribution setting storage unit 122)
The distribution setting storage unit 122 stores information regarding distribution settings indicating where the salary is to be distributed for each service user. For example, information regarding distribution settings includes at least one distribution account to which salary will be distributed, the amount to be transferred to the distribution destination account, and a nominal setting indicating the purpose of use or distribution purpose of the distribution destination account. including. Furthermore, the distribution setting storage unit 122 may store information regarding a plurality of distribution settings for each service user. In that case, in addition to the identifier linked to the information regarding each distribution setting, information indicating the transfer source, such as information indicating the name of the transfer source, information indicating the scheduled date of payment, or an arbitrary name that specifies the transfer setting accepted from the user, etc. may be stored in association with each other. FIG. 9 is a diagram illustrating an example of information regarding distribution settings stored in the distribution settings storage unit 122 according to the embodiment.

As shown in FIG. 9, the information regarding the distribution settings stored in the distribution settings storage unit 122 includes an item of "user ID" and an item of "distribution settings." These items included in the information regarding the distribution settings are correlated with each other.

The "user ID" item stores a user ID, which is unique identification information given to each service user in order to uniquely identify the service user in the electronic payment service. For example, the user ID stored in the "user ID" item included in the information regarding distribution settings is the "user ID" item included in the information indicating the correspondence stored in the account information storage unit 121 described above. This information is the same as the user ID stored in .

The "allocation settings" item includes the "allocation destination account" item, the "remittance amount" item, and the "nominal name" item. Information for specifying the account to which the salary will be allocated is stored in the "allocation destination account" item. For example, if the destination account is a bank account, information indicating the account number for identifying the bank account is stored. In the item "Remittance amount", information indicating the remittance amount to the destination account is stored. In the item "Nominal", information indicating the purpose of use or the purpose of allocation of the "allocation destination account" is stored.

According to FIG. 9, the service user identified by the user ID "U#001" uses "M-1 Bank (ordinary) 111,111”, it is shown that a remittance of “220,000 yen” will be made. Note that the payment server 100 may receive the implementation date of the distribution process in advance from the service user as the distribution setting. In this case, the payment server 100 stores information indicating the execution date of the distribution process in the distribution setting storage unit 122 in association with the user ID.

(About the distribution history storage unit 123)
The distribution history storage unit 123 stores a distribution history, which is a history of distribution processes executed according to distribution settings, for each service user. FIG. 10 is a diagram illustrating an example of the distribution history stored in the distribution history storage unit 123 according to the embodiment. As shown in FIG. 10, the distribution history stored in the distribution history storage unit 123 includes items such as "user ID", "distribution date", "deposit amount", and "transfer amount". It has multiple items such as ``Remittance'' item, ``Remittance amount'' item, and ``Nominal amount'' item. These items included in the distribution history are associated with each other. Note that the distribution history storage unit 123 does not need to be particularly limited to the example described below, and can store salary deposit history, electronic payment service usage history, bank of transferred salary as the history of distribution processing. Information indicating the history of remittances to accounts, the history of deposits and withdrawals to other financial services, and the history of sending and receiving electronic money with other users of electronic payment services may be stored.

The "user ID" item stores a user ID, which is unique identification information given to each service user in order to uniquely identify the service user in the electronic payment service. For example, the user ID stored in the "user ID" item of the allocation history is stored in the "user ID" item of the information indicating the correspondence stored in the account information storage unit 121 described above. This information is the same as the user ID provided.

Information indicating the date on which the distribution process was executed according to the distribution settings is stored in the item "Distribution date." The item "Deposit amount" stores information indicating the amount of salary deposited into the receiving account. The "Allocation destination" item contains information indicating the destination account (account number) to which the remittance was made through the distribution process, and information indicating the electronic wallet to which the balance was added through the distribution process (wallet ID). ) is memorized. In the item "Remittance amount", information indicating the remittance amount remitted through the distribution process is stored. In the item "Nominal", information indicating the purpose of use or the purpose of distribution of the destination is stored.

For example, according to FIG. 10, on December 25, 20XX, distribution processing is executed for the salary of 300,000 yen deposited into the receiving account of the service user identified by the user ID "U#001". It is shown that Also, according to Figure 10, on December 25, 20XX, out of the 300,000 yen salary, 22 yen was paid to the M-1 Bank ordinary account identified by account number "111111" in the name of living expenses. It shows that a remittance of 10,000 yen was made. In addition, on December 25, 20XX, out of the 300,000 yen salary, 30,000 yen was transferred to the M-2 Bank ordinary account identified by account number "222222" in the name of a mortgage loan. It is shown that it has been done. Additionally, on December 25, 20XX, out of the 300,000 yen salary, a money balance equivalent to 50,000 yen was added to the electronic wallet specified by the wallet ID "Wallet #001". It is shown that the

(About the user information storage unit 124)
The user information storage unit 124 stores user information regarding service users. FIG. 11 is a diagram showing an example of user information stored in the user information storage unit 124 according to the embodiment. As shown in FIG. 11, the user information stored in the user information storage unit 124 includes information regarding the service usage history of the electronic payment service by the service user. The user information stored in the user information storage unit 124 includes items such as "user ID", "date of use", "store used", "payment amount", and "payment amount". It has multiple items such as ``Method'', ``Money Balance'', ``Deferred Payment'', ``Financial Services'', and ``Payment/Remittance''. These items included in the user information are associated with each other.

The "user ID" item stores a user ID, which is unique identification information given to each service user in order to uniquely identify the service user in the electronic payment service. For example, the user ID stored in the "user ID" item of the allocation history is stored in the "user ID" item of the information indicating the correspondence stored in the account information storage unit 121 described above. This information is the same as the user ID provided.

The "Usage date" field includes the date on which the payment for the product or service was made using the electronic payment service, and the charge of electronic money (balance addition) to the electronic wallet used in the electronic payment service. Information indicating the date on which the event occurred is stored. The "Used store" field contains information indicating the store where the payment for the product or payment for the service was made using the electronic payment service (member store that has introduced the electronic payment service), or information indicating the store where the payment for the product or service was made using the electronic payment service, or where the service user Information indicating the bank, credit card company, etc. used to charge electronic money to the wallet (add balance) is stored.

In the item "Amount of payment and payment", information indicating the amount of withdrawal and payment amount by using the electronic payment service is stored. The "Payment Method" item stores information indicating whether the service user made an immediate payment using an electronic payment service or a deferred payment. The "money balance" item stores information indicating the money balance at the time the service user uses the electronic payment service. The "money balance" item includes the regular money balance (balance for payments) that the service user charges through the payment app, and the money balance when a portion of the salary is received as electronic money. Each balance is managed individually. For example, the payment server 100 manages funds that are distributed as charges to an electronic wallet out of funds deposited into a receiving account associated with a service user as electronic money corresponding to a salary. The item "Deferred payment" stores information indicating whether the service user has registered to use deferred payment as a payment method for the electronic payment service.

The "Financial services" item includes the "Savings" item, which is one of the financial services linked to electronic payment services, and the "Operation" item, which is another financial service linked to electronic payment services. Contains. When a service user registers to use a financial service, various information set by the service user at the time of registering to use the financial service is stored as usage registration information in the "Savings" and "Operation" items. be done. For example, the usage registration information includes information indicating the usage amount of financial services, such as savings amount and asset management amount, and information indicating a predetermined account to which the usage amount is allocated. The "Payment/Remittance" item contains payment remittance information, including information regarding the payment of a specified amount from an electronic wallet by a service user using an electronic payment service, and information regarding remittances to other service users. be remembered.

According to Figure 11, the service user identified by user ID "U#001" charged electronic money worth 10,000 yen through M-1 Bank on December 12, 20XX. It is shown. Further, according to FIG. 11, it is shown that the service user identified by the user ID "U#001" has not registered to use deferred payment as a payment method. Also, according to FIG. 11, user information corresponding to the service user identified by the user ID "U#001" includes financial service usage registration information regarding savings and operations, and payment remittance information regarding payments and remittances. is shown to be included.

(About the control unit 130)
The control unit 130 is a controller, and for example, various programs stored in the storage device inside the payment server 100 use the RAM as a work area by a CPU (Central Processing Unit) or an MPU (Micro Processing Unit). This is achieved through execution. Further, the control unit 130 may be realized by, for example, an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

As shown in FIG. 7, the control unit 130 according to the embodiment includes a reception unit 131, a distribution processing unit 132, and a provision unit 133, and each of these units performs information processing functions and functions described below. accomplish or carry out an action.

(About reception department 131)
The reception unit 131 selects multiple sources including an electronic wallet owned by the service user in the electronic payment service as a destination for allocating funds (for example, salary) deposited into a predetermined bank account linked to the service user in advance. Receive distribution settings from the service user to specify the distribution destination. Here, the predetermined bank account linked to the service user in advance is a receiving account for receiving at least a part of the funds linked to the service user in electronic money, and the predetermined bank account linked to the service user (For example, business operator UA) is arbitrarily assigned to the service user from among the virtual accounts borrowed from the affiliated bank Y. The receiving account is linked to a bank account, which is a real account held at Bank Y by the operator of the electronic payment service, and remittances addressed to the receiving account are deposited into the real account.

Further, the receiving unit 131 may receive a setting of a receiving amount indicating the amount of funds to be received in electronic money from the service user. The receiving unit 131 registers information indicating the amount to be received set by the service user in the distribution setting storage unit 122 in association with the user ID of the service user.

Further, instead of the received amount, the receiving unit 131 may receive a setting of a receiving ratio indicating the ratio of the received amount to the funds from the service user. In this case, the receiving unit 131 registers information indicating the receiving ratio set by the service user in the distribution setting storage unit 122 in association with the user ID of the service user.

Further, the reception unit 131 may receive the above-mentioned setting of the amount to be received or the rate of receipt from the service user through a settings screen (an example of a "predetermined user interface") of a payment application provided to the service user.

Further, the reception unit 131 may receive settings from the service user for at least one account to which funds are to be allocated and the remittance amount corresponding to the account. In this case, the reception unit 131 sets the distribution by associating each information indicating the distribution destination account set by the service user and the remittance amount corresponding to the distribution destination account with the service user's user ID. It is registered in the storage unit 122.

In addition, the reception unit 131 provides information indicating the above-mentioned allocation destination account and the remittance amount corresponding to the allocation destination account through the settings screen (an example of a "predetermined user interface") of the payment application provided to the service user. may be accepted from the service user.

Further, instead of the remittance amount, the reception unit 131 may receive a setting of a remittance ratio indicating the ratio of the remittance amount to funds from the service user. In this case, the reception unit 131 registers information indicating the remittance rate set by the service user in the allocation setting storage unit 122 in association with the user ID of the service user.

In addition, the reception unit 131 also provides, as information regarding allocation settings, the allocation destination account to which funds deposited into a predetermined bank account linked to the service user in advance are allocated, and the transfer to the allocation destination account. Settings of nominal information indicating the amount and the purpose of use or the purpose of distribution of the destination account may be received from the service user. In this case, the reception unit 131 sends each nominal information indicating the allocation destination account set by the service user, the remittance amount corresponding to the allocation destination account, and the purpose of use or allocation purpose of the allocation destination account, It is registered in the distribution setting storage unit 122 in association with the user ID of the service user.

In addition, the reception unit 131 displays the above-mentioned allocation destination account, the remittance amount corresponding to the allocation destination account, and the allocation Each piece of nominal information indicating the purpose of use or the purpose of allocation of the destination account may be received from the service user. Further, the reception unit 131 may receive information indicating the name of each of a plurality of predetermined bank accounts.

In addition, the reception unit 131 receives a schedule for receiving funds from Bank Y, which is a partner of a business operator that operates an electronic payment service (for example, business UA), to a predetermined bank account linked in advance to the service user. Payment schedule information shown in the table may also be accepted.

Further, the receiving unit 131 may receive from the service user the setting of information indicating a ratio to funds as information for specifying the amount to be allocated to a predetermined financial service linked to the electronic payment service. In this case, the reception unit 131 registers information indicating the amount to be allocated to a predetermined financial service (ratio to funds) in the user information storage unit 124 in association with the user ID of the service user.

(About the distribution processing unit 132)
When the payment to a predetermined bank account is confirmed (when receiving the payment notification from the affiliated bank server 30), the distribution processing unit 132 performs the distribution processing based on the distribution settings corresponding to the target service user. , executes a distribution process to distribute funds deposited into a predetermined bank account.

In addition, if there is a setting for the received amount to be received as electronic money in the distribution settings corresponding to the target service user, the distribution processing unit 132 transfers an amount equivalent to the received amount to the electronic wallet held by the service user. Electronic money in an amount equivalent to the received amount, provided that the balance after addition does not exceed a predetermined amount that is the upper limit that the service user can secure in the electronic wallet. may be added to your electronic wallet. In addition, if the balance after adding electronic money equivalent to the received amount to the electronic wallet held by the service user exceeds a predetermined amount, the distribution processing unit 132 The amount corresponding to the excess amount exceeding the predetermined amount may be paid out to the set payout destination bank account.

Furthermore, if there is a setting of a receiving ratio indicating the ratio of the receiving amount to the funds in the allocation setting corresponding to the target service user, the allocation processing unit 132 calculates the receiving amount based on the funds and the receiving ratio. An amount of electronic money corresponding to the calculated received amount may be added to the electronic wallet.

In addition, in the allocation setting corresponding to the target service user, the allocation processing unit 132 sets at least one allocation destination account to which funds will be allocated and the remittance amount corresponding to the allocation destination account. If there is, the remittance may be executed from a predetermined bank account to the recipient account according to the settings of the recipient account and remittance amount.

In addition, if there is a remittance ratio setting indicating the ratio of the remittance amount to funds in the allocation settings corresponding to the target service user, the allocation processing unit 132 calculates the remittance amount based on the remittance ratio, Based on the calculated remittance amount, remittance may be executed from a predetermined bank account to the destination account.

Further, the allocation processing unit 132 selects a predetermined financial service linked to the electronic payment service based on information indicating the ratio of funds deposited into a predetermined bank account linked to the target service user in advance. Alternatively, an allocation process may be performed in which an amount to be allocated is calculated, and an amount corresponding to the calculated amount to be allocated is allocated to a predetermined account for using a predetermined financial service. For example, the distribution processing unit 132 may distribute cash in an amount equivalent to the distribution amount from a predetermined bank account to a predetermined account, or transfer electronic money in an amount equivalent to the distribution amount to the balance of the electronic wallet. You may also allocate the funds to a designated account.

Further, the distribution processing unit 132 directly distributes cash equivalent to the distribution amount from a predetermined bank account to a predetermined account, or It may also be determined whether to allocate electronic money equivalent to the amount from the balance of the electronic wallet to a predetermined account. For example, if the payment method available for a predetermined financial service is "cash only," the distribution processing unit 132 may remit cash in an amount equivalent to the distribution amount from a predetermined bank account to a predetermined account. Accordingly, it will be distributed directly. For example, the allocation processing unit 132 may directly allocate cash equivalent to the allocated amount from a predetermined bank account to a predetermined account according to the settings of the service user, or It may also be determined whether to allocate electronic money from the balance of the electronic wallet to a predetermined account. In addition, if both "cash" and "electronic money" are available as payment methods for a predetermined financial service, the distribution processing unit 132 transfers funds from a predetermined bank account to a predetermined account according to the settings of the service user. You may decide whether to allocate the money directly or to allocate it from the balance of the electronic wallet to a predetermined account.

In addition, the distribution processing unit 132 distributes electronic money in an amount corresponding to the distribution amount to a predetermined account from the money balance corresponding to the salary in the electronic wallet held by the service user. Processing may be executed. For example, when allocating a part of the salary received in electronic money to savings, the allocation processing unit 132 uses a bank account that the business UA holds at Bank Y and that is linked to the receiving account corresponding to the service user. An amount equivalent to the allocated amount will be transferred from the account to the savings bank account opened by the service user at Bank Y, and an amount equivalent to the allocated amount will be transferred from the money balance corresponding to the service user's salary. By subtracting the amount of electronic money, distribution processing regarding the service user's savings can be executed. In addition, when a part of the salary received in electronic money is allocated to asset management, the allocation processing unit 132 links the bank account that the business UA holds with Bank Y to the receiving account corresponding to the service user. An amount equivalent to the allocated amount will be transferred from the actual account to the bank account that the service user opened at Bank Y to deposit money into the securities account, and the money balance corresponding to the service user's salary will be transferred. By subtracting electronic money in an amount equivalent to the allocated amount, allocation processing regarding the service user's asset management can be executed.

In addition, if there are multiple transfer settings corresponding to the target service user, the allocation processing unit 132 corresponds to the funds deposited into the receiving account based on the content of the setting information included in the transfer settings. You may also select a distribution setting that indicates where the deposited funds will be distributed. For example, a distribution setting is selected based on the information on the scheduled payment date set in the distribution setting and information on the holder of the transfer source, and distribution processing is executed based on the selected distribution setting.

(About the provision section 133)
The providing unit 133 provides the service user with suggestion information regarding the setting of the next amount to be received based on the service user's usage history of the electronic payment service.

Further, the providing unit 133 can provide the service user with information regarding distribution settings corresponding to the service user, for example, in response to a request from the service user.

Further, the providing unit 133 may provide the service user with the payment schedule information received by the receiving unit 131. At this time, the providing unit 133 may provide the service user with money arrival schedule information including the expected money arrival date and the expected money arrival amount for a predetermined bank account.

Further, the providing unit 133 may provide the service user with information indicating the schedule of distribution processing specified based on the distribution settings corresponding to the service user, along with the payment schedule information.

Further, the providing unit 133 may provide the service user with an object that transfers the processing for setting the distribution according to the service user's operation, along with the payment schedule information.

Further, the providing unit 133 may provide the service user with information regarding the distribution process executed according to the distribution settings corresponding to the service user.

Further, the providing unit 133 refers to the usage history of the electronic payment service corresponding to the service user and determines whether the service user has a debt that requires settlement in the electronic payment service (for example, deferred payment). If it is determined that the service user has a debt, the service user may be provided with information on the payment schedule and proposal information for proposing the liquidation of the debt. good.

In addition, in response to a request from a service user, the providing unit 133 transfers the expenditure from the service user's funds to an expense item for identifying the expenditure, based on the history of allocation processing and the usage history of the electronic payment service. Provide service users with household account book information organized by category. Further, the providing unit 133 provides the service user with household account book information in which funds are organized as income based on the name corresponding to the funds deposited in a predetermined bank account and information on the funds deposited in the predetermined bank account. may be provided to Further, the providing unit 133 may provide the service user with household account book information including information indicating the history from which information on funds deposited into a predetermined bank account is obtained. Further, the providing unit 133 may provide the service user with household account book information in which funds deposited into a predetermined bank account are organized by name indicating the purpose of use or the purpose of allocation.

[3. Processing procedure example]
(3-1. Payment schedule provision processing)
An example of the processing procedure in the payment server 100 according to the embodiment will be described below. First, an example of the processing procedure of the payment schedule provision processing according to the embodiment will be explained using FIG. 12. FIG. 12 is a flowchart illustrating an example of a processing procedure of a payment schedule provision process executed by the payment server 100 according to the embodiment. Note that the processing procedure shown in FIG. 12 is executed by the control unit 130 included in the payment server 100. The control unit 130 repeatedly executes the processing procedure shown in FIG. 12 while the payment server 100 is in operation.

As shown in FIG. 12, the providing unit 133 determines whether or not payment schedule information has been received from the partner bank server 30 (step S101).

When determining that the provision unit 133 has received the payment schedule information from the partner bank server 30 (step S101; Yes), the provision unit 133 selects the target user who is the target service user based on the received payment schedule information. is specified (step S102). Then, the providing unit 133 provides payment schedule information to the specified target user (step S103), and ends the processing procedure shown in FIG. 12.

Further, in step S101 described above, when the providing unit 133 determines that the payment schedule information has not been received from the partner bank server 30 (step S101; No), the processing procedure shown in FIG. 12 is ended.

(3-2. Sorting process)
Hereinafter, an example of the processing procedure of the distribution process according to the embodiment will be described using FIG. 13. FIG. 13 is a flowchart illustrating an example of the processing procedure of the distribution process executed by the payment server 100 according to the embodiment. Note that the processing procedure shown in FIG. 13 is executed by the control unit 130 included in the payment server 100. The control unit 130 repeatedly executes the processing procedure shown in FIG. 13 while the payment server 100 is in operation.

As shown in FIG. 13, the distribution processing unit 132 determines whether the money has arrived at the receiving account linked to the service user (step S201).

If the allocation processing unit 132 determines that the money has arrived at the receiving account linked to the service user (step S201; Yes), the allocation processing unit 132 refers to the information stored in the allocation setting storage unit 122 and selects the target The distribution settings of the target user, who is the service user, are identified (step S202).

Further, the allocation processing unit 132 refers to the specified allocation settings and identifies information regarding the bank account to which the target user will be allocated (step S203).

Further, the allocation processing unit 132 transmits a remittance instruction based on the specified allocation destination account and remittance amount to the partner bank server 30 (step S204).

Further, the providing unit 133 provides the target user with information regarding the allocation process to the bank account (step S205).

In addition, the distribution processing unit 132 determines whether or not there is an electronic wallet to which the target user's salary will be distributed in the target user's distribution settings (step S206).

If the allocation processing unit 132 determines that there is an electronic wallet to which the target user's salary will be allocated (step S206; Yes), the allocation processing unit 132 determines whether the money balance after allocation is less than or equal to a predetermined upper limit amount. is determined (step S207). That is, the distribution processing unit 132 determines whether the balance after adding electronic money corresponding to the received amount registered in the distribution settings to the electronic wallet is less than or equal to a predetermined amount.

If the distribution processing unit 132 determines that the money balance after distribution is less than or equal to the predetermined upper limit amount (step S207; Yes), the distribution processing unit 132 distributes the amount equivalent to the received amount corresponding to the target user according to the distribution settings. is added to the balance (step S208). That is, the distribution processing unit 132 adds an amount of electronic money corresponding to the received amount registered in the distribution setting to the electronic wallet.

Further, the providing unit 133 provides information regarding the allocation process to the electronic wallet to the target user (step S209), and ends the processing procedure shown in FIG. 13. That is, the providing unit 133 provides the target user with information that the electronic wallet has been charged with electronic money in an amount corresponding to the received amount.

In step S207 described above, if the distribution processing unit 132 determines that the money balance after distribution is not less than the predetermined upper limit amount (step S207; No), the process proceeds to step S209 described above. . That is, the distribution processing unit 132 provides the target user with information that the electronic wallet cannot be charged due to an excess balance.

In step S206 described above, if the distribution processing unit 132 determines that there is no electronic wallet to which the salary of the target user is distributed (step S206; No), the distribution processing unit 132 ends the processing procedure shown in FIG. 13.

In step S201 described above, if the distribution processing unit 132 determines that no money has arrived at the receiving account linked to the service user (step S201; No), the processing procedure shown in FIG. 13 ends.

Note that the payment server 100 does not need to execute the processing procedure shown in FIG. 13 in the order shown in FIG. For example, the payment server 100 may execute the processing steps from step S206 to step S209 before the processing steps from step S202 to step S205. Further, the payment server 100 may simultaneously perform the information provision in step S205 and the information provision in step S209 after both the processing procedure of step S204 and the processing procedure of step S208 are completed.

[4. Modified example]
(4-1. Regarding distribution of excess money)
In the embodiment described above, the payment server 100 adds the amount of electronic money equivalent to the received amount to the electronic wallet held by the service user (for example, the service user UB), and the balance after the addition is stored in the electronic wallet. An example has been described in which an amount of electronic money equivalent to the received amount is added (charged) to an electronic wallet on the condition that the amount does not exceed a predetermined amount that is predetermined as the upper limit that can be secured. Furthermore, in the above-described embodiment, an example has been described in which the payment server 100 provides the service user with information that if the balance after addition exceeds a predetermined amount, the electronic wallet cannot be charged because the balance exceeds the balance. Here, the payment server 100 may provide the service user UB with proposal information indicating that the electronic wallet has an excess balance and suggesting distribution of the excess amount by a predetermined amount. An overview of information processing by the payment server 100 according to the modified example will be described below. Note that, although an example of information processing that proposes allocation of an amount in excess of a predetermined amount will be described below, the payment server 100 is not particularly limited to this example. For example, the payment server 100 accepts settings for distribution of excess amounts (settings for specifying a percentage of the excess amount and where to distribute it) in addition to normal distribution settings. The excess amount may be distributed based on. Further, for example, the payment server 100 accepts in advance the selection of the destination to which the excess amount will be allocated from among the destinations to which the excess amount will be allocated when the excess amount occurs in the normal allocation settings, and automatically The amount may be added to the amount to be distributed to the corresponding destination. For example, when accepting distribution settings, checking the checkbox to determine whether or not to add and distribute excess amounts in the event of an excess amount becomes effective.

For example, the allocation processing unit 132 included in the control unit 130 shown in FIG. It is determined whether or not the balance after addition of the electronic money is added to the electronic wallet owned by the service user UB exceeds a predetermined amount. Then, when the allocation processing unit 132 determines that the balance after addition exceeds the predetermined amount, the allocation processing unit 132 passes this information to the providing unit 133 included in the control unit 130 .

If the distribution processing unit 132 determines that the balance after addition exceeds the predetermined amount, the provision unit 133 provides information that the balance after addition exceeds the predetermined amount, as well as information that the balance after addition exceeds the predetermined amount. By transmitting proposal information proposing the allocation of the information to the user terminal 10, it is provided to the service user through the payment application running on the user terminal 10.

For example, the providing unit 133 uses the service to provide proposal information that proposes that the excess amount be distributed to a bank account that is specified as one of the destinations for salary distribution in the distribution settings corresponding to the target service user. may be provided to the person. In addition, if the target service user is registered to use a financial service linked to an electronic payment service, the providing unit 133 provides the service user with proposal information that proposes allocating the excess amount to the financial service that is currently being used. may be provided to Further, if the target service user is not registered to use financial services, the providing unit 133 provides proposal information that proposes registration for financial services and allocates excess amount to the financial services currently being used. may be provided to the service user.

Further, the providing unit 133 may suggest a recipient based on the usage status (for example, usage history) of bank accounts and financial services registered as recipients. For example, in the case of a bank account, the providing unit 133 may determine the most frequently used account as the transfer destination account based on the history of remittances to bank accounts that are accepted each time, rather than the transfer history or bank account based on the transfer settings. good. Further, for example, if it is possible to obtain the balance using the balance API of the account registered as the target service user's bank account, the providing unit 133 may determine, for example, the rate at which the balance decreases ( For example, if the rate of decrease over a given period exceeds a threshold or the balance has decreased below a certain amount, the number of times used (for example, the cumulative number of times or the number of times over a given period) is the highest. An account or the like may be determined as the proposed allocation destination account. Regarding financial services, similarly to the case of bank accounts, the providing unit 133 performs transfers from accounts linked to financial services based on the remittance history and balance of the user account of the service user linked to the financial services. You may also decide on a distribution account.

Further, the providing unit 133 may make an inquiry as to whether or not to allocate the excess amount, for example, through the proposal information. Then, when there is a reply from the service user that the excess amount will be distributed, the providing unit 133 communicates this to the distribution processing unit 132. The distribution processing unit 132 executes a process of distributing the excess amount according to the answers from the service users.

Further, the reception unit 131 included in the control unit 130 may receive setting information in advance from the service user that specifies the destination to which the excess amount will be distributed. In this case, the distribution processing unit 132 executes the process of distributing the excess amount based on the setting information corresponding to the target service user. Further, the providing unit 133 may provide the service user with information to the effect that the excess amount allocation processing is to be executed, to the user terminal 10 according to the pre-set information. Further, when the distribution processing unit 132 executes the distribution process for the excess amount, the providing unit 133 transmits information to the user terminal 10 to the effect that the distribution process for the excess amount has been executed. may be provided to the person.

(4-2. Regarding prepaid services)
(4-2-1. Overview of information processing regarding prepaid services)
Traditionally, there has been a salary advance payment service for employees who need unexpected expenses. If a company wanted its employees to use a salary advance payment service, it would be necessary to conclude a service usage contract with a prepayment service provider, which would be difficult to implement. Therefore, the payment server 200 according to the modified example temporarily transfers at least a part of the salary that the service user UB is scheduled to receive in electronic money, so that the electronic wallet held by the service user UB can We provide a prepayment service that precharges the amount of money desired by the service user. Thereby, the payment server 200 according to the modification can propose a new option to the service user as a method of receiving salary in electronic money. As a result, the payment server 200 according to the modified example does not require the company to conclude a contract with a prepayment provider, allows employees to use prepayment of salary, and improves the convenience of services related to digital salary payment. You can improve your performance. On the other hand, employees can also receive at least a portion of their salary in electronic money through advance payment without the knowledge of the company they work for. An overview of information processing regarding the prepaid service according to the modified example will be described below. FIG. 14 is a diagram showing an overview of information processing regarding a prepaid service according to a modification.

For example, when the partner bank server 30 receives transfer reservation information from the bank server 20, it transmits it to the settlement server 200 as payment schedule information, as shown in FIG. 14 (step S51). For example, the scheduled payment information includes information indicating the scheduled payment date corresponding to the scheduled transfer date, the target account number corresponding to the transfer destination account number, and the scheduled payment amount corresponding to the scheduled transfer amount. There is. Note that the transfer reservation information may include information indicating the transfer source. In this case, the partner bank server 30 may include information indicating the transfer source in the payment schedule information and transmit it to the payment server 200.

Upon receiving the payment schedule information from the partner bank server 30, the payment server 200 refers to the information stored in the account information storage unit 221 and identifies the target person corresponding to the payment schedule information (step S52). ). For example, the payment server 200 searches for a recipient account number that matches the information target account number from among the recipient account numbers stored in the account information storage unit 221, and searches for a recipient account number that matches the information target account number, and By specifying the user ID, the target person (for example, service user UB) corresponding to the payment schedule information is specified.

Further, after specifying the target person, the payment server 200 provides the target person with the money payment schedule information by transmitting the money payment schedule information to the user terminal 10 of the specified target person (step S53). At this time, the payment server 200 requests the target person to use a prepayment service that pre-adds a predetermined amount of electronic money to the electronic wallet, along with payment schedule information including the scheduled payment date and scheduled payment amount. Provide link information to accept. Specifically, the payment server 200 transmits payment schedule information including link information (for example, link information LK) for accepting a request to use the prepayment service from the target person to the user terminal 10.

When the user terminal 10 receives the payment schedule information from the payment server 200, it notifies the service user UB, for example, by displaying the payment schedule information J-5 in a pop-up format through the payment application. The payment schedule information J-5 displays, for example, information that the salary will be received in two days, as well as link information LK for the service user UB to send a request to use the prepaid service to the payment server 200. .

Further, as shown in FIG. 14, the user terminal 10 has a usage request reception screen G5 for accepting a usage request for the prepaid service from the service user UB in response to the operation by the service user UB on the link information LK. Is displayed. For example, the user terminal 10 transmits a request to the payment server 200 to obtain information for displaying the usage request reception screen G5, according to the code written in the link information LK. The user terminal 10 then acquires the information sent from the payment server 100 as a response to the request, and displays the usage request reception screen G5 based on the acquired information.

In addition, the usage request reception screen G5 displayed on the user terminal 10 serves as a user interface that allows the service user UB to specify the prepayment amount to be added to the electronic wallet in advance when accepting the usage request for the prepayment service. Function. For example, the usage request reception screen G5 includes a prepayment amount specification area A5 for accepting an operation for specifying a prepayment amount from the service user UB, and a button B5 for transmitting a usage request for the prepayment service to the payment server 100. It is provided. The prepayment amount specification area A5 includes a slide bar that allows the service user UB to set the prepayment amount with an intuitive operation. The slide bar is configured to be movable according to the operation of the service user UB on a line connecting the minimum amount (for example, 0 yen) and the maximum amount (for example, 300,000 yen) that can be specified as the prepayment amount. When providing the usage request reception screen G5 to the service user UB, the payment server 100 sets the payment schedule included in the payment schedule information received from the partner bank server 30 as the maximum amount that can be specified as the prepayment amount. Set the amount automatically. Note that if the service user UB specifies the minimum amount as the prepayment amount, the payment server 200 determines that the service user UB has not specified the prepayment amount.

Note that the payment server 200 is not particularly limited to an example in which the expected payment amount is automatically set as the maximum amount that can be specified as the prepayment amount. For example, the payment server 200 may use a ratio set in advance by the provider of the prepayment service, and set the maximum amount to be the amount obtained by multiplying the expected payment amount by the ratio. Further, the payment server 200 may use the upper limit set in advance in the prepayment service. In this case, the payment server 200 may control the upper limit amount to be the highest amount even if the scheduled payment amount exceeds the upper limit amount. Furthermore, the payment server 200 may determine the maximum amount that can be specified as the advance payment amount based on the track record of salary receipt through the service user UB's receiving account. For example, the payment server 200 may determine the maximum amount to be the amount obtained by multiplying the scheduled payment amount by a percentage corresponding to the period of receiving salary through the receiving account. Further, the payment server 200 may determine the maximum amount that can be specified as the prepayment amount based on the payment history of the electronic payment service of the service user UB. For example, the payment server 200 may determine the average value of the payment amount for a predetermined period as the maximum amount. Further, when the payment server 200 collects a fee from the service user UB due to the use of the prepaid service, the payment server 200 may set the amount obtained by subtracting the fee from the scheduled amount to be received as the maximum amount.

When the user terminal 10 receives an operation on the button B5 provided on the usage request reception screen G5 from the service user UB, it transmits a request to use the prepaid service including the specification of the prepaid amount to the payment server 200 (step S54). ).

When the payment server 200 receives a request to use the prepayment service from the user terminal 10, it executes a prepayment process for the service user UB (step S55). For example, if the request to use a prepayment service includes a specification of a prepayment amount, the payment server 200 pre-adds electronic money equivalent to the specified amount to an electronic wallet held by the service user. On the other hand, if the prepayment usage request does not include the specification of the prepayment amount (if the amount specified as the prepayment amount is 0 yen), the payment server 200 sends the payment amount corresponding to the received amount in the distribution settings. Add electronic money in advance.

In this way, the payment server 200 according to the modified example aims to improve the convenience of services related to digital salary payment through the scheme for using the prepayment service shown in FIG.

Furthermore, upon receiving the payment schedule information, the payment server 200 checks whether the target user is registered to use the prepayment service, and if the target user is registered to use the prepayment service, the payment server 200 directly executes the prepayment process. You may. For example, the payment server 200 provides the target user with payment schedule information including link information for accepting changes to the prepaid amount. When the payment server 200 receives a request to change the prepayment amount from the target user, the payment server 200 sends electronic money in an amount equivalent to the change amount included in the change request to the electronic wallet owned by the target user in advance. Execute the prepayment process to add.

Further, for example, if a request to change the prepayment amount is not accepted from the target user, the payment server 200 checks whether there is a history of specifying the prepayment amount for the target user. If it is confirmed that there is a history of specifying the prepayment amount for the target user, the payment server 200 sends the e-wallet owned by the target user the previous payment amount. A prepayment process is executed in which an amount of electronic money corresponding to the amount specified at the time of prepayment is added in advance.

Further, for example, if it is confirmed that there is no history of specifying the prepayment amount for the target user, the payment server 200 may , performs a prepayment process that adds in advance an amount of electronic money equivalent to the amount to be received in the distribution settings.

In addition, in the prepayment process described above, the payment server 200 performs prepayment based on the collection history of the predetermined amount pre-added to the electronic wallet, the usage history of the electronic payment service, and the deposit history to the predetermined bank account (receiving account). It may be determined whether advance addition to an electronic wallet is to be performed for a service user who is a target of service-related processing.

For example, the payment server 200 may decide to perform advance addition (prepayment) to the electronic wallet on the condition that there are no problems with the collection history from the target service user UB. Specifically, for example, if there is a track record of debt collection by refund from service user UB after canceling the payment schedule for service user UB, payment server 200 sends payment to service user UB. You may also decide to pre-add (pre-pay) to your electronic wallet.

Further, the payment server 200 may decide to perform advance addition (prepayment) to the electronic wallet on the condition that there is no problem in the usage status of the electronic payment service by the target service user UB. Specifically, the payment server 200 may, for example, terminate the service if the service user UB has a predetermined number of payments or more within a predetermined period, or if a predetermined amount or more has been charged within a predetermined period. It may be decided to perform advance addition (prepayment) to the electronic wallet for the user UB.

Further, the payment server 200 may decide to perform advance addition (prepayment) to the electronic wallet on the condition that there is no problem with the payment status to the receiving account. Specifically, for example, if there is a record of continuous deposits from the same company to the receiving account corresponding to the service user UB, the payment server 200 sends the service user UB to the electronic wallet. It may be decided to carry out pre-addition (advance payment) of . In addition, to give another specific example, the payment server 200 may send money from the same company that is sending remittances to the service user UB among other service users who are using other prepayment services. If there is a service user who receives continuous remittances, it may be decided to perform advance addition (prepayment) to the electronic wallet for the service user UB. In addition, to give another specific example, the payment server 200 determines that the social credibility of a remittance source company that continuously sends remittances to the receiving account corresponding to the service user UB is relatively high. In this case, the service user UB may decide to make an advance addition (prepayment) to the electronic wallet. As an evaluation standard for social credibility, it is assumed that an index for evaluating a company's profitability, safety, productivity, etc. exceeds a predetermined standard.

In addition, when payment is made to the salary receiving account (predetermined bank account) assigned to the target user, the payment server 200 sends the payment in advance to the electronic wallet owned by the service user UB who is subject to processing related to the prepayment service. A collection process is executed to collect the added predetermined amount from the funds deposited in the receiving account. For example, the payment server 200 transfers an amount equivalent to a predetermined amount out of the funds deposited into the receiving account to a predetermined bank account linked to a business providing a prepayment service (for example, business UA shown in FIG. 1). Transfer or send money to. Further, the payment server 200 subtracts a predetermined pre-added (prepaid) amount from the funds deposited into the receiving account and adds the amount to the money balance of the service user UB's electronic wallet. In addition, if distribution settings are set, pre-addition to the e-wallet and distribution processing will be performed based on the amount after deducting the pre-added (pre-paid) predetermined amount based on the distribution settings. . In addition, the amount added to the money balance of the e-wallet, the amount that becomes the base amount when pre-adding to the e-wallet or performing the distribution process is the pre-added (pre-paid) amount and the fee associated with the use of the pre-payment service. It may be the amount after deducting the amount. That is, when the payment server 200 collects a predetermined amount pre-added to an electronic wallet owned by a service user who is subject to processing related to the prepayment service from the funds deposited in the receiving account, the payment server 200 charges a fee associated with the use of the prepayment service. may be collected together. Note that the fee may be a fixed amount agreed upon in advance when applying for the prepaid service, or may be an amount obtained by multiplying a predetermined amount added in advance by a fixed rate.

Note that the payment server 200 may extend the prepayment service to purposes other than pre-addition to an electronic wallet. For example, the payment server 200 may accept settings regarding advance remittance of electronic money to a predetermined bank account or advance remittance of electronic money to another user account from the service user UB. In this case, when the payment server 200 receives information on the scheduled payment to a predetermined bank account linked to the service user UB from the partner bank server 30, the payment server 200 sends the payment to the predetermined bank according to the settings regarding advance remittance of the service user UB. Execute advance transfer of electronic money to an account or advance transfer of electronic money to another user account.

(4-2-2. Information provision associated with implementation of prepaid services)
Hereinafter, an example of information provision accompanying implementation of the prepayment scheme will be described using FIG. 15. FIG. 15 is a diagram illustrating an overview of information provision accompanying implementation of a prepayment scheme according to a modification.

For example, upon receiving transfer reservation information from the bank server 20, the partner bank server 30 transmits it to the settlement server 200 as payment schedule information, as shown in FIG. 15 (step S61).

Upon receiving the payment schedule information from the partner bank server 30, the payment server 200 refers to the information stored in the account information storage unit 121 and identifies the target person corresponding to the payment schedule information (step S62). ).

Further, after specifying the target person, the payment server 200 refers to the information stored in the user information storage unit 124 and confirms whether or not the target person is registered for use of prepayment (step S63). At this time, if the target person is registered to use prepayment, the payment server 200 acquires information on the amount to be received from the allocation settings corresponding to the target person as prepayment information.

Then, the payment server 200 provides the target person with the payment schedule information by transmitting the payment schedule information including the prepayment information to the user terminal 10 (step S64).

When the user terminal 10 receives the payment schedule information from the payment server 100, it notifies the service user UB, for example, by displaying the payment schedule information J-6 in a pop-up format through the payment application. For example, as shown in FIG. 15, payment schedule information J-6 includes information that the salary will be received in two days, information J-6-1 indicating the scheduled amount to be received, and information J-6-1 indicating the scheduled amount to be paid in advance. Information J-6-2 is included. In this way, when the payment server 100 provides payment schedule information J-6 to the service user UB, the payment server 100 calculates the payment amount corresponding to the amount to be received that has been pre-added (or scheduled to be pre-added) to the electronic wallet by the prepayment service. Notify that the amount will be included. Thereby, the payment server 200 can make the service user UB grasp the amount to be received and the amount to be paid in advance at once.

Note that when providing the payment schedule information J-6 to the service user UB, the payment server 100 provides the payment schedule information J-6 to the service user UB if the prepayment execution timing has been reached. A prepayment process may be performed beforehand. In this case, the payment server 100 provides the service user UB with information indicating the prepaid amount (pre-added to the electronic wallet) instead of the information J-6-2 indicating the scheduled prepaid amount.

(4-2-3. Configuration of payment server according to modified example)
Next, the configuration of the payment server 200 according to a modification will be described using FIG. 16. FIG. 16 is a diagram illustrating a configuration example of a payment server 200 according to a modification. As shown in FIG. 16, the payment server 200 according to the modification includes a communication section 210, a storage section 220, and a control section 230.

The payment server 200 according to the modification has basically the same configuration as the payment server 100 according to the embodiment. That is, the communication unit 210 corresponds to the communication unit 210 included in the payment server 100 according to the embodiment. Furthermore, the storage unit 220 corresponds to the storage unit 120 included in the payment server 100 according to the embodiment. Further, the control unit 230 corresponds to the control unit 130 included in the payment server 100 according to the embodiment. The payment server 200 according to the modified example is different from the payment server 100 according to the embodiment in the following points.

The storage unit 220 includes an account information storage unit 221 , an allocation setting storage unit 222 , an allocation history storage unit 223 , a user information storage unit 224 , and a prepayment history storage unit 225 . The account information storage unit 221 according to the modification corresponds to the account information storage unit 121 according to the embodiment. Moreover, the distribution setting storage unit 222 according to the modification corresponds to the distribution setting storage unit 122 according to the embodiment. Furthermore, the distribution history storage section 223 according to the modification corresponds to the distribution setting storage section 123 according to the embodiment. Further, the user information storage unit 224 according to the modification corresponds to the user information storage unit 224 according to the embodiment.

The account information storage unit 221 according to the modification stores the same information as the account information storage unit 121 according to the embodiment. Further, the distribution setting storage unit 222 according to the modification stores the same information as the distribution setting storage unit 122 according to the embodiment. Further, the distribution history storage unit 123 according to the modification stores the same information as the distribution history storage unit 223 according to the embodiment. On the other hand, the user information storage unit 224 according to the modification stores information that is partially different from the information stored in the user information storage unit 124 according to the embodiment. FIG. 17 is a diagram illustrating an example of user information stored in the user information storage unit 124 according to a modification. As shown in FIG. 17, the user information stored in the user information storage unit 224 has an item of “prepayment”. The information differs from the personal information.

The "prepayment" item stores information indicating whether the service user has registered to use the prepayment service. Further, the "prepayment" item may store a specification history including information indicating a specified amount specified by the service user as the prepayment amount to be pre-added to the electronic wallet using the prepayment service.

Further, the prepayment history storage unit 225 according to the modification stores information regarding the usage history of the prepayment service by the service user. FIG. 18 is a diagram illustrating an example of information regarding the usage history of prepaid services stored in the prepaid history storage unit 225 according to the modification.

As shown in FIG. 18, the information related to the usage history of the prepaid service stored in the prepaid history storage unit 225 according to the modification includes items such as "user ID", "prepaid date", and "prepaid amount". It has multiple items such as . These items included in the information regarding the usage history of the prepaid service are correlated with each other.

The "user ID" item stores a user ID, which is unique identification information given to each service user in order to uniquely identify the service user in the electronic payment service.

The "prepayment date" item stores information indicating the date of prepayment performed for the corresponding service user by the prepayment service. The "prepayment amount" item stores information indicating the amount of electronic money pre-added to the electronic wallet of the corresponding service user through the prepayment service.

Further, as shown in FIG. 16, the control section 230 includes a reception section 231, a distribution processing section 232, a provision section 233, a prepayment section 234, and a collection section 235. The control unit 230 includes a prepayment unit 234 and a collection unit 235 as functional units for realizing information processing according to the modification.

The reception unit 231 has the same functions as the reception unit 131 according to the embodiment. In other words, the reception unit 231 selects a plurality of allocation destinations including an electronic wallet owned by the service user in the electronic payment service as a destination for the allocation of funds deposited into a predetermined bank account linked in advance to the service user. A distribution setting specifying a destination is received from the service user.

The distribution processing unit 232 has the same function as the distribution processing unit 132 according to the embodiment. That is, when the payment into a predetermined bank account is confirmed, the allocation processing unit 232 executes an allocation process to allocate the funds based on the allocation settings corresponding to the target service user.

The providing unit 233 has various functions related to information processing according to a modification in addition to the same functions as the providing unit 133 according to the embodiment. For example, when the provision unit 233 receives payment schedule information from the partner bank server 30, the provision unit 233 receives the payment schedule information as well as a request to use a prepayment service that pre-adds a predetermined amount of electronic money to an electronic wallet. link information (for example, link information LK shown in FIG. 14) is provided to the service user.

For example, when accepting a request to use a prepaid service, the providing unit 233 may request the service user to specify a prepaid amount to be pre-added to the electronic wallet within the range of the amount scheduled to be received for a predetermined bank account (receiving account). At the same time, a user interface (for example, usage request acceptance screen G5 shown in FIG. 14) is provided that can accept requests.

In addition, when providing scheduled payment information to the service user, the providing unit 233 may notify the service user that the scheduled payment amount includes an amount equivalent to the received amount pre-added to the electronic wallet by the prepayment service. good.

The prepayment unit 234 receives a notification of payment schedule information indicating a schedule for payment to a predetermined bank account linked to the service user in advance from a partner bank (for example, Bank Y shown in FIG. 1). (when the communication unit 210 receives payment schedule information from the affiliated bank server 30), in response to a request from a service user who is subject to processing related to prepayment services, payment is made to a predetermined bank account before payment is received. Next, in the electronic payment service, processing related to a prepayment service is executed in which a predetermined amount of electronic money is added in advance to the electronic wallet held by the service user.

For example, when there is a request to use a prepayment service through the link information described above, the prepayment unit 234 executes a prepayment process of adding a predetermined amount to the electronic wallet in advance. Further, for example, if the usage request received from the service user includes a specification of a prepayment amount, the prepayment unit 234 adds electronic money equivalent to the prepayment amount to the electronic wallet in advance. On the other hand, if the request to use the prepaid service does not include the specification of the prepaid amount, the prepayment unit 234 specifies the amount to be received in electronic money in the distribution settings of the service user who is subject to processing regarding the prepaid service. An amount of electronic money equivalent to the received amount is added to the electronic wallet in advance.

The prepayment unit 234 also determines the prepayment service based on the collection record of the amount equivalent to the received amount pre-added to the electronic wallet by the collection unit 235, the usage history of the electronic payment service, and the history of deposits into a predetermined bank account. It may be determined whether or not to perform advance addition to the electronic wallet for the service user who is the target of the process.

When there is a deposit into a predetermined bank account (receiving account), the collection unit 235 deposits a predetermined amount pre-added to an electronic wallet owned by a service user who is subject to processing related to the prepayment service into the predetermined bank account. recover from the received funds. In this case, the collection unit 235 adds electronic money equivalent to the amount after deducting a predetermined amount from the funds deposited in the receiving account to the electronic wallet owned by the service user UB. Note that the control unit 230 may include a processing unit separate from the collection unit 235 that executes a function of adding electronic money corresponding to the amount after collecting the predetermined amount to the wallet.

In addition, when collecting a predetermined amount pre-added to an electronic wallet owned by a service user who is subject to processing related to the prepayment service from funds deposited in a predetermined bank account, the collection unit 235 also performs prepayment service usage. The accompanying fees may also be recovered. In this case, the collection unit 235 provides the service user with electronic money equivalent to the amount after deducting a predetermined amount from the funds deposited in the receiving account and further deducting the fee associated with the use of the prepaid service. Add to the e-wallet owned by UB. Note that the control unit 230 may include a processing unit separate from the collection unit 235 that executes a function of adding electronic money corresponding to the amount after collecting the predetermined amount to the wallet.

(4-2-4. Processing procedure example related to modification)
Hereinafter, an example of a processing procedure of information processing executed by the payment server 200 according to a modification will be described. First, an example of the processing procedure of the prepayment process according to the modified example will be described using FIG. 19. FIG. 19 is a flowchart illustrating an example of a processing procedure of a prepayment process executed by the payment server 200 according to a modification. Note that the processing procedure shown in FIG. 19 is executed by the control unit 230 included in the payment server 200. The control unit 230 repeatedly executes the processing procedure shown in FIG. 19 while the payment server 200 is in operation.

As shown in FIG. 19, the providing unit 233 determines whether payment schedule information has been received from the partner bank server 30 (step S301).

When determining that the provision unit 233 has received the payment schedule information from the partner bank server 30 (step S301; Yes), the provision unit 233 selects the target user who is the target service user based on the received payment schedule information. is specified (step S302).

Further, the providing unit 233 determines whether or not there is a prepaid usage registration for the target user (step S303).

If the providing unit 233 determines that there is no registration for prepaid service for the specified target user (step S303; No), the providing unit 233 sends the specified target user a link information for receiving a request to use the prepaid service. Money schedule information is provided (step S304).

Further, the providing unit 233 determines whether a request to use the prepaid service has been received from the target user (step S305).

If the providing unit 233 determines that a request to use the prepaid service has been received from the target user (step S305; Yes), it is determined whether the request to use the service includes the specification of the prepaid amount (step S306). .

If the provision unit 233 determines that the service usage request includes the specification of the prepayment amount (step S306; Yes), the prepayment unit 234 charges the specified amount to the electronic wallet owned by the target user. A corresponding amount of electronic money is added in advance (step S307), and the processing procedure shown in FIG. 19 is ended.

On the other hand, if the providing unit 233 determines that the service usage request does not include the specification of the prepayment amount (step S306; No), the prepayment unit 234 sends the e-wallet owned by the target user An amount of electronic money corresponding to the received amount in the distribution setting is added in advance (step S308), and the processing procedure shown in FIG. 19 is ended.

In step S305 described above, if the providing unit 233 determines that it has not received a request to use the prepaid service from the target user (step S305; No), it ends the processing procedure shown in FIG. 19. For example, the providing unit 133 may preset a predetermined validity period in the link information LK included in the payment schedule screen G5 shown in FIG. It is possible to derive a determination result that the usage request is not accepted.

In step S303 described above, if the providing unit 233 determines that there is prepayment registration for the specified target user (step S303; Yes), the provision unit 233 performs prepayment processing for the registered user (see FIG. 20 described later). This is executed (step S309), and the processing procedure shown in FIG. 19 ends.

In step S301 described above, if the providing unit 233 determines that payment schedule information has not been received from the affiliated bank server 30 (step S301; No), it ends the processing procedure shown in FIG. 19.

Next, an example of a processing procedure for prepayment processing for a registered user according to a modification will be described. FIG. 20 is a flowchart illustrating an example of a processing procedure of prepayment processing for a registered user, which is executed by the payment server 200 according to the modification. Note that the processing procedure shown in FIG. 20 is executed by the control unit 230 included in the payment server 200. The control unit 230 repeatedly executes the processing procedure shown in FIG. 20 while the payment server 200 is in operation.

As shown in FIG. 20, the providing unit 233 provides the identified target user with payment schedule information including link information for accepting a change in the prepayment amount (step S401).

Further, the providing unit 233 determines whether a request to change the prepayment amount has been received from the target user (step S402).

If the provision unit 233 determines that the request to change the prepayment amount has been accepted from the target user (step S402; Yes), the provision unit 233 sends an amount corresponding to the change amount included in the change request to the electronic wallet owned by the target user. The amount of electronic money is added in advance (step S403), and the processing procedure shown in FIG. 20 is ended.

On the other hand, if the providing unit 233 determines that the request to change the prepayment amount has not been accepted from the target user (step S402; No), the provider 233 checks whether there is a history of specifying the prepayment amount for the target user (step S404).

If it is confirmed that there is a history of specifying the prepayment amount for the target user (step S404; Yes), the providing unit 233 refers to the designation history of the target user and sends the request to the electronic wallet owned by the target user. , an amount of electronic money corresponding to the amount specified at the time of the previous prepayment is added in advance (step S405), and the processing procedure shown in FIG. 20 is ended.

On the other hand, if it is confirmed that there is no history of specifying the prepayment amount for the target user (step S404; No), the providing unit 233 sends the received amount in the distribution setting to the electronic wallet owned by the target user. A corresponding amount of electronic money is added in advance (step S406), and the processing procedure shown in FIG. 20 is ended.

Next, an example of a procedure for collection processing according to the modification will be described. FIG. 21 is a flowchart illustrating a processing procedure example of a collection process executed by the payment server 200 according to the modification. Note that the processing procedure shown in FIG. 21 is executed by the control unit 230 included in the payment server 200. The control unit 230 repeatedly executes the processing procedure shown in FIG. 21 while the payment server 200 is in operation.

As shown in FIG. 21, the providing unit 233 determines whether payment schedule information has been received from the partner bank server 30 (step S501).

When determining that the provision unit 233 has received the payment schedule information from the partner bank server 30 (step S501; Yes), the provision unit 233 selects the target user who is the target service user based on the received payment schedule information. is specified (step S502).

The collection unit 235 also refers to the usage history of prepayments corresponding to the target user and checks whether there are any prepayments for which funds corresponding to the pre-addition have not been collected (step S503).

If it is confirmed that there is a prepayment for which the funds corresponding to the advance addition have not been collected for the target user (step S503; Yes), the collection unit 235 collects the funds from the target user's receiving account from the receiving account corresponding to the target user. The predetermined amount pre-added to the electronic wallet owned by is collected (step S504), and the processing procedure shown in FIG. 21 is ended.

On the other hand, if it is confirmed that there is no prepayment for which the funds corresponding to the pre-addition have not been collected for the target user (step S503; No), the collection unit 235 ends the processing procedure shown in FIG. 21.

In step S501 described above, if the providing unit 233 determines that the payment schedule information has not been received from the affiliated bank server 30 (step S501; No), it ends the processing procedure shown in FIG. 21.

Further, in the above-mentioned modification, the payment server 200 may limit the purpose of use of the money balance that is pre-added to the electronic wallet held by the service user (for example, the service user UB shown in FIG. 14). For example, the payment server 200 may allow the money balance pre-added to the electronic wallet to be used only for electronic payment (code payment) by an electronic payment service, and may not be used for other remittances. In this case, the control unit 230 manages the money balance pre-added by the prepayment service, distinguishing it from other balances, among the money balances recorded in the electronic wallet of the service user who uses the prepayment service.

(4-3. About system configuration)
In the embodiment described above, an example has been described in which the payment server 100 included in the information processing system SYS performs processing related to an electronic payment service and also performs processing related to a distribution service that distributes a service user's salary according to distribution settings. However, the configuration of the information processing system SYS according to the embodiment does not need to be particularly limited to such an example, and the server device that performs processing related to electronic payment service and the server device that performs processing related to distribution service are connected. , may be physically different individual servers, or may be server devices belonging to different systems. In this case, the respective server devices cooperate with each other and are communicably connected in a state where they can exchange information necessary for their respective processing.

Further, among the processes described in the above embodiments, all or part of the processes described as being performed automatically can be performed manually, and conversely, the processes described as being performed automatically can be performed manually. All or part of the processing can also be performed automatically using known methods. In addition, information including the processing procedures, specific names, and various data and parameters shown in the above documents and drawings may be changed arbitrarily, unless otherwise specified. For example, the various information shown in each figure is not limited to the illustrated information.

Further, each component of each device shown in the drawings is functionally conceptual, and does not necessarily need to be physically configured as shown in the drawings. In other words, the specific form of distributing and integrating each device is not limited to what is shown in the diagram, and all or part of the devices can be functionally or physically distributed or integrated in arbitrary units depending on various loads and usage conditions. Can be integrated and configured.

Furthermore, the embodiments described above can be combined as appropriate within a range that does not conflict with the processing contents.

[5. effect〕
As described above, the payment server 200 according to the modification is an information processing device that executes processing related to electronic payment services provided to users through an online system, and includes a prepayment unit 234. If the advance payment unit 234 receives a notification from a partner bank of payment schedule information indicating a schedule for payment to a predetermined bank account (salary receiving account) that is linked to the service user in advance, the prepayment unit 234 will not proceed with the use of the service. In response to a request from a user, the electronic payment service executes processing related to a prepayment service that pre-adds a predetermined amount of electronic money to the electronic wallet held by the service user before the money is deposited in the predetermined bank account. .

In this way, the payment server 200 according to the modification can propose a new option of prepayment to the service user as a receiving method when receiving at least a portion of the salary in electronic money. As a result, the payment server 200 according to the modified example does not require the company to conclude a contract with a prepayment provider, allows employees to use prepayment of salary, and improves the convenience of services related to digital salary payment. It is possible to improve the

Further, the payment server 200 according to the modification further includes a providing unit 233. The providing unit 233 provides the service user with link information for accepting a request to use a prepayment service that adds a predetermined amount of electronic money to an electronic wallet in advance, as well as payment schedule information. The prepayment unit 234 pre-adds a predetermined amount to the electronic wallet when there is a request to use the prepayment service through the link information. Thereby, the payment server 200 according to the modification can provide the service user with an opportunity to use the prepayment service when confirming the payment schedule.

Further, the payment server 200 according to the modified example includes a reception section 231 and a distribution processing section 232. The reception unit 231 receives allocation settings from the service user that specifies multiple allocation destinations including an electronic wallet as the allocation destination for funds deposited into a predetermined bank account linked to the service user in advance. accept. When the payment into a predetermined bank account is confirmed, the allocation processing unit 232 executes an allocation process to allocate the funds based on the allocation settings corresponding to the target service user. When accepting a request to use the prepayment service, the providing unit 233 provides a user interface that allows the service user to specify a prepayment amount to be pre-added to the electronic wallet within the range of the scheduled payment amount for a predetermined bank account. provide. The prepayment unit 234 pre-adds electronic money equivalent to the prepayment amount to the electronic wallet when the usage request received from the service user includes the specification of the prepayment amount, and if the usage request does not include the specification of the prepayment amount. In this case, an amount of electronic money corresponding to the received amount specified as the amount to be received in electronic money in the distribution setting is added to the electronic wallet in advance. Thereby, the payment server 200 according to the modification can provide the service user with an opportunity to flexibly and easily change the amount of electronic money received through the prepayment service.

In addition, the prepayment unit 234 sends information about the target service user to the e-wallet based on the collection history of the predetermined amount pre-added to the e-wallet, the usage history of the e-payment service, and the history of deposits into the predetermined bank account. Determine whether to perform pre-addition of . Thereby, the payment server 200 according to the modification can increase the possibility of debt collection for prepaid services.

Furthermore, the payment server 200 according to the modification further includes a collection unit 235. When there is a deposit into a predetermined bank account, the collection unit 235 collects a predetermined amount pre-added to the electronic wallet from the funds deposited into the predetermined bank account. Thereby, the payment server 200 according to the modified example can collect the debt generated due to prepayment from the service user, and can operate the prepayment service as a sustainable scheme.

Furthermore, when collecting a predetermined amount from funds, the collection unit 235 also collects a fee associated with the use of the prepaid service. Thereby, the payment server 200 according to the modification can operate the prepayment service in a sound manner.

In addition, the collection unit 235 adds electronic money to the electronic wallet equal to the amount after subtracting the predetermined amount added to the electronic wallet in advance from the funds deposited into the specified bank account.

In addition, the collection unit 235 adds electronic money to the electronic wallet, which is equivalent to the amount after subtracting the predetermined amount from the funds and further deducting the fee associated with the use of the prepayment service.

In addition, when providing the scheduled payment information to the service user, the providing unit 233 includes a predetermined amount that has been pre-added to the electronic wallet by the prepayment service in the scheduled payment amount included in the scheduled payment information. Notify that the amount is included. Thereby, the payment server 200 according to the modified example can make the service user grasp the scheduled amount to be received and the amount to be paid in advance at once.

[6. Hardware configuration]
Further, the payment server 200 according to the modification described above is realized by, for example, a computer 1000 having a configuration as shown in FIG. 22. FIG. 22 is a hardware configuration diagram showing an example of a computer that implements the functions of the payment server 200 according to the modification.

Computer 1000 has CPU 1100, RAM 1200, ROM 1300, HDD 1400, communication interface (I/F) 1500, input/output interface (I/F) 1600, and media interface (I/F) 1700.

CPU 1100 operates based on a program stored in ROM 1300 or HDD 1400, and controls each part. The ROM 1300 stores a boot program executed by the CPU 1100 when the computer 1000 is started, programs depending on the hardware of the computer 1000, and the like.

The HDD 1400 stores programs executed by the CPU 1100, data used by the programs, and the like. Communication interface 1500 receives data from other devices via communication network 500 (corresponding to network N in the embodiment) and sends it to CPU 1100, and also sends data generated by CPU 1100 to other devices via communication network 500. Send to device.

The CPU 1100 controls output devices such as a display and printer, and input devices such as a keyboard and mouse via an input/output interface 1600. CPU 1100 obtains data from an input device via input/output interface 1600. Further, CPU 1100 outputs the generated data to an output device via input/output interface 1600.

Media interface 1700 reads programs or data stored in recording medium 1800 and provides them to CPU 1100 via RAM 1200. CPU 1100 loads this program from recording medium 1800 onto RAM 1200 via media interface 1700, and executes the loaded program. The recording medium 1800 is, for example, an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable disk), a magneto-optical recording medium such as an MO (Magneto-Optical disk), a tape medium, a magnetic recording medium, or a semiconductor memory. etc.

For example, when the computer 1000 functions as the payment server 200 according to the modified example, the CPU 1100 of the computer 1000 realizes the functions of the control unit 230 by executing a program loaded onto the RAM 1200. That is, CPU 1100 realizes processing by payment server 200 according to the modification in cooperation with a program (for example, an information processing program) loaded onto RAM 1200. Further, each data in the storage device of the payment server 100 is stored in the HDD 1400. The CPU 1100 of the computer 1000 reads these programs from the recording medium 1800 and executes them, but as another example, these programs may be acquired from another device via a predetermined communication network.

[7. others〕
Some of the embodiments of the present application have been described above in detail based on the drawings, but these are merely examples, and various modifications and variations may be made based on the knowledge of those skilled in the art, including the embodiments described in the disclosure section of the invention. It is possible to carry out the invention in other forms with modifications.

Furthermore, the configuration of the payment server 100 described above can be changed flexibly, such as implementing some functions by calling an external platform using an API (Application Programming Interface), network computing, or the like.

Further, the "unit" described in the claims can be read as "means", "circuit", etc. For example, the control section can be read as a control means or a control circuit.

SYS Information processing system 10 User terminal 20 Bank server 30 Partner bank server 100, 200 Settlement server 110, 210 Communication section 120, 220 Storage section 121, 221 Account information storage section 122, 222 Distribution setting storage section 123, 223 Transfer Minute history storage unit 124, 224 User information storage unit 130, 230 Control unit 131, 231 Reception unit 132, 232 Distribution processing unit 133, 233 Providing unit 234 Prepayment unit 235 Collection unit

Claims (11)

An information processing device that executes processing related to electronic payment services provided to users through an online system,
Processing of a prepayment service in which a predetermined amount of electronic money is pre-added to an electronic wallet held by the user in the electronic payment service before the money is received in a predetermined bank account linked to the user in advance. a prepaid section to carry out ;
a providing unit that provides the user with a usage request reception screen for accepting a usage request for the prepayment service when receiving payment schedule information indicating a scheduled payment for the predetermined bank account from the affiliated bank;
has
The prepaid department is
The information processing apparatus is characterized in that the processing of the prepaid service is executed on the condition that a request to use the prepaid service is accepted from the user through the usage request reception screen . The provision department is
providing the user with the payment schedule information including link information for displaying the usage request reception screen on the user's terminal device;
The prepaid department is
When a request to use the prepaid service is received through the request acceptance screen displayed on the terminal device in response to the user's operation on the link information, a predetermined amount is pre-added to the electronic wallet. The information processing device according to claim 1. a reception unit that receives allocation settings from the user specifying a plurality of allocation destinations including the electronic wallet as allocation destinations for funds deposited into a predetermined bank account linked to the user in advance; ,
further comprising an allocation processing unit that executes an allocation process to allocate the funds based on the allocation settings corresponding to the target user when the deposit into the predetermined bank account is confirmed;
The provision department is
When accepting a request to use the prepayment service, a user interface is provided that allows the user to specify a prepayment amount to be pre-added to the electronic wallet within the range of the amount scheduled to be received in the predetermined bank account. ,
The prepaid department is
If the usage request received from the user includes the specification of the prepayment amount, electronic money equivalent to the prepayment amount is added to the electronic wallet in advance, and the usage request does not include the specification of the prepayment amount. 3. The information processing apparatus according to claim 2, wherein, in the case where the electronic money is received in the distribution setting, an amount of electronic money corresponding to the received amount specified as the amount to be received in electronic money is added to the electronic wallet in advance. The prepaid department is
Based on the collection history of the predetermined amount pre-added to the e-wallet, the usage history of the e-payment service, and the history of deposits into the predetermined bank account, advance payment to the e-wallet is made for the target user. The information processing device according to claim 1, wherein the information processing device determines whether or not to perform addition. 2. The electronic wallet according to claim 1, further comprising a collection unit that recovers the predetermined amount pre-added to the electronic wallet from the funds deposited into the predetermined bank account when there is a deposit into the predetermined bank account. The information processing device described. The collection section is
The information processing device according to claim 5, wherein when the predetermined amount is collected from the funds, a fee associated with the use of the prepayment service is also collected. The collection section is
The information processing device according to claim 5, wherein electronic money corresponding to an amount after deducting the predetermined amount from funds deposited in the predetermined bank account is added to the electronic wallet. The collection section is
According to claim 7, electronic money corresponding to the amount after further subtracting a fee associated with the use of the prepayment service from the amount after subtracting the predetermined amount from the funds is added to the electronic wallet. information processing equipment. The provision department is
When providing the scheduled deposit information to the user, the scheduled deposit amount included in the scheduled deposit information includes an amount equivalent to the predetermined amount pre-added to the electronic wallet by the prepayment service. The information processing device according to claim 2, further comprising a notification that the information processing device is included. An information processing method performed by a computer that executes processing related to electronic payment services provided to users through an online system,
Processing related to a prepayment service in which a predetermined amount of electronic money is pre-added to an electronic wallet held by the user in the electronic payment service before the money is received in a predetermined bank account linked to the user in advance. a prepayment process to be carried out ;
a providing step of providing the user with a usage request reception screen for accepting a request to use the prepayment service, when payment schedule information indicating a schedule for deposit to the predetermined bank account is received from the affiliated bank;
including;
The prepayment process is
Processing of the prepaid service is performed on the condition that a request to use the prepaid service is accepted from the user through the usage request reception screen.
An information processing method characterized by: Computers that perform processing related to electronic payment services provided to users through online systems,
Processing related to a prepayment service in which a predetermined amount of electronic money is pre-added to an electronic wallet held by the user in the electronic payment service before the money is received in a predetermined bank account linked to the user in advance. the prepayment steps to be taken ;
a provision step of providing the user with a usage request reception screen for accepting a usage request for the prepayment service when receiving payment schedule information indicating a scheduled payment for the predetermined bank account from the affiliated bank;
run the
The prepayment procedure is as follows:
An information processing program that executes processing of the prepaid service on the condition that a request to use the prepaid service is accepted from the user through the usage request reception screen .

Images