JP7730396B2 - Management device, management method, and management program - Google Patents

Description

The present invention relates to a management device, a management method, and a management program.

Conventionally, electronic payment services that use digital money such as electronic money or virtual currency to make payments have been known. For example, one type of electronic payment service is a method of making payments by displaying or reading a two-dimensional code or the like using a terminal device carried by the user (e.g., smartphone payment).

In recent years, "digital salary payments" have been proposed as an electronic payment service that allows salary payments using digital money.

Patent No. 6513861

The above conventional technologies have room for further improvement in terms of promoting the use of electronic payment services that support digital salary payments.

This application has been made in light of the above, and aims to provide a management device, management method, and management program that can promote the use of electronic payment services that support digital salary payments.

The management device according to the present application has an acquisition unit, a deposit acceptance unit, and a sorting processing unit. The acquisition unit acquires user information related to users who use specified payment methods. The deposit acceptance unit accepts deposits of digital money into a payment account owned by the user, into which digital money as salary and digital money other than salary that has been charged by the user or digital money as profits earned through electronic commerce are deposited, and the total balance of deposited digital money is managed separately into a salary balance nominally representing salary and a non-salary balance nominally representing other than salary. The sorting processing unit sorts a portion of the digital money deposited by the deposit acceptance unit based on the user information acquired by the acquisition unit.

One aspect of this embodiment has the effect of promoting the use of electronic payment services that support digital salary payments.

FIG. 1 is a diagram illustrating an example of a management process according to the first embodiment. FIG. 2 is a diagram illustrating an example of electronic payment processing according to the first embodiment. FIG. 3 is a diagram illustrating an example of the configuration of the payment server according to the first embodiment. FIG. 4 is a diagram illustrating an example of an account database according to the first embodiment. FIG. 5 is a diagram showing an example of a deposit request according to the first embodiment. FIG. 6 is a diagram showing an example of a withdrawal request according to the first embodiment. FIG. 7 is a diagram showing an example of a screen of a user terminal according to the first embodiment. FIG. 8 is a flowchart showing an example of the procedure of the deposit process in the management process according to the first embodiment. FIG. 9 is a flowchart showing an example of the procedure of the withdrawal process in the management process according to the first embodiment. FIG. 10 is a diagram illustrating an example of a management process according to the second embodiment. FIG. 11 is a diagram illustrating an example of the configuration of the payment server according to the second embodiment. FIG. 12 is a diagram illustrating an example of an account database according to the second embodiment. FIG. 13 is a diagram illustrating an example of a history database according to the second embodiment. FIG. 14 is a diagram illustrating an example of a registration information database according to the second embodiment. FIG. 15 is a diagram illustrating an example of a billing information database according to the second embodiment. FIG. 16 is a diagram showing an example of a screen of a user terminal according to the second embodiment. FIG. 17 is a flowchart showing an example of a procedure for a sorting information registration process in the management process according to the second embodiment. FIG. 18 is a flowchart showing an example of the procedure of the funds transfer process in the management process according to the second embodiment. FIG. 19 is a flowchart illustrating an example of a procedure for a settlement process in the management process according to the second embodiment. FIG. 20 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of the payment server.

Below, a detailed description will be given of a form for implementing the management device, management method, and management program according to the present application (hereinafter referred to as "embodiment") with reference to the drawings. Note that the management device, management method, and management program according to the present application are not limited to this embodiment. Furthermore, identical components in the following embodiments will be designated by the same reference numerals, and duplicate explanations will be omitted.

1. First embodiment
[1-1. Management process]
The management process implemented by the management device and the like according to the first embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the management process according to the first embodiment. In Fig. 1, it is assumed that the management process and the like according to the embodiment are implemented by a payment server 10, which is an example of the management device according to the first embodiment.

As shown in FIG. 1, the management system 1 according to the first embodiment includes a payment server 10, a user terminal 100, a payment source server 400, a bank server 600, and an ATM (Automatic Teller Machine) 800.

The payment server 10, user terminal 100, payment source server 400, and bank server 600 are connected to each other via a network N (see, for example, Figure 3) via wired or wireless communication. Network N is, for example, a wide area network (WAN) such as the Internet. Note that the management system 1 shown in Figure 1 may include multiple payment servers 10, multiple user terminals 100, multiple payment source servers 400, multiple bank servers 600, and multiple ATMs 800.

The payment server 10 is an information processing device that executes the management processing according to the first embodiment, and is realized by a server device, a cloud system, or the like. For example, the payment server 10 provides an electronic payment service related to electronic payments made by displaying or reading a predetermined code using the user terminal 100. For example, the payment server 10 manages digital money payment accounts owned by providers of transaction objects and users to whom transaction objects are provided, and realizes various payments by transferring digital money between payment accounts in accordance with payment information from users. Note that digital money may be, for example, points or currency used independently by various companies, or electronically tradable currencies provided by countries such as Japanese yen or dollars. The processing details of the electronic payment service performed via the payment server 10 will be described later.

The user terminal 100 is an information processing device used by a user. The user terminal 100 may be realized, for example, as a smartphone, tablet terminal, notebook PC (Personal Computer), desktop PC, mobile phone, or PDA (Personal Digital Assistant). Figure 1 shows an example in which the user terminal 100 is a smartphone.

The payment source server 400 is an information processing device used by a business that pays salaries to users, and is realized by a server device, cloud system, etc. For example, the payment source server 400 is a server device that belongs to the business that employs the user (hereinafter referred to as the "payer"). Note that the business that serves as the payer is not limited to a business (such as a company or corporation), but may also be a national government, prefecture, city, town, village, or other local government.

The user terminal 100 and payment source server 400 display the information delivered by the payment server 10 using a web browser or application.

Furthermore, when the user terminal 100 and payment source server 400 receive control information from the payment server 10 that enables specified information processing, they perform the information processing in accordance with the control information. Here, the control information is written in, for example, a scripting language such as JavaScript (registered trademark), a style sheet language such as CSS (Cascading Style Sheets), a programming language such as Java (registered trademark), or a markup language such as HTML (HyperText Markup Language). Note that the specified application itself distributed from the payment server 10 may also be considered as control information.

Bank server 600 is an information processing device belonging to a bank that manages users' bank accounts, and is realized by a server device, cloud system, etc. For example, bank server 600 manages, as bank account usage history, information regarding withdrawals from bank accounts by various card companies and various service providers (such as the amount withdrawn and the date and time of the withdrawal), current account information (such as the account balance), and other information associated with the user.

The bank server 600 is also connected to the ATM 800 via a network such as the Internet, either wired or wirelessly, allowing for mutual communication. The ATM 800 dispenses cash in accordance with user operations.

The payer, who is the user's employer, pays the user's salary on a regular basis (for example, once a month). The management system 1 according to the first embodiment supports so-called "digital salary payments," in which salary payments are made in digital money.

First, the payment server 10 receives a deposit request from the payment source server 400 (step S1). The deposit request includes identification information (payment destination identification information, hereafter referred to as "payment destination ID") of the user (payment destination) receiving the digital money deposit, the deposit amount, and the deposit name. Figure 1 shows an example of a deposit request that includes the payment destination ID "U1," the deposit amount "300,000 yen," and the name "salary."

Note that the payment recipient ID "U1" is the identification information of user U1 (user identification information, hereafter referred to as "user ID"). The user ID can be any information that can identify user U1, and can be numbers, letters, symbols, etc., or a combination of these, as well as, for example, a telephone number and email address, or a combination of a telephone number, email address, etc., and a name. The name can be written in kanji, hiragana, katakana, or the alphabet. The deposit request may also include identification information that identifies the source of payment (payment source identification information, hereafter referred to as "payment source ID").

Next, the payment server 10 determines whether the item included in the deposit request is salary. If the item included in the deposit request is salary, the payment server 10 performs the deposit process on the salary balance of the total balance linked to the user ID included in the deposit request.

For example, the payment server 10 stores account information that associates an "Owner ID" item, a "Total Balance" item, and a "Details" item. The "Owner ID" item stores identification information (owner identification information, hereinafter referred to as "owner ID") that identifies the owner of the digital money account (payment account). Here, an example is shown in which the "Owner ID" item stores user ID "U1" that identifies user U1, but the "Owner ID" item may also store, in addition to the user ID, a payment source ID, identification information that identifies the provider that provides the transaction object (provider identification information, hereinafter referred to as "provider ID"), etc. The "Total Balance" item stores information indicating the total balance of digital money owned by the owner identified by the owner ID.

The "Breakdown" item stores information indicating the breakdown of the total balance stored in the "Total Balance" item. Specifically, the "Breakdown" item includes a "Salary" item and a "Non-Salary" item. The "Salary" item stores information indicating the balance of digital money deposited as salary, out of the total balance stored in the "Total Balance" item. The "Non-Salary" item stores information indicating the balance of digital money deposited under a name other than salary, out of the total balance stored in the "Total Balance" item.

For example, Figure 1 shows an example of account information including user ID "U1," total balance "1,000,000 yen," salary "700,000 yen," and non-salary "300,000 yen." In this case, when the deposit request shown in Figure 1 is received, the payment server 10 changes the "total balance" item associated with user ID "U1" from "1,000,000 yen" to "1,300,000 yen." The payment server 10 also changes the "salary" item associated with user ID "U1" from "700,000 yen" to "1,000,000 yen" (step S2). The "non-salary" item remains unchanged.

On the other hand, when the payment server 10 receives a deposit request that includes an item other than salary, it changes the "total balance" item and the "non-salary" item in the corresponding account information. In this case, the "salary" item remains unchanged. Note that the "non-salary" item may be subdivided into multiple items. In other words, there may be multiple items other than salary, and in this case, the "non-salary" item may be subdivided to correspond to the multiple items.

In this way, the management system 1 according to the first embodiment manages at least the salary balance separately from the total balance of digital money. As a result, for example, the payment server 10 can display on the user terminal 100 of user U1, splitting balance information indicating the total balance (e.g., a total balance of 1,300,000 yen) into salary balance information indicating the salary balance (e.g., a total balance of 1,000,000 yen) and non-salary balance information indicating the non-salary balance (e.g., a total balance of 300,000 yen) (step S3).

Therefore, the management system 1 according to the first embodiment allows for appropriate management of balances, including salary, when digital salary payments are made.

In the case of digital salary payments, convenience for users can be ensured by making it possible to convert the digital money paid as salary into cash. Specifically, it is necessary to make it possible to withdraw the digital money paid as salary from an ATM. Therefore, the management system 1 according to the first embodiment is configured to make it possible to withdraw the digital money paid as salary from an ATM 800.

For example, in accordance with the operation by user U1, ATM 800 sends a withdrawal request including the user ID and the withdrawal amount to bank server 600 (step S4). The operation by user U1 on ATM 800 may be, for example, an input operation on a touch panel or physical buttons on ATM 800, or an operation in which ATM 800 reads a QR code (registered trademark) or the like displayed on user terminal 100. The information input to ATM 800 needs to include at least the user ID and the withdrawal amount.

Next, the bank server 600 sends the withdrawal request received from the ATM 800 to the payment server 10 (step S5).

Next, the payment server 10 changes the "Salary" item in the corresponding balance information based on the withdrawal request received from the bank server 600. For example, suppose the withdrawal request includes user ID "U1" and a withdrawal amount of "100,000 yen." In this case, the payment server 10 changes the "Total Balance" item linked to user ID "U1" from "1,300,000 yen" to "1,200,000 yen," and changes the "Salary" item from "1,000,000 yen" to "900,000 yen" (step S6).

Next, the payment server 10 sends a withdrawal instruction including the user ID and the withdrawal amount to the bank server 600 (step S7). Upon receiving the withdrawal instruction, the bank server 600 debits the withdrawal amount included in the withdrawal instruction from the bank account of the business operator to which the payment server 10 belongs, i.e., the company that provides the electronic payment service (step S8). Note that this process may be performed when the withdrawal instruction is received from the payment server 10, or at a predetermined time, for example, once a month.

The bank server 600 also sends a withdrawal instruction, including the withdrawal amount, to the ATM 800 (step S9). The ATM 800 then dispenses cash in an amount equal to the withdrawal amount included in the withdrawal instruction (step S10).

In this way, in the management system 1 according to the first embodiment, user U1 can withdraw the digital money equivalent to his/her salary balance from the ATM 800 as cash from the total digital money balance he/she owns.

The above-mentioned cash conversion mechanism applies to digital money paid as salary, and may not apply to digital money paid under other names. If digital money paid under other names than salary could also be converted into cash, there are concerns that it could become a breeding ground for money laundering, for example. For this reason, the payment server 10 may prohibit the withdrawal of non-salary balances from the ATM 800. However, if the non-salary balance is subdivided into multiple items, the withdrawal of any of the multiple subdivided items from the ATM 800 may be permitted.

1-2. Payment using the user terminal 100
Next, an example of payment (electronic payment) using the user terminal 100 will be described with reference to Fig. 2. Fig. 2 is a diagram showing an example of electronic payment processing according to the first embodiment. In the management system 1, both the salary balance and the non-salary balance of the total balance of digital money described above can be used for electronic payment.

As shown in FIG. 2, the management system 1 may further include a provider terminal 200. The provider terminal 200 is an information processing device used by a provider who provides transaction objects to users. The provider terminal 200 may be realized, for example, as a POS (Point of Sales) terminal, smartphone, tablet terminal, notebook PC, desktop PC, mobile phone, PDA, etc. The provider terminal 200 also displays information distributed by the payment server 10 using a web browser or application. Note that FIG. 2 shows an example in which the provider terminal 200 is a POS terminal.

The following description will discuss an example in which user U1 makes a payment using a user terminal 100 using a two-dimensional code (QR code (registered trademark)) placed at store A, which indicates identification information C1 that identifies store A (hereinafter referred to as the "store code"), but the first embodiment is not limited to this. The example of payment described below can also be applied when any user makes a payment at any store using any user terminal 100. Furthermore, store code C1 may not only be a QR code (registered trademark), but may also be a barcode, a specified mark, a number, etc. (i.e., a specified code).

For example, when user U1 makes a payment for the use or purchase of payment items (transaction items) such as various products or services at store A, user U1 launches a payment app pre-installed on user terminal 100. Then, user U1 photographs and reads store code C1 installed at store A via the payment app (step S11). In such a case, user terminal 100 displays a screen for inputting the price of the payment item and accepts input of the payment amount from user U1 or a store clerk at store A. User terminal 100 then transmits payment information indicating the user ID that identifies user U1, the store code C1 (or information indicated by store code C1, i.e., information indicating store A (e.g., provider ID)), and the payment amount to payment server 10.

When the payment server 10 accepts payment information from the user terminal 100 (step S12), it transfers digital money in the amount indicated by the payment amount from the payment account of user U1 indicated by the user ID to the payment account of store A indicated by store code C1 (step S13). The payment server 10 then sends a notification to the user terminal 100 that the payment has been completed (step S14). In such a case, the user terminal 100 notifies the user that payment has been made using digital money by displaying a screen or outputting a specified sound indicating that the payment has been completed.

Payment using the user terminal 100 is not limited to the above-described process. For example, payment using the user terminal 100 may also be made using a provider terminal 200 installed in store A. For example, the user terminal 100 displays a user ID on its screen to identify user U1. In such a case, the provider terminal 200 installed in store A reads the user ID displayed on the user terminal 100 and transmits payment information indicating the user ID, payment amount, and information identifying store A to the payment server 10. In such a case, the payment server 10 transfers digital money in the amount indicated by the payment amount from the payment account of user U1 indicated by the user ID to the payment account of store A, and may notify the provider terminal 200 or user terminal 100 of store A that the payment has been completed by displaying a screen or outputting a specified audio message indicating that the payment has been completed.

Furthermore, payments using the user terminal 100 may not only involve transferring digital money from a payment account to which user U1 has previously charged digital money to store A's payment account, but may also involve, for example, payment using a credit card that user U1 has previously registered. In such cases, for example, user terminal 100 may transfer digital money equivalent to the payment amount to store A's payment account and bill the operating company (card company) of user U1's credit card for the payment amount.

Furthermore, payments using the user terminal 100 are not limited to payments made to physical stores, and may also be payments for transactions made through e-commerce services (i.e., online payments). In such cases, for example, the user terminal 100 transmits payment information indicating the user ID that identifies user U1, the provider ID, and the price of the transaction (payment amount) to the payment server 10. The payment server 10 then transfers digital money in the amount indicated by the payment amount from the payment account of user U1 indicated by the user ID to the payment account of the provider indicated by the provider ID, and notifies the user terminal 100 that the payment has been completed by displaying a screen or outputting a specified sound indicating that the payment has been completed.

[2. Payment Server Configuration]
Next, the configuration of the payment server 10 will be described with reference to Fig. 3. Fig. 3 is a diagram showing an example of the configuration of the payment server 10 according to the first embodiment. As shown in Fig. 3, the payment server 10 has a communication unit 20, a storage unit 30, and a control unit 40.

(Regarding the communication unit 20)
The communication unit 20 is realized by, for example, a network interface card (NIC), etc. The communication unit 20 is connected to the network N by wire or wirelessly, and transmits and receives information between the user terminal 100, the provider terminal 200, the payment source server 400, the bank server 600, etc.

(Regarding the storage unit 30)
The storage unit 30 is realized by, for example, a semiconductor memory element such as a random access memory (RAM) or a flash memory, or a storage device such as a hard disk or an optical disk. As shown in FIG. 4 , the storage unit 30 has an account database 31.

(Regarding account database 31)
The account database 31 stores various information (an example of the balance information described above) related to accounts (payment accounts) held by users, salary payers, providers, etc. in electronic payment services. An example of the information stored in the account database 31 will now be described using FIG. 4. FIG. 4 is a diagram showing an example of an account database according to the first embodiment. In the example of FIG. 4, the account database 31 has items such as "account ID,""ownerID,""totalbalance," and "details."

The "Account ID" field stores identification information (account identification information, hereafter referred to as "account ID") for identifying a payment account. The "Owner ID" field stores identification information for identifying the owner of the payment account linked to the account ID. For example, in the example shown in Figure 4, the "Owner ID" field stores the user ID "U1" of user U1, the payer ID "E1" of the payer who pays the salary, the provider ID "P1" of the provider who provides the transaction object, etc.

The "Total Balance" item stores information showing the total balance of the payment account. The "Details" item stores information showing the breakdown of the total balance. Specifically, the "Details" item includes a "Salary" item and a "Non-Salary" item, and the "Non-Salary" item is further subdivided into, for example, a "Regular" item and a "Profit" item.

The "Salary" field stores information indicating the balance of digital money deposited as salary out of the total balance stored in the "Total Balance" field. The "Non-Salary" field stores information indicating the balance of digital money deposited under a name other than salary out of the total balance stored in the "Total Balance" field.

Furthermore, among the "Non-salary" items, the "Normal" item stores information indicating the balance of digital money charged by the payment account owner himself/herself. As an example, the "Normal" item stores information indicating the balance of digital money deposited from a credit card or bank account linked to the payment account. The "Profit" item stores information indicating, for example, the balance of digital money cashed back on the payment amount when using an electronic payment service provided by the management system 1.

(Regarding the control unit 40)
The control unit 40 is a controller, and is realized, for example, by a CPU (Central Processing Unit) or MPU (Micro Processing Unit) or the like executing various programs stored in a storage device inside the payment server 10 using RAM as a work area. The control unit 40 is also a controller, and is realized, for example, by an integrated circuit such as an ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). As shown in FIG. 3 , the control unit 40 according to the first embodiment has a reception unit 41, a deposit processing unit 42, a withdrawal processing unit 43, and a display control unit 44, and realizes or executes the functions and actions of information processing described below.

(Regarding the reception unit 41)
The reception unit 41 receives a digital money deposit request. An example of information included in the deposit request will now be described with reference to Fig. 5. Fig. 5 is a diagram showing an example of a deposit request according to the first embodiment.

As shown in Figure 5, the deposit request includes information such as "Payment Source ID," "Payment Destination ID," "Deposit Amount," and "Nominal." "Payment Source ID" is identification information of the payment source that sent the deposit request, and "Payment Destination ID" is identification information of the payee. "Deposit Amount" is information indicating the amount of digital money to be deposited, and "Nominal" is information indicating the nominal name of the deposit. The deposit request shown in Figure 5 indicates that "300,000 yen" will be deposited as salary from the employer of user U1, identified by payment source ID "E1," to user U1, identified by payment destination ID "U1."

The reception unit 41 also receives a withdrawal request for digital money to the ATM 800. An example of information included in a withdrawal request will now be described with reference to Figure 6. Figure 6 is a diagram showing an example of a withdrawal request according to the first embodiment.

As shown in Figure 6, a withdrawal request includes information such as "Bank ID," "Withdrawal Source ID," "Withdrawal Amount," and "Withdrawal Destination." "Bank ID" is identification information for the bank that sent the withdrawal request, and "Withdrawal Source ID" is identification information for the user making the withdrawal. "Withdrawal Amount" is information indicating the withdrawal amount, and "Withdrawal Destination" is information indicating the withdrawal destination (where the money is to be withdrawn). The withdrawal request shown in Figure 6 was sent from a bank with bank ID "B1," and indicates that a user with withdrawal source ID "U1" (i.e., user U1) will withdraw 100,000 yen from an ATM.

The reception unit 41 may receive payment information related to payment for a transaction object in the e-commerce service. For example, the reception unit 41 receives payment information from the user terminal 100 indicating a user ID that identifies the user, a provider ID that identifies the provider that provides the transaction object, and the price (payment amount) of the transaction object.

The reception unit 41 may also receive payment information from a provider terminal 200 installed in a store. For example, the reception unit 41 receives payment information indicating the user ID read by the provider terminal 200 and displayed on the user terminal 100, the payment amount, and information identifying the store.

The reception unit 41 may also receive a request to confirm the total balance of digital money from the user terminal 100. In this case, the confirmation request only needs to include at least the user ID.

(Regarding the deposit processing unit 42)
The deposit processing unit 42 performs a deposit process for the account database 31 based on the deposit request accepted by the acceptance unit 41 .

Specifically, the deposit processing unit 42 transfers digital money equivalent to the deposit amount included in the deposit request from the payment account linked to the payment source ID included in the deposit request to the payment account linked to the payment destination ID included in the deposit request. In other words, the deposit processing unit 42 subtracts the deposit amount from the total balance of the payment account linked to the payment source ID, and adds the deposit amount to the total balance of the payment account linked to the payment destination ID.

The deposit processing unit 42 also determines whether the item included in the deposit request is "salary." If the item included in the deposit request is "salary," the deposit processing unit 42 adds the deposit amount to the "salary" item in the total balance of the payment account linked to the payee ID.

On the other hand, if the item included in the deposit request is "other than salary," the deposit processing unit 42 adds the deposit amount to the "other than salary" item in the total balance of the payment account linked to the payee ID. For example, if the item included in the deposit request is "regular," the deposit processing unit 42 adds the deposit amount to the "regular" item in the total balance of the payment account linked to the payee ID. Also, if the item included in the deposit request is "profit," the deposit processing unit 42 adds the deposit amount to the "profit" item in the total balance of the payment account linked to the payee ID.

(Regarding the withdrawal processing unit 43)
The withdrawal processing unit 43 performs a withdrawal process for the account database 31 based on the withdrawal request received by the reception unit 41 .

Specifically, the withdrawal processing unit 43 subtracts digital money equivalent to the withdrawal amount included in the withdrawal request from the settlement account linked to the withdrawal source ID included in the withdrawal request. The withdrawal processing unit 43 then sends a withdrawal instruction to the bank server 600 of the bank ID included in the withdrawal request via the communication unit 20 and network N. The withdrawal instruction may include information such as the withdrawal source ID and the withdrawal amount.

The withdrawal processing unit 43 also determines whether the withdrawal destination included in the withdrawal request is an "ATM." If the withdrawal destination included in the withdrawal request is an "ATM," the withdrawal processing unit 43 subtracts the withdrawal amount from the "salary" item in the total balance of the settlement account linked to the withdrawal source ID.

If the withdrawal destination included in the withdrawal request is other than "ATM," for example, if the withdrawal destination is "bank account," the withdrawal processing unit 43 may subtract the withdrawal amount from the item selected by the user from the "salary" and "regular" items of the settlement account linked to the withdrawal source ID. The selection of the balance items to be used as the withdrawal source (here, the "salary" and "regular" items) may be performed by operating the ATM 600. It may also be set in advance by the user.

(Regarding the display control unit 44)
The display control unit 44 displays content relating to the electronic payment service provided by the management system 1 on the user terminal 100 used by the user.

For example, when the reception unit 41 receives a request to confirm the total balance from a user terminal 100, the display control unit 44 transmits balance information indicating the total balance of the payment account owned by the user to the user terminal 100 of the user identified by the user ID included in the confirmation request. At this time, the display control unit 44, for example, obtains information on the "total balance" item, "salary" item, and "non-salary" item from the payment account linked to the user ID, and displays the obtained information on the user terminal 100 via the payment app.

Figure 7 shows an example of balance information displayed on the user terminal 100. Figure 7 is a diagram showing an example of the screen of the user terminal 100 according to the first embodiment. Figure 7 shows, as an example, balance information for the payment account owned by user U1.

As shown in Figure 7, the display control unit 44 acquires the following information from the payment account linked to user ID "U1": "1,000,000 yen" for the "Total balance" item, "700,000 yen" for the "Salary" item, and "300,000 yen" for the "Non-salary" item, and displays each acquired information on the user terminal 100.

In this way, the display control unit 44 displays the total digital money balance divided into the salary balance and the non-salary balance on the user terminal 100 used by the user.

3. Management process flow
Next, the procedure of the management process of the payment server 10 according to the first embodiment will be described. First, the procedure of the deposit process will be described with reference to Fig. 8. Fig. 8 is a flowchart showing an example of the procedure of the deposit process in the management process according to the first embodiment.

As shown in FIG. 8, the payment server 10 accepts a deposit request (step S101). Next, the payment server 10 determines whether the name of the deposit request is "salary" (step S102). If it determines that the name is "salary" (step S102; Yes), the payment server 10 deposits the money into the salary balance (step S103). Specifically, the payment server 10 transfers funds from the payment source's settlement account to the payee's salary balance.

On the other hand, if the deposit request is not for "salary," i.e., if it is determined to be for "non-salary" (step S102; No), the payment server 10 deposits the money into the non-salary balance (step S104). Specifically, the payment server 10 transfers funds from the payment source's settlement account to the payee's non-salary balance. After completing the processing of step S103 or step S104, the payment server 10 terminates the deposit process.

Next, the withdrawal processing procedure will be described with reference to Figure 9. Figure 9 is a flowchart showing an example of the withdrawal processing procedure in the management processing according to the first embodiment.

As shown in FIG. 9, the payment server 10 accepts a withdrawal request (step S201). Next, the payment server 10 determines whether the withdrawal destination is an ATM (step S202). If it determines that the withdrawal destination is an ATM (step S202; Yes), the payment server 10 performs a withdrawal from the salary balance (step S203).

On the other hand, if the withdrawal destination is not an ATM, i.e., if it is determined that the withdrawal destination is a bank account (step S202; No), the payment server 10 withdraws the amount from the balance item selected by the user, either the salary balance or the non-salary balance (step S204). After completing the processing of step S203 or step S204, the payment server 10 sends a withdrawal instruction to the bank server 600 (step S205) and ends the withdrawal process.

4. Second embodiment
Next, the management process according to the second embodiment will be described with reference to Fig. 10. Fig. 10 is a diagram showing an example of the management process according to the second embodiment.

As shown in FIG. 10, when the payment server 10 receives a salary deposit request from the payment source server 400 (step S21), it deposits digital money as salary into the user's payment account to which the salary is to be paid (step S22). As described above, the salary deposit request includes, for example, identification information (payee ID) of the user (payee) receiving the salary deposit, the deposit amount, and the deposit name. Also, as described above, when the name included in the deposit request is "salary," the payment server 10 deposits the digital money amount included in the deposit request into the "salary balance" of the payment account linked to the payee ID.

Next, the payment server 10 performs a sorting process to sort a portion of the digital money deposited as salary into the payment account of the payee according to its intended use based on the user information of the payee user (step S23).

For example, user information may include setting information regarding payroll sorting (hereinafter referred to as "sorting information"). The sorting information may include, for example, identification information identifying the transaction target (transaction target identification information, hereinafter referred to as "transaction target ID"), identification information identifying the provider who is the source of the transaction target (provider identification information, hereinafter referred to as "provider ID"), the amount of the transaction target, etc.

In the example shown in Figure 10, the system is set to sort "10,000 yen" into use A, "5,000 yen" into use B, and "3,000 yen" into use C. In this case, when digital money is deposited into a user's payment account as salary, the payment server 10 sorts the digital money deposited as salary according to the sorting information: 10,000 yen as digital money to be used for use A, 5,000 yen as digital money to be used for use B, and 3,000 yen as digital money to be used for use C. In this case, the payment server 10 limits the use of 18,000 yen of the digital money deposited as salary to uses A to C. In other words, the amount of salary that the user can use for purposes other than uses A to C is the total amount of salary minus 18,000 yen.

In this way, the payment server 10 according to the second embodiment limits the uses of digital money deposited as a salary by sorting the digital money deposited as a salary based on user information. This allows users to prevent overspending of their salary by setting up the system to sort expenses that inevitably occur every month, such as utility bills, communication fees, and tuition fees.

Furthermore, when digital money is deposited as a salary, the payment server 10 may automatically use the digital money sorted by purpose for that purpose. For example, if purpose A is a deposit into an investment account owned by the user, the payment server 10 may automatically transfer 10,000 yen of the digital money deposited as a salary to the investment account. For example, if purpose B is the purchase of a product that the user purchases regularly (for example, monthly), the payment server 10 may transfer 5,000 yen of the digital money deposited as a salary to the payment account of the provider of that product.

In this way, the payment server 10 may sort the digital money deposited as salary by retaining a portion of the digital money deposited as salary in a payment account owned by the user, or by transferring a portion of the digital money deposited as salary to an account other than the payment account owned by the user.

The payment server 10 may also generate sorting information based on input operations by the user, or may generate it based on withdrawal history information from the user information. For example, the payment server 10 may estimate the transaction objects that the user regularly purchases based on the withdrawal history information, and generate sorting information including the transaction object ID of the estimated transaction object, the provider ID of the provider that provides the transaction object, and the amount of the transaction object. At this time, the payment server 10 may suggest to the user whether or not to use the generated sorting information, and if the suggestion is approved, the generated sorting information may be adopted.

5. Payment Server Configuration
Next, the configuration of the payment server according to the second embodiment will be described with reference to Fig. 11. Fig. 11 is a diagram showing an example of the configuration of the payment server according to the second embodiment.

As shown in FIG. 11, the control unit 40 of the payment server 10 according to the second embodiment has an acquisition unit 45, a funds transfer unit 46, an estimation unit 47, a determination unit 48, a payment processing unit 49, and a proposal unit 50. Furthermore, the memory unit 30 of the payment server 10 according to the second embodiment has a history database 32, a registration information database 33, and a billing information database 34.

(Regarding account database 31)
An example of information stored in the account database 31 according to the second embodiment will be described with reference to Fig. 12. Fig. 12 is a diagram showing an example of the account database according to the second embodiment.

As shown in FIG. 12, the account database 31 according to the second embodiment includes, as "salary" items, items such as "everyday use," "reservation #1," and "reservation #2." The "everyday use" item stores the amount of digital money deposited as salary that has no restrictions on use, i.e., the amount of digital money that the user can use freely. The "reservation #1" and "reservation #2" items store the amount of digital money deposited as salary that has restrictions on use. These "reservation" items are linked to the "sorting information" items in the registration information database 33, which will be described later. When a new reserved item is added to the "sorting information" item, the newly added reserved item is also added to the account database 31.

When a deposit request containing "salary" as the nominal item is accepted, the deposit processing unit 42 according to the second embodiment stores the digital money of the "amount" included in the deposit request in the "everyday use" item of the "salary" item of the payment account. A portion of the digital money stored in the "everyday use" item will then be transferred by the funds transfer unit 46, which will be described later, to the "reserved" item of the "salary" item or to an account other than the payment account into which the salary was deposited. This point will be discussed later.

(Regarding the history database 32)
The history database 32 stores information relating to the history of past transactions made by the user (an example of withdrawal history information). An example of information stored in the history database 32 will now be described with reference to Fig. 13. Fig. 13 is a diagram showing an example of the history database according to the second embodiment.

In the example shown in Figure 13, the history database 32 has fields such as "User ID," "Date and Time," "Provider ID," "Transaction Subject," and "Amount."

The "User ID" field stores the user ID of the user who conducted the transaction. The "Date and Time" field stores the date and time the transaction was conducted (payment was made). The "Provider ID" field stores the provider ID of the provider who provided the transaction object. The "Transaction Object" field stores information for identifying the transaction object (for example, product number, product name, etc.). The "Amount" field stores the amount paid by the user for the provision of the transaction object.

(Regarding the registration information database 33)
The registration information database 33 stores registration information (an example of user information) related to users. An example of information stored in the registration information database 33 will now be described with reference to Fig. 14. Fig. 14 is a diagram showing an example of the registration information database according to the second embodiment.

In the example shown in Figure 14, the registration information database 33 has items such as "User ID," "Name," "Age," "Gender," "Family Composition," "Investment Account ID," and "Sorting Information."

The "User ID" field stores the user ID. The "Name" field stores the name of the user identified by the user ID. Note that the name stored in the "Name" field is not limited to kanji, and may be expressed in hiragana, katakana, the alphabet, etc. The "Age" field stores the age of the user identified by the user ID. The "Gender" field stores the gender of the user identified by the user ID. The "Family Composition" field stores the family composition of the user identified by the user ID. For example, information such as the relationship to the user, name, age, and gender is stored in the "Family Composition" field. The "Investment Account ID" field stores identification information (investment account identification information, hereinafter referred to as "investment account ID") that identifies the investment account owned by the user identified by the user ID.

The "sorting information" item stores the contents of the sorting information set for the user identified by the user ID. For example, the "sorting information" item includes items such as "sorting ID," "provider ID," "transaction target," and "set amount."

The "sorting ID" item stores identification information for identifying sorting information. Here, two types of sorting IDs are stored: "reservation ID" and "remittance ID." "Reservation ID" is identification information that identifies sorting information to be reserved in the user's payment account, and "remittance ID" is identification information that identifies sorting information to be transferred to an account other than the user's payment account.

The "Provider ID" field stores the provider ID of the provider who provides the transaction object to be used in the sorting information identified by the sorting ID. The "Transaction Object" field stores information (e.g., product number, product name, etc.) for identifying the transaction object to be used in the sorting information identified by the sorting ID. The "Set Amount" field stores the set amount of digital money to be reserved in the payment account or transferred to an account other than the payment account in the sorting information identified by the sorting ID.

(Regarding the billing information database 34)
The billing information database 34 stores billing information transmitted from, for example, the provider terminal 200 or a provider server owned by the provider. An example of information stored in the billing information database 34 will now be described with reference to FIG. 15. FIG. 15 is a diagram showing an example of a billing information database according to the second embodiment. In the example of FIG. 15, the billing information database 34 has items such as "billing information ID,""userID,""providerID,""paymentdeadline,""transactiontarget," and "amount."

The "Billing Information ID" field stores identification information for identifying the billing information. The "Provider ID" field stores a provider ID that identifies the provider who is the billing source. The "User ID" field stores a user ID that identifies the user who is the billing recipient. The "Payment Deadline" field stores the payment deadline for the billed amount. The "Transaction Object" field stores information that indicates the transaction object that is the subject of the bill. Here, for ease of understanding, we have used "electricity" and "water," but the "Transaction Object" field stores information that can identify the transaction object. The "Amount" field stores the amount to be billed to the billing recipient.

(Regarding the acquisition unit 45)
The acquisition unit 45 acquires user information related to the user. For example, the acquisition unit 45 acquires various pieces of information stored in the account database 31, the history database 32, the registration information database 33, and the billing information database 34 as the user information.

(Regarding the funds transfer unit 46)
The funds transfer unit 46 transfers a portion of the digital money received as salary from among the digital money received by the reception unit 41 based on the user information acquired by the acquisition unit 45.

The funds transfer unit 46 transfers a portion of the digital money deposited as salary to a "reserved" item in the payment account into which the digital money as salary was deposited, or to an account other than the payment account into which the digital money as salary was deposited, in accordance with the sorting information stored in the registered information database 33. The sorting information with the reservation ID attached is acquired from the registered information database 33 by the acquisition unit 45.

First, we will explain how to transfer digital money to the "reserved" item in your payment account.

As described above, digital money as salary is first deposited into the "ordinary use" item under the "salary" item in the payment account. When digital money is deposited into the "ordinary use" item, the funds transfer unit 46 transfers a portion of the digital money deposited into the "ordinary use" item to the "reservation" item in accordance with the sorting information associated with the reservation ID. For example, in the registration information database 33 shown in FIG. 14, two sorting information items, "reservation #1" and "reservation #2," are linked to a user with user ID "U1." When digital money as salary is deposited to user U1 with user ID "U1," the funds transfer unit 46 transfers the digital money from the "ordinary use" item to the "reservation #1" and "reservation #2" items in the payment account linked to user ID "U1."

At this time, the funds transfer unit 46 transfers digital money from the "regular use" item to the "reservation" item so that the amount stored in the "reservation" item of the payment account matches the amount stored in the "set amount" item of the sorting information.

For example, suppose that before a salary is deposited, "100 yen" is stored in the "Reservation #1" item of a payment account. In this case, the funds transfer unit 46 transfers "14,900 yen" from the "Regular Use" item of the payment account to the "Reservation #1" item so that the "Reservation #1" item of the payment account becomes "15,000 yen."

In addition, the funds transfer unit 46 may transfer the amount of digital money stored in the "Set Amount" item of the sorting information from the "Regular Use" item of the payment account to the "Reservation" item, regardless of the balance in the "Reservation" item.

Here, as shown in FIG. 14, the sorting information for "Reservation #1" is linked to multiple provider IDs and multiple recipients. As an example, the sorting information for "Reservation #1" is linked to recipients such as "electricity" and "water." In this way, the sorting information for "Reservation #1" may be sorting information for setting aside monthly expenses (fixed costs). The "Set Amount" item linked to such sorting information for "Reservation #1" may store an amount entered by the user, or may store an amount estimated by the estimation unit 47, which will be described later. The contents of the estimation unit 47 will be described later. In this way, the funds transfer unit 46 may transfer a portion of the digital money deposited as salary to the "Reservation" item based on the monthly expenditure amount estimated by the estimation unit 47.

In addition, the sorting information for "Reservation #1" is not limited to utility bills as described above, and may also be linked to items of trade that the user purchases on a regular basis (e.g., monthly) (e.g., supplements, disposable contact lenses, etc.). The "Set Amount" item linked to such sorting information for "Reservation #1" may store an amount entered by the user, or an amount estimated by the estimation unit 47, which will be described later.

Next, we will explain what happens when you transfer part of the digital money deposited as salary to an account other than the payment account into which the digital money as salary was deposited.

When digital money is deposited as salary into the "Regular Use" item, the funds transfer unit 46 transfers a portion of the digital money deposited into the "Regular Use" item to a different account in accordance with the sorting information associated with the remittance ID. For example, in the registration information database 33 shown in FIG. 14, two sorting information items, "Remittance #1" and "Remittance #2," are linked to a user with user ID "U1." As an example, when digital money is deposited as salary into user U1 with user ID "U1," the funds transfer unit 46 transfers the set amount "3,000 yen" linked to "Remittance #1" from the "Regular Use" item of the settlement account linked to user ID "U1" to the investment account identified by the provision object "Investment #1" linked to "Remittance #1."

Here, the sorting information for "Remittance #1" may be generated based on a proposal by the proposal unit 50, which will be described later. The contents of the proposal unit 50 will be described later. In this way, the funds transfer unit 46 may automatically transfer the amount of digital money deposited as salary, in the amount proposed by the proposal unit 50, to the investment account.

(Regarding the estimation unit 47)
The estimation unit 47 estimates the transaction objects and amounts that the user periodically purchases based on the withdrawal history information stored in the history database 32, which is part of the user information acquired by the acquisition unit 45.

As an example, the estimation unit 47 identifies transaction objects that a user has purchased consecutively over multiple months based on the withdrawal history information. For example, the estimation unit 47 references the history database 32 shown in FIG. 13 and identifies that user U1 with user ID "U1" has purchased the offer item "supplements" for the amount of "5,000 yen" provided by the provider with provider ID "P1" for multiple consecutive months (e.g., three months). In this case, the estimation unit 47 estimates that the offer item "supplements" for the amount of "5,000 yen" provided by the provider with provider ID "P1" is a transaction object that the user purchases regularly.

The estimation unit 47 may also estimate the monthly expenditure amount of the user based on the withdrawal history information stored in the history database 32, which is part of the user information acquired by the acquisition unit 45.

As an example, the estimation unit 47 refers to the history database 32, calculates the user's monthly expenditures for multiple months (for example, the most recent three months), and estimates the average amount (average expenditure amount) as the monthly expenditure amount.

In this case, the estimation unit 47 may calculate the average expenditure amount by limiting the transaction objects. For example, the estimation unit 47 may calculate the average expenditure amount by limiting it to utility bills such as water, gas, and electricity. Furthermore, the estimation unit 47 may calculate the average expenditure amount by limiting it to fixed expenses that are always paid every month, such as monthly tuition for cram schools, rent, and loans, in addition to utility bills.

The estimation unit 47 may also estimate the monthly expenditure amount based on billing information stored in the billing information database 34.

For example, the estimation unit 47 references the billing information database 34 shown in FIG. 15 and identifies billing information with billing information IDs "Bill #1" and "Bill #2" as billing information linked to user ID "U1." The billing information for "Bill #1" indicates that user U1 with user ID "U1" has been invoiced by the provider with provider ID "P4" to pay the amount of "8,000 yen" for the transaction object "electricity" by the payment deadline "3/27/2021." Furthermore, the billing information for "Bill #2" indicates that user U1 with user ID "U1" has been invoiced by the provider with provider ID "P5" to pay the amount of "7,000 yen" for the transaction object "water" by the payment deadline "3/27/2021."

In this case, the estimation unit 47 may estimate the total amount of electricity and water bills, "15,000 yen," as user U1's expenditure for March.

The estimation unit 47 may also estimate the amount of digital money to be transferred to the investment account based on the amount of digital money deposited as salary and user information.

For example, the estimation unit 47 determines the ratio of the amount to be deposited into the investment account relative to the salary amount based on at least one of the user's age, gender, and family structure stored in the registration information database 33. For example, the payment server 10 may pre-store market price information linking the above ratio to a combination of age, gender, family structure, etc. (for example, information such as "a single man in his 30s should allocate 3% of his salary to investments"), and in this case the estimation unit 47 may determine the above ratio based on the market price information.

The estimation unit 47 then uses the salary amount and the above ratio to estimate the amount of digital money to be transferred to the investment account.

(Regarding the determination unit 48)
When the payment information is accepted by the accepting unit 41, the determining unit 48 determines whether the content of the payment matches the purpose set in the "reservation" item in the payment account.

For example, if the payment information includes user ID "U1," provider ID "P4," and supply item "electricity," the determination unit 48 determines that the payment details match the use set in the sorting information for "Reservation #1," i.e., the provider ID and supply item linked to "Reservation #1."

Furthermore, if the payment information includes the user ID "U1," the provider ID "P1," and the item to be provided "supplements," the determination unit 48 determines that the payment details match the purpose set in the sorting information for "Reservation #2," i.e., the provider ID and item to be provided linked to "Reservation #2."

(Regarding the payment processing unit 49)
The payment processing unit 49 executes payment processing in accordance with the payment information accepted by the acceptance unit 41. For example, the payment processing unit 49 transfers digital money in the amount indicated by the payment amount from the account of the user indicated by the user ID to the account of the provider indicated by the provider ID.

Here, if the determination unit 48 determines that the contents of the payment information accepted by the acceptance unit 41 match the purpose set in the "reservation" item of the payment account, the payment processing unit 49 performs the payment process using the balance of the "reservation" item that matches the purpose.

For example, if the payment information accepted by the acceptance unit 41 includes user ID "U1," provider ID "P1," item to be provided "supplement," and amount "5,000 yen," the payment processing unit 49 transfers "5,000 yen" from the balance of the "Reservation #2" item, "5,000 yen," to the payment account of provider ID "P1."

In this way, the use of digital money linked to a "reserved" item is limited to the purpose set for that "reserved" item. Therefore, by setting aside the digital money needed each month in advance in a "reserved" item, users can curb wasteful spending of digital money.

(Regarding the proposal unit 50)
The suggestion unit 50 generates sorting information based on the estimation results by the estimation unit 47, transmits the contents of the generated sorting information to the user terminal 100 via the communication unit 20 and the network N, and suggests to the user that they reserve or automatically transfer their salary using the generated sorting information.

Then, when a notification that the proposal is approved is received from the user terminal 100 via the communication unit 20 and the network N, the proposal unit 50 registers the approved sorting information in the registration information database 33.

In addition, when the suggestion unit 50 receives sorting information created by the user through operation of the user terminal 100 via the communication unit 20 and the network N, the suggestion unit 50 may register the received sorting information in the registration information database 33.

(Regarding the display control unit 44)
The display control unit 44 according to the second embodiment displays the total balance of digital money as salary, i.e., the salary balance, divided into a reserved balance and a regular use balance on the user terminal 100 used by the user.

For example, when the reception unit 41 receives a request to confirm the salary balance from the user terminal 100, the display control unit 44 transmits the salary balance in the payment account owned by the user, i.e., the total amount of digital money linked to the "salary" item, to the user terminal 100 of the user identified by the user ID included in the confirmation request. At this time, the display control unit 44, for example, obtains information on the "regular use" and "reserved" items from the payment account linked to the user ID, and displays the obtained information on the user terminal 100 via the payment app.

Figure 16 shows an example of salary balance information displayed on the user terminal 100. Figure 16 is a diagram showing an example of a screen on the user terminal 100 according to the second embodiment. Figure 16 shows, as an example, salary balance information for the payment account held by user U1.

As shown in FIG. 16, the display control unit 44 acquires the following information from the payment account linked to user ID "U1": "525,000 yen" for the "salary" item, "500,000 yen" for the "everyday use" item, and "25,000 yen" for the "reservations" item, and displays each acquired information on the user terminal 100.

In this way, the display control unit 44 may divide the digital money salary balance into a balance for everyday use and a balance for reserved use and display them on the user terminal 100 used by the user.

6. Management process flow
Next, the procedure of the management process of the payment server 10 according to the second embodiment will be described. First, the registration process of the sorting information will be described with reference to Fig. 17. Fig. 17 is a flowchart showing an example of the procedure of the registration process of the sorting information in the management process according to the second embodiment.

As shown in FIG. 17, the payment server 10 generates sorting information based on the estimation results by the estimation unit 47 (step S301). Next, the payment server 10 transmits the generated sorting information to the user terminal 100 and suggests to the user that they register the sorting information (step S302).

Next, the payment server 10 determines whether the proposal made in step S302 has been approved (step S303). If it determines that the proposal has been approved (step S303; Yes), it registers the proposed sorting information in the registration information database 33 (step S304).

When the processing of step S304 is completed, or when the proposal is not approved in step S303 (step S303, No), the payment server 10 terminates the sorting information registration process.

Next, the funds transfer process will be described with reference to Figure 18. Figure 18 is a flowchart showing an example of the steps of the funds transfer process, which is part of the management process according to the second embodiment.

As shown in FIG. 18, the payment server 10 deposits digital money as salary into the ordinary use balance ("ordinary use" item) of the account database 31 (step S401). Next, the payment server 10 determines whether sorting information linked to the "reservation ID" ("reservation" sorting information) is registered in the registration information database 33 (step S402). If it determines that "reservation" sorting information is registered (step S402; Yes), the payment server 10 transfers digital money from the ordinary use balance to the reservation balance in accordance with the "reservation" sorting information (step S403).

When the processing of step S403 has been completed, or when "reservation" sorting information has not been registered in step S402 (step S403; No), the payment server 10 determines whether sorting information linked to the "remittance ID" ("remittance" sorting information) has been registered in the registration information database 33 (step S404). When it determines that "remittance" sorting information has been registered (step S404; Yes), the payment server 10 transfers digital money from the general use balance to a separate account in accordance with the "remittance" sorting information (step S405).

When the processing of step S405 has been completed, or if "remittance" sorting information has not been registered in step S404 (step S404; No), the payment server 10 terminates the funds transfer processing.

Next, the payment process will be described with reference to Figure 19. Figure 19 is a flowchart showing an example of the payment process steps in the management process according to the second embodiment.

As shown in FIG. 19, the payment server 10 acquires payment information (step S501). Next, the payment server 10 determines whether the content of the acquired payment information matches the purpose set in the reserved balance (step S502). If it is determined that the content matches the purpose set in the reserved balance (step S502; Yes), the payment server 10 performs payment processing using the reserved balance (step S503).

On the other hand, if the reserved balance does not match the intended use in step S502 (step S502: No), the payment server 10 performs payment processing using the ordinary use balance (step S504). After completing the processing of step S503 or step S504, the payment server 10 terminates the payment processing.

7. Modifications
The above-described embodiment is merely an example, and various modifications and applications are possible.

In the above-described embodiment, an example was described in which a portion of digital money deposited as salary is transferred. However, similarly, a portion of digital money other than salary may be set aside or transferred to a different account. For example, in the account database 31 shown in FIG. 12, the "Other than salary" item may include items such as a "daily use" item and a "set aside" item. In this case, when a deposit request including an item other than salary is accepted, the digital money equivalent to the "amount" included in the deposit request is stored in the "daily use" item of the "other than salary" item in the settlement account. The portion of the digital money stored in the "daily use" item will then be transferred by the funds transfer unit 46, described below, to the "set aside" item of the "salary" item or to an account other than the settlement account into which the salary was deposited. In this way, the funds transfer process may be performed for digital money other than salary.

The deposit request sent from the payment source server 400 to the payment server 10 may include "payment date" information. The "payment date" is information that specifies the date on which the deposit process will be executed. In this case, the payment server 10 executes the deposit process on the payment date specified by the "payment date" included in the deposit request. In other words, the payment server 10 suspends the deposit process until the payment date specified by the "payment date." In this way, the management system 1 may be configured to be able to schedule digital salary payments.

The "payment date" information only needs to include at least the month information among the date and month. For example, if the "payment date" information includes "April," the payment server 10 will execute the deposit process on a predetermined day in April (for example, April 25th).

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

Furthermore, the components of each device shown in the figure are functional concepts and do not necessarily have to be physically configured as shown. In other words, the specific form of distribution and integration of each device is not limited to that shown, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various loads, usage conditions, etc.

Furthermore, the above-mentioned embodiments can be combined as appropriate to the extent that the processing content is not contradictory.

8. Effects
As described above, the payment server 10 according to the embodiment is a management device that manages the balance of digital money used for electronic payments by reading a predetermined code, and includes a reception unit 41 and a deposit processing unit 42. The reception unit 41 receives a deposit request that includes identification information of a user receiving a digital money deposit and the name of the deposit. If the name included in the deposit request received by the reception unit 41 is salary, the deposit processing unit 42 performs a deposit process for the salary balance of the total balance linked to the identification information included in the deposit request, and if the name included in the deposit request received by the reception unit 41 is a name other than salary, the deposit processing unit 42 performs a deposit process for the non-salary balance of the total balance linked to the identification information included in the deposit request.

As a result, the payment server 10 according to the embodiment can manage the digital money balance held by the user separately into a salary balance and a non-salary balance. Therefore, according to the payment server 10 according to the embodiment, when a digital salary payment is made, the balance including the salary can be appropriately managed.

In addition, in the payment server 10 according to the embodiment, the reception unit 41 receives a withdrawal request to an ATM that includes the user's identification information. The payment server 10 according to the embodiment also includes a withdrawal processing unit 43 that, when a withdrawal request is received by the reception unit 41, performs a withdrawal process from the salary balance of the total balance linked to the identification information included in the withdrawal request.

This means that when users cash their salary received in digital money, they can withdraw it directly from an ATM without going through a bank account (i.e., without first transferring the digital money to a bank account).

In addition, the payment server 10 according to the embodiment has a display control unit 44 that divides the total balance into a salary balance and a non-salary balance and displays them on the user terminal 100 used by the user.

This allows users to easily check the balance of their salary deposited into their payment account. Users can also easily understand the balance of digital money they own that can be cashed at an ATM out of their total digital money balance.

The payment server 10 according to the embodiment also includes an acquisition unit 45, a reception unit 41, and a funds transfer unit 46. The acquisition unit 45 acquires user information related to users who use a specified payment method. The reception unit 41 accepts digital money deposits for users. The funds transfer unit 46 transfers a portion of the digital money deposited as salary, of the digital money accepted as a deposit by the reception unit 41, based on the user information acquired by the acquisition unit 45.

This allows users to set aside a portion of the digital money deposited as a salary for monthly utility bills, for example, or to automatically transfer the money to an account other than the payment account, such as an investment account. Therefore, the payment server 10 according to the embodiment can promote the use of electronic payment services that support digital salary payments.

Furthermore, in the payment server 10 according to the embodiment, the funds transfer unit 46 transfers a portion of the digital money deposited as salary to an account other than the payment account into which the digital money as salary was deposited. This allows the user to transfer a portion of the deposited salary to a specified account, for example, without operating a terminal. Therefore, the payment server 10 according to the embodiment can promote the use of electronic payment services that support digital salary payments.

In addition, in the payment server 10 according to the embodiment, accounts other than payment accounts are investment accounts. The payment server 10 according to the embodiment further includes an estimation unit 47 that estimates the amount of digital money to be transferred to the investment account based on the amount of digital money deposited as salary and user information. The funds transfer unit 46 transfers the amount of digital money estimated by the estimation unit 47 from the digital money deposited as salary to the investment account.

This allows the user to transfer a portion of their deposited salary to an investment account, for example, without operating a terminal. Furthermore, because the amount of digital money to be transferred to the investment account is estimated by the estimation unit 47, the user does not have to worry about how much of their salary to allocate to investments. Therefore, the payment server 10 according to the embodiment can promote the use of electronic payment services that support digital payment of salaries.

Furthermore, in the payment server 10 according to the embodiment, the funds transfer unit 46 transfers a portion of the digital money deposited as salary to the reserved balance in the payment account into which the digital money as salary was deposited.

This allows users to reserve the digital money they need each month in their payment account, helping to curb wasteful spending.

The payment server 10 according to the embodiment also includes a determination unit 48 and a payment processing unit 49. When payment information relating to a payment using a specified payment method is acquired, the determination unit 48 determines whether the details of the payment match the purpose set for the reserved balance. When the determination unit 48 determines that the details of the payment match the purpose, the payment processing unit 49 performs payment processing using the reserved balance.

This makes it possible to limit the use of digital money deposited into the reserved balance. In other words, it is possible to prevent digital money deposited into the reserved balance from being used for purposes other than its intended purpose.

The payment server 10 according to the embodiment also has an estimation unit 47 that estimates the monthly expenditure amount based on the withdrawal history information of the payment account owned by the user, which is part of the user information acquired by the acquisition unit 45. The funds transfer unit 46 transfers a portion of the digital money deposited as salary to the reserved balance based on the expenditure amount estimated by the estimation unit 47.

In this way, by setting aside the monthly expenditure amount estimated by the estimation unit 47 in the reservation balance, it is possible to prevent users from overspending digital money.

The payment server 10 according to the embodiment also includes an estimation unit 47 that estimates the monthly expenditure amount based on invoice information indicating the details of the bill to the user, which is part of the user information acquired by the acquisition unit 45. The funds transfer unit 46 transfers a portion of the digital money deposited as salary to the reserved balance based on the expenditure amount estimated by the estimation unit 47.

In this way, by setting aside the monthly expenditure amount estimated by the estimation unit 47 in the reservation balance, it is possible to prevent users from overspending digital money. Furthermore, by estimating the expenditure amount based on invoice information, it is possible to more accurately estimate the monthly expenditure amount.

The payment server 10 according to the embodiment also has a display control unit 44 that displays the total balance of digital money as salary on the user's user terminal 100, dividing it into a reserved balance and a balance other than the reserved balance.

This allows users to easily understand how much of their salary balance deposited into their payment account is digital money with limited uses and how much is digital money that can be used freely.

9. Hardware Configuration
The payment server 10 according to each of the above-described embodiments is realized, for example, by a computer 1000 configured as shown in Fig. 20. The following description will be given taking the payment server 10 as an example. Fig. 20 is a hardware configuration diagram showing an example of a computer that realizes the functions of the payment server. The computer 1000 has a CPU 1100, a RAM 1200, a ROM 1300, a HDD 1400, a communication interface (I/F) 1500, an input/output interface (I/F) 1600, and a media interface (I/F) 1700.

The CPU 1100 operates based on programs stored in the ROM 1300 or HDD 1400, and controls each component. The ROM 1300 stores a boot program executed by the CPU 1100 when the computer 1000 starts up, as well as programs that depend on the computer 1000's hardware.

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

The CPU 1100 controls output devices such as displays and printers, and input devices such as keyboards and mice, via the input/output interface 1600. The CPU 1100 acquires data from input devices via the input/output interface 1600. The CPU 1100 also outputs data generated via the input/output interface 1600 to output devices.

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

For example, when the computer 1000 functions as the payment server 10, the CPU 1100 of the computer 1000 executes programs loaded onto the RAM 1200 to realize the functions of the control unit 40. In addition, the HDD 1400 stores various data in the storage device of the payment server 10. The CPU 1100 of the computer 1000 reads and executes these programs from the recording medium 1800, but as another example, the CPU 1100 of the computer 1000 may also obtain these programs from another device via a specified communications network.

[10. Other]
Although some of the embodiments of the present application have been described in detail above with reference to the drawings, these are merely examples, and the present invention can be implemented in other forms that include the embodiments described in the Disclosure of the Invention section and that have undergone various modifications and improvements based on the knowledge of those skilled in the art.

Furthermore, the configuration of the payment server 10 described above can be flexibly changed, such as by calling external platforms using APIs (Application Programming Interfaces) or network computing, depending on the function.

Furthermore, the term "unit" in the claims can be read as "means" or "circuit." For example, a reception unit can be read as a reception means or a reception circuit.

1 Management system 10 Settlement server 20 Communication unit 30 Memory unit 31 Account database 32 History database 33 Registration information database 34 Billing information database 40 Control unit 41 Reception unit 42 Deposit processing unit 43 Withdrawal processing unit 44 Display control unit 45 Acquisition unit 46 Funds transfer unit 47 Estimation unit 48 Determination unit 49 Settlement processing unit 50 Proposal unit 100 User terminal 200 Provider terminal 400 Payment source server 600 Bank server

Claims (4)

an acquisition unit that acquires user information related to a user who uses a predetermined payment method;
a deposit acceptance unit that accepts deposits of the digital money into a payment account owned by the user, the payment account into which digital money as salary and the digital money other than salary are deposited;
a funds transfer unit that transfers a portion of the digital money received by the deposit receiving unit based on the user information acquired by the acquisition unit,
The funds transfer unit
A management device characterized by transferring a portion of the digital money to an account other than the payment account, or to a reserved balance in the payment account. The user information is
including sorting information regarding sorting of said digital money;
The sorting information includes sorting items that associate uses with amounts,
The reserved balance is:
a reservation item corresponding to said use;
The management device described in claim 1, characterized in that the funds transfer unit transfers, for each sorting item, the amount corresponding to that sorting item to the reserved item in the reserved balance that corresponds to the same purpose as the sorting item. 1. A computer-implemented management method comprising:
an acquisition step of acquiring user information relating to a user who uses a predetermined payment method;
a deposit acceptance step of accepting deposit of the digital money into a payment account owned by the user, the payment account into which digital money as salary and the digital money other than salary are deposited;
a funds transfer step of transferring a part of the digital money received in the deposit receiving step based on the user information acquired in the acquisition step,
The funds transfer step includes:
a management method comprising: transferring a portion of the digital money to an account other than the settlement account, or transferring a portion of the digital money to a reserved balance in the settlement account. an acquisition step for acquiring user information relating to a user who uses a predetermined payment method;
a deposit acceptance step of accepting deposit of the digital money into a payment account owned by the user, the payment account into which digital money as salary and the digital money other than salary are deposited;
a funds transfer procedure for transferring a portion of the digital money received in the deposit receiving procedure based on the user information acquired in the acquisition procedure,
The fund transfer procedure is as follows:
A management program characterized by transferring a portion of the digital money to an account other than the settlement account, or to a reserved balance in the settlement account.