Deposit system, deposit methods, and program

Abstract

To provide a deposit system executing an appropriate deposit to electronic settlement means of users.SOLUTION: A transfer type acquisition part (101) of a deposit system (1) acquires transfer information representing a transfer type in transfer in which an account number of a user is specified as a transfer destination. A necessity determination part (102) determines whether or not it is necessary to deposit money into electronic settlement means of the user based on the transfer type represented by the transfer information. When the necessity determination part determines that the deposit is necessary, a deposit execution part (104) executes the deposit according to the transfer amount in the transfer.SELECTED DRAWING: Figure 6

Description

Technical Field

[0001] The present disclosure relates to a payment system, a payment method, and a program.

Background Art

[0002] Conventionally, technologies for promoting cashless payment using electronic payment means (e.g., electronic money or virtual currency) are known. For example, in Patent Document 1, when a law amendment enabling payment of wages to employees by depositing into electronic money is carried out in Japan, a financial infrastructure system that can respond to the law amendment by using base money that enables deposit into conventional electronic money is described.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the above-described technology, a deposit into an electronic payment means may be executed based on a transfer in which a user's account number is specified as the transfer destination. Taking the payment of wages described in Patent Document 1 as an example, when a company, which is an employer, makes a transfer designating an employee's account number as the transfer destination, a deposit into the employee's electronic money may be executed. Among such transfers, there are not only transfers of wages to employees but also transfers of non-wages (e.g., advances, etc.), and thus it is required to appropriately manage electronic money by distinguishing these. This point is not limited to wage digital payments and electronic money such as in Patent Document 1, but also applies to transfers other than wages and electronic payment means in general.

[0005] One of the purposes of this disclosure is to ensure that appropriate payments are made to users' electronic payment methods. [Means for solving the problem]

[0006] 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 in which the user's account number is designated 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; and a deposit execution unit that, if the necessity determination unit determines that the deposit is necessary, executes the deposit in accordance with the amount of the transfer. [Effects of the Invention]

[0007] According to this disclosure, appropriate deposits can be made to the user's electronic payment method. [Brief explanation of the drawing]

[0008] [Figure 1] This figure shows an example of the hardware configuration of the deposit system in the first embodiment. [Figure 2] This figure shows an example of the overview of the deposit system in the first embodiment. [Figure 3] This figure shows an example of the procedure that a user who wishes to receive digital payroll in the first embodiment would follow. [Figure 4] This figure shows an example of the procedure that a user who wishes to receive digital payroll in the first embodiment would follow. [Figure 5] This diagram shows an example of an electronic money balance. [Figure 6] This figure shows an example of the functions implemented in the deposit system of the first embodiment. [Figure 7] This is a diagram showing an example of an electronic money database. [Figure 8] This figure shows an example of a workplace database. [Figure 9] This is a diagram showing an example of a bank transfer database. [Figure 10]It is a diagram showing an example of a virtual account database. [Figure 11] It is a diagram showing an example of the processing executed in the payment system of the first embodiment. [Figure 12] It is a diagram showing an example of the processing executed in the payment system of the first embodiment. [Figure 13] It is a diagram showing an example of the system configuration in the second embodiment. [Figure 14] It is a diagram showing an example of the outline of the payment system in the second embodiment. [Figure 15] It is a diagram showing an example of the functions realized by the payment system of the second embodiment. [Figure 16] It is a diagram showing an example of a vendor database. [Figure 17] It is a diagram showing an example of the processing executed in the payment system of the second embodiment. [Figure 18] It is a diagram showing an example of the processing executed in the payment system of the second embodiment. [Figure 19] It is a diagram showing an example of the functions in a modification example. [Figure 20] It is a diagram showing an example of a notice regarding the execution of the designated account transfer process. [Figure 21] It is a diagram showing an example of a balance management screen. [Figure 22] It is a diagram showing an example of a notice to the requester in a transfer. [Figure 23] It is a diagram showing an example of a notice prompting the use of the balance. [Embodiments for Carrying Out the Invention]

[0009] [1. First Embodiment] An example of an embodiment of a payment system, a payment method, and a program according to the present disclosure, the first embodiment, will be described.

[0010] [1-₁. Hardware Configuration of the Payment System in the First Embodiment] Figure 1 shows an example of the hardware configuration of a 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.

[0011] For example, deposit system 1 includes deposit server 10. Deposit server 10 is a server computer of a business operator that handles 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.

[0012] 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, wherever "electronic money" is written, it can be interpreted as any payment method that allows deposits. For example, a payment method has the concept of a balance. Credit cards, debit cards, and points are not depositable, so wherever "electronic money" is written, it can be interpreted as a prepaid payment method, cryptocurrency, account, wallet, or other depositable payment method.

[0013] 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.

[0014] 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 inputting and outputting data with external devices (e.g., a USB port).

[0015] 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.

[0016] Employment System 2 is the system of the employer of a user who uses electronic money. In the first embodiment, a company is described as an example of an employer, but the employer is not limited to a company and can be any entity that pays the user a salary. For example, the employer may be a sole proprietorship, a local government, a non-profit corporation, or any other organization. For example, Employment System 2 includes an employer server 20 and an employer terminal 24. Note that Employment System 2 may include at least one computer and is not limited to the example in Figure 1. This is the same as in the deposit system 1.

[0017] 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.

[0018] 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 configuration of the control unit 25, the storage unit 26, and the communication unit 27 may be the same as that of the control unit 11, the storage unit 12, and the 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.

[0019] 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, a securities company, a cooperative, a labor bank, or other institution. For example, Financial Institution System 3 includes a Financial Institution Server 30. Note that Financial Institution System 3 may include at least one computer and is not limited to the example in Figure 1. This is the same as in the deposit system 1.

[0020] For example, the financial institution server 30 is a server computer of 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, the storage unit 32, and the communication unit 33 may be the same as those of the control unit 11, the storage unit 12, and the communication unit 13, respectively. The 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.

[0021] The user terminal 40 is the user's computer. For example, the user terminal 40 is a personal computer, smartphone, tablet, or wearable device. Although only one user terminal 40 is shown in Figure 1, there may be user terminals 40 for each of multiple users. 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 configuration of the control unit 41, storage unit 42, communication unit 43, operation unit 44, and display unit 45 may be the same as that 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.

[0022] [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 prescribed 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).

[0023] Figures 3 and 4 show 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 placed at the electronic money merchant read the code C10, the payment is executed based on the payment method that has been set as the payment source in advance. 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.

[0024] 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 type. For example, electronic money may be of a type in which information such as the balance is written to the IC chip of the user terminal 40, a type in which information such as the balance is written to the IC card, a type in which information such as the balance is written to the magnetic card, a type that is completed solely by biometric authentication such as facial recognition, or other types.

[0025] For example, if the user selects button B11, the user terminal 40 displays the details of the digital salary payment procedure on the payment app screen SC1, as shown in the upper right of Figure 3. If 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 take as an example the case where the user performs the procedure for opening a virtual account at a financial institution and the procedure for registering a designated account from the payment app, but these procedures may be performed by someone other than the user, such as the employer.

[0026] A virtual account is an account used solely 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 the same as a regular real account except that it is associated with a virtual account. A virtual account may also have a withdrawal function.

[0027] 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 for transferring funds that the user cannot receive in the digital salary payment system of the first embodiment. The designated account may be an account at the same financial institution where the virtual account was opened, or it may be an account at a different financial institution. The user can designate an account at any financial institution as the designated account.

[0028] 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 is opened. 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 has been opened. 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.

[0029] For example, if the user selects button B14 while the payment app screen SC1 is in the upper right corner, 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. After the registration of the designated account is complete, 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.

[0030] 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 it is time 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 will use FB data as an example.

[0031] 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 name, transfer date, source information, recipient information, and transfer amount.

[0032] For example, the employer server 20 sends 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 publicly 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.

[0033] For example, the deposit server 10 uses an API to obtain transfer information from the financial institution server 30 regarding salary transfers subject to digital salary payment. The transfer information includes all or part of the FB data. For example, the transfer information shows the remitter name (remitter name), recipient, transfer type, and transfer amount. If the remitter name is different from the remitter name, both the remitter name and the remitter name may be included in the transfer information. This disclosure describes the case where both the remitter 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. The transfer information may also be in FB data format or 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.

[0034] In the first embodiment, the deposit server 10 executes a deposit to electronic money 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 a transfer to the designated account. If a transfer of an advance payment or other payment other than salary is executed, the transfer type will be a general transfer. The transfer type may not be specified.

[0035] 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 may 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 so that it cannot be withdrawn.

[0036] Hereafter, the first balance will be referred to as the salary balance. The second balance will be referred to as the non-salary balance. In the first embodiment, it is assumed that there are two types of electronic money balances: 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 shopping limit of a credit card, the basic balance (15,000 yen in the example in Figure 5) increases. When electronic money is charged based on the cash advance limit of a credit card, sales proceeds from an online shopping mall, 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.

[0037] For example, if the transfer type is salary transfer or bonus transfer, and the 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 amount deposited into the salary balance would exceed the upper limit, the deposit server 10 deposits the amount of the transfer 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.

[0038] For example, suppose users U1 to U3, each an employee of a certain company, have each applied for digital payroll. Suppose the maximum salary balance limit is 100,000 yen. Suppose user U1's current salary balance is 20,000 yen. Suppose the type of transfer made to user U1 is a salary transfer. Suppose the amount of the transfer is 30,000 yen. In this case, adding the transfer amount of 30,000 yen to user U1's current salary balance of 20,000 yen does not exceed the limit. Therefore, the entire transfer amount of 30,000 yen will be deposited into user U1's salary balance.

[0039] 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 amount of the transfer 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, which is part of the transfer amount, is deposited into user U2's salary balance so that the salary balance reaches the upper limit. The remaining 30,000 yen of the transfer amount that exceeds the upper limit is deposited into user U2's designated account.

[0040] 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 will not be made to user U3's salary balance. Regardless of user U3's current salary balance, the entire transfer amount will be deposited into user U3's designated account.

[0041] 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 type of transfer. 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 not necessary, it executes a transfer to the designated account. In this way, the deposit system 1 can execute an appropriate deposit to the user's electronic money. The details of the deposit system 1 will be described below.

[0042] [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.

[0043] [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.

[0044] [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.

[0045] 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, and 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.

[0046] A user ID is an example of user identification information that can identify a user. Therefore, wherever "user ID" is written, it can be read as "user identification information." User identification information is not limited to a user ID; it may be any 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.

[0047] Balance information is information that shows the balance of electronic money. In the first embodiment, the balance information shows the salary balance, the premium balance of the non-salary balance, and the basic balance of the non-salary balance. 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.

[0048] History information is information that shows the history of each deposit and use of electronic money. For example, history information shows the date and time of deposit, deposit method, deposit type, deposit amount, and at least one of the balance after deposit. History information shows the date and time of use of electronic money, location of use, amount used, balance after use, and at least one of the location of use. History information is updated when a deposit is made to electronic money. History information is also updated when electronic money is used.

[0049] 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's name for 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.

[0050] 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's name for 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.

[0051] 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 the data necessary for the user to perform the procedures shown in Figures 3 and 4. The data storage unit 100 only needs to store the data necessary for the processing performed by the deposit server 10 (for example, the upper limit of the salary balance).

[0052] [Transfer Information Acquisition Section] 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 arrives (for example, the user's payday at their workplace, or a day before payday).

[0053] For example, the deposit server 10 periodically or irregularly queries the financial institution system 3 to determine whether or not a transfer has been made to the user's virtual account. When the financial institution system 3 receives an inquiry from the deposit server 10, it determines whether or not a transfer has been made to the user's virtual account based on the transfer database DB3 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 sends the transfer information to the deposit server 10. The transfer information acquisition unit 101 acquires 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.

[0054] For example, when multiple users' account numbers are specified as recipients for transfers and these transfers are executed simultaneously, the transfer information acquisition unit 101 identifies the type of transfer for each of the multiple 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 in a branch name that can identify electronic money, such as "AAA Cash Branch," but the virtual account may be opened in a regular branch.

[0055] 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 performed by the financial institution server 30. This process itself may be a process used in publicly known virtual accounts.

[0056] 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.

[0057] [Necessity determination section] The necessity determination unit 102 determines whether or not a deposit is necessary for the user to make to their electronic money, based on the type of transfer identified by the transfer information acquisition unit 101. The necessity of a deposit is whether or not to make 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 one of the predetermined types. The necessity determination unit 102 determines that a deposit to the electronic money is necessary if the type of transfer is one of the predetermined types. 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.

[0058] In the first embodiment, the necessity determination unit 102 determines that a deposit to the electronic money 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 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 is unnecessary if the transfer type indicates a general transfer, or if the transfer type is unknown (if the transfer type is not specified, or if there is no transfer type at all).

[0059] 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.

[0060] [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 any other balance. 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.

[0061] 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 depending on the user. The upper limit determination unit 103 calculates the sum of the transfer amount in the transfer 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 the sum exceeds the upper limit.

[0062] [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 into the electronic money (charge amount) 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 like that of 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 into the salary balance.

[0063] 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 an electronic money service provider that handles electronic money. The parent account is common to each virtual account of multiple users. 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, when the necessity determination unit 102 determines that a deposit is necessary. The deposit execution unit 104 executes a deposit to the electronic money using the balance of the parent account as the source of funds. The process of executing a deposit to electronic money based on a financial institution account may be the same as the process used for charging known electronic money.

[0064] Furthermore, the parent account may not be held by an electronic money provider that handles electronic money, but by someone else (for example, the user's employer, or a vendor that collaborates with the electronic money provider). In addition, the deposit execution unit 104 may execute a deposit to electronic money based on an account other than the parent account that is not associated with the virtual account. The deposit execution unit 104 may execute a deposit to electronic money based on an account at a financial institution other than the financial institution of the financial institution system 3. The deposit execution unit 104 may execute a deposit to electronic money based on a payment method other than an account.

[0065] For example, the deposit execution unit 104 executes a deposit to the electronic money so that the transfer amount is deposited into the electronic money if 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. If a fee is incurred when depositing into the electronic money, the deposit execution unit 104 may execute a deposit to the electronic money so that the amount deposited into the electronic money is the transfer amount minus the fee.

[0066] 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 in the electronic money and the upper limit. The deposit execution unit 104 executes the deposit to the electronic money so that the salary balance in the electronic money increases by the difference. In other words, the deposit execution unit 104 executes the deposit to the electronic money so that the salary balance after the deposit matches the upper limit. The deposit execution unit 104 may also execute the deposit to the electronic money so that the salary balance after the deposit is less than the upper limit.

[0067] [Designated Account Transfer Section] 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.

[0068] 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, but 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.

[0069] For example, the designated account transfer unit 105 executes a designated account transfer process to transfer the amount exceeding the upper limit of the transfer amount 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 also execute the designated account transfer process so that the amount transferred to the designated account is the amount that the user should have received minus the transfer fee.

[0070] [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.

[0071] [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.

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

[0073] 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 financial institution code, financial institution name, branch code, branch name, account type, account number, and account holder name. Since some employees do not wish to receive their salaries digitally, the transfer destination information does not necessarily represent a virtual account. The transfer destination information 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 shall be specified by the person in charge of salary transfers at the workplace.

[0074] [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 (e.g., 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.

[0075] [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 the tools that the person in charge uses to register users' payroll information.

[0076] [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.

[0077] [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 bank transfer information stored in the workplace database DB2 is updated.

[0078] [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.

[0079] [Data Storage Unit] The data storage unit 300 stores the data necessary for making 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.

[0080] 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 the FB data was received, and the FB data itself. The transfer database DB3 only needs to store any information related to transfers, and the information stored in the transfer database DB3 is not limited to the example in Figure 9. For example, information about transfers received from sources other than one's employer may be stored in the transfer database DB3.

[0081] Figure 10 shows an example of a virtual account database DB4. The virtual account database DB4 is a database that stores various information about virtual accounts opened at a financial institution. For example, the virtual account database DB4 stores virtual account information about the virtual account and parent account information about the parent account associated with that virtual account. The virtual account database DB4 only needs to store some kind of information about the virtual account, and 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.

[0082] For example, virtual 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's name for the virtual account. Parent 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's name for the parent account. When a user opens a virtual account, the virtual account opening unit 301 generates virtual account information for that virtual account and stores it in the virtual account database DB4 in association with the parent account information. One 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.

[0083] [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.

[0084] [Bank Transfer Reception 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.

[0085] [Transfer Information Transmission Section] 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.

[0086] [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.

[0087] [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 the payment application or browser for displaying various screens such as the payment application screen SC1.

[0088] [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.

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

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

[0091] 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. 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 be executed between the deposit server 10 and the financial institution server 30.

[0092] When a user's virtual account is opened in S100, information about 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. Information about the user's designated account 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.

[0093] When the payment date for salary or bonus at the workplace approaches, the workplace server 20 generates FB data based on the workplace database DB2 (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 in advance in the payment database DB3 any details that fall under the category of bulk payments such as advance payments. The workplace server 20 sends 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.

[0094] 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 transfer to the virtual account of the "AAA Cash Branch". When the financial institution server 30 receives the request from the deposit server 10 (S106), it 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 salary payments, the deposit server 10 receives the transfer information for each of the multiple users in S109.

[0095] The deposit server 10 determines whether a deposit to the electronic money is necessary based on the transfer type indicated by the transfer information (S110). If it is determined that a deposit to the electronic money is necessary (the transfer type is salary transfer or bonus transfer) (S110: necessary), the deposit server 10 determines whether the user's salary balance exceeds the upper limit based on the electronic money database DB1 (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 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 in S116 described 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.

[0096] In S111, if it is determined that the user's salary balance exceeds the upper limit (S111:Y), the process moves to Figure 12, where the deposit server 10 executes a deposit to the electronic money 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. If the user's salary balance has already reached the upper limit at the time of S111, the process in S113 is not executed, and the transfer in the process in S114 is executed for the entire transfer amount.

[0097] In S110, if it is determined that no deposit is required for the electronic money (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 or not there are any transfers that have not yet been processed (S116). If it is determined that there are any transfers that have not yet been processed (S116:Y), the process returns to S110. If it is determined that there are no transfers that have not yet been processed (S116:N), this process ends.

[0098] [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.

[0099] 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 enables deposit system 1 to implement a mechanism for executing appropriate deposits to electronic money using a virtual account system. For example, electronic money providers can securely manage funds in a parent account before depositing them to electronic money.

[0100] 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 in a parent account where it is the account holder. For example, this makes it easier for electronic money service providers to manage funds that are eligible for digital salary payments.

[0101] Furthermore, deposit system 1 determines that a deposit is not necessary if the transfer type does not indicate a salary transfer or a bonus transfer. Deposit system 1 determines that a deposit is necessary if the transfer type indicates a salary transfer or a bonus transfer. In this way, deposit system 1 can perform appropriate deposits in digital salary payments by distinguishing between salary and non-salary payments for the user's electronic money. For example, deposit system 1 can prevent deposits other than salary from occurring in the salary balance. Deposit system 1 can prevent salary deposits from occurring in other balances (for example, a basic balance that cannot be withdrawn).

[0102] 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.

[0103] 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 exclude the non-salary portion of a transfer in advance. The deposit system 1 can reliably deposit only those transfers that are classified as salary transfers or bonus transfers as electronic money. For example, when a salary transfer is made via ATM, the person in charge at the workplace cannot select the transfer type. As a result, salary transfers made via ATM may all be treated as "non-salary (general)." In this case, if electronic money is granted as non-salary, it may become impossible to properly manage what should rightfully be salary. Therefore, the deposit system 1 transfers the funds to the user's designated account without granting electronic money based on non-salary. By providing a mechanism to grant electronic money based on salary, the deposit system 1 enables more appropriate management of electronic money.

[0104] Furthermore, when a deposit is deemed necessary, deposit system 1 determines whether the deposit will cause the balance to exceed the upper limit. If 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. In this way, deposit system 1 can set a limit on the salary balance of the electronic money. For example, deposit system 1 can prevent the salary balance from exceeding a rule set by the government or administrative body. If the amount of guarantee that the electronic money business operator must guarantee is determined by the upper limit of the salary balance, deposit system 1 can set the upper limit to an appropriate amount, thereby ensuring that the guarantee amount is appropriate.

[0105] 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 will then execute 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 properly manage the salary limit.

[0106] [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.

[0107] 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.

[0108] 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, the storage unit 52, and the communication unit 53 may be the same as those of the control unit 11, the storage unit 12, and the 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.

[0109] [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.

[0110] For example, a vendor-issued number uses a numbering system similar to that of an account at a financial institution. The 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 an account at a financial institution. 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 that of an account at a financial institution. The vendor-issued number itself may be a publicly known number.

[0111] The overall flow in the second embodiment is generally the same as the overall flow in the first embodiment. However, the overall flow in the second embodiment differs from the overall flow in 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 flow 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.

[0112] The vendor server 50 can use publicly known processes 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 the vendor-issued numbers of other users. The vendor server 50 transmits the issued vendor-issued number to the user terminal 40. The vendor server 50 may also transmit the issued vendor-issued number to the workplace system 2 along with user identification information such as the user's employee number.

[0113] For example, in order to implement digital salary payments using vendor-issued numbers, a source of funds is needed for users to deposit 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 such 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.

[0114] 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. When 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.

[0115] For example, the financial institution server 30 retrieves the financial institution's portion of the FB data from all employees of the workplace. The coordination between the deposit server 10 and the financial institution server 30 may be the same as in the first embodiment, so it is omitted in Figure 14. The vendor server 50 retrieves the portion of the vendor's FB data that has a specified vendor issuance number from all employees of the workplace. The deposit server 10 requests transfer information from the vendor server 50 using an API. When the vendor server 50 receives the request from the deposit server 10, it generates transfer information based on the FB data. The vendor server 50 sends the transfer information to the deposit server 10.

[0116] 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 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.

[0117] For example, the person in charge of payroll at a workplace modifies the FB data as needed. The process after the FB data has been 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 does not think that the FB data needs to be modified, 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.

[0118] In the second embodiment, the electronic money service provider that handles electronic money has opened its own 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.

[0119] [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.

[0120] 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 number. Alternatively, for example, one employer may use the virtual account method (method of the first embodiment) and another employer may use the vendor method (method of the second embodiment), so both methods may coexist. The deposit system 1 may be able to support both methods.

[0121] [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.

[0122] [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.

[0123] [Transfer Information Acquisition Section] 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 the 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 regarding the user's vendor-issued number to the deposit server 10 based on the vendor database DB6 described later.

[0124] For example, the vendor system 5 receives transfer information from the workplace server 20 and sends 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 of this fact.

[0125] For example, the transfer information acquisition unit 101 may acquire transfer information from the vendor system 5 before the scheduled date of the transfer. The scheduled date can also be called the reservation date for the transfer. For example, for salary transfers, it is the 25th of each month. The FB data is assumed to specify the scheduled date of the transfer. 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 on which the transfer information is acquired may be predetermined. The transfer information acquisition unit 101 may also acquire the transfer information on the scheduled date.

[0126] [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 only need to be predetermined. The error conditions only need to be conditions that can be determined based on the transfer information. For example, the error conditions are 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.

[0127] In the second embodiment, examples of error conditions will be explained, including when the salary balance exceeds the upper limit and when the transfer type is not a salary transfer or a bonus transfer. Specifically, an example will be given where an error occurs if the deposit to the electronic money cannot be executed, or if only a portion of the transfer amount can be deposited into the electronic money. 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.

[0128] For example, the error determination unit 106 determines whether the transfer type for a transfer to 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 not a salary transfer or a bonus transfer, it determines that an error occurs.

[0129] 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 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 the transfer type is not a salary transfer or a bonus transfer.

[0130] Furthermore, the error conditions may be any conditions 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, for example, the error conditions may be whether the deposit determined by the deposit determination unit 108 described later is sufficient, or whether the amount determined by the transfer determination unit 109 described later is sufficient. In this case, the error determination unit 106 has the same function as the deposit determination unit 108 or the transfer determination unit 109.

[0131] [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.

[0132] [Deposit Determination Unit] For example, if a deposit is made to a vendor-related account by the remitter in a transfer 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 of the vendor-related account (total amount of deposit). 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 the deposit indicated by this information with the total amount of the transfer in the current transfer.

[0133] [Transfer Determination Unit] For example, if a transfer is received in a vendor-related account and the transfer amount is subsequently transferred by the remitter, 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 determines whether or not the transfer has been made by comparing the transfer history shown in this information with the total amount of the transfer and the name of the remitter in the current transfer. 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.

[0134] [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.

[0135] 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 does not determine that the deposit is sufficient, the deposit execution unit 104 does not execute the deposit based on that deposit.

[0136] For example, the deposit execution unit 104 executes a 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 a deposit based on the balance of the vendor-related account.

[0137] [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.

[0138] [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.

[0139] Figure 16 shows an example of a vendor database DB6. The vendor database DB6 is a database that stores various information necessary to facilitate 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, and the information stored in the vendor database DB6 is not limited to the example in Figure 16. For example, information about the employer may be stored in the vendor database DB6.

[0140] [Number Issuance Department] The number issuing unit 501 issues a vendor-issued number for 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.

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

[0142] [Transfer Information Transmission Section] 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 DB6. The transfer information transmission unit 503 transmits the transfer information based on all or part of the FB data stored in the transfer database DB5. 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.

[0143] [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, financial institution system 3, vendor system 5, and 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.

[0144] As shown in Figure 17, the user terminal 40 launches the payment application and performs a process to issue the user's vendor-issued number to the vendor server 50 (S200). When 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 a 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.

[0145] 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.

[0146] The deposit server 10 determines whether an error occurs based on the transfer information (S210). If it is determined that no error occurs (S210:N), the process proceeds to S223, described below. If it is determined in S210 that an error has occurred (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).

[0147] Moving to Figure 18, the workplace server 20 accepts the correction of 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). The following S218 to S222 are the same as S205 to S209, respectively. The subsequent S223 to S229 are the same as S110 to S116, respectively. Note that the timing at which 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, transfer information may be generated after error detection and error correction are completed.

[0148] [2-4. Summary of the Second Embodiment] In the second embodiment, the deposit system 1 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. This enables the deposit system 1 to implement a mechanism for executing 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.

[0149] 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 an error will occur in the transfer. If the deposit system 1 determines that an error will occur, it executes a correction request process to request the correction of the error in the transfer. The correction request process makes it less likely for errors to occur.

[0150] 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.

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

[0152] [3. Variant] 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.

[0153] 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.

[0154] [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.

[0155] 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 a 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.

[0156] 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 thereof. The notification may also include information similar to that which is viewable by users in well-known financial applications or websites.

[0157] 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 a designated account transfer process has been executed. For example, it prevents a user from mistakenly believing that their salary was not paid because their electronic money salary balance has not increased, even though their salary was paid via digital salary payment. The user can be aware that their salary has been paid through a transfer to their designated account.

[0158] [3-2. Variation 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.

[0159] Figure 21 shows an example of a balance management screen. In Modification 2, the example shows that when the user selects button B12 on the payment application screen SC1, the balance management screen SC3 is displayed. However, the balance management screen SC3 may be displayed when other operations are performed. The balance management screen SC3 should be displayed only when the user performs an operation to display the balance management screen SC3. 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 history of deposits to the user's designated account is stored in the electronic money database DB1 or another database. When a transfer is executed to the user's designated account, the deposit server 10 obtains data showing the history of the transfer from the financial institution server 30 and records the data in the data storage unit 100.

[0160] 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.

[0161] 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 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 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.

[0162] In Modification 2, the deposit system 1 displays on the balance management screen SC3 that a designated account transfer has been executed. This allows the user to be aware that a designated account transfer has been executed. For example, it prevents a user from mistakenly believing that their salary was not paid because their electronic money salary balance has not increased, even though their salary was paid via digital salary payment. The user can be aware that their salary has been paid by a transfer to the designated account. For example, even if the money is not deposited as electronic money, it may be displayed on the balance management screen SC3 as if it had been deposited and then withdrawn, in which case user convenience is further improved.

[0163] [3-3. Modified Example 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 notifies the transfer requester in the transfer to refrain from making transfers of types that are determined not to require payment.

[0164] 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 the method of transferring their salary. The employer's email address is 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.

[0165] In Modification 3, the deposit system 1 notifies the transferor of the transfer request based on the execution result of the designated account transfer process, urging them not to make 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 have 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 ask them not to make the non-salary transfer.

[0166] [3-4. Modification 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.

[0167] The deposit system 1 of the modified example 4 includes a setting reception unit 113. The setting reception unit 113 receives settings from the user regarding whether to transfer the funds to a designated account specified by the user when the necessity determination unit 102 determines that a deposit is unnecessary, or to deposit the funds into the basic balance and premium balance in that case. The user's settings are stored in the electronic money database DB1. For example, the user specifies the 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.

[0168] In variation 4, the deposit server 10 refers to the user's settings if it determines that the transfer type does not indicate a salary transfer or a bonus transfer. The deposit execution unit 104 executes a deposit to the second balance if the settings received from the user indicate a second balance. The method for executing the deposit to the second balance can utilize publicly known processes. In the case of 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.

[0169] 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, but the details of the designated account transfer process are as described in the first embodiment.

[0170] 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 will be deposited into electronic money, and if the transfer amount exceeds 10,000 yen, it will be 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.

[0171] 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.

[0172] [3-5. Variation 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.

[0173] 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. Although it differs from the first and second embodiments in that there are first and second upper limits, the determination method of the upper limit determination unit 103 itself is the same as in the first and second embodiments.

[0174] 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. Although it differs from the first and second embodiments in that there are first and second upper limits, the processing of the designated account transfer unit 105 itself is the same as in the first and second embodiments.

[0175] 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.

[0176] In Modification 5, the deposit system 1 determines whether the deposit will cause the salary balance to exceed the second upper limit when it is determined that a deposit is necessary. If the deposit system 1 determines that the salary balance will exceed the second upper limit, it executes a transfer to a designated account. In this way, the deposit system 1 can impose a second upper limit on the salary balance of electronic money.

[0177] [3-6. Modification 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.

[0178] 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 a message M18 on the payment app screen SC1 of the payment app, indicating that the user should use their balance. The data for the notification is stored 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 app, email, SMS, push notification, banner notification, or other notification means.

[0179] In Modification 6, the deposit system 1 determines whether the balance will exceed the first upper limit after the deposit is made, when it is determined that a deposit is 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 provide the user with an incentive to actively use their salary balance, making it less likely that the salary balance will exceed the second upper limit before the salary is transferred.

[0180] [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 an appropriate amount that the user 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 an appropriate amount to the user as a transfer based on past performance of designated account transfer processing.

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

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

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

[0184] For example, deposit system 1 may, based on the user's electronic money withdrawal history, deposit the amount exceeding the upper limit into the electronic money balance as a reserve amount for a certain period, rather than transferring it to the designated account. 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 setting options to the user based on the user's electronic money withdrawal history. Deposit system 1 may also set different point multipliers for electronic money usage 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 the salary balance is used than when other balances are used.

[0185] 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.

[0186] [4. Addendum] For example, the payment system related to this disclosure can also be configured as follows: (1) A transfer information acquisition unit that 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 in accordance with 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. (1) The deposit system described above. (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. (1) The deposit system described above. (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 deposit 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 deposit 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 is one of the options listed in (9) to (11). (13) The aforementioned payment 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 a 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 deposit 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 deposit 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 deposit system is one of the options listed in (15) to (17). [Explanation of Symbols]

[0187] 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

1. 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.

2. 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.

3. 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.

4. 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.

5. The deposit system further includes a display control unit that causes the user's terminal to display a balance screen on which the first balance and the second balance are distinguished. The deposit system according to claim 2 or 3.

6. 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.

7. The aforementioned first balance is withdrawable. The deposit system according to claim 6.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

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. 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.

Images