JP2019174873A - Payment support apparatus, payment support method and payment support program - Google Patents

Abstract

To execute a payment procedure easily.SOLUTION: A payment support server 111 includes a first acquisition unit 501, an identification unit 502, a second acquisition unit 503, and an execution unit 504. The first acquisition unit 501 acquires biological information of a payer received from the payer. The identification unit 502 identifies account information corresponding to the biological information acquired by the first acquisition unit 501. The second acquisition unit 503 acquires authentication information received from the payer. When succeeding the authentication using the authentication information of the payer acquired by the second acquisition unit 503, the execution unit 504 causes a processing that a predetermined amount is moved from an account indicated by the account information identified by the identification unit 502 to an account of a receiver designated in advance to execute.SELECTED DRAWING: Figure 5

Description

  The present invention relates to a payment support apparatus, a payment support method, and a payment support program for transferring a predetermined amount between accounts.

  Conventionally, in an event where a plurality of participants gather, such as a banquet or a party, the event organizer collects the participation fee from the participant and pays the cost together. As a method of collecting expenses from the participants, there are, for example, delivery by cash, transfer by advance or later transfer, and the like.

  In addition, when determining the date and location of the banquet, information on the date and time of the banquet selected by the participants and the objective evaluation information (store points) for the restaurant candidates are received and added together. After the deadline, there is a system that transmits a reservation e-mail to a restaurant decided by the secretary and transmits information and date / time of the restaurant to the participant (see, for example, Patent Document 1 below).

JP 2006-323805 A

  However, in the prior art, when the payer (participant) pays the cost by transfer, the payer obtains the account information of the payee (secretary) and accounts with the payer's terminal device or the financial institution's terminal device. There was a problem that it took time and money for the payment procedure to transfer by entering the number. In addition, in the case of a transfer at a later date, there is a problem that the participant forgets to transfer, and sometimes fails to collect, and the work burden and financial burden of the secretary are imposed.

  SUMMARY OF THE INVENTION An object of the present invention is to provide a payment support apparatus, a payment support method, and a payment support program that can easily perform a payment procedure in order to solve the above-described problems caused by the prior art.

  In order to solve the above-described problems and achieve the object, a payment support apparatus according to the present invention is acquired by a first acquisition unit that acquires biometric information of the payer received from a payer, and the first acquisition unit. Authentication means for specifying account information corresponding to the biometric information, second acquisition means for acquiring authentication information received from the payer, and authentication using the authentication information acquired by the second acquisition means. And execution means for executing a process of transferring a predetermined amount from the account indicated by the account information specified by the specifying means to a payee's account specified in advance.

  In the payment support apparatus according to the present invention as set forth in the invention described above, the first acquisition means acquires the biological information transmitted from a recipient terminal possessed by the recipient.

  In the payment support apparatus according to the present invention as set forth in the invention described above, the account information includes address information of a payer terminal possessed by the payer, and the specifying means is the living body acquired by the first acquisition means. Further comprising request means for specifying a payer terminal indicated by address information corresponding to the information, and making a payment request for the predetermined amount to the payer terminal specified by the specifying means, the second acquisition means, The authentication information transmitted from the payer terminal is acquired after the payment request by the request unit is made.

  In the payment support apparatus according to the present invention, in the above invention, when the request unit does not execute the processing by the execution unit until a predetermined period has elapsed after making the payment request, the payer The payment request is made again to the terminal.

  In the payment support apparatus according to the present invention as set forth in the invention described above, the authentication information is the same information as the biological information.

  The payment support apparatus according to the present invention further comprises an output control means for outputting, to a predetermined terminal, error information indicating that the account information is not specified when the account information is not specified by the specifying means. Furthermore, it is characterized by having.

  In the payment support apparatus according to the present invention as set forth in the invention described above, the account information includes information on the name of the payer, and the specifying means corresponds to the biological information acquired by the first acquisition means. The payer's name information is specified, and the output control means causes a predetermined terminal to output name list information created using the payer's name information specified by the specifying means. To do.

  In the payment support apparatus according to the present invention as set forth in the invention described above, the output control means causes a predetermined terminal to output information indicating that payment is completed when the processing by the execution means is executed. Features.

  Further, the payment support method according to the present invention acquires the payer's biometric information received from the payer, specifies account information corresponding to the acquired biometric information, and acquires authentication information received from the payer When the authentication using the acquired authentication information is successful, the computer executes a process of transferring a predetermined amount from the account indicated by the specified account information to the account of the recipient designated in advance. It is characterized by performing.

  The payment support program according to the present invention acquires the payer's biometric information received from a payer, specifies account information corresponding to the acquired biometric information, and acquires authentication information received from the payer If the authentication using the acquired authentication information is successful, the computer executes a process of transferring a predetermined amount from the account indicated by the specified account information to the account of the recipient specified in advance. It is made to perform.

  According to the payment support apparatus, the payment support method, and the payment support program according to the present invention, there is an effect that the payment procedure can be easily performed.

FIG. 1 is an explanatory diagram of a system configuration example of a payment support system 100 according to the embodiment. FIG. 2A is a block diagram illustrating an example of a hardware configuration of the payment support server 111 and the bank server 113. FIG. 2B is a block diagram illustrating an example of a hardware configuration of the payee terminal 121 and the payer terminal 131. FIG. 3A is an explanatory diagram showing an example of the contents stored in the account information database (DB) 114. FIG. 3B is an explanatory diagram showing an example of the stored contents of the settlement information database (DB) 112. FIG. 4 is a diagram illustrating an example of a payment support method by the payment support server 111 according to the present embodiment. FIG. 5 is an explanatory diagram showing a functional configuration of the payment support server 111. FIG. 6 is an explanatory diagram (part 1) illustrating an example of an operation screen displayed on the recipient terminal 121. FIG. 7 is an explanatory diagram (part 2) illustrating an example of an operation screen displayed on the recipient terminal 121. FIG. 8 is an explanatory diagram showing an example of a screen for registering participants displayed on the recipient terminal 121. FIG. 9A is an explanatory diagram illustrating an example of a registration completion screen displayed on the recipient terminal 121. FIG. 9B is an explanatory diagram illustrating an example of an error screen displayed on the recipient terminal 121. FIG. 10 is an explanatory diagram showing an input example of the administrator screen displayed on the recipient terminal 121. FIG. 11 is an explanatory diagram showing an input example of the administrator screen displayed on the recipient terminal 121. FIG. 12 is an explanatory diagram illustrating an example of a distribution screen displayed on the recipient terminal 121. FIG. 13 is an explanatory diagram illustrating an example of a payment status confirmation screen displayed on the recipient terminal 121. FIG. 14 is an explanatory diagram showing an example of a billing screen displayed on the payer terminal 131. FIG. 15 is an explanatory diagram illustrating an example of a payment procedure completion screen displayed on the payer terminal 131. FIG. 16 is a flowchart showing an example of a payer participation acceptance process performed by the payee terminal 121. FIG. 17 is a flowchart illustrating an example of a payer registration processing procedure performed by the payment support server 111. FIG. 18 is a flowchart illustrating an example of a payment request processing procedure performed by the payment support server 111. FIG. 19 is a flowchart showing an example of a payment acceptance processing procedure performed by the payer terminal 131. FIG. 20 is a flowchart illustrating an example of a transfer processing procedure performed by the payment support server 111. FIG. 21 is a flowchart illustrating an example of a transfer processing procedure performed by the payment support server 111. FIG. 22 is a flowchart showing an example of a participation reception processing procedure performed by the payer terminal 131. FIG. 23 is an explanatory diagram showing another example of the functional configuration of the payment support server 111. FIG. 24 is a flowchart illustrating another example of a series of processes performed by the payment support server 111.

  Exemplary embodiments of a payment support apparatus, a payment support method, and a payment support program according to the present invention will be described below in detail with reference to the drawings.

(System configuration of payment support system)
First, a system configuration example of the payment support system 100 according to the embodiment will be described. FIG. 1 is an explanatory diagram of a system configuration example of a payment support system 100 according to the embodiment. In FIG. 1, the payment support system 100 includes a payment support server 111, a bank server 113, a payee terminal 121, and a payer terminal 131.

  The payment support server 111 is an example of a payment support apparatus according to the present invention, and is, for example, a server provided in a company that provides a payment support service. The payment support server 111 is a general-purpose computer device that manages payment by transfer for each event. The payment support server 111 is, for example, a personal computer having a CPU (Central Processing Unit), a memory, an interface, and the like. The payment support server 111 has a settlement information database (DB) 112. The stored contents of the settlement information DB 112 will be described later with reference to FIG. 3B.

  The bank server 113 is a server provided in a financial institution such as a bank, for example. The bank server 113 is a general-purpose computer device that manages payee and payer accounts. The bank server 113 is a personal computer having a CPU, a memory, an interface, and the like. The bank server 113 has an account information database (DB) 114. The contents stored in the account information DB 114 will be described later with reference to FIG. 3A.

  The recipient terminal 121 is a computer device that the secretary (recipient) has in an event such as a banquet. For the recipient terminal 121, for example, a smartphone or a tablet PC (Personal Computer) is used.

  The payer terminal 131 is a computer device possessed by a participant (payer) who participates in an event such as a banquet. As the payer terminal 131, for example, a smartphone or a tablet PC is used. The payee terminal 121 and the payer terminal 131 have a CPU, a memory, an interface, and the like.

  However, the payee terminal 121 and the payer terminal 131 are not limited to smartphones and tablet PCs, but are various PCs such as desktop PCs, notebook PCs, tablet PCs, mobile phones, and PHSs (Personal Handyphone Systems). Is also possible.

  In the payment support system 100, the payment support server 111, the bank server 113, the payee terminal 121, and the payer terminal 131 are connected via a wired or wireless network 140. The network 140 is, for example, the Internet or a mobile communication network. However, the network 140 may be a LAN (Local Area Network), a WAN (Wide Area Network), or the like.

  The payment support server 111 is installed with a payment support program according to the present invention. The payment support server 111 performs processing according to various requests from the bank server 113, the payee terminal 121, and the payer terminal 131, and outputs various processing results to the payee terminal 121 and the payer terminal 131. To do.

(Example of hardware configuration of payment support server 111 and bank server 113)
Next, an example of a specific configuration of the payment support server 111 and the bank server 113 will be described. FIG. 2A is a block diagram illustrating an example of a hardware configuration of the payment support server 111 and the bank server 113. Since both the payment support server 111 and the bank server 113 have the same configuration, the payment support server 111 will be described below, and the description of the bank server 113 will be omitted.

  In FIG. 2A, the computer device that implements the payment support server 111 includes a CPU 211, a memory 212, and a communication IF (Interface) 213. The units 211 to 213 included in the computer device are connected by a bus 210. The CPU 211 controls the entire computer device.

  The memory 212 stores programs such as a boot program, various database data, and the like. The memory 212 stores various programs and data according to the payment support method of the present embodiment, such as a payment support program and partial data of various databases.

  The memory 212 is used as a work area for the CPU 211. The memory 212 may be a recording medium that records various data. The memory 212 can be realized by, for example, a ROM (Read-Only Memory), a RAM (Random Access Memory), a HDD (Hard Disc Drive), and an HD (Hard Disc).

  The communication IF 213 is connected to the network 140 and controls an interface between the inside of the computer device and external devices such as the payee terminal 121 and the payer terminal 131. Specifically, the communication IF 213 controls data input / output between the inside of the computer device and the external device.

(Example of hardware configuration of payee terminal 121 and payer terminal 131)
Next, an example of the hardware configuration of the payee terminal 121 and the payer terminal 131 will be described. FIG. 2B is a block diagram illustrating an example of a hardware configuration of the payee terminal 121 and the payer terminal 131. Since the payee terminal 121 and the payer terminal 131 have the same configuration, the payee terminal 121 will be described below, and the description of the payer terminal 131 will be omitted.

  2B, the recipient terminal 121 includes a CPU 221, a memory 222, an output device 223, an input device 224, and a communication IF 225. The constituent units 221 to 225 included in the recipient terminal 121 are connected to each other by a bus 220.

  The CPU 221 controls the entire recipient terminal 121. The CPU 221 controls the entire recipient terminal 121 using various programs and data stored in the memory 222. The memory 222 can be realized by a ROM, RAM, HDD, HD, flash memory, or the like.

  The output device 223 includes, for example, a display, a speaker, an audio output terminal, and the like. The display displays operation contents, guidance information for the user, and the like. The display displays various operation screens related to the payment support service. The display can be realized, for example, mainly by a liquid crystal display, an organic EL (Electro-Luminescence) display, or the like.

  The speaker outputs sound, alarm sound, and the like. The audio output terminal is a terminal for connecting a headphone or the like, and outputs sound, an alarm sound or the like to the connected headphone or the like in the same manner as a speaker.

  The input device 224 includes keys for inputting characters, numerical values, various instructions, and the like, and performs data input. The input device 224 can be realized by, for example, a touch panel or a keyboard. The input device 224 realized by a touch panel, a keyboard, or the like outputs a signal corresponding to an input operation on the input device 224 to the CPU 221.

  When the input device 224 is realized by a touch panel, the touch panel is stacked on the display surface side of the display. When the touch panel detects that a writing member such as a finger or a pen is in contact, the touch panel outputs an electrical signal corresponding to the contact position of the writing member with respect to the touch panel. As the touch panel, various known methods such as a resistive film method, a capacitance method, an acoustic pulse recognition method, an ultrasonic surface acoustic wave method, an infrared light shielding method, and an image recognition method can be used.

  The input device 224 includes a camera. The camera captures still images and moving images. Specifically, for example, the camera is controlled by the CPU 221 to capture an imaging target, generate image data, capture and input a two-dimensional code such as a barcode or QR code (registered trademark), or OCR Characters photographed using the (Optical Character Reader) function can be converted into data and input.

  The input device 224 includes a microphone. The microphone performs analog / digital conversion on the voice of the speaker input as analog data, and generates digital audio data. By using the microphone, the user can input characters and the like via the recipient terminal 121 instead of using the touch panel or the keyboard.

  The input device 224 includes a scanner and a sensor that read biological information. Although details will be described later, the biological information includes information such as a fingerprint, a palm shape, a face, a blood vessel, a retina, an iris, and a voiceprint.

  The communication IF 225 controls an interface between the inside of the payee terminal 121 and an external device such as the payment support server 111 or the payer terminal 131. The communication IF 225 may be connected to a telephone line network and used for voice communication.

(Storage contents of various DBs 112 and 114)
Next, the contents stored in the account information database (DB) 114 held by the payment support server 111 shown in FIG. 1 and the account information database (DB) 114 held by the bank server 113 will be described with reference to FIGS. 3A and 3B. The various DBs 112 and 114 are realized by a storage unit such as a memory, for example.

  FIG. 3A is an explanatory diagram showing an example of the contents stored in the account information database (DB) 114. 3A, the account information database 114 has fields of a user ID (Identification), name, address, terminal information, financial institution code, branch number, account number, balance, and authentication information. By setting information in each field, a record of account information (for example, account information 300-1 to 300-3) is stored.

  The user ID indicates identification information given to each user such as a payee or payer. The name indicates the name of a bank account holder (user). The address indicates the address of the bank account holder. The terminal information is an address of a terminal device owned by a bank account holder. The financial institution code is a code assigned to each financial institution. The branch number is a number assigned to the main branch of the financial institution. The account number is a number assigned to the account. The balance is the balance in the account. The authentication information includes biometric information registered in biometric authentication, a registered number in password authentication, and the like.

  For example, the account information 300-1 includes a user ID “U001”, a name “Soken Sotaro”, an address “Tokyo ...”, terminal information “aaa ... @ xxx”, a financial institution code “0000”, and a branch number “ 345 ”, account number“ 456... ”, Remaining amount“ ¥ 150,689 ”, and authentication information“ data XX ”. Similarly, the account information 300-2 and 300-3 other than the account information 300-1 are also stored in the account information DB 114.

  FIG. 3B is an explanatory diagram showing an example of the stored contents of the settlement information database (DB) 112. In FIG. 3B, the settlement information DB 112 includes fields for settlement ID, user ID, name, terminal information, account number, balance, authentication information, transfer account number, payment amount, payment presence / absence, and payment date / time. By setting information in each field, a record of settlement information (for example, settlement information 310-1 to 310-3) is stored.

  The settlement ID indicates identification information attached to each payment (settlement). The user ID indicates identification information given to each user such as a payee or payer, and is the same as the user ID stored in the account information DB 114 (see FIG. 3A). Therefore, the settlement information 310 is associated with the account information 300 of the account information DB 114.

  In the settlement information DB 112, the name, terminal information, account number, balance, and authentication information are the same as those included in the account information 300 of the account information DB 114. The transfer account number is the account number of the payee (secretary). The payment amount indicates the amount to be paid to the recipient. The presence / absence of payment indicates the presence / absence of payment to the recipient (whether or not it has been completed). The payment date and time indicates the date and time when the payment procedure to the recipient is completed.

  For example, the settlement information 310-1 includes a settlement ID “S001”, a user ID “U001”, a name “Soken Sotaro”, terminal information “aaa... @Xxx”, an account number “456. , 689 ”, authentication information“ data XX ”, transfer account number“ 123... ”, Payment amount“ ¥ 5,000 ”, payment presence / absence“ present ”, payment date and time“ 10/28 23:52 ”. Similarly, the settlement information 310-2 and 310-3 other than the settlement information 310-1 are stored in the settlement information DB 112.

(Payment support method by payment support server 111)
Next, a payment support method by the payment support server 111 according to the present embodiment will be described with reference to FIG. FIG. 4 is a diagram illustrating an example of a payment support method by the payment support server 111 according to the present embodiment. The numbers in parentheses shown below correspond to the numbers in parentheses shown in FIG.

  As shown in FIG. 4, it is assumed that an event such as a banquet is held at an event venue 400 such as an izakaya. It is assumed that a payee (secretary) having the payee terminal 121 and a plurality of payers (participants) having the payer terminal 131 participate in the banquet. At the event venue 400, the manager operates the recipient terminal 121 to display a reception screen 410 for receiving a fingerprint.

  (1) The secretary urges the participant to hold the finger from each participant to the recipient terminal 121 and accepts the fingerprint information and the bank account information associated with the fingerprint information. Then, the recipient terminal 121 transmits the fingerprint information received on the reception screen 410 to the payment support server 111. (2) Then, the payment support server 111 accesses the bank server 113 specified for each payer, and specifies the account information associated with the payer's fingerprint.

  (3) Further, the payment support server 111 creates name list information (participant name list) by specifying information indicating the payer's name from the payer's fingerprint information. The list information created by the payment support server 111 is transmitted to the recipient terminal 121. Thereby, the recipient terminal 121 can display name list information.

  Suppose that the banquet is over. For example, suppose that the price of a banquet is 100,000 yen and the price per person is 5,000 yen. (4) The payment support server 111 makes a payment request for 5,000 yen and an authentication request to each payer terminal 131. The authentication request is an authentication request using a fingerprint, for example.

  When the payer operates the payer terminal 131, the payer terminal 131 displays a reception screen 420 for receiving a fingerprint. (5) When the payer holds his / her finger over the payer terminal 131, the payer terminal 131 transmits the received fingerprint information and information indicating acceptance of the transfer to the payment support server 111.

  When the payment support server 111 receives the fingerprint information indicating that the transfer is to be accepted from the payer terminal 131, (6) a predetermined amount is transferred from the payer's account to the payee's account specified in advance. Participation fee will be transferred.

  As described above, in the payment support method using the payment support server 111, the payer can simply register for participation in the event simply by performing the fingerprint authentication via the payee terminal 121 at the event venue. Further, by displaying the list information on the recipient terminal 121, the recipient (secretary) can grasp the number of participants and the number of participants only by browsing the list information. Thereby, it is possible to reduce the labor of the secretary for grasping the number of event participants.

  Further, after the event, the payer can complete the transfer only by performing fingerprint authentication via the payer terminal 131. For this reason, the payer can perform the payment procedure easily, quickly and accurately. Further, since it is possible to eliminate the disclosure of information related to the recipient's account, the recipient can conduct the transaction with peace of mind.

(Functional configuration of payment support server 111)
FIG. 5 is an explanatory diagram showing a functional configuration of the payment support server 111. In FIG. 5, the payment support server 111 includes a first acquisition unit 501, a specification unit 502, a second acquisition unit 503, an execution unit 504, a creation unit 505, a request unit 506, an output control unit 507, A third acquisition unit 508 and a calculation unit 509 are provided. Each unit 501 to 508 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 (see FIG. 2A) of the payment support server 111, for example.

  The first acquisition unit 501 acquires the payer's biometric information received from the payer. The payer's biometric information received from the payer is biometric information for performing participation registration, for example, information obtained due to the payer's active action. In other words, the payer's biometric information received from the payer does not include biometric information such as face information (face photo) taken unintentionally by the payer.

  The payer's biometric information is authentication information associated with the account information of each bank. For example, the payer's biometric information is payer's fingerprint information. However, the payer's biometric information is not limited to the payer's fingerprint information, and may be other biometric information such as a palm shape, face, blood vessel, retina, iris, and voiceprint of the payer.

  Moreover, the 1st acquisition part 501 acquires the information of the bank which shows which bank account is the account matched with the said biometric information with the payer's biometric information. The bank information acquisition method includes, for example, displaying a different reception area for each bank on the display screen of the recipient terminal 121, accepting fingerprint information, and receiving the reception area information from the recipient terminal 121. It is possible to acquire bank information indicated by the information in the reception area. In addition to this method, it is also possible to acquire bank information input from a payer by an operation input or the like, separately from accepting fingerprint authentication.

  The identification unit 502 identifies account information corresponding to the biological information acquired by the first acquisition unit 501. For example, the specifying unit 502 specifies the account information by inquiring of the bank server 113 indicated by the bank information acquired by the first acquiring unit 501 whether or not there is account information corresponding to the biometric information.

  The second acquisition unit 503 acquires authentication information received from the payer. The authentication information received from the payer is, for example, the payer authentication information for accepting the transfer of a predetermined amount. The authentication information may be information unique to the payer. In the present embodiment, the authentication information is, for example, the same information as the biometric information acquired by the first acquisition unit 501, specifically, fingerprint information associated with the payer's account information. Further, the authentication information may be a personal identification number or biometric information other than fingerprints such as a palm shape, face, blood vessel, retina, iris, and voiceprint. The authentication information may be payment permission information acquired by pressing a button for accepting payment.

  When the execution unit 504 succeeds in the authentication using the payer authentication information acquired by the second acquisition unit 503, the execution unit 504 receives from the payer account indicated by the account information specified by the specifying unit 502 in advance. A process of transferring a predetermined amount to a person's account is executed. The account information is stored in the bank server 113 of each bank. The account information includes information on the payer's name, an account number, address information of the payer terminal 131, and the like (see account information 300 in FIG. 3A).

  The process of moving the predetermined amount is a process of making a transfer. For example, the execution unit 504 causes the bank server 113 to transfer a predetermined amount from the payer's account to the payee's account. The payee's account is an account designated in advance by the payee, for example, the payee's account. The predetermined amount is a participation fee at the event. The predetermined amount is, for example, an amount obtained by apportioning the expense required for the event by the number of participants in the event.

  Next, a terminal that receives the payer's biometric information will be described. In the present embodiment, the terminal that receives the payer's biometric information is the payee terminal 121. The first acquisition unit 501 acquires the payer's biometric information transmitted from the payee terminal 121 of the payee. Specifically, the first acquisition unit 501 acquires the payer's biometric information received by the receiving unit of the recipient terminal 121 that the recipient has. The accepting unit of the recipient terminal 121 is a scanner or sensor that reads biometric information. The first acquisition unit 501 acquires the payer's biometric information received by the payee terminal 121 from the payee terminal 121.

  However, the terminal that accepts the payer's biometric information is not limited to the payee terminal 121 but may be the payer terminal 131. In this case, the first acquisition unit 501 acquires biometric information transmitted from the payer terminal 131. Further, the terminal that receives the payer's biometric information may be the payer's own payer terminal 131, and the first acquisition unit 501 may acquire the biometric information transmitted from each payer terminal 131. Good. In this way, each payer does not need to touch another person's terminal in order to transmit his / her biological information to the payment support server 111. Therefore, the payment support server 111 can easily obtain biometric information of the payer who feels resistance to touching another person's terminal for reasons such as leakage of biometric information and hygiene. In this case, for example, a participation request unit (not shown) may transmit request information (event guidance) about whether or not to participate to the payer terminal 131 indicated by the address information registered in advance. Furthermore, when the first acquisition unit 501 acquires the biometric information transmitted from the payer terminal 131, the payment support server 111 may perform participation registration of the payer corresponding to the payer terminal 131. Good.

  Next, the payment request to the payer will be described. In the present embodiment, the specifying unit 502 specifies the payer terminal indicated by the address information corresponding to the biological information acquired by the first acquiring unit 501. The request unit 506 makes a payment request for a predetermined amount to the payer terminal 131 indicated by the address information specified by the specifying unit 502.

  The second acquisition unit 503 acquires the payer authentication information transmitted from the payer terminal 131 from which the payment request is made after the payment request by the request unit 506 is made. The accepting unit that accepts the authentication information by the payer terminal 131 is an input device 224 (see FIG. 2B) to which the payer authentication information is input. For example, when the payer authentication information is biometric information, the accepting unit of the payer terminal 131 is a scanner or a sensor that reads the authentication information. When the payer authentication information is a password, the accepting unit of the payer terminal 131 is a touch panel or a keyboard. The second acquisition unit 503 acquires the payer authentication information received by the payer terminal 131 from the payer terminal 131.

  When the payer terminal 131 accepts the payer authentication information, for example, payment can be made even after the event is dissolved. In addition, when payment can be completed on the spot of the event venue, it is possible to accept payer authentication information using the recipient terminal 121. In this case, the payee terminal 121 presents the payment amount for each payer using information for identifying the payer from the payer (for example, the biometric information of the payer), and accepts authentication information for each payer. Just do it. Then, the recipient terminal 121 transmits the received authentication information to the payment support server 111. Thereby, even if the payer does not have the payer terminal 131, the payment can be completed at the event venue.

  Next, prompting the payer for payment will be described. In the present embodiment, the requesting unit 506 makes a payment request when a process for transferring a predetermined amount by the execution unit 504 is not executed until a predetermined period elapses after a payment request is made. A payment request is made to 131 again. The predetermined period is, for example, a period of one month. Further, the timing when the request unit 506 makes a payment request may be, for example, the day when the payer's account can be expected to have a certain amount of money, specifically, the day after the salary day (for example, 25th of every month). Also good.

  Next, output of error information will be described. When the specifying unit 502 does not specify the account information corresponding to the payer's biometric information, the output control unit 507 causes the predetermined terminal to output error information indicating that the account information is not specified. The predetermined terminal is, for example, a terminal device that receives biometric information and transmits the biometric information to the payment support server 111. In the present embodiment, the predetermined terminal is the recipient terminal 121. For example, the output control unit 507 causes the receiver terminal 121 to output error information by transmitting error information to the receiver terminal 121.

  Further, when the account information corresponding to the payer's biometric information is specified by the specifying unit 502, the output control unit 507 outputs registration completion information indicating that the account information has been specified to a predetermined terminal. The predetermined terminal is not limited to the payee terminal 121, and may be the payer terminal 131 when the terminal device that has received and transmitted the biometric information is the payer terminal 131.

  Further, even when the account information is specified by the specifying unit 502, the output control unit 507 sets error information indicating that there is no predetermined amount when there is no predetermined amount in the account indicated by the account information. Output to the terminal. The predetermined amount is an amount expected as the cost of the event, and can be arbitrarily set by the recipient, for example. On the other hand, the output control unit 507 causes a predetermined terminal to output registration completion information when there is a predetermined amount in the account indicated by the account information.

  Next, creation of name list information will be described. In the present embodiment, the specifying unit 502 specifies information on the payer's name corresponding to the biological information acquired by the first acquiring unit 501. The creation unit 505 creates name list information using information on the payer's name specified by the specifying unit 502. The output control unit 507 outputs the name list information created by the creation unit 505 to a predetermined terminal. In the name list indicated by the name list information, for example, names of participants are listed. For example, the output control unit 507 causes the recipient terminal 121 to output the name list information by transmitting the name list information to the recipient terminal 121. The predetermined terminal from which the output control unit 507 outputs the name list information is a terminal of a person (secretary) who views the name list information, and specifically, the recipient terminal 121.

  In the present embodiment, the output control unit 507 adds information indicating that payment is completed to the directory information to the predetermined terminal when the execution unit 504 executes a process of transferring a predetermined amount. Output. For example, the creation unit 505 creates name list information in which the name of the participant is associated with the presence / absence of payment. For example, the output control unit 507 causes the recipient terminal 121 to output such name list information. Thereby, the payee can easily grasp whether or not the payment is completed for each payer.

  Next, calculation of expenses in the event will be described. In the present embodiment, the third acquisition unit 508 acquires information on expenses in the event and information on payers who have participated in the event. Such information is acquired, for example, when the recipient terminal 121 accepts the information from the recipient (secretary). The expense information at the event is, for example, information on the total payment amount at the event. The information on the payer is, for example, information on the number of people who participated in the event. However, the information regarding the payer may include, for example, attribute information of the participant such as age, gender, job title, and address.

  The calculation unit 509 calculates a payment amount according to the payer based on the cost information acquired by the third acquisition unit 508 and the information related to the payer. For example, the calculation unit 509 calculates a payment amount corresponding to the payer by a predetermined calculation method such as a per capita rate or a slope distribution. Further, for example, the calculation unit 509 may calculate the payment amount according to the payer by a predetermined calculation method using the attribute information of the participant, for example, by setting the payment amount according to the age.

  The predetermined calculation method can be arbitrarily set by the recipient (secretary). The request unit 506 makes a payment request for the payment amount corresponding to the payer to the payer terminal 131 indicated by the address information associated with the biological information acquired by the first acquisition unit 501.

(Examples of display screens of payee terminal 121 and payer terminal 131)
Next, examples of display screens of the payee terminal 121 and the payer terminal 131 will be described with reference to FIGS. FIG. 6 is an explanatory diagram (part 1) illustrating an example of an operation screen displayed on the recipient terminal 121. The operation screen 600 of FIG. 6 includes selection buttons 601 and 602 indicating already registered events, and a registration button 603 for performing event registration.

  The event indicated by the selection button 601 indicates an event of a welcome party on October 14 that was performed in the past. When the selection button 601 is selected, name list information including the payment status of the payer at the welcome party on October 14 is displayed. The event indicated by the selection button 602 indicates an event of a synchronization meeting to be performed from now (from 19:00 today). A registration button 603 is a button for registering other events. When the recipient selects the selection button 602 on the operation screen 600, the operation screen 700 shown in FIG.

  FIG. 7 is an explanatory diagram (part 2) illustrating an example of an operation screen displayed on the recipient terminal 121. The operation screen 700 in FIG. 7 includes selection buttons 701 and 702. The selection button 701 is a button for shifting to a participant (payer) screen. The selection button 702 is a button for shifting to an administrator (recipient) screen. For example, when the selection button 701 is selected on the operation screen 700, the operation screen 800 shown in FIG. 8 is displayed, and when the selection button 702 is selected, the operation screen 1000 shown in FIG. 10 is displayed.

  FIG. 8 is an explanatory diagram showing an example of a screen for registering participants displayed on the recipient terminal 121. The registration screen 800 of FIG. 8 shows a screen when operated by a participant before the start of the event, for example, at the event venue of the synchronous party. The registration screen 800 includes at least a notification 801 indicating that the expense for the event is to be debited, a fingerprint authentication field 802, a bank selection button 803, a transmission button 804, and a return button 805.

  The fingerprint authentication column 802 has a different column for receiving a fingerprint for each bank. If the payer agrees to debit the expense at the event, he places his finger over the desired bank fingerprint field 802. When the bank selection button 803 is selected, a fingerprint authentication field 802 of a bank other than the currently displayed bank is displayed. When the send button 804 is selected, the fingerprint information input in the fingerprint authentication field 802 is transmitted to the payment support server 111 together with the bank information shown in the fingerprint authentication field 802.

  When the return button 805 is selected on the registration screen 800, the screen returns to the operation screen 700 of FIG. When the transmission button 804 is selected on the registration screen 800, the screen shifts to a registration completion screen 900 in FIG. 9A or an error screen 920 in FIG. 9B.

  Further, as described above, when the payer's biometric information is received by the payer terminal 131, for example, the operation screen 800 is displayed on the payer terminal 131 in addition to the payee terminal 121. . In such a case, the payee terminal 121 and the payer terminal 131 display a shared operation screen 800 using, for example, a known screen sharing technique.

  In this case, when the payer terminal 131 holds the finger over the fingerprint authentication field 802 and selects the send button 804 in the terminal, for example, along with the bank information shown in the fingerprint authentication field 802, The fingerprint information input in the fingerprint authentication field 802 is transmitted to the recipient terminal 121.

  When the payee terminal 121 receives these pieces of information from the payer terminal 131, the payee terminal 121 updates the display content of the operation screen 800 as if the payer held his / her finger over the fingerprint authentication field 802 at the own terminal, Information received from the payer terminal 131 is transmitted to the payment support server 111.

  In this case, the registration completion screen 900 in FIG. 9A and the error screen 920 in FIG. 9B may be displayed on the payer terminal 131 in addition to the payee terminal 121 in the same manner.

  FIG. 9A is an explanatory diagram illustrating an example of a registration completion screen displayed on the recipient terminal 121. The registration completion screen 900 of FIG. 9A includes a notification 901 that the registration of the participant is completed and a menu button 902. By the notification 901, the payer can grasp that the registration for the account withdrawal of the expense at the event is completed. When the menu button 902 is selected, for example, the screen returns to the operation screen 600 of FIG.

  In this way, the payment support server 111 can accept consent for debiting the expenses at the event by simply holding the finger of the participant, and can register in the name list information.

  FIG. 9B is an explanatory diagram illustrating an example of an error screen displayed on the recipient terminal 121. The error screen 920 of FIG. 9B includes a notification 921 that the balance of the account is insufficient and a menu button 902. The notification 921 allows the payer to know that the balance of the account is insufficient. Further, the content to be notified differs depending on the type of error. For example, when the account cannot be specified, the fact is notified.

  Even in the case of an error, in order to use this payment method, for example, another payer may be allowed to make payments for two people. For example, in the registration screen 800 of FIG. 8, another payer displays a button that allows other payers to set payments for a plurality of people, and the button is operated to accept designation of the number of other payers. May be able to pay for multiple people. In this case, the other payer may receive the payment amount in cash or the like from the payer in error.

  FIG. 10 is an explanatory diagram showing an input example of the administrator screen displayed on the recipient terminal 121. An administrator screen 1000 in FIG. 10 shows, for example, a screen viewed by the secretary at the start of the event of the synchronization party. The administrator screen 1000 includes name list information 1001, a membership fee calculation button 1002, and a return button 1003. The list information 1001 includes the name of the meeting, the number of participants, and the name of the participant (name of the payer).

  When the membership fee calculation button 1002 is selected on the administrator screen 1000, the screen shifts to the input screen 1100 in FIG. Further, when the return button 1003 is selected on the administrator screen 1000, the screen returns to the operation screen 700 of FIG. By using the list information 1001, the recipient (secretary) can easily grasp the number and names of the participants without confirming the number and names of the participants.

  Also, in the name list information 1001, for example, in the vicinity of each participant's name (right in the example shown in the figure), in order to indicate the fact that the participant has "accepted the account withdrawal of expenses", the participant An image imitating a seal (an imprint) may be displayed (see, for example, 1001a). In addition, in this case, instead of an image imitating a seal, an image representing a deformed fingerprint may be displayed, or the participant may ask “when (for example, what day of the month) A QR code or the like indicating that “acceptance for withdrawal” may be displayed.

  FIG. 11 is an explanatory diagram showing an input example of the administrator screen displayed on the recipient terminal 121. An input screen 1100 in FIG. 11 shows a screen that is operated by the secretary after the event of the synchronization party ends, for example. The input screen 1100 includes a price input field 1101, calculation method selection buttons 1102 and 1103, a number of people input field 1104, a setting button 1105, a calculation button 1106, a name list information button 1107, and a menu button 1108. In the price input field 1101, for example, the total payment amount in the event is input by the recipient. Calculation method selection buttons 1102 and 1103 are buttons for the recipient (secretary) to select an equal distribution or an inclination distribution.

  In the number-of-persons input field 1104, the number of people in the case of equal division is entered. The number of people input field 1104 displays, for example, the number of payers who have previously registered payment by fingerprint. However, if there is a payer in error, if the per capita rate is set, since the payer is not counted, the number of people in the number entry field 1104 can be changed manually.

  The setting button 1105 is a button for calculating a payment amount for each payer by a calculation method arbitrarily determined by the recipient. The calculation button 1106 is a button for calculating the payer's payment amount based on the contents input in each column or the selected contents. When the calculation button 1106 is selected on the input screen 1100, the screen shifts to a distribution screen 1200 shown in FIG.

  When the name list information button 1107 is selected on the input screen 1100, the screen returns to the administrator screen 1000 of FIG. When the menu button 1108 is selected on the input screen 1100, the screen returns to the operation screen 600 of FIG. Thus, in this embodiment, the payee (secretary) can easily obtain the participation fee for each payer without calculating the participation fee.

  FIG. 12 is an explanatory diagram illustrating an example of a distribution screen displayed on the recipient terminal 121. The distribution screen 1200 of FIG. 12 includes name list information 1201, a determination button 1202, and a return button 1203. The list information 1201 indicates the name of the participant (name of the payer) and the payment amount for each payer. The determination button 1202 is a button for determining the payment amount with the amount shown in the name list information 1201.

  When the determination button 1202 is selected, the payment amount of each payer is determined with the amount shown in the name list information 1201, and a payment request is transmitted to the payer terminal 131. When the return button 1203 is selected, the screen returns to the input screen 1100 (see FIG. 11), and for example, the payer's payment amount can be calculated by another calculation method.

  FIG. 13 is an explanatory diagram illustrating an example of a payment status confirmation screen displayed on the recipient terminal 121. The payment status confirmation screen 1300 in FIG. 13 includes name list information 1301. The list information 1301 indicates the name of the participant (the name of the payer), the payment amount, and the presence / absence of payment (completed or incomplete) for each payer. For example, when “Yes” indicating whether or not there is payment is tapped, the date and time when the payment procedure is completed is displayed. Further, when “None” indicating whether or not payment is made is tapped, a screen may be displayed on which a payment request can be retransmitted to a payer terminal 131 of a payer whose payment procedure has not been completed.

  By using the list information 1301, the recipient (secretary) can easily grasp the presence / absence of the payment by only checking the list information 1301 without having to check whether or not there is a separate payment to his / her account. Can do.

  FIG. 14 is an explanatory diagram showing an example of a billing screen displayed on the payer terminal 131. The billing screen 1400 of FIG. 14 shows a screen that is operated by the payer after the event of the synchronous party ends. The billing screen 1400 includes a notification 1401 for accepting that the displayed amount is debited as an expense for the event, a fingerprint authentication field 1402, and a send button 1403.

  If the payer agrees that the displayed amount will be debited as the cost of the event, the payer places his finger over the fingerprint authentication field 1402. When the transmission button 1403 is selected, the input fingerprint information is transmitted to the payment support server 111, and when the payment procedure is completed, the process proceeds to a payment procedure completion screen 1500 shown in FIG.

  FIG. 15 is an explanatory diagram illustrating an example of a payment procedure completion screen displayed on the payer terminal 131. The payment procedure completion screen 1500 shown in FIG. 15 includes a notification 1501 indicating that registration has been completed. The notification 1501 enables the payer to know that the account deduction for the expense at the event has been completed. In this way, the payer can simply complete the payment by bank transfer simply by holding the finger.

(An example of a payer participation reception processing procedure performed by the payee terminal 121)
Next, an example of a payer participation reception processing procedure performed by the payee terminal 121 will be described with reference to FIG. FIG. 16 is a flowchart showing an example of a payer participation acceptance process performed by the payee terminal 121.

  In FIG. 16, the payee terminal 121 determines whether or not a payer registration start is accepted (step S1601). The payer registration is started, for example, when the selection button 701 for shifting to the “participant screen” on the operation screen 700 (see FIG. 7) accepts the selection. The payee terminal 121 waits until accepting the payer registration start (step S1601: No). When the payee terminal 121 accepts the start of registration of the payer (step S1601: Yes), for example, in the fingerprint authentication field 802 of FIG. 8, the authentication information for registration (payer's fingerprint information) is accepted (step S1602). ).

  Then, the recipient terminal 121 determines whether or not reception has been completed (step S1603). Completion of reception is, for example, that the transmission button 804 in FIG. 8 is selected. The recipient terminal 121 returns to step S1602 when the reception is not completed (step S1603: No). When the recipient terminal 121 completes the reception (step S1603: Yes), it sends the authentication information for registration (payer's fingerprint information) to the payment support server 111 (step S1604).

  Next, the recipient terminal 121 determines whether or not a registration result has been received from the payment support server 111 (step S1605). The recipient terminal 121 waits until it receives a registration result from the payment support server 111 (step S1605: No). When the recipient terminal 121 receives the registration result from the payment support server 111 (step S1605: Yes), the recipient terminal 121 displays the registration result on the display (step S1606), and ends a series of processing according to this flowchart. The registration result screen is, for example, the registration completion screen 900 in FIG. 9A or the error screen 920 in FIG. 9B.

  Through the above-described processing, the recipient terminal 121 can perform registration for making an account debit for the expense at the event quickly and accurately by a simple operation of only fingerprint authentication (just hold the finger). it can.

(An example of a payer registration process performed by the payment support server 111)
Next, an example of a payer registration processing procedure performed by the payment support server 111 will be described with reference to FIG. FIG. 17 is a flowchart illustrating an example of a payer registration processing procedure performed by the payment support server 111. In FIG. 17, the payment support server 111 determines whether or not registration authentication information (payer fingerprint information) has been received from the recipient terminal 121 (step S1701).

  The payment support server 111 waits until receiving registration authentication information from the recipient terminal 121 (step S1701: No). Then, when the payment support server 111 receives the authentication information for registration from the payee terminal 121 (step S1701: Yes), the payment support server 111 inquires the bank server 113 and specifies the payer and account information associated with the authentication information ( Step S1702).

  Next, the payment support server 111 determines whether or not the account information has been identified (step S1703). If the payment support server 111 cannot identify the account information (step S1703: NO), the payment support server 111 transmits an error message (for example, see the error screen 920 in FIG. 9B) to the payee terminal 121 (step S1704). The process ends.

  On the other hand, when the payment support server 111 can identify the account information (step S1703: Yes), the payment support server 111 determines whether or not there is a predetermined balance in the payer's account (step S1705). The predetermined amount is an amount predetermined by the recipient, for example, a cost assumed in the event. If there is no predetermined amount remaining in the payer's account (step S1705: No), the payment support server 111 proceeds to step S1704.

  On the other hand, when there is a predetermined amount remaining in the payer's account (step S1705: Yes), the payment support server 111 registers various information of the payer included in the account information in the settlement information DB 112 (see FIG. 3B). (Step S1706). Then, the payment support server 111 registers the payer in the name list information (step S1707). Next, the payment support server 111 transmits a registration message (see the registration completion screen 900 in FIG. 9A) to the recipient terminal 121 (step S1708), and ends a series of processing according to this flowchart.

  Through the processing described above, the payment support server 111 can register various types of information on the payer in the settlement information DB 112 (see FIG. 3B), and can perform registration processing on the payee and the payer via the payee terminal 121. The result can be notified.

(Example of payment request processing procedure performed by the payment support server 111)
Next, an example of a payment request processing procedure performed by the payment support server 111 will be described with reference to FIG. FIG. 18 is a flowchart illustrating an example of a payment request processing procedure performed by the payment support server 111. In the flowchart of FIG. 18, the payment support server 111 determines whether information related to payment has been received from the recipient terminal 121 (step S1801). The reception of information related to payment is that the calculation button 1106 is selected on the input screen 1100 of FIG.

  The payment support server 111 waits until receiving information regarding payment from the recipient terminal 121 (step S1801: No). When receiving information related to payment from the payee terminal 121 (step S1801: Yes), the payment support server 111 calculates the payment amount of each payer (step S1802). The calculation method is a method selected by the recipient, such as an even split or a slope distribution (see the input screen 1100 in FIG. 11).

  Next, the payment support server 111 determines whether or not it is a decision (step S1803). “Determination” means that the determination button 1202 in FIG. 12 is selected. If it is not a decision (step S1803: No), the payment support server 111 determines whether to change the calculation method (step S1804). The change of the calculation method is, for example, that the return button 1203 in FIG. 12 is selected.

  When the payment support server 111 does not change the calculation method (step S1804: No), the payment support server 111 returns to step S1803. On the other hand, when changing the calculation method (step S1804: Yes), the payment support server 111 returns to step S1801. In step S1803, if it is a decision (step S1803: Yes), the payment support server 111 transmits a payment request to each payer terminal 131 (step S1805), and ends a series of processes according to this flowchart.

  Through the processing described above, the payment support server 111 can calculate the payment amount of each payer and make a payment request to each payer terminal 131.

(Example of payment acceptance processing procedure performed by payer terminal 131)
Next, an example of a payment acceptance processing procedure performed by the payer terminal 131 will be described with reference to FIG. FIG. 19 is a flowchart showing an example of a payment acceptance processing procedure performed by the payer terminal 131. In the flowchart of FIG. 19, first, the payer terminal 131 determines whether or not a payment request has been received from the payment support server 111 (step S1901).

  The payer terminal 131 waits until a payment request is received from the payment support server 111 (step S1901: No). When the payer terminal 131 receives a payment request from the payment support server 111 (step S1901: Yes), for example, in the fingerprint authentication field 1402 of FIG. 14, the payment information (fingerprint information) is accepted. (Step S1902).

  Then, the payer terminal 131 determines whether or not the acceptance is completed (step S1903). Completion of reception is, for example, that the transmission button 1403 in FIG. 14 is selected. When the payer terminal 131 does not complete the reception (step S1903: No), the payer terminal 131 returns to step S1902. When the acceptance is completed (step S1903: Yes), the payer terminal 131 transmits the authentication information for payment (payer's fingerprint information) to the payment support server 111 (step S1904).

  Next, the payer terminal 131 determines whether or not a payment result has been received from the payment support server 111 (step S1905). The payer terminal 131 waits until a payment result is received from the payment support server 111 (step S1905: No). When the payer terminal 131 receives the payment result from the payment support server 111 (step S1905: Yes), the payer terminal 131 displays the payment result on the display (step S1906), and ends the series of processes according to this flowchart. The payment result screen is, for example, the payment procedure completion screen 1500 shown in FIG.

  By the above-described processing, the payer terminal 131 can perform consent for the account debit for the expense at the event only by fingerprint authentication (just by holding the finger). Thereby, the payment procedure can be performed easily, quickly and accurately.

(Example of transfer processing procedure performed by the payment support server 111)
Next, an example of a transfer processing procedure performed by the payment support server 111 will be described with reference to FIG. FIG. 20 is a flowchart illustrating an example of a transfer processing procedure performed by the payment support server 111. In the flowchart of FIG. 20, the payment support server 111 determines whether or not the authentication information for payment has been received from the payer terminal 131 (step S2001).

  If the payment support server 111 does not receive authentication information for payment from the payer terminal 131 (step S2001: No), the payment support server 111 determines whether a predetermined period has elapsed since the payment request was made (step S2002). If the predetermined period has not elapsed since the payment request was made (step S2002: No), the payment support server 111 proceeds to step S2001.

  When a predetermined period has elapsed since the payment request was made (step S2002: Yes), the payment support server 111 transmits the payment request again to the payer terminal 131 of the unpaid payer (step S2003), and the process proceeds to step S2001. To do. In step S2001, when the payment support server 111 receives the authentication information for payment from the payer terminal 131 (step S2001: Yes), the payment support server 111 instructs the bank server 113 to perform transfer from the payer's account to the payee's account. (Step S2004).

  When the transfer is completed, the payment support server 111 registers that the transfer is completed in the name list information (step S2005), and transmits the payment result to the payer terminal 131 (step S2006). Next, the payment support server 111 determines whether or not all payers have been paid (step S2007). If payment by all payers is not completed (step S2007: No), the payment support server 111 proceeds to step S2001. The payment support server 111 completes a series of processes according to this flowchart when payment of all payers is completed (step S2007: Yes).

  Through the processing described above, the payment support server 111 can execute the transfer and register the fact that the transfer is completed in the name list information. In addition, payment can be prompted for payments that are not made.

(Another example of payment method)
In the explanation above, the case where the payer transfers the participation fee after the end of the event is explained, but in the following, the participation fee is determined in advance and the payer transfers the participation fee before the start of the event. explain. Events for which participation fees are uniformly set in advance are, for example, alumni associations and wedding secondary parties.

(Another example of the transfer processing procedure performed by the payment support server 111)
FIG. 21 is a flowchart illustrating an example of a transfer processing procedure performed by the payment support server 111. In the flowchart of FIG. 21, the payment support server 111 determines whether or not registration authentication information (payer fingerprint information) has been received from the recipient terminal 121 (step S2101).

  The payment support server 111 waits until receiving registration authentication information from the recipient terminal 121 (step S2101: No). Then, when the payment support server 111 receives the authentication information for registration from the payee terminal 121 (step S2101: Yes), the payment support server 111 inquires the bank server 113 and specifies the payer and account information associated with the authentication information ( Step S2102).

  Next, the payment support server 111 determines whether or not the account information has been identified (step S2103). When the payment support server 111 cannot identify the account information (step S2103: No), the payment support server 111 transmits an error message (for example, refer to the error screen 920 in FIG. 9B) to the recipient terminal 121 (step S2104). The process ends.

  On the other hand, when the account information can be specified (step S2103: Yes), the payment support server 111 determines whether or not there is a predetermined amount of balance in the payer's account (step S2105). The predetermined amount is an amount predetermined by the recipient, for example, an event participation fee. If there is no predetermined amount remaining in the payer's account (step S2105: No), the payment support server 111 proceeds to step S2104.

  On the other hand, when there is a predetermined amount remaining in the payer's account (step S2105: Yes), the payment support server 111 causes the bank server 113 to perform transfer from the payer's account to the payee's account (step S2106). . Then, the payment support server 111 registers that the transfer has been completed in the name list information created in advance (step S2107), and transmits the payment result to the payer terminal 131 (step S2108). In response to this, the recipient terminal 121 displays a screen corresponding to the payment procedure completion screen 1500 in FIG. 15, for example.

  Next, the payment support server 111 determines whether or not all payers registered in the list information created in advance have been paid (step S2109). The payment support server 111 proceeds to step S2101 when payment of all payers is not completed (step S2109: No). The payment support server 111 completes a series of processes according to this flowchart when payment of all payers is completed (step S2109: Yes).

  Through the processing described above, the payment support server 111 can transfer the participation fee by simply holding the fingerprint before the start of the event in the event where the participation fee is uniformly determined in advance, and the payer who has finished the transfer is listed. You can register for information.

(Another example of payer registration method)
In the above description, the case where the payer's participation is accepted by the payee terminal 121 at the event venue on the day of the event has been described. However, in the following, the case where the payer's participation is accepted by the payer terminal 131 before the day of the event. explain.

(Another example of a procedure for accepting participation by the payer terminal 131)
FIG. 22 is a flowchart showing an example of a participation reception processing procedure performed by the payer terminal 131. In the flowchart of FIG. 22, first, the payer terminal 131 determines whether or not information related to the participation request has been received from the payment support server 111 (step S2201).

  Here, supplementing the transmission of the participation request from the payment support server 111, the payment support server 111 creates in advance name list information including information on the payer scheduled to participate based on the input of the payee (secretary), etc. Suppose you are. Further, the payment support server 111 transmits a participation request to the payer terminal 131 of the payer registered in the list information at a predetermined timing designated by the payee (secretary). Thereby, the payer terminal 131 receives the participation request from the payment support server 111.

  The payer terminal 131 waits until it receives a participation request from the payment support server 111 (step S2201: No). When the payer terminal 131 receives the participation request from the payment support server 111 (step S2201: Yes), for example, the payer terminal 131 displays a screen corresponding to the fingerprint authentication field 802 in FIG. ) Is received (step S2202).

  Then, the payer terminal 131 determines whether or not the acceptance is completed (step S2203). Completion of reception is, for example, that the payer terminal 131 displays a screen corresponding to the transmission button 804 in FIG. 8 and that button is selected. If the acceptance is not completed (step S2203: No), the payer terminal 131 returns to step S2202. On the other hand, when the acceptance is completed (step S2203: Yes), the payer terminal 131 transmits authentication information for registration (specifically, for example, fingerprint information) to the payment support server 111 (step S2204). .

  Next, the payer terminal 131 determines whether or not a registration result has been received from the payment support server 111 (step S2205). The payer terminal 131 waits until a registration result is received from the payment support server 111 (step S2205: No). When the payer terminal 131 receives the registration result from the payment support server 111 (step S2205: Yes), the payer terminal 131 displays the registration result on the display (step S2206), and ends the series of processes according to this flowchart. The registration result screen is, for example, a screen corresponding to the registration completion screen 900 in FIG. 9A or the error screen 920 in FIG. 9B.

  Through the above-described processing, registration for paying the expenses at the event from the payer terminal 131 can be performed. For example, registration for participation at a place other than the event venue is performed before the event day. be able to. Accordingly, since registration and participation for making an account withdrawal can be made prior to the date of the event, the reception procedure at the event venue can be simplified.

  In addition, the payer terminal 131 can easily and quickly register for the account withdrawal of the expense at the event by fingerprint authentication (just hold the finger) before the day of the event. Even if a person who has registered to participate in the event (payer) suddenly misses the day, the payment support server 111 can identify the payer's account information and contact information. After completion, the payer can be charged for a fee such as a cancellation fee.

(Another example of functional configuration of payment support server 111)
FIG. 23 is an explanatory diagram showing another example of the functional configuration of the payment support server 111. In FIG. 23, the payment support server 111 includes a biometric information receiving unit 2301 2302, a participant / payment account management unit 2303, a payment account inquiry unit 2304, a payment account information receiving unit 2305, and an expense information receiving unit 2306. A payment amount calculation unit 2307, a payment amount transmission unit 2308, a transfer request unit 2309, a transfer result reception unit 2310, and a payment status storage unit 2311.

  The biometric information receiving unit 2301 receives the biometric information transmitted from the event participation intention expression terminal device 2351. Specifically, the biological information receiving unit 2301 realizes its function by, for example, the communication IF 213 illustrated in FIG. 2A.

  The event participation intention expression terminal device 2351 is a terminal device used by a person who wants to participate in an event (participation applicant) to express his intention to participate in the event. Specifically, the event participation intention expression terminal device 2351 may be, for example, the payee terminal 121 shown in FIG. 1 or the payer terminal 131 shown in FIG. By installing a predetermined application in at least one of the payee terminal 121 and the payer terminal 131, a function as the event participation intention expression terminal device 2351 can be realized.

  The event participation intention expression terminal device 2351 obtains the biological information of the applicant who wants to participate from the person who wants to participate in the event that wants to participate. The biometric information of the applicant who wishes to participate is biometric information for performing participation registration, for example, information obtained due to the active action of the applicant. The biometric information of the applicant who wishes to participate may be, for example, fingerprint information of the biometric information of the applicant who wishes to participate, or may be other biometric information such as a palm shape, face, blood vessel, retina, iris, and voiceprint.

  The biometric information may be authentication information associated with each bank's payment account that is not only specified by the individual who wants to participate but also owned by the applicant. In that case, the information for collation which collates the said biometric information with each bank server 113 may be registered beforehand. By doing so, when the payment account inquiry unit 2304 makes an inquiry about the payment account of the participant who wishes to participate in each bank server 113 based on the biometric information, each bank server is used according to the biometric information. 113 can identify the payment account.

  In addition, the event participation intention expression terminal device 2351 obtains bank information indicating which bank account is associated with the biometric information together with the biometric information of the applicant. Also good. The bank information acquisition method may be acquired by using, for example, the method described above with reference to FIGS.

  In addition, personal information such as name, date of birth, address, e-mail address (including an SNS (Social Networking Service) account) and the like may be acquired together. This email address can be used as the email address of the payment approval terminal device 2353 to which the payment amount transmission unit 2308 transmits the payment amount.

  In this manner, the biometric information acquired by the event participation intention expression terminal device 2351 or the personal information of the applicant who includes the bank information acquired together with the biometric information is transmitted to the biometric information receiving unit 2301. The biometric information receiving unit 2301 receives the transmitted biometric information, or biometric information and personal information as event participant information, and passes it to the participant / payment account management unit 2303.

  The participant / payment account management unit 2303 manages information related to the event participant and information related to the participant's payment account based on the information received by the biometric information receiving unit 2301. Specifically, for example, the participant / payment account management unit 2303 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 shown in FIG. 2A.

  The payment account inquiry unit 2304 makes an inquiry to the bank server 113 for information on payment accounts of event participants. Specifically, the payment account inquiry unit 2304 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 shown in FIG. 2A and the communication IF 213, for example.

  Based on the biometric information received by the biometric information receiving unit 2301, the payment account inquiry unit 2304 has, for each bank server 113, whether there is a payment account of a person matching the biometric information, and there is a payment account. If there is, a request for obtaining information (account number, etc.) regarding the payment account is made. At this time, the personal information (name, date of birth, address, etc.) of the owner of the biometric information that is received by the biometric information receiving unit 2301 and serves as a clue to the inquiry may be transmitted together.

  Further, the payment account inquiry unit 2304 can also inquire about the balance of the payment account. Specifically, you may ask for information about the actual balance, and for example, send information about the approximate amount of the event participation fee (if the amount has already been finalized) You may make it inquire about whether there exists a balance more than the said amount of money.

  Here, when the bank where the payment account exists is known, an acquisition request is made only to the bank server 113 of the bank. On the other hand, when the bank where the payment account exists is not known, an acquisition request may be made to the bank server 113 of each bank. And you may make it identify which bank it is by the reply from the bank server 113 of each bank.

  The bank server 113 determines whether or not there is biometric information that matches the biometric information received from the payment account inquiry unit 2304. If there is, the payment associated with (associated with) the biometric information. Information related to the account is transmitted to the payment support server 111 inquired. At that time, the bank server 113 may also transmit information regarding the balance of the payment account.

  The payment account information receiving unit 2305 receives from the bank server 113 information about the payment account of the event participant inquired by the payment account inquiry unit 2304 and passes the received information to the participant / payment account management unit 2303. Specifically, the payment account information receiving unit 2305 realizes its function by, for example, the communication IF 213 shown in FIG. 2A.

  The participant / payment account management unit 2303 stores and manages the payment account information received by the payment account information receiving unit 2305 and the participant in association with each other. The participant / payment account management unit 2303 does not need to make an inquiry to the bank server 113 when information about the payment account of the participant has already been acquired and managed. For example, in the case of a regular event or the like, there is a case where information related to a participant's payment account has been acquired in advance, and in that case, it is not necessary to make an inquiry. However, the balance may be inquired each time.

  In this manner, the participant / payment account management unit 2303 officially designates the participant who wishes to participate in the event when the payment account of the applicant is confirmed (or when the balance is confirmed to be a certain amount or more). Register as a participant. At this time, it may be notified to the event participation intention expression terminal device 2351 or another terminal device that it has been officially registered (see, for example, FIG. 9A).

  The expense information receiving unit 2306 receives information related to the event expense transmitted from the event expense input terminal device 2352. Specifically, the information related to the event fee may be information on the total payment amount in the event, for example. Information related to the payer (for example, information on the number of people who participated in the event, age, gender, job title, address, etc., participant attribute information) may be included. Specifically, the cost information receiving unit 2306 realizes its function by, for example, the communication IF 213 illustrated in FIG. 2A.

  The event cost input terminal device 2352 is a terminal device used to input information related to the cost of an event. Specifically, the event cost input terminal device 2352 may be, for example, the recipient terminal 121 shown in FIG. 1, or may be another terminal device. The function as the event cost input terminal device 2352 can be realized by installing a predetermined application in the recipient terminal 121 or other terminal devices.

  Specifically, the event cost input terminal device 2352 displays, for example, a screen as shown in FIG. 11 and inputs amount information related to the event cost, information related to the allocation method, etc. in a predetermined column, for example, from the secretary. , Can accept input of information about the cost of the event.

  In this way, the information regarding the cost of the event acquired by the event participation intention expression terminal device 2351 is transmitted to the cost information receiving unit 2306 of the payment support server 111. The expense information receiving unit 2306 receives information related to the cost of the transmitted event and passes it to the payment amount calculation unit 2307.

  The payment amount calculation unit 2307 calculates the payment amount to be paid by each participant based on the information on the event cost received by the cost information reception unit 2306 and the information on the participant acquired from the participant / payment account management unit 2303. To do. Specifically, the payment amount calculation unit 2307 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 shown in FIG. 2A, for example.

  The payment amount calculation unit 2307 acquires information on the participant from the participant / payment account management unit 2303, and calculates the payment amount of each participant from the information on the event fee. For example, the payment amount calculation unit 2307 calculates a payment amount according to the payer by a predetermined calculation method such as an equal distribution or a slope distribution.

  Further, the payment amount calculation unit 2307 may calculate the payment amount according to the payer by a predetermined calculation method using the attribute information of the participant, for example, a payment amount according to the age. The predetermined calculation method may be arbitrarily set by the recipient (secretary). Then, the payment amount calculation unit 2307 passes the calculated amount (participant payment amount) to the transfer request unit 2309.

  The payment amount transmission unit 2308 transmits information on the payment amount paid by each participant calculated by the payment amount calculation unit 2307 to the specific payment approval terminal device 2353. Specifically, the payment amount transmission unit 2308 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 illustrated in FIG. 2A and the communication IF 213, for example.

  The payment approval terminal device 2353 is a terminal device used by the participant to approve payment of the participation fee for the event. Specifically, the payment approval terminal device 2353 may be, for example, the payer terminal 131 shown in FIG. 1 or the payee terminal 121 shown in FIG. By installing a predetermined application in at least one of the payer terminal 131 and the payee terminal 121, the function as the payment approval terminal device 2353 can be realized.

  The payment approval terminal device 2353 that transmits information related to the payment amount is specified based on the personal information of each participant stored in the participant / payment account management unit 2303. Specifically, the payment approval terminal device 2353 that transmits the payment amount may be specified using information such as an email address (including an SNS account) of the personal information of the participant.

  The payment approval terminal device 2353 receives the payment amount information from the payment amount transmission unit 2308 and then acquires the authentication information of the payer (participant). The accepting unit that accepts the authentication information by the payer terminal 131 is an input device 224 (see FIG. 2B) to which the payer authentication information is input.

  For example, when the payer authentication information is biometric information, the accepting unit of the payer terminal 131 is a scanner or a sensor that reads the authentication information. When the payer authentication information is a password, the accepting unit of the payer terminal 131 is a touch panel or a keyboard. The second acquisition unit 503 acquires the payer authentication information received by the payer terminal 131 from the payer terminal 131.

  Specifically, for example, the payment approval terminal device 2353 may display the screen shown in FIG. 14 and obtain the biological information of the event participant from the event participant. The biometric information of the event participant received from the event participant is authentication information for authenticating the transfer, for example, information obtained due to an active action of the event participant. The biometric information of the event participant may be, for example, fingerprint information of the biometric information of the event participant, or other biometric information such as a palm shape, a face, a blood vessel, a retina, an iris, and a voiceprint.

  When the payer terminal 131 accepts the payer authentication information, for example, payment can be made even after the event is dissolved. In addition, when payment can be completed on the spot of the event venue, it is possible to accept payer authentication information using the recipient terminal 121. In this case, the payee terminal 121 presents the payment amount for each payer using information for identifying the payer from the payer (for example, the biometric information of the payer), and accepts authentication information for each payer. Just do it. Then, the recipient terminal 121 transmits the received authentication information to the payment support server 111. Thereby, even if the payer does not have the payer terminal 131, the payment can be completed at the event venue.

  In this manner, the biological information acquired by the payment approval terminal device 2353 is transmitted to the biological information receiving unit 2302. The biometric information receiving unit 2302 receives the biometric information transmitted from the payment approval terminal device 2353 and passes the received biometric information to the transfer request unit 2309. Specifically, the biological information receiving unit 2302 realizes its function by, for example, the communication IF 213 illustrated in FIG. 2A.

  The transfer request unit 2309 uses the amount calculated by the payment amount calculation unit 2307 or the amount determined in advance as the participation fee sent from the participant / payment account management unit 2303 to the bank server 113. A request is made to transfer money from the payer's payment account to a predetermined transfer account (for example, a manager's account). Specifically, the transfer request unit 2309 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 shown in FIG. 2A and the communication IF 213, for example.

  When the transfer request unit 2309 receives the biometric information received by the biometric information receiving unit 2302, the transfer request unit 2309 acquires information on the payment account of the participant of the biometric information from the participant / payment account management unit 2303. Also, the transfer amount, that is, either the amount to be paid by the participant calculated by the payment amount calculation unit 2307 or the predetermined amount held by the participant / payment account management unit 2303 is acquired. To do. Then, the bank server 113 is requested to transfer the acquired amount to the transfer destination account (for example, the manager's account) with the information related to the acquired payment account and the biometric information.

  When the bank server 113 receives the transfer request from the transfer request unit 2309, the bank server 113 determines whether or not the attached biometric information matches the information stored in advance for verification. The transfer procedure is carried out so that the transferred amount is transferred to the designated bank account. Then, the bank server 113 transmits the implemented transfer result to the payment support server 111. If the biometric information does not match, the fact that the transfer could not be made is notified as a transfer result.

  The transfer result receiving unit 2310 receives, from the bank server 113, the transfer result, that is, information regarding the transfer status from the payment account of each participant who has requested transfer by the transfer request unit 2309. Specifically, the transfer result receiving unit 2310 realizes its function by, for example, the communication IF 213 illustrated in FIG. 2A.

  The payment status storage unit 2311 stores, as the payment status of each participant, information regarding the transfer status from the payment account of each participant received by the transfer result receiving unit 2310. Information on the payment status includes, for example, “payment (transfer) completed”, “payment (transfer) incomplete” due to not performing the operation procedure by the payment approval terminal device 2353, biometric information does not match, or insufficient balance, etc. The situation is such that “payment (transfer) is impossible”. Specifically, the payment status storage unit 2311 realizes its function by causing the CPU 211 to execute a program stored in the memory 212 shown in FIG. 2A, for example.

  The participant / payment account management unit 2303 may execute a prompting process for the participant as necessary based on the payment status stored in the payment status storage unit 2311. The timing of prompting may be as described above.

  Further, the participant / payment account management unit 2303 may create name list information of the event participant based on the stored information on the participant. As shown in FIGS. 11, 12, and 13, the names of the participants are listed in the name list indicated by the name list information, and the list can be displayed on a terminal device such as the recipient terminal 121. Thereby, the participant and the payment amount can be easily grasped (see FIGS. 11 and 12), and the recipient can easily grasp whether or not the payment is completed for each payer. (See FIG. 13).

  FIG. 24 is a flowchart illustrating another example of a series of processes performed by the payment support server 111. In the flowchart of FIG. 24, the payment support server 111 shown in FIG. 23 receives the biological information of the event participants (participants who want to participate) from the event participation intention expression terminal device 2351 (step S2401). And the payment account information of a participant is acquired from the bank server 113 using the biometric information received in step S2401 (step S2402).

  Next, information related to the event cost is received from the event cost input terminal device 2352 (step S2403). Thereafter, the payment amount of each event participant is specified based on the received event fee (step S2404). Then, the specified payment amount is presented to the payment approval terminal device 2353 (step S2405).

  Thereafter, authentication information (biological information) is received from the payment approval terminal device 2353 (step S2406). Then, a transfer request is made to the bank server 113 using the received authentication information (biometric information) (step S2407). Based on the request, the bank server 113 performs a transfer process.

  Next, the information regarding the transfer result is received from the bank server 113 (step S2408). And the information regarding the received transfer result is memorize | stored (step S2409), and a series of processes of the payment assistance server 111 are complete | finished.

  As described above, the payment support server 111 according to the present embodiment receives and receives the participant's biological information from the participation intention expression terminal device used by the event participant to express his / her intention to participate. The payment account of the participant is identified from the biometric information, the payment amount of the participant is identified based on the cost of the event, the identified payment amount is transmitted to the payment approval terminal device, and the payment approval terminal Participant authentication information, such as biometric information, is received from the device, and based on the received authentication information, a transfer process from the specified payment account to a predetermined payee is executed. Collection can be done more easily and efficiently.

  As described above, the payment support server 111 according to the present embodiment can specify the account information associated with the biological information only by receiving the biological information from the payer. Accordingly, the payer can easily register for participation without performing a complicated operation such as inputting a personal identification number. In particular, by using biometric information as fingerprint information, it is possible to register for participation in an event simply and quickly simply by a payer holding his / her finger.

  In addition, the payment support server 111 executes the transfer from the payer's account to the payee's account when the authentication by the payer's authentication information is successful. Thereby, the payment support server 111 can obtain consent from the payer before executing the transfer. Further, since the payer can confirm the payment amount when making the transfer, the payment (authentication) can be rejected in the case of an unreasonable request such as an expensive request.

  Further, even if the payment support server 111 transmits a payment request to a third party's terminal unrelated to the payer due to erroneous transmission or the like, the payment procedure requires authentication information of the payer. Even if the payment procedure is performed using this terminal, it is possible to prevent the transfer.

  Therefore, according to this embodiment, the payer can easily perform the payment procedure with peace of mind. Further, according to the present embodiment, since the transfer from the payer's account to the payee's account is made possible without disclosing the payee's account number or the like to the payer, the payee can conduct the transaction with peace of mind. be able to. In particular, by using the authentication information of the payer as fingerprint information, the transfer can be performed easily and quickly simply by holding the finger of the payer.

  Further, in the present embodiment, the payment support server 111 acquires the payer's biometric information transmitted from the recipient terminal 121. Thereby, the payment support server 111 can specify account information corresponding to the payer's biometric information transmitted from the payee terminal 121. Thus, according to the payment support server 111, for example, at the event venue on the day of the event, the manager (recipient) simply accepts biometric information from a plurality of participants (payers) in order using the recipient terminal 121. Therefore, the payer's biometric information can be obtained more easily.

  Further, in the present embodiment, the payment support server 111 makes a payment request for a predetermined amount to the payer terminal 131. Thereby, the payment support server 111 can prompt the payer to pay. Therefore, according to the payment support server 111, it is possible to reduce the labor involved in the payment communication performed by the manager (recipient).

  Further, in the present embodiment, the payment support server 111 acquires the authentication information transmitted from the payer terminal 131 after making a payment request to the payer terminal 131. Thereby, the payment assistance server 111 can perform transfer, when the authentication using the authentication information transmitted from the payer terminal 131 is successful. Therefore, the payer can complete the payment procedure simply by inputting the authentication information to the payer terminal 131, regardless of the time or place, after the event ends, and the payment procedure can be performed more easily. it can.

  Further, in the present embodiment, the payment support server 111 makes a payment request to the payer terminal 131 again when the transfer is not executed before the predetermined period elapses after making the payment request. As a result, the payment support server 111 can prompt the payer who does not perform the payment procedure to pay again. Therefore, according to the payment support server 111, it is possible to reduce the labor required for the payment promotion performed by the secretary (recipient) and to prevent the participation fee from being missed.

  Further, in the present embodiment, the authentication information of the payer for accepting payment is the same information as the biometric information when the payer performs participation registration. Thereby, according to the payment assistance server 111, even when the terminal (payee terminal 121) which receives biometric information in participation registration differs from the terminal (payer terminal 131) which receives biometric information in consent of payment, it is the same, respectively. Since biometric information can be used, the reliability that a participant and a payer are the same person can be improved, and the safety of transactions can be improved.

  In the present embodiment, the payment support server 111 outputs error information indicating that the account information is not specified to a predetermined terminal (for example, the recipient terminal 121) when the account information corresponding to the biometric information cannot be specified. I decided to let them. Thereby, the payment support server 111 can refuse the participation registration by the payment support method concerning this Embodiment about the payer corresponding to the account information which cannot be specified, and can notify that to a payer. In addition, the payer who is refused the participation registration can pay the participation fee by another method.

  In this embodiment, when the payment support server 111 can identify the account information, the payment support server 111 causes a predetermined terminal (for example, the recipient terminal 121) to output registration completion information indicating that the account information has been identified. It was. Thereby, it is possible to notify the payer corresponding to the identified account information that participation registration for the event has been performed.

  Further, in the present embodiment, the payment support server 111 uses the name information of the payer corresponding to the biometric information when performing participation registration, and uses the created name list information to a predetermined terminal (for example, the recipient terminal 121). To output. Thereby, the recipient (secretary) can grasp the number of participants and the number of participants by browsing the name list information without confirming the attendance of the participants. For this reason, according to the payment support server 111, the labor concerning confirmation of attendance performed by the secretary can be reduced.

  In this embodiment, when payment by the payer is completed, the payment support server 111 adds information indicating that the payment is completed to the directory information and outputs it to a predetermined terminal (for example, the payee terminal 121). I decided to let them. Thereby, for example, the recipient can easily grasp the presence / absence of the deposit by simply checking the name list information without the recipient having to individually confirm the presence / absence of the deposit to his / her account. For this reason, according to the payment support server 111, the labor concerning the confirmation of the presence or absence of the payment which a secretary performs can be reduced.

  Further, in the present embodiment, the payment support server 111 outputs error information to a predetermined terminal (for example, the payee terminal 121) when there is no predetermined amount in the payer's account when performing participation registration. I decided to let them. As a result, the payment support server 111 can prevent registration of payers who are expected to have no payment ability. Therefore, the payment support server 111 can prevent the participation fee from being collected.

  Further, in the present embodiment, the payment support server 111 calculates the payment amount for each payer based on the information on the expense in the event and the information on the payer who participated in the event. Thereby, the payment support server 111 can reduce the labor required for the calculation of the expenses performed by the secretary. Further, the payment support server 111 makes a payment request for the calculated payment amount for each payer to the payer terminal 131 corresponding to each payer. Thereby, the payment support server 111 can reduce the labor concerning the communication of the payment which a secretary performs.

  Further, in the present embodiment, it is possible to accept biometric information for participation registration not only at the recipient terminal 121 but also at the payer terminal 131 (see FIG. 22). Thereby, for example, when the payment support server 111 transmits a guide letter to the payer terminal 131, the payer goes to the event via the payer terminal 131 at a place other than the event venue before the date of the event. Can be registered.

  Further, according to the payment support server 111, even if the payer is registered to participate in the event, even if he / she suddenly leaves the day, the account information and contact information of the payer can be specified. After completion, the payer can be charged a predetermined fee such as a cancellation fee.

  Further, the payment support server 111 sets an upper limit for each payer or an upper limit for the total payment in the event in an event such as a banquet, and when the upper limit is reached, the recipient terminal 121 Alternatively, the payer terminal 131 may be notified of the alarm. Specifically, the payment support server 111 receives information on the amount of money from an event venue such as an izakaya at a predetermined timing (for example, when the participant orders or when a predetermined time elapses). What is necessary is just to determine whether is exceeding the upper limit.

  The payment support server 111 may transmit an alarm to the payee terminal 121 or the payer terminal 131 when the set upper limit is exceeded or the upper limit is approached. Thereby, the participant can suppress the expense concerning an event within the range of an upper limit.

  Moreover, although this embodiment demonstrated the case where the payment assistance apparatus of this invention was implement | achieved in the payment assistance server 111 of the company which provides a payment assistance service, it is not limited to this. For example, by installing an application program according to the payment support program of the present invention in a device such as a smart phone or a tablet PC such as the recipient terminal 121, the payment support device of the present invention can be realized by these devices. Is possible.

  For example, when the payment support apparatus of the present invention is realized by the payee terminal 121, the payee terminal 121 realizing the payment support apparatus receives the biometric information received from the bank account 113 by the payment account inquiry unit 2304. Identify each payer's payment account by making a request to obtain information about whether there is a payment account for the person who matches, or if there is a payment account (such as an account number) Information about the payment account can be obtained.

  Also, for example, the payment support apparatus of the present invention can be realized by a card company server or a bank server 113. For example, when the payment support apparatus of the present invention is realized by the bank server 113, the bank server 113 that realizes the payment support apparatus matches the received biological information with respect to the other bank server 113 by the payment account inquiry unit 2304. Even if the payer's payment account is set up in another financial institution by requesting to obtain information about whether the payer has a payment account, or if there is a payment account, Information regarding the payment account can be obtained by identifying the payment account of the payer.

  Furthermore, when various information can be shared between different industries using a credit card API (Application Programming Interface), the invention is also provided by another server (for example, an insurance company server). It is also possible to realize a payment support apparatus.

  The payment support method described in the present embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation.

  Payment support programs include hard disk, flexible disk, CD (Compact Disc) -ROM (Read Only Memory), MO (Magneto-Optical Disk), DVD (Digital Versatile Disk), USB (Universal Serial Bus) memory, etc. It is stored in a possible storage medium and executed by being read from the storage medium by a computer. Further, the payment support program may be distributed via a network such as the Internet.

  As described above, the payment support device, the payment support method, and the payment support program according to the present invention are useful for the payment support device, the payment support method, and the payment support program that move a predetermined amount between accounts. In particular, the present invention is suitable for a payment support apparatus, a payment support method, and a payment support program for transferring a predetermined amount from an account with account information associated with biometric information.

100 payment support system 111 payment support server 112 settlement information DB
113 Bank server 114 Account information DB
121 Payee terminal 131 Payer terminal 140 Network 211, 221 CPU
212,222 Memory 213,225 Communication IF
223 Output device 224 Input device 210, 220 Bus 501 First acquisition unit 502 Identification unit 503 Second acquisition unit 504 Execution unit 505 Creation unit 506 Request unit 507 Output control unit 508 Third acquisition unit 509 Calculation unit 2301, 2302 Biological information reception Unit 2303 Participant / Payment Account Management Unit 2304 Payment Account Inquiry Unit 2305 Payment Account Information Reception Unit 2306 Cost Information Reception Unit 2307 Payment Amount Calculation Unit 2308 Payment Amount Transmission Unit 2309 Transfer Request Unit 2310 Transfer Result Reception Unit 2311 Payment Status Storage Unit 2351 Event participation intention expression terminal device 2352 Event expense input terminal device 2353 Payment approval terminal device

Claims (10)

First acquisition means for acquiring biometric information of the payer received from the payer;
Specifying means for specifying account information corresponding to the biological information acquired by the first acquiring means;
Second acquisition means for acquiring authentication information received from the payer;
When the authentication using the authentication information acquired by the second acquisition unit is successful, a predetermined amount is transferred from the account indicated by the account information specified by the specifying unit to the account of the recipient specified in advance. Execution means for executing processing to be performed;
A payment support apparatus characterized by comprising:   The payment support apparatus according to claim 1, wherein the first acquisition unit acquires the biological information transmitted from a recipient terminal of the recipient. The account information includes address information of a payer terminal possessed by the payer,
The specifying means specifies a payer terminal indicated by address information corresponding to the biological information acquired by the first acquisition means,
Requesting means for making a payment request for the predetermined amount to the payer terminal specified by the specifying means;
The second acquisition unit acquires the authentication information transmitted from the payer terminal after the payment request is made by the request unit.
The payment support apparatus according to claim 1 or 2, characterized in that   The request means makes the payment request to the payer terminal again when the processing by the execution means is not executed until a predetermined period elapses after making the payment request. 3. The payment support apparatus according to 3.   The payment support apparatus according to claim 1, wherein the authentication information is the same information as the biological information.   6. The apparatus according to claim 1, further comprising output control means for causing a predetermined terminal to output error information indicating that the account information is not specified when the account information is not specified by the specifying means. The payment support apparatus according to one. The account information includes information of the payer's name,
The specifying means specifies information of a payer's name corresponding to the biometric information acquired by the first acquiring means,
The output control means causes a predetermined terminal to output name list information created using information on the payer's name specified by the specifying means.
The payment support apparatus according to claim 6.   The payment support apparatus according to claim 6 or 7, wherein the output control means causes a predetermined terminal to output information indicating that the payment has been completed when the processing by the execution means is executed. Obtaining the payer's biometric information received from the payer,
Identify account information corresponding to the acquired biometric information,
Obtain authentication information accepted from the payer,
When the authentication using the acquired authentication information is successful, a process of transferring a predetermined amount from the account indicated by the specified account information to a pre-designated recipient's account is executed.
A payment support method, characterized in that a process is executed by a computer. Obtaining the payer's biometric information received from the payer,
Identify account information corresponding to the acquired biometric information,
Obtain authentication information accepted from the payer,
When the authentication using the acquired authentication information is successful, a process for transferring a predetermined amount from the account indicated by the specified account information to a pre-designated recipient's account is executed.
A payment support program for causing a computer to execute processing.

Images