JP7830573B2 - Deposit system, deposit methods, and program - Google Patents

Description

This disclosure pertains to deposit systems, deposit methods, and programs.

Conventionally, technologies for promoting a cashless society through electronic payment methods (e.g., electronic money or cryptocurrency) are known. For example, Patent Document 1 describes a financial infrastructure system that, in the event of a legal amendment in Japan allowing the payment of employee salaries through deposits into electronic money, can accommodate such amendment by utilizing a base money system that allows deposits into conventional electronic money.

Japanese Patent Publication No. 2021-043873

In the technologies described above, deposits to electronic payment methods may be made based on bank transfers where the user's account number is specified as the recipient. Taking the salary payment described in Patent Document 1 as an example, when an employer (a company) makes a bank transfer specifying an employee's account number as the recipient, the funds may be deposited into the employee's electronic money account. Such transfers include not only salary payments but also non-salary payments (e.g., advances), so it is necessary to distinguish between these and manage electronic money appropriately. This point is not limited to digital salary payments and electronic money as described in Patent Document 1, but also applies to transfers other than salaries and electronic payment methods in general.

One of the purposes of this disclosure is to ensure that appropriate payments are made to users' electronic payment methods.

The deposit system relating to this disclosure includes: a transfer information acquisition unit that acquires transfer information indicating the type of transfer in a transfer where the user's account number is designated as the recipient; a necessity determination unit that determines whether a deposit to the user's electronic payment method is necessary based on the transfer type indicated by the transfer information; and a deposit execution unit that, if the necessity determination unit determines that the deposit is necessary, executes the deposit according to the transfer amount in the transfer.

According to this disclosure, appropriate deposits can be made to the user's electronic payment method.

This figure shows an example of the hardware configuration of the deposit system in the first embodiment. This figure shows an example of the overview of the deposit system in the first embodiment. This figure shows an example of the procedure that a user who wishes to receive digital payroll in the first embodiment would follow. This figure shows an example of the procedure that a user who wishes to receive digital payroll in the first embodiment would follow. This diagram shows an example of an electronic money balance. This figure shows an example of the functions implemented in the deposit system of the first embodiment. This is a diagram showing an example of an electronic money database. This figure shows an example of a workplace database. This is a diagram showing an example of a bank transfer database. This figure shows an example of a virtual account database. This figure shows an example of the processing performed in the deposit system of the first embodiment. This figure shows an example of the processing performed in the deposit system of the first embodiment. This figure shows an example of the system configuration in the second embodiment. This figure shows an example of the overview of the deposit system in the second embodiment. This figure shows an example of the functions implemented in the deposit system of the second embodiment. This figure shows an example of a vendor database. This figure shows an example of the processing performed in the deposit system of the second embodiment. This figure shows an example of the processing performed in the deposit system of the second embodiment. This figure shows an example of the function in a modified example. This figure shows an example of a notification regarding the execution of a designated account transfer process. This figure shows an example of a balance management screen. This figure shows an example of a notification sent to the remitter during a bank transfer. This figure shows an example of a notification prompting you to use your balance.

[1. First Embodiment]
A first embodiment, which is an example of an embodiment of the deposit system, deposit method, and program related to this disclosure, will be described.

[1-1. Hardware configuration of the deposit system in the first embodiment]
Figure 1 shows an example of the hardware configuration of the deposit system in the first embodiment. For example, the deposit system 1 is connected to a network N such as the Internet or a LAN. In the first embodiment, the workplace system 2, the financial institution system 3, and the user terminal 40 are also connected to the network N. Any computer can be connected to the network N. The computers connected to the network N are not limited to the example in Figure 1.

For example, the deposit system 1 includes a deposit server 10. The deposit server 10 is a server computer of a business operator handling electronic payment methods. In the first embodiment, electronic money (digital money) is described as an example of an electronic payment method, but the payment method itself can be of any type and is not limited to electronic money. For example, the payment method may be a prepaid payment method not called electronic money, cryptocurrency, account, wallet, credit card, debit card, points, or other means.

Hereafter, businesses that handle electronic money will be referred to as electronic money businesses. For example, an electronic money business is a company that manages and operates electronic money. In the following explanation, where "electronic money" is mentioned, it can be interpreted as any payment method that allows deposits. For example, a payment method has the concept of a balance. Since credit cards, debit cards, and points are not depositable, where "electronic money" is mentioned, it can be interpreted as a prepaid payment method, cryptocurrency, account, wallet, or other depositable payment method.

For example, the deposit server 10 includes a control unit 11, a storage unit 12, and a communication unit 13. The control unit 11 includes at least one processor. The storage unit 12 includes at least one of volatile memory such as RAM and non-volatile memory such as flash memory. The communication unit 13 includes at least one of a communication interface for wired communication and a communication interface for wireless communication.

Furthermore, the program stored in the storage unit 12 may be supplied to the deposit server 10 via the network N. Alternatively, the program stored on a computer-readable information storage medium may be supplied to the deposit server 10 via a reading unit that reads the information storage medium (e.g., an optical disc drive or memory card slot), or via an input/output unit for data input/output with external devices (e.g., a USB port).

Furthermore, the deposit system 1 only needs to include at least one computer and is not limited to the example in Figure 1. For example, the deposit system 1 may include the deposit server 10 and other server computers. The deposit system 1 may also include other computers besides the server computer, such as a personal computer, tablet, or smartphone. The deposit system 1 may also include only other computers besides the server computer, without including a server computer.

The Workplace System 2 is the system for the workplace of a user who uses electronic money. In the first embodiment, a company is described as an example of a workplace, but the workplace is not limited to a company; it can be any entity that pays the user's salary. For example, the workplace may be a sole proprietorship, a local government, a non-profit corporation, or other organization. For example, Workplace System 2 includes a Workplace Server 20 and a Workplace Terminal 24. Note that Workplace System 2 only needs to include at least one computer and is not limited to the example in Figure 1. This point is the same as with the Deposit System 1.

For example, the workplace server 20 is a server computer at the workplace. The workplace server 20 includes a control unit 21, a storage unit 22, and a communication unit 23. The hardware configurations of the control unit 21, storage unit 22, and communication unit 23 may be the same as those of the control unit 11, storage unit 12, and communication unit 13, respectively. The program stored in the storage unit 22 may be supplied to the workplace server 20 via a network N or an information storage medium.

For example, the workplace terminal 24 is the computer of the person in charge of payroll processing at the workplace. The workplace terminal 24 is a personal computer, smartphone, or tablet. The workplace terminal 24 includes a control unit 25, a storage unit 26, a communication unit 27, an operation unit 28, and a display unit 29. The hardware configurations of the control unit 25, storage unit 26, and communication unit 27 may be the same as those of the control unit 11, storage unit 12, and communication unit 13, respectively. The operation unit 28 is an input device such as a keyboard, mouse, or touch panel. The display unit 29 is a display such as a liquid crystal or organic EL. The program stored in the storage unit 26 may be supplied to the workplace terminal 24 via a network N or an information storage medium.

The financial institution system 3 is a system for a financial institution. In the first embodiment, a bank is described as an example of a financial institution, but the financial institution can be any type and is not limited to a bank. For example, the financial institution may be a credit union, securities company, cooperative, labor bank, or other institution. For example, the financial institution system 3 includes a financial institution server 30. Note that the financial institution system 3 only needs to include at least one computer and is not limited to the example in Figure 1. This point is the same as with the deposit system 1.

For example, the financial institution server 30 is a server computer for a financial institution. The financial institution server 30 includes a control unit 31, a storage unit 32, and a communication unit 33. The hardware configurations of the control unit 31, storage unit 32, and communication unit 33 may be the same as those of the control unit 11, storage unit 12, and communication unit 13, respectively. The program stored in the storage unit 32 may be provided to the financial institution server 30 via a network N or an information storage medium.

The user terminal 40 is the user's computer. For example, the user terminal 40 may be a personal computer, smartphone, tablet, or wearable device. Although only one user terminal 40 is shown in Figure 1, there may be multiple user terminals 40 for each user. For example, the user terminal 40 includes a control unit 41, a storage unit 42, a communication unit 43, an operation unit 44, and a display unit 45. The hardware configurations of the control unit 41, storage unit 42, communication unit 43, operation unit 44, and display unit 45 may be the same as those of the control unit 11, storage unit 12, communication unit 13, operation unit 28, and display unit 29, respectively. The program stored in the storage unit 42 may be provided to the user terminal 40 via a network N or an information storage medium.

[1-2. Overview of the deposit system in the first embodiment]
Figure 2 shows an example of an overview of the deposit system 1 in the first embodiment. In the first embodiment, the deposit system 1 enables digital salary payments to users by coordinating with a financial institution system 3 that receives salary transfer requests from the employer system 2. For example, a user who wishes to receive a digital salary payment performs a predetermined procedure from a payment application installed on the user terminal 40. The payment application is an application provided by an electronic money provider (for example, a so-called smartphone application).

Figures 3 and 4 illustrate an example of the procedure performed by a user who wishes to receive their salary digitally in the first embodiment. For example, when the payment application is launched on the user terminal 40, the user terminal 40 displays the payment application screen SC1 on the display unit 45. When the user has the payment terminal at the electronic money merchant read code C10, the payment is executed based on the payment method pre-set as the payment source. In the example in Figure 3, the user has set electronic money as the payment source. The user can change the payment source to another payment method, such as a credit card.

In the first embodiment, online electronic money is used as an example, but electronic money can be of any type and is not limited to online. For example, electronic money may be a type in which balance information is written to the IC chip of the user terminal 40, a type in which balance information is written to the IC card, a type in which balance information is written to the magnetic card, a type that is completed solely by biometric authentication such as facial recognition, or other types.

For example, when the user selects button B11, the user terminal 40 displays the details of the digital salary payment procedure on the payment application screen SC1, as shown in the upper right of Figure 3. When the user selects button B12, the user terminal 40 displays a balance management screen (modification example 2 described later) for managing the electronic money balance on the display unit 45. In the first embodiment, we use the example of a user performing procedures for opening a virtual account at a financial institution and registering a designated account from the payment application; however, these procedures may be performed by someone other than the user, such as their employer.

A virtual account is an account specifically for receiving transfers. In other words, a virtual account is an account for receiving transfers. Virtual accounts are sometimes called temporary accounts. For example, a virtual account may not have a balance concept, or its balance may be fixed at a predetermined value (e.g., 0 yen). A virtual account is associated with a parent account. The parent account is the account into which cash is deposited for transfers to the virtual account. The parent account may have a balance concept, or its balance may not be fixed at a predetermined value (e.g., 0 yen). A parent account is similar to a regular physical account except for the fact that it is associated with a virtual account. A virtual account may also have a withdrawal function.

The designated account is a real account, distinct from the virtual account. For example, the account holder of the designated account is the user. The designated account is used to transfer funds that the user cannot receive directly in the digital salary payment system of the first embodiment. The designated account may be at the same financial institution where the virtual account was opened, or it may be at a different financial institution. The user can designate an account at any financial institution as the designated account.

For example, when the user selects button B13, the user terminal 40 launches a browser and displays the financial institution screen SC2, which shows the financial institution's website, on the display unit 45, as shown in the lower left of Figure 3. The financial institution screen SC2 displays information necessary for opening a virtual account, such as the user's name, date of birth, and address. When the user selects button B20, the virtual account opening is completed. As shown in the lower right of Figure 3, the user terminal 40 displays a message on the financial institution screen SC2 indicating that the virtual account opening is complete. The user can also modify the information by selecting button B21. The procedure for opening a virtual account itself may be the same as a publicly known procedure.

For example, when the payment app screen SC1 is in the upper right corner and the user selects button B14, the user terminal 40 displays input form F15 on the payment app screen SC1, as shown on the left side of Figure 4, to accept input information about the designated account. The user specifies the designated account by entering the financial institution name (financial institution code), branch name (branch code), account type, account number, and account holder's name into input form F15. Once the user has entered the necessary information into input form F15 and selected button B16, the registration of the designated account is completed. Upon completion of the designated account registration, the user terminal 40 displays a message on the payment app screen SC1 indicating that the registration of the designated account is complete, as shown on the right side of Figure 4.

Returning to Figure 2, the user requests the person in charge of payroll at their workplace to register the virtual account they issued as the recipient of the payroll. The person in charge operates the workplace terminal 24 to register the user's payroll recipient information with the workplace server 20. When the time comes to execute the payroll transfer, the workplace server 20 outputs FB (Firm Banking) data. The payroll transfer itself may be executed by a publicly known process. Note that IB (Internet Banking) data may be used instead of FB data. The following explanation uses FB data as an example.

For example, FB data includes a header record, data record, trailer record, and end record. The format of the FB data may be a known format. The FB data includes the transfer type. In the first embodiment, a transfer type of "21" means a general transfer. A transfer type of "11" means a salary transfer. A transfer type of "12" means a bonus transfer. The numerical value indicated by the transfer type may have a predetermined meaning and is not limited to the example of the first embodiment. The FB data also includes other information such as the remitter's name, transfer date, source information, recipient information, and transfer amount.

For example, the employer server 20 transmits FB data to the financial institution server 30. The financial institution server 30 receives the FB data from the employer server 20. The financial institution server 30 executes the transfer based on the FB data. The transfer based on the FB data may be executed by a known process. In the first embodiment, since the user specifies a virtual account as the transfer destination, the user's salary is deposited into a parent account managed by the electronic money service provider.

For example, the deposit server 10 uses an API to obtain transfer information related to salary transfers subject to digital salary payment from the financial institution server 30. The transfer information includes all or part of the FB data. For example, the transfer information shows the remitter's name (remitter name), the recipient, the type of transfer, and the transfer amount. If the remitter's name is different from the remitter name, both the remitter's name and the remitter name may be included in the transfer information. This disclosure describes the case where both the remitter's name and the remitter name are the user's employer. The transfer information may show the details of a transfer that is executed immediately, or it may show the details of a transfer that is scheduled for the future. Also, the transfer information may remain as FB data, or it may be converted to another format. If the transfer information is converted to another format, additional information may be added to the transfer information. For example, information on whether or not the cash has been deposited into the account may be added to the transfer information. In the case of the second embodiment described later, information on whether or not the cash has been deposited into the account is not added to the transfer information.

In the first embodiment, the deposit server 10 executes the deposit to the electronic money account if the transfer type is salary transfer or bonus transfer. If the transfer type is not salary transfer or bonus transfer (for example, if the transfer type is a general transfer, or if no transfer type is specified), the deposit server 10 executes the transfer to the designated account. If a transfer of expenses other than salary, such as advance payments, is executed, the transfer type becomes a general transfer. The transfer type may also not be specified.

Figure 5 shows an example of an electronic money balance. In the first embodiment, the electronic money has a first balance for digital salary payments and a second balance different from the first balance. The first balance has an upper limit set. In the first embodiment, the upper limit is given as an example of 100,000 yen, but the upper limit can be any value and is not limited to the example of the first embodiment. For example, the upper limit may be specified by the user. The first balance is withdrawable. The second balance may be the same as the balance of conventional electronic money. The second balance may be withdrawable or restricted from being withdrawn.

Hereafter, the first balance will be referred to as the salary balance, and the second balance as the non-salary balance. In the first embodiment, it is assumed that the electronic money balance consists of a basic balance that cannot be withdrawn and a premium balance that can be withdrawn. For example, when electronic money is charged based on the credit card's shopping limit, the basic balance (15,000 yen in the example in Figure 5) increases. When electronic money is charged based on the credit card's cash advance limit, online shopping mall sales, or cryptocurrency, the premium balance (10,000 yen in the example in Figure 5) increases. The salary balance (50,000 yen in the example in Figure 5) is classified as the premium balance.

For example, if the transfer type is salary transfer or bonus transfer, and the salary amount deposited into the salary balance does not exceed the upper limit, the deposit server 10 deposits the entire transfer amount into the salary balance. If the transfer type is salary transfer or bonus transfer, and the salary amount deposited into the salary balance would exceed the upper limit, the deposit server 10 deposits the portion of the transfer amount that does not exceed the upper limit into the salary balance, and transfers the amount exceeding the upper limit to the designated account. If the transfer type is neither salary transfer nor bonus transfer, the deposit server 10 transfers the entire transfer amount to the designated account.

For example, suppose users U1 through U3, each employees of a certain company, have each completed the procedure for digital salary payment. Let's assume the salary balance limit is 100,000 yen. User U1's current salary balance is 20,000 yen. Let's assume the transfer type for user U1 is a salary transfer. Let's assume the transfer amount is 30,000 yen. In this case, adding the 30,000 yen transfer amount to user U1's current salary balance of 20,000 yen does not exceed the limit. Therefore, the entire 30,000 yen transfer amount will be deposited into user U1's salary balance.

For example, suppose user U2's current salary balance is 80,000 yen. Suppose the type of transfer made to user U2 is a bonus transfer. Suppose the transfer amount is 50,000 yen. In this case, adding the 50,000 yen transfer amount to user U2's current salary balance of 80,000 yen exceeds the upper limit. Therefore, 20,000 yen (part of the transfer amount) is deposited into user U2's salary balance to bring it up to the upper limit. The remaining 30,000 yen (the amount exceeding the upper limit) is deposited into user U2's designated account.

For example, suppose user U3's current salary balance is 50,000 yen. Suppose the transfer type for user U3 is a general transfer. Suppose the transfer amount is 60,000 yen. In this case, since the transfer type is neither a salary transfer nor a bonus transfer, the deposit to user U3's salary balance will not be executed. Regardless of user U3's current salary balance, the entire transfer amount will be deposited into user U3's designated account.

As described above, the deposit system 1 of the first embodiment determines whether a deposit is necessary to the electronic money salary balance based on the transfer type. If the deposit system 1 determines that a deposit to the salary balance is necessary, it executes the deposit to the salary balance. If the deposit system 1 determines that a deposit to the salary balance is unnecessary, it executes a transfer to the designated account. This allows the deposit system 1 to execute appropriate deposits to the user's electronic money. The details of the deposit system 1 will be described below.

[1-3. Functions realized in the deposit system of the first embodiment]
Figure 6 shows an example of the functions implemented in the deposit system 1 of the first embodiment. Figure 4 also shows examples of the functions implemented in the workplace system 2, the financial institution system 3, and the user terminal 40, respectively.

[1-3-1. Functions implemented in the deposit system]
For example, the deposit server 10 includes a data storage unit 100, a transfer information acquisition unit 101, a necessity determination unit 102, an upper limit determination unit 103, a deposit execution unit 104, and a designated account transfer unit 105. The data storage unit 100 is implemented by a storage unit 12. The transfer information acquisition unit 101, the necessity determination unit 102, the upper limit determination unit 103, the deposit execution unit 104, and the designated account transfer unit 105 are implemented by a control unit 11.

[Data Storage Unit]
The data storage unit 100 stores the data necessary for depositing funds into electronic money. For example, the data storage unit 100 stores the electronic money database DB1.

Figure 7 shows an example of the electronic money database DB1. The electronic money database DB1 is a database that stores various information related to electronic money. For example, the electronic money database DB1 stores user ID, balance information, history information, virtual account information, and designated account information. The electronic money database DB1 only needs to store some kind of information related to electronic money; the information stored in the electronic money database DB1 is not limited to the example in Figure 7. For example, a temporary ID included in code C10 may be stored in the electronic money database DB1.

A User ID is an example of user identification information that can identify a user. Therefore, wherever "User ID" is written, it can be interpreted as "User Identification Information." User identification information is not limited to a User ID; it may be other information besides the User ID. For example, user identification information may be an email address, a phone number, or a temporary ID included in code C10. User identification information can be any information that can identify a user in some way. User identification information can also be defined as electronic money identification information that can identify electronic money.

Balance information refers to information indicating the balance of electronic money. In the first embodiment, the balance information shows the salary balance, the premium balance among the non-salary balances, and the basic balance among the non-salary balances. Hereafter, when these three balances are not distinguished, they will simply be referred to as the balance. The balance information is updated when a deposit is made to the electronic money. The balance information is also updated when the electronic money is used.

History information shows the history of both electronic money deposits and usage. For example, history information shows at least one of the following: the date and time of electronic money deposit, the deposit method, the deposit type, the deposit amount, and the balance after the deposit. History information also shows at least one of the following: the date and time of electronic money usage, the usage location, the usage amount, the balance after usage, and the usage location. History information is updated when electronic money is deposited. History information is also updated when electronic money is used.

Virtual account information is information that identifies a user's virtual account. For example, virtual account information may include all or part of the financial institution code, financial institution name, branch code, branch name, account type, account number, and account holder name of the virtual account. Virtual account information may also indicate the parent account associated with the virtual account. In the first embodiment, when the user completes the procedure shown in Figure 3, the deposit server 10 obtains the virtual account information from the financial institution server 30 or the user terminal 40. The deposit server 10 stores the virtual account information in the electronic money database DB1 so that it is associated with the user's user ID.

The designated account information is information that identifies the user's designated account. For example, the designated account information includes all or part of the financial institution code, financial institution name, branch code, branch name, account type, account number, and account holder name of the designated account. In the first embodiment, when the user completes the procedure shown in Figure 4, the deposit server 10 generates the designated account information based on the information entered by the user in input form F15. The deposit server 10 stores the designated account information in the electronic money database DB1 so that it is associated with the user's user ID.

Furthermore, the data storage unit 100 can store any data. The data stored in the data storage unit 100 is not limited to the electronic money database DB1. For example, the data storage unit 100 may store data necessary for the user to perform the procedures shown in Figures 3 and 4. The data storage unit 100 only needs to store data necessary for the processing executed by the deposit server 10 (for example, the upper limit of the salary balance).

[Transfer Information Acquisition Department]
The transfer information acquisition unit 101 acquires transfer information indicating the type of transfer in a transfer where the user's account number is specified as the recipient. In the first embodiment, the transfer information acquisition unit 101 acquires transfer information from the financial institution system 3 of a financial institution. The transfer information indicates at least the type of transfer. The transfer information may indicate only the type of transfer. The transfer information acquisition unit 101 can acquire transfer information at any time. For example, the transfer information acquisition unit 101 may acquire transfer information from the financial institution system 3 each time the financial institution system 3 accepts a transfer to a specific account. The transfer information acquisition unit 101 may also acquire transfer information from the financial institution system 3 when a predetermined date and time (for example, the user's payday at their workplace, or a day before payday) arrives.

For example, the deposit server 10 periodically or irregularly queries the financial institution system 3 to determine whether a transfer has been made to the user's virtual account. Upon receiving the query from the deposit server 10, the financial institution system 3 determines whether a transfer has been made to the user's virtual account based on the transfer database DB 3 (described later). If the financial institution system 3 determines that a transfer has been made to the user's virtual account, it generates transfer information. The financial institution system 3 then transmits the transfer information to the deposit server 10. The transfer information acquisition unit 101 retrieves the transfer information from the financial institution system 3. If the financial institution system 3 determines that no transfer has been made to the user's virtual account, it informs the deposit server 10 of this fact.

For example, when multiple users' account numbers are specified as recipients for transfers executed simultaneously, the transfer information acquisition unit 101 identifies the transfer type for each of the transfers. In the first embodiment, the user's account number is the user's virtual account number at the financial institution. The virtual account numbering system is the same as that of a regular physical account. In the example of the virtual account in Figure 3, the virtual account is opened under a branch name that can identify electronic money, such as "AAA Cash Branch," but the virtual account may also be opened under a regular branch.

In the first embodiment, when a user's virtual account number is specified as the recipient for a transfer, the cash is transferred to the parent account associated with the virtual account. The transfer process to the parent account is executed by the financial institution server 30. This process itself may be a process used in publicly known virtual accounts.

Furthermore, the transfer information acquisition unit 101 may identify the transfer type based on a string indicating the details of the transfer (transaction content), rather than the transfer type in the FB data. For example, the transfer information acquisition unit 101 may identify the transfer type by determining whether or not a string such as "KYUYO" or "SHOYO" exists in the string. The transfer information acquisition unit 101 may also identify transfer types other than salary transfers or bonus transfers. Other transfer types may include payments such as remittances, pocket money, tuition fees, or other specific payments.

[Necessity determination section]
The necessity determination unit 102 determines whether or not a deposit to the user's electronic money is necessary based on the type of transfer identified by the transfer information acquisition unit 101. The necessity of a deposit is whether or not to perform the deposit. Depositing money into electronic money is sometimes called charging. For example, the necessity determination unit 102 determines that a deposit to the electronic money is unnecessary if the type of transfer is not a predetermined type. The necessity determination unit 102 determines that a deposit to the electronic money is necessary if the type of transfer is a predetermined type. The predetermined type is not limited to salary transfers or bonus transfers as in the first embodiment, but can be any predetermined type. For example, the predetermined type may be payments such as remittances, pocket money, tuition fees, or other specific payments.

In the first embodiment, the necessity determination unit 102 determines that a deposit to the electronic money account is unnecessary if the transfer type does not indicate a salary transfer or a bonus transfer. In other words, the necessity determination unit 102 determines that a deposit to the electronic money account is unnecessary if the transfer type is neither a salary transfer nor a bonus transfer. For example, the necessity determination unit 102 determines that a deposit to the electronic money account is unnecessary if the transfer type indicates a general transfer, or if the transfer type is unknown (if no transfer type is specified, or if no transfer type exists).

In the first embodiment, the necessity determination unit 102 determines that a deposit is necessary when the transfer type indicates either a salary transfer or a bonus transfer. In other words, the necessity determination unit 102 determines that a deposit to electronic money is necessary when the transfer type is either a salary transfer or a bonus transfer. If the deposit system 1 is used for purposes other than salary transfers, the necessity determination unit 102 can determine whether a deposit is necessary by determining whether the transfer type is a predetermined type.

[Upper limit determination unit]
In the first embodiment, the electronic money has an upper limit set on the deposit balance. For example, the deposit balance is the salary balance. The deposit balance is not limited to the salary balance and may be other balances. For example, if the concept of a salary balance does not exist, the premium balance may correspond to the deposit balance. Alternatively, for example, the basic balance may correspond to the deposit balance. If the concepts of basic balance and premium balance do not exist, any balance of the electronic money may correspond to the deposit balance.

The upper limit determination unit 103 determines whether the salary balance will exceed the upper limit after the deposit, if the necessity determination unit 102 determines that a deposit is necessary. The upper limit is stored in the data storage unit 100. In the first embodiment, the upper limit is given as an example where it is the same for all users, but the upper limit may differ for each user. The upper limit determination unit 103 calculates the sum of the transfer amount to the user's virtual account and the user's current salary balance. The upper limit determination unit 103 determines whether the salary balance will exceed the upper limit after the deposit by determining whether this sum exceeds the upper limit.

[Deposit Execution Department]
The deposit execution unit 104 executes a deposit corresponding to the transfer amount in a transfer if the necessity determination unit 102 determines that a deposit is necessary. A deposit corresponding to the transfer amount means a deposit where the amount deposited (charged) to the electronic money is the same as the transfer amount, or a deposit where the deposit amount is less than the transfer amount. The deposit execution unit 104 does not execute a deposit if the necessity determination unit 102 determines that a deposit is unnecessary. The method of executing the deposit itself can utilize publicly known processes. In the case of electronic money as in the first embodiment, the deposit may be executed based on the process used for charging publicly known electronic money. The deposit execution unit 104 executes the deposit by updating the balance information stored in the electronic money database DB1. For example, if the deposit execution unit 104 determines that a deposit is necessary, it executes a deposit to the salary balance.

For example, the deposit execution unit 104 executes a deposit to the electronic money based on the balance of the parent account when the necessity determination unit 102 determines that a deposit is necessary. In the first embodiment, the parent account holder is the electronic money service provider that handles the electronic money. The parent account is common to each virtual account of multiple users. When the necessity determination unit 102 determines that a deposit is necessary, the deposit execution unit 104 executes a deposit to the electronic money based on the balance of the parent account, which is held by the electronic money service provider and is common to multiple users. The deposit execution unit 104 executes the deposit to the electronic money using the balance of the parent account as the source of funds. The process of executing an electronic money deposit based on a financial institution account may be the same as the process used for charging known electronic money.

Furthermore, the parent account may not be held by the electronic money provider handling the electronic money, but by someone else (for example, the user's employer, or a vendor collaborating with the electronic money provider). Additionally, the deposit execution unit 104 may execute a deposit to the electronic money based on an account other than the parent account, and not associated with the virtual account. The deposit execution unit 104 may also execute a deposit to the electronic money based on an account at a financial institution other than the financial institution in the financial institution system 3. Finally, the deposit execution unit 104 may also execute a deposit to the electronic money based on a payment method other than an account.

For example, the deposit execution unit 104 executes a deposit to the electronic money account so that the transfer amount is deposited into the electronic money account when the upper limit determination unit 103 determines that the balance does not exceed the upper limit. The deposit execution unit 104 deposits the entire transfer amount into the electronic money account. If a fee is incurred when depositing into the electronic money account, the deposit execution unit 104 may execute the deposit so that the amount deposited into the electronic money account is the transfer amount minus the fee.

For example, if the upper limit determination unit 103 determines that the salary balance exceeds the upper limit, the deposit execution unit 104 executes a deposit to the electronic money based on the difference between the current salary balance and the upper limit. The deposit execution unit 104 executes the deposit so that the salary balance in the electronic money increases by the difference. In other words, the deposit execution unit 104 executes the deposit so that the salary balance after the deposit matches the upper limit. The deposit execution unit 104 may also execute the deposit so that the salary balance after the deposit is less than the upper limit.

[Designated Account Transfer Department]
If the Necessity Determination Unit 102 determines that a deposit is not required, the Designated Account Transfer Unit 105 executes a Designated Account Transfer Process to transfer part or all of the transfer amount to the Designated Account specified by the user. The Designated Account Transfer Process can be any process related to a transfer to a Designated Account. For example, the Designated Account Transfer Unit 105 executes the Designated Account Transfer Process by requesting a transfer to the Designated Account from the financial institution's system (e.g., Financial Institution System 3 or another system) or the Japanese Bankers Association's system. In the first embodiment, the parent account associated with the user's virtual account becomes the source of the transfer, so the Designated Account Transfer Unit 105 requests a transfer from Financial Institution System 3. FB data may also be used in this transfer.

Furthermore, the transfer request itself can utilize publicly known processing methods. In the first embodiment, the designated account transfer unit 105 identifies the user's designated account by referring to the electronic money database DB1; however, the designated account transfer unit 105 may identify the user's designated account by referring to other databases. If a financial institution manages the deposit system 1, the designated account transfer unit 105 may execute the transfer itself instead of requesting a transfer from another system.

For example, the designated account transfer unit 105 executes a designated account transfer process to transfer the amount exceeding the upper limit to the designated account specified by the user. The designated account transfer unit 105 executes the designated account transfer process so that the amount transferred to the designated account is the transfer amount to the user's virtual account minus the amount deposited into the electronic money. If a transfer fee is incurred, the designated account transfer unit 105 may execute the designated account transfer process so that the amount transferred to the designated account is the amount the user would normally receive minus the transfer fee.

[1-3-2. Functions implemented by the workplace system]
For example, the workplace server 20 includes a data storage unit 200 and a transfer request unit 201. The data storage unit 200 is implemented by a storage unit 22. The transfer request unit 201 is implemented by a control unit 21. The workplace terminal 24 includes a data storage unit 240, a display control unit 241, and an operation reception unit 242. The data storage unit 200 is implemented by a storage unit 26. The display control unit 241 and the operation reception unit 242 are implemented by a control unit 25.

[Data Storage Unit]
The data storage unit 200 stores the data necessary for making transfers to users. For example, the data storage unit 200 stores the employer database DB2. However, the data storage unit 200 may also store other data besides the employer database DB2. For example, the data storage unit 200 may store information about the employer's account that will be the source of funds for the transfer to the user. The employer's account may be an account at the same financial institution as the financial institution where the user opened a virtual account, or it may be an account at a different financial institution.

Figure 8 shows an example of the Employer Database DB2. The Employer Database DB2 is a database that stores various information related to employee transfers. For example, the Employer Database DB2 stores employee number, name, transfer destination information, transfer amount, and transfer type. The Employer Database DB2 only needs to store some information related to transfers; the information stored in the Employer Database DB2 is not limited to the example in Figure 7. For example, FB data of previously executed transfers may be stored in the Employer Database DB2. If a user wishes to receive only a portion of their salary digitally, the amount requested by the user may be stored in the Employer Database DB2. The transfer to the user's virtual account may be limited to that amount only. Any amount exceeding that may be transferred to the user's physical account.

The transfer destination information refers to information about an employee's bank account. For example, the transfer destination information may include all or part of the following: financial institution code, financial institution name, branch code, branch name, account type, account number, and account holder name. Since some employees may not wish to receive their salaries digitally, the transfer destination information does not necessarily represent a virtual account. It may also represent a real account rather than a virtual one. In the first embodiment, since we are describing a transfer to a user who wishes to receive their salary digitally, the transfer destination information represents the user's virtual account. The transfer amount and transfer type will be specified by the person in charge of salary transfers at the workplace.

[Bank Transfer Request Department]
The transfer request unit 201 requests a transfer from the financial institution system 3. For example, the transfer request unit 201 generates FB data based on the recipient information, transfer amount, and transfer type stored in the employer database DB2. The transfer request unit 201 requests the transfer by transmitting the FB data to the financial institution system 3 or another system (for example, the interbank payment system). The method of requesting the transfer itself can utilize publicly known processes. For example, the transfer request unit 201 may request the transfer by performing the same process as the publicly known process used when salary payments are made at an employer such as a company.

[Data Storage Unit]
The data storage unit 240 stores data necessary for the work of the person in charge of payroll transfers at the workplace. For example, the data storage unit 240 stores a tool for the person in charge to register the user's payroll information.

[Display Control Unit]
The display control unit 241 displays a screen related to salary transfers at the workplace on the display unit 29. The person in charge enters the user's virtual account information from this screen.

[Operation Reception Section]
The operation reception unit 242 receives operations on the screen displayed by the display control unit 241. Based on the content of the operation, the transfer destination information stored in the workplace database DB2 is updated.

[1-3-3. Functions implemented in financial institution systems]
For example, the financial institution server 30 includes a data storage unit 300, a virtual account opening unit 301, a transfer acceptance unit 302, and a transfer information transmission unit 303. The data storage unit 300 is implemented by a storage unit 32. The virtual account opening unit 301, the transfer acceptance unit 302, and the transfer information transmission unit 303 are implemented by a control unit 31.

[Data Storage Unit]
The data storage unit 300 stores data necessary for transfers to users. For example, the data storage unit 300 stores the transfer database DB3 and the virtual account database DB4. The data storage unit 300 may also store other data besides the transfer database DB3 and the virtual account database DB4. For example, the data storage unit 300 may store API data for linking with the deposit system 1.

Figure 9 shows an example of a transfer database DB3. The transfer database DB3 is a database that stores various information related to transfers to accounts at a financial institution. For example, the transfer database DB3 stores the source of the FB data, the date and time of receipt of the FB data, and the FB data itself. The transfer database DB3 only needs to store any information related to transfers; the information stored in the transfer database DB3 is not limited to the example in Figure 9. For example, information regarding transfers received from sources other than one's employer may be stored in the transfer database DB3.

Figure 10 shows an example of a virtual account database DB4. The virtual account database DB4 is a database that stores various information related to virtual accounts opened at a financial institution. For example, the virtual account database DB4 stores virtual account information and parent account information related to the parent account associated with that virtual account. The virtual account database DB4 only needs to store some information related to the virtual account; the information stored in the virtual account database DB4 is not limited to the example in Figure 10. For example, the user ID of the user who opened the virtual account may be stored in the virtual account database DB4.

For example, virtual account information shows all or part of the virtual account's financial institution code, financial institution name, branch code, branch name, account type, account number, and account holder name. Parent account information shows all or part of the parent account's financial institution code, financial institution name, branch code, branch name, account type, account number, and account holder name. When a user opens a virtual account, the virtual account opening unit 301 generates virtual account information for that virtual account, associates it with the parent account information, and stores it in the virtual account database DB4. Each parent account is associated with at least one virtual account. The association between parent accounts and virtual accounts is defined by the virtual account information and parent account information in the virtual account database DB4.

[Virtual Account Opening Department]
The virtual account opening unit 301 opens a virtual account for a user. For example, the virtual account opening unit 301 opens a virtual account when it receives a predetermined request (in the first embodiment, the request in the flow shown in Figure 3) from the user terminal 40. The method of opening a virtual account itself may be a publicly known method. The virtual account opening unit 301 issues an account number for a user's virtual account so as not to overlap with the account numbers of other accounts. When the virtual account opening unit 301 issues a virtual account, it updates the virtual account database DB4.

[Bank Transfer Department]
The transfer acceptance unit 302 receives transfer requests from the workplace system 2. For example, the transfer acceptance unit 302 receives transfer requests by receiving FB data from the workplace system 2. The transfer acceptance unit 302 may also accept transfer requests from other systems or ATMs other than the workplace system 2.

[Transfer Information Transmission Department]
The transfer information transmission unit 303 transmits transfer information to the deposit system 1. For example, when the transfer information transmission unit 303 receives a request for transfer information from the deposit system 1, it generates transfer information based on the transfer database DB3. The transfer information transmission unit 303 generates transfer information based on all or part of the FB data stored in the transfer database DB3. The transfer information transmission unit 303 transmits the transfer information to the deposit system 1.

[1-3-4. Functions implemented on the user terminal]
The user terminal 40 includes a data storage unit 400, a display control unit 401, and an operation reception unit 402. The data storage unit 400 is implemented by a storage unit 42. The display control unit 401 and the operation reception unit 402 are implemented by a control unit 41.

[Data Storage Unit]
The data storage unit 400 stores the data necessary for the digital payroll procedure. For example, the data storage unit 400 stores a payment application or browser for displaying various screens such as the payment application screen SC1.

[Display Control Unit]
The display control unit 401 displays various screens, such as the payment application screen SC1, on the display unit 45 based on the payment application or browser stored in the data storage unit 400.

[Operation Reception Section]
The operation reception unit 402 receives operations on various screens displayed by the display control unit 401.

[1-4. Processing performed in the deposit system of the first embodiment]
Figures 11 and 12 show an example of processing performed in the deposit system 1 of the first embodiment. Figures 11 and 12 also show an example of processing performed in the workplace system 2, the financial institution system 3, and the user terminal 40, respectively. The processing in Figures 11 and 12 is performed by the control units 11, 21, 31, and 41 operating according to the programs stored in the storage units 12, 22, 32, and 42, respectively.

As shown in Figure 11, the user terminal 40 launches the payment application and executes a process to open a virtual account for the user with the financial institution server 30 (S100). The process in S100 is as described with reference to Figure 3. Note that the financial institution may pre-assign multiple virtual accounts to the electronic money provider. In this case, when a user applies to open a virtual account using the payment application, the deposit server 10 may assign a virtual account to that user. The account opening process may also be executed between the deposit server 10 and the financial institution server 30.

When a user's virtual account is opened in S100, the information of the virtual account is registered in the electronic money database DB1 and the virtual account database DB4. The user terminal 40 performs a process to register the designated account with the deposit server 10 (S101). The process in S101 is as explained with reference to Figure 4. The user's designated account information is registered in the electronic money database DB1. When the user applies for a transfer destination at their workplace, the person in charge of transfers at the workplace operates the workplace terminal 24 to register the transfer destination information in the transfer database DB3.

The workplace server 20 generates FB data based on the workplace database DB2 when the payment date for salary or bonus at the workplace approaches (S102). The person in charge at the workplace shall register the details of salary or bonus in advance in the payment database DB3. The person in charge shall also register details of comprehensive payments, such as advance payments, in the payment database DB3 in advance. The workplace server 20 transmits the FB data to the financial institution server 30 (S103). The financial institution server 30 receives the FB data from the workplace server 20 and executes the payment (S104). In S104, the payment database DB3 is updated. The cash for the payment to the user's virtual account is initially deposited into the parent account.

The deposit server 10 requests transfer information from the financial institution server 30 using an API (S105). Since the financial institution server 30 handles various types of transfers, the deposit server 10 requests transfer information for a virtual account at the "AAA Cash Branch". Upon receiving the request from the deposit server 10 (S106), the financial institution server 30 generates transfer information based on the transfer database DB3 (S107). The financial institution server 30 sends the transfer information to the deposit server 10 (S108). The deposit server 10 receives the transfer information from the financial institution server 30 (S109). If multiple users wish to receive digital payroll, the deposit server 10 receives the transfer information for each of the multiple users in S109.

The deposit server 10 determines whether a deposit to the electronic money account is necessary based on the transfer type indicated by the transfer information (S110). If it is determined that a deposit to the electronic money account is necessary (the transfer type is salary transfer or bonus transfer) (S110: necessary), the deposit server 10 determines, based on the electronic money database DB1, whether the user's salary balance exceeds the upper limit (S111). If it is determined that the user's salary balance does not exceed the upper limit (S111: N), the deposit server 10 executes the deposit to the electronic money account based on the electronic money database DB1 so that the entire transfer amount is deposited into the salary balance (S112), and then proceeds to the process described in S116 below. Since the source of the deposit is the balance of the parent account at the financial institution, the process in S112 is executed by the deposit server 10 coordinating with the financial institution server 30.

In S111, if it is determined that the user's salary balance exceeds the upper limit (S111: Y), the process moves to Figure 12, and the deposit server 10 executes a deposit to the electronic money account based on the electronic money database DB1, so that only a portion of the transfer amount is deposited (S113). Since the source of the deposit is the balance of the parent account at the financial institution, the process in S113 is executed by the deposit server 10 coordinating with the financial institution server 30. The deposit server 10 refers to the electronic money database DB1 to identify the designated account and executes the transfer so that the amount exceeding the upper limit is transferred to the designated account (S114). Since the source of the transfer is the balance of the parent account at the financial institution, the process in S114 is executed by the deposit server 10 coordinating with the financial institution server 30. Note that if the user's salary balance had already reached the upper limit at the time of S111, the process in S113 is not executed, and the transfer in S114 is executed for the entire transfer amount.

In S110, if it is determined that a deposit to the electronic money is not required (S110:N), the deposit server 10 refers to the electronic money database DB1 to identify the designated account and executes the transfer so that the entire transfer amount is deposited into the designated account (S115). Since the source of the transfer is the balance of the parent account at the financial institution, the process in S115 is executed by the deposit server 10 coordinating with the financial institution server 30. The deposit server 10 determines whether there are any transfers that have not yet been processed (S116:Y). If it is determined that there are any transfers that have not yet been processed (S116:N), the process returns to S110. If it is determined that there are no transfers that have not yet been processed (S116:N), this process terminates.

[1-5. Summary of the First Embodiment]
The deposit system 1 of the first embodiment determines whether a deposit to the electronic money is necessary based on the transfer type indicated by the transfer information. If the deposit system 1 determines that a deposit is necessary, it executes a deposit corresponding to the transfer amount in the transfer. This allows the deposit system 1 to execute an appropriate deposit to the electronic money. For example, if the deposit to the electronic money is of an inappropriate transfer type, the deposit system 1 can prevent an inappropriate deposit from being executed by determining that a deposit is unnecessary. If the deposit to the electronic money is of an appropriate transfer type, the deposit system 1 can execute an appropriate deposit by determining that a deposit is necessary.

Furthermore, deposit system 1 obtains transfer information from financial institution system 3. Deposit system 1 executes the deposit when it determines that a deposit is necessary. This allows deposit system 1 to implement a mechanism for appropriately depositing funds into electronic money using a virtual account system. For example, electronic money providers can securely manage funds in a parent account before depositing them into electronic money.

Furthermore, when the deposit system 1 determines that a deposit is necessary, it executes the deposit based on the balance of a parent account common to multiple users, where the account holder is the electronic money service provider handling the electronic money. This allows the electronic money service provider to manage transfers from users' employers using a parent account in which it is the account holder. For example, this makes it easier for electronic money service providers to manage funds eligible for digital salary payments.

Furthermore, the deposit system 1 determines that a deposit is unnecessary if the transfer type does not indicate a salary transfer or bonus transfer. The deposit system 1 determines that a deposit is necessary if the transfer type indicates a salary transfer or bonus transfer. This allows the deposit system 1 to distinguish between salary and non-salary payments for the user's electronic money, enabling it to perform appropriate deposits in digital salary payments. For example, the deposit system 1 can prevent non-salary deposits from occurring in the salary balance. The deposit system 1 can also prevent salary deposits from occurring in other balances (e.g., a basic balance that cannot be withdrawn).

Furthermore, if the deposit system 1 determines that a deposit is necessary, it will execute the deposit into the salary balance, rather than the non-salary balance. This allows the user to manage their salary balance and non-salary balance separately, thus improving user convenience. For example, if the user terminal 40 displays the salary balance and non-salary balance separately, the user will find it easier to manage their salary balance and non-salary balance.

Furthermore, if the deposit system 1 determines that a deposit is not required, it executes a designated account transfer process to transfer part or all of the transfer amount to the designated account specified by the user. This allows the deposit system 1 to ensure that the user receives the funds they are entitled to via the designated account. For example, the deposit system 1 can preemptively exclude the non-salary portion of a transfer. The deposit system 1 can reliably deposit only transfers that are classified as salary transfers or bonus transfers as electronic money. For example, when a salary transfer is made via ATM, the employee at the workplace cannot select the transfer type. Therefore, salary transfers made via ATM may all be treated as "non-salary (general)." In this case, if electronic money is awarded as non-salary, it may become impossible to properly manage funds that should rightfully be salary. Therefore, the deposit system 1 transfers the funds to the user's designated account without awarding electronic money based on non-salary. By providing a mechanism for awarding electronic money based on salary, the deposit system 1 enables more appropriate management of electronic money.

Furthermore, when a deposit is deemed necessary, the deposit system 1 determines whether the deposit will cause the balance to exceed the upper limit. If the deposit system 1 determines that the balance will not exceed the upper limit, it executes the deposit so that the transfer amount is credited to the electronic money account. This allows the deposit system 1 to impose limits on the electronic money salary balance. For example, the deposit system 1 can prevent the salary balance from exceeding a rule set by the government or administrative body. If the guaranteed amount that the electronic money provider must guarantee is determined by the upper limit of the salary balance, the deposit system 1 can ensure the guaranteed amount is appropriate by setting an upper limit that results in an appropriate compensation amount.

Furthermore, if the deposit system 1 determines that the salary balance exceeds the upper limit, it will execute a deposit based on the difference between the current salary balance in the electronic money and the upper limit. The deposit system 1 then executes a designated account transfer process to transfer the amount exceeding the upper limit to the designated account specified by the user. This prevents situations where the user is unable to receive the amount exceeding the upper limit. For example, the deposit system 1 can appropriately manage the salary limit.

[2. Second Embodiment]
In the first embodiment, an example was given in which the deposit system 1 implements digital salary payments using the user's virtual account. The method of implementing digital salary payments is not limited to the example of the first embodiment. The deposit system 1 may implement digital salary payments by other methods. In the second embodiment, an example was given in which the deposit system 1 implements digital salary payments in cooperation with a vendor system of a vendor that develops financial software. The vendor is a company that partners with an electronic money business operator that handles electronic money. In the second embodiment, the same configuration as in the first embodiment will not be explained.

Figure 13 shows an example of the system configuration in the second embodiment. As shown in Figure 13, in the second embodiment, the deposit system 1 is connected to the vendor system 5 via the network N in a communicative manner. For example, the vendor system 5 includes a vendor server 50. Note that the vendor system 5 only needs to include at least one computer and is not limited to the example in Figure 1. This point is the same as in the deposit system 1.

For example, the vendor server 50 is the vendor's server computer. The vendor server 50 includes a control unit 51, a storage unit 52, and a communication unit 53. The hardware configurations of the control unit 51, storage unit 52, and communication unit 53 may be the same as those of the control unit 11, storage unit 12, and communication unit 13, respectively. The program stored in the storage unit 52 may be provided to the vendor server 50 via a network N or an information storage medium.

[2-1. Overview of the deposit system in the second embodiment]
Figure 14 shows an example of the overview of the deposit system 1 in the second embodiment. In the second embodiment, the account number for transfers to users is a vendor-issued number issued by the vendor. The vendor-issued number may also be called by other names such as a virtual account number. The vendor-issued number is solely for the purpose of transfers. The issuance of a vendor-issued number does not mean that an account is opened at a financial institution.

For example, vendor-issued numbers use a numbering system similar to that of accounts at financial institutions. A vendor-issued number includes a code equivalent to the financial institution code, a code equivalent to the branch code, and a number equivalent to the account number. The number of digits in these codes is also the same as that of accounts at financial institutions. Some digits of the vendor-issued number allow it to be identified as a vendor-issued number. However, the vendor-issued number may use a different numbering system than accounts at financial institutions. The vendor-issued number itself may be a publicly known number.

The overall flow in the second embodiment is generally the same as that in the first embodiment. However, the overall flow in the second embodiment differs from that of the first embodiment in that a vendor-issued number is used instead of the virtual account number. For example, the user operates the user terminal 40 to access the vendor server 50 instead of the financial institution server 30 and issues their own vendor-issued number. The process for issuing the vendor-issued number may be the same as in Figure 3, and the process in which the financial institution server 30 issues the virtual account number can be replaced with the process in which the vendor server 50 issues the vendor-issued number.

Furthermore, the vendor server 50 can utilize publicly known processing methods for issuing vendor-issued numbers. When the vendor server 50 receives a request for a vendor-issued number from a user's terminal 40, it issues a vendor-issued number that does not overlap with those of other users. The vendor server 50 then transmits the issued vendor-issued number to the user terminal 40. The vendor server 50 may also transmit the issued vendor-issued number, along with user identification information such as the user's employee number, to the workplace system 2.

For example, to implement digital salary payments using vendor-issued numbers, a source of funds is required for users to deposit funds into their electronic money accounts. In the second embodiment, it is assumed that the electronic money provider has opened an account with a financial institution to pool these funds. Hereafter, this account will be referred to as the vendor-related account. If there are multiple users at a workplace who wish to receive digital salary payments, the vendor-related account is common to all of these users. For example, the name on the vendor-related account is the electronic money provider. The vendor-related account may be common to multiple workplaces, or a separate vendor-related account may be opened for each workplace.

For example, when a user obtains their vendor-issued number, they apply to their employer for a bank transfer account. The person in charge of payroll at the employer operates the employer terminal 24 to register the user's vendor-issued number with the employer server 20. As the timing of the transfer, such as payday or bonus day, approaches, the employer server 20 generates FB data in the same manner as in the first embodiment. In the second embodiment, the FB data includes the vendor-issued number instead of the virtual account number.

For example, the financial institution server 30 retrieves the financial institution's FB data from the FB data of all employees at the workplace. The coordination between the deposit server 10 and the financial institution server 30 may be the same as in the first embodiment, and is therefore omitted in Figure 14. The vendor server 50 retrieves the FB data of the specified vendor-issued numbers from the FB data of all employees at the workplace. The deposit server 10 requests transfer information from the vendor server 50 using the API. Upon receiving the request from the deposit server 10, the vendor server 50 generates transfer information based on the FB data. The vendor server 50 then transmits the transfer information to the deposit server 10.

The subsequent processing may be the same as in the first embodiment, but in the second embodiment, the deposit server 10 checks in advance whether or not an error will occur. For example, the deposit server 10 performs a determination in advance as to whether or not the salary balance exceeds the upper limit, or whether or not it is a bulk transfer. The deposit server 10 sends the error determination result to the vendor server 50. When the vendor server 50 receives the error determination result from the deposit server 10, it forwards the error determination result to the workplace system 2.

For example, the person in charge of payroll at a workplace modifies the FB data as needed. The process after the FB data is modified is the same as the process when the FB data was first generated. The old FB data is discarded. If the person in charge believes that modification of the FB data is unnecessary, they do not modify it. The person in charge may also forget to modify the FB data. In such cases, the financial institution system 3 may choose not to receive the FB data, or it may choose to receive the same FB data again.

In the second embodiment, the electronic money service provider has opened an account with a financial institution. The user's employer deposits a deposit into the electronic money service provider's account. Alternatively, instead of a deposit, the user's employer may deposit the total amount into the electronic money service provider's account each time a salary payment is made. Deposits to the user's electronic money or designated account are made from the balance in the electronic money service provider's account. In the second embodiment, digital salary payment is realized through the above process.

[2-2. Functions realized in the deposit system of the second embodiment]
Figure 15 shows an example of the functions implemented in the payment system 1 of the second embodiment. Figure 15 also shows an example of the functions implemented in the workplace system 2, the vendor system 5, and the user terminal 40. In the second embodiment, the same functions as in the first embodiment will not be described.

In Figure 15, the functions of the financial institution system 3 are omitted, but the financial institution system 3 may have the functions described in the first embodiment. That is, the first and second embodiments may be combined. In this case, the user may be able to choose whether to open a virtual account or to be issued a vendor-issued number. Alternatively, for example, one employer may use the virtual account method (the method of the first embodiment), while another employer uses the vendor method (the method of the second embodiment), thus allowing both methods to coexist. The deposit system 1 may be capable of supporting both methods.

[2-2-1. Functions implemented in the deposit system]
For example, the deposit system 1 of the second embodiment includes an error determination unit 106, a correction request unit 107, a deposit determination unit 108, and a transfer determination unit 109. Each of the error determination unit 106, the correction request unit 107, the deposit determination unit 108, and the transfer determination unit 109 is implemented by a control unit 11.

[Data Storage Unit]
In the second embodiment, a vendor-issued number is stored in the electronic money database DB1 instead of the virtual account information shown in Figure 7. For example, when a vendor-issued number is issued to a user, the deposit server 10 stores the vendor-issued number in the electronic money database DB1 in association with the user's user ID. The other configurations of the electronic money database DB1 are the same as in the first embodiment. The data storage unit 100 in the second embodiment may store data that can identify whether individual employers are subject to the deposit described later or to the on-demand transfer described later.

[Transfer Information Acquisition Department]
In the second embodiment, the transfer information acquisition unit 101 acquires transfer information from the vendor's vendor system 5. For example, the vendor system 5 voluntarily transmits transfer information to the deposit system 1. The transfer information acquisition unit 101 acquires the said transfer information from the vendor system 5. That is, the transfer information acquisition unit 101 may acquire transfer information transmitted from the vendor system 5 rather than proactively obtaining the transfer information from the vendor system 5. The deposit server 10 may periodically or irregularly query the vendor system 5 to see whether a transfer has been made to the user's vendor-issued number. When the vendor system 5 receives a query from the deposit server 10, it transmits the transfer information relating to the user's vendor-issued number to the deposit server 10 based on the vendor database DB 6 described later.

For example, the vendor system 5 receives transfer information from the workplace server 20 and transmits the transfer information to the deposit server 10. The transfer information acquisition unit 101 acquires the transfer information from the vendor system 5. If the vendor system 5 has not received the transfer information from the workplace server 20, it will inform the deposit server 10 accordingly.

For example, the transfer information acquisition unit 101 may acquire transfer information from the vendor system 5 before the scheduled transfer date. The scheduled date can also be called the reservation date for the transfer. For example, for salary transfers, this would be the 25th of each month. The FB data is assumed to specify the scheduled transfer date. The transfer information acquisition unit 101 acquires the transfer information from the vendor system 5 on the day before or earlier than the scheduled date. The date and time when the transfer information is acquired may be predetermined. The transfer information acquisition unit 101 may also acquire the transfer information on the scheduled date itself.

[Error detection unit]
The error determination unit 106 determines whether or not an error related to the transfer will occur based on the transfer information before the scheduled date. The error conditions that correspond to an error can be predetermined. The error conditions can be any conditions that can be determined based on the transfer information. For example, the error conditions can be conditions that can be determined based on the remitter's name, the recipient's name, the type of transfer, and the transfer amount. The error determination unit 106 determines whether or not the error conditions are met based on the transfer information. If the error determination unit 106 determines that the error conditions are not met, it determines that no error will occur. If the error determination unit 106 determines that the error conditions are met, it determines that an error will occur.

In the second embodiment, examples of error conditions are explained, specifically when the salary balance exceeds the upper limit and when the transfer type is not a salary transfer or bonus transfer. That is, an example is when the inability to deposit funds into electronic money, or when only a portion of the transfer amount can be deposited into electronic money, constitutes an error. For example, the error determination unit 106 determines, based on the user's salary balance and the transfer amount in the transfer, whether the user's salary balance has already exceeded the upper limit, or whether the transfer amount will exceed the upper limit after the transfer. If the error determination unit 106 determines that the user's salary balance does not exceed the upper limit, it determines that no error occurs. If the error determination unit 106 determines that the user's salary balance exceeds the upper limit, it determines that an error occurs.

For example, the error determination unit 106 determines whether the transfer type for a user's vendor-issued number is a salary transfer or a bonus transfer. If the error determination unit 106 determines that the transfer type is a salary transfer or a bonus transfer, it determines that no error occurs. If the error determination unit 106 determines that the transfer type is neither a salary transfer nor a bonus transfer, it determines that an error occurs.

The error determination unit 106 may combine the above determinations. For example, the error determination unit 106 may determine that no error occurs if the salary balance does not exceed the upper limit and the transfer type is either a salary transfer or a bonus transfer. The error determination unit 106 may also determine that an error occurs if the salary balance exceeds the upper limit or if the transfer type is neither a salary transfer nor a bonus transfer.

Furthermore, the error conditions may be arbitrary and are not limited to the examples above. For example, the error conditions may be that the vendor-issued number is invalid, the transfer amount is above a threshold, the name of the transfer requestor is not a specified name, or other conditions. Alternatively, the error conditions may be whether the deposit is sufficient as determined by the deposit determination unit 108 (described later), or whether the amount is sufficient as determined by the transfer determination unit 109 (described later). In this case, the error determination unit 106 has the same function as the deposit determination unit 108 or the transfer determination unit 109.

[Correction Request Department]
The correction request unit 107 executes a correction request process to request correction of the error in the transfer when the error determination unit 106 determines that an error has occurred. The correction request process can be any process that directly or indirectly requests the transfer details from the requester in some form. In the second embodiment, the process in which the deposit server 10 sends a predetermined notification to the vendor server 50 is given as an example of the correction request process, but the process in which the deposit server 10 sends a predetermined notification to the workplace server 20 or another computer may also be considered the correction request process. For example, when the error determination unit 106 determines that an error has occurred, the correction request unit 107 sends a notification to the vendor server 50 indicating the content of the error. The notification is assumed to include information that can identify the transfer in which the error has been determined to have occurred.

[Deposit Determination Unit]
For example, if a deposit is made by the remitter in a transfer to a vendor-related account before the transfer information is received, the deposit determination unit 108 determines whether the deposit is sufficient based on the transfer information. Sufficient deposit means that the total amount of the deposit is equal to or greater than the total amount of the transfer in the transfer. The deposit determination unit 108 requests the financial institution server 30 to inquire about the balance (total amount of deposit) of the vendor-related account. When the financial institution server 30 receives the inquiry request, it sends information indicating the balance of the vendor-related account to the deposit server 10. The deposit server 10 receives this information from the financial institution server 30. The deposit determination unit 108 determines whether the deposit is sufficient by comparing the total amount of deposit indicated by this information with the total amount of the transfer in the current transfer.

[Transfer Determination Section]
For example, if a transfer is received in a vendor-related account and the transfer amount is subsequently transferred by the transferor, the transfer determination unit 109 determines whether or not the amount has been transferred to the vendor-related account. The transfer determination unit 109 requests the financial institution server 30 to inquire about the details of the vendor-related account. Upon receiving the request, the financial institution server 30 sends information indicating the details of the vendor-related account to the deposit server 10. The deposit server 10 receives this information from the financial institution server 30. The transfer determination unit 109 compares the transfer history indicated by this information with the total amount of the transfer and the name of the transferor in the current transfer to determine whether or not the transfer has been made. If these do not match, the transfer determination unit 109 does not determine that the transfer has been made; if they do match, it determines that the transfer has been made.

[Deposit Execution Department]
In the second embodiment, the deposit execution unit 104 executes a deposit to the electronic money when the necessity determination unit 102 determines that a deposit is necessary. This differs from the first embodiment in that the source of the deposit is a vendor-related account rather than a parent account, but otherwise it is the same as the first embodiment. The deposit execution unit 104 uses the balance of the vendor-related account as the source of funds to execute a deposit to the user's electronic money.

For example, the deposit execution unit 104 executes the deposit to the electronic money if the deposit determination unit 108 determines that the deposit is sufficient. If the deposit determination unit 108 determines that the deposit is not sufficient, the deposit execution unit 104 does not execute the deposit based on that deposit.

For example, the deposit execution unit 104 executes the deposit to the electronic money based on the balance of the vendor-related account when the transfer determination unit 109 determines that the amount has been transferred to the vendor-related account. If the transfer determination unit 109 does not determine that the amount has been transferred to the vendor-related account, the deposit execution unit 104 does not execute the deposit based on the balance of the vendor-related account.

[2-2-2. Functions implemented by vendor systems]
For example, the vendor server 50 includes a data storage unit 500, a number issuance unit 501, a transfer acceptance unit 502, and a transfer information transmission unit 503. The data storage unit 500 is implemented by a storage unit 52. The number issuance unit 501, the transfer acceptance unit 502, and the transfer information transmission unit 503 are implemented by a control unit 51.

[Data Storage Unit]
The data storage unit 500 stores the data necessary for transfers to users. For example, the data storage unit 500 stores the transfer database DB5 and the vendor database DB6. The transfer database DB5 is generally similar in content to the transfer database DB3, so its illustration is omitted. However, the recipient of the FB data stored in the transfer database DB5 is not a virtual account as in the first embodiment, but a vendor-issued number. In other respects, the transfer database DB5 is the same as the transfer database DB3.

Figure 16 shows an example of the vendor database DB6. The vendor database DB6 is a database that stores various information necessary for facilitating transfers via vendors. For example, the vendor database DB6 stores the vendor issuance number, the user's name, date of birth, and address. The vendor database DB6 only needs to store some information related to the vendor issuance number; the information stored in the vendor database DB6 is not limited to the example in Figure 16. For example, information about the user's workplace may also be stored in the vendor database DB6.

[Number Issuance Department]
The number issuing unit 501 issues a vendor-issued number to the user. For example, the number issuing unit 501 issues a vendor-issued number when it receives a predetermined request from the user terminal 40. The method of issuing the vendor-issued number itself may be a publicly known method. The number issuing unit 501 issues a vendor-issued number for a given user in a way that does not overlap with other vendor-issued numbers. When the number issuing unit 501 issues a vendor-issued number, it stores the vendor-issued number, the user's name, date of birth, and address in the vendor database DB6.

[Bank Transfer Department]
The transfer acceptance unit 502 receives transfer information from the workplace system 2. For example, the transfer acceptance unit 502 receives transfer information by receiving FB data from the workplace system 2. The transfer acceptance unit 502 may also receive transfer information from other systems or ATMs other than the workplace system 2.

[Transfer Information Transmission Department]
The transfer information transmission unit 503 transmits transfer information to the deposit system 1. For example, when the transfer information transmission unit 503 receives a request for transfer information from the deposit system 1, it transmits the transfer information based on the vendor database DB 6. The transfer information transmission unit 503 transmits the transfer information based on all or part of the FB data stored in the transfer database DB 5. The transfer information transmission unit 503 transmits the transfer information to the deposit system 1. The transfer information transmission unit 503 may transmit the transfer information received from the workplace system 2 as is, or it may convert it to another format before transmitting it.

[2-3. Processing performed in the deposit system of the second embodiment]
Figures 17 and 18 show examples of processes performed in the deposit system 1 of the second embodiment. Figures 17 and 18 also show examples of processes performed in the workplace system 2, the financial institution system 3, the vendor system 5, and the user terminal 40, respectively. The processes in Figures 17 and 18 are performed by the control units 11, 21, 31, 41, and 51 operating according to programs stored in the storage units 12, 22, 32, 42, and 52, respectively.

As shown in Figure 17, the user terminal 40 launches the payment application and executes a process to issue the user's vendor-issued number to the vendor server 50 (S200). Once the user's vendor-issued number is issued in S200, information about the vendor-issued number is registered in the electronic money database DB1 and the vendor database DB6. The process in S201 is the same as the process in S101. When the user applies for a transfer destination at their workplace, the person in charge of transfers at the workplace operates the workplace terminal 24 to register the transfer destination information with the workplace server 20.

The employer server 20 sends FB data to the vendor server 50 (S203). The vendor server 50 receives the FB data from the employer server 20 and stores it in the transfer database DB5 (S204). In S204, the transfer database DB5 is updated. The deposit server 10 requests transfer information from the vendor server 50 using the API (S205). When the vendor server 50 receives the request from the deposit server 10 (S206), it generates transfer information based on the transfer database DB5 (S207). The vendor server 50 sends the transfer information to the deposit server 10 (S208). The deposit server 10 receives the transfer information from the vendor server 50 (S209). If multiple users wish to receive digital payroll, the deposit server 10 receives the transfer information for each of the multiple users in S209.

The deposit server 10 determines whether an error occurs based on the transfer information (S210). If no error is determined to occur (S210:N), the process proceeds to S223, described below. If an error is determined to occur in S210 (S210:Y), the deposit server 10 requests the vendor server 50 to correct the FB data (S211). Upon receiving the request (S212), the vendor server 50 requests the employer server 20 to correct the FB data (S213). The employer server 20 accepts the request (S214).

Moving to Figure 18, the workplace server 20 receives the correction of the FB data from the person in charge at the workplace (S215). The workplace server 20 sends the corrected FB data to the vendor server 50 (S216). The vendor server 50 receives the corrected FB data from the workplace server 20 (S217). Steps S218 to S222 are the same as steps S205 to S209, respectively. Steps S223 to S229 are the same as steps S110 to S116, respectively. Note that the timing at which the transfer information is generated based on the transfer database DB5 is not limited to the above example. This timing may be any other appropriate timing. For example, the transfer information may be generated after error detection and error correction are completed.

[2-4. Summary of the Second Embodiment]
The deposit system 1 of the second embodiment obtains transfer information from the vendor system 5. When the deposit system 1 determines that a deposit to electronic money is necessary, it executes the deposit based on the balance of the vendor-related account associated with the vendor-issued number. In this way, the deposit system 1 can realize a mechanism to execute appropriate deposits to electronic money using the vendor-issued number system. For example, a user who is hesitant to open a virtual account with a financial institution can use the vendor-issued number system to receive their salary or bonus in electronic money.

Furthermore, the deposit system 1 obtains transfer information from the vendor system 5 before the scheduled transfer date. Before the scheduled date, the deposit system 1 determines, based on the transfer information, whether or not a transfer error will occur. If the deposit system 1 determines that an error will occur, it executes a correction request process to request correction of the transfer error. This correction request process reduces the likelihood of errors occurring.

Furthermore, deposit system 1 determines whether the deposit is sufficient based on the transfer information. If deposit system 1 determines that the deposit is sufficient, it executes the deposit. Deposit system 1 can prevent insufficient funds for deposits to electronic money.

Furthermore, the deposit system 1 determines whether or not the amount has been transferred to the vendor-related account. If the deposit system 1 determines that the amount has been transferred to the vendor-related account, it executes the deposit. The deposit system 1 can prevent insufficient funds for deposits to electronic money.

[3. Variations]
This disclosure is not limited to the embodiments described above. This disclosure may be modified as appropriate without departing from the spirit of this disclosure. In the following modifications, an example is given in which the digital payment of salaries in the modifications is implemented by the method of the first embodiment, but the digital payment of salaries in the modifications may also be implemented by the method of the second embodiment.

Figure 19 shows an example of the functionality in a modified example. As shown in Figure 19, the deposit server 10 includes a first notification unit 110, a display control unit 111, a second notification unit 112, a setting reception unit 113, a third notification unit 114, and an appropriate amount suggestion unit 115. Each of the first notification unit 110, the display control unit 111, the second notification unit 112, the setting reception unit 113, the third notification unit 114, and the appropriate amount suggestion unit 115 is implemented by the control unit 11.

[3-1. Variation 1]
For example, if a transfer is made to a user's designated account, the user may mistakenly believe that they have not received their salary or other payments because the money has not been deposited into their electronic money account. For this reason, the user may be notified that a transfer has been made to their designated account. Modification 1 of the deposit system 1 includes a first notification unit 110. When a designated account transfer process is executed, the first notification unit 110 notifies the user about the execution of the designated account transfer process.

Figure 20 shows an example of a notification regarding the execution of a designated account transfer process. For example, the first notification unit 110 notifies the user by displaying message M17, indicating that the designated account transfer process has been executed, on the payment application screen SC1 of the payment application. The first notification unit 110 may notify the user based on any notification means. For example, the first notification unit 110 may notify the user based on the notification function within the payment application, email, SMS, push notification, banner notification, or other notification means.

For example, the first notification unit 110 determines whether or not the designated account transfer process has been executed. If the first notification unit 110 determines that the designated account transfer process has been executed, it sends a notification to the user. The data necessary for the notification is stored in the data storage unit 100. The notification may include any information. For example, in addition to information indicating that the designated account transfer process has been executed, the notification may also include the name of the remitter in the transfer, the date and time of the transfer, the transfer amount, or a combination of these. The notification may also include information similar to that available to users on well-known financial applications or websites.

In Modified Example 1, the deposit system 1 notifies the user when a designated account transfer process is executed. This allows the user to be aware that the designated account transfer process has been performed. For example, it prevents a user from mistakenly believing that their salary was not paid because their electronic money salary balance hasn't increased, even though their salary was paid via digital salary payment. The user can then be aware that their salary has been paid through a transfer to their designated account.

[3-2. Modification Example 2]
For example, when a designated account transfer process is executed, instead of a notification as in Modification Example 1, the fact that the designated account transfer process has been executed may be displayed on the balance management screen for managing the balance of the electronic money. The deposit system 1 in Modification Example 2 includes a display control unit 111. When a designated account transfer process is executed, the display control unit 111 causes the balance management screen for managing the balance of the payment method to display that the designated account transfer process has been executed.

Figure 21 shows an example of a balance management screen. In Modification 2, the example shows a case where the balance management screen SC3 is displayed when the user selects button B12 on the payment application screen SC1. However, the balance management screen SC3 may also be displayed when other operations are performed. The balance management screen SC3 should only be displayed when the user performs an operation to display it. The data necessary for displaying the balance management screen SC3 is assumed to be stored in the data storage unit 100. For example, data showing the deposit history to the user's designated account is stored in the electronic money database DB1 or another database. When a transfer to the user's designated account is executed, the deposit server 10 obtains data showing the execution history of the transfer from the financial institution server 30 and records this data in the data storage unit 100.

For example, when the user terminal 40 selects button B12, it sends a request to the deposit server 10 to display the balance management screen SC3. The deposit server 10 receives the request from the user terminal 40 to display the balance management screen SC3. The display control unit 111 refers to the electronic money database DB1 and obtains the user's electronic money balance information and usage history. In the modified example 2, the execution result of the designated account transfer process is shown as part of the electronic money usage history.

For example, the display control unit 111 generates display data for the balance management screen SC3 based on the electronic money balance information and usage history. The display data can be any data necessary to display a screen on the user terminal 40, and may be in any data format. For example, the display data may be HTML data or image data. In the example shown in Figure 21, the display control unit 111 generates display data for the balance management screen SC3 indicating that a designated account transfer process has been executed as part of the usage history. The display control unit 111 transmits the generated display data to the user terminal 40. Upon receiving the display data, the user terminal 40 displays the balance management screen SC3 on the display unit 45 based on the display data.

In Modified Example 2, the deposit system 1 displays a notification on the balance management screen SC3 indicating that a designated account transfer has been executed. This allows the user to be aware that the designated account transfer has been performed. For example, it prevents a user from mistakenly believing that their salary was not paid because their electronic money salary balance hasn't increased, even though their salary was paid via digital salary payment. The user can then be aware that their salary has been paid through a transfer to their designated account. For example, even if the funds are not deposited as electronic money, the balance management screen SC3 may initially display it as if the funds were deposited and then withdrawn; in this case, user convenience is further improved.

[3-3. Variation 3]
For example, if a user does not use their electronic money salary balance after it has reached its upper limit, their subsequent salary will be transferred to a designated account. If a user's salary is repeatedly transferred to a designated account, the purpose of digital salary payment is diminished, so the user may be prompted to reconsider their salary transfer destination. Modification 3 of the deposit system 1 includes a second notification unit 112. Based on the execution result of the designated account transfer process, the second notification unit 112 sends a notification to the transfer requester urging them not to make transfers of types that are determined not to require payment.

Figure 22 shows an example of a notification to the sender in a bank transfer. In Modification 3, the sender is the user's employer. When the deposit system 1 is applied to situations other than digital salary payments, the sender may be someone other than the employer. For example, the sender may be the user's family, friends, students, or other acquaintances. For example, the second notification unit 112 sends an email to the user's employer's email address prompting the user to change their salary transfer method. The employer's email address is assumed to be pre-stored in the data storage unit 100. The second notification unit 112 may notify the employer based on any notification means. For example, the second notification unit 112 may notify the employer based on a notification function in some management tool, SMS, push notification, banner notification, or other notification means.

In Modification 3, the deposit system 1, based on the execution result of the designated account transfer process, notifies the transfer requester to refrain from making transfers of types that are determined not to require payment. This prevents the deposit system 1 from diminishing the significance of digital salary payments. If the user changes the transfer destination, the deposit server 10 does not need to perform unnecessary processing, thus reducing the processing load on the deposit server 10. For example, when a fixed amount of non-salary transfer is made each month, the deposit system 1 can also notify the user that it will contact the company to prevent the non-salary transfer.

[3-4. Variation 4]
For example, as described in the first and second embodiments, the electronic money may have a salary balance for deposit by the deposit execution unit 104, and a basic balance and a premium balance that are different from the salary balance. The salary balance is an example of a first balance. The basic balance and the premium balance are examples of a second balance. The first balance and the second balance may be balances that are managed separately from each other and may be called by other names. The deposit execution unit 104 executes a deposit to the salary balance when the necessity determination unit 102 determines that a deposit is necessary. This point is as described in the first and second embodiments.

The deposit system 1 in Modification 4 includes a setting reception unit 113. The setting reception unit 113 receives settings from the user regarding whether to transfer funds to a designated account specified by the user when the necessity determination unit 102 determines that a deposit is unnecessary, or to deposit funds into the basic balance and premium balance in such cases. The user's settings are stored in the electronic money database DB1. For example, the user specifies these settings from the payment application screen SC1 or another screen. The deposit server 10 records the settings specified by the user in the data storage unit 100.

In variation 4, the deposit server 10 refers to the user's settings when it determines that the transfer type does not indicate a salary transfer or bonus transfer. The deposit execution unit 104 executes the deposit to the second balance if the settings received from the user indicate the second balance. The method for executing the deposit to the second balance can utilize publicly known processes. For electronic money, the deposit to the second balance may be executed based on the process used for charging publicly known electronic money. The deposit execution unit 104 executes the deposit to the second balance by updating the balance information stored in the electronic money database DB1.

For example, the designated account transfer unit 105 executes the designated account transfer process when the settings received from the user indicate a designated account. The condition for executing the designated account transfer process is that the settings received from the user indicate a designated account; however, the details of the designated account transfer process are as described in the first embodiment.

Furthermore, the user may specify the settings in Modification 4 by specifying the deposit amount or remaining balance. For example, the user may set it up so that if the transfer amount is less than 10,000 yen, it is deposited into electronic money, and the amount exceeding 10,000 yen is transferred to a designated account. Alternatively, for example, the deposit system 1 may suggest setting options to the user based on past deposit and withdrawal history.

In Modification 4, the deposit system 1 executes a deposit to the second balance when the settings received from the user indicate the second balance. The deposit system 1 also executes a transfer to the designated account when the settings received from the user indicate the designated account. This allows the deposit system 1 to provide deposits according to the user's preferences, thereby increasing user convenience.

[3-5. Variant 5]
For example, in the first and second embodiments, an example was given in which an upper limit of 100,000 yen is set for the electronic money. The electronic money may have a first upper limit and a second upper limit that is higher than the first upper limit. In Modification 5, the first upper limit is assumed to be 80,000 yen. The second upper limit is assumed to be 100,000 yen. Each of the first and second upper limits may be any value and is not limited to Modification 5. Each of the first and second upper limits may be specified by the electronic money business operator handling the electronic money, or it may be specified by the user.

In Modification 5, the upper limit determination unit 103 determines whether the balance will exceed the second upper limit after a deposit is made, when the necessity determination unit 102 determines that a deposit is necessary. While it differs from the first and second embodiments in that both a first and second upper limit exist, the determination method of the upper limit determination unit 103 itself is the same as in the first and second embodiments.

In Modification 5, the designated account transfer unit 105 executes the designated account transfer process when the upper limit determination unit 103 determines that the balance exceeds the second upper limit. While it differs from the first and second embodiments in that both a first and second upper limit exist, the processing of the designated account transfer unit 105 itself is the same as in the first and second embodiments.

Furthermore, the first upper limit may be used for purposes other than notifications, as described in Modification Example 6 below. For example, if a user's salary balance exceeds the second upper limit, deposits to the salary balance will not be accepted. However, if the salary balance exceeds the first upper limit, the system may prompt the user to confirm whether a deposit is necessary before the deposit is made to the salary balance. The deposit execution unit 104 may execute a deposit exceeding the first upper limit based on the user's response. For example, the first upper limit may be used for notifications to the employer rather than the user.

In Modification 5, the deposit system 1 determines whether the deposit will cause the salary balance to exceed the second upper limit when a deposit is deemed necessary. If the deposit system 1 determines that the salary balance will exceed the second upper limit, it executes a transfer to the designated account. This allows the deposit system 1 to impose a second upper limit on the electronic money salary balance.

[3-6. Variation 6]
For example, in Modification 5, the upper limit determination unit 103 may determine whether the salary balance will exceed the first upper limit after the deposit, when the necessity determination unit 102 determines that a deposit is necessary. The deposit system 1 in Modification 6 includes a third notification unit 114. When the upper limit determination unit 103 determines that the balance exceeds the first upper limit, the third notification unit 114 sends a notification to the user urging them to use the balance.

Figure 23 shows an example of a notification prompting the use of the balance. For example, the third notification unit 114 notifies the user by displaying message M18, indicating a prompt to use the balance, on the payment application screen SC1 of the payment application. The data for the notification is assumed to be recorded in the data storage unit 100. The third notification unit 114 may notify the user based on any notification means. For example, the third notification unit 114 may notify the user based on the notification function within the payment application, email, SMS, push notification, banner notification, or other notification means.

In Modified Example 6, the deposit system 1 determines whether the deposit will cause the balance to exceed the first upper limit when a deposit is deemed necessary. If the deposit system 1 determines that the salary balance will exceed the first upper limit, it sends a notification to the user encouraging them to use their salary balance. This allows the deposit system 1 to incentivize the user to actively use their salary balance, making it less likely for the salary balance to exceed the second upper limit before salary transfer.

[3-7. Variation 7]
For example, if digital salary payments are repeatedly made to a user, it may be possible to estimate how much can be paid each month without exceeding the upper limit of the salary balance. In this case, the system may suggest to the user an appropriate amount that they can receive as a digital salary payment. The deposit system 1 in Modification 7 includes an appropriate amount suggestion unit 115. The appropriate amount suggestion unit 115 suggests to the user an appropriate amount to be transferred based on past performance of designated account transfer processing.

For example, the appropriate amount presentation unit 115 calculates the average amount a user received as salary via electronic money over all or part of a past period. The appropriate amount presentation unit 115 then presents this calculated average amount to the user as an appropriate amount for transfer. The appropriate amount presentation unit 115 may present this information to the user based on the payment app screen SC1, the notification function within the payment app, email, SMS, push notifications, banner notifications, or other notification methods.

In Modification 7, the deposit system 1 suggests an appropriate transfer amount to the user based on past transaction history for designated account transfers. This allows the deposit system 1 to make the user aware of the appropriate transfer amount. For example, if 10,000 yen of a monthly salary transfer of 20,000 yen has been deposited into the designated account, the deposit system 1 can notify the user, "Please set the transfer amount for digital salary payment to 10,000 yen."

[3-8. Other variations]
For example, the above variations may be combined.

For example, based on the user's electronic money withdrawal history, deposit system 1 may, instead of transferring the amount exceeding the upper limit to the designated account, deposit it as a reserved amount into the electronic money balance for a certain period. Deposit system 1 may allow the user to set whether to deposit their salary into their electronic money balance or transfer it to a designated account. Deposit system 1 may allow the user to set the above setting by specifying an amount. For example, deposit system 1 may deposit amounts less than 10,000 yen into electronic money and transfer any amount exceeding 10,000 yen to the designated account. Deposit system 1 may propose such settings to the user based on their electronic money withdrawal history. Deposit system 1 may differentiate the point multiplier when using electronic money depending on whether the transfer type is a salary transfer or a non-salary transfer. Deposit system 1 may award points at a higher point multiplier when using the salary balance than when using other balances.

For example, the functions described as being implemented by the deposit server 10 may be shared among multiple computers in the deposit system 1. In this case, the sharing of functions can be achieved by each of the multiple computers sending its processing results to the other computers. The deposit system 1 may include at least one of the following: the employer system 2, the financial institution system 3, the vendor system 5, and the user terminal 40.

[4. Addendum]
For example, the payment system related to this disclosure can also be configured as follows:
(1)
A transfer information acquisition unit acquires transfer information indicating the type of transfer in a transfer where the user's account number is specified as the recipient,
A necessity determination unit that determines whether or not a deposit is necessary to the user's electronic payment method based on the transfer type indicated by the transfer information,
If the necessity determination unit determines that the deposit is necessary, the deposit execution unit executes the deposit according to the amount of the transfer in the transfer,
A deposit system that includes this.
(2)
The aforementioned account number is the virtual account number of the user at the financial institution.
The transfer information acquisition unit acquires the transfer information relating to the virtual account from the financial institution's financial institution system.
The deposit execution unit executes the deposit if the necessity determination unit determines that the deposit is necessary.
The deposit system described in (1).
(3)
The aforementioned account number is a vendor-issued number issued by the vendor.
The aforementioned transfer information acquisition unit acquires the transfer information from the vendor's vendor system.
The deposit execution unit, when the necessity determination unit determines that the deposit is necessary, executes the deposit based on the balance of the vendor-related account, which is an account at a financial institution associated with the vendor-issued number.
The deposit system described in (1).
(4)
The transfer information acquisition unit acquires the transfer information from the vendor system before the scheduled date of the transfer.
The aforementioned deposit system is
An error determination unit determines whether or not an error related to the transfer will occur based on the transfer information before the aforementioned scheduled date,
If the error determination unit determines that the error has occurred, the correction request unit executes a correction request process to request correction of the error in the transfer,
The deposit system described in (3) further includes the following.
(5)
Before the aforementioned transfer information is received, a deposit related to the remitter in the transfer is deposited into the aforementioned vendor-related account.
The deposit system further includes a deposit determination unit that determines whether the deposit is sufficient based on the transfer information.
The deposit execution unit executes the deposit if the deposit determination unit determines that the deposit is sufficient.
The deposit system described in (3) or (4).
(6)
After the transfer information is received, the amount corresponding to the transfer is transferred to the aforementioned vendor-related account by the remitter in the transfer.
The deposit system further includes a transfer determination unit that determines whether or not the amount has been transferred to the vendor-related account.
The deposit execution unit executes the deposit when the transfer determination unit determines that the amount has been transferred to the vendor-related account.
The payment system described in any of (3) to (5).
(7)
The necessity determination unit determines that the deposit is unnecessary if the transfer type does not indicate salary transfer or bonus transfer, and determines that the deposit is necessary if the transfer type indicates salary transfer or bonus transfer.
The payment system described in any of (1) to (6).
(8)
The aforementioned payment method has a first balance for salary or bonus payments, and a second balance different from the first balance.
The deposit execution unit, when it determines that the deposit is necessary, executes the deposit into the first balance.
The deposit system described in (7).
(9)
The deposit system further includes a designated account transfer unit that, when the necessity determination unit determines that the deposit is unnecessary, executes a designated account transfer process to transfer the transfer amount to the designated account specified by the user.
The payment system described in any of (1) to (8).
(10)
The deposit system further includes a first notification unit that notifies the user of the execution of the designated account transfer process when the designated account transfer process is executed.
The deposit system described in (9).
(11)
The deposit system further includes a display control unit that, when the designated account transfer process is executed, displays on the balance management screen for managing the balance of the payment method that the designated account transfer process has been executed.
The deposit system described in (9) or (10).
(12)
The deposit system further includes a second notification unit that, based on the execution result of the designated account transfer process, notifies the transferor in the transfer to refrain from making transfers of a type that is determined not to require payment.
The payment system described in any of (9) to (11).
(13)
The settlement means has a first balance for deposits and a second balance different from the first balance.
The deposit execution unit executes the deposit to the first balance when the necessity determination unit determines that the deposit is necessary.
The aforementioned deposit system is
A setting reception unit receives a setting from the user regarding whether to transfer the funds to the designated account specified by the user, or to deposit the funds into the second balance, if the necessity determination unit determines that the deposit is unnecessary.
When the above setting indicates the above designated account, the designated account transfer unit executes the designated account transfer process for transferring the transfer amount in the above transfer,
It further includes,
The deposit execution unit executes a deposit to the second balance when the setting indicates the second balance.
The payment system described in any of (1) to (12).
(14)
The aforementioned payment method has an upper limit set for the balance available for deposits.
The deposit system further includes an upper limit determination unit that determines whether the deposit will cause the balance to exceed the upper limit, when the necessity determination unit determines that the deposit is necessary.
The deposit execution unit executes the deposit so that the transfer amount in the transfer is deposited into the settlement means when the upper limit determination unit determines that the balance does not exceed the upper limit.
The payment system described in any of (1) to (13).
(15)
The deposit execution unit, when the upper limit determination unit determines that the balance exceeds the upper limit, executes the deposit based on the difference between the current balance of the settlement means and the upper limit.
The deposit system further includes a designated account transfer unit that performs a designated account transfer process to transfer the amount exceeding the upper limit of the transfer amount to a designated account specified by the user.
The deposit system described in (14).
(16)
The aforementioned payment method has a first upper limit and a second upper limit that is higher than the first upper limit set as upper limits.
The upper limit determination unit, when the necessity determination unit determines that the deposit is necessary, determines whether the deposit will cause the balance to exceed the second upper limit.
The designated account transfer unit executes the designated account transfer process when the upper limit determination unit determines that the balance exceeds the second upper limit.
The deposit system described in (15).
(17)
The upper limit determination unit, when the necessity determination unit determines that the deposit is necessary, determines whether the deposit will cause the balance to exceed the first upper limit.
The deposit system further includes a third notification unit that, when the upper limit determination unit determines that the balance exceeds the first upper limit, notifies the user to use the balance.
The deposit system described in (16).
(18)
The deposit system further includes an appropriate amount suggestion unit that suggests an appropriate amount to the user for the transfer based on past performance of the designated account transfer process.
The payment system described in any of (15) to (17).

1 Deposit system, 2 Workplace system, 3 Financial institution system, 5 Vendor system, N Network, 10 Deposit server, 11, 21, 25, 31, 41, 51 Control unit, 12, 22, 26, 32, 42, 52 Storage unit, 13, 23, 27, 33, 43, 53 Communication unit, 20 Workplace server, 24 Workplace terminal, 28, 44 Operation unit, 29, 45
Display unit, 30 Financial institution server, 40 User terminal, 50 Vendor server, 100 Data storage unit, 101 Transfer information acquisition unit, 102 Necessity determination unit, 103 Upper limit determination unit, 104 Deposit execution unit, 105 Designated account transfer unit, 106 Error determination unit, 107 Correction request unit, 108 Deposit determination unit, 109 Transfer determination unit, 110 First notification unit, 111 Display control unit, 112 Second notification unit, 113 Setting acceptance unit, 114 Third notification unit, 115 Appropriate amount presentation unit, 200 Data storage unit, 201 Transfer request unit, 240 Data storage unit, 241 Display control unit, 242 Operation acceptance unit, 300 Data storage unit, 301 Virtual account opening unit, 302 Transfer acceptance unit, 303 Transfer information transmission unit, 400 Data storage unit, 401 Display control unit, 402 Operation reception unit, 500 data storage unit, 501 number issuance unit, 502 transfer reception unit, 503 transfer information transmission unit, B11, B12, B13, B14, B16, B20, B21 buttons, C10 code, DB1 electronic money database, DB2 employer database, DB3 transfer database, DB4 virtual account database, DB5 transfer database, DB6 vendor database, F15 input form, M17 message, SC1 payment application screen, SC2 financial institution screen, SC3 balance management screen.

Claims (13)

A transfer information acquisition unit that acquires transfer information indicating the type of transfer in a transfer to a user , where the transfer is to a vendor-issued number issued by the vendor ,
A deposit execution unit that, when the transfer type indicated by the transfer information is not a salary transfer or a bonus transfer, does not execute a deposit into the first balance for salary or bonus in the user's electronic payment method, and executes the deposit into the first balance when the transfer type indicated by the transfer information is a salary transfer or a bonus transfer,
A deposit system that includes this. The deposit execution unit executes a deposit to a second balance, which is different from the first balance, if the transfer type indicated by the transfer information is not the salary transfer or the bonus transfer.
The deposit system according to claim 1. The deposit system further includes a setting reception unit that receives from the user the setting regarding the deposit to the second balance, which concerns whether to transfer the funds to a designated account specified by the user or deposit them into the second balance when the transfer type indicated by the transfer information is not a salary transfer or a bonus transfer .
The deposit execution unit executes a deposit to the second balance based on the setting if the transfer type indicated by the transfer information is not the salary transfer or the bonus transfer.
The deposit system according to claim 2. The deposit system further includes a designated account transfer unit that, when the transfer type indicated by the transfer information is not the salary transfer or the bonus transfer, executes a designated account transfer process for a transfer to a designated account specified by the user.
The deposit system according to claim 1. The deposit system further includes a display control unit that causes the user's terminal to display a balance screen that distinguishes between the first balance and the second balance.
The deposit system according to claim 2 or 3 . The display control unit displays a balance screen that distinguishes between the first balance, the second balance which cannot be withdrawn, and the second balance which can be withdrawn.
The deposit system according to claim 5. The aforementioned first balance is withdrawable.
The deposit system according to claim 6. The transfer information acquisition unit acquires the transfer information for the transfer to the user's virtual account.
A deposit system according to any one of claims 1 to 4. The aforementioned transfer information acquisition unit acquires the transfer information contained in FB (Firm Banking) data or IB (Internet Banking) data.
A deposit system according to any one of claims 1 to 4. If the deposit execution unit causes the first balance to exceed the upper limit when a deposit is made to the first balance, it deposits into the first balance an amount from the transfer information that does not exceed the upper limit.
The deposit system further includes a designated account transfer section that, when a deposit is made to the first balance, transfers the amount exceeding the upper limit to a designated account if the first balance exceeds the upper limit.
A deposit system according to any one of claims 1 to 4. A transfer information acquisition unit that acquires transfer information indicating the type of transfer in a transfer to a user,
A deposit execution unit that, when the transfer type indicated by the transfer information is not a salary transfer or a bonus transfer, does not execute a deposit into the first balance for salary or bonus in the user's electronic payment method, and executes the deposit into the first balance when the transfer type indicated by the transfer information is a salary transfer or a bonus transfer,
Includes,
The aforementioned deposit execution unit,
If a deposit to the first balance would cause the first balance to exceed the upper limit, the amount of the transfer indicated in the transfer information that does not exceed the upper limit shall be deposited into the first balance, and the amount exceeding the upper limit shall be deposited into the settlement means as a reserved amount.
Deposit system. Computers
A transfer information acquisition step involves obtaining transfer information indicating the type of transfer in a transfer to a user , where the transfer is to a vendor-issued number issued by the vendor .
A deposit execution step in which, if the transfer type indicated by the transfer information is not a salary transfer or a bonus transfer, the deposit is not made to the first balance for salary or bonus in the user's electronic payment method, and if the transfer type indicated by the transfer information is a salary transfer or a bonus transfer, the deposit is made to the first balance.
A deposit method to execute this. A transfer information acquisition unit that acquires transfer information indicating the type of transfer in a transfer to a user , where the transfer is to a vendor-issued number issued by the vendor .
If the transfer type indicated by the transfer information is not a salary transfer or a bonus transfer, the deposit execution unit does not execute the deposit into the first balance for salary or bonus in the user's electronic payment method, and if the transfer type indicated by the transfer information is a salary transfer or a bonus transfer, the deposit execution unit executes the deposit into the first balance.
A program that makes a computer function.