JP7137897B2 - Information processing method and information processing system - Google Patents

Description

The present invention relates to an information processing method and an information processing system .

Elderly people and people with disabilities who find it difficult to manage their money on their own can receive cash from caregivers such as family members on a regular basis. There may be In such cases, the caregiver needs to hand over the cash regularly, and the recipient may not be able to receive the cash at the desired timing, which can be a great stress for both parties. .

Therefore, the applicant of the present application has proposed a cash dispensing machine that dispenses cash stored in the device according to preset conditions (see Patent Document 1). In the cash dispensing machine of Patent Document 1, when the recipient is authenticated by biometric authentication and the set dispensing conditions are met, a set amount of cash is dispensed. With such a cash dispensing machine, the caregiver can set dispensing conditions in advance so that cash exceeding the set conditions will not be dispensed, thereby preventing the recipient from wasting money. You can receive cash on time.

Utility Model Registration No. 3223914

However, the cash dispensing machine of Patent Document 1 requires the helper to prepare and store cash in the device, which poses a problem that the burden on the caregiver is still heavy.

SUMMARY OF THE INVENTION The present invention has been made in view of such circumstances, and an object of the present invention is to provide an information processing method and the like that can reduce the burden on caregivers.

An information processing method according to an aspect of the present invention is an information processing method for depositing money into a payment account used for cashless payment using a mobile terminal, wherein the user using the mobile terminal is associated with the user. a money payout schedule set by an administrator associated with the user is registered in the server, and the balance of the payment account corresponding to the user is changed to the payout schedule at the timing according to the payout schedule corresponding to the user determining whether or not the amount is less than the deposit amount according to the payout schedule, and if it is determined to be less, specifying the amount that the balance of the payment account becomes the deposit amount according to the payout schedule, and providing the specified amount to the user If it is determined that the balance of the corresponding payment account is equal to or greater than the amount of money deposited according to the payout schedule, the process of not depositing money to the payment account corresponding to the user is included.

According to one aspect of the present invention, the burden on the caregiver can be further reduced.

1 is a schematic diagram showing a configuration example of an information processing system; FIG. It is a block diagram which shows the internal structural example of ATM. FIG. 3 is a block diagram showing an internal configuration example of a financial institution server and an administrator terminal; 3 is a schematic diagram showing a configuration example of a DB stored in a financial institution server; FIG. FIG. 11 is a flow chart showing an example of a payout schedule setting processing procedure; FIG. FIG. 11 is a flow chart showing an example of a payout schedule setting processing procedure; FIG. It is a schematic diagram which shows an example of a screen. It is a schematic diagram which shows an example of a screen. It is a schematic diagram which shows a screen example. It is a flow chart which shows an example of a payout processing procedure. It is a schematic diagram which shows an example of a screen. FIG. 10 is a schematic diagram showing a configuration example of an information processing system according to a second embodiment; It is a block diagram which shows the internal structural example of a cash dispenser. It is a schematic diagram which shows the structural example of DB memorize|stored in a cash dispensing apparatus. It is a flowchart which shows an example of the setting processing procedure of the payment|withdrawal schedule by a cash dispensing apparatus. It is a schematic diagram which shows an example of a screen. It is a schematic diagram which shows an example of a screen. It is a schematic diagram which shows an example of a screen. 10 is a flowchart showing an example of a payout processing procedure according to Embodiment 2; FIG. 11 is a schematic diagram showing a configuration example of an information processing system according to Embodiment 3; It is a block diagram which shows the internal structural example of the server for cashless payment, and a POS terminal. It is a schematic diagram which shows the structural example of account DB for payment. 2 is a block diagram showing an internal configuration example of a user terminal; FIG. FIG. 12 is a schematic diagram showing a configuration example of a setting screen in Embodiment 3; It is a flowchart which shows an example of a deposit processing procedure. It is a schematic diagram which shows an example of a screen. It is a flow chart which shows an example of a payment processing procedure. It is a schematic diagram which shows a screen example.

The information processing method, information processing system, and program of the present disclosure will be described in detail below based on the drawings showing the embodiments thereof.

(Embodiment 1)
An information processing system that pays out cash at a timing according to a cash payout schedule registered in advance in association with a user using a terminal of a financial institution installed in the city will be described. FIG. 1 is a schematic diagram showing a configuration example of an information processing system. The information processing system 100 of the present embodiment includes a financial institution server 10, a financial institution terminal 20, an administrator terminal 40, and the like. , a VPN (Virtual Private Network), a dedicated line, or the Internet. For example, the financial institution server 10 and financial institution terminal 20 may be connected via wide area Ethernet, VPN, or a dedicated line, and the financial institution server 10 and administrator terminal 40 may be connected via the Internet. The terminal 20 of the financial institution can be, for example, an ATM (Automated Teller Machine), a CD (Cash Dispenser), etc., and will be described as the ATM 20 below.

The financial institution server 10 is a server of a financial institution, and performs processing for registering a payout schedule for paying out cash to each customer's savings account (hereinafter simply referred to as an account) opened at the financial institution. Various information processing such as processing to pay out cash is performed. The financial institution server 10 performs processing related to each transaction such as deposit, withdrawal, transfer, and transfer received via ATM, CD, Internet banking, etc. for each customer's account. is publicly known, and detailed description thereof will be omitted. The financial institution server 10 is an information processing device capable of various types of information processing and transmission/reception of information, and is configured using, for example, a server computer or a personal computer. A plurality of financial institution servers 10 may be provided for distributed processing, may be realized by a plurality of virtual machines provided in one server, or may be realized by using a cloud server.

ATMs 20 are distributed throughout the city at commercial facilities such as financial institution stores, convenience stores, and shopping malls. It is configured to perform processing related to each transaction. The ATM 20 has, for example, a substantially quadrangular prism-shaped housing, and is provided with cash storage units (not shown) in which banknotes and money (cash) are stored by denomination (money amount). On one side (front side) of the ATM 20, there is a touch panel 23, a biometric sensor 26, a card insertion slot 20a for inserting a card 30 issued by a financial institution into the ATM 20, and a payout (withdrawn) card. A cash tray 20b for discharging cash is provided. Note that the cash tray 20b is also used as a cash slot for inserting banknotes and coins into the ATM 20, and the cash inserted into the cash tray 20b is stored in the cash storage unit by denomination. The cash tray 20b may be provided with an opening/closing lid whose opening/closing is controlled by the controller 21 (see FIG. 2). The arrangement positions of the touch panel 23, the biometric authentication sensor 26, the card slot 20a, and the cash tray 20b are not limited to the example shown in FIG.

The ATM 20 of this embodiment uses a vein sensor that reads palm veins as the biometric sensor 26 . Therefore, the information processing system 100 of the present embodiment has a configuration that performs user authentication by biometric authentication using the user's palm veins. However, biometric authentication used for user authentication is not limited to palm vein authentication, and may be biometric authentication using finger veins, fingerprints, irises, voiceprints, face shapes, etc. A configuration for performing authentication may also be used. Therefore, the biometric sensor 26 may be provided at a position where the user can easily perform an operation required for biometric authentication (for example, an operation of holding up the palm) according to the type of biometric authentication.

The administrator's terminal 40 is a terminal used by an administrator who manages the user's money, such as the user's guardian, family member, or helper who receives cash payment via the ATM 20, for example. The administrator terminal 40 performs various information processing such as processing for registering a cash dispensing schedule in the financial institution server 10 in association with the user, and processing for browsing the cash dispensing history of cash dispensed to the user via the ATM 20. I do. The administrator terminal 40 is configured using an information processing device such as a personal computer, a tablet terminal, or a smart phone, but may be configured by a dedicated terminal.

In the information processing system 100 of the present embodiment, for example, when the user's administrator (such as a caregiver) wishes to regularly hand cash to a user (such as a person being assisted) who has difficulty in managing money by himself/herself. , to open an account at a financial institution for withdrawing cash to the user. In the following description, the user is the holder of the account for withdrawing cash to the user. Then, the administrator concludes a contract with the financial institution for using cash withdrawal transactions via the ATM 20 for the opened account and the user, sets a cash withdrawal schedule, and sets the financial institution server 10. to register. A financial institution issues a card 30 that is used when cash is withdrawn using an ATM 20 to a user (account) who has made a contract for cash withdrawal transactions. The card 30 is a dedicated card for withdrawing cash, but may be a card used for various transactions (deposit/withdrawal transactions, transfer/transfer transactions, etc.) using the ATM 20 . The card 30 is, for example, a magnetic card having a magnetic tape (magnetic stripe) or an IC card having an IC (Integrated Circuit) chip. remembered.

After the cash withdrawal schedule is registered in the financial institution server 10, the user goes to one of the ATMs 20 and performs user authentication by biometric authentication when he/she wants to receive cash. When the user authentication is successful, the financial institution server 10 dispenses the amount of cash according to the payout schedule from the ATM 20 if the timing conforms to the payout schedule registered for the authenticated user. Therefore, in the information processing system 100 of the present embodiment, the user can receive the cash at the desired timing by setting the payout schedule by the administrator. In the information processing system 100 of the present embodiment, the administrator who manages the money of the user (cash recipient) who receives the payment of cash may be one or more administrators. A single administrator may manage one or more users.

FIG. 2 is a block diagram showing an example internal configuration of the ATM 20. As shown in FIG. The ATM 20 includes a control unit 21, a storage unit 22, a touch panel 23, a communication unit 24, a card reading unit 25, a biometric authentication sensor 26, a cash dispensing unit 27, a speaker 28, etc. These units are interconnected via a bus. It is The control unit 21 includes one or more processors such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), or a GPU (Graphics Processing Unit). The control unit 21 appropriately executes a control program 22P stored in the storage unit 22, thereby executing various information processing and control processing that the ATM 20 should perform. The storage unit 22 includes a RAM (Random Access Memory), flash memory, hard disk, SSD (Solid State Drive), and the like. The storage unit 22 stores in advance a control program 22P executed by the control unit 21 and various data necessary for executing the control program 22P. The storage unit 22 also temporarily stores data generated when the control unit 21 executes the control program 22P.

The touch panel 23 has a display section 23a and an input section 23b. The display unit 23 a is a liquid crystal display, an organic EL display, or the like, and displays various information according to instructions from the control unit 21 . The input unit 23b is a touch sensor, receives an operation input by a user who operates the ATM 20, and sends a control signal corresponding to the operation content to the control unit 21. FIG. Note that the display unit 23a and the input unit 23b may be provided separately, and the input unit 23b may include an operation button such as a pressing type other than the touch sensor. The communication unit 24 has an interface for connecting to the network N by wired communication or wireless communication, and transmits and receives information to and from another device via the network N.

The card reading unit 25 is a magnetic card reader or an IC card reader, reads card information stored in a magnetic tape or IC chip provided on the card 30 , and sends the read card information to the control unit 21 . The card reading unit 25 reads card information from the card 30 inserted into the ATM 20 through the card insertion slot 20a. The card reading unit 25 may be configured to read the card 30 placed at a predetermined position of the housing of the ATM 20 in a contact or non-contact manner.

The biometric sensor 26 acquires vein data by reading the veins of the palm held up within a predetermined detection range, and sends the acquired vein data to the control unit 21 . The biometric sensor 26 has, for example, a light-emitting portion that emits near-infrared light and a light-receiving portion that receives light reflected by the palm of the near-infrared light emitted by the light-emitting portion. Get data. The biometric sensor 26 may be a built-in sensor configured integrally with the ATM 20 as shown in FIG. 1, or may be a sensor externally attached to the ATM 20 . When the biometric sensor 26 is externally attached, the ATM 20 has a connection unit that can be connected to an external sensor via, for example, a USB (Universal Serial Bus) cable, or a wireless communication unit that can wirelessly communicate with the external sensor. and is configured to acquire vein data acquired by the external sensor via the connection unit or the wireless communication unit.

The cash dispensing unit 27 has, for example, a transport path for transporting cash stored in the cash storage unit to the cash tray 20b for each denomination, and an opening/closing unit for opening/closing each transport path. The cash dispensing unit 27 opens and closes each transport path with the opening/closing unit according to the instruction from the control unit 21, thereby conveying (dispensing) the amount of cash according to the instruction from the control unit 21 to the cash tray 20b. The speaker 28 is an audio output unit that outputs audio according to instructions from the control unit 21, and outputs audio messages instructed by the control unit 21. FIG.

In addition to the configuration described above, the ATM 20 includes a denomination discrimination unit that discriminates the denominations (amounts) of banknotes and money (cash) inserted in the cash tray 20b, and stores the inserted cash for each denomination to the cash storage unit. It has a cash receiving section (not shown) including a conveying section for conveying. The cash reception unit can store the inserted cash in the cash storage unit by denomination by transporting the inserted cash by denomination determined by the denomination determination unit by the transport unit.

FIG. 3 is a block diagram showing an internal configuration example of the financial institution server 10 and the administrator terminal 40. As shown in FIG. The financial institution server 10 includes a control section 11, a storage section 12, a communication section 13, an input section 14, a display section 15, a reading section 16, etc. These sections are interconnected via a bus. The control unit 11, the storage unit 12, the communication unit 13, the input unit 14, and the display unit 15 of the financial institution server 10 correspond to the control unit 21, the storage unit 22, the communication unit 24, the input unit 23b, and the display unit 23a of the ATM 20, respectively. Since they have the same configuration, detailed description will be omitted. In addition to the control program 12P executed by the control unit 11, the storage unit 12 of the financial institution server 10 stores a customer account DB 12a and a schedule DB 12b, which will be described later. The customer account DB 12a and the schedule DB 12b may be stored in another storage device connected to the financial institution server 10, or may be stored in another storage device with which the financial institution server 10 can communicate.

The reading unit 16 reads information stored in a portable storage medium 1a including CD (Compact Disc)-ROM, DVD (Digital Versatile Disc)-ROM, USB (Universal Serial Bus) memory, SD (Secure Digital) card, etc. read. The control program 12</b>P and various data stored in the storage unit 12 may be read from the portable storage medium 1 a by the control unit 11 via the reading unit 16 and stored in the storage unit 12 . The control program 12P and various data stored in the storage unit 12 may be downloaded from another device by the control unit 11 via the communication unit 13 and stored in the storage unit 12 .

The administrator terminal 40 includes a control section 41, a storage section 42, a communication section 43, an input section 44, a display section 45, etc., and these sections are interconnected via a bus. The control unit 41, the storage unit 42, the communication unit 43, the input unit 44, and the display unit 45 of the administrator terminal 40 correspond to the control unit 11, the storage unit 12, the communication unit 13, the input unit 14, and the financial institution server 10, respectively. Since the configuration is the same as that of the display unit 15, detailed description thereof will be omitted. In addition to the control program 42P executed by the control unit 41, the storage unit 42 of the administrator terminal 40 includes an Internet banking application program 42AP for using Internet banking provided by the financial institution server 10 (hereinafter referred to as Internet banking application 42AP). The Internet banking application 42AP may be downloaded by the control unit 41 from another device via the communication unit 43 and stored in the storage unit 42 . If the administrator terminal 40 has a reading unit that reads information stored in a portable storage medium, the Internet banking application 42 AP is read from the portable storage medium by the control unit 41 via the reading unit and stored in the storage unit 42 . may be stored in

FIG. 4 is a schematic diagram showing a configuration example of the DBs 12a and 12b stored in the financial institution server 10. As shown in FIG. FIG. 4A shows the customer account DB 12a, and FIG. 4B shows the schedule DB 12b. The customer account DB 12a stores information about each customer's (user's) account opened at a financial institution. The customer account DB 12a shown in FIG. 4A includes a branch number column, an account number column, a customer information column, a card information column, a user ID column, an administrator authentication data column, a deposit/withdrawal history column, and the like. store information about the customer and the account in association with the account number of the customer. The branch number column stores the identification information (branch number) assigned to each branch, including the main branch of the financial institution, and the account number column stores the identification information (account number) assigned to each account opened at each branch. ). The customer information column stores information relating to the customer of the account holder, and stores personal information such as the user's name, address, telephone number, date of birth, and the like. The card information column stores the card information stored in the card 30 issued to the customer (user) in association with each account. It stores the identification information (user ID) assigned to each user. The administrator authentication data string stores authentication data used for administrator authentication performed in login processing when using Internet banking provided by the financial institution server 10, for example. The administrator authentication data may be, for example, a login ID and password (character string data) assigned to an administrator who manages the user's money (account). It may be biometric data of the administrator when it is configured to perform administrator authentication using the . Note that when there are multiple administrators who manage each account (user), administrator authentication data for each of the multiple administrators is stored. The deposit/withdrawal history column stores history information regarding deposit/withdrawal transactions performed on the account. The history information includes information on normal deposit/withdrawal transactions for an account and information on withdrawal processing by cash withdrawal transactions according to a pre-registered withdrawal schedule. As the store number stored in the customer account DB 12a, the store number assigned to the store is stored by the control unit 11 when a new store is established. The account number, customer information, and card information stored in the customer account DB 12a are the account number assigned to the customer, the customer information specified by the customer, and the card 30 issued to the user when a new account is opened. The card information stored in is stored by the control unit 11 . As the user ID stored in the customer account DB 12a, the user ID assigned to the user is stored by the control unit 11 when the user who receives cash withdrawal from the account via the ATM 20 is registered. As the data for administrator authentication stored in the customer account DB 12a, the data for administrator authentication specified by the administrator is stored by the control unit 11, for example, when a user who receives cash payment is registered. As for the deposit/withdrawal history stored in the customer account DB 12a, the control unit 11 stores information about the deposit/withdrawal process when the deposit/withdrawal process is performed for each account. The contents stored in the customer account DB 12a are not limited to the example shown in FIG. 4A. Of the customers who have opened an account with a financial institution, the user ID and administrator authentication data are not registered in the customer account DB 12a for customers who have not concluded a contract for using cash withdrawal transactions.

The schedule DB 12b stores information about users who regularly receive cash payments. The schedule DB 12b shown in FIG. 4B includes a user ID column, a biometric authentication data column, a payout schedule column, a payout history column, and the like, and stores information on payout processing in association with the user ID. The user ID column stores identification information (user ID) assigned to each user, and the biometric authentication data column stores biometric data (vein data) used when performing biometric authentication for each user. The payout schedule column stores payout schedules indicating cash payout schedules set for each user. The payout history column stores information about cash payout processing performed for each user according to a payout schedule registered in advance. Specifically, the payment history column includes a date/time column, an ATM-ID column, and an amount column. The date and time column stores the date and time when the withdrawal process was performed, the ATM-ID column stores identification information (ATM-ID) assigned to the ATM 20 used for the withdrawal process, and the amount column stores the withdrawal process. stores the amount paid out by In addition to being stored in the schedule DB 12b, the biometric authentication data may be stored in a predetermined area of the storage unit 12 or another storage device. (for example, a file name indicating the storage location of the data). A user ID stored in the schedule DB 12b is issued and stored by the control unit 11 when a new user is added. The biometric data stored in the schedule DB 12b is stored by the control unit 11 as biometric data acquired from a user when a new user is added. The payout schedule stored in the schedule DB 12b is stored by the control unit 11 when input via the input unit 14 or the communication unit 13 when a new user is added, and is input via the input unit 14 or the communication unit 13. is changed by the control unit 11 when a change instruction is input. The payout history stored in the schedule DB 12b is stored by the control unit 11 when cash payout processing is performed for each user. The storage contents of the schedule DB 12b are not limited to the example shown in FIG. 4B, and may store various types of information related to users, and may store various types of information related to administrators.

In the present embodiment, processing performed by each device when an administrator sets a payout schedule for a user using the administrator terminal 40 and confirms a payout history by the user will be described below. 5 and 6 are flow charts showing an example of the payout schedule setting procedure, and FIGS. 7 to 9 are schematic diagrams showing examples of screens. The following processing is realized by the control unit 41 according to the control program 42P stored in the storage unit 42 of the administrator terminal 40, and the control unit 11 realized by A part of the following processing may be realized by a dedicated hardware circuit.

In the information processing system 100 of the present embodiment, when an administrator wants to set or change a payout schedule for a user managed by the administrator, the administrator's terminal 40 activates the Internet banking application 42AP. When the controller 41 of the administrator terminal 40 receives an instruction to execute the Internet banking application 42AP via the input unit 44, it activates the Internet banking application 42AP. When the Internet banking application 42AP is activated, the control unit 41 displays, for example, a login screen as shown in FIG. 7A on the display unit 45 (S11). The login screen includes input fields for inputting authentication data (specifically, login ID and password) used for login processing (administrator authentication) when using Internet banking provided by the financial institution server 10, and an input field. and a login button for instructing execution of login processing based on the login ID and password. It should be noted that when the login process is configured to perform administrator authentication using biometric data (for example, vein data), and the administrator terminal 40 is equipped with a sensor that reads the biometric data of the administrator, the login screen is , it may have a biometric data reading button for instructing reading of biometric data.

The administrator inputs the login ID and password on the login screen and operates the login button to instruct the execution of the login process. The control unit 41 of the administrator terminal 40 acquires the authentication data (login ID and password) of the customer (administrator) required for login processing via the login screen (S12), and confirms whether the login button has been operated. It is determined whether or not (S13). If the control unit 41 determines that the login button has not been operated (S13: NO), it continues acquiring authentication data (S12). When the control unit 41 determines that the login button has been operated (S13: YES), it requests the financial institution server 10 to perform administrator authentication based on the acquired authentication data (S14).

When the administrator terminal 40 requests administrator authentication based on the authentication data, the control unit 11 of the financial institution server 10 performs administrator authentication based on the acquired authentication data (S15). Specifically, the control unit 11 determines whether or not there is manager authentication data that matches the login ID and password acquired as the authentication data in the manager authentication data stored in the customer account DB 12a. do. If there is matching administrator authentication data, the control unit 11 determines that authentication has succeeded, and if there is no matching administrator authentication data, it determines that authentication has failed. The control unit 11 determines whether or not the administrator authentication has succeeded (S16), and if it determines that it has failed (S16: NO), an error screen (not shown) displaying a message indicating that the authentication has failed. ) is generated and transmitted to the administrator terminal 40 (S17). When receiving the error screen from the financial institution server 10, the control unit 41 of the administrator terminal 40 displays the error screen on the display unit 45 (S18) and notifies the administrator that the login process has failed.

If it is determined that the administrator authentication has succeeded (S16: YES), the control unit 11 of the financial institution server 10 selects one of the processes that can be executed using Internet banking, as shown in FIG. 7B. An initial screen for acceptance is generated and transmitted to the administrator terminal 40 (S19). When receiving the initial screen from the financial institution server 10, the control unit 41 of the administrator terminal 40 displays the initial screen on the display unit 45 (S20). The initial screen shown in FIG. 7B includes a cash withdrawal button for instructing execution of processing related to cash withdrawal transactions, a balance inquiry button for instructing execution of balance inquiry, and a transfer button for instructing execution of transfer or transfer processing.・ Display a transfer button, various change procedure buttons for instructing execution of various change procedures, etc. In addition to these buttons, the initial screen displays buttons for instructing execution of various processes that can be performed using Internet banking. The customer (administrator) selects the desired processing using Internet banking by operating any button on the initial screen.

The control unit 41 of the administrator terminal 40 determines whether or not the cash withdrawal button in the initial screen has been operated (S21), and if it determines that it has not been operated (S21: NO), another process while waiting. When another button on the initial screen is operated, the control unit 41 causes the financial institution server 10 to execute each process such as balance inquiry, transfer/transfer, and various change procedures corresponding to the operated button. , and the financial institution server 10 executes each process. If it is determined that the cash withdrawal button has been operated (S21: YES), the control unit 41 requests the financial institution server 10 to execute processing related to cash withdrawal transactions (S22). When the manager terminal 40 requests the controller 11 of the financial institution server 10 to execute a process related to a cash withdrawal transaction, as shown in FIG. is generated and transmitted to the administrator terminal 40 (S23). When receiving the user list screen from the financial institution server 10, the control unit 41 of the administrator terminal 40 displays the user list screen on the display unit 45 (S24). The screen shown in FIG. 7C displays a list of user names and user IDs that can be managed by the administrator who is the logged-in (authenticated) customer. It is configured. The control unit 11 reads the user information (user ID and user name) stored in the customer account DB 12a in association with the authenticated customer (administrator) information, and generates a user list displaying the read user information. By doing so, the screen shown in FIG. 7C is generated.

On the screen shown in FIG. 7C, the administrator selects a user who wants to set the payout schedule or check the payout history from among the users displayed in the user list. The control unit 41 of the administrator terminal 40 determines whether or not any user has been selected on the user list screen (S25). wait until If it is determined that any user has been selected (S25: YES), the control unit 41 requests the financial institution server 10 to display a menu screen regarding cash withdrawal transactions for the selected user (S26). When a menu screen is requested from the administrator terminal 40, the control unit 11 of the financial institution server 10 generates a menu screen corresponding to the selected user and sends it to the administrator terminal 40, as shown in FIG. 7D. Send (S27). When receiving the user's menu screen from the financial institution server 10, the control unit 41 of the manager's terminal 40 displays the user's menu screen on the display unit 45 (S28). The screen shown in FIG. 7D includes the name and user ID of the selected user, the last cash withdrawal execution date and time of this user's last cash withdrawal, and the processing (operation) that can be operated by the administrator for the user. A menu button for instructing execution is displayed. The menu buttons include a schedule setting button for instructing execution of the user's payout schedule setting process as an operation menu, and a payout history confirmation button for instructing display of the payout history by the user. In addition, as a management menu, it has a user information change button for instructing a setting change of information about a user and an administrator information change button for instructing a setting change of information about an administrator. The menu screen is not limited to the configuration shown in FIG. 7D, and may be configured to display the balance of the account associated with the user, for example.

Note that, for example, when the number of users that can be managed by the logged-in administrator is one, the control unit 11 of the financial institution server 10 does not generate the user list screen as shown in FIG. A menu screen may be generated and provided to the administrator terminal 40 . In this case, the control unit 11 of the financial institution server 10 and the control unit 41 of the manager's terminal 40 do not execute the processes of steps S23 to S26 in FIGS.

On the menu screen shown in FIG. 7D, the administrator operates the schedule setting button to instruct the user to execute the payout schedule setting process, and operates the payout history confirmation button to allow the user to display the payout history. instruct. Further, the administrator operates the user information change button to instruct the setting change of the registered information about the user, and operates the administrator information change button to instruct the setting change of the registered information about the administrator himself/herself. The control unit 41 of the administrator terminal 40 determines whether or not the schedule setting button has been operated on the menu screen (S29). A setting screen is requested from the financial institution server 10 (S30). When a payment schedule setting screen is requested from the administrator terminal 40, the control unit 11 of the financial institution server 10 generates a setting screen as shown in FIG. 8 and transmits it to the administrator terminal 40 (S31). . When receiving the setting screen from the financial institution server 10, the control unit 41 of the administrator terminal 40 displays the setting screen on the display unit 45 (S32).

The payment schedule setting screen shown in FIG. 8 is a screen for setting a schedule (conditions) for paying out cash to the user using the ATM 20 . Specifically, on the setting screen, as the payout schedule, the number of payouts per day can be set, the day of the week can be set for the payout, and whether or not to carry forward the amount that has not been paid out is set. It has input fields for inputting information related to carryover setting and amount setting for setting the amount to be paid out. The input field for setting the number of times has a check box for selecting one or more times per day, and an input field for a payout time period that allows cash to be paid out. The column is provided with a pull-down menu from which arbitrary times can be selected as the start time and end time of the payout period. The input field for setting the day of the week is a check box for selecting one of daily, weekly, and periodic, and if every week is selected, select any day from Monday to Sunday as a selectable day. and an input field for inputting a payout cycle (for example, once every two days or once every three days) when the cycle is selected. The carryover setting input field has a check box for selecting whether or not to pay out (carry over) the amount that was not paid out during the payout period (unpaid amount) at the time of the next or subsequent payouts, and an "Unpaid an input field for entering the number of days that can be carried over or the amount of money that can be carried over (upper limit of the amount of money that can be carried over) as the limit that can be carried over when "Amount can be carried over and paid out" is selected. The input field for setting the amount of money has an input field for inputting the amount of money to be paid out per time. In addition, the setting screen has a detailed setting button for instructing the execution of detailed settings that can be set for, for example, the payout time zone and amount for each date, and the setting of the payout schedule with the contents entered via the setting screen. and a setting button for instructing. If a payout schedule has already been set for the user for whom the payout schedule is to be set, the control unit 11 of the financial institution server 10 reads out the payout schedule of this user from the schedule DB 12b, and each information of the readout payout schedule. may be generated and provided to the administrator's terminal 40 in a state in which is entered in the corresponding input fields. The payout schedule setting screen is not limited to the configuration shown in FIG.

On the setting screen shown in FIG. 8, the administrator inputs setting contents in each input column according to the payout schedule agreed with the user. For example, when setting a payout schedule with a payout amount of 500 yen and a payout time period of 8:00 a.m. to 6:00 p.m., once a day , enter 8:00 to 18:00 as the payout time period, and enter 500 yen in the amount setting entry field. Then, the administrator operates the setting button when instructing the setting (registration) of the payout schedule based on the input contents. The control unit 41 accepts the setting contents (payout conditions) related to the payout schedule via the payout schedule setting screen, and displays the received setting contents in each input field (S33). Then, the control unit 41 determines whether or not the setting button of the setting screen has been operated (S34), and if it determines that the setting button has not been operated (S34: NO), continues to receive and display the setting contents (S33). . If it is determined that the setting button has been operated (S34: YES), the control unit 41 requests the financial institution server 10 to register the payout schedule with the setting contents input via the setting screen (S35).

When the registration of the payout schedule is requested, the control unit 11 (registration unit) of the financial institution server 10 stores the payout schedule in the schedule DB 12b based on the settings obtained from the administrator terminal 40 (S36). Specifically, the control unit 11 performs a registration process of storing, in the schedule DB 12b, the setting content received from the administrator terminal 40 as a payout schedule corresponding to the user ID of the user whose payout schedule is to be registered. After registering the payout schedule, the control unit 11 transmits a notification screen for notifying the registration completion to the manager terminal 40, and the manager terminal 40 displays the notice screen on the display unit 45 to confirm the payout schedule. The administrator may be notified of registration completion.

Although illustration is omitted, when the detailed setting button is operated on the payout schedule setting screen, the administrator terminal 40 acquires the detailed schedule setting screen from the financial institution server 10 and displays it on the display unit 45. , receives detailed setting contents regarding the payout schedule via the detailed schedule setting screen. The detailed schedule setting screen displays, for example, a calendar for one month, and has input fields for accepting inputs of payout time periods and payout amounts for each date. When the administrator terminal 40 receives the settings for each date via the detailed schedule setting screen, it registers the payout schedule based on the settings for each date in the financial institution server 10 (schedule DB 12b).

On the other hand, when determining that the schedule setting button has not been operated on the menu screen (S29: NO), the control section 41 determines whether or not the payout history confirmation button on the menu screen has been operated (S37). If it is determined that the payout history confirmation button has been operated (S37: YES), the control unit 41 requests the financial institution server 10 for history information (payout history) of cash payout processing performed for this user ( S38). When receiving a payment history request from the administrator terminal 40, the control unit 11 of the financial institution server 10 generates a payment history screen as shown in FIG. 9 and transmits it to the administrator terminal 40 (S39). When receiving the payout history screen from the financial institution server 10, the control unit 41 of the administrator terminal 40 displays the payout history screen on the display unit 45 (S40). The payment history screen shown in FIG. 9 displays the date and time when the user paid out cash using the ATM 20 and the amount (payment history), and the balance of the account associated with the user. The control unit 11 of the financial institution server 10 reads out the payout history stored in the schedule DB 12b in association with the user ID of the user, and displays the read out payout history information to display the payout history screen ( display information). The payout history screen is not limited to the configuration shown in FIG.

The payout history screen shown in FIG. 9 has a close button for instructing to end the display of the screen. The display of the history screen is ended, and the display returns to the menu screen shown in FIG. 7D, for example. The control unit 41 may be configured to transmit the payout history screen to a printer via the communication unit 43, for example, or may be configured to transmit to another device via the communication unit 43. . With such a configuration, the payout history screen can be displayed not only on the display unit 45 of the manager's terminal 40, but also printed on paper by a printer or transmitted to another device. In this case, the payout history screen may have a print button for instructing printing of the screen and a send button for instructing transmission of the screen.

When determining that the payout history confirmation button has not been operated on the menu screen (S37: NO), the control section 41 skips steps S38 to S40 and ends the process. When the user information change button is operated on the management menu in the menu screen, the control unit 41 of the administrator terminal 40 acquires a user information change screen (not shown) from the financial institution server 10 and displays it. , accepts an instruction to change the setting information about the user via the user information change screen. For example, the user information change screen is configured to receive an instruction to change the vein data of the user. When the control unit 41 receives an instruction to change the vein data via the user information change screen, the financial institution server 10 The biometric authentication data stored in the schedule DB 12b is updated with the received vein data. Further, when the administrator information change button is operated, the control unit 41 of the administrator terminal 40 acquires and displays an administrator information change screen (not shown) from the financial institution server 10, and displays the administrator information change screen. Receives an instruction to change the setting information about the administrator via the screen. For example, the administrator information change screen is configured to receive administrator authentication data such as a password. When receiving authentication data via the manager information change screen, the control unit 41 updates the manager authentication data stored in the customer account DB 12a of the financial institution server 10 to the received authentication data.

Through the above-described processing, the administrator can set and change payout schedules for the users managed by him/herself, and can check the payout history of each user. In addition, the administrator can execute various processes after being authenticated as an administrator with appropriate authority through authentication processing based on his or her own authentication data, thereby ensuring safety in Internet banking. can.

Next, processing performed by each device when the user uses the ATM 20 to receive cash payment will be described. FIG. 10 is a flowchart showing an example of a payout processing procedure, and FIG. 11 is a schematic diagram showing an example of a screen. The following processing is implemented by the control unit 21 according to the control program 22P stored in the storage unit 22 of the ATM 20, and is implemented by the control unit 11 according to the control program 12P stored in the storage unit 12 of the financial institution server 10. . A part of the processing may be realized by a dedicated hardware circuit.

In the ATM 20 in the standby state, the control unit 21 determines whether or not the card reading unit 25 has read the card information from the card 30 inserted from the card insertion slot 20a (S51), and determines that the card information has not been read. If so (S51: NO), wait. If it is determined that card information has been read from the card 30 (S51: YES), the control unit 21 displays a biometrics authentication screen requesting biometrics authentication on the display unit 23a (touch panel 23) as shown in FIG. 11 (S52). ). The biometrics authentication screen shown in FIG. 11 notifies the user of the use of the palm for biometrics authentication and the installation location of the biometrics sensor 26 held over the palm. In this embodiment, the card 30 is a dedicated card for cash withdrawal transactions, so when the card information is read from the card 30, the control unit 21 of the ATM 20 displays a biometric authentication screen on the display unit 23a. Not limited to configuration. For example, if the card 30 is a card used for various transactions at the ATM 20, the control unit 21 once transmits the read card information to the financial institution server 10, and sends the card information to the financial institution server 10. may be configured to inquire whether or not a contract for a cash dispensing transaction has been concluded, and display a biometric authentication screen if the contract for a cash dispensing transaction has been concluded.

The control unit 21 determines whether biometric data (in this case, vein data) has been acquired by the biometric authentication sensor 26 (S53), and if it is determined that it has not been acquired (S53: NO), it waits until it is acquired. . In the standby state, the control unit 21 may output a message prompting reading of the biometric data by voice from the speaker 28, and if a light is provided near the biometric authentication sensor 26, turn on the light or turn on the light. The location of the biometric sensor 26 may be communicated to the user by blinking.

If the biometric sensor 26 determines that biometric data has been acquired (S53: YES), the control unit 21 requests the financial institution server 10 for user authentication based on the acquired biometric data (S54). Here, the control unit 21 transmits the card information read from the card 30 and the biometric data obtained from the user's palm to the financial institution server 10 to request user authentication. When the administrator terminal 40 requests user authentication based on biometric data, the control unit 11 (authentication unit) of the financial institution server 10 performs user authentication based on the acquired biometric data (S55). Specifically, the control unit 11 reads the user ID corresponding to the card information received from the ATM 20 from the customer account DB 12a, and reads the biometric authentication data corresponding to the read user ID from the schedule DB 12b. Then, the control unit 11 determines whether or not the biometric authentication data read from the schedule DB 12b matches the biometric data received from the ATM 20. If they match, it determines that the authentication has succeeded, and if they do not match, it determines that the authentication has failed. to decide.

The control unit 11 determines whether or not the user authentication has succeeded (S56), and if it determines that it has failed (S56: NO), an error screen displaying a message indicating that the authentication has failed and cash cannot be dispensed. (not shown) is generated and transmitted to the ATM 20 (S57). When receiving the error screen from the financial institution server 10, the control unit 21 of the ATM 20 displays the error screen on the display unit 23a (S58), and notifies the user that cash cannot be dispensed due to biometric authentication failure. If the control unit 11 determines that the user authentication has succeeded (S56: YES), it determines whether cash can be paid out (withdrawal) at this point based on the payout schedule of the authenticated user. It judges (S59). Here, the control unit 11 reads out the payout schedule and payout history of the authenticated user from the schedule DB 12b, determines whether or not the payout at this time matches the timing according to the readout payout schedule, If so, it will be judged that it can be paid out. For example, if the payout schedule is registered once a day and the cash for today has already been paid out, the payout at this time does not match the payout schedule, so the control unit 11 cannot pay out. I judge. In addition, the control unit 11 reads out the balance of the user's withdrawal account from the deposit/withdrawal history stored in the customer account DB 12a, determines whether the read balance is less than the amount to be paid out, and If the amount is less than the scheduled payout amount, it may be determined that the payout is not possible (insufficient balance).

If it is determined that it is possible to pay out at this time (S59: YES), the control unit 11 (payout unit) transmits to the ATM 20 an instruction to pay out the amount of cash set in the payout schedule (S60). If there is cash that has not been dispensed by the previous disbursement timing, the control unit 11 calculates the disbursable amount based on the undisbursed amount and the set carry-over upper limit amount. A cash withdrawal instruction for the amount is transmitted to the ATM 20 . Then, the control unit 11 includes the date and time at this point in time, the ATM-ID of the ATM 20 that transmitted the payment instruction, and the amount of money as the payment history corresponding to the user ID of the user who paid out the cash, that is, the user authenticated in step S55. The payout history information is stored in the schedule DB 12b (S61). Note that the control unit 11 stores, in the customer account DB 12a, payment history information including the date and amount at this point in time as a payment history for the account of the user who paid out cash. As a result, cash is withdrawn from the user's account, and its history information is registered in the customer account DB 12a. When the control unit 21 of the ATM 20 receives the cash dispensing instruction from the financial institution server 10, the cash dispensing unit 27 dispenses (pays) the amount of cash according to the dispensing instruction (S62). After that, the control unit 21 displays a completion screen for notifying that the cash dispensing process has been completed on the display unit 23a (S63), and ends the series of processes. Note that the control unit 11 of the financial institution server 10, for example, after the process of step S61, informs the administrator terminal 40 of the administrator corresponding to the user who has paid out cash that the user has received cash (payment history) may be transmitted. In this case, every time the user receives cash, it is possible to notify the administrator.

If it is determined in step S59 that payment is not possible (S59: NO), the control unit 11 generates a payment-impossible screen (not shown) notifying that cash cannot be paid out at this time and transmits it to the ATM 20 ( S64). When receiving the withdrawal prohibition screen from the financial institution server 10, the control unit 21 of the ATM 20 displays the withdrawal prohibition screen on the display unit 23a (S65), and notifies the user that cash cannot be received at this time. Note that the control unit 11 of the financial institution server 10 may specify the next available date and time for payment from the user's payout schedule and provide the ATM 20 with a disallowed payment screen that notifies the specified date and time. For example, the control unit 11 may provide the ATM 20 with a dispensable screen that displays a message such as "You can receive cash at 1:00 pm today" or "The next payment will be at 8:00 am tomorrow morning." The control unit 21 of the ATM 20 may output a message notifying that cash cannot be dispensed at the present time and a message notifying the next possible dispensation date and time from a speaker 28 in addition to displaying the dispensation prohibition screen. In addition, the control unit 11 of the financial institution server 10, for example, after the process of step S64, notifies the manager terminal 40 of the administrator corresponding to the user who failed to pay out cash that the user failed to pay out cash. may be transmitted. At this time, the control unit 11 may notify the administrator terminal 40 of the reason why the cash payment has failed (for example, payment has already been made or the balance is insufficient). In this case, the administrator can grasp the timing when the user tries to pay out the cash, and can grasp the insufficient balance at an early stage.

With the above-described processing, cash is dispensed to the user when the user is authenticated as an appropriate user by user authentication based on the user's biometric data, so the user can obtain cash at the desired timing. be able to. In addition, since the cash payout process for each user is performed according to the payout schedule set for each user, cash exceeding the amount set in the payout schedule is not paid out. Therefore, waste by the user does not occur. In addition, since the payout schedule can be set for each user, it is possible to set different payout timings and payout amounts for each user. Furthermore, in the information processing system 100 of the present embodiment, cash is dispensed to the user using the ATM 20 installed in the city. It is only necessary to deposit money, and for example, there is no need to prepare cash to be handed over to the user in advance. Therefore, the burden required for the user's money management can be reduced. In addition, for example, it is possible to temporarily hand cash to the user separately from the timing according to the payout schedule.

In this embodiment, when the user uses the ATM 20 to withdraw cash, the financial institution server 10 performs user authentication based on the card information read from the card 30 and the user's biometric data. not. For example, the configuration may be such that user authentication is performed based only on the biometric data of the user. In this case, when the user wants to receive cash via the ATM 20, the user causes the ATM 20 to read his biometric data. The financial institution server 10 determines whether or not the biometric data of the user read by the ATM 20 matches the biometric authentication data of any user registered in the schedule DB 12b. identifies the user that matches, and determines that the identified user has been successfully authenticated. In such a configuration, the user does not need to carry the card 30 with him/her, and when he/she wishes to receive cash, he or she can hold the palm of his or her hand over the ATM 20, resulting in good operability.

In this embodiment, an account is opened at a financial institution in the user's name for each user who receives cash payment, and this account is used as an account for cash payment. In other words, one account for cash withdrawal is prepared for one user, and the administrator may appropriately deposit money into the account for cash withdrawal of the user managed by himself/herself. The deposit to the user's cash withdrawal account may be any of deposit from another account under the name of the user, deposit from the manager's account, deposit from another person's account, and deposit in cash. good too. Therefore, for example, when one manager manages the money of a plurality of users, the money can be appropriately deposited into each user's account for cash withdrawal, and the burden of money management does not increase. Also, one account in the name of the user may have a normal deposit account and an account for cash withdrawal. In this case, the administrator can maintain the balance of the cash withdrawal account by appropriately depositing (transferring) the funds from the normal deposit account to the cash withdrawal account in the user's account. In the configuration of this embodiment as described above, one administrator can manage the money of multiple users, and the money of one user can be managed by multiple administrators. It is possible.

In this embodiment, the financial institution server 10 transmits notification information to the administrator terminal 40 when the user receives cash via the ATM 20 or fails to withdraw cash. This allows the administrator to grasp the cash withdrawal status (payment history) of the user and the insufficient balance of the account for cash withdrawal. In addition, the financial institution server 10 may notify the administrator terminal 40 of the fact that the user has not paid out cash at the timing registered in the payout schedule, for example. Specifically, the control unit 11 of the financial institution server 10 causes the administrator terminal 40 to You may transmit the notification information which notifies that the payment of cash was not performed. In this case, the administrator can grasp that the user did not pay out the cash. In this way, by notifying the manager of the daily disbursement status (disbursement history) including the fact that the user did not disburse cash, the manager can grasp the user's living condition. For example, if the user pays out cash at a predetermined time every day, the administrator can grasp the user's health condition based on the user's payment situation. In addition, for example, when a user who has paid out cash at a predetermined time every day does not pay out cash, the administrator can grasp changes in the user's physical condition. Management is also possible. In addition, since the administrator is notified when cash is not paid out, the administrator can quickly grasp changes in the physical condition of the user. In addition, the financial institution server 10 notifies the manager terminal 40 when the balance of the user's cash withdrawal account becomes insufficient, and also notifies the manager terminal 40 when the balance of the cash withdrawal account reaches a predetermined amount (e.g., one day's worth of payment). You may notify when it becomes less than the amount or the amount paid out for one week). In this case, the administrator can grasp the occurrence of insufficient balance in advance.

As described above, the content that the financial institution server 10 notifies to the administrator's terminal 40 may be configured to be selectable by the administrator. For example, the content of the notification may be that cash has been paid out, that cash has not been paid out, that cash has failed to be paid out, or that the balance of the account for cash withdrawal is insufficient (balance (2) is selected and registered in the financial institution server 10. Then, the financial institution server 10 transmits notification information corresponding to each user to the administrator terminal 40 at an appropriate notification timing, according to the registered contents of each user. According to such a configuration, transmission of unnecessary notification information to the administrator's terminal 40 is suppressed, and the administrator can receive notification of necessary information.

(Embodiment 2)
In addition to the ATM 20, an information processing system that pays out cash to a user using a cash dispensing device that stores cash inside the device and dispenses cash according to a registered dispensing schedule associated with the user will be described. FIG. 12 is a schematic diagram showing a configuration example of an information processing system according to the second embodiment. The information processing system 100 of this embodiment includes a cash dispensing device 50 in addition to the financial institution server 10, the ATM 20, and the administrator's terminal 40, and the cash dispensing device 50 can be connected to the network N. The financial institution server 10, the ATM 20, and the administrator terminal 40 of the present embodiment are the same devices as the financial institution server 10, the ATM 20, and the administrator terminal 40 of the first embodiment, so detailed description thereof will be omitted. .

The cash dispenser 50 is installed and used in private residences, common areas of collective housing, medical facilities, welfare facilities, and the like. In the cash dispensing device 50 of the present embodiment, the number of users (cash recipients) who receive cash dispensing may be one or more, and the number of administrators who manage the deposits and withdrawals of each user may be one. or multiple people. In the following, a case where the cash dispenser 50 is installed in a facility where a plurality of administrators manage a plurality of users will be described as an example.

The cash dispensing device 50 of the present embodiment has, for example, a square prism-shaped housing, and inside the housing is a cash storage unit (not shown) in which banknotes and money (cash) are stored by denomination (money amount). ) are provided. A touch panel 53 is provided on one surface of the cash dispensing device 50 , and the surface on which the touch panel 53 is provided is the front surface of the cash dispensing device 50 . A cash slot 50b for inserting banknotes and coins is provided in front of the cash dispenser 50, and the denomination of cash inserted from the cash slot 50b is determined by a denomination determination unit 57a (see FIG. 13). After the (money amount) is discriminated, it is stored in the cash storage unit for each discriminated denomination. A payout port and a payout tray 56a are provided in front of the cash payout device 50, through which cash paid out by the cash payout unit 56 (see FIG. 13) is discharged. Furthermore, a speaker 58 is provided in front of the cash dispenser 50 . The arrangement positions of the touch panel 53, the cash slot 50b, the payout tray 56a, and the speaker 58 are not limited to the example shown in FIG. good. For example, the touch panel 53 may be provided at a position where the operator who operates the cash dispenser 50 can easily operate it, and the speaker 58 may be provided at a position where the operator can hear the output sound. The cash slot 50b may be provided at a position where cash can be easily thrown into the cash dispenser 50, and the payout slot and payout tray 56a may be provided at a position where cash dispensed from the cash dispenser 50 can be easily taken. good.

A biometric authentication sensor 55 is provided on the upper surface of the cash dispenser 50 . The biometric sensor 55 of the present embodiment is a vein sensor that reads palm veins, and the cash dispenser 50 of the present embodiment is configured to perform biometric authentication using palm veins. However, the biometric authentication by the cash dispenser 50 is not limited to palm vein authentication, and may be biometric authentication using finger veins, fingerprints, irises, voiceprints, face shapes, etc., and a combination of a plurality of biometric information. The configuration may be such that authentication is performed by The biometric authentication sensor 55 may be provided on a surface other than the upper surface of the cash dispenser 50, and is located at a position where the operator can easily perform an operation required for biometric authentication (for example, an operation of holding the palm up), depending on the type of biometric authentication. It is sufficient if it is set in Further, a side face of the cash dispenser 50 is provided with a collective insertion slot 50a for collectively inserting banknotes and coins, and a lid with a key is attached to the collective insertion slot 50a. After the denomination (money amount) of the cash inserted from the collective insertion port 50a is discriminated by the denomination discriminating section 57a, the denomination is stored in the cash storage section for each discriminated denomination. The collective insertion port 50a may be provided on a surface other than the side surface of the cash dispensing device 50, and may be provided at a position where the operator can easily insert cash collectively. The cash dispenser 50 configured as described above is placed on, for example, a horizontal platform, and fixed to a platform, a wall, a pillar, or the like with a mounting bracket 50c for use.

FIG. 13 is a block diagram showing an internal configuration example of the cash dispenser 50. As shown in FIG. The cash dispensing device 50 includes a control unit 51, a storage unit 52, a touch panel 53, a communication unit 54, a biometric sensor 55, a cash dispensing unit 56, a cash receiving unit 57, a speaker 58, etc., and these units are connected via a bus. interconnected. The control unit 51, the storage unit 52, the touch panel 53, the communication unit 54, the biometric sensor 55, the cash dispensing unit 56, and the speaker 58 of the cash dispensing device 50 correspond to the control unit 21, the storage unit 22, the touch panel 23, Since it has the same configuration as the communication unit 24, the biometric authentication sensor 26, the cash dispensing unit 27, and the speaker 28, detailed description thereof will be omitted. In addition to the control program 52P executed by the control unit 51, the storage unit 52 of the cash dispenser 50 stores an administrator information DB 52a and a user information DB 52b, which will be described later. The administrator information DB 52a and the user information DB 52b may be stored in another storage device connected to the cash dispensing device 50, or may be stored in another storage device with which the cash dispensing device 50 can communicate.

The cash reception unit 57 includes, for example, a denomination discrimination unit 57a that discriminates the denominations (amounts) of banknotes and money (cash) inserted from the batch insertion port 50a or the cash insertion port 50b. It has a transport path for transporting to the cash storage unit and a guide part for guiding the inserted cash to each transport path for each denomination. The cash receiving unit 57 guides the inserted cash to each transport path by the guide unit according to the denomination determined by the denomination determining unit 57a, so that the inserted cash is determined according to the amount (denomination). It is conveyed to the cash storage part on the conveying path. When the denomination discrimination unit 57a discriminates the denomination of the cash inserted from the collective insertion port 50a or the cash insertion port 50b, it notifies the control unit 51 of the discriminated denomination.

FIG. 14 is a schematic diagram showing a configuration example of the DBs 52a and 52b stored in the cash dispenser 50. As shown in FIG. FIG. 14A shows the administrator information DB 52a, and FIG. 14B shows the user information DB 52b. The manager information DB 52a stores information about the manager who manages the cash of the user who uses the cash dispenser 50 and the state of deposits and withdrawals. Here, the administrator is, for example, an employee of a facility in which the cash dispenser 50 is installed, and is a person in charge of managing deposits and withdrawals of users using the cash dispenser 50 . The administrator information DB 52a shown in FIG. 14A includes an administrator ID column, an authentication data column, a user information column in charge, a work history column, and the like, and stores each piece of information about the administrator in association with the administrator ID. The administrator ID column stores identification information (administrator ID) assigned to each administrator, and the authentication data column stores data used when authenticating each administrator. Note that the administrator authentication data may be, for example, a password (character string data) designated by the administrator, or biometric data (palm vein data in this embodiment) that can be read by the biometric authentication sensor 55. may In this embodiment, a configuration in which both the password and biometric data are stored in the administrator information DB 52a will be described as an example, but only one of them may be stored in the administrator information DB 52a. The user information column in charge stores information on users assigned to each administrator, specifically, user identification information (user ID) assigned to users assigned to each administrator. The work history column stores history information including the content and date and time of work performed by each manager on the cash dispenser 50 . The work history information includes, for example, the date and time when the administrator logged in to the cash dispenser 50, the date and time when the administrator performed various setting processes for the user in charge, the deposit/withdrawal history of the user in charge of the administrator, including the date and time when the administrator confirmed all the operations performed by the administrator on the cash dispenser 50 . In addition to being stored in the administrator information DB 52a, the authentication data and work history may be stored in a predetermined area of the storage unit 52 or another storage device. In this case, the authentication data string and work history string are Information for reading each data (for example, a file name indicating the storage location of the data) is stored.

The administrator ID stored in the administrator information DB 52a is issued and stored by the control unit 11 when a new administrator is added. The authentication data and the user information in charge stored in the administrator information DB 52a are stored by the control unit 51 when input via the input unit 53b or the communication unit 54 when a new administrator is added, It is changed by the control unit 51 when a change instruction is input via the input unit 53b or the communication unit . When palm vein data is used as the authentication data, the authentication data is input via the biometric sensor 55 . In the work history stored in the administrator information DB 52a, when the administrator performs an operation (work) on the cash dispensing device 50 via the input unit 53b, the control unit 51 stores the work date and time and the work content in association with each other. be done. The storage contents of the administrator information DB 52a are not limited to the example shown in FIG. 14A, and can store various kinds of information about administrators. For example, the configuration may be such that the administrator's name, department, etc. are stored.

The user information DB 52b stores information about users who deposit cash in the cash dispenser 50 and receive cash payments periodically. A user is, for example, a user or a resident of a facility in which the cash dispenser 50 is installed. The user information DB 52b shown in FIG. 14B includes a user ID column, a biometric authentication data column, a name column, a payment schedule column, a deposit/withdrawal history column, etc., and stores each piece of information about the user in association with the user ID. The user ID column stores identification information (user ID) assigned to each user, the biometric authentication data column stores biometric data (vein data) used when biometric authentication is performed for each user, The name column stores the name of each user. The payment schedule column stores a payment schedule (payment schedule) indicating a payment schedule set for each user, and the deposit/withdrawal history column stores details of deposits/withdrawals made corresponding to each user. Store historical information including date and time. Note that the deposit/withdrawal history information includes, for example, history information such as the date and time of deposit by the administrator and the amount of deposit, and the date and time of withdrawal by the user and the amount of withdrawal. In addition to being stored in the user information DB 52b, the biometric authentication data and deposit/withdrawal history may be stored in a predetermined area of the storage unit 52 or another storage device. The column stores information for reading each data (for example, file name indicating the storage location of the data).

A user ID stored in the user information DB 52b is issued and stored by the control unit 51 when a new user is added. The biometric authentication data stored in the user information DB 52b is stored by the control unit 51 when input via the biometric authentication sensor 55 when a new user is added, and is input via the input unit 53b or the communication unit 54. is changed by the control unit 51 when input is made through the biometric authentication sensor 55 when a change is instructed. The name stored in the user information DB 52b is stored by the control unit 51 when the name is input via the input unit 53b or the communication unit 54 when a new user is added. The withdrawal schedule stored in the user information DB 52b is stored by the control unit 51 when input via the input unit 53b or the communication unit 54 when a new user is added, and It is changed by the control unit 51 when a change instruction is input via 54 . The deposit/withdrawal history stored in the user information DB 52b is stored in association with the date and time of deposit and the amount of deposit by the control unit 51 when the deposit is made in association with the user, and when the withdrawal is made by the user The date and time of payment and the amount of payment are stored in association with each other by the control unit 51 . The contents stored in the user information DB 52b are not limited to the example shown in FIG. 14B, and can store various types of information about users. For example, the user's age, gender, patient ID card number at a medical institution, hospital room number in the case of hospitalization, room number in the case of living in a welfare facility, address, telephone number, contact information such as family (phone number, etc.) ) and other personal information may be stored.

In the information processing system 100 of this embodiment, the administrator terminal 40 and the financial institution server 10 execute the same processes as those shown in FIGS. As a result, the administrator authenticated based on the administrator authentication data can set and change the payout schedule (withdrawal schedule) of the user managed by the administrator in the financial institution server 10 (schedule DB 12b). , the user's payout history can be checked. In the information processing system 100 of the present embodiment, after the process of step S36, the control unit 11 of the financial institution server 10 associates the payout schedule stored in the schedule DB 12b with the user ID of the user whose payout schedule is registered. and transmit it to the cash dispenser 50 registered for use by this user. When receiving the user ID and the payout schedule from the financial institution server 10, the cash payout device 50 stores the received payout schedule in the user information DB 52b as the payout schedule corresponding to the received user ID. As a result, the payout schedule registered in the financial institution server 10 using the administrator terminal 40 can also be registered in the cash payout device 50 . Information on the cash dispenser 50 registered for use by each user is stored, for example, in the schedule DB 12b in association with the user ID.

The cash dispensing device 50 of this embodiment registers the dispensing schedule (withdrawal schedule) transmitted from the financial institution server 10 in the user information DB 52b, and also registers the withdrawing schedule input via the input unit 53b as user information. It can be registered in the DB 52b. Further, the cash dispensing device 50 is configured to receive deposits in association with registered users, and is configured to allow viewing of the history of deposit and withdrawal processing performed for the users. Below, when the administrator operates the cash dispensing device 50 to set a withdrawal schedule for the user, confirm the user's deposit/withdrawal history, and register deposits for the user, the cash dispensing device 50 The processing to be performed will be described. FIG. 15 is a flow chart showing an example of a payment schedule setting processing procedure by the cash dispensing device 50, and FIGS. 16 to 18 are schematic diagrams showing examples of screens. The following processing is realized by the control unit 51 according to the control program 52P stored in the storage unit 52 of the cash dispenser 50, but part of the processing may be realized by a dedicated hardware circuit.

When the cash dispenser 50 is in the standby state, the initial screen (login screen) as shown in FIG. 16A, for example, is displayed on the touch panel 53 (display unit 53a). The login screen includes entry fields for entering a login ID and password, a login button for instructing execution of login processing based on the entered login ID and password, and a biometrics button for instructing reading of biometric data. and a data read button. When operating the cash dispenser 50, the administrator inputs a login ID and password on the login screen and operates a login button, or operates a biometric data reading button to instruct execution of login processing. For the login ID, for example, an administrator ID assigned to each administrator is used.

In the cash dispenser 50 displaying the login screen as shown in FIG. 16A, the control unit 51 determines whether or not the administrator authentication data necessary for login processing has been acquired (S71). For example, when the administrator enters a login ID and password on the login screen and operates a login button, the control unit 51 acquires the login ID and password as authentication data. The login ID and password are input via a keyboard or numeric keypad displayed on the touch panel 53, for example. If the cash dispenser 50 has a card reader for reading card information stored in an IC card, for example, the administrator ID and password can be read from the IC card storing the administrator ID and password of each administrator. may be read. Further, when the administrator operates the biometric data reading button on the login screen, the control unit 51 displays a message prompting the reader to read the vein data on the touch panel 53 or outputs a voice from the speaker 58 . Acquire vein data. The message prompting the reader to read the vein data may be, for example, "Hold your palm over the biometric sensor", "Hold your palm over the upper surface of the device", or the like. Alternatively, a light may be provided near the biometric sensor 55, and the control unit 51 may notify the location of the biometric sensor 55 and encourage reading of the vein data by lighting or blinking the light.

If the control unit 51 determines that the administrator's authentication data has not been acquired (S71: NO), it waits until the data is acquired. If it is determined that the administrator's authentication data has been acquired (S71: YES), the controller 51 authenticates the administrator based on the acquired authentication data (S72). Specifically, when the controller 51 acquires an administrator ID and a password as authentication data, the authentication data (password) stored in the administrator information DB 52a in association with the acquired administrator ID is: It is determined whether or not the acquired passwords match, and if it is determined that they match, it is determined that the authentication has succeeded. Further, when vein data is acquired as authentication data, the control unit 51 determines whether or not the acquired vein data matches any of the authentication data (vein data) stored in the administrator information DB 52a. If it is determined that they match, it is determined that the authentication has succeeded. At this time, the control unit 51 identifies the administrator (administrator ID) corresponding to the authentication data that matches the acquired vein data, and determines that the identified administrator has been successfully authenticated.

The control unit 51 determines whether or not the authentication of the administrator based on the obtained authentication data has succeeded (S73), and if it has failed (S73: NO), returns to the process of step S71. At this time, the control unit 51 may display or audibly output a message indicating that the authentication has failed, and after displaying or audibly outputting the message, returns to displaying the login screen shown in FIG. 16A. If it is determined that the administrator has been successfully authenticated based on the acquired authentication data (S73: YES), the control unit 51 generates a list screen of users for whom the authenticated administrator is in charge, as shown in FIG. 16B. is displayed on the touch panel 53 (S74). The screen shown in FIG. 16B displays the administrator ID of the logged-in (authenticated) administrator, and a list of names and user IDs of users who are in charge of this administrator (list of users in charge). Note that the name and user ID of each user can be selected from the list of users in charge. The screen shown in FIG. 16B also has an end button for instructing the end of the operation by the administrator. The control unit 51 reads the user information (user ID) in charge stored in the administrator information DB 52a in association with the administrator ID of the authenticated administrator, and retrieves the name of the user of the read user ID from the user information DB 52b. A list of users in charge is generated by reading out and displaying the names and user IDs of users in charge. Then, the control unit 51 generates the screen shown in FIG. 16B by adding the administrator ID of the logged-in administrator and the end button to the generated list of users in charge. Note that after the administrator is authenticated successfully, the control unit 51 generates login history information indicating that the login process has been performed, including the date and time at this point in time, as the work history corresponding to the administrator ID of the authenticated administrator. is stored in the administrator information DB 52a.

On the screen shown in FIG. 16B, the administrator selects a user to be operated from among the users displayed in the list of users in charge. The control unit 51 determines whether or not selection of any user has been accepted through the list of users in charge (S75), and if it is determined that it has not been accepted (S75: NO), it waits until acceptance. When the end button is operated in the list of users in charge, the control unit 51 ends the display of the list of users in charge and returns to the display of the login screen shown in FIG. 16A.

If it is determined that any user has been selected from the list of users in charge (S75: YES), the control unit 51 generates a menu screen corresponding to the selected user and displays it on the touch panel 53, as shown in FIG. 16C. Display (S76). The menu screen shown in FIG. 16C includes the administrator ID of the logged-in administrator, the name and user ID of the selected user, and the current balance of this user (the amount of money received from the cash dispenser 50 minus the amount of money paid). (remaining amount) and the date and time of the last cash payment by the user are displayed. In addition, the execution date and time of the final payment may be the execution date and time of the payment by the cash dispenser 50 or the execution date and time of the payment by the ATM 20 . In the case of the execution date and time of withdrawal by the ATM 20 , the control unit 51 acquires from the financial institution server 10 the last withdrawal execution date and time when the user last used the ATM 20 to withdraw cash. The menu screen shown in FIG. 16C also has a menu button for instructing the user to execute a process (operation) that can be operated by the administrator, and an end button for instructing the user to finish the operation. . The menu buttons are associated with the user as a schedule setting button for instructing execution of the user's withdrawal schedule setting process as an operation menu, and a deposit/withdrawal history confirmation button for instructing the user to display the deposit/withdrawal history. and a deposit button for depositing money. In addition, as a management menu, it has a user information change button for instructing a setting change of information about a user and an administrator information change button for instructing a setting change of information about an administrator. The control unit 51 reads the information of the menu screen stored in advance in the storage unit 52, and retrieves the current balance and final payout from the deposit/withdrawal history stored in the user information DB 52b in association with the user ID of the selected user. Read execution date and time. Then, the control unit 51 generates the menu screen shown in FIG. 16C by adding the administrator ID of the administrator, the user's name and user ID, the user's current balance, and the final payout date and time to the read screen information. do. The menu screen is not limited to the configuration shown in FIG. 16C.

On the menu screen shown in FIG. 16C , the administrator operates the schedule setting button to instruct the user to execute the payment schedule setting process, and operates the deposit/withdrawal history confirmation button to display the payment history for the user. is displayed and the user operates the deposit button to instruct the user to accept the deposit. Further, the administrator operates the user information change button to instruct the setting change of the registered information about the user, and operates the administrator information change button to instruct the setting change of the registered information about the administrator himself/herself. The control unit 51 determines whether or not the schedule setting button has been operated on the menu screen (S77), and if it determines that it has been operated (S77: YES), the withdrawal schedule setting screen as shown in FIG. 17 is displayed. It is displayed on the touch panel 53 (S78).

The payment schedule setting screen shown in FIG. 17 has the same configuration as the payment schedule setting screen shown in FIG. The control unit 51 reads the information of the payment schedule setting screen stored in advance in the storage unit 52, and the read screen information includes the administrator ID, the user's name and user ID, the user's current balance, and the final payment execution. By adding the date and time, the payment schedule setting screen shown in FIG. 17 is generated. The payment schedule setting screen is not limited to the configuration shown in FIG.

When the setting contents (withdrawal conditions) related to the payment schedule are received via the payment schedule setting screen, the control unit 51 displays the received setting contents in each input column (S79). Then, the control unit 51 determines whether or not the setting button of the withdrawal schedule setting screen has been operated (S80), and if it determines that it has not been operated (S80: NO), repeats the process of step S79. If it is determined that the setting button on the withdrawal schedule setting screen has been operated (S80: YES), the control unit 51 stores the withdrawal schedule based on the settings input via the withdrawal schedule setting screen (S81). . Specifically, the control unit 51 stores the input setting contents in the user information DB 52b as a payment schedule corresponding to the user ID of the user to be set. After storing the withdrawal schedule, the control unit 51 includes the current date and time and the user ID of the user as work history corresponding to the administrator ID of the administrator here, and the withdrawal schedule is set. History information indicating this is stored in the administrator information DB 52a. Further, after the processing of step S81, the control unit 51 may return to the display of the menu screen shown in FIG. 16C. Furthermore, the control unit 51 may associate the withdrawal schedule stored in the user information DB 52b with the user ID, transmit the schedule to the financial institution server 10, and register the schedule in the financial institution server 10 (schedule DB 12b). In this case, the payment schedule (payment schedule) input via the cash dispensing device 50 can be registered in the financial institution server 10, and the payment schedule registered in the cash dispensing device 50 and the payment schedule registered in the financial institution server 10 can be registered. can be matched with the payout schedule.

When it is determined in step S77 that the schedule setting button has not been operated (S77: NO), the control section 51 determines whether or not the deposit/withdrawal history confirmation button on the menu screen has been operated (S82). When determining that the deposit/withdrawal history confirmation button has been operated (S82: YES), the control unit 51 generates a deposit/withdrawal history screen as shown in FIG. 18A and displays it on the touch panel 53 (S83). The deposit/withdrawal history screen shown in FIG. 18A includes the date and amount (withdrawal history) when the user to be processed withdrew cash from the cash dispenser 50 and the date and amount when the cash was deposited to the cash dispenser 50 corresponding to the user. (deposit history) and the balance at each date and time are displayed. The control unit 51 reads the deposit/withdrawal history stored in the user information DB 52b in association with the user ID of the user to be processed, generates a deposit/withdrawal history list, and adds the administrator ID, the user's A deposit/withdrawal history screen shown in FIG. 18A is generated by adding the user's name, user ID, user's current balance, and last payment execution date and time. The deposit/withdrawal history screen is not limited to the configuration shown in FIG. 18A. For example, the deposit/withdrawal history screen may be configured to display not only the deposit/withdrawal history by the cash dispensing device 50 but also the dispensing history of cash dispensed via the ATM 20 . After displaying the deposit/withdrawal history screen, the control unit 51 displays the deposit/withdrawal history screen including the current date and time and the user ID of the user as the work history corresponding to the administrator ID of the administrator here. The history information indicating that it has been broken is stored in the administrator information DB 52a.

The deposit/withdrawal history screen shown in FIG. 18A has a close button for instructing termination of display of the screen. When the close button of the deposit/withdrawal history screen is operated, the control unit 51 The display is ended, and the display returns to the menu screen shown in FIG. 16C, for example. The control unit 51 may be configured to transmit the deposit/withdrawal history screen to a printer via the communication unit 54, for example, or may be configured to transmit to another device via the communication unit 54. good. With such a configuration, the deposit/withdrawal history screen can be displayed not only on the display unit 53a of the cash dispenser 50, but also printed on paper by a printer or transmitted to another device. In this case, the deposit/withdrawal history screen may have a print button for instructing printing of the screen and a send button for instructing transmission of the screen.

When determining that the deposit/withdrawal history confirmation button on the menu screen has not been operated (S82: NO), the control unit 51 determines whether or not the deposit button on the menu screen has been operated (S84). When determining that the deposit button has been operated (S84: YES), the control unit 51 displays an amount receipt screen as shown in FIG. 18B on the touch panel 53 (S85). The amount reception screen shown in FIG. 18B has an input field for inputting the amount to be deposited into the cash dispenser 50 in association with the user to be processed, and an OK button for registering the amount input in the input field. have. The administrator inputs the amount of cash received from the user or the user's family in the input field, and operates the OK button when instructing the registration of the input amount. The control unit 51 accepts the payment amount via the amount acceptance screen (S86), and when the OK button is operated, the date and time of this point and the accepted amount are displayed as the payment history corresponding to the user ID of the user to be processed. The included payment history information is stored in the user information DB 52b (S87). After storing the deposit history, the control unit 51 stores history information indicating that the deposit has been made, including the date and time at this time and the user ID of the user, as the work history corresponding to the administrator ID of the administrator here. is stored in the administrator information DB 52a. In addition, when the administrator has registered the amount of payment for each user, or when the amount of payment has been registered for a plurality of users, the administrator may store the cash in the cash dispensing device 50 collectively. Cash may be thrown into the cash storage section from the collective insertion slot 50a. When cash is inserted from the collective insertion slot 50a, the control unit 51 determines the amount of the inserted cash by the denomination determination unit 57a, and the determined amount is the amount registered by the administrator through the deposit processing. It is determined whether or not they match, and if they match, the deposit process is completed. On the other hand, if the amount determined by the denomination determination unit 57a does not match the amount of money deposited, the control unit 51 may display an error message on the touch panel 53 to prompt the administrator for confirmation. In addition, the control unit 51 displays the amount determined by the denomination determination unit 57a on the touch panel 53 as the input amount to prompt the administrator to confirm the input amount. The input process may be completed after confirming that the input amount matches the input amount.

If it is determined that the deposit button on the menu screen has not been operated (S84: NO), the control section 51 skips steps S85 to S87 and ends the process. Note that when the user information change button is operated in the management menu in the menu screen, the control unit 51 displays a user information change screen (not shown), and configures the user to be operated via the user information change screen. Accepts information change instructions. Further, when the administrator information change button is operated, the control unit 51 displays an administrator information change screen (not shown), and changes the setting information regarding the operating administrator via the administrator information change screen. accept instructions. Even when the user information and the administrator information are changed as described above, the control unit 51 includes the date and time at this time as the work history corresponding to the administrator ID of the administrator, and the details of the processing performed. is stored in the administrator information DB 52a.

With the above-described processing, the administrator can set and change the withdrawal schedule of the user in charge by operating the touch panel 53 of the cash dispensing device 50, can check the deposit/withdrawal history of each user, and can The user's cash can be deposited and registered. Note that the administrator can operate the cash dispenser 50 after being authenticated as an administrator with appropriate authority through authentication processing based on his or her own authentication data. can ensure the integrity of

The ATM 20 and the financial institution server 10 of this embodiment execute the same processing as the processing shown in FIG. Thereby, also in the information processing system 100 of this embodiment, cash can be paid out via the ATM 20 when the user is authenticated based on his or her biometric data. In the information processing system 100 of this embodiment, it is possible to receive payment of cash also via the cash dispensing device 50 . Processing performed by the cash dispensing device 50 when the user receives cash dispensed from the cash dispensing device 50 will be described below. FIG. 19 is a flow chart showing an example of a payout processing procedure according to the second embodiment. The following processing is implemented by the control unit 51 according to the control program 52P stored in the storage unit 52 of the cash dispenser 50, and is executed by the control unit 11 according to the control program 11P stored in the storage unit 12 of the financial institution server 10. Realized. A part of the following processing may be realized by a dedicated hardware circuit.

In the cash dispenser 50 in the standby state, the control unit 51 determines whether biometric data (in this case, vein data) has been acquired by the biometric authentication sensor 55 (S91). (S91: NO), waits until acquisition. Note that, in the standby state, the control unit 51 may display the login screen shown in FIG. 16A on the touch panel 53 and display or output by voice a message prompting reading of the vein data. If a light is provided near the biometric sensor 55, the control unit 51 may notify the location of the biometric sensor 55 and encourage reading of the vein data by lighting or blinking the light.

When it is determined that the biometric authentication sensor 55 has acquired the vein data (S91: YES), the control unit 51 (authentication unit) authenticates the user based on the acquired vein data (S92). Here, the control unit 51 determines whether or not the acquired vein data matches any of the biometric authentication data stored in the user information DB 52b. is identified, and it is determined that the identified user has been successfully authenticated. The control unit 51 determines whether or not the user authentication based on the vein data has succeeded (S93), and if it has failed (S93: NO), returns to the process of step S91. At this time, the control unit 51 may display or output a message indicating that the user authentication has failed. If it is determined that the user authentication based on the vein data has succeeded (S93: YES), the control unit 51 determines whether the authenticated user can pay out cash at this point. to the financial institution server 10 (S94).

When the control unit 11 of the financial institution server 10 receives an inquiry as to whether payment is possible or not, it is possible to pay out cash at this time based on the payment schedule (payment schedule) of the user authenticated by the cash dispensing device 50. (S95). Here, the control unit 11 reads the authenticated user's payout schedule (payout schedule) and payout history from the schedule DB 12b, and determines whether or not the payout at this time matches the timing according to the readout payout schedule. is determined, and if they match, it is determined that the payout is possible. The control unit 11 transmits the determined result to the cash dispenser 50 (S96).

The control unit 51 of the cash dispenser 50 determines whether or not the cash can be dispensed at this time based on the determination result of the financial institution server 10 (S97). The control unit 51 also reads out the user's current balance in the cash dispenser 50 from the deposit/withdrawal history stored in the user information DB 52b, and determines whether or not the read balance is less than the amount to be withdrawn. , it may be determined that the withdrawal is not possible when the balance is less than the amount to be withdrawn. If it is determined that the payout at this time is possible (S97: YES), the control unit 51 (payout unit) pays out the amount of cash set in the payout schedule by the cash payout unit 56 (S98 ). If there is undispensed money (cash that has not been dispensed) by the previous withdrawal timing, the control unit 51 can withdraw money based on the amount of money not yet disbursed and the set carryover upper limit amount. amount is calculated, and cash of the calculated amount is paid out by a cash dispensing unit 56.例文帳に追加Then, the control unit 51 saves the payment history information including the date and time and the amount of payment as the payment history corresponding to the user ID of the user who paid out the cash, that is, the user authenticated in step S92, to the user information DB 52b. (S99). The control unit 51 associates the withdrawal history information stored in the user information DB 52b with the user ID and transmits it to the financial institution server 10 (S100). When receiving payment history information (payment history information) from the cash dispensing device 50, the control unit 11 of the financial institution server 10 stores the received payment history information in the schedule DB 12b as a payment history corresponding to the received user ID. Store (S101). As a result, the cash dispensing history of cash dispensed via the cash dispenser 50 is stored in the financial institution server 10 (schedule DB 12b). Therefore, the financial institution server 10 can store history information of not only the cash dispensing process performed by the ATM 20 but also the cash dispensing process performed by the cash dispenser 50 in the schedule DB 12b. Note that either the control unit 11 of the financial institution server 10 or the control unit 51 of the cash dispensing device 50, for example, after the process of step S101 or S100, the administrator corresponding to the user who paid cash using the cash dispensing device 50 Notification information for notifying that the user has received cash payment (payment history) may be transmitted to the administrator terminal 40 of .

If it is determined that the payout is not possible at this time (S97: NO), the control unit 51 displays a message indicating that the payout is not possible at this time on the touch panel 53 or outputs the voice from the speaker 58, thereby notifying the user that the payout is not possible. (S102). It should be noted that the control unit 51 may specify the next available date and time for withdrawal from the user's payment schedule and notify the specified date and time when notifying that the payment is not possible. Further, the control unit 51 of the cash dispensing device 50, for example, after the process of step S102, the user tried to pay out cash to the administrator terminal 40 of the administrator corresponding to the user who failed to pay out cash. and that the payout has failed. In addition, when the balance corresponding to the user is insufficient and payment is not possible, the administrator can grasp the shortage of cash from the notification information from the cash dispensing device 50 .

The control unit 51 of the cash dispenser 50 performs the above-described processing each time the biometric sensor 55 acquires vein data. Accordingly, cash is dispensed to the user when the user is authenticated as a proper user by authentication processing based on the user's vein data. Therefore, the safety of the cash stored in the cash dispenser 50 can be ensured, and the user can obtain the cash at the desired timing. Further, in this embodiment, cash can be received via the ATM 20 or the cash dispensing device 50, so that the user can receive cash from the device that the user wants to use, which is convenient. In addition, in the information processing system 100 of the present embodiment, since the financial institution server 10 manages the cash dispensing history of the ATM 20 and the cash dispensing history (withdrawal history) of the cash dispensing device 50, each device It is possible to prevent duplicate payout processing via . Therefore, since the amount of cash exceeding the amount according to the payout schedule set for each user is not paid out, waste by the user does not occur.

In this embodiment, the same effects as those of the first embodiment described above can be obtained. Further, in this embodiment, the cash dispensing process by the ATM 20 and the cash dispensing process by the cash dispensing device 50 can be linked, and the user can receive cash from either device. Also in the present embodiment, it is possible to apply the modified examples appropriately described in the first embodiment.

In the information processing system 100 of the present embodiment, the payment schedule and deposit/withdrawal history of each user may be managed only by the financial institution server 10 (schedule DB 12b). In this case, the cash dispensing device 50 causes the financial institution server 10 to execute a process of determining whether or not cash can be dispensed according to the dispensing schedule (dispensing schedule) and dispensing history. Further, the administrator's authentication data or the user's biometric authentication data (biometric data) may be managed only by the financial institution server 10 (schedule DB 12b). In this case, the cash dispenser 50 transmits the acquired administrator authentication data to the financial institution server 10 and causes the financial institution server 10 to perform administrator authentication based on the authentication data. The cash dispenser 50 also transmits the acquired biometric data of the user to the financial institution server 10 and causes the financial institution server 10 to perform user authentication based on the biometric data.

In the information processing system 100 of the present embodiment, the process of depositing money into the cash dispensing device 50 in association with the user may be performed not only by the administrator but also by the user himself, or may be performed by the user's family.

(Embodiment 3)
Information for depositing cash into an account for cashless settlement associated with the user at a timing according to a payout schedule (payment schedule) instead of withdrawing cash to the user via the ATM 20 or the cash dispensing device 50. A processing system will be described. FIG. 20 is a schematic diagram showing a configuration example of an information processing system according to the third embodiment. The information processing system 101 of this embodiment includes a cashless payment server 60, a POS (Point Of Sales) terminal 70, and a user terminal 80 in addition to the financial institution server 10 and the administrator terminal 40. A server 60, a POS terminal 70 and a user terminal 80 can be connected to the network N. FIG. The financial institution server 10 and the administrator terminal 40 of the present embodiment are the same devices as the financial institution server 10 and the administrator terminal 40 of the first embodiment, so detailed description thereof will be omitted. In the financial institution server 10 of the present embodiment, the customer account DB 12a stored in the storage unit 12 stores the account number of the payment account for cashless payment in association with each account.

The cashless payment server 60 is a server of a company that provides cashless payment services, and performs various types of information processing such as processing for managing payment accounts opened in association with each user who wishes to use the cashless payment services. I do. The cashless payment server 60 is configured using, for example, a server computer or a personal computer. A plurality of cashless payment servers 60 may be provided for distributed processing, may be realized by a plurality of virtual machines provided in one server, or may be realized using a cloud server. .

The POS terminal 70 is a payment processing terminal that performs various processes related to cashless payment in the store, and a plurality of POS terminals may be provided in one store. The POS terminal 70 performs payment processing (payment processing) corresponding to application payment using a mobile terminal (user terminal 80). Application payment is called smartphone payment or QR code (registered trademark) payment, and is a payment method that uses a payment processing application (hereinafter referred to as a payment application) installed in a user terminal 80 such as a smartphone. The user terminal 80 is a mobile terminal of a user shopping at a store, such as a smart phone or a tablet terminal. The user terminal 80 has a payment application installed therein, and performs processing related to application payment by executing the payment application.

FIG. 21 is a block diagram showing an internal configuration example of the cashless payment server 60 and the POS terminal 70. As shown in FIG. The cashless payment server 60 includes a control section 61, a storage section 62, a communication section 63, an input section 64, a display section 65, a reading section 66, etc. These sections are interconnected via a bus. The control unit 61, the storage unit 62, the communication unit 63, the input unit 64, the display unit 65, and the reading unit 66 of the cashless payment server 60 are respectively the control unit 11, the storage unit 12, and the communication unit of the financial institution server 10. 13, the input unit 14, the display unit 15, and the reading unit 16, the detailed description thereof will be omitted. In addition to the control program 62P executed by the control unit 61, the storage unit 62 of the cashless payment server 60 stores a payment account DB 62a, which will be described later. The payment account DB 62a may be stored in another storage device connected to the cashless payment server 60, or may be stored in another storage device with which the cashless payment server 60 can communicate.

The POS terminal 70 includes a control section 71, a storage section 72, a communication section 73, an input section 74, a display section 75, a code reader 76, etc. These sections are interconnected via a bus. The control unit 71, the storage unit 72, the communication unit 73, the input unit 74, and the display unit 75 of the POS terminal 70 correspond to the control unit 61, the storage unit 62, the communication unit 63, and the input unit 64 of the cashless payment server 60, respectively. , and the display unit 65, detailed description thereof will be omitted. The code reader 76 is a device that reads a two-dimensional code such as a QR code, obtains code information by decoding the read code, and sends the obtained code information to the control unit 71 . The code reader 76 may be configured to read one-dimensional codes such as bar codes in addition to two-dimensional codes.

FIG. 22 is a schematic diagram showing a configuration example of the payment account DB 62a. The payment account DB 62a stores information on payment accounts of users who use cashless payment. The payment account DB 62a shown in FIG. 22 includes an account number column, a customer information column, a code information column, a user ID column, a financial institution account information column, a deposit/withdrawal history column, etc. Each piece of information is stored. The account number column stores identification information (account number) assigned to each account (payment account) opened for cashless payment. The customer information column stores information about the customer of the payment account holder, and stores personal information such as the user's name, address, telephone number, date of birth, and the like. The code information column stores code information used for cashless payment. The code information is code information used to generate a payment code (for example, a QR code) displayed on the user terminal 80 when making a cashless payment. The user ID column stores identification information (user ID) assigned to a user who makes a cashless payment using a payment account. The financial institution account information stores identification information (account number) assigned to an account opened at a financial institution for depositing money into a payment account. The deposit/withdrawal history column stores history information related to deposit/withdrawal processing performed on the payment account. The account number, customer information, code information, user ID and financial institution account information stored in the payment account DB 62a are the account number assigned to the customer and the account number specified by the customer when a new payment account is opened. The control unit 61 stores the customer information received, the code information and user ID assigned to the user, and the account number of the financial institution designated by the customer. As for the deposit/withdrawal history stored in the payment account DB 62a, the control unit 61 stores information about the deposit/withdrawal process when the deposit/withdrawal process is performed for each payment account. The storage contents of the payment account DB 62a are not limited to the example shown in FIG.

FIG. 23 is a block diagram showing an internal configuration example of the user terminal 80. As shown in FIG. The user terminal 80 includes a control section 81, a storage section 82, a communication section 83, an input section 84, a display section 85, a biometric authentication sensor 86, etc. These sections are interconnected via a bus. The control unit 81, the storage unit 82, the communication unit 83, the input unit 84, and the display unit 85 of the user terminal 80 correspond to the control unit 61, the storage unit 62, the communication unit 63, and the input unit 64 of the cashless payment server 60, respectively. , and the display unit 65, detailed description thereof will be omitted. Note that the storage unit 82 of the user terminal 80 stores a payment application 82AP in addition to the control program 82P executed by the control unit 81 . The payment application 82AP is, for example, downloaded by the control unit 81 from another device via the communication unit 83 and stored in the storage unit 82 .

The biometric sensor 86 is, for example, a vein sensor that reads the veins of a palm, reads the veins of a palm held within a predetermined detection range, acquires vein data, and sends the acquired vein data to the control unit 81 . The user terminal 80 of this embodiment has a configuration for performing biometric authentication using palm veins, but is not limited to palm vein authentication. or a configuration in which authentication is performed by combining a plurality of pieces of biometric information.

In the information processing system 101 of this embodiment, the administrator terminal 40 and the financial institution server 10 execute the same processes as those shown in FIGS. As a result, the administrator who has been authenticated based on the administrator authentication data can set and change the user's payout schedule managed by him/herself to the financial institution server 10 (schedule DB 12b), and can record the user's payout history. (History of payment to account for payment) can be confirmed. In the information processing system 101 of the present embodiment, the payout schedule setting screen displayed on the display unit 45 of the administrator terminal 40 in step S32 is slightly different from the configuration shown in FIG.

FIG. 24 is a schematic diagram showing a configuration example of a setting screen according to the third embodiment. The setting screen shown in FIG. 24 is a screen for setting a schedule (conditions) for depositing money into a payment account for cashless payment associated with a user. The setting screen shown in FIG. 24 differs from the setting screen of the first embodiment shown in FIG. 8 in the number of times setting input field and carryover setting input field. In the setting screen shown in FIG. 24, the input field for setting the number of times includes a check box for selecting either once or multiple times per day, and the time of deposit from the account of the financial institution to the payment account (payment time). ), and a pull-down menu from which an arbitrary time can be selected is provided in the entry field for the payment time. The input fields for carryover settings include a check box for selecting whether to set the upper limit of the balance of the payment account, and whether to set the upper limit of the balance of the payment account to the amount of one withdrawal, or an arbitrary amount. and an input field for inputting the maximum balance amount. The check box for selecting whether to set the upper limit of the balance of the payment account to the amount of one withdrawal or to an arbitrary amount, "Set the upper limit of the balance of the payment account" is selected , and the input field for the maximum balance amount can be input when "Set an arbitrary amount for the maximum balance amount" is selected. In this embodiment, money is deposited from the account of the financial institution to the payment account at the timing and amount according to the payment schedule, so if the user does not use cashless payment, the balance of the payment account will increase. Become. Therefore, by setting the upper limit of the balance of the payment account to the amount of one payment or an arbitrary amount, it is possible to prevent the balance of the payment account from exceeding the set upper limit.

In this embodiment as well, the administrator enters settings into each entry field on the setting screen shown in FIG. Register in DB 12b). In addition, since the financial institution server 10 manages the history of deposits (withdrawal processing) to the payment account according to the payment schedule set by the user, the administrator can use the administrator terminal 40 to A user's payout history (deposit history to a payment account) can be acquired from the institution server 10 and viewed.

Next, the processing performed by each device when the financial institution server 10 deposits money from each user's financial institution account to a payment account for cashless settlement according to each user's payout schedule will be described. FIG. 25 is a flow chart showing an example of a deposit processing procedure, and FIG. 26 is a schematic diagram showing an example of a screen. The following processing is realized by the control unit 11 according to the control program 12P stored in the storage unit 12 of the financial institution server 10, and the control unit 11 according to the control program 62P stored in the storage unit 62 of the cashless payment server 60. 61. A part of the processing may be realized by a dedicated hardware circuit.

Based on the payout schedule stored in the schedule DB 12b, the control unit 11 of the financial institution server 10 determines whether there is a user at the payout timing to deposit money from the financial institution account to the payment account (S111). For example, the control unit 11 determines whether or not the payout timing (payout time) indicated by the payout schedule of each user has arrived. to decide. When determining that there is no user at the payout timing (S111: NO), the control section 11 waits while performing other processes. If it is determined that there is a user at the payout timing (S111: YES), the control unit 11 inquires of the cashless payment server 60 about the balance of this user's payment account (S112). When receiving an inquiry about the balance of the payment account from the financial institution server 10, the control unit 61 of the cashless payment server 60 reads the balance of the corresponding user's payment account from the payment account DB 62a (S113). The balance obtained is transmitted to the financial institution server 10 (S114).

When the control unit 11 of the financial institution server 10 receives the balance of the payment account of the user at the timing of payment from the cashless payment server 60, it determines whether or not payment to this user is possible (S115). . For example, the control unit 11 (determining unit) reads out the maximum balance amount set for this user (specifically, the amount of one payment or an arbitrary amount) from the schedule DB 12b, and from the cashless payment server 60 It determines whether or not the received balance is less than the maximum balance amount. The control unit 11 determines whether or not withdrawal is possible depending on whether or not the balance of the user's account for payment is less than the upper limit of the balance. Further, when the upper limit of the balance is not set for this user, the control section 11 may determine that the payout is possible. When determining that there is a user at the payout timing (S111: YES), the control unit 11 determines whether or not an upper limit balance is set for this user. The processing of steps S112 to S116 may be skipped. If it is determined that it is possible to pay out to the user (S115: YES), the control section 11 calculates the amount of money to be deposited to this user (S116). Specifically, the control unit 11 (specific unit) sets the amount set in the payout schedule as the upper limit based on the amount set in the payout schedule, the balance of the payment account, and the upper limit of the balance. , calculates (specifies) the amount (deposit amount) that brings the balance of the payment account closer to the upper limit of the balance. In addition, when the balance upper limit amount is not set for the user, the control unit 11 sets the amount set in the payout schedule as the amount to be deposited for this user. Then, the control unit 11 (deposit unit) performs a transfer process for depositing the calculated amount of money from the account of the financial institution to the payment account for this user (S117). Specifically, the control unit 11 performs withdrawal processing to the account of the financial institution, and the control unit 61 of the cashless settlement server 60 performs deposit processing to the payment account (S118). In addition, when the control unit 11 performs the transfer process of depositing money from the account of the financial institution to the account for payment, if there is no amount of money to be deposited in the account of the financial institution, it is assumed that the money cannot be deposited (withdrawn) due to insufficient amount. The processing of steps S117 to S120 may be skipped.

After the transfer process, the control unit 11 of the financial institution server 10 stores, in the schedule DB 12b, payout history information including the date and time and the amount at this time as the payout history corresponding to the user ID of the user who made the payment to the payment account (S119). ). Note that the control unit 61 of the cashless payment server 60 stores the payment history information including the date and time and the amount at this point in the payment account DB 62a as the payment history corresponding to the user ID of the user who made the payment to the payment account. . Further, the control unit 11 generates a screen (notification information) displaying a message notifying that the payment has been made from the account of the financial institution to the payment account as shown in FIG. The user terminal 80 is notified that the payment has been made to the payment account (S120). The screen shown in FIG. 26 displays the fact that payment has been made to the payment account, the payment amount, the balance of the payment account, the date and time of the last cashless payment, and the like. By displaying the screen received from the financial institution server 10 on the display unit 85, the user terminal 80 can notify the user that the payment has been made to the payment account for cashless payment. Note that the control unit 11 may transmit, for example, after the process of step S120, notification information for notifying that the payment has been made to the payment account of the user, to the administrator terminal 40 of the administrator corresponding to the user. . As a result, the administrator can also be notified that the payment has been made to the user's payment account.

On the other hand, when determining that the payout to the user is not possible (S115: NO), the control section 11 skips the processing of steps S116 to S120. In other words, if payment to the user is not possible, the user's payment account is not processed for payment. Specifically, if the balance of the payment account for cashless payment is equal to or greater than the set balance upper limit (the amount of one withdrawal or any amount), the payment process to the user's payment account will be performed. can't break By the above-described processing, the payment is made to the payment account for cashless payment according to the payout schedule set for each user, so the user can purchase the product by cashless payment. It should be noted that, since no amount exceeding the amount set in the payout schedule is deposited for each user, wasteful spending by the user does not occur. In addition, since it is possible to set an upper limit for the balance of the payment account of the user, even if the user does not use cashless payment, the balance of the payment account does not exceed the upper limit. When the control unit 11 of the financial institution server 10 determines that the user cannot be paid out (S115: NO), the administrator terminal 40 of the administrator corresponding to this user is instructed to pay to the account for payment. Notification information may be sent to notify that the deposit has failed and the reason (the balance has reached the upper limit of the balance or the balance of the account of the financial institution is insufficient). If the balance of the account of the financial institution corresponding to the user is insufficient and payment is not possible, the manager can grasp the insufficient balance of the account from the notification information from the financial institution server 10 .

Next, processing performed by each device when a user makes a cashless payment will be described. FIG. 27 is a flowchart showing an example of a payment processing procedure, and FIG. 28 is a schematic diagram showing an example of a screen. The following processing is implemented by the control unit 81 according to the control program 82P stored in the storage unit 82 of the user terminal 80, and is implemented by the control unit 71 according to the control program 72P stored in the storage unit 72 of the POS terminal 70. , is realized by the control unit 61 according to the control program 62P stored in the storage unit 62 of the cashless payment server 60. A part of the processing may be realized by a dedicated hardware circuit.

When the user purchases a product by cashless payment, the user activates the payment application 82AP on the user terminal 80 . The control unit 81 of the user terminal 80 activates the payment application 82AP according to the user's instruction via the input unit 84 (S121), and displays a biometric authentication screen requesting biometric authentication on the display unit 85 as shown in FIG. 28A. (S122). The biometric authentication screen shown in FIG. 28A displays a message prompting biometric authentication, and also displays a message notifying the user that the palm is used for biometric authentication and the installation position of the biometric sensor 86 held over the palm. may

The control unit 81 determines whether or not the user's biometric data (for example, vein data) has been acquired by the biometric sensor 86 (S123), and if it is determined that it has not been acquired (S123: NO), it waits until it is acquired. do. When determining that the biometric data of the user has been acquired (S123: YES), the control unit 81 performs user authentication based on the acquired biometric data (S124). The biometric authentication data used for user authentication is registered in the payment application 82AP in advance. Therefore, the control unit 81 acquires biometric authentication data from the payment application 82AP, determines whether or not the acquired biometric authentication data matches the biometric data acquired by the biometric authentication sensor 26, and if they match, is judged to be authentication success, and if they do not match, it is judged to be authentication failure.

The control unit 81 determines whether or not the user authentication has succeeded (S125), and if it determines that it has failed (S125: NO), displays a message indicating that the authentication has failed, as shown in FIG. 28B. An error screen is generated and displayed on the display unit 85 (S127). As a result, the user can be notified that authentication has failed and cashless payment cannot be used. When determining that the user authentication has succeeded (S125: YES), the control unit 81 generates a payment code used for cashless payment, and displays a screen displaying the payment code on the display unit 85 as shown in FIG. 28C. Display (S126). Code information used when generating a payment code is registered in the payment application 82AP, and the control unit 81 reads the code information from the payment application 82AP and generates a payment code from the code information. The user presents the user terminal 80 on which the settlement code is displayed as shown in FIG. 28C to the store staff, and the store staff reads the presented settlement code with the POS terminal 70 and performs cashless settlement processing. .

The control unit 71 of the POS terminal 70 reads the payment code through the code reader 76 to acquire the code information (S128), and requests the cashless payment server 60 for payment processing based on the acquired code information (S129). ). The control unit 71 transmits payment information including code information and the amount to be paid in cashless payment to the cashless payment server 60 to request payment processing. When receiving a payment processing request from the POS terminal 70, the control unit 61 of the cashless payment server 60 determines whether the payment processing is possible based on the received code information (S130). For example, the control unit 61 acquires the balance of the payment account corresponding to the received code information from the payment account DB 62a, and depending on whether the acquired balance is greater than the scheduled payment amount, settlement processing is possible. Determine whether or not

If it is determined that the settlement process is possible (S130: YES), the control unit 61 performs the settlement process (S131) and notifies the POS terminal 70 of the completion of the settlement process (S132). The settlement process includes, for example, a process of withdrawing the payment amount from the payment account corresponding to the code information, a process of depositing the withdrawn amount into the account of the store, and the like. When the control unit 71 of the POS terminal 70 is notified of the completion of the payment processing from the cashless payment server 60, the display unit 75 displays a message indicating that the payment processing has been completed (S133), and notifies the store staff. do. On the other hand, if it is determined that the settlement process is not possible (S130: NO), the control unit 61 notifies the POS terminal 70 that the settlement process has failed (S134). is displayed on the display unit 75 (S135) to notify the store staff.

By the above-described processing, when the user is authenticated as a proper user by user authentication based on the user's biometric data, the user can use cashless payment, so the user can purchase the product at the desired timing. . In addition, since the payment account used for cashless payment is charged according to the payout schedule set by the user, it is not possible to spend more than the amount set in the payout schedule, and the user does not waste money. Furthermore, in the information processing system 101 of the present embodiment, cashless payment is used, so that the administrator and the user do not have to handle cash, and the burden required for money management can be reduced.

In this embodiment, the same effects as those of the above-described embodiments can be obtained. In addition, in this embodiment, the payment to the payment account used for cashless payment can be made according to the payment schedule, so the user does not need to receive cash, and can carry the user terminal 80 to purchase the product. Because it is good, operability is good. Especially for users who are accustomed to cashless payments, user-friendly payment processing is possible while suppressing wasteful spending. Also in this embodiment, it is possible to apply the modified examples appropriately described in each of the above-described embodiments.

In this embodiment, after the user purchases the product by cashless payment, the cashless payment server 60 notifies the user's manager's manager terminal 40 that the user has purchased the product. good too. Specifically, for example, after the process of step S132 in FIG. 27, the control unit 61 of the cashless payment server 60 sends the notification information for notifying the completion of the cashless payment to the manager who manages the money of the user. to the user terminal 40. The destination information of the administrator terminal 40 is registered in the payment account DB 62a, for example. In addition, when the user fails in cashless payment, the cashless payment server 60 may notify the manager's terminal 40 of the failure of the cashless payment. Specifically, for example, after the process of step S134 in FIG. 27, the control unit 61 of the cashless payment server 60 transmits notification information for notifying that the cashless payment has failed to the administrator terminal 40 . Thereby, the administrator can grasp the user's usage status of cashless payment and the balance of the payment account for cashless payment.

In the present embodiment, the financial institution server 10 is configured to transmit notification information to the administrator terminal 40 when a payment is made to the user's payment account, or when payment to the payment account fails. . In addition, when the balance of the financial institution account for depositing money into the user's payment account (the balance of money to be deposited into the payment account) becomes insufficient or less than a predetermined amount, the financial institution server 10 manages person may be notified. In this case, the administrator can grasp the insufficient balance of the financial institution account, or can grasp the occurrence of the insufficient balance in advance. Also in the present embodiment, the administrator may be able to select the content of the notification from the financial institution server 10 to the administrator terminal 40 . For example, as the content of the notification, one of the followings can be selected: that payment has been made to the user's payment account, that payment has not been made, or that the balance of the financial institution account is insufficient (insufficient balance status). and registered in the financial institution server 10. Then, the financial institution server 10 transmits notification information corresponding to each user to the administrator terminal 40 at an appropriate notification timing, according to the registered contents of each user. According to such a configuration, transmission of unnecessary notification information to the administrator's terminal 40 is suppressed, and the administrator can receive notification of necessary information.

In this embodiment, it may be configured such that the time period during which cashless payment can be used can be restricted to an arbitrary time period. Specifically, for each user, a time slot in which cashless payment can be used or a time slot in which cashless payment can not be used is set and registered in the payment account DB 62a. When the cashless payment server 60 receives a request for payment processing from the POS terminal 70, the cashless payment is possible depending on whether the time at that time is within the time zone in which cashless payment can be used. Determine whether or not When the time period during which cashless payment can be used is limited in this way, wasteful spending by the user can be further suppressed. For example, when a user uses cashless payment for online game billing or online shopping, the time period during which online game billing or online shopping can be performed is limited, so wasteful spending by the user can be effectively suppressed. Further, for example, by registering the midnight time period as the time period in which cashless payment cannot be used, it is possible to prevent the user from going out or wandering around in the middle of the night.

The embodiments disclosed this time are illustrative in all respects and should be considered not restrictive. The scope of the present invention is indicated by the scope of the claims rather than the meaning described above, and is intended to include all modifications within the scope and meaning equivalent to the scope of the claims.

10 financial institution server 11 control unit 12 storage unit 13 communication unit 20 ATM
21 control unit 22 storage unit 23 touch panel 24 communication unit 25 card reading unit 26 biometric sensor 27 cash dispensing unit 30 card 40 administrator terminal 50 cash dispensing device 51 control unit 52 storage unit 53 touch panel 54 communication unit 60 for cashless payment Server 70 POS terminal 80 User terminal

Claims (8)

An information processing method for depositing money into a payment account used for cashless payment using a mobile terminal,
registering in a server a money payout schedule set by an administrator associated with the user in association with the user who uses the mobile terminal;
determining whether or not the balance of the payment account corresponding to the user is less than the amount deposited according to the payment schedule at the timing according to the payment schedule corresponding to the user;
If it is determined that the amount is small, the balance of the payment account specifies the amount of the deposit amount according to the payment schedule,
Deposit the specified amount into the payment account corresponding to the user,
An information processing method including a process of not depositing money into the payment account corresponding to the user when it is determined that the balance of the payment account is equal to or greater than the deposit amount according to the payout schedule. Deposit the specified amount from the financial institution account associated with the user to the payment account corresponding to the user,
2. The information processing method according to claim 1, further comprising a process of outputting notification information notifying that said payment account has been deposited to said user's terminal. accepting and registering in the server an upper limit amount for the balance of the payment account corresponding to the user;
Identifying the amount to be deposited into the payment account based on the balance of the payment account corresponding to the user and the upper limit amount at the timing according to the payment schedule corresponding to the user;
The information processing method according to claim 1 or 2, further comprising depositing the specified amount of money into the payment account. outputting notification information notifying completion of cashless payment by said user using said mobile terminal or notification information notifying failure of said cashless payment to a terminal of an administrator associated with said user; The information processing method according to claim 1 or 2, comprising: Registering a plurality of administrators who manage the user in association with the user;
authenticate the administrator,
3. The method according to claim 1 or 2, comprising a process of outputting display information for displaying a payout history indicating amounts deposited into payment accounts corresponding to one or more users associated with the authenticated administrator. information processing method. Registering a plurality of administrators who manage the user in association with the user;
authenticate the administrator,
3. The information processing method according to claim 1 or 2, further comprising a process of accepting payout schedules for one or more users associated with an authenticated manager and registering them in said server. Registering in the server as notification content either the history of payment to the payment account or the shortage of money for payment to the payment account in association with the user,
3. The information processing method according to claim 1, further comprising a process of outputting, for each user, information according to notification contents registered in association with each user to a user terminal of the user. An information processing system for depositing money into a payment account used for cashless payment using a mobile terminal,
a registration unit that registers a money payout schedule in a server in association with a user who uses the mobile terminal;
a determination unit that determines whether or not the balance of the payment account corresponding to the user is less than the amount deposited according to the payment schedule at the timing according to the payment schedule corresponding to the user;
a specifying unit that specifies the amount of money that the balance of the payment account will be the deposit amount according to the payout schedule when it is determined that the amount is low;
a deposit unit that deposits the specified amount of money into a payment account corresponding to the user;
an authentication unit that authenticates the user based on the user's biometric information;
an information processing system comprising: a payment unit for paying a payment amount from a payment account corresponding to an authenticated user;

Images