JP2023063475A - Server, program, and information processing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To solve the problem in which the remittance of electronic money lacks versatility.

SOLUTION: According to a first aspect, a communication unit of a first server transmits information about a condition for remittance of electronic money to a second server via an API (Application Programming Interface). The communication unit of the first server remits electronic money to a first account identified by an identifier via the API by an instruction of a second account according to the condition for remittance.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2023,JPO&INPIT

Description

The present disclosure relates to technology such as a first server control method.

2. Description of the Related Art In recent years, services that realize electronic money management of a terminal or a user of the terminal, payment by electronic money, etc., are becoming popular, using an application that can be executed on a terminal such as a smartphone. For example, Japanese Laid-Open Patent Publication No. 2002-200000 discloses a technique for settling the purchase price of a product. Further, as a service related to electronic money, a service is provided for realizing electronic money remittance between terminal users (so-called person-to-person remittance). However, this service is merely a service for realizing inter-personal remittance, and has a problem of lacking versatility.

JP-A-2002-176671

According to a first aspect of the present invention, a communication unit of a first server transmits information regarding conditions for remittance of electronic money to a second server via an API (Application Programming Interface); A method of controlling a first server, including remittance of electronic money to a first account identified by an identifier via an API by a communication unit of the server according to instructions of the second account according to remittance conditions. is.

1 is a diagram illustrating an example of a configuration of a communication system according to one aspect of an embodiment; FIG. The figure which shows an example of a structure of the remittance instruction server in one aspect|mode of embodiment. FIG. 4 is a diagram showing an example of functions realized by a control unit of the server according to the embodiment; The figure which shows an example of the information memorize|stored in the memory|storage part of the server which concerns on an Example. The figure which shows an example of the payment application user registration data which concerns on an Example. The figure which shows an example of the remittance service account data which concerns on an Example. The figure which shows an example of the remitter registration data which concerns on an Example. The figure which shows an example of a data structure of the remitter management database which concerns on an Example. The figure which shows an example of a data structure of the user management database which concerns on an Example. The figure which shows an example of the function implement|achieved by the control part of the remittance instruction server which concerns on an Example. The figure which shows an example of the information memorize|stored in the memory|storage part of the remittance instruction server which concerns on an Example. FIG. 4 is a diagram showing an example of functions implemented by a control unit of the terminal according to the embodiment; The figure which shows an example of the information memorize|stored in the memory|storage part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display part of the terminal which concerns on an Example. The figure which shows an example of the display screen displayed on the display of the remittance instruction server which concerns on an Example. The figure which shows an example of the display screen displayed on the display of the remittance instruction server which concerns on an Example. The figure which shows an example of the display screen displayed on the display of the remittance instruction server which concerns on an Example. 4 is a flowchart showing an example of the flow of processing executed by each device according to the embodiment; 4 is a flowchart showing an example of the flow of processing executed by each device according to the embodiment; 4 is a flowchart showing an example of the flow of processing executed by each device according to the embodiment; The figure which shows an example of the remitter registration data which concerns on a modification.

<Compliance with legal matters>
Note that the disclosure provided herein is subject to compliance with the legal requirements of the implementing country required for the practice of this disclosure, such as confidentiality of communications.

An embodiment for implementing a first server control method and the like according to the present disclosure will be described with reference to the drawings.

[System configuration]
FIG. 1 is a diagram showing an example configuration of a communication system 1 according to an embodiment of the present disclosure.
As disclosed in FIG. 1, in the communication system 1, a server 10, terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ), and a remittance instruction server 40 (remittance instruction server 40A) , remittance instruction server 40B, remittance instruction server 40C, . . . ) and bank servers 60 (bank server 60A, bank server 60B, bank server 60C, .

The server 10 provides a predetermined service via the network 30 to the terminal 20 owned by the user. Specifically, for example, the server 10 provides services related to electronic money management and electronic money payment for the terminal 20 or the user of the terminal 20 .
Note that the number of terminals 20 connected to the network 30 is not limited.

The network 30 serves to connect one or more terminals 20 , one or more servers 10 , one or more remittance instruction servers 40 , and one or more bank servers 60 . That is, the network 30 means a communication network that provides a connection path so that the various devices can transmit and receive data after being connected.

One or more portions of network 30 may or may not be wired or wireless networks. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (wireless LAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), part of the Internet, public switched telephone network (Public Part of Switched Telephone Network (PSTN), mobile phone network, ISDN (integrated service digital networks), wireless LAN, LTE (long term evolution), CDMA (code division multiple access), Bluetooth (registered trademark), satellite communication, etc., or a combination of two or more thereof. Network 30 may include one or more networks 30 .

The terminal 20 (terminal 20A, terminal 20B, terminal 20C, ...) (not limited to, but an example of a terminal or an information processing device) is any information processing terminal capable of realizing the functions described in each embodiment. It may be a terminal. Terminals 20 may include, by way of example and not limitation, smart phones, mobile phones (feature phones), computers (including but not limited to desktops, laptops, tablets, etc.), media computer platforms (including but not limited to cable, satellite set top box, digital video recorder), handheld computing device (for example, but not limited to, a PDA (personal digital assistant), email client, etc.), wearable terminal (glasses-type device, watch-type device, etc.), or other type of computer , or including communication platforms. Also, the terminal 20 may be expressed as an information processing terminal.

Terminal 20A, terminal 20B, and terminal 20C basically have the same configuration, so terminal 20 will be described below. The user information is user information associated with an account used by the user in a predetermined service. User information includes, by way of example and not limitation, user's name, user's icon image, user's age, user's gender, user's address, user's hobbies, entered by the user or provided by a given service It may include information associated with the user, such as preferences, user identifiers, etc., and may or may not be any one or combination of these.

The server 10 (not limited to, but an example of a server, an information processing device, an information management device) has a function of providing a predetermined service to the terminal 20 . The server 10 may be any information processing device capable of realizing the functions described in each embodiment. Server 10 includes, by way of example and not limitation, server devices, computers (including but not limited to desktops, laptops, tablets, etc.), media computer platforms (including but not limited to cable, satellite set-top boxes, digital video recorders, etc.). ), handheld computing devices (by way of example and not limitation, PDAs, email clients, etc.), or other types of computers or communication platforms. Also, the server 10 may be expressed as an information processing device. If there is no need to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not be represented as information processing devices.

[Hardware (HW) configuration of each device]
The HW configuration of each device included in the communication system 1 will be described.

(1) HW Configuration of Terminal FIG. 1 shows an example of the HW configuration of the terminal 20 .
The terminal 20 includes a control unit 21 (CPU: central processing unit (central processing unit)), a storage unit 28, a communication I/F 22 (interface), an input/output unit 23, a display unit 24, a microphone 25, a speaker 26, and a camera 27. Prepare. Each component of the HW of terminal 20 is interconnected via bus B, by way of example and not limitation. Note that the HW configuration of the terminal 20 does not necessarily include all the components. By way of example and not limitation, terminal 20 may or may not be configured such that individual components or multiple components such as microphone 25 and camera 27 are detached.

Communication I/F 22 transmits and receives various data via network 30 . Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed. The communication I/F 22 has a function of executing communication with various devices such as the server 10 via the network 30 . Communication I/F 22 transmits various data to various devices such as server 10 according to instructions from control unit 21 . The communication I/F 22 also receives various data transmitted from various devices such as the server 10 and transmits the data to the control unit 21 . Also, the communication I/F 22 may be simply referred to as a communication section. Moreover, when the communication I/F 22 is configured by a physically structured circuit, it may be expressed as a communication circuit.

Input/output unit 23 includes a device for inputting various operations to terminal 20 and a device for outputting processing results processed by terminal 20 . In the input/output unit 23, the input unit and the output unit may be integrated, the input unit and the output unit may be separated, or not.

The input unit is implemented by any one or a combination of all types of devices that can receive input from the user and transmit information related to the input to the control unit 21 . The input unit includes, but is not limited to, hardware keys such as a touch panel, a touch display, and a keyboard, a pointing device such as a mouse, a camera (operation input via moving images), and a microphone (operation input by voice).

The output unit is implemented by any one or a combination of all types of devices capable of outputting processing results processed by the control unit 21 . The output unit includes, as non-limiting examples, a touch panel, a touch display, a speaker (audio output), a lens (as non-limiting examples, 3D (three dimensions) output and hologram output), a printer, and the like.

The display unit 24 is realized by any one or a combination of all kinds of devices capable of displaying according to the display data written to the frame buffer. The display unit 24 includes, as non-limiting examples, a touch panel, a touch display, a monitor (non-limiting examples include a liquid crystal display and OELD (organic electroluminescence display)), a head mounted display (HDM: Head Mounted Display), projection mapping, and a hologram. , including devices capable of displaying images, text information, etc. in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.

When the input/output unit 23 is a touch panel, the input/output unit 23 and the display unit 24 may be arranged to face each other with substantially the same size and shape.

The control unit 21 comprises, by way of example and not limitation, a hardware built-in data processing device comprising physically structured circuitry for carrying out the functions implemented by the code or instructions contained within the program. It is realized by Therefore, the control unit 21 may or may not be expressed as a control circuit.

Control unit 21 includes, by way of example and not limitation, a central processing unit (CPU), microprocessor, processor core, multiprocessor, ASIC (application-specific integrated circuit), FPGA (field programmable gate array).

The storage unit 28 has a function of storing various programs and various data required for the terminal 20 to operate. The storage unit 28 includes various storage media such as HDD (hard disk drive), SSD (solid state drive), flash memory, RAM (random access memory), and ROM (read only memory) as examples and not limitation. Also, the storage unit 28 may or may not be expressed as a memory.

The terminal 20 stores the program P in the storage unit 28 and executes the program P so that the control unit 21 executes processing as each unit included in the control unit 21 . That is, the program P stored in the storage unit 28 causes the terminal 20 to implement each function executed by the control unit 21 . Also, this program P may or may not be expressed as a program module.

A microphone 25 is used to input voice data. The speaker 26 is used for outputting audio data. The camera 27 is used for acquiring moving image data.

(2) Server HW Configuration FIG. 1 shows an example of the HW configuration of the server 10 .
The server 10 includes a control unit 11 (CPU), a storage unit 15, a communication I/F 14 (interface), an input/output unit 12, and a display 13. Each component of the HW of server 10 is interconnected via bus B, by way of example and not limitation. It should be noted that the HW of the server 10 does not have to include all components as the HW configuration of the server 10 . As an example and not a limitation, the HW of the server 10 may or may not be configured such that the display 13 is removed.

The control unit 11 comprises, by way of example and not limitation, a hardware built-in data processing device comprising physically structured circuitry for carrying out the functions implemented by the code or instructions contained within the program. It is realized by

The control unit 11 is typically a central processing unit (CPU), and may or may not be a microprocessor, processor core, multiprocessor, ASIC, or FPGA. In the present disclosure, the controller 11 is not limited to these.

The storage unit 15 has a function of storing various programs and various data necessary for the operation of the server 10 . The storage unit 15 is realized by various storage media such as HDD, SSD, and flash memory. However, in the present disclosure, the storage unit 15 is not limited to these. Also, the storage unit 15 may or may not be expressed as a memory.

Communication I/F 14 transmits and receives various data via network 30 . Communication may be performed by wire or wirelessly, and any communication protocol may be used as long as mutual communication can be performed. The communication I/F 14 has a function of executing communication with various devices such as the terminal 20 via the network 30 . Communication I/F 14 transmits various data to various devices such as terminal 20 according to instructions from control unit 11 . The communication I/F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits the data to the control unit 11 . Also, the communication I/F 14 may be simply referred to as a communication unit. Moreover, when the communication I/F 14 is configured by a physically structured circuit, it may be expressed as a communication circuit.

The input/output unit 12 is realized by a device for inputting various operations to the server 10 . The input/output unit 12 is implemented by any one or a combination of all types of devices that can receive input from a user and transmit information related to the input to the control unit 11 . The input/output unit 12 is implemented by hardware keys typically represented by a keyboard and a pointing device such as a mouse. Note that the input/output unit 12 may or may not include a touch panel, a camera (operation input via a moving image), and a microphone (operation input by voice) as examples without limitation. However, in the present disclosure, the input/output unit 12 is not limited to these.

The display 13 is typically implemented by a monitor (as a non-limiting example, a liquid crystal display or an OELD (organic electroluminescence display)). The display 13 may or may not be a head-mounted display (HDM). These displays 13 may or may not be capable of displaying display data in 3D. In the present disclosure, display 13 is not limited to these.

(3) Configuration of Remittance Instruction Server FIG. 2 shows an example of the HW configuration of the remittance instruction server 40 .
The remittance instruction server 40 includes a control section 41 (CPU), a storage section 45 , a communication I/F 44 (interface), an input/output section 42 and a display 43 . Each component of the HW of the remittance instruction server 40 is interconnected via a bus B as an example and not a limitation. It should be noted that the HW of the remittance instruction server 40 does not necessarily include all the components as the HW configuration of the remittance instruction server 40 . As an example and not a limitation, the HW of the remittance instruction server 40 may or may not be configured to remove the display 43 .

It should be noted that the components, circuits, and the like that constitute each functional unit of the remittance instruction server 40 can be the same as those of the server 10 as an example, not as a limitation, so description thereof will be omitted.

(4) Others The HW configuration of the bank server 60 and the parts and circuits that make up each functional unit can be configured in the same way as the server 10 and the remittance instruction server 40, for example and not limitation, so the description is omitted. do.

The server 10 stores the program P in the storage unit 15 and executes the program P so that the control unit 11 executes processing as each unit included in the control unit 11 . That is, the program P stored in the storage unit 15 causes the server 10 to implement each function executed by the control unit 11 . This program P may or may not be expressed as a program module.
The same is true for other devices.

Each embodiment of the present disclosure will be described as being implemented by the CPU of the terminal 20 and/or the server 10 executing the program P. FIG.
The same is true for other devices.

Note that the control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 is not only a CPU having a control circuit, but also an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)) or the like. Each process may or may not be implemented by a logic circuit (hardware) or a dedicated circuit. Also, these circuits may be realized by one or more integrated circuits, and the plurality of processes shown in each embodiment may or may not be realized by one integrated circuit. LSIs are also called VLSIs, super LSIs, ultra LSIs, etc., depending on the degree of integration. Therefore, the control unit 21 may or may not be expressed as a control circuit.
The same is true for other devices.

In addition, the program P of each embodiment of the present disclosure (as a non-limiting example, a software program, a computer program, or a program module) may be provided in a state stored in a computer-readable storage medium, It does not have to be. The storage medium can store the program P in a "non-transitory tangible medium". Also, the program P may or may not be for realizing part of the functions of each embodiment of the present disclosure. Furthermore, the function of each embodiment of the present disclosure may be implemented in combination with a program P already recorded in a storage medium, that is, a so-called difference file (difference program), or not.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and without limitation, field programmable gate arrays (FPGAs) or application specific ICs (ASICs)), hard Disk drive (HDD), hybrid hard drive (HHD), optical disk, optical disk drive (ODD), magneto-optical disk, magneto-optical drive, floppy diskette, floppy disk drive (FDD), magnetic tape, solid state It may include a drive (SSD), RAM drive, secure digital card or drive, any other suitable storage medium, or any suitable combination of two or more thereof. Storage media may, where appropriate, be volatile, nonvolatile, or a combination of volatile and nonvolatile. Note that the storage medium is not limited to these examples, and any device or medium that can store the program P may be used. Also, the storage medium may or may not be expressed as memory.

The server 10 and/or the terminal 20 can realize the functions of the functional units shown in each embodiment by reading the program P stored in the storage medium and executing the read program P.
The same is true for other devices.

In addition, the program P of the present disclosure may or may not be provided to the server 10 and/or the terminal 20 via any transmission medium (communication network, broadcast wave, etc.) capable of transmitting the program. . As a non-limiting example, the server 10 and/or the terminal 20 implement the functions of the plurality of functional units shown in each embodiment by executing a program P downloaded via the Internet or the like.
The same is true for other devices.

Each embodiment of the present disclosure can also be implemented in the form of a data signal in which the program P is embodied by electronic transmission.
At least part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing configured by one or more computers.
At least part of the processing in the terminal 20 may or may not be performed by the server 10 . In this case, the server 10 may or may not perform at least part of the processing of the functional units of the control unit 21 of the terminal 20 .
At least part of the processing in the server 10 may or may not be performed by the terminal 20 . In this case, the terminal 20 may or may not perform at least part of the processing of the functional units of the control unit 11 of the server 10 .
Unless explicitly mentioned, the configuration of determination in the embodiments of the present disclosure is not essential, and predetermined processing is performed when the determination condition is satisfied, or predetermined processing is performed when the determination condition is not satisfied. may or may not.

Note that the programs of the present disclosure are not limited to, but include script languages such as ActionScript and JavaScript (registered trademark), object-oriented programming languages such as Objective-C and Java (registered trademark), markup languages such as HTML5, and the like. implemented using

<Example>
In recent years, as applications (application software) related to network services, applications such as applications for electronic payments using electronic money (payment applications), applications for electronic money remittances (remittance applications), and some functions of these applications Alternatively, payment applications that integrate all functions are becoming popular, and it is becoming possible for the user of the terminal 20 to receive various services related to electronic money using these applications.

The embodiment described below is a service (hereinafter referred to simply as (referred to as a "remittance service" in this document). Below, a company that provides a remittance service is referred to as a “remittance service company”.

The remittance service provider may or may not be referred to as the payment application provider or the server 10 provider. Also, the remitter's account may be an account associated with the remitter or an account associated with the remittance instruction server 40 . Hereinafter, these are collectively referred to as "sender accounts".

Also, in this embodiment, various services including a remittance service are provided within the payment application, and the server 10 is operated and managed by the remittance service provider. In the following, as an example, the name of the payment application is referred to as "Payment App" and illustrated and described.

In addition, in the present embodiment, corporations and companies that are affiliated with the remittance service provider as corporations and companies that use the remittance service described later are referred to as "remitter", and in FIG. Person S2", . . .
It should be noted that a remitter who performs remittance via API in the remittance service described later may be a sole proprietor or an individual.

Also, as an example and not a limitation, the banks affiliated with the remittance service provider are shown as "bank B1", "bank B2", . . . in FIG.

The remittance service is a service that enables remittance of electronic money to the user of the terminal 20 by a corporation or company affiliated with the remittance service provider, so it is expressed as "corporate remittance service" or "corporate remittance service". You can also Further, since the remittance service is a service in which the remitter gives electronic money to the balance of the user of the terminal 20, it can also be expressed as a "balance giving service."

In this embodiment, the remittance service is defined as a remittance service provider that remits (temporarily remits) electronic money to the terminal 20 or the account of the user of the terminal 20 on behalf of the remitter, and This is explained as a service that settles the amount after the fact and bills the remitter.

In this embodiment, "electronic money" is electronic money distinguished from physical money, and is electronic money owned by the terminal 20 or the user of the terminal 20 managed by the payment application. , means electronic money transferred to the user of terminal 20 (or terminal 20) at the direction of the sender's account via an API associated with the payment application software. Electronic money may or may not be expressed as "electronic money".

Further, the "API" in this embodiment means, as an example and not a limitation, the server 10 so that an external device (remittance instruction server 40 in this embodiment) can use the function of electronic money remittance by the remittance service. It is published by (remittance service provider) and describes the data structure when sending data to the program component, the command method when processing by the program component, and the like. For example, this includes a data structure, an instruction method, and the like for transmitting a command for remittance of electronic money to the server 10 and receiving information on remittance of electronic money from the server 10 .

Uses of the remittance service in this embodiment and purposes of remittance of electronic money from a remitter to a user using the remittance service include, for example, the following.
(1) Payment of remuneration (questionnaire remuneration, etc.)
(2) Payment of affiliate fees (3) Payment of product purchase price (4) Payment of refund amount (5) Payment of campaign winnings, cashback, etc. (6) Payment of transportation expenses and rewards (7) Payment of welfare expenses (8) Payment of sales proceeds such as flea market applications (9) Payment of insurance and insurance refunds (10) Payment of dividends (11) Advance payment of salary (part/all of salary)

<Functional configuration>
(1) Functional Configuration of Server FIG. 3-1 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
The control unit 11 includes, as a main functional unit, a payment application management processing unit 111 as an example and not as a limitation.

The payment application management processing unit 111 has a function of executing payment application management processing for managing data related to the payment application executed on the terminal 20 according to the payment application management processing program 151 stored in the storage unit 15. there is

As an example and not a limitation, the payment application management processing unit 111 transfers electronic money to the terminal 20 specified by the identifier or to the account of the user of the terminal 20 according to the instructions of the remitter's account. and an electronic money management processing unit 1113 for managing electronic money associated with the terminal 20 or the user of the terminal 20 as functional units.

FIG. 3B is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The storage unit 15 stores a server main processing program that is executed as the main processing of the server 10, as well as a payment application management processing program 151 that is executed as a payment application management processing as an example and not a limitation.
The payment application management processing program 151 includes, as a subroutine program, a remittance service management processing program 1511 that is executed as remittance service management processing.

The storage unit 15 also stores payment application user registration data 153 , remittance service account data 154 , remitter registration data 155 , remitter management database 157 , and user management database 159 .

The payment application user registration data 153 is registration data of the terminal 20 or the user of the terminal 20 who uses the service of the payment application, and an example of the data structure is shown in FIG. 3-3.
In the payment application user registration data 153, as a non-limiting example, a user name, a terminal phone number, a terminal mail address, a payment application ID, an authentication password, the presence or absence of an account, and other registration information are associated and stored. be done.

The user name is the name of the user of the terminal 20 who uses the service provided by the payment application, and stores, for example, the name registered when the user of the terminal 20 first uses the payment application.

The terminal phone number is the phone number of the terminal 20 of the user with this user name. For example, the phone number of the terminal 20 registered first when the user of the terminal 20 uses the payment application is stored.
The terminal mail address is the mail address of the terminal 20 of the user with this user name. For example, the mail address of the terminal 20 that is first registered when the user of the terminal 20 uses the payment application is stored.
The terminal phone number and terminal mail address are examples of identification information for identifying the terminal 20 (hereinafter referred to as "terminal identification information").

The payment application ID is an ID that functions as identification information for identifying the terminal 20 or the user of the terminal 20, and is uniquely set by the server 10 for each terminal 20 that uses the payment application or for each user of the terminal 20. ID.

The authentication password is an authentication password that is requested to be input to the terminal 20 in the authentication process executed when using various functions provided as functions of the payment application on the terminal 20 of the user with this user name. For example, a password set by the user is stored.

The presence or absence of an account indicates the presence or absence of an account for the remittance service given to the terminal 20 or the user of the terminal 20 who desires to use the remittance service within the payment application. Hereinafter, the terminal 20 that uses the remittance service or the account given to the user of the terminal 20 is simply referred to as an "account".
The presence or absence of account stores "Yes" if the account has been acquired, and "No" if the account has not been acquired.

In this embodiment, a unique number of a predetermined number of digits (for example, any number of 10 to 12 digits) is generated by the server 10 as an "account number" (an example of an identifier, not a limitation). , the account of the terminal 20 or the user of the terminal 20 is specified (identified) by this account number.

Other registered information is other registered information of the user with this username, and includes, by way of non-limiting example, information such as a user icon image, which is image data of an icon used by the user in a payment application.

The various user information described above may be stored and managed by the server 10 as user information common to other applications that can be provided by the server 10 and the payment application, or may be stored and managed by the server 10 as separate user information. may be stored and managed by .

The remittance service account data 154 is management data for the above account, and an example of the data configuration is shown in FIG. 3-4.
The money transfer service account data 154 stores, by way of example and not limitation, a payment application ID, an account number, and an account type in association with each other.

As the payment application ID, an ID for which "existing" is stored in the payment application user registration data 153 as the existence of an account is stored.

The account number stores a number for specifying (identifying) the account described above.

Account type is the type of this account and includes, by way of example and not limitation, two types: cash account "Cash" and money account "Money".

A cash account is an account set for a user who has not verified whether or not the user of the terminal 20 is the actual user (hereinafter referred to as “identity verification”).
On the other hand, a money account is an account set for a user who has verified his/her identity.

When the account is initially set up, the account type is stored as "cache" because identity verification has not been performed, but after identity verification is performed, the account type becomes "cache" is changed (updated) from to "Money".

Identity verification may be performed, by way of example and not limitation, by the user of terminal 20 registering his or her bank account within a payment application. Specifically, the user's bank account information is input at the terminal 20, the input bank account information is transmitted to a server owned by the bank (bank server 60), and the bank server 60 receives the input from the user. The information is collated with information registered in advance with the bank. When the server 10 acquires the collation result from the bank server 60 and the acquired collation result indicates that the information input by the user and the information registered in the bank in advance are the same, the personal identification is performed. can be said to have been done.

The user's bank account information is input at the terminal 20, the input bank account information is transmitted to the server 10, and the bank account is registered in the server 10 in association with the terminal 20 or the user of the terminal 20. , the user may be configured to verify the identity of the user.

In this embodiment, the difference between a cash account and a money account is an electronic money account of the terminal 20 or the user of the terminal 20 managed by the server 10 (hereinafter referred to as an "electronic money account") based on the function of the payment application. The difference is whether or not some uses of electronic money are restricted.

In this embodiment, there are four uses of the electronic money in the electronic money account (more specifically, the electronic money balance in the electronic money account): "settlement", "remittance", "withdrawal", and "foreign currency exchange". It is explained as having one use. Note that, for example, foreign currency exchange does not have to be provided as a service.

"Settlement" is a function to settle the payment amount with electronic money in an electronic money account when purchasing a product sold at a store or receiving a service provided at a store.

For example, if the user of the terminal 20 purchases a product at a store and the payment amount is "10,000 yen", the terminal 20 requests the server 10 to settle the payment amount. In this case, the server 10 settles the payment by subtracting "10,000 yen" from the balance of the electronic money account of the user of the terminal 20 . The settled amount is then paid to the store by the remittance service provider.

"Remittance" is, for example, a function of sending money to another user's account registered as a "friend" within the payment application. "Friends" refers to a list of each user who has registered another user's account via a two-dimensional code or phone number.

However, unlike the "remittance" in the remittance service of this embodiment, the "remittance" referred to here means that the account of the user of one terminal 20 who is registered as a friend is transferred to another terminal 20 using the payment application. means the transfer of electronic money to a user's account (person-to-person remittance).

It should be noted that it may be configured such that remittance can be made to a user who is not registered as a friend. Specifically, it may be configured so that electronic money can be remitted by specifying it by e-mail, another SNS, a two-dimensional code, or a phone number.

For example, when one user uses the terminal 20 to select another user as a remittance destination and to select "10,000 yen" as the remittance amount, the server 10 "10,000 yen" is subtracted from the balance of the electronic money account of the user, and "10,000 yen" is added to the balance of the electronic money account of the other user.

“Withdrawal” is a bank affiliated with the remittance service provider, and is registered in the server 10 as a bank used by the user of the terminal 20 . is a function to withdraw

A user's electronic money account managed by the server 10 is associated with that user's bank account, and the user of the terminal 20 can use, by way of example and not limitation, the balance of the bank account to make payments to the electronic money account. Electronic money can be charged. For example, when the user uses the terminal 20 to select "10,000 yen" as the electronic money charge amount, the server 10 selects "10,000 yen" from the user's bank account balance. is subtracted, and "10,000 yen" is added to the balance of the user's electronic money account.

Also, the user of the terminal 20 can withdraw electronic money in an electronic money account to a bank account, for example and not limitation.
Here, "withdrawal" means subtracting the balance of the electronic money account and adding the subtracted amount to the balance of the bank account.

For example, when the user uses the terminal 20 to select "10,000 yen" as the amount of electronic money to be withdrawn from the user's electronic money account, the server 10 displays the electronic money account of the user. While subtracting "10,000 yen" from the balance, it communicates with the bank server 60 to add "10,000 yen" to the balance of the user's bank account.

"Foreign currency exchange" is a function of exchanging domestic money into foreign money using the balance of the electronic money account.

Thus, the electronic money in the electronic money account is, by way of example and not limitation, electronic money that allows the user to make payments, transfer money, withdraw money, etc. freely without restrictions within the balance of the electronic money. .

The electronic money in the electronic money account can be withdrawn by the server 10 to the bank account via the bank server 60 (the balance of the electronic money is converted into the balance of the bank account), and the balance of the bank account is transferred to the automatic cash machine. The user of the terminal 20 can withdraw (receive) bills or coins from a teller machine (ATM (Automatic Teller Machine)) or the like.

It should be noted that money managed by a bank account can be expressed as digital money (digital currency) in the sense of money managed by digital information as an example and not as a limitation.

In addition, in this embodiment, cash account users who have not verified their identity can use only the "payment" function among the above functions, and users of money accounts who have verified their identity can use the above functions. You can use all the functions of "settlement", "remittance", "withdrawal", and "foreign currency exchange" among the functions. Note that, for example, the cash account may also be configured to use the remittance function.

Also, instead of restricting the use of all electronic money in the electronic money account managed by the server 10 in association with the payment application, for example, only the electronic money transferred to the user by the remittance service in the payment application may be targeted and its use may be restricted.

The remitter registration data 155 is registration data relating to corporations, companies, etc. that are affiliated with the remittance service provider as a remitter, and an example of the data configuration is shown in FIG. 3-5. Corporations, companies, etc. that want to use the money transfer service for the purposes described above (for example, the purposes of (1) to (11) described above) apply to the money transfer service provider for sender registration, and the sender registration is approved. The registration data regarding the legal entity, company, or the like that has been sent is stored in the remitter registration data 155 .

In the remitter registration data 155, as a non-limiting example, categories, remitter names, remitter contact information, remitter IDs, and other registration information are stored in association with each other.

Classification is the classification of the remitter, such as private corporation/public corporation, for-profit corporation/non-profit corporation, type of company (limited liability company/stock company, etc.), type of shop/industry, etc., registered as a remitter. Information for classifying corporations and enterprises into categories is stored.

The remitter name is the name of the remitter.
The remitter contact information is information on the remitter's contact information, and includes, for example, the remitter's telephone number, e-mail address, web page URL, and other information.

The remitter ID is an ID as identification information given to a remitter who has registered with the server 10 to use the remittance service. A remitter assigned this remitter ID incorporates an API associated with a remittance service distributed/provided by the server 10 into a remittance instruction server 40 operated by the remitter. It is possible to transmit and receive various information related to services to and from the server 10 .

This remitter ID is, for example and not limitation, a channel ID which is an ID necessary for accessing the server 10 from the remittance instruction server 40 through the API, and which is an ID used as an API management unit by the server 10. be able to.

The remitter ID (for example, channel ID) can be said to be different from the account described above, but in the sense that it is information for using the service given to the remittance instruction server 40 or the remitter within the framework of the same remittance service. , the account of the terminal 20 or the user of the terminal 20, as well as the sender ID (channel ID) can be referred to as an "account". The account of the terminal 20 or the user of the terminal 20 is an example of a "first account", and the remitter ID is an example of a "second account".

Also, "remittance" in the remittance service of this embodiment means that the server 10 remits electronic money to an account specified by an account number according to an instruction of the remitter's account.
The remittance of electronic money in the remittance service of this embodiment can also be said to be remittance of electronic money from the remitter (or remittance instruction server 40) to the user of terminal 20 (or terminal 20).

Other registration information is other various registration information about the remitter.

The remitter management database 157 is a database in which management data relating to remitter registered in the remitter registration data 155 is accumulated, and an example of its data structure is shown in FIG. 3-6.
The remitter management database 157 stores remitter management data as management data for each remitter stored in the remitter registration data 155 .

Each remitter management data stores, by way of example and not limitation, a remitter ID, a security deposit, a remittable amount, a unit remittance limit, and remittance history data.

The deposit is the amount of deposit deposited by the remitter to the remittance service provider.
As described above, in the remittance service of this embodiment, the remittance service provider remits electronic money on behalf of the remitter, settles the amount of the remitted electronic money after the fact, and bills the remitter. Then, the remitter repays the remittance service by paying the billed amount of money to the remittance service provider.

Therefore, as a non-limiting example, the remitter should deposit the amount of money that will be remitted over a certain period of time (e.g., a month's period) as a security deposit by bank transfer or the like in advance. deposit and deposit to a remittance service provider. The amount of the security deposit deposited with the remittance service provider in this manner is stored in the security deposit column. If the billed amount is not repaid within the period, it will be recovered from the security deposit.

The security deposit is not limited to manually changing the security deposit column of each remitter management data after confirming the payment. It may be configured such that the security deposit column of the remitter management data is automatically updated.

Hereinafter, the unit cycle for settlement of the billing amount will be referred to as a "settlement cycle". However, "settlement" means calculating the amount (or calculating the amount in detail). Note that the "settlement cycle" may be expressed as a "repayment cycle" in the sense of a unit cycle for repaying the billed amount.

The remittable amount is the amount of electronic money that can be currently remitted from the remitter. It can also be called the latest remittance amount.
This remittable amount is calculated by subtracting the amount already remitted within the settlement period from the security deposit amount, and is stored in the remittable amount column.
Since the remittable amount can also be said to be the amount that can be added to the balance of the electronic money account of the user of the terminal 20, it can also be expressed as "amount that can be added to the balance." In addition, since the remittable amount can be said to be the amount of credit of the remitter, it can also be expressed as "credit amount".

The unit remittance limit is the amount of electronic money that can be remitted at one time from the remitter (remittance limit per remittance). Even if the amount is within the remittance limit, it is not possible to remit an amount larger than the unit remittance limit. For the unit remittance limit, as an example and not as a limitation, an amount set based on the law of the country (for example, "1 million yen" in Japan) can be stored.

The above information on the security deposit, remittance amount, and unit remittance limit amount is information indicating the conditions when the remitter remits electronic money to the user of the terminal 20 . Therefore, the amount information can be said to be a kind of information on conditions for remittance of electronic money (hereinafter referred to as "remittance condition information").

Here, the settlement cycle can be a cycle corresponding to the above fixed period (for example, one month), but it is also possible not to do so.
In the remittance service of this embodiment, since the remittance service provider pays for the remittance amount of electronic money, for example, if the remitter is required to deposit a security deposit for one month, the remittance cycle is set to once a month. Otherwise, if a remittance exceeds the security deposit amount, there is a risk that the remittance service provider will not be able to collect the excess amount.

Therefore, for example, when depositing a security deposit for one month, as a non-limiting example, the settlement cycle is set to be once every half month (twice a month). Then, the upper limit amount of money that is permitted to be remitted within the settlement period can be set as, for example, half the amount of the security deposit (half of the amount of the security deposit). In this case, the above remittance amount can be calculated as "amount of security deposit x 1/2 - amount of remittance completed in a period of half a month".

Of course, the settlement period can be set to a period corresponding to the fixed period. Also, the settlement period can be set to, for example, three or more times a month.
Furthermore, the fixed period for which the security deposit is applied is not limited to one month, and may be, for example, a period of half a month or two months or more.

The remittance history data is data related to the remittance history of the remitter in the remittance service. It is stored in association with the remittance amount, which is the amount.

The user management database 159 is a database that accumulates management data relating to users registered in the payment application user registration data 153, and an example of the data configuration is shown in FIG. 3-7.
User management data is stored in the user management database 159 as management data relating to users registered in the payment application user registration data 153 .

Each user management data stores, as a non-limiting example, a payment application ID, presence or absence of an account, an account number, an account type, an electronic money account balance, and payment history data.

Payment application ID to account type are as described above.
The electronic money account balance is the balance amount of the electronic money account of the user of this payment application ID.

The money receipt history data is the data of the money receipt history to the account of this account number in the money transfer service. A remitter ID, which is the remitter ID, and a received amount, which is the received amount, are stored in association with each other.

(2) Functional Configuration of Remittance Instruction Server FIG. 3-8 is a diagram showing an example of functions realized by the control unit 41 of the remittance instruction server 40 in this embodiment.
The control unit 41 includes, as a main functional unit, a remittance API processing unit 412 as an example and not as a limitation.

The remittance API processing unit 412 transmits and receives information related to electronic money remittance with the server 10 according to the remittance API program 452 stored in the storage unit 45, and performs electronic money remittance by the remittance service. It has a function to execute remittance API processing.

FIG. 3-9 is a diagram showing an example of information stored in the storage unit 45 of the remittance instruction server 40 in this embodiment.
The storage unit 45 stores a remittance instruction server main processing program 451 that is executed as a remittance instruction server main process and a remittance API program 452 that is executed as a remittance API process, for example and not limitation.

The remittance API program 452 is a program for remittance of electronic money via the server 10 based on the API described above.

In addition, the storage unit 45 stores remitter ID data 453 , remitter user data 455 , remittance condition data 457 , and remitter web page database 459 as an example and not limitation.

The remitter ID data 453 is data in which a remitter ID (for example, channel ID) assigned by the server 10 is stored.

The remittance destination user data 455 is data related to a user registered in advance as a user of the terminal 20 who remits electronic money by the remittance service. This includes information such as addresses.

In this embodiment, the remittance destination user data 455 does not store account-related information such as the payment application ID and account number described above, and it is assumed that the sender does not manage such information. explain.

As described above, the terminal 20 or the account of the user of the terminal 20 has two types, namely, a “cash account” and a “money account”. However, since these different types of accounts coexist within the same remittance service, the remitter can remit electronic money using the same mechanism.

Further, in this embodiment, the remitter side does not manage information regarding the type of account of the remittee. Therefore, the remitter does not have to be aware of whether the account type of the terminal 20 to which the electronic money is to be remitted or the account of the user of the terminal 20 is a "cash account" or a "money account". Request 10 to send electronic money.

The remittance condition data 457 is data in which the aforementioned electronic money remittance condition information is stored, and includes, as a non-limiting example, information such as the aforementioned security deposit, remittance amount, and unit remittance limit amount. These pieces of information can be acquired by the remittance instruction server 40 transmitting a remittance condition information request to the server 10 via API and receiving the remittance condition information request from the server 10 as a response.

The remitter web page database 459 is display data for web pages and websites posted on the Internet by the remitter. As a non-limiting example, the data for displaying a web page such as a receipt application page for the user of the terminal 20 who is a customer to input the method of receiving money and information necessary for receiving money and apply for receipt to the remitter. include. Web pages related to the remittance service, such as the remittance application page, are created independently by the remitter.

(3) Functional Configuration of Terminal FIG. 3-10 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
The control unit 21 includes, by way of example and not limitation, a payment application processing unit 211 as a main functional unit.

The payment application processing unit 211 has a function of performing processing based on various functions of the payment application according to the payment application program 287 stored in the storage unit 28 .

FIG. 3-11 is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment.
The storage unit 28 stores a terminal main processing program 281 that is executed as terminal main processing, a payment application program 287 that is executed as payment application processing, and payment application data 289 as an example and not limitation.
Payment application in the text means this payment application program 287 . Note that the payment application may be provided as a single application that does not have the messaging service (MS) function, or may be provided as a composite application that has the MS function.

The payment application data 289 is data for realizing various functions of the payment application, and as a non-limiting example, payment application ID data 2891, which is data of the payment application ID, and account data, which is data of the account of the remittance service. This includes data 2893 and payment history data 2895, which is history data of electronic money received by the remittance service.

<Display screen example>
Remittance of electronic money using the remittance service in this embodiment will be described with reference to an example of a display screen.

(1) Terminal Display Screen FIG. 3-12 is a diagram showing an example of an application screen displayed on the display unit 24 in the payment application executed on the terminal 20. FIG. This application screen is an example of a screen displayed when an operation to acquire an account for a remittance service is performed in the payment application and the account is granted by the server 10 .

On this application screen, characters of "account number" indicating that it is the account number of the remittance service given in the payment application "Payment App" are displayed. number is displayed. In this example, an 11-digit number is assigned as the account number. In this figure, part of the number is indicated by "X" for the sake of convenience, but the part of "X" is actually displayed by the number.

Below the account number, an explanation for explaining how to use the remittance service and the account number, and an image for explaining how to use the remittance service are displayed. This image includes an image showing the user and an image showing the remitter. Arrows connecting these images indicate "Step 1. Request payment from user to remitter", "Step 2. Money received". in the Payment App" is shown. However, the "request for payment" here means requesting the remitter to pay money.

Below that, detailed explanations of the above "Step 1" and "Step 2" are displayed. Specifically, as a detailed explanation of "Step 1", enter the account number and the last four digits of the phone number (mobile phone number in this example) on the remitter's web page (for example, the receipt application page described later). and that some senders may not be required to enter a phone number.
Further, as a detailed explanation of "Step 2", it is indicated that the amount of money deposited is confirmed by "Payment App".

FIGS. 3-13 to 3-16 are examples of web pages created by the remitter, and are diagrams showing examples of receipt application pages for the user of the terminal 20 to apply for receipt of money. The terminal 20 accesses these web pages through a browser or the payment application's built-in browser.
This receipt application page is a receipt application page created by a "shop specializing in buying clothes (○○ shop)", which is an example of a remitter. 3 shows a receipt application page screen displayed on the display unit 24. FIG. Also, here, it is assumed that the user of the terminal 20 has requested the store to purchase the clothes in advance, and the purchase contract has been concluded after an estimate or the like.

On this receipt application page screen, the name of the store is displayed at the top of the screen, and below it, images showing the current progress ("Enter customer information", "Confirm application details", "Select receipt method", " Application completed”) is displayed. FIG. 3-13 shows a screen for confirming the contents of an application corresponding to "confirmation of the contents of an application", in which the application date, receipt number, and purchase price are displayed in the center of the screen. Below that, along with the message "Are you sure about the above content?" A back button is displayed. For example, when the button "select receiving method" is touched on this screen, a receiving method selection screen as shown in FIG. 3-14 is displayed.

On this receipt method selection screen, as a method for the user of the terminal 20 to receive the purchase price, a "bank transfer" button for receiving the purchase price by bank transfer and a "remittance service" of the payment application are displayed. A button for "Payment App" for payment is displayed. For example, when the "Payment App" button is touched on this screen, an account number input screen as shown in FIG. 3-15 is displayed.

This account number input screen is a screen for the user of the terminal 20 to input the account number of the remittance service acquired by the payment application. An account number display field for displaying the account number entered by the numeric keypad is displayed. When the account number input screen is entered and the "Complete" button is touched, an additional authentication information input screen as shown in FIG. 3-16 is displayed.

This additional authentication information input screen is a screen for the user of the terminal 20 to input the additional authentication information. Here, the information of the last four digits of the mobile phone number registered in the server 10 is input as the additional authentication information. It shows an example of what to do. Specifically, in the center of the screen, the message "Please enter the last four digits of your registered mobile phone number." A digit number display field is displayed. When a number is entered on this additional authentication information input screen and the "Complete" button is touched, an application completion screen (not shown) is displayed.

FIG. 3-17 is a diagram showing an example of a notification screen displayed on the display unit 24 of the terminal 20 of the user who applied for receipt of the purchase price on the receipt application screen.
When the application for receipt of the purchase price is completed, the remittance instruction server 40 requests the server 10 to remit the purchase price in electronic money to the account specified by the account number via the API. Then, the server 10 updates the balance of the electronic money account of that account by adding the amount corresponding to the purchased amount. Then, the server 10 notifies the terminal 20 of the account.

Specifically, on the standby screen of the terminal 20, an icon of "Open" for activating the payment application "Payment App" is displayed in association with the message "Payment App has received payment from the remitter." there is

Here, the payment application may include, by way of example and not limitation, the functionality of an instant messaging service (IMS), which is a type of messaging service. In this case, by way of example and not limitation, based on IMS functionality, a money transfer service account (an example of a first account, without limitation), or a payment application account (without limitation, an account associated with the first account). An example of an account) allows the display unit 24 to display a talk room screen for displaying history information related to electronic money.

FIG. 3-18 is a diagram showing an example of the display screen displayed when the "open" icon is touched on the above notification screen.
By way of example and not limitation, when the "Open" icon is touched, a payment application is launched on terminal 20 and a talk room screen is displayed for displaying historical information regarding electronic money. In this talk room screen, an icon image of "Payment App" is displayed at the bottom of the screen, and information on deposit (remittance) from the remitter is displayed in a balloon in association with this icon image.

In this example, the message "The above amount has been deposited by the remitter" is displayed along with the characters "Charge 3,000 yen" indicating the amount deposited (remitted). Further, below that, an operation image showing the characters "confirm details" for confirming the details of the deposit (remittance) is displayed.

(2) Display Screen of Remittance Instruction Server FIGS. 3-19 to 3-21 show an example of a display screen on which information related to the remittance service displayed on the display 43 of the remittance instruction server 40 is displayed. . In the following, by way of example and not limitation, an administration tool screen displayed by an administration tool entitled "Payment App Remitter Management Tool" is illustrated.

FIG. 3-19 is a diagram showing an example of a remittance condition information confirmation screen of the management tool.
This remittance condition information confirmation screen is a screen for confirming the remittance condition information on the remitter side.
When an operation to request remittance condition information is performed from the management tool screen, a remittance condition information request is transmitted from the remittance instruction server 40 to the server 10 by the API. As a response, the remittance instruction server 40 receives a remittance condition information response from the server 10 via the API, and displays a remittance condition information confirmation screen based on the received remittance condition information response.

On this remittance condition information confirmation screen, as an example, not limitation, in the center of the screen, along with the words "remittance condition information", the security deposit, the remittance amount, and the remittance limit per time (unit remittance limit) are displayed. is displayed. Here, "100,000,000 yen" is displayed as the security deposit, "30,000,000 yen" as the remittance amount, and "1,000,000 yen" as the unit remittance limit. It is

For example, as described above, if the remittance cycle is set to once every half a month (twice a month), the remitter deposits "100,000,000 yen" as a security deposit with the remittance service provider. In this case, the amount of money that is permitted to be remitted within this settlement cycle is half the amount of the security deposit, that is, "50,000,000 yen". In this display screen example, since "20,000,000 yen" has already been used for remittance, the remittable amount is "50,000,000 yen - 20,000,000 yen = 30,000,000 yen". A state in which a "circle" is displayed is shown.

FIG. 3-20 is a diagram showing an example of a remittance completion screen of the management tool.
This remittance completion screen is a screen for confirming the remittance completion on the remitter side.
When an operation to request remittance is performed from the management tool screen, a remittance request is transmitted from the remittance instruction server 40 to the server 10 by API. After the remittance is executed by the server 10, the remittance instruction server 40 receives a remittance response regarding remittance completion (successful remittance) from the server 10 through the API, and displays a remittance completion screen based on the received remittance response. do.

In this remittance completion screen, as an example and not limitation, in the center of the screen, along with the characters "remittance completed", the message "remittance completed", the account number specified as the remittance destination, and the remittance instruction server 40 are displayed. A remittance request ID as an order ID issued by and included in a remittance request and transmitted to the server 10, and the remittance amount, which is the amount remitted by the server 10, are displayed in a pop-up format.

FIG. 3-21 is a diagram showing an example of a remittance error screen of the management tool.
This remittance error screen is a screen for confirming a remittance error on the remitter side.
When an operation to request remittance is performed from the management tool screen, a remittance request is transmitted from the remittance instruction server 40 to the server 10 by API. However, if the server 10 is unable to execute the remittance for some reason, the remittance instruction server 40 receives a remittance response regarding a remittance error (remittance failure) from the server 10 via the API, and responds to the received remittance response. Based on this, the remittance error screen is displayed.

Note that the management tool may be configured not to be provided. In this case, all operations related to the remittance service are performed only via API.

In this remittance error screen, as a non-limiting example, in the center of the screen, along with the words "remittance error", there is a message "An error has occurred." and the reason for the failure are displayed in a pop-up format. Here, as the reason for failure of remittance, a state is shown in which the message "The remittance amount is exceeded." indicating that the remittance amount has been exceeded is displayed.

<Processing>
3-22 to 3-24 are flowcharts showing an example of the flow of processing executed by each device in this embodiment.
In these figures, from the left, terminal main processing executed by the control unit 21 of the terminal 20, payment application management processing executed by the control unit 11 of the server 10, remittance instruction server executed by the control unit 41 of the remittance instruction server 40, Each example of the main processing is shown.
Each step of the flowchart is implemented by the CPU of each device reading out the program from the storage unit and executing it.

It should be noted that the flowcharts described below are merely examples of processing procedures for realizing the method of the present disclosure. Therefore, the processing for realizing the technique of the present disclosure is not limited to processing executed according to the flowcharts described below, and it is possible to omit some steps or add other steps.

First, the control unit 21 of the terminal 20 determines whether or not the payment application is being executed in its own terminal 20 (A1). If it is determined that it is being executed (A1: YES), the payment application processing unit 211 determines whether or not an operation to acquire an account for the remittance service has been performed on the input/output unit 23 within the payment application. (A3).

If it is determined that an operation to acquire an account has been performed (A3: Yes), the payment application processing unit 211 transmits account acquisition request information including the payment application ID to the server 10 via the communication I/F 22 (A5).

The payment application management processing unit 111 of the server 10 determines whether the communication I/F 14 has received account acquisition request information from the terminal 20 (B1). If it is determined that it has been received (B1: Yes), the remittance service management processing unit 1111 performs account generation processing (B3).

Specifically, by way of example and not limitation, a random number having a predetermined number of digits is generated according to an algorithm for generating random numbers, and is used as an account number. Then, in the payment application user registration data 153, the existence of an account associated with the payment application ID included in the account acquisition information received from the terminal 20 is updated to "present". Also, the generated account number and account type (“cash account” in the initial setting) are associated with the payment application ID and stored in the remittance service account data 154 .

In B1 and B3, the account number is generated when the account acquisition request is made, but the account numbers of all users may be generated in advance before the acquisition request is made. do not have.

Next, the remittance service management processing unit 1111 transmits the generated account number to the terminal 20 via the communication I/F 14 (B5). When the account number is received from the server 10 via the communication I/F 22 (A7), the payment application processing unit 211 causes the display unit 24 to display the received account number (A9).

The control unit 41 of the remittance instruction server 40 determines whether or not the input/output unit 42 has been operated to request the server 10 to transmit the remittance condition information (C1). If it is determined that the remittance has been made (C1: YES), the remittance API processing unit 412 follows the remittance API program 452 and accesses the server 10 via the API using the channel ID to send the remittance condition information request to the server 10. (C3).

The remittance service management processing unit 1111 determines whether or not a remittance condition information request has been received from the remittance instruction server 40 via the API using the communication I/F 14 (B7). : YES), a remittance condition information transmission propriety determination process for judging propriety of transmission of remittance condition information (pros and cons of transmission) is performed (B9).

Thereafter, the remittance service management processing unit 1111 transmits a remittance condition information response to the remittance instruction server 40 via the API using the communication I/F 14 (B11).

Specifically, if it is determined in B9 that the remittance condition information can be transmitted, the remitter ID corresponding to the channel ID used to access the server 10 is stored in the remitter management database 157. Acquire remittance condition information (guarantee, remittance amount, unit remittance limit) included in the remittance condition data from the remitter management data. As an example, not limitation, a return code (e.g., "0000") indicating transmission OK (success), a response message to the effect that transmission is OK, and acquired remittance condition information (guarantee, remittance amount, unit remittance limit amount) to the remittance instruction server 40 via the API.

On the other hand, if it is determined that the remittance condition information cannot be sent, the remittance condition information response including the return code indicating transmission NG (failure) and the reason for the transmission NG (reason for failure) is sent to the API as an example and not as a limitation. to the remittance instruction server 40 via

Here, the return code indicating transmission NG (failure) can be a code of different numbers depending on the reason for transmission NG (reason for failure). Reasons for not being able to send remittance condition information include, for example, the company or corporation that requested the remittance condition information is not a company or corporation that is officially registered as a remitter, or the company that requested the remittance condition information. A plurality of reasons are assumed, such as that the remittance service is unavailable for some reason, the remittance condition information request has an error (for example, a header information error), and an internal error in the server 10. be. It is preferable to set a return code with a different number in association with each of these multiple reasons, and transmit the remittance condition information response including the return code corresponding to the corresponding reason.

When the remittance API processing unit 412 receives the remittance condition information response from the server 10 via the API by the communication I/F 14 (C5), the remittance API processing unit 412 displays information based on the received remittance condition information response on the display 43 (C7 ).

Specifically, when a remittance condition information response including a return code (for example, "0000") indicating transmission OK (success) is received, the remittance condition information included in this remittance condition information response (security deposit, remittance amount, unit remittance limit) is displayed on the display 43. On the other hand, when receiving a remittance condition information response including a return code indicating transmission NG (failure), the display 43 displays the reason for the transmission NG (failure reason) contained in this remittance condition information response.

After A9, or if it is determined at A1 that the payment application is not running (A1: NO), the control unit 21 instructs the input/output unit 23 to receive It is determined whether or not an operation to access the application page has been performed (A11). If it is determined that the payment has been made (A11: YES), the control unit 21 accesses the remitter's receipt application page through the communication I/F 22 (A13).

The control unit 41 determines whether or not the receipt application page has been accessed from the terminal 20 (C9). It is transmitted to the terminal 20 (C11). In response, the receipt application page is displayed on the display unit 24 of the terminal 20 (A15).

Next, the control unit 21 transmits the input information input by the user of the terminal 20 via the input/output unit 23 on the receipt application page to the remittance instruction server 40 via the communication I/F 22 (A17). Here, the input information includes at least the account number (identifier) received at A7. That is, the account number entered by the user on the receipt application page is transmitted from the terminal 20 to the remittance instruction server 40 .

As described in the example of the display screen, in addition to the account number, information different from the account number, for example, additional authentication information such as the last four digits of the terminal phone number of the user's terminal 20, is included in the input information, It may be transmitted from the terminal 20 to the remittance instruction server 40 .

When input information is received from the terminal 20 via the communication I/F 44 (C13), the remittance API processing unit 412 follows the remittance API program 452 and accesses the server 10 via the API using the channel ID to send a remittance request to the server. 10 (C15). Here, the remittance request includes, as a non-limiting example, the input information received from the terminal 20 (account number is required; additional authentication information is optional) and the amount of money requested to the server 10 for remittance (hereinafter referred to as "remittance request amount”), a currency code, and a remittance request ID (which may be expressed as an order ID) uniquely generated by the remitter side is sent to the server 10 (C15).

The remittance service management processing unit 1111 determines whether or not a remittance request has been received from the remittance instruction server 40 via the API using the communication I/F 14 (B21). ), and a remittance decision process is performed (B23).

The remittance availability determination process will be described in detail.
(A) First, it is determined whether or not remittance is possible based on the remittance condition information.
Specifically, the remitter management data storing the remitter ID corresponding to the channel ID used to access the server 10 is read from the remitter management database 157 . Then, based on the remittance condition information included in the read remitter management data and the requested remittance amount included in the received remittance request, it is determined whether or not electronic money remittance is possible.

(2) Second, determine whether or not remittance is possible based on the account.
First, based on the input information included in the received remittance request, the account to which electronic money is to be remitted is determined. Specifically, when the input information includes only an account number, the remittance service account data 154 is referenced to determine whether or not there is an account number that matches the account number. If there is a matching account number, it is determined that "remittance is possible", and the account specified by the account number is determined as the account to which the electronic money is to be remitted. On the other hand, if there is no matching account number, it is determined that "remittance is not possible".

Also, if the input information includes an account number and additional authentication information, first, the remittance service account data 154 is referenced to determine whether or not there is an account number that matches the account number. If a matching account number exists, identify the payment application ID stored in association with that account number. Subsequently, referring to the payment application user registration data 153, it is determined whether or not the additional authentication information matches based on the information stored in association with the specified payment application ID. For example, if the additional authentication information is the last four digits of the terminal phone number, whether or not the number matches the last four digits of the terminal phone number stored in association with the specified payment application ID determine whether If they match, it is determined that "remittance is possible", and the account specified by the account number is determined as the account to which the electronic money is to be remitted. This is done because there is a possibility that the user may enter incorrect information on the remitter's receipt application page, resulting in problems such as remittance of electronic money to another account. .

On the other hand, if there is a matching account number but the additional authentication information does not match, it is determined that "remittance is not possible". This is because the user may have mistyped the additional authentication information, or the user may have mistyped the account number, which coincidentally matches another user's account number.

Also, if there is no matching account number, but there is matching additional authentication information in the payment application user registration data 153, it is determined that "remittance is not possible". This is because the user may have entered an incorrect account number, or a user who has not obtained an account for the remittance service may have applied for receipt.

Also, if neither the matching account number nor the matching additional authentication information exists, it is determined that "remittance is not possible". This is because it is possible that the user incorrectly entered both pieces of information, but there is a high possibility that a third party applied for receipt through mischief or the like.

If it is determined in the remittance availability determination process that remittance is possible (B25: YES), the remittance service management processing unit 1111 performs remittance process (B27). Specifically, the user management data in which the account number of the account determined in B23 is stored is read from the user management database 159. FIG. Then, the electronic money account balance of the read user management data is updated by adding the remittance request amount included in the received remittance request as the remittance amount. Also, the payment history data of the user management data is updated.

Thereafter, the remittance service management processing unit 1111 updates the remitter management data read in B23 (B29). Specifically, the remittance amount is subtracted from the remittance available amount in the remittance condition data and updated. Also, the remittance history data of the remitter management data is updated.

Next, the remittance service management processing unit 1111 transmits payment notification information for notifying that payment has been made to the account specified by the account number to the terminal 20 via the communication I/F 14 (B31).

When the communication I/F 22 receives payment notification information from the server 10 (A21), the control unit 21 determines whether or not the payment application is being executed (A23). If it is determined that the payment application is not being executed (A23: NO), the control unit 21 performs payment push notification processing (A25). Specifically, a payment push notification for notifying that payment has been received is displayed on the terminal main screen of the display unit 24 .

Thereafter, the control unit 21 determines whether or not an operation has been performed on the payment push notification for confirming the payment details (A27), and if it is determined that the operation has been performed (A27: YES), the payment application is started. (A29). Then, the payment application processing unit 211 causes the display unit 24 to display a talk room screen including received money information and the like (A31).

On the other hand, if it is determined in A23 that the payment application is being executed (A23: YES), the payment application processing unit 211 performs in-app payment notification processing (A33). Specifically, a payment notification for notifying that payment has been received is displayed in a predetermined area of the payment application screen of the display unit 24 .

After that, the payment application processing unit 211 determines whether or not an operation has been performed to confirm the details of the payment (A35), and if it determines that the operation has been performed (A35: YES), the process proceeds to A31.

Here, in A31, as an example and not a limitation, the display unit 24 can display a talk room screen such as that illustrated in FIG. 3-18. However, in this embodiment, since the remittance service is provided within the payment application, it can be said that this talk room screen is displayed on the display unit 24 based on the payment application account (for example, payment application ID). It can also be said that the information is displayed on the display unit 24 based on a service account (for example, an account specified by an account number).

After B31, or when it is determined that remittance is not possible in the remittance permission determination process (B25: NO), the remittance service management processing unit 1111 sends a remittance response to the communication I/F 22 via the API. It is transmitted to the server 40 (B33).

Specifically, when the remittance is successful, as a non-limiting example, a return code (e.g., "0000") indicating remittance OK (success), a response message to the effect that remittance is OK, and a unique message on the server 10 side A remittance response including the generated transaction ID is sent to the remittance instruction server 40 via the API.

On the other hand, if the remittance fails, the return code indicating remittance NG (failure), the reason for remittance NG (reason for failure of remittance), and the transaction ID uniquely generated by the server 10 are provided as an example, not as a limitation. The remittance response including the remittance request is transmitted to the remittance instruction server 40 via the API.

Here, the return code indicating remittance NG (failure) can be a code of different numbers depending on the reason for remittance NG (reason for failure). Reasons why the remittance is not possible include, for example, the input information (at least one of the remittee's account number and additional authentication information) is incorrect, the remittee's user's status, balance limit, etc. A plurality of reasons can be assumed, such as that the remittance cannot be made for some reason, that the requested remittance amount information is in error, or that the remittance requested amount exceeds the remittable amount. It is preferable to set a return code with a different number in association with each of these multiple reasons, and transmit the remittance condition information response including the return code corresponding to the corresponding reason.

After A31 or when it is determined not to display at A35 (A35: NO), the control unit 21 determines whether or not the payment application is being executed (A41). Then, if it is determined that it is being executed (A41: YES), the payment application processing unit 211 determines whether or not the "withdrawal" function has been selected (A43). In this case, the user of the terminal 20 taps the icon of "smartphone transaction" displayed on the display screen of the ATM as an example and not as a limitation.

If it is determined that the "withdrawal" function has been selected (A43: YES), the payment application processing unit 211 displays a screen (not shown) for selecting a bank/bank account and a screen (not shown) for inputting a withdrawal amount. A screen (not shown) is displayed on the display unit 24 . Then, the information input on these screens is transmitted to the server 10 through the communication I/F 22 as the withdrawal information (A45).

When the payment information is received from the terminal 20 by the communication I/F 14 (B41), the electronic money management processing unit 1113 of the server 10 performs a payment propriety determination process (B43). Specifically, as an example and not as a limitation, it is determined whether or not the account type of the terminal 20 that is the source of the withdrawal information or the account of the user of the terminal 20 is "money account". Also, it is determined whether or not the electronic money account balance of this terminal 20 or the user of the terminal 20 is larger than the withdrawal amount. Then, when these conditions are satisfied, it is determined that "withdrawal is possible".

If it is determined that withdrawal is possible (B45: YES), the electronic money management processing unit 1113 performs withdrawal processing (B47). Specifically, it communicates with the bank server 60 to subtract the withdrawal amount from the electronic money account and add it to the bank account balance. In addition, the electronic money management processing unit 1113 transmits information necessary for a cash withdrawal transaction (hereinafter referred to as “transaction information”) to the bank server 60 via the communication I/F 14 as an example and not limitation. . In this case, the bank server 60 communicates with the ATM and causes, by way of example and not limitation, a code image for a cash withdrawal transaction (hereinafter referred to as a "transaction code image") to be displayed on the ATM display.

Here, the transaction code image can be, by way of example and not limitation, an image of a two-dimensional code (eg, QR code (registered trademark)). Further, the transaction code image may include, for example and not limitation, the above transaction information as transaction code information, or information for communicating with the server 10 to acquire transaction information. may be included as transaction code information.

After A45, the payment application processing unit 211 activates a code reader provided as a function of the payment application (hereinafter referred to as "application code reader") (A47).

When the application code reader reads the transaction code image displayed on the ATM display (A49: YES), the payment application processing unit 211 decodes the transaction code information contained in the read transaction code image. (A51).

After that, the payment application processing unit 211 displays information necessary for withdrawing cash (for example, a company number or an authentication number for identifying a remittance service company) to the display unit 24 based on the acquired transaction code information. (A53). In this case, the user of the terminal 20 inputs the information displayed on the display unit 24 into the ATM to withdraw cash from the bank account.

When the transaction information is encoded in the transaction code image, the information necessary for withdrawing cash may be displayed on the display unit 24 based on the transaction information directly obtained by decoding. Further, when information for communicating with the server 10 to acquire transaction information is encoded in the transaction code image, processing for acquiring transaction information from the server 10 is executed based on the information acquired by decoding. Then, based on the transaction information acquired by this process, the information necessary for withdrawing cash may be displayed on the display unit 24 .

Here, the processing for "withdrawing" the electronic money received from the remitter is shown. In addition, the electronic money received from the remitter can be used as electronic money for "settlement", "remittance", and "foreign currency exchange". A detailed description of these processes is omitted.

After A53, the control unit 21 determines whether or not to end the process (A59), and if it determines to continue the process (A59: NO), returns the process to A1. On the other hand, if it is determined to end the processing (A59: YES), the terminal main processing ends.

After B47, the payment application management processing unit 111 determines whether or not to end the process (B59), and if it determines to continue the process (B59: NO), returns the process to B1. On the other hand, if it is determined to end the processing (B59: YES), the payment application management processing is ended.

After C23, the control unit 41 determines whether or not to end the process (C59), and if it determines to continue the process (C59: NO), returns the process to C1. On the other hand, if it is determined to end the process (C59: YES), the remittance instruction server main process ends.

<Effect of Example>
In this embodiment, the server 10 (not limited, but an example of a first server) uses a communication I/F 14 (not limited, but an example of a communication unit of a first server) to communicate via an API (Application Programming Interface). Then, remittance condition information (not limited, but an example of information regarding conditions for electronic money remittance) is sent to the remittance instruction server 40 (not limited, but an example of a second server). In addition, the server 10 transfers the remitter's account to the account (not limited but one example of the first account) specified by the account number (not limited but one example of the identifier) through the API via the communication I/F 14. (for example, a channel ID) (not limited to, but an example of a second account), an arrangement is shown in which electronic money is remitted according to remittance conditions.
As an example of the effects obtained by such a configuration, the first server can notify the second server of information regarding conditions for remittance of electronic money via the API. Also, the first server can remit electronic money to the first account identified by the identifier via the API according to the instructions of the second account according to the remittance conditions.

For example, the first account can be an account of a terminal or a user of a terminal that uses a service provided by an operator that operates the first server. Also, for example, the second server may be a server operated by a company, corporation, or the like, and the second account may be the second server or an account of the company, corporation, or the like. By doing so, it is possible to realize electronic money remittance from companies, corporations, etc. to the terminal user via the API, and to increase the versatility of electronic money remittance.

Also, in this embodiment, the conditions for remittance of electronic money are the remittable amount (not limited to, remittable electronic An example of conditions regarding the amount of money) is shown.
As an example of the effect obtained by such a configuration, it is possible to transfer electronic money to a first account via an API according to a condition regarding the amount of electronic money that can be transferred, according to an instruction from a second account.

Moreover, this embodiment shows a configuration in which the server 10 notifies the account specified by the account number through the communication I/F 14 when electronic money is remitted.
As an example of the effect obtained by such a configuration, since the first account is notified that the electronic money has been transferred, the user of the first account can know that the electronic money has been transferred, which is convenient. is.

Also, in this embodiment, the server 10 receives additional authentication information (not limited, but an example of information different from the identifier) from the remittance instruction server 40 via the API via the communication I/F 14 . Then, the server 10 shows a configuration for remittance of electronic money to an account specified by the account number and the additional authentication information via the API using the communication I/F 14 .
As an example of the effect obtained by such a configuration, by specifying the first account to which the electronic money is to be remitted not only by the identifier but also by information different from the identifier received from the second server via the API, For example, it is possible to prevent a situation in which electronic money is remitted to an account different from the account to which the remittance is scheduled.

Also, in this embodiment, the server 10 stores, in the storage unit 15, the balance of the electronic money account of the account specified by the account number. ) are associated and stored.
As an example of the effect obtained by such a configuration, the amount of electronic money to be transferred is stored in association with the balance of the electronic money account of the first account in the storage unit of the first server. can be managed by the first server.

In addition, in this embodiment, the server 10 includes a cash account (not a limitation, but an example of a restricted account in which part of the use of electronic money is restricted) that can only be used for settlement with electronic money, and a settlement and remittance with electronic money. , withdrawal, and foreign currency exchange are possible (not limited, but an example of an unrestricted account in which some uses of electronic money are not restricted), and a configuration in which accounts are managed by one of these accounts.
As an example of the effect obtained by such a configuration, the first account can be managed, electronic money can be managed with an appropriate account according to the use of the electronic money.

In addition, in this embodiment, the server 10 stores the amount of electronic money to be transferred in association with the balance of the electronic money account of either the cash account or the money account. can be associated appropriately depending on the account type.

Further, in this embodiment, based on communication with the remittance instruction server 40 via API, a notification (notification information) indicating that electronic money has been remitted to an account specified by an account number according to instructions of the remitter's account is sent. , the terminal 20 receives from the server 10 via the communication I/F 22 . Then, the terminal 20 shows a configuration in which a display based on the received notification is displayed on the display unit 24 .
As an example of the effect obtained by such a configuration, electronic money is transferred to a first account identified by an identifier based on communication with a second server via an API, according to instructions from the second account. can be notified to the user of the terminal.

Also, the present embodiment is intended for the terminal 20 to be connected to a money transfer service account (one example of a first account, without limitation) or a payment application account (one example of an account associated with the first account, without limitation). shows a configuration in which payment information and the like are displayed on the talk room screen of the payment application executed on the terminal 20 (not limited, but an example of the display area of the messaging application).
As an example of the effect obtained by such a configuration, the display based on the information received from the first server indicating that the electronic money has been transferred is displayed by the first account or an account associated with the first account. Since this is done in the display area of the messaging application executed on the terminal, it is possible to inform the user of the terminal that the electronic money has been remitted in an easy-to-understand manner.

In addition, the present embodiment provides that the terminal 20 controls an application code reader (an example, but not a limitation, of a terminal code reader) to display a transactional code at an ATM (an example, but not a limitation, of a cash dispenser). Code image (example, without limitation, of a code image displayed on a cash machine for withdrawing cash from a bank account based on the balance of electronic money associated with a first account managed by a first server) ). Then, the terminal 20 acquires information necessary for withdrawing cash from the server 10 ( An example of a process for withdrawing cash from an automatic teller machine) and a process of displaying information necessary for withdrawing cash on the display unit 24 (not limited to a process for withdrawing cash from an automatic teller machine) (an example of the processing of ) is shown.
As an example of the effect obtained by such a configuration, the user of the terminal can easily withdraw the amount of the transferred electronic money from his/her own bank account.

Further, in this embodiment, the remittance instruction server 40 receives the remittance condition information for electronic money from the server 10 via the API via the communication I/F 44 . Then, the remittance instruction server 40 uses the communication I/F 44 to send remittance request information for remittance of electronic money according to the remittance conditions to the account specified by the account number according to the instruction of the remitter's account via the API. 10 shows the configuration for sending to .
As an example of the effect obtained by such a configuration, the second server can acquire information regarding conditions for remittance of electronic money from the first server via the API. In addition, the second server transmits to the first server, via the API, information for remittance of electronic money to the first account identified by the identifier according to the instruction of the second account according to the remittance conditions. By doing so, electronic money can be remitted.

Also, in this embodiment, the conditions for remittance of electronic money are the remittable amount (not limited to, remittable electronic An example of conditions regarding the amount of money) is shown.
As an example of the effect obtained by such a configuration, it is possible to transfer electronic money to a first account via an API according to a condition regarding the amount of electronic money that can be transferred, according to an instruction from a second account.

Also, in this embodiment, the remittance instruction server 40 displays a remittance condition information confirmation screen (not a limitation, but an example of a display based on information on remittance conditions) on the display 43 .
As an example of the effect obtained by such a configuration, it is possible to inform the administrator of the second server or the like of the information regarding the conditions for remittance of electronic money by display.

<Modification>
Modifications of the above embodiment will be described below.

<Modification (1)>
In the above embodiment, money managed in the account on the server 10 is defined as "electronic money", and money managed in the account on the bank server 60 (bank) is defined as "digital currency". distinguished. However, without distinguishing between the two, both may be referred to as "electronic money" or both may be referred to as "digital currency".

Also, as "electronic money" or "digital currency", legal tender or virtual currency may be used. Also, "electronic money" or "digital currency" may or may not include cryptocurrency. Virtual currency may or may not include physical money such as coupons.

<Modification (2)>
The configuration of the communication system 1 described in the above embodiment can be changed as appropriate. For example, between the remitter and the remittance service provider, a money transfer agency acting on behalf of the money transfer is interposed, and the money transfer agency operates and manages the money transfer in addition to the server 10 and the remittance instruction server 40. A server may be provided.

<Modification (3)>
The remittance destination terminal 20 or the account of the user of the terminal 20 to which the electronic money is to be remitted may or may not be limited according to the instruction of the remitter's account. In this case, as an example and not as a limitation, the setting can be made on the server 10 side according to the remitter's intention.

FIG. 3-25 is a diagram showing an example of the data configuration of the remitter registration data 155B stored in the storage unit 15 of the server 10 in this case. Similar to the remitter registration data 155 (see FIG. 3-5), the remitter registration data 155B is data for managing remitter registration information in the server 10, but the data configuration is partially different.

Specifically, in the remitter registration data 155B, in addition to classification, remitter name, remitter contact information, remitter ID, and other registration information, remittance destination limitation setting is stored in association with the remitter registration data 155B.

The remittance destination limitation setting is a setting regarding whether or not to limit (narrow down) the account type of the remittance destination of electronic money. For example, for a sender whose remittance destination limitation setting is set to "ON", the account type of the remittance destination of electronic money is limited to "money account". In other words, a sender whose remittance destination limitation setting is set to "ON" is permitted to send electronic money to a user whose account type is "money account", but whose account type is "cash account". Remittance of electronic money to the user is prohibited.

In this case, the control unit 11 of the server 10 refers to the remitter registration data 155B in the remittance approval/disapproval determination process (B23) of the payment application management process (FIGS. 3-22 to 3-24) as an example and not a limitation. , determines the limited remittance destination setting stored in association with the remitter ID of the remittance instruction server 40 which is the source of the remittance request.

When the remittance destination limitation setting is "OFF", the control unit 11 determines that "remittance is possible". On the other hand, when the remittance destination limitation setting is “ON”, the control unit 11 refers to the remittance service account data 154 and refers to the account number (e.g., remittance of electronic money) included in the input information of the remittance request received from the remittance instruction server 40 The account type stored in association with the account number of the previous account) is determined.

When the account type associated and stored is "money", the control unit 11 determines that "remittance is possible". On the other hand, when the account type is "cash", the control unit 11 determines that "remittance is not possible".

In this modification, the server 10 determines whether or not the account of the remitter (not a limitation, but an example of a second account) is an account set to limit (narrow down) the remittance destinations of electronic money. do. If the account is set to limit the remittance destination of electronic money, the server 10 permits the remittance of electronic money based on the instruction of the remitter's account to the money account, and Prohibit the transfer of electronic money based on account instructions.
As an example of the effect obtained by such a configuration, if there are laws and regulations that require the identity verification of the remittee when remittance for a specific remittance purpose, By prohibiting the remittance of electronic money based on the law, it is possible to comply with laws and regulations.

<Modification (4)>
In the above-described embodiment, the remittance service is operated by depositing a security deposit from the remitter to the remittance service provider in advance, and the remittance service provider settles the amount of the remitted electronic money after the fact and charges the remitter for repayment. Although it is assumed that the service is provided, the service is not limited to this.

As an example and not a limitation, money for remittance is deposited in advance by a remitter to a remittance service operator, and the remittance service operator remits electronic money within the balance of the pre-deposited money. It can also be a service that

In this case, the server 10 may determine whether or not the requested remittance amount is within the balance before executing the remittance, and execute the remittance if it is within the balance. Further, in this case, the server 10 may transmit the current balance to the remittance instruction server 40 and notify the remitter of the balance before executing the remittance.

Also, as an example and not a limitation, the funds transfer balance is stored and managed by the remittance instruction server 40, and the remittance instruction server 40 remits the limit amount of electronic money from the funds transfer balance via the server 10. A system that enables

<Modification (5)>
In the above embodiment, the account of the terminal 20 or the user of the terminal 20 is classified into a "cash account" and a "money account", but these may not be distinguished. That is, all users may be treated as money accounts with identity verification required for all users, or all users may be treated as cash accounts without identity verification.

In the above embodiment, the terminal 20 or the user of the terminal 20 owns only one of the "cash account" and "money account". and a "money account" may be owned by the terminal 20 or the user of the terminal 20.

Also, the amount of electronic money that can be remitted from a remitter may be restricted according to the type of account. For example, the upper limit of electronic money remittance to the "cash account" may be set to "100,000 yen", and the upper limit of electronic money remittance to the "money account" may be set to "1,000,000 yen". .

<Modification (6)>
In the above-described embodiment, the technique of remittance (pay-as-you-go) in which electronic money is remitted every time the user of the terminal 20 applies for receipt on the receipt application page has been described, but the method is not limited to this.

Specifically, for users who make remittances at regular timings, such as salary payments, the remittance instruction server 40 registers information such as the date of remittance and the amount of remittance in the server 10 in advance. to Then, the server 10 may remit electronic money at regular timing based on pre-registered information. In other words, a periodic remittance (periodic payment) technique may be applied.

<Modification (7)>
In the above embodiment, the additional authentication information is illustrated as the last four digits of the terminal telephone number, but the additional authentication information is not limited to this. Any information related to the terminal 20 or the user of the terminal 20 that can be obtained and grasped by the server 10 and that is different from the account number may be used as the additional authentication information.

For example, the user of the terminal 20 is made to input the answer to the secret question, and the information is registered in the server 10 . Then, on the receipt application page of the remitter, the sender is prompted to enter the answer to the secret question as additional authentication information, and the server 10 receives the answer to the secret question received from the remittance instruction server 40 and the registered secret question. Additional authentication may be performed based on the answers to the above.

Alternatively, when a predetermined button is pressed after accessing the remitter's web page, the payment application is activated on the terminal 20, and a token acquired from the activated payment application is transmitted to the server 10 via the remitter, thereby It may be configured to identify the user.

<Modification (8)>
The remittance condition information described in the above embodiment is merely an example, and is not limited to this. For example, the amount of electronic money that the remitter can send in a certain period of time (1 day, 3 days, 1 week, etc.), e.g. The server 10 or the remittance instruction server 40 may set information on the remittance limit amount for a certain period of time, such as the remittance limit amount for a certain period, by including it in the remittance condition information. Then, the information of the remittance limit amount for a certain period of time is displayed on the remittance instruction server 40 or server 10 to notify the information, or the process of permitting remittance within the range not exceeding the remittance amount limit for a certain period of time (or prohibiting remittance exceeding the remittance limit amount) may be performed on the remittance instruction server 40 side or the server 10 side.

<Modification (9)>
In the above embodiment, the server 10 may have the function of providing messaging services such as the aforementioned IMS and the function of providing various services through payment applications. In this case, by way of example and not by way of limitation, within the IMS application, a payment application service or money transfer service may be provided.

In addition, a server having a function of providing a messaging service and a server having a function of providing various services by a payment application are separated, and two servers, a messaging service server and a payment service server, are configured. may

1 communication system 10 server 20 terminal 30 network 40 remittance instruction server 60 bank server

Claims (1)

transmitting information regarding conditions for remittance of electronic money to a second server via an API (Application Programming Interface) by a communication unit of the first server;
remittance of electronic money to a first account identified by an identifier via an API by the communication unit of the first server according to the instructions of the second account according to the remittance conditions;
A method of controlling the first server, comprising:

Images