JP7364311B2 - Programs, information processing methods, terminals - Google Patents

Description

The present disclosure relates to an authentication method, a program, and a terminal.

2. Description of the Related Art Recently, services for electronic payment using terminals such as mobile phones have become popular. For example, Patent Document 1 discloses a method of performing authentication by comparing password data input into a terminal with password data stored in advance in the terminal. However, there have been cases where the authentication of the terminal user in payment using electronic money is not easy to use.

Japanese Patent Application Publication No. 2002-176671

According to the first aspect of the present invention, display processing related to execution of authentication for a user of the terminal is performed in the display area of the terminal, and information regarding payment using electronic money is received by the communication unit of the terminal based on the authentication for the user of the terminal. The authentication method using a terminal is to acquire information different from the authentication information used to authenticate the user of the terminal, and to use the electronic authentication method based on the information different from the authentication information without displaying information related to the execution of authentication. and receiving information regarding the monetary payment by the communication unit.
According to the second aspect of the present invention, display processing related to execution of authentication for the user of the terminal is performed in the display area of the terminal, and information regarding payment using electronic money is received by the communication unit of the terminal based on the authentication for the user of the terminal. The program to be executed by the computer of the terminal is to acquire information different from the authentication information used to authenticate the user of the terminal, and to perform display processing related to the execution of authentication based on the information different from the authentication information. and receiving information regarding payments using electronic money by the communication unit.
According to the third aspect of the present invention, display processing related to execution of authentication for the user of the terminal is performed in the display area of the terminal, and information regarding payment using electronic money is received by the communication unit of the terminal based on the authentication for the user of the terminal. The terminal has a control unit that controls the terminal to obtain information different from the authentication information for authenticating the user of the terminal, and a control unit that performs control to obtain information different from the authentication information for authenticating the user of the terminal, and does not perform display processing related to the execution of authentication based on the information different from the authentication information. and a communication unit that receives information regarding payments using electronic money.
According to the fourth aspect of the present invention, a terminal authentication method for authenticating a terminal user includes acquiring information by the terminal, and performing processing related to authentication of the terminal user when the information does not satisfy a condition. , the information regarding electronic money is received by the communication unit of the terminal based on the authentication of the user of the terminal, and if the information satisfies the conditions, the information regarding the electronic money is sent to the communication unit of the terminal without executing the process related to the authentication of the user of the terminal. including receiving by.
According to a fifth aspect of the present invention, there is provided a program to be executed by a computer of a terminal that authenticates a user of the terminal, and the program includes the steps of acquiring information by the terminal and, when the information does not satisfy conditions, the user of the terminal If the communication unit of the terminal receives information regarding electronic money based on the authentication of the user of the terminal, and the information satisfies the conditions, the processing related to authentication of the user of the terminal is not executed and information regarding electronic money is received based on the authentication of the user of the terminal. and receiving information regarding the terminal by a communication unit of the terminal.
According to the sixth aspect of the present invention, a program executed by a terminal that performs processing related to payment using electronic money transmits first information regarding a location, which is different from authentication information for authenticating a user of the terminal, to a control unit of the terminal. and performing display processing related to execution of authentication for a user of the terminal by the control unit based on the first information and the acquisition of code information for making a payment using electronic money, or the reading of the code information. is executed by the terminal, and if the first information includes information regarding the set location, the display process is performed by the terminal between the time the payment is made at the set location and the set time elapses. When payment is made using electronic money, it includes processing for displaying information regarding the execution of authentication.
According to the seventh aspect of the present invention, an information processing method for a terminal that performs processing related to payment using electronic money is such that first information regarding a location, which is different from authentication information for authenticating a user of the terminal, is transmitted to the terminal by a control unit of the terminal. and performing a display process related to execution of authentication for a user of the terminal by the control unit based on the first information and the acquisition of code information for making a payment using electronic money, or the reading of the code information. If the first information includes information regarding a set location, the display process may include a display process in which, if the first information includes information regarding a set location, the terminal allows the terminal to make a payment using electronic money between the time the payment is made at the set location and the set time elapses. This includes processing for displaying information regarding the execution of authentication when authentication has been performed.
According to the eighth aspect of the present invention, a terminal that performs processing related to payment using electronic money acquires first information regarding a location, which is different from authentication information for authenticating a user of the terminal, and combines the first information and electronic money with The control unit includes a control unit that performs display processing related to execution of authentication for a user of the terminal based on acquisition of code information for performing monetary settlement or reading of code information, and the display processing is performed when the first information is set. If information about the location is included, the process of displaying information regarding the execution of authentication if a payment is made with electronic money using a terminal between the time the payment is made at the set location and the set time has elapsed. including.

FIG. 1 is a diagram illustrating an example of a configuration of a communication system in one aspect of an embodiment. FIG. 1 is a diagram illustrating an example of a system configuration of a store POS system in one aspect of the embodiment. FIG. 3 is a diagram illustrating an example of functions realized by the control unit of the server according to the first embodiment. The figure which shows an example of the information stored in the memory|storage part of the server based on 1st Embodiment. FIG. 3 is a diagram showing an example of user registration data according to the first embodiment. The figure showing an example of store registration data concerning a 1st embodiment. The figure which shows an example of the payment management database based on 1st Embodiment. FIG. 3 is a diagram illustrating an example of functions realized by a control unit of a terminal according to the first embodiment. FIG. 3 is a diagram showing an example of information stored in a storage unit of the terminal according to the first embodiment. FIG. 3 is a diagram showing an example of authentication skip condition data according to the first embodiment. The figure showing an example of terminal user data concerning a 1st embodiment. FIG. 3 is a diagram showing an example of authentication skip condition user setting data according to the first embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. The figure which shows an example of the display screen of the terminal based on 1st Embodiment. 1 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the first embodiment. 1 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the first embodiment. 1 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the first embodiment. 1 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the first embodiment. 5 is a flowchart illustrating an example of the flow of first authentication skip determination processing according to the first embodiment. The figure which shows an example of the authentication skip condition data based on a 1st modification. The flowchart which shows an example of the process flow of the terminal, store code reader device, and server based on a 1st modification. The figure which shows an example of the data structure of the code management database for terminal reading based on the 1st modification. FIG. 7 is a diagram illustrating an example of functions realized by a control unit of a server according to a second embodiment. FIG. 7 is a diagram illustrating an example of information stored in a storage unit of a server according to a second embodiment. FIG. 7 is a diagram showing an example of authentication skip condition data according to the second embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the second embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the second embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to the second embodiment. The flowchart which shows an example of the process flow of the terminal, store code reader device, and server based on a 2nd modification. The flowchart which shows an example of the process flow of the terminal, store code reader device, and server based on a 2nd modification. The flowchart which shows an example of the process flow of the terminal, store code reader device, and server based on a 2nd modification. FIG. 7 is a diagram illustrating an example of functions realized by a control unit of a server according to a third embodiment. 12 is a flowchart illustrating an example of the processing flow of a terminal, a store code reader device, and a server according to a third embodiment. The flowchart which shows an example of the process flow of the terminal, store code reader device, and server based on a 3rd modification. The flowchart which shows an example of the process flow of the terminal, store code reader device, and server based on a 3rd modification. FIG. 7 is a diagram illustrating an example of functions realized by a control unit of a server according to a fourth embodiment. FIG. 7 is a diagram illustrating an example of information stored in a storage unit of a server according to a fourth embodiment. The figure which shows an example of the data structure of the IMS user management database based on 4th Embodiment. The figure which shows an example of the data structure of the IMS group management database based on 4th Embodiment. The figure which shows an example of the data structure of the remittance arrival management database based on 4th Embodiment. FIG. 7 is a diagram illustrating an example of functions realized by a control unit of a terminal according to a fourth embodiment. FIG. 7 is a diagram illustrating an example of information stored in a storage unit of a terminal according to a fourth embodiment. The figure which shows an example of the data structure of the authentication skip condition data based on 4th Embodiment. The figure which shows an example of the data structure of the data for remittance arrival based on 4th Embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. FIG. 7 is a diagram showing an example of a display screen of a terminal according to a fourth embodiment. 12 is a flowchart illustrating an example of a processing flow of a terminal and a server according to a fourth embodiment. 12 is a flowchart illustrating an example of a processing flow of a terminal and a server according to a fourth embodiment. The figure which shows an example of the data structure of the authentication skip condition data based on a 4th modification. 12 is a flowchart illustrating an example of a processing flow of a terminal and a server according to a fourth embodiment.

<Compliance with legal matters>
Please note that the disclosures described herein are subject to compliance with the host country's legal requirements necessary for the implementation of the disclosures, such as confidentiality of communications.

Embodiments for implementing the authentication method and the like according to the present disclosure will be described with reference to the drawings.

[System configuration]
FIG. 1 is a diagram illustrating an example of the 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 store POS system 40 are connected via a network 30. .

The server 10 provides the terminals 20 owned by users with a service that enables the transmission and reception of content, including messages, between the terminals 20 via the network 30. Further, the server 10 provides a service (hereinafter referred to as "payment service") that communicates with the terminal 20 to realize electronic payment (an example of payment, not limited to payment). Note that the number of terminals 20 connected to the network 30 is not limited.

The network 30 plays a role of connecting one or more terminals 20, one or more servers 10, and one or more store POS systems 40. That is, the network 30 refers to a communication network that provides a connection path so that the various devices described above can transmit and receive data after being connected.

One or more portions of network 30 may or may not be a wired network or a wireless network. 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: WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), part of the Internet, public switched telephone network (Public 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 of these. Network 30 may include one or more networks 30.

The terminals 20 (terminal 20A, terminal 20B, terminal 20C, ...) (not limited to, but an example of a terminal or information processing device) may be any information processing terminal that can realize the functions described in each embodiment. It may be a terminal. Terminal 20 may include, by way of example and not limitation, a smartphone, a mobile phone (feature phone), a computer (by way of example and not limitation, a desktop, laptop, tablet, etc.), a media computer platform (by way of example and not limitation, a cable, satellite set, etc.). top boxes, digital video recorders), handheld computing devices (by way of example and not limitation, personal digital assistants, email clients, etc.), wearables (such as eyeglasses, watch devices, etc.), or other types of computers. , or communication platform. Further, the terminal 20 may be expressed as an information processing terminal.

Since the configurations of terminal 20A, terminal 20B, and terminal 20C are basically the same, in the following description, only terminal 20 will be described. Furthermore, if necessary, the terminal used by user X will be expressed as terminal 20X, and the user information in a predetermined service associated with user X or terminal 20X will be expressed as user information X. Note that 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, the user's name, the user's icon image, the user's age, the user's gender, the user's address, and the user's hobbies, entered by the user or provided by a predetermined service. It includes information associated with the user such as preferences and user identifiers, and may be any one or a combination of these, or may not be the same.

The server 10 (not limited to, but an example of a server, an information processing device, or 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 that can implement the functions described in each embodiment. Server 10 may include, by way of example and not limitation, a server device, a computer (such as, by way of example and not limitation, a desktop, laptop, tablet, etc.), a media computer platform (by way of example and not limitation, a cable, satellite set-top box, digital video recorder, etc.). ), handheld computing devices (by way of example and not limitation, PDAs, email clients, etc.), or other types of computers or communication platforms. Further, 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 each expressed as an information processing device.

In the embodiment described below, the server 10 will be described as having a function of providing a messaging service (IMS (Instant Messaging Service)) and a function of providing a payment service.

Note that the server with the function of providing IMS and the server with the function of providing payment services may or may not be configured as two separate servers, the IMS server and the payment server. It's okay.

In addition, by way of example and not limitation, the business operator that operates the server 10 is a company (for example, company "X"), and the stores (member stores) of member stores affiliated with the IMS business operator are "store S1" and "store S1". Store S2'', . . .

The store POS system 40 is a POS system that is introduced and used in a store affiliated with an IMS operator.
This store POS system 40 includes, by way of example and not limitation, a store code reader device 50, a code register 60, and a store server 70.

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

(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), 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, a camera 27, It includes a clock section 29A and a position calculation information detection section 29B. Each component of the HW of terminal 20 is interconnected via bus B, by way of example and not limitation. Note that it is not essential that the HW configuration of the terminal 20 includes all the components. By way of example and not limitation, terminal 20 may or may not be configured to remove individual components or components, such as microphone 25 and camera 27.

The communication I/F 22 transmits and receives various data via the 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 communicating with various devices such as the server 10 via the network 30. The communication I/F 22 transmits various data to various devices such as the server 10 according to instructions from the control unit 21. Furthermore, the communication I/F 22 receives various data transmitted from various devices such as the server 10 and transmits the received data to the control unit 21 . Moreover, the communication I/F 22 may be simply expressed as a communication section. In addition, when the communication I/F 22 is composed of a physically structured circuit, it may be expressed as a communication circuit.

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

The input unit is realized 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, by way of example and not limitation, a touch panel, a touch display, hardware keys such as a keyboard, a pointing device such as a mouse, a camera (operation input via moving images), and a microphone (operation input via voice).

The output unit is realized by any one of all types of devices capable of outputting the processing results processed by the control unit 21 or a combination thereof. The output unit includes, by way of example and not limitation, a touch panel, a touch display, a speaker (audio output), a lens (including, but not limited to, 3D (three dimensions) output or hologram output), a printer, and the like.

The display unit 24 is realized by any one or a combination of all types of devices capable of displaying data according to the display data written in the frame buffer. The display unit 24 may include, by way of example and not limitation, a touch panel, a touch display, a monitor (including, but not limited to, a liquid crystal display or an OELD (organic electroluminescence display)), a head mounted display (HDM), a projection mapping, and a hologram. , 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 have substantially the same size and shape and may be disposed facing each other.

The clock unit 29A is a built-in clock of the terminal 20, and outputs time information (timekeeping information). The clock unit 29A includes, by way of example and not limitation, a clock using a crystal oscillator, a clock using the NITZ (Network Identity and Time Zone) standard, and the like. The clock section 29A can also be expressed as a timekeeping section or a time information detection section, by way of example and not limitation.

The position calculation information detection unit 29B has a function of detecting (measuring) information (hereinafter referred to as “position calculation information”) necessary for the control unit 21 to calculate (measure) the position of its own terminal 20. Department. The position calculation information detection unit 29B can also be expressed as a position calculation sensor unit, by way of example and not limitation.

The position calculation information detection unit 29B includes, by way of example and not limitation, a satellite positioning sensor (satellite positioning sensor) which is a sensor or unit for calculating the position of the terminal 20 using a satellite positioning system such as GPS (Global Positioning System). unit), and an inertial measurement sensor (IMU (Inertial Measurement Unit)) that is a sensor or unit for calculating the position of the terminal 20 using an inertial navigation system.

The satellite positioning unit includes, by way of example and not limitation, an RF receiving circuit that converts an RF (Radio Frequency) signal including a positioning satellite signal transmitted from a positioning satellite received by an antenna (not shown) into a digital signal; A positioning satellite signal is captured by performing correlation calculation processing on the digital signal output from the RF receiving circuit, and information such as satellite orbit data and time data extracted from the positioning satellite signal is used as position calculation information. It has a baseband processing circuit etc. for output.

The inertial measurement unit has an inertial sensor that is a sensor that detects information necessary for calculating the position of the terminal 20 by inertial navigation calculation. Inertial sensors include, by way of example and not limitation, a 3-axis acceleration sensor and a 3-axis gyro sensor, and use the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor as position calculation information. Output.

The control unit 21 has a physically structured circuit for executing functions realized by codes or instructions included in a program, and includes, by way of example and not limitation, a data processing device built into hardware. This is realized by Therefore, the control unit 21 may or may not be expressed as a control circuit.

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

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

In the terminal 20, the program P is stored in the storage unit 28, and by executing the program P, 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 realize each function executed by the control unit 21. Furthermore, this program P may or may not be expressed as a program module.

The microphone 25 is used for inputting audio data. The speaker 26 is used to output audio data. The camera 27 is used to obtain moving image data.

(2) HW configuration of server FIG. 1 shows an example of the HW configuration of the server 10.
The server 10 includes a control section 11 (CPU), a storage section 15, a communication I/F 14 (interface), an input/output section 12, a display 13, and a clock section 19. The HW components of server 10 are interconnected via bus B, by way of example and not limitation. Note that the HW of the server 10 does not necessarily include all the components as the HW configuration of the server 10 . By way of example and not limitation, the HW of the server 10 may or may not be configured to remove the display 13.

The control unit 11 has a physically structured circuit for executing functions realized by codes or instructions included in a program, and includes, by way of example and not limitation, a data processing device built into hardware. This 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 control unit 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. Furthermore, the storage unit 15 may or may not be expressed as a memory.

The communication I/F 14 transmits and receives various data via the 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 communicating with various devices such as the terminal 20 via the network 30. The communication I/F 14 transmits various data to various devices such as the terminal 20 according to instructions from the control unit 11. Further, the communication I/F 14 receives various data transmitted from various devices such as the terminal 20 and transmits the received data to the control unit 11. Moreover, the communication I/F 14 may be simply expressed as a communication section. Furthermore, when the communication I/F 14 is composed of a physically structured circuit, it may be expressed as a communication circuit.

The input/output unit 12 is realized by a device that inputs various operations to the server 10. The input/output unit 12 is realized 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 typically implemented using hardware keys such as a keyboard or a pointing device such as a mouse. Note that the input/output unit 12 may or may not include, by way of example and not limitation, a touch panel, a camera (operation input via moving images), and a microphone (operation input via voice). However, in the present disclosure, the input/output unit 12 is not limited to these.

The display 13 is typically realized by a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OELD)). Note that the display 13 may or may not be a head mounted display (HDM). Note that these displays 13 may or may not be capable of displaying display data in 3D. In the present disclosure, the display 13 is not limited to these.

The clock unit 19 is a built-in clock of the server 10, and outputs time information (timekeeping information). The clock unit 19 includes, by way of example and not limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, and the like. The clock section 19 can also be expressed as a clock section or a time information detection section, by way of example and not limitation.

(3) System configuration of store POS FIG. 2 shows an example of the system configuration of the store POS system 40.
The store POS system 40 is a POS system that is introduced and used in a store that is affiliated with the business operator (IMS business operator) that operates the server 10, and includes, by way of example and not limitation, a store code reader device 50, It includes a code register 60 and a store server 70.

The store code reader device 50 is communicatively connected to a code register 60 and a store server 70 via a POS communication I/F 57 (for example, without limitation, a wired communication I/F or a wireless communication I/F in the store), and is connected to a code register 60 and a store server 70. At the time of checkout, the terminal display code displayed on the display section 24 of the terminal 20 is read. Then, based on reading the terminal display code, information regarding the payment at the terminal 20 (as an example, but not limited to, payment request information to be described later) is transmitted to the server 10 via the communication I/F 54, and the server 10 Information regarding the payment result (by way of example and not limitation, store payment result information to be described later) is received from the server 10 through the communication I/F 54 .

The store code reader device 50 includes, by way of example and not limitation, a control section 51, an input/output section 52, a display section 53, a communication I/F 54, a storage section 55, a sound output section 56, and a POS communication I/F section. F57 and a code reader 58.

The code reader 58 is a code reader for reading a two-dimensional code, and in this specification, the two-dimensional code (for example, QR code (registered trademark)) displayed on the display unit 24 of the terminal 20 and presented by the user of the terminal 20 )) includes a two-dimensional code reader (for example, a QR code reader) for reading a terminal display code.

By way of example and not limitation, the code register 60 is communicatively connected to the store code reader device 50 and the store server 70 via the POS communication I/F 57, and the store code reader device 50 uses the store payment result information acquired from the server 10. , issue a receipt with the total amount of sold products printed on it. The code register 60 is a cash register configured to be compatible with a payment application, and can also be called a stationary terminal compatible with a payment application.

The store server 70 may store, by way of example and not limitation, store information regarding its own store, information regarding products sold at its own store, information regarding services provided at its own store, and information regarding the sale of products and provision of services at its own store. Manage various information such as information related to sales. The store server 70 is configured to be able to communicate with the store code reader device 50 and the code register 60 via the POS communication I/F 57, and is also configured to be able to communicate with external devices such as the server 10 via the network 30.

Note that the store server 70 does not necessarily need to be configured to be able to communicate directly with the store code reader device 50, and may be configured to be able to communicate with the store code reader device 50 via the code register 60. For example, the store payment result information acquired by the store code reader device 50 from the server 10 may be sent to the code register 60, and then sent from the code register 60 to the store server 70.

(4) Others The server 10 stores the program P in the storage unit 15, and by executing the program P, 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 realize each function executed by the control unit 11. This program P may or may not be expressed as a program module.
The same applies to other devices.

In each embodiment of the present disclosure, description will be made assuming that the CPU of the terminal 20 and/or the server 10 executes the program P.
The same applies to other devices.

Note that the control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 may be formed not only in a CPU having a control circuit but also in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)), etc. Each process may or may not be realized by a dedicated logic circuit (hardware) or a dedicated circuit. Further, 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. Furthermore, LSIs are sometimes 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 applies to other devices.

Further, the program P (by way of example, but not limitation, a software program, computer program, or program module) of each embodiment of the present disclosure may be provided in a state stored in a computer-readable storage medium, or It doesn't have to be done. The storage medium can store the program P in a "non-temporary tangible medium". Further, the program P may or may not be for realizing a part of the functions of each embodiment of the present disclosure. Furthermore, it may or may not be a so-called difference file (difference program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded on a storage medium.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) such as, by way of example and not limitation, field programmable gate arrays (FPGAs) or application specific integrated circuits (ASICs), hard drives, etc.・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 (SSD), a RAM drive, a secure digital card, or any other suitable storage medium, or any suitable combination of two or more thereof. Storage media may be volatile, non-volatile, or a combination of volatile and non-volatile, where appropriate. Note that the storage medium is not limited to these examples, and may be any device or medium that can store the program P. Further, the storage medium may or may not be expressed as a memory.

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

Further, 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 waves, etc.) that can transmit the program. . By way of example and not limitation, 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 applies to other devices.

Further, each embodiment of the present disclosure can also be realized in the form of a data signal embedded in a carrier wave, 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, at least part of the processing of each functional unit of the control unit 21 of the terminal 20 may or may not be performed by the server 10.
At least part of the processing in the server 10 may or may not be performed by the terminal 20. In this case, at least part of the processing of each functional unit of the control unit 11 of the server 10 may or may not be performed by the terminal 20.
Unless explicitly stated, the configuration of the determination in the embodiments of the present disclosure is not essential, and a predetermined process may be performed when the determination condition is met, or a predetermined process is performed when the determination condition is not met. You may or may not.

Note that the program of the present disclosure uses, by way of example and not limitation, scripting 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, etc. It is implemented using

<First embodiment>
In recent years, network services such as IMS and SNS (Social Networking Service) have become popular.
"IMS" is a service that allows messages to be sent and received between users' communication devices in order to have conversations between them using the Internet. In this specification, the expression "IMS", which is an abbreviation for instant messaging service, is used, but in a broad sense, it means messaging services in general, and is not limited to instant messaging services.
"SNS" is a service that allows social networks and communities to be formed on the Internet, primarily for the purpose of communication between users of communication devices. Note that IMS can also be said to be one form (one form) of SNS. Therefore, IMS and SNS may or may not be distinguished.

In addition, in connection with these network services, electronic payment applications (application software) are becoming popular, and the number of cases in which users of the terminal 20 make payments at stores using electronic payment applications is increasing. It's coming.

The first to third embodiments are, by way of example and not limitation, an application provided by an IMS operator and as a function of IMS application software (hereinafter simply referred to as "IMS application"). , or perform electronic payment using IMS payment application software (hereinafter simply referred to as "payment application"), which is an application for electronic payment that can be used by the user of the terminal 20, as an application that works with the IMS application. This is an embodiment.

More specifically, in the first to third embodiments, when a user of the terminal 20 purchases a product at a store or receives a service provided by a store, the user makes an electronic payment using a payment application. . At this time, the authentication for electronic payment requested from the user on the terminal 20 side is skipped if a specific condition is met.

In the embodiment described below, "payment" means "electronic payment" using a payment application unless otherwise specified.
Furthermore, unless otherwise specified, "authentication" means to authenticate that the user of the terminal 20 is an authorized user in order to make a payment, and "authentication processing" refers to the authentication for this payment. It means the processing to realize.
In addition, "authentication skip conditions" means conditions for skipping the authentication processing for payment described above, unless otherwise specified, and "skipping authentication processing" refers to conditions for ignoring the processing instructions for authentication processing. , which means processing the next command, that is, omitting the authentication process.
Further, unless otherwise specified, "IMS money" refers to electronic money that is managed by the IMS operator on the server 10 and that can be used by the user of the terminal 20 in the payment application.

Here, "electronic money" is a payment means that is an alternative to cash and is provided by a business operator (in the embodiment described below, an IMS business operator) and uses information and communication technology.
Although a modification will be described later, electronic money in the present disclosure is not limited to IMS money, but can be a concept that includes all payment means that can be used by users as an alternative to cash.
The content described in the first embodiment is applicable to any of the other embodiments.

<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 server 10 includes a server main processing section 111, an IMS processing section 112, and a payment management processing section 113 as functions realized by the control section 11.

The server main processing unit 111 has a function of executing server main processing, which is processing for controlling the server 10 in an integrated manner, according to the server main processing program 151 stored in the storage unit 15.

The IMS processing unit 112 has a function of executing IMS processing, which is processing for realizing the transmission and reception of content including IMS messages etc. between the terminals 20, according to the IMS processing program 1512 stored in the storage unit 15. have.

The payment management processing unit 113 has a function of executing payment management processing, which is processing for executing and managing payments using IMS money, in accordance with the payment management processing program 1513 stored in the storage unit 15.

In the present embodiment, the user of the terminal 20 uses the payment application stored in the terminal 20 to make payments using two types of payments: "terminal code display" and "terminal code reading", by way of example and not limitation. This will be explained as being possible.

The payment type "terminal code display" means that when the user of the terminal 20 makes a payment at a store, the terminal display code displayed on the terminal 20 is sent to the store's code register using the payment application stored in the terminal 20. This is a payment type in which payment is made by presenting the terminal display code to the store clerk at step 60 and having the store code reader device 50 read the terminal display code.

The payment type "terminal code reading" allows the user of the terminal 20 to use the payment application stored in the terminal 20 to make a payment at a store, for example, at the front of the store, near the code register 60, or at the store. This is a payment type in which payment is made by reading a terminal reading code posted in a display area (as an easy-to-understand example, a bento area, a beverage area, or a food area) that corresponds to the product type.

In this embodiment, it is assumed that the terminal display code and the terminal reading code are each represented by a two-dimensional code. A two-dimensional code is a display type code that has information in the horizontal and vertical directions, and includes a matrix code in which small squares are arranged vertically and horizontally (hereinafter referred to as "matrix code"), and a one-dimensional code. There are stacked codes (hereinafter referred to as "stacked codes") in which a plurality of original codes (barcodes, as an example, not limited) are stacked one above the other.

In this embodiment, in order to simplify the explanation, a QR code (registered trademark), which is an example of a widely used matrix code, will be described as an example of a terminal display code and a terminal reading code.

Note that, unlike the present embodiment, as a matrix code other than the QR code, a code such as an SP code, Vericode, maxi code, CP code, or Chameleon code may or may not be used. Furthermore, instead of the matrix code, various stack codes may or may not be used.

The payment management processing section 113 includes, by way of example and not limitation, a terminal display code generation processing section 1131, a terminal display code transmission processing section 1133, a store payment result information transmission processing section 1136, and a terminal payment result information transmission processing section. A processing unit 1137 is included as a functional unit.

The terminal display code generation processing unit 1131 has a function of generating a terminal display code. The terminal display code generation processing unit 1131 accesses at least a payment page, which is one of the web pages provided by the server 10, based on receiving the terminal display code generation request information transmitted from the terminal 20. A QR code containing access information and authentication information is generated as a terminal display code.

The access information includes, by way of example and not limitation, a URL (Uniform Resource Locator) for the store code reader device 50 that has read the terminal display code to access the payment page. This access information can also be expressed as a "link" or "link information." Hereinafter, the URL of the payment page will be referred to as "payment page URL."

The authentication information includes, by way of example and not limitation, as authentication information necessary for the server 10 to authenticate that the terminal 20 or the user of the terminal 20 is the authorized terminal 20 or the authorized user of the terminal 20. A token randomly issued by the server 10 is included.

The authentication information is information issued by a certificate authority, and the token is authentication information issued by the server 10 as a certificate authority to authenticate the terminal 20 or the user of the terminal 20.

The token in this embodiment can also be expressed as a "random token," "access token," or "payment token," for example. In this embodiment, since tokens are issued at random, a different token is generated each time a terminal display code is generated. Therefore, the token or the terminal display code containing this token functions as a one-time password.

In addition, in this embodiment, the terminal display code generation processing unit 1131 uses a two-dimensional code (a QR code as an example, not a limitation) as well as a one-dimensional code (a barcode as an example, not a limitation) as a terminal display code. is also generated. This is because some stores may not be able to read two-dimensional codes, but may be able to read one-dimensional codes.

In this embodiment, when the terminal display code generation processing unit 1131 generates the terminal display code, the terminal display code is associated with a validity period (for example, a period of "5 minutes" from the time of code generation). and transmits it to the terminal 20. If the terminal display code displayed on the terminal 20 is read by the store code reader device 50 within this validity period, payment is possible, but after the validity period has passed, the terminal display code is read by the store code reader device 50. If it is read, you will need to reacquire the terminal display code. In other words, the terminal display code in this embodiment functions as a timed code.

On the other hand, the terminal reading code used in the payment type "terminal code reading" includes at least, as access information, the payment page URL for the terminal 20 that has read the terminal reading code to access the payment page. It will be done.

In this embodiment, the description will be made assuming that the terminal reading code includes two types of terminal reading codes.

The first type of terminal reading code (hereinafter referred to as the "first type terminal reading code") is used in stores of various industries in Japan (a typical example is Japanese convenience stores), etc. It is a code. This type 1 terminal reading code is, as an example of a usage mode, a code used to make payments for products of a product type sold at a store for a uniform amount (fixed amount), such as bento boxes and drinks. It can be done.

The first type terminal reading code includes, by way of example and not limitation, the payment page URL associated with the store that operates the first type terminal reading code and corresponding to the product or product type sold at that store. included.

For a store that operates a type 1 terminal reading code, the server 10 may, by way of example and not limitation, link the store ID of the store (not limited to, an example of store identification information) with the product or product type, The sales amount and payment page URL are stored and managed.

The second type of terminal reading code (hereinafter referred to as the "second type terminal reading code") is a special code that can be used at a specific store in a foreign country (a typical example is a food stall in China) or on the Internet. This is a code used in electronic commerce, etc. using . Unlike the first type terminal reading code, this type 2 terminal reading code is different from the first type terminal reading code in that the server 10 side does not manage the product type or sales amount, and the user of the terminal 20 makes a purchase. The code can be used to enter the amount of the product you want and make the payment yourself.

The second type terminal reading code includes, by way of example and not limitation, a payment page URL associated with a store that operates the second type terminal reading code and corresponding to the store.

The server 10 stores and manages the payment page URL in association with the store ID of a store that operates the second type terminal reading code, by way of example and not limitation.

Note that, unlike this embodiment, only one type of code among the first type terminal reading code and the second type terminal reading code may be used as the terminal reading code. In other words, without dividing the terminal reading code into two types, only the first type terminal reading code can be used as the terminal reading code, or only the second type terminal reading code can be used as the terminal reading code. You can also do it.
In this case, configurations related to terminal reading codes that are not applicable to the functions, data, processing, etc. described in this embodiment can be deleted.

FIG. 3-2 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, by way of example and not limitation, a server main processing program 151 as a program that is read by the control unit 11 and executed as server main processing.
Further, the server main processing program 151 includes, as subroutine programs, an IMS processing program 1512 that is read by the control unit 11 and executed as IMS processing, and a payment management processing program 1513 that is executed as payment management processing.
The payment management process will be described in detail later using a flowchart.

Further, the storage unit 15 stores user registration data 153, store registration data 155, payment management database 157, and code management database 159 as data, by way of example and not limitation.

The user registration data 153 is registration data of the terminal 20 that uses the payment service and the user of the terminal 20, and an example of the data structure is shown in FIG. 3-3.
The user registration data 153 stores, by way of example and not limitation, a user name, a terminal telephone number, a terminal e-mail address, a user ID, an authentication password, and other registration information in association with each other.

The user name is the name of the user of the terminal 20 who uses the payment service, and stores the name that the user of the terminal 20 registers when using the payment service.

The terminal telephone number is the telephone number of the terminal 20 of the user with this user name, and stores the telephone number of the terminal 20 that the user of the terminal 20 registers when using the payment service.
The terminal email address is the email address of the terminal 20 of the user with this user name, and stores the email address of the terminal 20 that the user of the terminal 20 registers when using the payment service.
The terminal telephone number and the terminal email address are examples of identification information for identifying the terminal 20 (hereinafter referred to as "terminal identification information").

The user ID is an ID that functions as identification information for identifying the user of the terminal 20, and is an ID uniquely set for the user who uses the payment application. This user ID is set and stored as a unique ID for each user by the server 10, by way of example and not limitation.
The user ID is an example of identification information (hereinafter referred to as "user identification information") for identifying the user of the terminal 20.

The authentication password is an authentication password that the user is required to input when performing payment authentication processing (hereinafter simply referred to as "authentication processing") on the terminal 20 of the user with this user name. The password set by is memorized.

Other registered information is other registered information of the user with this user name, and includes, by way of example and not limitation, a user icon image, which is image data of an icon used by the user in an IMS application, a user profile, etc. .

Note that the various types of user information described above can be stored and managed on the server 10 side as common user information between the IMS application and the payment application.

The store registration data 155 is registration data of a store affiliated with an IMS operator (payment service operator), and an example of the data structure is shown in FIG. 3-4.
The store registration data 155 stores the industry, store name, store location information, store POS system information, store ID, first specific industry flag, and second specific industry flag in association with each other as store information. Ru.

The industry type stores the industry type of the store. This industry includes, by way of example and not limitation, "convenience stores," "supermarkets," "pharmacies," "izakayas," "department stores," "restaurants," "bookstores," and "watch stores." It will be done.

In the store name field, for each business type, store names of stores included in (belonging to) that business type are stored.

The store location information stores location information of the location of the store with this store name (hereinafter referred to as "store location information"). This store location information may represent the store location using two-dimensional or three-dimensional location coordinates, or may represent the store location using longitude and latitude (latitude, longitude, and altitude in some cases). .

The store POS system information stores information regarding the store POS system 40 used at this store. This store POS system information includes, by way of example and not limitation, information necessary for the server 10 to communicate with the store code reader device 50 and the store server 70.

Since the store POS system 40 performs processing in cooperation with the server 10, by way of example and not limitation, the store POS system 40 acquires in advance a software package for a payment service provided (distributed) from the server 10 and stores it in the store code reader device 50 or the store. This software package can be stored in the server 70 and used by being called from a program for payment processing at a store. A typical example is an application programming interface (API), and the store code reader device 50 can transmit information to the server 10 and receive information from the server 10 by activating the API, for example.

In addition, the server 10 receives information such as a store's industry type, store name, store location information, store POS system information, etc., from the store server 70 of the store, by way of example and not limitation, and stores the information in the store registration data 155. You can keep it as is.

The store ID is an ID that functions as identification information for identifying the store with this store name. This store ID is set and stored as a unique ID for each store by the server 10, by way of example and not limitation.
The store ID is an example of identification information for identifying a store (hereinafter referred to as "store identification information").

The first specific industry flag is a flag indicating whether or not this industry is a preset first type of specific industry (hereinafter referred to as "first specific industry"). "ON" is stored in the industry that falls under the first specific industry, and "OFF" is stored in the industry that does not fall under the first specific industry. The first specific industry type can be set in advance on the server 10 side, by way of example and not limitation. In this example, "convenience store" and "supermarket", which are industries that many users use on a daily basis, are set as the first specific industry.

The second specific industry flag is a flag indicating whether or not this industry is a preset second type of specific industry (hereinafter referred to as "second specific industry"). "ON" is stored in the industry that falls under the second specific industry, and "OFF" is stored in the industry that does not fall under the second specific industry. The second specific industry type can also be set in advance on the server 10 side, by way of example and not limitation. In this example, "Izakaya", which is a business type with a high risk of a user leaving the terminal 20 behind, is set as the second specific business type.

The payment management database 157 is a database that cumulatively stores data for managing information regarding payments by users of each terminal 20, and an example of the data structure is shown in FIG. 3-5.
The payment management database 157 stores payment management data generated for each terminal 20 or each user of the terminal 20.

Each payment management data stores, by way of example and not limitation, the user ID of the user of the terminal 20, balance, IMS points, daily upper limit setting, auto charge setting, and payment history data. .

The user ID stored in the user registration data 153 is stored in the user ID.
The balance stores the latest value of the balance (remaining money) of IMS money owned by the user with this user ID.

IMS Points stores points that can be earned through various IMS services and at affiliated stores affiliated with IMS operators. IMS points have a value equivalent to 1 yen per point, by way of example and not limitation, and can be exchanged for gift certificates, products, etc., and can also be converted into cash in a payment application and used for payment.

The daily upper limit setting amount stores the upper limit amount per day that the user with this user ID can use for payment.
The auto charge setting is a setting for whether or not to automatically replenish IMS Money (auto charge) when the remaining balance is low (for example, "500 yen") or "0 yen". "ON" is stored when the auto charge setting is made by the user, and "OFF" is stored otherwise. By way of example and not limitation, auto-charging can be performed from a bank account registered by the user of the terminal 20.

The payment history data is data related to the payment history of the user with this user ID, and includes, by way of example and not limitation, the payment date and time that is the date and time when the payment was made by the server 10 and the store where the payment was made for the user with this user ID. A store ID, which is the ID of the store, a payment store name, which is the name of the store with the store ID, and a payment amount, which is the payment amount, are stored in chronological order in association with each other.

The code management database 159 is a database for managing terminal display codes and terminal reading codes, and includes a terminal display code management database 1591 and a terminal reading code management database 1593.

The terminal display code management database 1591 is a database for managing terminal display codes, and includes, by way of example and not limitation, the user ID stored in the user registration data 153 and the user identified from this user ID. Data associated with the token included in the terminal display code generated for the terminal 20 is stored.

Note that instead of or in addition to the user ID, which is the user identification information, terminal identification information such as the terminal phone number stored in the user registration data 153 is stored in the terminal display code management database 1591. You may or may not.

The terminal reading code management database 1593 is a database for managing terminal reading codes, and includes, by way of example and not limitation, data for managing type 1 terminal reading codes, and data for managing type 2 terminal reading codes. data for managing the information is stored.

Specifically, for the type 1 terminal reading code, by way of example and not limitation, for each store ID, the product or product type sold at that store, the sales amount, and the payment page URL are associated. Data is stored.
In addition, in this embodiment, since products are sold for a uniform amount (fixed amount) at stores that operate Type 1 terminal reading codes, products or product types are not associated, and the sales amount and payment page are Data associated with the URL may be stored.

Further, regarding the second type terminal reading code, data in which a payment page URL is associated with each store ID is stored, by way of example and not limitation.

In addition, instead of or in addition to the store ID, which is the store identification information, store POS system information stored in the store registration data 155, contact information such as the store telephone number, and the store email address may be used. It may or may not be stored in the terminal reading code management database 1593.

(2) Functional configuration of terminal FIG. 3-6 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
The terminal 20 includes a terminal main processing section 211, an IMS application processing section 212, a payment application processing section 213, and a position calculation processing section 217 as functions realized by the control section 21.

The terminal main processing section 211 has a function of executing terminal main processing, which is processing for controlling the terminal 20 in an integrated manner, according to the terminal main processing program 281 stored in the storage section 28 . As an example and not a limitation, if the terminal 20 is a mobile phone, it may control to make a call with another mobile phone, landline phone, etc. via the communication I/F 22, or The camera 27 controls access to various websites, controls the display unit 24 to display various information, or performs processing to analyze various sound data input from the microphone 25. Performs processes such as analyzing still images and moving images taken by.

The IMS application processing unit 212 performs IMS application processing, which is processing for transmitting and receiving content with other users' terminals 20 via the server 10, based on the IMS application 282 stored in the storage unit 28. It has the ability to execute.

The payment application processing unit 213 has a function of executing payment application processing, which is processing for communicating with the server 10 and making payments, based on the payment application 283 stored in the storage unit 28.

The payment application processing unit 213 has a terminal display code acquisition processing unit 2131, a code reading processing unit 2133, an authentication skip determination processing unit 2135, and an authentication processing unit 2137 as functional units.

The terminal display code acquisition processing unit 2131 has a function of executing processing for acquiring a terminal display code from the server 10 in the payment type "terminal code display".

The code reading processing unit 2133 has a function of executing processing for reading the terminal reading code posted at the store in the payment type "terminal code reading".

The authentication skip determination processing unit 2135 executes an authentication skip determination process, which is a process for determining whether or not to skip the authentication process executed by the authentication process unit 2137, in accordance with the authentication skip determination process program 2845 stored in the storage unit 28. It has a function of executing determination processing.

In this embodiment, the authentication skip determination processing unit 2135 receives the terminal display code from the server 10 based on the processing of the terminal display code acquisition processing unit 2131 for the payment type “terminal code display”, by way of example and not limitation. Authentication skip determination processing is executed at a later timing.
Furthermore, by way of example and not limitation, when the payment type is "terminal code reading", the authentication skip determination processing unit 2135 determines whether the server Authentication skip determination processing is executed at a timing after receiving information regarding a payment schedule (hereinafter referred to as "payment schedule information") from.
However, the execution timing of these authentication skip determination processes can be changed as appropriate.

The authentication processing unit 2137 has a function of performing authentication processing according to the authentication processing program 2847 stored in the storage unit 28.
In the authentication process, by way of example and not limitation, as a display process related to execution of authentication for the user of the terminal 20, a process of displaying an authentication screen on the display unit 24 for prompting the user of the terminal 20 to input an authentication password is performed, and this authentication It is determined whether the authentication password entered on the screen matches a registered authentication password.

The position calculation processing unit 217 has a function of executing a position calculation process, which is a process of calculating the position of the own terminal 20, based on the position calculation information output from the position calculation information detection unit 29B. . The position calculation processing unit 217 performs satellite positioning calculations based on the satellite orbit data, time data, etc. output from the satellite positioning sensor (satellite positioning unit) included in the position calculation information detection unit 29B, and The position of the terminal 20 is calculated. In addition, the position calculation processing unit 217 performs inertial navigation calculations based on the information on acceleration and angular velocity output from the inertial measurement sensor (inertial measurement unit) included in the position calculation information detection unit 29B, and Calculate the position of 20.

Note that, unlike this embodiment, by way of example and not limitation, a processing device or an arithmetic device (for example, a CPU or a DSP) is provided in the position calculation information detection unit 29B, and the position calculation The information detection unit 29B may or may not calculate the position of the terminal 20 and output it.

In addition, by way of example and not limitation, a wireless device such as a beacon that transmits a beacon signal (a typical example is a Bluetooth signal) to enable the terminal 20 to acquire location information is installed at the affiliated store, and the terminal 20 , location information may or may not be acquired based on a beacon signal transmitted from a beacon installed in the store.

FIG. 3-7 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, by way of example and not limitation, a terminal main processing program 281 that is read by the control unit 21 and executed as the terminal main process, and a position program that is read by the control unit 21 and executed as the position calculation process. A calculation processing program 287 is stored.

In addition, the storage unit 28 stores an IMS application 282 and a payment application 283 as application software obtained by downloading in advance from the server 10, by way of example and not limitation.
Note that the IMS application 282 and the payment application 283 may be one application or may be different applications.

Further, the storage unit 28 stores terminal data 286 and calculated position history data 288, by way of example and not limitation.

The terminal data 286 is data related to this terminal 20, and includes, by way of example and not limitation, terminal identification information such as a terminal phone number and terminal email address, lock setting "ON/OFF" on the OS side of the terminal 20, and information on the terminal 20. This includes information such as the terminal unlock password for unlocking the OS side and the authentication setting "ON/OFF" on the terminal side.

The calculated position history data 288 includes, by way of example and not limitation, the position calculation processing unit 217 that performs position calculation processing at predetermined time intervals (for example, "every 1 minute," "every 5 minutes," or "every 10 minutes.") A history of the calculated position of the terminal 20 (hereinafter referred to as "calculated position") is stored.

The payment application 283 includes a payment application program 284 that is read by the control unit 21 and executed as payment application processing, and payment application data 285 that stores various data related to the payment application.

The payment application program 284 includes, by way of example and not limitation, an authentication skip determination processing program 2845 that is read out by the control unit 21 and executed as an authentication skip determination process, and an authentication skip determination processing program 2845 that is read out by the control unit 21 and executed as an authentication process. The authentication processing program 2847 is included as a subroutine program.

Payment application data 285 includes, by way of example and not limitation, authentication skip condition data 2851, payment data 2853, and store data 2855.

The store data 2855 stores, by way of example and not limitation, store information in which the type of business stored in the store registration data 155 of the server 10 is associated with the first specific industry flag and the second specific industry flag.

This store data 2855 can be updated by distributing the latest store information from the server 10 to the terminal 20, for example, at the timing of updating the IMS application 282 or the payment application 283.

Authentication skip condition data 2851 is data in which authentication skip conditions, which are conditions for skipping authentication processing, are defined, and an example of the data structure is shown in FIG. 3-8.
Authentication skip condition data 2851 includes a condition category number that is the category number of the authentication skip condition, a condition number that is the number of the authentication skip condition included in the category of this condition category No., and an authentication skip condition of this condition number. , the presence or absence of application indicating whether or not to apply this authentication skip condition to make a determination, and the importance (priority) of this authentication skip condition are stored in association with each other. Hereinafter, each authentication skip condition and its determination method will be explained in detail.

<Condition Category No. “SP1”>
Condition category No. "SP1" is a "time" category, and includes, by way of example and not limitation, authentication skip conditions of condition No. "SP1-1" and "SP1-2."

As the authentication skip condition of condition No. "SP1-1", "the current date and time is within a set time from the final payment date and time" is defined.
The “last payment date and time” is the date and time when the last payment was made (the latest date and time when the payment was made), regardless of whether the authentication process was skipped at the terminal 20 or not. This is to improve user convenience, since if the current date and time is within a set time (for example, "within one hour") from the last payment date and time, the payment will be made again in a short period of time. , which means omitting authentication.

In determining this authentication skip condition, by way of example and not limitation, the terminal 20 uses the current date and time based on the time measured by the clock unit 29A, and the final payment date and time stored in the payment history data of the payment data 2853. It can be determined whether the current date and time is within a set time from the final payment date and time.

As the authentication skip condition of condition No. "SP1-2", "the current time is included in the set time zone" is defined. By way of example and not limitation, the set time period can be set in advance by the user of the terminal 20. Specifically, for example, by setting the time period in which the user of the terminal 20 frequently makes payments as the preset time period, the user of the terminal 20 can omit authentication when making payments during the preset time period. .

In determining this authentication skip condition, by way of example and not limitation, the terminal 20 obtains the current time based on the time measured by the clock unit 29A, and determines whether the current time is included in the set time zone. All you have to do is judge.

<Condition Category No. “SP2”>
Condition category number "SP2" is a category of "store/location", and includes, by way of example and not limitation, the authentication skip conditions of condition numbers "SP2-1" to "SP2-4".

The authentication skip condition of condition No. "SP2-1" is defined as "the customer has previously performed payment or payment authentication at the store where the payment is scheduled."
A "scheduled payment store" means a store where payment is scheduled to be made from now on (a store in an undetermined state before payment). In other words, if you have previously made a payment or performed authentication for the same at a store where you are about to make a payment, the authentication will be omitted to improve user convenience.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the history of calculated positions and the latest calculated position stored in the calculated position history data 288, and the payment date and time stored in the payment history data. It can be determined whether or not there is a calculated position that matches the latest calculated position among the calculated positions corresponding to the same date and time as the past payment date and time.

As the authentication skip condition of condition No. "SP2-2", "the store scheduled for payment is the set store" is defined. Basically, the set store can be set on the server 10 side. By way of example and not limitation, the server 10 may aggregate stores that are statistically frequently used by users and set them as set stores. This means that in stores that are frequently used by users, authentication is omitted in order to improve user convenience.

Note that it may be possible to set the store on the terminal 20 side instead of on the server 10 side. For example, the user of the terminal 20 can cause the terminal 20 to set a store that he or she uses frequently as a set store. Further, for example, the user of the terminal 20 may set stores in a specific industry (for example, convenience stores) as stores near his or her home as safe stores, but other stores may be considered risky stores. You can also choose not to set it as .

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the history of the calculated position stored in the calculated position history data 288, the payment store name stored in the payment history data, and the store data 2855. , and determine whether there is a calculated position that matches the latest calculated position among the calculated positions corresponding to the same date and time as the payment date and time at the past set store. You can do as you like.

As the authentication skip condition of condition No. "SP2-3", "the store scheduled for payment is a store of the first specified industry" is defined. As described above, the first specific business type is defined as a business type that many users use on a daily basis, such as a "convenience store" or a "supermarket." When making payments at these stores, authentication is omitted to improve user convenience.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the history of the calculated position stored in the calculated position history data 288, the payment store name stored in the payment history data, and the store data 2855. The first specific industry flag stored in the store is acquired, and the latest calculated position matches the calculated position corresponding to the same date and time as the past payment date and time at the store with the first specific industry flag "ON". It may be determined whether or not a calculated position exists.

The authentication skip condition of condition No. "SP2-4" is defined as "exceeding the set time from the payment date and time at the store of the second specified industry". As described above, the second specific business type can be set to be a business type where there is a high risk of the user leaving the terminal 20 behind, such as "Izakaya". Further, the set time can be set to, for example, "3 hours", "6 hours", or "12 hours". If a payment is made at a store where there is a high risk of leaving the terminal 20 behind, authentication is required from the payment date and time until the set time has passed, but if the set time has passed from the payment date and time, authentication may be omitted. means.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the current date and time based on the time measured by the clock unit 29A and the payment history data stored in the payment data 2853 of the storage unit 28. Obtain the payment date and time at the store and the second specific industry flag stored in the store data 2855, and check whether the current date and time exceeds the set time from the payment date and time at the store where the second specific industry flag is "ON". can be determined.

<Condition Category No. “SP3”>
Condition category number "SP3" is a category of "amount of money", and includes, by way of example and not limitation, the authentication skip conditions of condition numbers "SP3-1" to "SP3-3".

The authentication skip condition of condition No. "SP3-1" is set as "the amount does not exceed the daily upper limit setting".
The "daily upper limit set amount" is the upper limit set amount that is used as a threshold for the total amount of payment amounts (settled amounts) that have already been settled in one day. In other words, if the total amount of payments already made in one day does not exceed the daily upper limit setting amount, authentication is omitted in order to improve user convenience.

Conversely, if the total amount of payments that have already been made in a day exceeds the daily maximum amount, authentication will be performed to ensure that you are spending too much money on payments. It can alert you. Further, when a minor or the like makes a payment, a guardian can set restrictions on usage.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the total amount of the daily upper limit set amount stored in the payment data 2853 and the daily payment amount specified from the payment history data. It is possible to determine whether the total amount exceeds the daily upper limit setting amount by acquiring the following.

As the authentication skip condition of condition No. "SP3-2", "the balance is less than or equal to the set amount (or less than the set amount) and the auto charge setting is OFF" is defined. By way of example and not limitation, the set amount can be set in advance by the user of the terminal 20. This is to improve user convenience, as if the balance is below the set amount (or less than the set amount), the user will not be able to purchase expensive items with payment, and the risk is considered to be low. Skip authentication.

However, if the auto-charge setting is "ON", IMS money is automatically replenished, allowing the user to purchase high-priced products with payment, which poses a risk. Therefore, the conditions for authentication skip are that the balance is less than or equal to the set amount (or less than the set amount) and that the auto charge setting is "OFF".

In this case, if the auto charge setting is "ON", the authentication process will not be skipped in principle even if the balance is less than or equal to the set amount (or less than the set amount). However, as mentioned above, in order to improve user convenience, it is also possible to skip the authentication process even if the auto charge setting is "ON". In this case, as an example and not a limitation, the auto charge setting OFF may be excluded from the authentication skip condition of the above condition number "SP3-2", and it may be set as "balance is less than or equal to the set amount (or less than the set amount)". In other words, even if the auto charge setting is "ON", it does not necessarily mean that authentication processing is required.If auto charge is "ON", even if the balance is less than the set amount (or less than the set amount) For example, there may be cases where authentication processing is performed, or there may be cases where authentication processing is not performed.

In determining this authentication skip condition, the terminal 20 obtains, by way of example and not limitation, the balance and auto charge settings stored in the payment data 2853, and determines whether the balance is less than or equal to the set amount (or less than the set amount). , and it can be determined whether the auto charge setting is "OFF".

As the authentication skip condition of condition No. "SP3-3", "the frequency of payment per month or the payment amount is within an appropriate range" is defined. For example, the threshold frequency is the average value, maximum value, or mode of the payment frequency per month in the past predetermined period (the past 6 months or the past year), and the average payment amount per month in the past predetermined period is set as the threshold frequency. The value, maximum value, and mode are calculated as the threshold amount. Then, when the payment frequency exceeds the threshold frequency or the payment amount exceeds the threshold amount, authentication is performed, and in other cases, authentication is omitted.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the payment frequency and payment amount calculated from the payment history data stored in the payment data 2853, and the threshold value stored in the storage unit 28. The frequency and the threshold amount may be acquired to determine whether the payment frequency exceeds the threshold frequency and whether the payment amount exceeds the threshold amount.

Note that the above authentication skip condition may or may not be based on the number of times payments are made using IMS Money (settlement frequency) instead of the frequency of payments made using IMS Money (settlement frequency). Good too. Additionally, it may or may not be possible to set separate conditions for the payment frequency to be within an appropriate range, the number of payments to be within an appropriate range, and the payment amount to be within an appropriate range. It's okay.

As the authentication skip condition of condition No. "SP3-4", "the scheduled payment amount is less than or equal to the set amount (or less than the set amount)" is defined. The amount to be set should be within a range that is not considered to be a large amount for one-time payment, such as ``10,000 yen'' or ``20,000 yen,'' in light of common sense and social norms. be able to.
The "scheduled payment amount" means the amount that is scheduled to be settled from now on (the amount that is in an undetermined state before settlement). In other words, if the amount to be paid is not very large, authentication is omitted to improve user convenience.

In determining this authentication skip condition, the terminal 20 acquires the scheduled payment amount from the server 10, by way of example and not limitation, and determines whether the scheduled payment amount is less than or equal to the set amount (or less than the set amount). You can do it like this.

However, in the present embodiment, when the payment type is "terminal code display", the terminal 20 executes the authentication skip determination process at the timing after receiving the terminal display code from the server 10. However, at this timing, the terminal 20 has not yet acquired payment schedule information from the server 10, and the scheduled payment amount is unknown. Therefore, in this embodiment, the authentication skip condition of condition No. "SP3-4" is not applicable for the payment type "Terminal code display", and is set to "X", and is applicable only for the payment type "Terminal code reading". shall be.

<Condition Category No. “SP4”>
Condition category No. "SP4" is a category of "product", and includes, by way of example and not limitation, the authentication skip conditions of condition No. "SP4-1" and "SP4-2."

As the authentication skip condition of condition No. "SP4-1", "the product to be purchased is a daily consumer item" is defined.
"Product scheduled for purchase" means a product that is scheduled to be purchased by making a payment (a product in an undetermined state before payment). In other words, if the product to be purchased by making a payment is a daily consumer product, authentication is omitted in order to improve user convenience.

"There is a purchase history of the product to be purchased" is defined as the authentication skip condition of condition No. "SP4-2". This means that if the planned purchase product matches a product that the user of the terminal 20 has purchased at least once, authentication is omitted to improve user convenience.

In order to determine these authentication skip conditions, the terminal 20 needs to acquire information regarding the product to be purchased. However, in this embodiment, the information regarding the product to be purchased is not transmitted from the server 10 to the terminal 20 for either the payment type "terminal code display" or "terminal code reading". Therefore, the terminal 20 cannot determine the authentication skip condition included in the condition category No. "SP4 (product)".

In this embodiment, for the payment type "terminal code reading", the success or failure of the authentication skip conditions of condition Nos. "SP4-1" and "SP4-2" is determined using the method described below as an alternative method.

First, regarding the authentication skip condition No. "SP4-1", the terminal 20 reads the terminal reading code, and then accesses the payment page based on the payment page URL included in the terminal reading code, The store ID and sales amount associated with this payment page URL are acquired from the server 10. Then, if the store identified from the store ID acquired from the server 10 is a store of the first specific industry, and the sales amount is less than or equal to the threshold amount (or less than the threshold amount), the terminal 20 selects the product to be purchased. are determined to be daily consumer goods.

Next, regarding the authentication skip condition No. "SP4-2", after reading the terminal reading code, the terminal 20 accesses the payment page in the same manner as above, and accesses the store associated with the payment page URL. The ID and sales amount are acquired from the server 10. Then, the terminal 20 determines whether or not there is a payment store ID and a payment amount that match the store ID and sales amount acquired from the server 10, respectively, among the payment store IDs and payment amounts stored in the payment history data. If there is a match, it is determined that there is a purchase history for the product to be purchased.

<Condition Category No. “SP5”>
Condition category No. "SP5" is a "security" category, and includes, by way of example and not limitation, the authentication skip condition of condition No. "SP5-1."

“The terminal is locked or the payment application is locked” is defined as the authentication skip condition of condition No. “SP5-1”. This means that if the OS (Operating System) of the terminal 20 is locked or the payment application is locked, the terminal unlock password or payment application must be entered in order to release these locks. Authentication by entering an application unlock password is required. Therefore, in order to improve user convenience, authentication for payment is not required.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, information on whether or not the OS side of the terminal 20 is locked, which is stored in the terminal data 286, and the payment application side, which is stored in the payment application data 285. It is possible to determine whether the terminal is locked or the payment application is locked by acquiring information on whether the terminal is locked or not.

<Condition Category No. “SP6”>
Condition category No. "SP6" is a category of "authentication settings", and includes, by way of example and not limitation, the authentication skip condition of condition No. "SP6-1".

As the authentication skip condition of condition No. "SP6-1", "authentication setting on the terminal side or authentication setting on the payment application side is OFF" is defined.
Authentication on the terminal side is various types of authentication required of the user on the terminal 20 side, including authentication of the user's identity. Authentication on the payment application side is authentication required of the user when making a payment using the payment application.
This means that if the user of the terminal 20 has configured the terminal 20 to omit authentication, or if the payment application has configured the payment application to omit authentication, authentication will be omitted. .

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the authentication settings on the terminal side stored in the terminal data 286 and the conditions stored in the authentication skip condition user setting data of the payment data 2853. The condition-specific setting flag of No. “SP6-1” is acquired to determine whether at least one of the authentication settings on the terminal side and the authentication settings on the payment application side is “OFF”. can do.

Further, for each of the above-mentioned authentication skip conditions, whether or not to apply the authentication skip condition to perform the authentication skip determination is determined for each payment type.

Specifically, for the payment type "terminal code display", the authentication skip conditions of condition No. "SP3-3", "SP3-4", "SP4-1", "SP4-2" are given as an example and not a limitation. Not applicable is set as “×” for other authentication skip conditions, and “〇” is set as applicable for other authentication skip conditions.

The reason why the authentication skip condition of condition No. "SP3-3" is not applicable is marked as "×" because when the payment type is "terminal code display", the terminal 20 cannot obtain information about the scheduled payment amount, and the scheduled payment amount is not applicable. This is because it is not possible to determine whether or not it is within the appropriate range. However, since it is possible to determine whether the payment frequency is within an appropriate range, determining whether the scheduled payment amount is within an appropriate range may or may not be necessary. .

Similarly, the reason why the authentication skip condition of condition number "SP3-4" is marked as not applicable is "x" because the terminal 20 cannot obtain information regarding the scheduled payment amount, and the scheduled payment amount is less than or equal to the set amount (or This is because it is not possible to determine whether the amount is less than the amount.

In addition, the reason why the authentication skip conditions of condition Nos. "SP4-1" and "SP4-2" are not applicable and is marked "×" is because the payment type "terminal code display" means that the terminal 20 makes the purchase Because it is not possible to obtain information about the planned product, it is not possible to determine whether the planned purchase product is a daily consumer goods or whether there is a purchase history of the planned purchase product. be.

On the other hand, regarding the payment type "Terminal code reading", as an example and not a limitation, it is not applicable in principle to the authentication skip conditions of condition No. "SP4-1" and "SP4-2", but as mentioned above “×(〇)” is specified because it can be applied by alternative methods.

In addition, by way of example and not limitation, for each of the above authentication skip conditions, "importance" which is an index value indicating the degree of importance of the authentication skip condition ("priority level" indicating the degree to which the authentication skip condition is applied preferentially) ) is determined for each type of payment. As an example and not a limitation, the degree of importance is expressed in three levels from "A" to "C", with "A" being the most important and "C" being the least important. It is being

Specifically, regarding the payment type "terminal code display", condition numbers "SP1-1", "SP2-1", "SP2-4", "SP3-1", "SP3- The importance level "A" is set for the authentication skip conditions of "2", "SP5-1", and "SP6-1", and the importance level is set for the authentication skip conditions of condition Nos. "SP2-2" and "SP2-3". "B" is defined, and the importance level "C" is defined for the authentication skip condition of condition No. "SP1-2". In addition, since the authentication skip conditions of condition No. "SP3-3", "SP3-4", "SP4-1", and "SP4-2" are not applicable, "- (none)" is set for the importance level. It is being

In addition, regarding the payment type "Terminal code reading", the condition No. "SP2-1", "SP2-4", "SP3-4", "SP4-1", "SP4-2", The authentication skip condition of "SP6-1" has an importance level of "A", and the condition number is "SP1-1", "SP2-2", "SP2-3", "SP3-1", "SP3-2". ”, the authentication skip conditions of “SP5-1” are assigned an importance level of “B”, and the authentication skip conditions of condition Nos. “SP1-2” and “SP3-3” are assigned an importance level of “C”. There is.

Note that the above-mentioned importance setting is merely an example, and it goes without saying that the setting can be changed as appropriate. In addition, in the above, the applicability and importance are determined for each authentication skip condition (each condition No.), but instead, the applicability and importance are determined for each authentication skip condition category (condition category No.). You may or may not have to specify this.

Further, in this embodiment, the degree of importance is set in association with the authentication skip condition, but the setting of this degree of importance is not an essential requirement, and it is also possible not to set the degree of importance. In other words, the importance column does not need to be provided in the authentication skip condition data 2851 described above.
In this case, in the authentication skip determination process, by way of example and not limitation, the success or failure of the authentication skip conditions is determined in an arbitrary order, and if any of the authentication skip conditions is met, it is determined that the authentication process is to be skipped. Just do it.

The information indicated by the authentication skip condition category in the above authentication skip condition data 2851 and the information used to determine each authentication skip condition included in each category are information related to IMS money (not limited to, but an example of electronic money). include.

Specifically, for example, the category "SP1 (time)" includes information regarding the time when payment was made using IMS Money, and this information can be said to be information regarding IMS Money in a broad sense.
For example, the category "SP2 (store/location)" includes information about the place where the payment was made with IMS Money and information about the store where the payment was made with IMS Money, but in a broad sense, this information is This can be said to be information about IMS Money.
Further, for example, the category "SP3 (amount)" includes information regarding the amount of IMS Money, and this information can be said to be information regarding IMS Money in a broad sense.
Further, for example, the category "SP4 (product)" includes information about products purchased with IMS money, and this information can be said to be information about IMS money in a broad sense.

Note that the meaning of the term "information regarding..." is the same for other examples, so a description of each case will be omitted.

FIG. 3-9 is a diagram showing an example of the data structure of the payment data 2853.
The payment data 2853 includes the user ID, authentication password, payment application unlock password which is the password for unlocking the payment application, IMS points, balance, daily maximum set amount, and auto Charge settings, payment history data, authentication skip condition settings, and authentication skip condition user setting data are stored.

The payment history data stores the same data as the payment history data stored in the payment management data of this user ID, which is managed by the payment management database 157 of the server 10. This payment history data includes, by way of example and not limitation, that after a payment is made by the server 10, the payment date and time, payment store ID, payment store name, and payment amount are transmitted from the server 10 to the terminal 20. The history is stored as payment history data.

The authentication skip condition setting is a setting related to the authentication skip condition used by the own terminal 20 for authentication skip determination. Authentication skip condition settings include, by way of example and not limitation, "user settings" and "automatic settings."

"User Settings" is a setting to perform authentication skip judgment by applying authentication skip conditions determined based on the user's selection/determination operation of the terminal 20 from among the authentication skip conditions defined in the authentication skip condition data 2851. be.
“Automatic setting” is a setting in which authentication skip determination is performed using authentication skip conditions automatically determined by the terminal 20 from authentication skip conditions defined in authentication skip condition data 2851.

The authentication skip condition user setting data is setting data related to the above authentication skip condition setting "user setting", and an example of the data structure is shown in FIG. 3-10.
The authentication skip condition user setting data stores a condition category number, a condition number, a setting type, a condition category setting flag, and a condition setting flag in association with each other.

The condition category number and condition number defined in the authentication skip condition data 2851 are stored in the condition category number and condition number, respectively.

As the setting type, either "by condition category" or "by condition" is stored.
The setting type "by condition category" is a type for the user of the terminal 20 to set authentication skip conditions to be applied by condition category. In other words, when setting to apply authentication skip conditions to each category all at once, this setting type "by condition category" is used.
The setting type "by condition" is a type for the user of the terminal 20 to set authentication skip conditions to be applied for each condition. That is, when setting to apply the authentication skip condition to each condition individually, this setting type "by condition" is used.

The setting flag by condition category is a flag indicating whether or not to apply the authentication skip condition included in the condition category No. when the setting type is "by condition category". “ON” is set in association with the condition category number, and “OFF” is set in association with the condition category number for condition categories that are not applied.

The condition-specific setting flag is a flag that indicates whether or not to apply the authentication skip condition of the condition number when the setting type is “condition-specific.” For the conditions to be applied, “ "ON" is set, and for conditions that are not applied, "OFF" is set in association with the condition number. By way of example and not limitation, for categories in which the conditional category setting flag is set to "ON," all the conditional setting flags are also set to "ON."

(3) Functional configuration of store code reader device FIG. 2 shows an example of functions realized by the control unit 51 of the store code reader device 50 in this embodiment.
The store code reader device 50 has a store code reader device main processing section 511 and a store payment processing section 513 as functions realized by the control section 51.

Store code reader device main processing section 511 performs store code reader device main processing, which is a process for controlling store code reader device 50 in an integrated manner, according to store code reader device main processing program 551 stored in storage section 55. It has the ability to execute.

The store payment processing unit 513 has a function of executing store payment processing, which is processing related to payment at its own store, in accordance with the store payment processing program 5511 stored in the storage unit 55.

FIG. 2 shows an example of information stored in the storage unit 55 of the store code reader device 50 in this embodiment.
The storage unit 55 stores, by way of example and not limitation, a store code reader device main processing program 551 that is read by the control unit 51 and executed as the store code reader device main process. The store code reader device main processing program 551 also includes a store payment processing program 5511 as a subroutine program, which is read by the control unit 51 and executed as store payment processing.
The store payment process will be described in detail later using a flowchart.

<Payment method>
A payment method using a payment application in this embodiment will be described with reference to an example of a display screen displayed on the display unit 24 of the terminal 20.

(1) Payment type “Terminal code display”
FIGS. 3-11 to 3-14 are screen diagrams for explaining the flow of payment when authentication is not skipped in the payment type "terminal code display".

FIG. 3-11 is a diagram showing an example of a payment application screen displayed on the display unit 24 of the terminal 20.
This payment application screen is a display screen that is displayed when the payment application is started, and the name of the payment application "IMS Pay" is displayed at the top of the screen. The balance (here, "3000 yen") is displayed in the frame below, and a charge button for charging the amount is displayed next to it. Further, below that, a plurality of function icons corresponding to various functions of the payment application are displayed.

Among these function icons, the icon labeled "Code" is a "code icon" for acquiring a terminal display code from the server 10 when making a payment using the payment type "terminal code display". In addition, the icon labeled "Code reader" is a code reader (provided as a function of the payment application) that is used to read the terminal reading code on the terminal 20 when making a payment using the payment type "Read terminal code". This is a code reader icon for activating an application (hereinafter referred to as an "application code reader").

FIG. 3-12 is a diagram showing an example of an authentication screen displayed when the "code icon" is touched by the user of the terminal 20 on the payment application screen.
If it is not determined to skip the authentication process in the authentication skip determination process described later, this authentication screen is displayed.
On this authentication screen, the text "Password" (authentication password) and the message "Please enter the password you are currently using." are displayed, and below that, a password display that displays the password you entered is displayed. A field and a keyboard for entering a password are displayed.

FIG. 3-13 is a diagram showing an example of a terminal display code screen that is displayed when the authentication result is "OK" in the authentication processing based on the password input on the above authentication screen.
On this terminal display code screen, the word "code" is displayed at the top of the screen, and below it is an IMS point tab for setting the payment method and whether or not to use IMS points for payment. Displayed. Further, below that, as the terminal display code transmitted from the server 10 and received by the terminal 20, a terminal display code represented by a barcode and a terminal display code represented by a QR code are displayed. ing. Further, as described above, these terminal display codes have a validity period set therein, and the remaining time of the validity period is displayed in a countdown format in association with the terminal display code.

The user of the terminal 20 makes a payment by presenting the terminal display code screen to a store clerk at the code register 60 and having the store code reader device 50 read the terminal display code. In this case, the store code reader device 50 accesses the payment page based on the payment page URL included in the read terminal display code, and transmits information necessary for payment.

FIG. 3-14 is a diagram showing an example of a payment completion screen displayed on the terminal 20 when the payment by the server 10 is completed.
On this payment completion screen, you can see the text ``Payment Complete'' in the center of the terminal display code screen shown in Figure 3-13, along with the details from ``Payment History''. ” message and a “confirmation icon” to check the payment history are displayed in a pop-up format.

FIGS. 3-15 and 3-16 are screen diagrams for explaining the flow of payment in the case of the payment type "terminal code display" with authentication skip.
FIG. 3-15 shows the same payment application screen as in FIG. 3-11, and FIG. 3-16 shows the same terminal display code screen as in FIG. 3-13.

If the "code icon" is touched by the user of the terminal 20 on the payment application screen in Figure 3-15, and if it is determined to skip the authentication process in the authentication skip determination process described later, the terminal display in Figure 3-16 The display switches to the code screen for In other words, the display switches from the payment application screen to the terminal display code screen without displaying the authentication screen shown in FIG. 3-12.

(2) Payment type “Terminal code reading”
As described above, there are two types of payment type "terminal code reading": a case where a first type terminal reading code is read and a case where a second type terminal reading code is read. Each of these will be explained.

(2-1) Type 1 terminal reading code Figure 3-17 shows the same payment application screen as Figure 3-11, with the "code reader icon" among the function icons tapped. ing.
When the code reader icon is tapped by the user, the application code reader is activated and a reading standby screen as shown in FIG. 3-18 is displayed on the display unit 24. In this state, when the terminal 20 is moved so that the two-dimensional code is included within the frame at the center of the screen, the two-dimensional code is read by the application code reader.

FIG. 3-19 is a diagram showing an example of a display screen displayed on the display unit 24 when a two-dimensional code is read by an application code reader. It shows the condition.
When the first type terminal reading code is read by the terminal 20, the terminal 20 accesses the payment page based on the URL included in the read first type terminal reading code and transmits the information necessary for payment. do.

FIG. 3-20 is a diagram showing an example of a payment page screen displayed on the display unit 24 of the terminal 20.
On this payment page screen, at the top of the screen, you will see the store where you plan to make the payment (in this case, "XXX SHOP"), the date to make the payment (in this case, "2018/10/24"), and the scheduled payment amount (in this case, "480 yen)) is displayed. Below that, the payment method and an IMS points tab for setting whether to make a payment using IMS points are displayed. , a payment execution icon for executing the payment indicated as "Perform payment" is displayed.

FIG. 3-21 is a diagram showing an example of a payment completion screen that is displayed when the payment execution icon is tapped by the user of the terminal 20 on the payment page screen.
On this payment completion screen, in the center of the payment page screen, you can see the text ``Payment Complete'' and the details from ``Payment History''. ” message and a “confirmation icon” to check the payment history are displayed in a pop-up format.

(2-2) Type 2 terminal reading code Figures 3-22 to 3-24 show display screens similar to those in Figures 3-17 to 3-19.
FIG. 3-25 is a diagram showing an example of a scheduled payment amount input setting screen displayed when the terminal 20 accesses the server 10 after reading the type 2 terminal reading code.
This scheduled payment amount input setting screen displays the icon image of the user of the terminal 20 as well as the scheduled payment store (in this case, "XXX SHOP"), and below that, the payment schedule where the entered scheduled payment amount is displayed. An amount display field, a current balance, and a keyboard for inputting the scheduled payment amount are displayed.

On this scheduled payment amount input setting screen, for example, as shown in Figure 3-26, the user of the terminal 20 inputs the scheduled payment amount (here, "480 yen"), and the "completion icon" displayed below it. When is tapped, the keyboard is hidden, and a payment execution icon for executing the payment indicated as "Make payment" is displayed, for example, as shown in FIG. 3-27. When the payment execution icon is tapped by the user of the terminal 20, a payment completion screen is displayed, for example, as shown in 3-28.

<Processing>
3-29 to 3-32 are flowcharts showing an example of the flow of processing executed by each device in this embodiment.
In these figures, from the left side, a first payment application process, which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20, and a store payment process executed by the store payment processing unit 513 of the store code reader device 50. A first store payment process, which is an example of the above, and a first payment management process, which is an example of the payment management process executed by the payment management processing unit 113 of the server 10, are shown.

Each step in each process is indicated by a combination of uppercase letters and numbers, and the term step is omitted in this specification.
Furthermore, the flowchart described below is merely an example of the processing in this embodiment, and in the flowchart described below, some steps may not be executed, or additional steps may be inserted.

First, the payment application processing unit 213 of the terminal 20 receives a user's terminal payment operation on the input/output unit 23 (A1). Then, the payment application processing unit 213 determines the payment type based on the received terminal payment operation (A3).

If the payment type is "terminal code display" (A3: terminal code display), the terminal display code acquisition processing unit 2131 sends the terminal display code generation request information including the user ID to the server via the communication I/F 22. 10 (A5).

The server 10 determines whether or not the terminal display code generation request information has been received from the terminal 20 via the communication I/F 14 (C1), and if it is determined that it has been received (C1; Yes), the server 10 generates the terminal display code. The processing unit 1131 performs terminal display code generation processing (C3).

Specifically, by way of example and not limitation, random tokens are issued using a method (algorithm) for generating random tokens. Then, a terminal display code containing the access information and the issued token is generated. More specifically, for example, data consisting of a website URL string provided by the server 10 and a token string (for example, a parameter part starting with a "?" symbol) is encoded. , to generate a terminal display code represented by a two-dimensional code image. Further, the user ID included in the received terminal display code generation request information and the issued token are associated with each other and stored in the terminal display code management database 1591.

Next, the terminal display code transmission processing unit 1133 transmits the generated terminal display code to the terminal 20 via the communication I/F 14 (C5).

When the payment application processing unit 213 receives the terminal display code from the server 10 through the communication I/F 22 (A7), the payment application processing unit 213 executes the first authentication skip determination process according to the authentication skip determination process program 2845 stored in the storage unit 28. Execute (A9).

FIG. 3-33 is a flowchart illustrating an example of the flow of the first authentication skip determination process. Note that, in order to distinguish from the authentication skip determination process in other embodiments, this will be conveniently referred to as "first authentication skip determination process."

First, the authentication skip determination processing unit 2135 determines the payment type (D1). Then, if it is determined that the payment type is "terminal code display" (D1; terminal code display), the authentication skip determination processing unit 2135 determines the authentication skip condition setting stored in the payment data 2853 ( D3).

If it is determined that the authentication skip condition setting is "user setting" (D3; user setting), the authentication skip determination processing unit 2135 sets the authentication skip condition in the authentication skip condition user setting data stored in the payment data 2853. The authentication skip condition to be applied is determined based on the user settings and whether or not the authentication skip condition is applied as defined in "payment type: terminal code display" of the authentication skip condition data 2851 (D5).

Specifically, by way of example and not limitation, among the authentication skip conditions in which "〇" is stored in association with whether or not "payment type: terminal code display" is applied in the authentication skip condition data 2851, the authentication skip condition user settings In the data, the authentication skip condition included in the condition category where "By condition category" is stored in the setting type and "ON" is stored in the setting flag for each condition category, and "By condition" in the setting type. is stored, and the authentication skip condition in which "ON" is stored in the condition-specific setting flag is determined as the authentication skip condition to be applied.

Further, if it is determined that the authentication skip condition setting is "automatic setting" (D3; automatic setting), the authentication skip determination processing unit 2135 determines that the authentication skip condition setting is set in "payment type: terminal code display" of the authentication skip condition data 2851. The authentication skip condition to be applied is determined based on whether or not the authentication skip condition is applied and the degree of importance (priority) (D7).

Specifically, by way of example and not limitation, among the authentication skip conditions in which "〇" is stored in association with whether or not "payment type: terminal code display" is applied in the authentication skip condition data 2851, for example, if the importance level is " The authentication skip condition associated with “A” or “B” is determined as the authentication skip condition to be applied.

On the other hand, if it is determined that the payment type is "terminal code reading" (D1; terminal code reading), the authentication skip determination processing unit 2135 sets the authentication skip condition stored in the payment data 2853 of the storage unit 28. is determined (D9).

If it is determined that the authentication skip condition setting is "user setting" (D9; user setting), the authentication skip determination processing unit 2135 sets the authentication skip condition of the authentication skip condition user setting data stored in the payment data 2853. The authentication skip condition to be applied is determined based on the user settings and the application status defined for payment type: terminal code reading in the authentication skip condition data 2851 (D11).

Specifically, by way of example and not limitation, among the authentication skip conditions in which "〇" is stored in association with whether or not "payment type: terminal code reading" is applied in the authentication skip condition data 2851, the authentication skip condition user settings In the data, the authentication skip condition included in the condition category where "By condition category" is stored in the setting type and "ON" is stored in the setting flag for each condition category, and "By condition" in the setting type. is stored, and the authentication skip condition in which "ON" is stored in the condition-specific setting flag is determined as the authentication skip condition to be applied.

Further, if it is determined that the authentication skip condition setting is "automatic setting" (D9; automatic setting), the authentication skip determination processing unit 2135 determines that the authentication skip condition setting is set as "payment type: terminal code reading" in the authentication skip condition data 2851. The authentication skip condition to be applied is determined based on whether or not the authentication skip condition is applied and the degree of importance (priority) (D13).

Specifically, as an example and not a limitation, among the authentication skip conditions in which "〇" is stored in association with the payment type: application/non-application of terminal code reading in the authentication skip condition data 2851, for example, the importance level is "A". Alternatively, the authentication skip condition associated with "B" is determined as the authentication skip condition to be applied.

After D5, D7, D11, or D13, the authentication skip determination processing unit 2135 acquires information necessary for determining each determined authentication skip condition (D15). The information necessary to determine each authentication skip condition and the determination method thereof are as described above.

Thereafter, the authentication skip determination processing unit 2135 determines whether the authentication skip condition is successful or not (D17). Specifically, based on the information acquired in D15, the success or failure of each authentication skip condition determined in D5, D7, D11, or D13 is determined. Then, for example, if at least one authentication skip condition is satisfied, it is determined that the authentication process is to be skipped, and in other cases, it is determined that the authentication process is not to be skipped. Then, the authentication skip determination processing unit 2135 ends the first authentication skip determination process.

Note that the method for determining the authentication skip condition and the method for determining the success or failure of the authentication skip condition described above are merely examples, and are not limited thereto.

Specifically, by way of example and not limitation, only the authentication skip conditions associated with "A" in importance may or may not be determined as the authentication skip conditions to be applied. Furthermore, the authentication skip conditions with the importance level "C" may or may not be included in the applied authentication skip conditions.

Furthermore, as an example and not a limitation, for authentication skip conditions associated with the importance level "A", it is determined that the authentication process is skipped when at least one authentication skip condition is satisfied, but the importance level is "B". '' may or may not be determined to skip the authentication process when all the authentication skip conditions are satisfied.

Returning to the main process, the payment application processing unit 213 determines whether or not it has been determined to skip the authentication process in the first authentication skip determination process (A11). If it is determined that the authentication process is to be skipped (A11; Yes), the payment application processing unit 213 moves the process to A19.

On the other hand, if it is determined not to skip the authentication process (A11: No), the authentication processing unit 2137 performs the authentication process (A13). Specifically, an authentication screen is displayed on the display unit 24, and the user is prompted to input an authentication password. If the input authentication password matches the authentication password stored in the payment data 2853 of the storage unit 28, the authentication result is set as "OK". On the other hand, if the authentication passwords do not match, the authentication result is set as "NG".

If the authentication result is determined to be "NG" in the authentication process (A15; No), the payment application processing unit 213 executes error processing (A17). Specifically, for example, a notification is provided to prompt the user to input the authentication password again. The payment application processing unit 213 then returns the process to A13.

Thereafter, the payment application processing unit 213 causes the terminal display code to be displayed on the display unit 24 (A19). At this time, the payment application processing unit 213 sends a message such as a message (code reading instruction display) instructing the user of the terminal 20 to have the terminal display code read by the store code reader device 50 together with the terminal display code. It may or may not be displayed on the display section 24.

The store payment processing unit 513 of the store code reader device 50 receives a store payment operation performed by a store clerk on the input/output unit 52 (B1). Then, the store payment processing unit 513 determines whether the payment type is "terminal code display" based on the received store payment operation (B3).

If the payment type is "terminal code display" (B3; Yes), the store payment processing unit 513 performs a scheduled payment amount setting process (B5). Specifically, the amount of the product to be sold is set as the "scheduled payment amount" based on the amount input operation by the store clerk into the input/output unit 52.

Thereafter, the store payment processing unit 513 issues an instruction to read the terminal display code (B7). Specifically, for example, a message instructing the user to read the terminal display code may be displayed on the display unit 53, or a voice instructing the user to read the terminal display code may be outputted from the sound output unit 56. , notify the store clerk. In response to this terminal display code reading instruction notification, the store clerk prompts the user of the terminal 20 to present the terminal display code.

When the terminal display code displayed on the display unit 24 of the terminal 20 at A19 is read by the code reader 58 of the store code reader device 50 (B9), the store payment processing unit 513 performs code information acquisition processing (B11). . Specifically, data is decoded from the read terminal display code to obtain various information included in the read terminal display code.

Thereafter, the store payment processing unit 513 accesses the payment page through the communication I/F 54 based on the payment page URL obtained from the read terminal display code, and stores the store ID and the terminal display The second payment request information including the token obtained from the business code and the scheduled payment amount set in B5 is transmitted to the server 10 (B13).

When the payment management processing unit 113 receives the second payment request information from the store code reader device 50 via the communication I/F 14 (C9), it performs payment processing (C11). Specifically, by way of example and not limitation, users who are stored in association with the token included in the second payment request information received from the store code reader device 50 in the terminal display code management database 1591 of the storage unit 15 Identify the ID. Then, based on the balance stored in the payment management data of the specified user ID in the payment management database 157 of the storage unit 15, it is determined whether the scheduled payment amount can be paid. If the payment is possible, the scheduled payment amount is subtracted from the balance and updated, the payment history data is updated, and the payment result is marked as "successful". On the other hand, if the payment is not possible, the payment result is determined as "failure".
Note that the settled amount is paid to the store directly from the IMS operator (payment service operator) or through an agent.

Next, the payment management processing unit 113 determines the payment result (C13). If the payment result is "successful" (C13; success), the store payment result information transmission processing unit 1136 uses the communication I/F 14 to transmit the store payment success information as store payment result information to the store code reader device. 50 (C15). Similarly, the terminal payment result information transmission processing unit 1137 transmits the terminal payment success information to the terminal 20 as terminal payment result information via the communication I/F 14 (C17). The payment management processing unit 113 then ends the first payment management process.

On the other hand, if the payment result is "failure" (C13; failure), the store payment result information transmission processing unit 1136 uses the communication I/F 14 to transmit the store payment failure information as store payment result information and store code. The information is transmitted to the reader device 50 (C19). Similarly, the terminal payment result information transmission processing unit 1137 transmits the terminal payment failure information to the terminal 20 as terminal payment result information via the communication I/F 14 (C21). The payment management processing unit 113 then ends the first payment management process.

When the store payment processing unit 513 receives store payment result information from the server 10 through the communication I/F 54 (B15), it determines the payment result (B17), and if the payment result is "successful" (B17). ; success), the payment success notification process is performed (B19). Then, the store payment processing unit 513 ends the first store payment processing.

On the other hand, if the payment result is "failure" (B17; failure), the store payment processing unit 513 performs a payment failure notification process (B21). Then, the store payment processing unit 513 ends the first store payment processing.

When the payment application processing unit 213 receives terminal payment result information from the server 10 through the communication I/F 22 (A21), it determines the payment result (A23), and if the payment result is "successful" (A23). ; success), the payment success notification process is performed (A25).

Thereafter, the payment application processing unit 213 determines whether or not to display the payment history (A27). Specifically, by way of example and not limitation, when a user's payment history confirmation operation on the input/output unit 23 is detected, it is determined that the payment history is to be displayed.

If it is determined that the payment history is to be displayed (A27; Yes), the payment application processing unit 213 performs payment history display processing (A29). The payment application processing unit 213 then ends the first payment application process.

On the other hand, if the payment result is "failure" (A23; failure), the payment application processing unit 213 performs a payment failure notification process (A26). The payment application processing unit 213 then ends the first payment application process.

Next, if it is determined that the payment type is "terminal code reading" in A3 (A3; terminal code reading), the code reading processing unit 2133 activates the application code reader according to the user's operation and reads the terminal code reading code. A process of reading (a first type terminal reading code or a second type terminal reading code) is performed (A31).

Thereafter, the payment application processing unit 213 performs code information acquisition processing (A33). Specifically, data is decoded from the terminal reading code read by the application code reader, and various information contained in the read terminal reading code is obtained.

Thereafter, the payment application processing unit 213 accesses the payment page through the communication I/F 22 based on the payment page URL obtained from the read terminal reading code (A35).

The payment management processing unit 113 determines payment schedule information in response to access to the payment page from the terminal 20 (C33). Specifically, the information stored in association with this payment page is obtained by referring to the terminal reading code management database 1593. Then, the payment management processing unit 113 transmits payment schedule information according to the determination result to the terminal 20 via the communication I/F 14 (C35).

In this case, if the information associated with the payment page is information about a store that operates the type 1 terminal reading code, the payment management processing unit 113 includes the store scheduled for payment and the scheduled payment amount. The first type payment schedule information is transmitted to the terminal 20 via communication I/14. On the other hand, if the information associated with the payment page is information about a store that operates the second type terminal reading code, the payment management processing unit 113 stores the second type payment schedule information (including the store scheduled for payment). ) is sent to the terminal 20 via communication I/14.

Upon receiving the payment schedule information from the server 10 through the communication I/F 22 (A37), the payment application processing unit 213 determines the type of the received payment schedule information (A39). If the type of payment schedule information is "second type payment schedule information" (A39; second type), a scheduled payment amount setting process is performed (A41). Specifically, the total amount of the products to be purchased is set as the "scheduled payment amount" based on the amount input operation by the user of the own terminal 20 to the input/output unit 23.

After A41, or if the type of payment schedule information is “2nd type payment schedule information” (A39; 1st type), the payment application processing unit 213 performs the authentication skip stored in the storage unit 28. A first authentication skip determination process is executed according to the determination process program 2845 (A9). The payment application processing unit 213 then executes the processes A11 to A17.

Thereafter, the payment application processing unit 213 transmits first payment request information including, by way of example and not limitation, a user ID and payment confirmation information to the server 10 on the payment page (A43). However, when the process of A41 is executed, the set scheduled payment amount is also included in the first payment request information and transmitted to the server 10. Then, the payment application processing unit 213 performs the processing from A21 onwards.

When the payment management processing unit 113 receives the first payment request information from the terminal 20 via the communication I/F 14 (C37), it performs payment processing (C11). Then, the payment management processing unit 113 moves the processing to C13 and subsequent steps.

If it is determined in B5 that the payment type is not "terminal code display"(B3; No), the store payment processing unit 513 moves the process to B15.
A case where the payment type is not "terminal code display" is a case where the payment type is "terminal code reading". In this case, by way of example and not limitation, the store clerk instructs the user of the terminal 20 to read the terminal reading code, and the user of the terminal 20 activates the application code reader of the terminal 20 to read the terminal reading code. All you have to do is read the code.

Note that, as described above, only one type of code among the first type terminal reading code and the second type terminal reading code may be used as the terminal reading code.
In this case, only one type of payment schedule information is sent from the server 10 to the terminal 20 in step C35 in Figure 3-31, and there is no need to determine the type of payment schedule information on the terminal 20. Step A39 can be deleted.
Further, if only the first type terminal reading code is applied, it is not necessary to set the scheduled payment amount on the terminal 20, so step A41 in FIG. 3-31 can also be deleted.

<Effects of the first embodiment>
The first embodiment performs an authentication process (an example of a display process, not a limitation) for an electronic payment (an example of a payment, not a limitation) for a user of the terminal 20, and based on the result of the authentication process, the IMS Money A terminal 20 that receives information regarding a payment using electronic money (an example, but not a limitation) through a communication I/F 22 (an example, but not a limitation, of a communication unit of a terminal) authenticates a user of the terminal using an authentication password (an example, but not a limitation) of a terminal communication unit. (Example of authentication information for authentication) Then, the terminal 20 performs an authentication skip determination based on the acquired information, and if the authentication skip condition is satisfied, the terminal 20 does not perform the authentication process, and the server 10 performs the payment result information (not limited to, regarding payment using electronic money). An example of information) is shown in the figure.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can easily receive information regarding the payment using electronic money without performing display processing related to execution of authentication for the user of the terminal. . In addition, when making payments using electronic money, the terminal acquires information different from the authentication information used to authenticate the terminal user, which eliminates the need for display processing, reducing the processing load on the terminal. . Further, when making a payment using electronic money, it is not necessary to perform display processing every time, so the payment can be made quickly and smoothly, improving convenience for the user.

Further, in the first embodiment, the information different from the authentication password (an example of information different from the authentication information, not limited to) includes information about IMS money (not limited to, an example of information about electronic money). It shows the configuration.
As an example of the effect obtained by such a configuration, when a terminal makes a payment using electronic money, by acquiring information regarding electronic money, the terminal does not need to perform display processing related to the execution of authentication for the terminal user. Processing load can be reduced.

Further, in the first embodiment, the above information regarding IMS money is information regarding the amount of IMS money associated with the terminal 20 or the user of the terminal 20 (without limitation, information regarding the amount of IMS money associated with the terminal or the user of the terminal The figure shows a configuration including an example of information regarding the amount of electronic money.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can obtain information regarding the amount of electronic money, thereby eliminating the need for display processing related to execution of authentication for the user of the terminal. The processing load on the terminal can be reduced. Further, since the information regarding the amount of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform processing related to payment based on the information regarding the appropriate amount of electronic money.

Further, in the first embodiment, the above information regarding the amount of IMS money includes information regarding the daily upper limit setting amount (not a limitation, but an example of information regarding the set amount of electronic money). .
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information regarding the set amount of electronic money, thereby eliminating the need for display processing related to execution of authentication for the terminal user. Therefore, the processing load on the terminal can be reduced.

Further, the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process until the daily upper limit set amount (an example of a set amount, not a limitation) is exceeded.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal does not display information regarding the execution of authentication until the set amount of electronic money is exceeded, which reduces the processing load on the terminal. At the same time, it is possible to improve user convenience. On the other hand, when making a payment using electronic money, if the set amount is exceeded, a display regarding the execution of authentication may be displayed, so that the user can be alerted to the fact that the set amount has been exceeded.

Further, in the first embodiment, the above information regarding the amount of IMS Money is information regarding the balance of IMS Money associated with the terminal 20 or the user of the terminal 20 (without limitation, information regarding the balance of IMS Money associated with the terminal or the user of the terminal). The figure shows a configuration including an example of information regarding the balance of electronic money.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can obtain information regarding the balance of electronic money, thereby eliminating the need for display processing related to execution of authentication for the user of the terminal. The processing load on the terminal can be reduced. Furthermore, since the information regarding the balance of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform processing related to payment based on the information regarding the appropriate balance of electronic money.

Furthermore, the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process when the balance of IMS money is less than or equal to the set amount.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal does not display information regarding the execution of authentication if the balance of electronic money is less than or equal to the set amount. Therefore, the processing load on the terminal can be reduced. In addition, for example, if the balance of electronic money is small, high-value payments cannot be made and the risk is considered to be low. Therefore, by not displaying information regarding the execution of authentication, it is possible to ensure safety and improve user convenience. can improve sex.

Further, in the first embodiment, if the terminal 20 is set to auto-charge (not limited to a setting where electronic money is automatically deposited into the terminal), the balance of IMS money is less than or equal to the set amount. Alternatively, a configuration is shown in which authentication processing is performed when the amount is less than a set amount.
As an example of the effect obtained by such a configuration, electronic money is automatically deposited into the terminal when the electronic money on the terminal becomes less than or equal to the set amount. In this case, if the amount becomes small, electronic money is automatically deposited into the terminal, making it possible to make large payments, which poses a risk. Therefore, by displaying information regarding the execution of authentication, it is possible to alert the user that a large amount of payment will be possible.

Furthermore, in the first embodiment, the above-mentioned information regarding IMS money includes information regarding the frequency or number of payments made using IMS money (without limitation, information regarding the frequency or number of times payments were made using electronic money). It shows.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information regarding the frequency or number of payments made using electronic money, and thereby performs display processing regarding execution of authentication for the user of the terminal. This reduces the processing load on the terminal. In addition, for example, if the frequency of payments using electronic money is high or the number of times is large, there is a high possibility that the same user has made payments using electronic money, and the risk is considered to be low, so the display processing By avoiding this, it is possible to improve user convenience while ensuring safety.

Furthermore, the first embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information regarding the date and time of final payment using IMS money (not limited to this, but an example of information regarding the time when payment was made using electronic money).
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information regarding the time when the payment was made using electronic money, thereby eliminating the need for display processing related to the execution of authentication for the terminal user. Therefore, the processing load on the terminal can be reduced.

Furthermore, the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process if the set time has elapsed since the final payment date and time using IMS money.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal does not need to display information regarding the execution of authentication if it is within the set time from the time when the payment was made using electronic money. The processing load on the terminal can be reduced. For example, if a long period of time has not passed since a payment was made using electronic money, there is a high possibility that the same user will make the payment again, and the risk is considered to be low, so no information regarding the execution of authentication will be displayed. This makes it possible to improve user convenience while ensuring safety.

Furthermore, the first embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information regarding a place where a payment is made using IMS money (not limited to information regarding a place where a payment is made using electronic money).
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can obtain information regarding the place where the payment was made using electronic money, thereby eliminating the need for display processing related to execution of authentication for the terminal user. Therefore, the processing load on the terminal can be reduced.

Furthermore, in the first embodiment, the above information regarding the place where the payment was made using IMS Money includes information regarding the store where the payment was made using IMS Money (not limited to information regarding the store where the payment was made using electronic money). It shows the configuration.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information about the store where the payment was made using electronic money, thereby eliminating the need for display processing related to execution of authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.

Further, in the first embodiment, the terminal 20 uses the location information of the store where the payment was made using IMS money (not limited to this, but is an example of information regarding the place where the payment was made using electronic money) and the location calculation processing unit 217. This shows a configuration in which authentication processing is not performed based on the location information of the terminal 20 (not limited to, but an example of information related to the location of the terminal).
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal displays information regarding the execution of authentication based on information about the store where the payment was made using electronic money and information about the location of the terminal. Therefore, the processing load on the terminal can be reduced. In addition, for example, if the location of the terminal is not far from a store where the user made a payment using electronic money in the past, there is a high possibility that the user is attempting to make a payment at the same store, and the risk is considered to be low. By not displaying the execution information, it is possible to improve user convenience while ensuring safety.

In addition, in the first embodiment, the above information regarding IMS Money is information regarding the place where the authentication for making the IMS Money payment was performed (not limited to the place where the authentication was performed for making the electronic money payment). This shows a configuration including an example of information about places visited.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information regarding the location where the authentication for making the electronic money payment was performed, thereby improving the authentication for the terminal user. Since there is no need to perform display processing related to execution, the processing load on the terminal can be reduced. Also, for example, if it is a place where authentication was performed for electronic money payments in the past, there is a high possibility that the same user will be authenticated again, and the risk is considered to be low. By not performing display processing, it is possible to improve user convenience while ensuring safety.

Furthermore, in the first embodiment, the information different from the authentication password described above includes information regarding the location.
As an example of the effect obtained by such a configuration, when a terminal makes a payment using electronic money, by acquiring information about the location, the terminal does not have to perform display processing related to the execution of authentication for the terminal user. The load can be reduced.

Further, in the first embodiment, the above-mentioned information regarding the location includes information regarding the location of the store where the product is purchased.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can obtain information regarding the place where the product is purchased, thereby eliminating the need for display processing related to the execution of authentication for the terminal user. , the processing load on the terminal can be reduced. In addition, information regarding the place where a product is purchased can be used, for example, to determine whether the location is a store that sells low-priced products such as daily necessities, and to perform authentication for the terminal user. This can be used as a guideline for whether or not to do so.

Furthermore, in the first embodiment, the information regarding the place where the product is purchased includes information regarding the store where the product is sold.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can obtain information about the store that sells the product, thereby eliminating the need for display processing related to the execution of authentication for the terminal user. , the processing load on the terminal can be reduced. In addition, information about stores that sell products can be used, for example, to determine whether the store sells low-priced products such as daily necessities, and whether authentication should be performed for the terminal user. It can be used as a guideline.

Further, in the first embodiment, the terminal 20 does not perform the authentication process when the scheduled payment store is a set store or a store in the first specific industry (not limited to, but an example of the first location). A configuration is shown in which authentication processing is performed until a set time elapses from the payment date and time at a store (not limited to, but an example of a second location) of a second specific industry different from the store.
As an example of the effect obtained by such a configuration, when the terminal acquires information regarding the first location when making a payment using electronic money, the terminal does not display information regarding the execution of authentication; If information regarding location 2 is obtained, a display regarding execution of authentication will be displayed until a set time has elapsed after payment is made at the second location using electronic money. In the case where the user leaves behind the terminal or loses the terminal at a second location, it is possible to prevent fraudulent payments from being made by a third party who has acquired the terminal.

Furthermore, in the first embodiment, the information different from the authentication password described above includes information regarding the product.
As an example of the effect obtained by such a configuration, when the terminal makes a payment using electronic money, by acquiring information about the product, the terminal does not have to perform display processing related to the execution of authentication for the terminal user. The load can be reduced. Furthermore, since it is possible to determine whether a high-priced product or a low-priced product has been purchased based on the information regarding the product, it can be used as a guideline for whether or not to perform authentication for the user of the terminal.

Further, in the first embodiment, information different from the above authentication password is information related to the terminal 20 or the settings of the payment application stored in the terminal 20 (without limitation, information related to the terminal or the settings of the application stored in the terminal). (Example of information)
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information regarding the settings of the terminal or an application stored in the terminal, and thereby performs display processing related to the execution of authentication for the terminal user. This reduces the processing load on the terminal. Further, for example, if the information regarding the settings of the terminal or the application stored in the terminal is information set by the user, the user's intention can be respected and the user's convenience can be improved.

In addition, in the first embodiment, information different from the authentication password described above is information set on the terminal 20 indicating whether or not the terminal 20 is locked (not limited to, information set on the terminal, (Example of information regarding security) is shown.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires the information set on the terminal regarding the security of the terminal, so that the terminal does not display processing related to the execution of authentication for the terminal user. This reduces the processing load on the terminal. Further, for example, if the information related to the security of the terminal is information related to authentication of the user of the terminal, convenience for the user can be improved by omitting display processing related to execution of authentication for the user of the terminal.

Further, in the first embodiment, the information different from the above-mentioned authentication password is information on the terminal-side authentication settings set in the terminal 20 or information on the authentication settings for payment set in the payment application stored in the terminal 20. A configuration including information (an example, but not limited to, information regarding skipping execution of authentication set in a terminal or an application stored in the terminal) is shown.
As an example of the effect obtained by such a configuration, the terminal acquires information regarding skipping the execution of authentication set in the terminal or an application stored in the terminal when making a payment using electronic money. Since there is no need to perform display processing related to the execution of authentication for the user of the terminal, the processing load on the terminal can be reduced.

Further, in the first embodiment, the information different from the above-mentioned authentication password includes information sent from the server 10 related to payments using IMS money (not limited to this, but an example of a server that manages payments using electronic money). It shows.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal acquires information sent from a server related to the payment using electronic money, and thereby performs display processing related to execution of authentication for the user of the terminal. This reduces the processing load on the terminal.

In addition, in the first embodiment, the terminal 20 may not execute payment processing based on information different from the above-mentioned authentication password, and the terminal display code (not limited to An example of code information for making a payment using electronic money is displayed on the display unit 24, and based on reading of the terminal display code by the code reader 58 (not limited to, but an example of a code reader) of the store code reader device 50. , shows a configuration in which information on payment results using IMS money is received by the communication I/F 22.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can simply read the code information for making the payment using electronic money displayed in the display area of the terminal using a code reader. You can easily receive payment information.

Further, in the first embodiment, the terminal 20 sends a message such as a message instructing the user of the terminal 20 to read the code for terminal display with the code reader 58 of the store code reader device 50 (not limited to reading the code information). An example of a display related to the above is displayed on the display unit 24, and information different from the authentication password is obtained based on reading of the terminal reading code by the code reader 58 of the store code reader device 50.
As an example of the effect obtained by such a configuration, the terminal can notify the user of the terminal of information regarding reading of code information. Further, when making a payment using electronic money, the terminal can easily obtain information different from authentication information by simply having a code reader read the code information displayed in the display area of the terminal.

Furthermore, the first embodiment shows a configuration in which the information different from the authentication password includes the scheduled payment amount (not limited to this, but an example of information regarding the amount of the product to be purchased and the total amount).
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal simply reads the code information displayed in the display area of the terminal with a code reader, and the terminal displays information regarding the amount and total amount of the product to be purchased. can be easily obtained.

Furthermore, the first embodiment shows a configuration in which the terminal 20 does not perform the authentication process when the scheduled payment amount is less than or equal to the set amount.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, if the total amount of the purchased product is less than or equal to the set amount set by the terminal, the terminal will be able to perform authentication. Since no display is performed, user convenience can be improved. Additionally, if the total amount of purchased products is low, the risk is considered to be low, so by not displaying information regarding the execution of authentication, it is possible to improve user convenience while ensuring safety. .

Further, in the first embodiment, when the terminal 20 has a purchase history of the product to be purchased (an example, not limited to, when the product matches a product that the user of the terminal has purchased at least once), the terminal 20 performs the authentication process. Shows no configuration.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, if the product matches a product that the user of the terminal has purchased more than once, the terminal does not display information regarding the execution of authentication, which increases the convenience of the user. can improve sex. Furthermore, since the risk is considered to be low if the same product is being purchased, by not displaying information regarding the execution of authentication, it is possible to improve convenience for the user while ensuring safety.

Further, in the first embodiment, the terminal 20 uses a password different from the authentication password transmitted from the server 10 that manages payment using IMS money based on reading of a terminal display code (an example of code information, not limited to). A configuration in which information is received and acquired by the communication I/F 22 is shown.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the terminal can easily retrieve information different from the authentication information sent from the server that manages the electronic money payment by simply reading the code information. can be obtained.

Further, in the first embodiment, the information regarding the payment using IMS Money includes information sent from the server 10 (an example of an external server, not limited to) indicating that the payment was made using IMS Money. It shows the configuration.
As an example of the effect obtained by such a configuration, the terminal can obtain information indicating that a payment has been made using electronic money from an external server.

Further, in the first embodiment, when the terminal 20 that performs authentication regarding the payment of the user of the terminal 20 acquires information necessary for making an authentication skip determination, and the acquired information does not satisfy the authentication skip condition, the terminal 20 The communication I/F 22 performs authentication processing for the user, and receives information regarding IMS money based on the result of the authentication processing. On the other hand, when the acquired information satisfies the authentication skip condition, a configuration is shown in which information regarding IMS money is received by the communication I/F 22 without performing authentication processing for the user of the terminal 20.
As an example of the effect obtained by such a configuration, when the information acquired by the terminal satisfies the conditions, unlike when the conditions are not met, processing related to authentication for the terminal user is not executed, so the processing load on the terminal is reduced. It can be reduced. Furthermore, since the user of the terminal does not have to perform operations necessary for authentication, convenience for the user can be improved.

<First modification (1)>
In the first embodiment, the type of authentication for the user of the terminal 20 is password authentication, and the display process related to the execution of this authentication is the process of displaying an authentication screen for inputting the authentication password, but the present invention is not limited to this. In addition, for example, the type of authentication for the user of the terminal 20 may be biometric authentication such as face authentication, fingerprint authentication, voice authentication, etc., and the process of displaying the authentication screen necessary for performing these biometric authentications may be performed by the terminal. Display processing related to execution of user authentication may or may not be performed.

Furthermore, by way of example and not limitation, the process of displaying an authentication screen in the authentication process for acquiring an account such as a user ID for using a payment service may be made to be a display process related to the execution of authentication for the user of the terminal. You may or may not. Then, when the result of this authentication process is "OK", the terminal 20 may receive the account information for using the payment service from the server 10 as information regarding the payment using electronic money. It's okay and you don't have to.

<Effects of first modification (1)>
As an example of the effects of this modification, the terminal can easily display information regarding payments using electronic money, without performing display processing regarding the execution of authentication to the terminal user, even for authentication other than authentication using an authentication password. can be received.

Further, the terminal can easily acquire information necessary for using the payment service as information regarding payment using electronic money, without performing display processing related to execution of authentication for the user of the terminal.

<First modification (2)>
In the first embodiment, the electronic money is described as IMS money, but it is not limited to this. Electronic money is not limited to IMS money, but includes, for example and without limitation, so-called virtual currency, in-game currency, gift codes sent (presented) as gifts from users of other terminals 20, and various other types including the above-mentioned IMS points. The concept can include all payment methods that users can use as an alternative to cash, such as points sent (presented) to users through a point service.

<Effects of first modification (2)>
As an example of the effect obtained by this modification, when a terminal makes a payment using electronic money different from the electronic money associated with the IMS, the terminal can perform a display process related to the execution of authentication for the user of the terminal. Information can be easily received.

<First modification (3)>
In the first embodiment, the terminal display code and the terminal reading code are each described as a two-dimensional code, but the present invention is not limited to this. At least one of the terminal display code and the terminal reading code may or may not be the aforementioned one-dimensional code (by way of example, but not limitation) as described above, by way of example and not limitation.

In addition, at least one of the terminal display code and the terminal reading code is a character code represented by a character string of information stored in the code, and the terminal display code is read with a camera in the store and recognized as a character. However, the terminal reading code may or may not be read by the camera 27 of the terminal 20 to recognize the characters and obtain the information contained in each code.

<Effects of first modification (3)>
As an example of the effect of this modification, it is possible to realize terminal payment based on a terminal display code or a terminal reading code that is different from a two-dimensional code. Further, even if the terminal or store code reader device does not support two-dimensional codes, payment using electronic money can be realized.

<First modification (4)>
In the first embodiment, information regarding the payment transmitted from the server 10 is stored in the storage unit 28 of the terminal 20 as payment history data, and the terminal 20 determines whether to skip authentication based on the information regarding the payment included in this payment history data. However, it is not limited to this.

Specifically, payment history data may not be stored in the storage unit 28 of the terminal 20. In this case, the terminal 20 may or may not request information necessary for the authentication skip determination from the server 10 and perform the authentication skip determination based on the information acquired from the server 10.

<Effects of first modification (4)>
As an example of the effect obtained by this modification, since there is no need to store information regarding the history of payments using electronic money in the terminal, the storage capacity of the terminal can be saved.

<First modification (5)>
In the first embodiment, the store location information is included in the store data 2855 distributed from the server 10 to the terminal 20, and the terminal 20 uses the store location information included in the store data 2855 and the information calculated by the location calculation processing unit 217. The authentication skip determination may or may not be performed based on the location information of the terminal 20 (hereinafter referred to as "terminal location information").

Specifically, for example, when determining the authentication skip condition of "Payment scheduled store is set store" of condition No. "SP2-2" included in condition category No. "SP2", the latest calculated position of the terminal 20 is , it can be determined whether the location matches the location of the set store stored in the store data 2855.
The same applies to other authentication skip conditions related to stores and locations.

<Effects of first modification (5)>
As an example of the effect obtained by this modification, the terminal can easily determine whether the authentication skip condition is satisfied based on the terminal location information calculated by its own terminal 20 and the store location information acquired from the outside. can.

<First modification (6)>
In the first embodiment, the daily upper limit set amount is set as a threshold value for the total amount of settled amounts (settled amounts) in that day, but the present invention is not limited to this.

Specifically, as an example and not a limitation, the daily upper limit setting amount is the sum of the total amount of the settled amount for that day (settlement amount) and the amount that is about to be settled (scheduled settlement amount). The upper limit amount may or may not be set as the threshold amount.

Furthermore, the upper limit setting amount does not necessarily have to be the upper limit setting amount for one day, but may be the upper limit setting amount for a predetermined period in the past (the past week, the past two weeks, the past month, etc.). You don't have to.

In addition, the upper limit set amount is the amount set for the amount to be paid from now on (scheduled payment amount), that is, the amount to be paid at one time, and the authentication skip is set when the "scheduled payment amount is less than or equal to the set amount (or less than the set amount)" It is also possible to perform authentication skip determination based on conditions. By doing so, the authentication process can be skipped when the user of the terminal 20 purchases a low-priced product.

<Effects of first modification (6)>
As an example of the effect obtained by this modification, whether to display information regarding the execution of authentication by taking into account not only the amount paid in the past (settlement amount) but also the amount to be paid in the future (scheduled payment amount). can be determined.

Furthermore, user convenience can be improved by not displaying information regarding execution of authentication until the amount of one payment exceeds a set amount.

<First modification (7)>
The various authentication skip conditions described in the first embodiment are merely examples, and can be added, deleted, or changed as appropriate.

Specifically, as an example and not a limitation, the authentication skip condition of condition number "SP1-1" that "the current date and time is within the set time from the last payment date and time" is changed to "the current date and time is within the set time from the last authentication date and time". It is also possible to do this. For example, after the user of the terminal 20 performs authentication on the terminal 20 when purchasing a certain product (for example, a lunch box), the user of the terminal 20 immediately authenticates with the terminal 20 to purchase another product (for example, coffee). This is because there may be cases where authentication is required.

In addition, the above-mentioned "last authentication date and time" is not necessarily limited to the date and time when the last authentication for payment was performed, and is not limited to, but is used as an example, and is not limited to, for personal remittance of IMS Money, which will be described later in the fourth embodiment. the date and time when the last authentication for remittance was carried out, the last time when the authentication to unlock the OS side of the terminal 20 was carried out, and the last time when the authentication to unlock the payment application side was carried out. The date and time when a type of authentication different from payment authentication was last performed, such as the date and time when the authentication was performed, can also be set as the "last authentication date and time" in the above authentication skip condition.

In addition, as an example and not a limitation, the "last payment date and time" in the authentication skip condition of condition No. "SP1-1" may be changed to the "last charge date and time" which is the latest date and time when IMS Money was charged by the user, or It can also be set as the "last payment-related operation date and time" which is the latest date and time when a user operation related to payment was performed within the application. If not much time has passed since the last time IMS Money was charged, it is likely that the user has charged IMS Money for payment, so it is reasonable to skip the authentication process. Additionally, if a long period of time has not passed since the last user operation related to payment within the payment application, there is a high possibility that the user performed the operation with the intention of making a payment, so the authentication process It is reasonable to skip it.

Further, the "set time period" in the authentication skip condition of condition No. "SP1-2" can be a concept that includes a specific day of the week or a specific date. By way of example and not limitation, Saturday or Sunday may be set as the specific day of the week. This is because on Saturdays and Sundays, many users go out for shopping or eating, and there are many opportunities for payments to be made. Furthermore, Christmas (including Christmas Eve) or the third day of the New Year may be set as the specific date. This is because on Christmas, many users go out to buy presents and have dinner, and on the third day of the month, many users go out to sell their first purchases, and each of them tends to have more opportunities to make payments.

Furthermore, there is also a risk that the user of the terminal 20 may use his or her terminal 20 to be used by a third party to purchase an expensive product and then exchange the purchase for cash. Therefore, as an example and not a limitation, it is possible to add an authentication skip condition such that "the store scheduled for payment is not a store that sells products that are easily redeemable for cash." Examples of products that are easily redeemable for cash include products such as jewelry and watches.If the payment is scheduled to be made at a store that sells such products (such as a jewelry store or a watch store), please use the terminal 20 to make a payment. It is possible to prevent the authentication process from being skipped.

It is also possible to add authentication skip conditions related to the weather. For example, on rainy or snowy days, the number of users using public transportation increases, so the risk of leaving the terminal 20 behind increases. For this reason, by way of example and not limitation, an authentication skip condition such as "the weather on that day is not raining or snowing" may be added to prevent the authentication process from being skipped on rainy or snowy days.

<Effects of first modification (7)>
As an example of the effect obtained by this modification, when making a payment using electronic money, the terminal will not only be able to perform payment authentication within the set time from the last time the payment authentication was performed, but also when the payment authentication is User convenience can be further improved by not displaying information regarding the execution of authentication even if a set time has elapsed since the last time a different type of authentication was performed.

In addition, when making a payment using electronic money, if it is within the set time from the last time the electronic money was deposited, or within the set time from the last time the payment-related operation was performed within the application. In this case, the user's convenience can be further improved by not displaying information regarding the execution of authentication.

Further, by not displaying information regarding execution of authentication on a specific day of the week or on a specific date, user convenience can be further improved.

In addition, by not performing display processing related to authentication for the terminal user based on information that takes into account the user's risk, it is possible to achieve appropriate payment that takes into account the balance between user convenience and risk. be able to.

<First modification (8)>
In the process of FIG. 3-29 described in the first embodiment, when the payment type is "terminal code display", the timing after the terminal 20 receives the terminal display code from the server 10 (after A7) Although the first authentication skip determination process is performed in this example, the present invention is not limited thereto.

As an example and not a limitation, the first authentication skip determination process is performed before the terminal 20 transmits the terminal display code generation request information to the server 10 (before A5 in FIG. 3-29). You may or may not need to do so.

Furthermore, by way of example and not limitation, after the terminal 20 transmits the terminal display code generation request information to the server 10 (A7 in FIG. 3-29), the terminal display code is immediately transmitted from the server 10 to the terminal 20. Instead, the authentication skip determination process may or may not be performed before the terminal display code is transmitted from the server 10 to the terminal 20.

Specifically, after receiving the terminal display code generation request information transmitted from the terminal 20 (C1 in FIG. 3-29; Yes), the server 10 sends authentication request information to the terminal 20 to request authentication. Send. Then, the terminal 20 performs the first authentication skip determination process at a timing after receiving this authentication request information from the server 10.

If it is determined that the authentication process is to be skipped, the terminal 20 skips the authentication process and transmits authentication skip execution information indicating that the authentication process has been skipped to the server 10. On the other hand, if it is determined not to skip the authentication process, the terminal 20 performs the authentication process, and if the authentication result is "OK", sends authentication success information indicating that the authentication was successful to the server 10. do. Then, after receiving either the authentication skip execution information or the authentication success information from the terminal 20, the server 10 performs a terminal display code generation process to generate a terminal display code (C3 in FIG. 3-29). ), and transmits the generated terminal display code to the terminal 20 (C5 in FIG. 3-29).

In this case, after the server 10 receives the terminal display code generation request information transmitted from the terminal 20 (C1 in FIG. 3-29; Yes), the server 10 performs the terminal display code generation process and generates the terminal display code. It is also possible to generate the authentication request information (C3 in FIG. 3-29) and then transmit the authentication request information to the terminal 20.

As described above, the timing at which the authentication skip determination process is performed on the terminal 20 side can be broadly divided into any of three timings.

<Effects of first modification (8)>
As an example of the effect obtained by this modified example, when making a payment using electronic money, the terminal can, at any one of a plurality of timings, use authentication information different from the authentication information for authenticating the terminal user. It is possible to determine whether or not to execute display processing related to execution of authentication for a user.

<First modification (9)>
In the above embodiment, information regarding the product to be purchased is not sent from the server 10 to the terminal 20 for both payment types "terminal code display" and "read terminal code", and the terminal 20 acquires information regarding the product to be purchased. Although this is not possible, it is also possible for the terminal 20 to acquire information on the product to be purchased, for example, by the following method.

Specifically, by way of example and not limitation, a camera provided as a function of a payment application (hereinafter referred to as an "application camera"), or an imaging device (or an imaging unit) such as a camera 27 provided in the terminal 20, etc. ) is stored in the storage unit 28 of the terminal 20 to enable the type of product to be identified based on the photographed image taken by the user.

In the payment type "terminal code display", for example, before A1 of the first payment application process in FIG. Take an image of. That is, the user of the terminal 20 uses the application camera or the camera 27 to take an image of the product to be purchased at the code register 60 of the store. Then, the terminal 20 performs a product type identification process to identify the type of product from the photographed image (hereinafter referred to as "photographed image"). Then, the terminal 20 performs the process of "A3; display terminal code to A7", and then performs the first authentication skip determination process (A9).

Similarly, regarding the payment type "read terminal code", for example, before A1 of the first payment application process in FIG. Take an image of the planned product. The terminal 20 then performs product type identification processing to identify the type of product from the captured image. Then, the terminal 20 performs the first authentication skip determination process after performing the process of "A3; Read terminal code to A41" (A9).

FIG. 3-34 is a diagram showing an example of authentication skip condition data 2851 in this case. This data structure is similar to the authentication skip condition data 2851 in FIG. 3-8, but the difference is in the part surrounded by a thick black frame.

Specifically, regarding the authentication skip condition of "Product to be purchased is a daily consumer goods" in Condition No. "SP4-1", the application status for both payment types "Terminal code display" and "Terminal code reading" is set as " 〇” is specified. This is because by using the above method, it becomes possible to identify the type of product on the terminal 20, so based on the identified type of product, it is possible to determine whether the product to be purchased is a daily consumer good or not. This is because it can be determined. Further, the importance level "B" is set for the payment type "terminal code display", and the importance level "A" is set for the payment type "terminal code reading".

In addition, regarding the authentication skip condition of condition No. "SP4-2" of "there is a purchase history of the product to be purchased", "〇" is set as whether or not it is applied to the payment type "terminal code display". This is because by using the above method, it is possible to identify the product type on the terminal 20, and by storing the history of the identified product type in the storage unit 28, it is possible to identify the product type to be purchased. This is because it is possible to determine whether there is a purchase history. Further, the importance level "B" is set for the payment type "terminal code display", and the importance level "A" is set for the payment type "terminal code reading".

In addition, in the first embodiment, for the payment type "terminal code reading", the success or failure of the authentication skip conditions of condition No. "SP4-1" and "SP4-2" was determined by an alternative method, but the above-mentioned camera In the method using , since the type of the product to be purchased can be identified on the terminal 20, it is possible to determine whether these authentication skip conditions are met based on the identification result.

In addition to taking an image of the product to be purchased with the camera of the terminal 20 as described above, for example, the store code reader device 50 may be equipped with a camera, and the camera of the store code reader device 50 may be used to capture the image of the product to be purchased by the user of the terminal 20. It is also possible to take an image of the product to be purchased.

In this case, one method is for the store code reader device 50 to identify the type of the product to be purchased based on the image taken by the camera, and to transmit the identified type of the product to be purchased to the terminal 20. be able to.

Alternatively, as another method, the store code reader device 50 transmits a photographed image taken by a camera to the terminal 20, and the terminal 20 determines the type of product to be purchased based on the photographed image received from the store code reader device 50. It may also be possible to identify it.

<Effects of first modification (9)>
This modification shows a configuration in which the information different from the authentication password described above includes information on products sold at the store (not limited to this, but an example of information related to the products).
As an example of the effect obtained by such a configuration, the terminal does not need to perform display processing related to the execution of authentication for the user of the terminal based on information regarding the product, so that the processing load on the terminal can be reduced.

In addition, in this modification, the terminal 20 acquires a photographed image of the product to be purchased taken by the application camera or camera 27 (not limited to, but an example of an imaging device) of the terminal 20, and based on the acquired photographed image. , shows a configuration in which no authentication processing is performed.
As an example of the effect obtained by such a configuration, since the terminal does not display information regarding execution of authentication based on the image of the product taken by the imaging device, the processing load on the terminal can be reduced. For example, if a product identified from an image taken by an imaging device has a purchase history in the past or is a specific type of product, not displaying information regarding the execution of authentication can help the user. Convenience can be improved.

Furthermore, this modification shows a configuration in which the information different from the above-mentioned authentication password includes information on the product to be purchased (not limited to this, but an example of information on the product to be purchased by the user of the terminal).
As an example of the effect obtained by such a configuration, the terminal does not need to perform display processing related to the execution of authentication for the terminal user based on information about products purchased by the terminal user, so the processing load on the terminal is reduced. It can be reduced.

Moreover, this modification shows a configuration in which the authentication process is not performed when information on the product planned to be purchased by the user of the terminal 20 is acquired and it is determined that there is a purchase history of the product planned to be purchased.
As an example of the effect obtained by such a configuration, if the product matches a product that the user of the terminal has purchased more than once, the terminal does not display information regarding execution of authentication, which reduces the processing load on the terminal. can. Furthermore, since the risk is considered to be low if the same product is being purchased, by not displaying information regarding the execution of authentication, it is possible to improve convenience for the user while ensuring safety.

Further, this modification example shows a configuration in which the authentication process is not performed when information on a product to be purchased by the user of the terminal 20 is acquired and it is determined that the product to be purchased is a daily consumer item.
As an example of the effect obtained by such a configuration, when the product purchased by the user is a daily consumer item, the terminal does not display information regarding the execution of authentication, so that the processing load on the terminal can be reduced. Additionally, since the risk of purchasing daily consumer goods is considered to be low, by not displaying information regarding the execution of authentication, it is possible to improve convenience for users while ensuring safety. .

In addition to the above, methods using short-range wireless communication or non-contact communication may be applied, by way of example and not limitation, as a method for identifying products purchased by the user of the terminal 20 and the product types on the terminal 20. You can also.

Specifically, by way of example and not limitation, an RF tag (for example, an IC tag) storing product identification information or product type identification information is embedded in each product or product type sold at the store. Further, the terminal 20 is equipped with a reader/writer compatible with RF tags. Then, the terminal 20 uses radio waves to scan the RF tag embedded in the product the user purchases, and acquires the product identification information and product type identification information stored in the RF tag. Identify the product type.

<First modification (10)>
In the first embodiment, the store requests the server 10 to skip the authentication process of the terminal 20, and the server 10 provides information for skipping the authentication process (hereinafter referred to as "authentication skip information"). may or may not be transmitted to the terminal 20.

In this modification, it is possible to cause the terminal 20 to skip the authentication process based on the authentication skip information sent from the server 10. Therefore, for example, even if a person who wants to purchase a product or receive a service uses another person's terminal 20 to make a payment, the authentication process is skipped on the terminal 20 and the payment is not completed. There may also be a problem that the data may be lost. This modification places the risk on the store side and skips the authentication process of the terminal 20, knowing that such a problem may occur.

First, a case will be described in which authentication skip is performed on a store-by-store basis. This is a case in which the store decides whether or not to skip the authentication process for the terminal 20, and targets stores that have consented to skip the authentication process for the terminal 20, even though they are aware of the risks.

FIG. 3-35 is a flowchart showing an example of the processing flow of each device in this case, and is a diagram showing the processing part when the payment type is "terminal code reading" in the processing described in the first embodiment. This is an excerpt of the processing part of 3-31. Note that steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

If the store payment processing unit 513 determines in B5 that the payment type is not "terminal code display", that is, the payment type is "terminal code reading" (B3; No), the communication I/F 54 skips authentication. The request information is transmitted to the server 10 (B51).

Specifically, if the own store is a store that operates a type 1 terminal reading code, the store payment processing unit 513, by way of example and not limitation, associates the store ID with the type 1 terminal reading code. Authentication skip request information including sales amount information of the product to be sold is transmitted to the server 10.
Further, if the own store is a store that operates a type 2 terminal reading code, the store payment processing unit 513 transmits authentication skip request information including the store ID to the server 10, by way of example and not limitation.

Here, the authentication skip request information is information that requests the server 10 to generate authentication skip information for causing the terminal 20 to skip authentication processing. This authentication skip request information can be transmitted by the store code reader device 50 to the server 10 based on the approval of the store server 70, by way of example and not limitation.

Furthermore, although the description here assumes that the store code reader device 50 transmits the authentication skip request information to the server 10, instead of this, the store server 70 may transmit the authentication skip request information to the server 10. It's okay and you don't have to.

When the payment management processing unit 113 receives the authentication skip request information from the store code reader device 50 through the communication I/F 14 (C51), it performs terminal reading code generation determination processing (C53).

Specifically, by way of example and not limitation, it is determined whether the store that sent the authentication skip request information is an affiliated store. In addition, if the received authentication skip request information includes sales amount information of a product sold in association with a type 1 terminal reading code, the sales amount indicated by this sales amount information is an amount within an appropriate range (limited to For example, whether or not the amount is below the threshold amount (depending on the store's industry, the product/product type, etc. sold, but for example, "less than 1,000 yen," "less than 2,000 yen," "less than 3,000 yen," etc.) If these conditions are met, it is determined that a terminal reading code is to be generated.On the other hand, if these conditions are not met, it is determined that a terminal reading code is not to be generated.

If it is determined that a terminal reading code is to be generated (N55; Yes), the payment management processing unit 113 performs a terminal reading code generation process (C57).

In this terminal reading code generation process, the payment management processing unit 113 generates a terminal reading code including access information. More specifically, for example, the character string of the payment page URL is encoded and graphically generated to generate a terminal reading code represented by a two-dimensional code image. In addition, the payment management processing unit 113 also stores the sales amount (only for stores that operate the first type terminal reading code), the payment page URL, and whether or not authentication is skipped (in this case, the authentication Skip "Yes") is associated and stored in the terminal reading code management database 1593 of the code management database 159.

Thereafter, the payment management processing unit 113 transmits the generated terminal reading code to the store code reader device 50, which is the source of the authentication skip request information, via the communication I/F 14 (C59).

On the other hand, if it is determined that the terminal reading code is not to be generated (C55; No), the payment management processing unit 113 informs the store code reader device 50 via the communication I/F 14 that the terminal reading code cannot be generated. (C61). Then, the payment management processing unit 113 moves the process to C63.

The store payment processing unit 513 determines whether or not the terminal reading code has been received from the server 10 via the communication I/F 54 (B53), and if it is determined that the terminal reading code has been received (B53; Yes), the received terminal reading code is The code is displayed on the display section 53 (B55).

The payment application processing unit 213 of the terminal 20 reads the terminal reading code using an application code reader (A51). Specifically, one of the terminal reading codes posted at the store and the terminal reading code displayed on the store code reader device 50 at B55 is read. Then, the payment application processing unit 213 performs the processes of A33 and A35.

After C59 or C61, the payment management processing unit 113 determines payment schedule information according to the access to the payment page from the terminal 20 (C63). Specifically, with reference to the terminal reading code management database 1593, information stored in association with the payment page URL of this payment page is acquired. Then, the payment management processing unit 113 transmits payment schedule information (authentication skip "Yes" or "No") according to the determination result to the terminal 20 via the communication I/F 14 (C65).

If the information stored in association with the payment page URL is information indicating "no" authentication skip (in the case of the process flow from C61 to C63), it is the same as C35 in FIG. 3-31. That is, the payment management processing unit 113 transmits payment schedule information that does not include authentication skip information to the terminal 20.

On the other hand, if the information stored in association with the payment page URL is information indicating that the authentication skip is "present" (in the case of the process flow from C59 to C63), the payment management processing unit 113 stores the authentication skip information. The payment schedule information including the payment schedule information is transmitted to the terminal 20.
In this case, if the information associated with the payment page URL is information about a store that operates the type 1 terminal reading code, the payment management processing unit 113 stores the scheduled payment store, the scheduled payment amount, and the authentication skip. The first type payment schedule information including the above information is transmitted to the terminal 20.
On the other hand, if the information associated with the payment page URL is information about a store that operates a type 2 terminal reading code, the payment management processing unit 113 stores a second The payment schedule information (not including the scheduled payment amount) is transmitted to the terminal 20 via the communication I/14.

When the payment application processing unit 213 receives the payment schedule information (authentication skip "Yes" or "No") from the server 10 via the communication I/F 22 (A53), the payment application processing unit 213 performs the processing of A39 and A41, and then performs the second authentication. Skip determination processing is performed (A55). Note that in order to distinguish from the authentication skip determination process in other embodiments, this will be referred to as a "second authentication skip determination process" for convenience.

In this second authentication skip determination process, the authentication skip determination processing unit 2135 determines whether or not the payment schedule information received from the server 10 includes authentication skip information. In A51, if the terminal reading code displayed on the store code reader device 50 has been read, it is determined that the received payment schedule information includes authentication skip information. If the transaction code has been read, it is determined that the received payment schedule information does not include authentication skip information. If it is determined that the received payment schedule information includes authentication skip information, it is determined that the authentication process is to be skipped. The payment application processing unit 213 then moves the process to A11.

In addition, in the above-mentioned second authentication skip determination process, as an example and not a limitation, there is a case where the authentication setting for payment on the payment application side of the terminal 20 is set to "ON", or when the authentication process is not skipped on the terminal 20. If the mode is set, it is possible to prevent the authentication process from being skipped even if the payment schedule information includes authentication skip information.

Next, the above process is a process for performing authentication skip on a store-by-store basis, but by way of example and not limitation, it may be possible to perform authentication skip on a product-by-product or product-type basis sold at a store. is also possible.

FIG. 3-36 is a diagram showing an example of the terminal reading code management database 1593 stored in the storage unit 15 of the server 10 in this case.
This terminal reading code management database 1593 includes terminal reading code management data generated for stores that have agreed to skip the authentication process of the terminal 20.

In the terminal reading code management data of each store, by way of example and not limitation, the product type, sales amount, payment page URL, and whether or not authentication is skipped are stored in association with the store ID of that store. Ru.

In this example, the product types include "lunch box", "beverage", and "gift product", and for each product type, the sales amount, payment page URL, and whether or not authentication is skipped are associated. There is. For the product types "lunch box" and "beverage", "yes" is set as the presence or absence of authentication skip, but for the product type "gift product", "no" is set as the presence or absence of authentication skip. Therefore, when a user purchases a boxed lunch or a drink at this store, the authentication process is skipped at the terminal 20, but when the user purchases a gift item at this store, the authentication process is not skipped at the terminal 20. Become.

Furthermore, it is also possible to classify and associate sales amount, payment page URL, and whether or not authentication is skipped within one product type.
Specifically, as an example and not a limitation, the product type "bento" is classified into bentos with a sales amount of "200 yen," lunches with a sales amount of "300 yen," and lunch boxes with a sales amount of "500 yen." , for each category, the payment page URL and the presence or absence of authentication skipping may be associated with each other.

The settings of the plurality of patterns described above can be changed as appropriate on the server 10 side depending on what kind of operation the store side performs.

<Effects of first modification (10)>
This modification shows a configuration in which the information different from the authentication password includes authentication skip information.
As an example of the effect obtained by such a configuration, a terminal can skip authentication of a user of the terminal based on skip information for the terminal to skip authentication of a user of the terminal. Further, it is possible to determine whether or not to skip the authentication of the terminal user based on the skip information, and it is not necessary to determine whether other conditions are met, thereby reducing the processing load on the terminal.

Further, this modification shows a configuration in which the authentication skip information is generated by the server 10 based on authentication skip request information transmitted from the store code reader device 50.
As an example of the effect obtained by such a configuration, the terminal can easily skip the authentication of the terminal user based on the skip information generated by the server based on the request from the store that manages the product. In addition, it is possible to determine whether or not to skip the authentication of the terminal user based on the skip information generated by the server, and there is no need to determine whether other conditions are met, reducing the processing load on the terminal. I can do it.

<Second embodiment>
The second embodiment, like the first embodiment, is an embodiment that improves the convenience of payment. More specifically, by way of example and not limitation, when making a payment using a payment application on the terminal 20, the server 10 performs an authentication skip determination, and if the authentication skip condition is met, the user of the terminal 20 is Skips the requested authentication process.
The content described in the second embodiment is applicable to any of the other embodiments.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Functional configuration>
FIG. 4-1 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
The payment management processing section 113 includes, by way of example and not limitation, a terminal display code generation processing section 1131, a terminal display code transmission processing section 1133, a store payment result information transmission processing section 1136, and a terminal payment result information transmission processing section. In addition to the processing section 1137, the authentication skip determination processing section 1139 is included as a functional section.

The authentication skip determination processing unit 1139 performs an authentication skip determination process, which is a process for determining whether or not to skip the authentication process executed in the terminal 20, according to the authentication skip determination process program 1515 stored in the storage unit 15. It has the ability to execute. This authentication skip determination process can also be called an authentication necessity determination process for determining whether or not it is necessary to have the terminal 20 perform the authentication process.

In the present embodiment, the authentication skip determination processing unit 1139 performs the authentication skip determination process at a timing after receiving the terminal display code generation request information from the terminal 20 for the payment type "terminal code display", by way of example and not limitation. Execute.
Furthermore, by way of example and not limitation, the authentication skip determination processing unit 1139 executes the authentication skip determination process at a timing after receiving the first payment request information from the terminal 20 in the payment type "terminal code reading".
However, the execution timing of these authentication skip determination processes can be changed as appropriate.

FIG. 4-2 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The payment management processing program 1513 includes, by way of example and not limitation, an authentication skip determination processing program 1515 that is read by the control unit 11 and executed as an authentication skip determination process as a subroutine program.

In addition, the storage unit 15 includes, by way of example and not limitation, user registration data 153, store registration data 155, payment management database 157, code management database 159, and authentication skip condition data 156. , credit score data 158 are stored.

The authentication skip condition data 156 is data in which authentication skip conditions, which are conditions for causing the terminal 20 to skip the authentication process for payment, are defined.

The credit score data 158 is data in which a credit score representing the social credibility of the user of the terminal 20 in numerical values, ranks, etc. is stored for each terminal 20 or for each user of the terminal 20.
The credit score is calculated or determined based on, by way of example and not limitation, the payment history, age, work type, annual income, etc. of the user of the terminal 20.

In this embodiment, by way of example and not limitation, the credit score is quantified using a score system of "0 points" to "100 points", and a credit score of "100 points" indicates the highest social trust of the user, and a credit score of "100 points" is the highest. It is assumed that "0 point" means that the user's social trust is the lowest.

FIG. 4-3 is a diagram showing an example of the data structure of the authentication skip condition data 156 in this embodiment. This data structure is similar to the authentication skip condition data 2851 of the terminal 20, but the contents are partially different. The following description focuses on different conditions.

<Condition Category No. “SP2-5”>
Regarding condition category No. "SP2 (store/location),""the location of the store scheduled for payment and the location of the terminal are not far apart" is defined as the authentication skip condition of condition No. "SP2-5." This means that the authentication process of the terminal 20 is skipped when the location of the store where the payment is scheduled and the location of the terminal 20 where the payment is scheduled are not separated by a set distance or more, for example.

In this determination, by way of example and not limitation, the server 10 acquires the store location information of the store scheduled for payment from the store information registered in the store registration data 155 in the authentication skip determination process. Further, the server 10 requests terminal position information from the terminal 20, and receives and acquires the latest calculated position calculated by the position calculation processing unit 217 from the terminal 20 as the terminal position information. Then, the server 10 determines whether the store location and the terminal location are separated by a set distance or more.

In addition, in the above authentication skip condition, by way of example and not limitation, information on the region (area) where each store exists is stored in the storage unit 15 of the server 10, and the server 10 stores information about the region (area) where each store exists, It may or may not be necessary to specify the area where the terminal is located and then determine whether or not the terminal location is included in the specified area.

<Condition Category No. “SP5-2”>
The authentication skip condition for condition number "SP5-2" included in condition category number "SP5 (security)" is defined as "the trust score of the terminal user is 80 points or more." This allows the authentication process of the terminal 20 to be skipped when the credit score of the user of the terminal 20 stored in the credit score data 158 is 80 points or higher, that is, when the trust of the user of the terminal 20 has reached a certain level. It means that.

In this determination, the terminal 20 acquires the credit score of the user of the terminal 20 who is scheduled to make a payment from among the credit scores stored in the credit score data 158. Then, it is determined whether the acquired credit score is 80 points or more.

Other conditions are similar to the authentication skip condition data 2851 of the terminal 20, but in this embodiment, unlike the first embodiment, the server 10 performs the authentication skip determination process. Therefore, the server 10 stores user information stored in the user registration data 153 of the storage unit 15, store information stored in the store registration data 155, payment management information stored in the payment management database 157, etc. The information necessary for the authentication skip determination is acquired from the information stored and managed in 10 (hereinafter referred to as "server management information"). Further, the server 10 requests the terminal 20 to obtain information that is not managed by the server 10, such as location information of the terminal 20 (terminal location information). The server 10 then performs an authentication skip determination based on the acquired information.

Next, regarding the payment type "terminal code display", as an example and not a limitation, condition No. "SP2-1" to "SP2-5" (conditions included in condition category No. "SP2"), condition No. "SP3- 3", "SP3-4", and condition Nos. "SP4-1" and "SP4-2" (conditions included in condition category No. "SP4") are marked with "x" as not applicable.

The reason why the authentication skip condition included in the condition category No. "SP2" is marked as not applicable is "×" because, for the payment type "terminal code display", the server 10 selects the store where the payment is scheduled to be made at the timing of performing the authentication skip determination process. This is because it cannot be grasped.

The reason why the authentication skip conditions of condition No. "SP3-3" and "SP3-4" are not applicable is marked as "x" because the server 10 performs the authentication skip judgment process for the payment type "terminal code display". This is because it is not possible to determine the scheduled payment amount.

The reason why the authentication skip condition included in the condition category No. "SP4" is marked as not applicable is that for the payment type "terminal code display", the server 10 selects the product to be purchased at the timing when performing the authentication skip determination process. This is because it cannot be grasped.

On the other hand, regarding the payment type "Terminal code reading", as an example and not a limitation, "x (〇)" is set as not applicable to the authentication skip condition of condition number "SP5-1", and for other authentication skip conditions “〇” indicates that it is applicable.

In addition, for both payment types "Display terminal code" and "Read terminal code", the authentication skip condition of condition No. "SP5-1" is set as "x (〇)", but this is basically This is because, due to the specifications, the server 10 cannot grasp the lock status on the OS side of the terminal 20 and the lock status on the payment application side.
However, if the specifications on the terminal 20 side are changed to notify the server 10 of information regarding these lock statuses, the server 10 side can grasp the lock status of the terminal 20, so that the authentication skip determination can be performed. It becomes possible.

<Processing>
FIGS. 4-4 to P4-6 are flowcharts showing an example of the flow of processing executed by each device in this embodiment.
In these figures, from the left side, the second payment application process, which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20, and the store payment process executed by the store payment processing unit 513 of the store code reader device 50. A second store payment process, which is an example of processing, and a second payment management process, which is an example of payment management processing executed by the payment management processing unit 113 of the server 10, are shown.

Note that the flowchart described below is just an example of the processing in this embodiment, and in the flowchart described below, some steps may not be executed, or additional steps may be inserted.
Further, steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

First, the payment application processing unit 213 of the terminal 20 executes processes A1 to A3. If the payment type is "terminal code display" (A3: terminal code display), the terminal display code acquisition processing unit 2131 executes the process of A5.

If the server 10 determines that the terminal display code generation request information has been received from the terminal 20 via the communication I/F 14 (C1; Yes), the authentication skip determination processing unit 1139 executes the authentication stored in the storage unit 15. A third authentication skip determination process is executed according to the skip determination process program 1515 (G1). Note that in order to distinguish from the authentication skip determination process in other embodiments, this will be referred to as a "third authentication skip determination process" for convenience.

Specifically, the authentication skip determination processing unit 1139 uses the same method as in the first embodiment to determine the success or failure of the authentication skip condition included in the authentication skip condition data 156 in the storage unit 15 using various types of information acquired from the storage unit 15. The determination is made based on the server management information and the information requested and obtained from the terminal 20.

After performing the third authentication skip determination process, the payment management processing unit 113 determines whether or not it has been determined to skip the authentication process (G3). If it is determined that the authentication process is to be skipped (G3; Yes), the payment management processing unit 113 moves the process to C3.

On the other hand, if it is determined not to skip the authentication process (G1: No), the payment management processing unit 113 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (G5).

The payment application processing unit 213 determines whether additional authentication request information has been received from the server 10 through the communication I/F 22 (E1), and if it is determined that the information has not been received (E1; No), the process proceeds to A7. move. In this case, the authentication process at the terminal 20 is skipped.

On the other hand, if it is determined that additional authentication request information has been received from the server 10 through the communication I/F 22 (E1; Yes), the payment application processing unit 213 executes the processes A13 to A17. In this case, the authentication process is executed at the terminal 20.

If the authentication result is "OK" in the authentication process (A15; Yes), the payment application processing unit 213 transmits authentication success information to the server 10 via the communication I/F 22 (E3).

When the payment management processing unit 113 receives the authentication success information from the terminal 20 via the communication I/F 14 (G7), it executes the processes of C3 and C5. That is, after receiving information indicating that the authentication was successful from the terminal 20, a terminal display code is generated (C3), and the generated terminal display code is transmitted to the terminal 20 (C5).

On the other hand, if it is determined in A3 that the payment type is "terminal code reading" (A3; terminal code reading), the payment application processing unit 213 executes processes A31 to A43.

When the server 10 receives the first payment request information from the terminal 20 through the communication I/F 14 (C37), the authentication skip determination processing unit 1139 executes the first payment request information according to the authentication skip determination processing program 1515 stored in the storage unit 15. The authentication skip determination process of step 3 is executed (G1).

After performing the third authentication skip determination process, the payment management processing unit 113 determines whether or not it has been determined to skip the authentication process (G3). If it is determined that the authentication process is to be skipped (G3; Yes), the payment management processing unit 113 moves the process to C11.

On the other hand, if it is determined not to skip the authentication process (G1: No), the payment management processing unit 113 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (G5).

The payment application processing unit 213 determines whether additional authentication request information has been received from the server 10 through the communication I/F 22 (E1), and if it is determined that the additional authentication request information has not been received (E1; No), the process proceeds to A21. move. In this case, the authentication process at the terminal 20 is skipped.

On the other hand, if the payment application processing unit 213 determines that additional authentication request information has been received from the server 10 through the communication I/F 22 (E1; Yes), it executes the processes A13 to A17. In this case, the authentication process is executed at the terminal 20.

In addition, in the above process, when the payment type is "terminal code display", the server 10 sends the third message after receiving the terminal display code generation request information from the terminal 20 (after C1; Yes). However, the present invention is not limited to this.
As an example and not a limitation, the server 10 may perform the third authentication skip determination process at a timing after receiving the second payment request information from the store code reader device 50 (after C9). , you don't have to.

<Effects of the second embodiment>
In the second embodiment, the server 10 receives payment request information (not limited to, an example of information regarding payment of electronic money by the terminal) from the terminal 20 through the communication I/F 14, and receives additional authentication request information (not limited to, information regarding the authentication of the user of the terminal) is transmitted to the terminal 20 via the communication I/F 14. Further, the server 10 receives authentication success information (not limited to, an example of information indicating that the user of the terminal has been authenticated) from the terminal 20, and performs payment based on the received authentication success information. Result information (an example of payment information indicating that payment using electronic money has been performed) is transmitted to the terminal 20 via the communication I/F 14. Then, the server 10 transmits the additional authentication request information to the terminal 20 via the communication I/F 14 by acquiring information different from the authentication password (an example of authentication information, not limited to) for authenticating the user of the terminal 20. A configuration is shown in which the payment result information is transmitted to the terminal 20 via the communication I/F 14 without being transmitted.
As an example of the effect obtained by such a configuration, when making a payment using electronic money, the server acquires information different from the authentication information for authenticating the terminal user, so that the server transfers information related to the authentication of the terminal user to the terminal. Since the data is not sent to the server, the processing load on the server can be reduced. Furthermore, since payment information can be sent to the terminal without sending information related to authentication of the terminal user to the terminal, convenience for the user can be improved.

Furthermore, in the second embodiment, the information different from the authentication password is information associated with the terminal identification information of the terminal 20 or the user identification information of the terminal 20 (without limitation, information that identifies the terminal or the user of the terminal). 2 shows a configuration including an example of information associated with identification information for
As an example of the effect obtained by such a configuration, the server may transmit information related to the authentication of the user of the terminal to the terminal by acquiring information associated with the terminal or identification information for identifying the user of the terminal. Payment information can be sent to the terminal without having to do so.

Further, in the second embodiment, the information associated with the terminal identification information of the terminal 20 or the user identification information of the terminal 20 is information related to the IMS money (limited to This example shows a configuration including information related to the terminal or electronic money associated with the user of the terminal.
As an example of the effect obtained by such a configuration, the server can acquire information regarding the electronic money associated with the terminal or the user of the terminal, thereby allowing the server to perform payment without transmitting information regarding the authentication of the terminal user to the terminal. Information can be sent to the terminal.

Further, in the second embodiment, the information regarding the IMS money associated with the terminal 20 or the user of the terminal 20 is the information regarding the amount of IMS money associated with the terminal 20 or the user of the terminal 20 (limited to This example shows a configuration including information regarding the amount of electronic money associated with the terminal or the user of the terminal.
As an example of the effect obtained by such a configuration, the server transmits information regarding the authentication of the terminal user to the terminal by acquiring information regarding the amount of electronic money associated with the terminal or the user of the terminal. Payment information can be sent to the terminal without any hassle. For example, if the amount of electronic money is low, by not sending information related to the terminal user's authentication to the terminal, it is possible to omit authentication on the terminal, improving user convenience. be able to.

Further, in the second embodiment, information regarding the amount of IMS money associated with the terminal 20 or the user of the terminal 20 is a set daily upper limit amount (not limited to the set amount of the electronic money that has been set). (Example of information regarding).
As an example of the effect obtained by such a configuration, the server can obtain information regarding the set amount of electronic money and send payment information to the terminal without transmitting information regarding authentication of the terminal user to the terminal. Can be sent.

Further, in the second embodiment, the server 10 transmits additional authentication request information (not limited to, but an example of information related to authentication of the terminal user) to the terminal 20 through the communication I/F 14 until the daily upper limit set amount is exceeded. The configuration is shown in which payment result information is sent to the terminal 20 via the communication I/F 14 without being sent to the terminal 20.
As an example of the effect obtained by such a configuration, the server does not send information related to the authentication of the terminal user to the terminal until the set amount of electronic money is exceeded, which reduces the communication amount of the server. This can reduce the load on the server. In addition, if the set amount of electronic money exceeds the set amount, the server sends information related to the terminal user's authentication to the terminal, so it can alert the terminal user that the set amount has been exceeded. .

Further, in the second embodiment, the information regarding the amount of IMS Money described above is information on the balance of IMS Money associated with the terminal 20 or the user of the terminal 20 (without limitation, information regarding the amount of IMS Money associated with the terminal or the user of the terminal). The figure shows a configuration including an example of information regarding the balance of electronic money.
As an example of the effect obtained by such a configuration, the server may transmit information regarding the authentication of the terminal user to the terminal by acquiring information regarding the balance of electronic money associated with the terminal or the user of the terminal. Payment information can be sent to the terminal without any hassle. Further, the server can appropriately perform processing related to payment based on information regarding the balance of electronic money associated with the terminal or the user of the terminal.

In addition, in the second embodiment, when the balance of the IMS money described above is less than or equal to the set amount, the server 10 provides additional authentication request information (not limited to this, but an example of information related to authentication of the terminal user). A configuration is shown in which payment result information is not transmitted to the terminal 20 through the communication I/F 14, but payment result information is transmitted to the terminal 20 through the communication I/F 14.
As an example of the effect obtained by such a configuration, if the balance of electronic money is less than or equal to the set amount, the server does not send information regarding the authentication of the user of the terminal to the terminal. The amount of communication on the server can be reduced, and the load on the server can be reduced. Also, for example, if the balance of electronic money is small, large payments cannot be made and the risk is considered to be low. It becomes possible to omit authentication, and it is possible to improve user convenience while ensuring safety.

Further, in the second embodiment, when the auto charge setting of the terminal 20 is set to "ON", the server 10 communicates additional authentication request information when the balance of IMS money is less than or equal to the set amount. It shows a configuration in which payment result information is transmitted to the terminal 20 through the I/F 14, and payment result information is transmitted to the terminal 20 through the communication I/F 14.
As an example of the effect obtained by such a configuration, the server can be configured to automatically deposit electronic money into the terminal when the electronic money on the terminal becomes less than or equal to the set amount. In this case, if the amount becomes small, electronic money is automatically deposited into the terminal, making it possible to make large payments, which poses a risk. Therefore, the server can alert the user that a large amount of payment will be possible by transmitting information regarding the authentication of the user of the terminal to the terminal through the communication unit.

Furthermore, the second embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information on the frequency or number of times payments are made using IMS money.
As an example of the effect obtained by such a configuration, the server can acquire information regarding the frequency or number of payments made using electronic money, thereby allowing the server to transmit payment information without transmitting information regarding the authentication of the terminal user to the terminal. It can be sent to the terminal. For example, if the frequency of payments using electronic money is high or the number of times is large, there is a high possibility that the same user is making payments using electronic money, and the risk is considered to be low. By not transmitting information related to authentication to the terminal, it becomes possible to omit authentication at the terminal, and it is possible to improve convenience for the user while ensuring safety.

Furthermore, the second embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information on the time when payment was made using IMS money.
As an example of the effect obtained by such a configuration, the server can obtain information about the time when the payment was made using electronic money, so that the server can send payment information to the terminal without transmitting information about the authentication of the terminal user to the terminal. Can be sent.

Further, in the second embodiment, the server 10 sends additional authentication request information (an example of information related to authentication of the user of the terminal) to the terminal via the communication I/F 14 if the set time has passed since the time when the payment was made. 20, but instead transmits the payment result information to the terminal 20 via the communication I/F 14.
As an example of the effect obtained by such a configuration, the server does not send information related to the authentication of the terminal user to the terminal within the set time from the time of payment, reducing the amount of communication on the server. It is possible to reduce the load on the server. For example, if a long period of time has not passed since the payment was made, there is a high possibility that the same user will make the payment again, and the risk is considered to be low, so information regarding the authentication of the terminal user is sent to the terminal. By not doing so, it is possible to improve user convenience while ensuring safety.

Furthermore, the second embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information regarding a place where payment was made using IMS money.
As an example of the effect obtained by such a configuration, the server can obtain information about the place where the payment was made using electronic money, so that the server can send payment information to the terminal without transmitting information about the authentication of the terminal user to the terminal. Can be sent.

Furthermore, in the second embodiment, the information regarding the place where the payment was made using IMS money includes information regarding the store where the payment was made using IMS money.
As an example of the effect obtained by such a configuration, the server can acquire information about the store where the payment was made using electronic money, so that the server can send payment information to the terminal without transmitting information related to the authentication of the terminal user to the terminal. Can be sent.

Further, in the second embodiment, the server 10 generates additional authentication request information (not limited to information regarding authentication of the user of the terminal) based on the location of the store where the payment was made using IMS money and the location of the terminal 20. (Example) is not transmitted to the terminal 20 through the communication I/F 14, but a configuration is shown in which payment result information is transmitted to the terminal 20 through the communication I/F 14.
As an example of the effect obtained by such a configuration, the server does not send information regarding the authentication of the user of the terminal to the terminal based on information regarding the store where the payment was made using electronic money and information regarding the location of the terminal. , the amount of communication on the server can be reduced, and the load on the server can be reduced. In addition, for example, if the location of the terminal is not far from a store where the user made a payment using electronic money in the past, there is a high possibility that the user is attempting to make a payment at the same store, and the risk is considered to be low. By not transmitting information related to user authentication to the terminal, it is possible to improve user convenience while ensuring safety.

Furthermore, the second embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information regarding the location of a store where authentication for IMS money payment is performed.
As an example of the effect obtained by such a configuration, the server transmits information regarding the authentication of the user of the terminal to the terminal by acquiring information regarding the location where the authentication for electronic money payment was performed. Payment information can be sent to the terminal without any hassle. In addition, for example, if the location has been used to perform authentication for electronic currency payments in the past, the same user may be required to perform authentication again, and the risk is considered to be low. By not transmitting information related to authentication to the terminal, it is possible to improve user convenience while ensuring safety.

The second embodiment also includes information associated with the terminal identification information of the terminal 20 or the user identification information of the terminal 20 (without limitation, information associated with the terminal or identification information for identifying the user of the terminal). (Example of information) shows a configuration including information on products purchased by the user of the terminal 20.
As an example of the effect obtained by such a configuration, the server can obtain information regarding products purchased by the terminal user, thereby transmitting payment information to the terminal without transmitting information regarding the authentication of the terminal user to the terminal. Can be sent.

Further, in the second embodiment, the server 10 transmits additional authentication request information to the communication I/F 10 based on information on products purchased by the user of the terminal 20 and information on products purchased by the user of the terminal 20. This shows a configuration in which payment result information is not transmitted to the terminal 20 by the communication I/F 14, but is transmitted to the terminal 20 by the communication I/F 14.
As an example of the effect obtained by such a configuration, the server may obtain information regarding the authentication of the terminal user based on information regarding the product purchased by the terminal user and information regarding the product purchased by the terminal user. Since the information is not sent to the terminal, the amount of communication on the server can be reduced, and the load on the server can be reduced. Also, for example, if the same product has been purchased in the past, there is a high possibility that the same user is trying to purchase the same product, and the risk is considered to be low, so information regarding the authentication of the terminal user is sent to the terminal. By not doing so, it is possible to improve user convenience while ensuring safety.

Furthermore, the second embodiment shows a configuration in which the information different from the above authentication password includes information regarding the store.
As an example of the effect obtained by such a configuration, the server can transmit payment information to the terminal without transmitting information regarding authentication of the terminal user to the terminal by acquiring information regarding the location.

Further, the second embodiment shows a configuration in which the above-mentioned store information includes information regarding the store where the product is purchased, is transmitted from the store server 70, and is received by the server 10 through the communication I/F 14.
As an example of the effect obtained by such a configuration, the server can obtain information by receiving information regarding the store where the product is purchased, transmitted from the server of the store that manages the product.

Further, in the second embodiment, the server 10 receives the location information of the terminal 20 from the terminal 20 via the communication I/F 14, and combines the location information of the store where the user of the terminal 20 purchases a product and the location information of the terminal 20. Based on this, a configuration is shown in which additional authentication request information is not transmitted to the terminal 20 through the communication I/F 14, and payment result information is transmitted to the terminal 20 through the communication I/F 14.
As an example of the effect obtained by such a configuration, the server does not transmit information regarding the authentication of the user of the terminal to the terminal based on the information regarding the location of the store where the product is purchased and the received information regarding the location of the terminal. Therefore, the amount of communication on the server can be reduced, and the load on the server can be reduced. Also, for example, if the location of the store where the product is purchased and the location of the terminal are not far apart, there is a high possibility that the user is attempting to make a payment at that store, and the risk is considered to be low. By not sending information related to authentication to the terminal, user convenience can be improved.

Furthermore, the second embodiment shows a configuration in which the information different from the authentication password described above includes information regarding the product.
As an example of the effect obtained by such a configuration, the server can transmit payment information to the terminal without transmitting information regarding authentication of the terminal user to the terminal by acquiring information regarding the product.

Furthermore, in the second embodiment, when the product to be purchased is a daily consumer product, the server 10 transmits additional authentication request information (not limited to this, but is an example of information related to authentication of the user of the terminal) to the terminal via the communication I/F 14. 20, but instead transmits the payment result information to the terminal 20 via the communication I/F 14.
As an example of the effect obtained by such a configuration, if the information about the product matches the information about the product set in advance, the server does not send information related to the authentication of the user of the terminal to the terminal, so the server communication The amount can be reduced, and the load on the server can be reduced.

Furthermore, the second embodiment shows a configuration in which the information regarding the above-mentioned products includes information regarding the total amount of the products to be purchased.
As an example of the effect obtained by such a configuration, the server can transmit payment information to the terminal without transmitting information regarding the authentication of the terminal user to the terminal by acquiring information regarding the total amount of the product. . Also, for example, if the total amount of the product is low, the risk is considered to be low, so information regarding the authentication of the terminal user is not sent to the terminal, thereby ensuring safety and improving user convenience. can be improved.

<Second modification (1)>
A composite process may be performed by combining the authentication skip determination on the terminal 20 side described in the first embodiment and the authentication skip determination on the server 10 side described in the second embodiment, You don't have to.

4-7 and 4-8 are flowcharts showing an example of the flow of processing executed by each device in this case.
In these figures, from the left side, the third payment application process, which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20, and the store payment process executed by the store payment processing unit 513 of the store code reader device 50. A third store payment process, which is an example of the process, and a third payment management process, which is an example of the payment management process executed by the payment management processing unit 113 of the server 10, are shown, respectively.

If the payment application processing unit 213 determines that the payment type is "terminal code display" in A3 (A3; terminal code display), it performs a first authentication skip determination process (H3). Then, the payment application processing unit 213 performs processes A11 to A17.

If it is determined in A15 that the authentication result is "OK" (A15; Yes), or if it is determined in A11 to skip the authentication process (A11; Yes), the payment application processing unit 213 uses the communication I/F 22 to , sends terminal display code generation request information including the user ID and authentication skip status information, which is information indicating whether or not authentication processing has been skipped, to the server 10 (H15).

The payment management processing unit 113 determines whether terminal display code generation request information has been received from the terminal 20 via the communication I/F 14 (J1). If it is determined that the information has been received (C1; Yes), the authentication skip determination processing unit 1139 executes the fourth authentication skip determination process after performing the processes of C3 to C9 (J3). Note that in order to distinguish from the authentication skip determination process in other embodiments, this will be referred to as a "fourth authentication skip determination process" for convenience.

In this fourth authentication skip determination process, the authentication skip determination processing unit 1139 determines whether the authentication process has been skipped in the terminal 20 based on the authentication skip status information included in the terminal display code generation request information received from the terminal 20. Determine whether or not.

If the authentication process is not skipped by the terminal 20, the authentication skip determination processing unit 1139 determines that additional authentication is unnecessary. This is because the authentication process has already been completed on the terminal 20.
On the other hand, when the authentication process is skipped in the terminal 20, the authentication skip determination processing unit 1139 determines whether the authentication skip condition is successful or not based on the authentication skip condition included in the authentication skip condition data 156 in the storage unit 15. If the authentication skip condition is satisfied, it is determined that additional authentication is not necessary, and if the authentication skip condition is not satisfied, it is determined that additional authentication is necessary. This is because although the authentication process was skipped in the terminal 20, depending on the result of the authentication skip determination by the server 10, it may be better to have the terminal 20 perform additional authentication.

As a specific example, for example, due to a difference between the authentication skip settings on the terminal 20 side and the authentication skip settings on the server 10 side, the terminal 20 determines that the authentication processing should be skipped because the scheduled payment amount is not large. However, since the scheduled payment amount is large, the server 10 determines that there is a problem (risk) in having the terminal 20 skip the authentication process, so it cancels the authentication skip of the terminal 20 and causes the terminal 20 to perform additional authentication. There are cases.

Note that, unlike the above, if the authentication process is skipped by the terminal 20, the server 10 may trust the judgment of the terminal 20 and determine that additional authentication is not necessary. In this case, the server 10 side does not need to perform the authentication skip determination.

If it is determined in the fourth authentication skip determination process that additional authentication is necessary (G3; No), the payment management processing unit 113 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (G5). After receiving the authentication success information from the terminal 20 via the communication I/F 14 (G7), the payment management processing unit 113 performs payment processing (C11). Then, the payment management processing unit 113 moves the process to C13.

After A19, the payment application processing unit 213 processes E1, A13 to A17, and E3, and then moves the process to A21.

<Effects of second modification (1)>
As an example of the effect obtained by this modification, the terminal and the server can cooperate to determine whether or not to execute display processing related to authentication of the user of the terminal. Furthermore, by transmitting information regarding whether or not the display process is to be performed from the terminal to the server, the server can easily determine whether or not to cause the terminal to additionally execute the display process.

<Second modification (2)>
Similarly to <First Modification (10)>, the store may request the server 10 to have the terminal 20 skip the authentication process.

FIG. 4-9 is a flowchart showing an example of the processing flow of each device in this case, and is a diagram showing the processing part when the payment type is "terminal code reading" in the processing described in the second embodiment. This is an excerpt of the processing part of 4-5. Note that steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

When the payment management processing unit 113 receives the authentication skip request information from the store code reader device 50 via the communication I/F 14 (C51), it performs the processes of C53 to C65. Thereafter, when the payment management processing unit 113 receives the first payment request information from the terminal 20 through the communication I/F 14 (C37), the authentication skip determination processing unit 1139 executes the fifth authentication skip determination process (G51). ). Note that, in order to distinguish from the authentication skip determination process in other embodiments, this will be referred to as "fifth authentication skip determination process" for convenience.

In this fifth authentication skip determination process, the authentication skip determination processing unit 1139 refers to the terminal reading code management database 1593 and determines whether authentication skip "Yes" is associated with the payment page URL accessed by the terminal 20. If there is an association, it is determined that the authentication process is to be skipped. Then, the payment management processing unit 113 moves the processing to G3 and thereafter.

<Effects of second modification (2)>
This modification shows a configuration in which the information different from the authentication password includes authentication skip information.
As an example of the effect obtained by such a configuration, the server can easily cause the terminal to skip the authentication of the terminal user based on the skip information for skipping the authentication of the terminal user.

Further, this modification shows a configuration in which the authentication skip information is generated by the server 10 based on authentication skip request information transmitted from the store code reader device 50.
As an example of the effect obtained by such a configuration, the server can generate skip information for causing the terminal to skip the authentication of the terminal user based on a request from the store that manages the product.

<Second modification (3)>
The server 10 may or may not change the authentication skip conditions based on the trust score of the user of the terminal 20.

Specifically, by way of example and not limitation, the server 10 increases the "setting time" in the authentication skip condition of condition No. "SP1-1" of the authentication skip condition data 156 as the credit score of the user of the terminal 20 increases. You may or may not do so.

More specifically, by way of example and not limitation, the set time when the credit score is 0 points is set as "2 hours". Further, a threshold value that is an integral multiple of 10 points (10 points, 20 points, . . . , 100 points) is set as a credit score threshold. Then, each time the credit score of the user of the terminal 20 reaches a threshold, the set time can be set longer by one hour.

In addition, as an example and not a limitation, the server 10 increases the "daily upper limit setting amount" in the authentication skip condition of condition No. "SP3-1" of the authentication skip condition data 156 as the credit score of the user of the terminal 20 increases. You may or may not do so. More specifically, as an example and not a limitation, the daily upper limit set amount when the credit score is 0 points is set as "0 yen". Further, a threshold value that is an integral multiple of 10 points (10 points, 20 points, . . . , 100 points) is set as a credit score threshold. Then, each time the credit score of the user of the terminal 20 reaches a threshold, the daily upper limit setting amount can be set higher by 5000 yen.

Further, by way of example and not limitation, the higher the trust score of the user of the terminal 20, the more likely it is to be determined that the authentication process is to be skipped, or it may not be necessary. For example, for a user with a credit score of "90 points or more", the authentication process is skipped regardless of whether other types of authentication skip conditions are met. In addition, for users whose credit score is "80 points or more and less than 90 points," the authentication process is skipped if any one of the other types of authentication skip conditions is satisfied, and the credit score is "80 points or more and less than 90 points." For users with 70 points or more and less than 80 points, the authentication process is skipped if any two of the other types of authentication skip conditions are satisfied.
The same applies below.

Furthermore, by way of example and not limitation, for users whose credit score is equal to or higher than the threshold score (for example, "60 points or more"), authentication skip determination is performed only on the server 10 using the method described in the second embodiment. For users whose score is less than the threshold score (for example, "less than 60 points"), the authentication skip determination may be performed at both the terminal 20 and the server 10 using the method described in the second modification (1). You don't have to.

<Effects of second modification (3)>
As an example of the effect obtained by this modification, the skip condition can be changed based on the trust of the user of the terminal. For example, user convenience can be improved by making it easier for authentication to be skipped as the user of the terminal has higher trust.

<Second modification (4)>
As a place where the terminal 20 makes a payment, it is assumed that, for example, the customer purchases a product using on-board sales on a Shinkansen train, or the customer eats at a moving food stall. In this case, the location of the terminal 20 and the location of the store will each change.

Therefore, for mobile stores, the server 10 acquires store location information from the mobile stores. Additionally, the server 10 acquires terminal location information from the terminal 20. For example, when determining the authentication skip condition "The location of the store scheduled for payment and the location of the terminal are not far apart" of condition No. "SP2-5", the server 10 uses the store location information acquired from the mobile store. It is preferable to make the determination based on the terminal location information acquired from the terminal 20.

<Effects of second modification (4)>
As an example of the effect obtained by this modification, even if the store moves, the server can appropriately authenticate the user of the terminal based on the location information obtained from the terminal and the location information obtained from the store. can be skipped.

<Third embodiment>
The third embodiment is an embodiment in which the above-described authentication skip information is included in the payment code. In the third embodiment, based on the same idea as <First Modification (10)>, the store side is given a risk and the authentication process of the terminal 20 is skipped. The difference from <First Modification (10)> is that authentication skip information is included in the terminal reading code.
The content described in the third embodiment is applicable to any of the other embodiments.
In addition, the same reference numerals are given to the same constituent elements as those already mentioned, and the explanation thereof will be omitted.

<Functional configuration>
FIG. 5-1 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
The payment management processing unit 113 includes a terminal display code generation processing unit 1131, a terminal display code transmission processing unit 1133, a store payment result information transmission processing unit 1136, a terminal payment result information transmission processing unit 1137, and an authentication processing unit 1131. In addition to the skip determination processing section 1139, it has a special terminal reading code generation processing section 1134 and a special terminal reading code transmission processing section 1135.

The special terminal reading code generation processing unit 1134 has a function of generating a special terminal reading code that is a special terminal reading code that includes authentication skip information.

The special terminal reading code transmission processing unit 1135 has a function of transmitting the special terminal reading code generated by the special terminal reading code generation processing unit 1134 to the terminal 20.

<Processing>
FIG. 5-2 is a flowchart showing an example of the processing flow of each device in this embodiment, and is a processing part when the payment type is "terminal code reading" in the processing explained in the first embodiment. This is an extraction of the processing portion of Figure 3-29. Note that steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

If the store payment processing unit 513 determines in B5 that the payment type is not "terminal code display", that is, the payment type is "terminal code reading" (B3; No), the store payment processing unit 513 uses the communication I/F 54 to select a special terminal. The reading code generation request information is transmitted to the server 10 (M51).

Specifically, if the own store is a store that operates a type 1 terminal reading code, the store payment processing unit 513, by way of example and not limitation, associates the store ID with the type 1 terminal reading code. Special terminal reading code generation request information including sales amount information of the product to be sold and authentication skip request information is transmitted to the server 10.
In addition, if the own store is a store that operates a type 2 terminal reading code, the store payment processing unit 513 uses a special terminal reading code that includes, by way of example and not limitation, the store ID and authentication skip request information. Send generation request information to the server 10.

Here, the authentication skip request information is similar to the authentication skip request information described in <First Modification (10)>, and is information (request information) for requesting the server 10 to generate authentication skip information. This authentication skip request information can be transmitted from the store code reader device 50 to the server 10 based on the approval of the store server 70, by way of example and not limitation. In other words, the authentication skip request information can also be said to be information requested by the store server (store server 70) that performs IMS money settlement using the terminal 20.

Specifically, if your store is a store that operates a Type 1 terminal reading code, by way of example and not limitation, the store may collect information on the sales amount of products such as boxed lunches and drinks that are sold at a uniform price. It can be included in the special terminal reading code generation request information.

However, the information that can be included in the special terminal reading code generation request information is not limited to the above information. In addition to the above information, by way of example and not limitation, information regarding products sold in association with the special terminal reading code (product name, product type, etc.) may or may not be included.

In addition, the information regarding the above products includes, by way of example and not limitation, products that are less than the set price or products that are less than the set price (depending on the industry of the store and the product/product type sold, for example, "500 yen or less" or "less than 500 yen") The information may or may not be information regarding products "less than 500 yen", "less than 1000 yen", or "less than 1000 yen".

In addition, in a store that operates a type 1 terminal reading code, by way of example and not limitation, the store clerk inputs the total amount of products purchased by the user of the terminal 20 using IMS money into the store code reader device 50 and sets the amount. Information regarding the total amount of products purchased by the user of the terminal 20 using IMS money may or may not be included in the special terminal reading code generation request information.

In addition, instead of or in addition to the store ID (store identification information), the store code reader device 50 sends a special terminal reading code to store area information (not limited to, but an example of information regarding the location) of the store location. It may or may not be included in the generation request information and transmitted to the server 10.

Note that although the description here assumes that the store code reader device 50 transmits the special terminal reading code generation request information to the server 10, instead of this, the store server 70 transmits the special terminal reading code generation request information. It may or may not be transmitted to the server 10.

When the payment management processing unit 113 receives special terminal reading code generation request information from the store code reader device 50 via the communication I/F 14 (N51), it performs special terminal reading code generation determination processing (N53).

Specifically, by way of example and not limitation, it is determined whether the store that sent the special terminal reading code generation request information is an affiliated store. In addition, if the received special terminal reading code generation request information includes sales amount information of a product sold in association with the first type terminal reading code, the sales amount indicated by this sales amount information is within the appropriate range. Amount (as an example and not a limitation, below the threshold amount (depending on the industry of the store and the product/product type sold, etc., but for example "less than 1000 yen", "less than 2000 yen", "less than 3000 yen", etc.) If these conditions are met, it is determined that a special terminal reading code is to be generated.On the other hand, if these conditions are not met, it is determined that a special terminal reading code is not to be generated. do.

If it is determined that a special terminal reading code is to be generated (N55; Yes), the special terminal reading code generation processing unit 1134 performs special terminal reading code generation processing (N57).

In this special terminal reading code generation process, the special terminal reading code generation processing unit 1134 generates a special terminal reading code including, by way of example and not limitation, access information and authentication skip information. More specifically, for example, data consisting of a character string of a payment page URL and a character string of a command instructing or requesting to skip the authentication process is encoded and visualized, Generates a special terminal reading code represented by a two-dimensional code image.

In addition, the payment management processing unit 113 also stores the sales amount (only for stores that operate the Type 1 special terminal reading code), the payment page URL, and whether or not authentication is skipped (in this case, in correspondence with the store ID of this store). Authentication skip "Yes") is stored in the terminal reading code management database 1593 of the code management database 159.

As authentication skip information, instead of including a command that instructs or requests to skip the authentication process in the special terminal reading code, a token containing the authentication skip information should be included in the special terminal reading code. You may or may not.

Thereafter, the special terminal reading code transmission processing unit 1135 transmits the special terminal reading code via the communication I/F 14 to the store code reader device 50 that is the source of the special terminal reading code generation request information (N59).

On the other hand, if it is determined that the special terminal reading code is not to be generated (N55; No), the payment management processing unit 113 informs the store code reader via the communication I/F 14 that the special terminal reading code cannot be generated. The device 50 is notified (N61). Then, the payment management processing unit 113 moves the process to N63.

The store payment processing unit 513 determines whether or not the special terminal reading code has been received from the server 10 via the communication I/F 54 (M53), and if it is determined that the code has been received (M53; Yes), the received special terminal The reading code is displayed on the display section 53 (M55).

On the other hand, if the store payment processing unit 513 determines that the communication I/F 54 has not received the special terminal reading code from the server 10 but has received the authentication skip impossible information (M53; No), then Processing is then moved to B15.

The payment application processing unit 213 of the terminal 20 reads either the terminal reading code posted at the store or the special terminal reading code displayed on the display unit 53 of the store code reader device 50 at M55 into an application code reader. (L51). Then, the payment application processing unit 213 performs the processes of A33 and A35.

The payment management processing unit 113 determines payment schedule information in response to access to the payment page from the terminal 20 (N63). Specifically, the information stored in association with this payment page is obtained by referring to the terminal reading code management database 1593. Then, the payment management processing unit 113 transmits payment schedule information according to the determination result to the terminal 20 via the communication I/F 14 (N65).

In this case, if the information associated with the payment page is information about a store that operates the Type 1 special terminal reading code, the payment management processing unit 113 stores the scheduled payment store and the scheduled payment amount. The first type payment schedule information including the information is transmitted to the terminal 20 via the communication I/14. On the other hand, if the information associated with the payment page is information about a store that operates a type 2 special terminal reading code, the payment management processing unit 113 generates type 2 payment schedule information including the store where the payment is scheduled. (excluding the scheduled payment amount) is transmitted to the terminal 20 via communication I/14.

When the payment application processing unit 213 receives the payment schedule information from the server 10 through the communication I/F 22 (L53), it performs the processes of A39 and A41, and then performs the sixth authentication skip determination process (L55).

In this sixth authentication skip determination process, the authentication skip determination processing unit 2135 determines whether authentication skip information is included in the code information acquired in the code information acquisition process of A33. In L51, if the special terminal reading code displayed on the store code reader device 50 is read, it is determined that the acquired code information includes authentication skip information, and the terminal reading displayed in the store is determined to include authentication skip information. If the authentication code has been read, it is determined that the acquired code information does not include authentication skip information. If it is determined that the acquired code information includes authentication skip information, it is determined that the authentication process is to be skipped. The payment application processing unit 213 then moves the process to A11.

<Effects of the third embodiment>
In the third embodiment, the server 10 (an example, not a limitation, of an information processing device) uses a special terminal reading code (not a limitation, a code example of information). The server 10 acquires information such as store information and sales amount information (not limited to, but an example of information) based on the special terminal reading code request information. Then, the server 10 generates a special terminal reading code based on the acquired information, including information regarding the authentication process to be executed by the terminal 20 (not limited to this, but an example of information regarding the authentication of the terminal user). It shows the configuration.
As an example of the effect obtained by such a configuration, the information processing device can easily generate code information including information related to authentication of the terminal user based on the acquired information. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Further, in the third embodiment, the special terminal reading code (an example of code information, not a limitation) includes information that can be read by an application code reader (an example of a code reader, not a limitation) of the terminal 20. It shows.
As an example of the effect obtained by such a configuration, the information processing device can generate code information including information read by a code reader of a terminal.

Further, the third embodiment shows a configuration in which the information acquired by the server 10 includes information different from the authentication password (not limited to this, but an example of authentication information for authenticating the user of the terminal).
As an example of the effect obtained by such a configuration, the information processing device acquires information different from the authentication information for authenticating the user of the terminal, so that the information processing device can store code information including information related to authentication of the user of the terminal. can be generated. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Further, the third embodiment shows a configuration in which the information different from the authentication password described above includes information regarding the location.
As an example of the effect obtained by such a configuration, the information processing device can generate code information including information regarding authentication of the user of the terminal by acquiring information regarding the location. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Further, the third embodiment shows a configuration in which the above information regarding the location includes store identification information (not limited to this, but an example of information regarding the store where payment using electronic money is performed by the terminal).
As an example of the effect obtained by such a configuration, the information processing device generates code information including information related to authentication of the user of the terminal by acquiring information about a store where electronic money payments are made using the terminal. can do. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Further, in the third embodiment, the above-mentioned special terminal reading code includes authentication skip information when the store is a store of the first specific industry stored in the server 10 (an example of a specific store, not limited to). This shows the configuration that will be generated including:
As an example of the effect obtained by such a configuration, if the store is a specific store stored in the information processing device, the information processing device may generate code information including information regarding authentication of the user of the terminal. I can do it. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Further, the third embodiment shows a configuration in which the information different from the above authentication password includes information regarding the product name and product type (not limited to, but an example of information related to the product) sold at the store.
As an example of the effect obtained by such a configuration, the information processing device can generate code information including information regarding authentication of the terminal user by acquiring information regarding the product. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Furthermore, the third embodiment shows a configuration in which the above-mentioned information regarding products includes information regarding products whose price is less than or equal to a set amount.
As an example of the effect obtained by such a configuration, the information processing device acquires information about products that are less than or equal to a set amount, and can generate a code including information related to authentication of the terminal user. Information can be generated. In this case, for example, if the price of the product purchased by the user is low, the risk is considered to be low. For this reason, by generating code information that includes information regarding the authentication of the terminal user, it is possible to ensure security while also allowing the terminal to obtain information regarding the authentication of the terminal user through the generated code information. Therefore, user convenience can be improved.

Further, the third embodiment shows a configuration in which the information regarding the above-mentioned products includes information regarding the total amount of products purchased by the user of the terminal 20 using IMS money.
As an example of the effect obtained by such a configuration, the information processing device acquires information regarding the total amount of products purchased by the terminal user using electronic money, and collects code information including information regarding the authentication of the terminal user. can be generated. In this case, for example, if the total amount of products purchased by the terminal user using electronic money is low, the risk is considered to be low. For this reason, by generating code information that includes information regarding the authentication of the terminal user, it is possible to ensure security while also allowing the terminal to obtain information regarding the authentication of the terminal user through the generated code information. Therefore, user convenience can be improved.

Further, the third embodiment shows a configuration in which the information acquired by the server 10 includes authentication skip request information (not limited to this, but an example of request information for requesting generation of information related to authentication of a terminal user). There is.
As an example of the effect obtained by such a configuration, the information processing device acquires request information for requesting generation of information related to authentication of a terminal user, and generates code information including information related to authentication of the terminal user. can be generated. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Furthermore, in the third embodiment, the information acquired by the server 10 includes authentication skip request information (not limited to this, but an example of request information requested by a server of a store that performs electronic currency payments using a terminal). It shows.
As an example of the effect obtained by such a configuration, the information processing device acquires request information requested by the server of the store that performs electronic money payments using the terminal, and then, according to the store's intention, the information processing device Code information can be generated, including information regarding authentication. Furthermore, since the terminal can acquire information regarding the authentication of the terminal user via the generated code information, the user's convenience can be improved.

Further, the third embodiment shows a configuration in which the information including the special terminal reading code includes authentication skip information (not limited to this, but an example of skip information for the terminal to skip the authentication of the terminal user). ing.
As an example of the effect obtained by such a configuration, the information processing apparatus can generate code information including skip information for the terminal to skip the authentication of the user of the terminal. Further, it is possible to cause the terminal to skip the authentication of the terminal user via the generated code information.

Further, in the third embodiment, the authentication skip information described above includes information that allows the terminal 20 to skip the authentication process when the terminal 20 acquires the authentication skip information.
As an example of the effect obtained by such a configuration, it is possible to easily and reliably cause the terminal to skip the authentication of the user of the terminal based on the skip information included in the code information.

Further, in the third embodiment, the server 10 transmits a special terminal reading code (not limited to, an example of code information) to the store code reader device 50 through the communication I/F 14, and the application code reader of the terminal 20 uses the special A configuration is shown in which payment request information is received from the terminal 20 by the communication I/F 14 based on the reading of the terminal reading code.
As an example of the effect obtained by such a configuration, the server can receive and acquire information regarding electronic money payment by the terminal based on the transmitted code information being read by the code reader of the terminal.

Furthermore, the third embodiment shows a configuration in which the information different from the above-mentioned authentication password includes authentication skip information associated with the above-mentioned special terminal reading code.
As an example of the effect obtained by such a configuration, the server can associate information different from authentication information with code information read by a code reader of a terminal.

Further, the third embodiment shows a configuration in which the above authentication skip information includes information generated by the store code reader device 50.
As an example of the effect obtained by such a configuration, the server can associate information generated based on the store that manages the product with code information read by the code reader of the terminal.

Further, the third embodiment shows a configuration in which the above authentication skip information is generated based on request information transmitted from the store code reader device 50.
As an example of the effect obtained by such a configuration, the server can generate information associated with code information based on a request from a store that manages products.

<Third modification (1)>
In the third embodiment, the server 10 generates a special terminal reading code that includes authentication skip information, but the invention is not limited to this. By way of example and not limitation, the server 10 may perform special terminal reading, including information used by the terminal 20 to skip authentication of the user of the terminal 20, i.e., information necessary for the terminal 20 to make an authentication skip determination. It is also possible to generate code for

Specifically, by way of example and not limitation, the server 10, in a special terminal reading code generation process, based on a request from the store, information regarding the price of the product that the user of the terminal 20 plans to purchase with IMS money, and the terminal 20 Information about products that the user of terminal 20 plans to purchase using IMS Money, information about the area where the user of terminal 20 makes payments using IMS Money, information about stores where the user of terminal 20 purchases products using IMS Money, etc. Information may also be included to generate a special terminal reading code.

For example, the store code reader device 50 includes the amount of products that the user of the terminal 20 plans to purchase and the total amount thereof as the scheduled payment amount in the special terminal reading code generation request information based on the operation of the store clerk. and sends it to the server 10. Then, the server 10 generates a special terminal reading code including the scheduled payment amount included in the special terminal reading code generation request information received from the store code reader device 50.

Further, for example, the store code reader device 50 may generate product identification information for identifying the product purchased by the user of the terminal 20 and product type identification information for identifying the product type based on the operation of the store clerk. , is included in the special terminal reading code generation request information and transmitted to the server 10. Then, the server 10 generates a special terminal reading code including the product identification information or product type identification information included in the special terminal reading code generation request information received from the store code reader device 50.

Further, for example, the store code reader device 50 sends information stored in advance in its own device, such as area information of the location of its own store and store identification information (store ID) of its own store, to a special terminal reading code generation request. It is included in the information and transmitted to the server 10. Then, the server 10 generates a special terminal reading code including the area information and store identification information included in the special terminal reading code generation request information received from the store code reader device 50.

The special terminal reading code generated by the server 10 in this manner is transmitted to the store code reader device 50, displayed, and read by the terminal 20, as described above. The terminal 20 can perform the authentication skip determination based on various types of information obtained by decoding data from the read special terminal reading code.
Note that the method for determining whether to skip authentication by the terminal 20 may or may not be performed based on the descriptions of the above-described embodiments and modifications.

<Effects of third modification (1)>
This modification shows a configuration in which the information included in the special terminal reading code includes information used by the terminal 20 to skip authentication of the user of the terminal 20.
As an example of the effect obtained by such a configuration, the server can generate code information including information used by the terminal to skip authentication of the user of the terminal. Additionally, information used by the terminal to skip the authentication of the user of the terminal can be acquired by the terminal through the generated code information, and based on this information, it is possible to determine whether or not to skip the authentication of the user. can be easily determined by the terminal.

Further, in this modification, the information included in the above-mentioned special terminal reading code includes information regarding a product that the user of the terminal 20 purchases with IMS money.
As an example of the effect obtained by such a configuration, the server can generate code information including information regarding products that the user of the terminal purchases with electronic money. In addition, the terminal user can obtain information about the product purchased with electronic money through the generated code information. For example, the user can skip user authentication based on the product the user purchases. The terminal can easily determine whether or not the

Furthermore, in this modification, the information regarding the product that the user of the terminal 20 purchases using IMS money includes information regarding the amount of the product that the user of the terminal 20 purchases using IMS money.
As an example of the effect obtained by such a configuration, the server can generate code information including information regarding the price of the product. In addition, information regarding the price of the product can be obtained by the terminal through the generated code information. For example, the terminal can determine whether or not to skip the user authentication based on the price of the product the user purchases. This can be easily determined.

Further, in this modification, the information included in the above-mentioned special terminal reading code includes information regarding the region (area) where the user of the terminal 20 makes the payment.
As an example of the effect obtained by such a configuration, the server can generate code information including information regarding the location. In addition, it is possible for the terminal to obtain information regarding the location via the generated code information. For example, the terminal can determine whether or not to skip the user authentication based on the area where the user makes payment or the location of the store. can be easily determined.

Further, in this modification, the information included in the above-mentioned special terminal reading code includes information regarding the store where the user of the terminal 20 purchases the product.
As an example of the effect obtained by such a configuration, the server can generate code information including information about the store where the product is purchased. In addition, the terminal can obtain information about the store where the product is purchased through the generated code information. For example, it is possible to determine whether or not to skip user authentication based on the store where the user purchases the product. This can be easily determined by the terminal.

<Third modification (2)>
In the third embodiment, the server 10 generates a special terminal reading code that includes authentication skip information, but the invention is not limited to this. Specifically, by way of example and not limitation, the terminal 20 is configured to display a terminal display code used in the payment type "terminal display code" and which includes authentication skip information (hereinafter, "special terminal display code"). It is also possible to generate a code (referred to as a "use code").

FIGS. 5-3 and 5-4 are flowcharts showing an example of the processing flow of each device in this case. Note that steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

If the payment application processing unit 213 determines that the payment type is "terminal code display" in A3 (A3; terminal code display), it performs a first authentication skip determination process (H3). Then, the payment application processing unit 213 performs processes A11 to A17.

If it is determined that the authentication result is "OK" in A15 (A15; Yes), or if it is determined that the authentication process is to be skipped in A11 (A11; Yes), the payment application processing unit 213 generates a special terminal display code. A generation process is performed (P15). Specifically, by way of example and not limitation, a special terminal display code is generated that includes authentication skip status information, which is information on whether or not the terminal 20 has skipped authentication processing. Then, the payment application processing unit 213 displays the generated special terminal display code on the display unit 24 (P19).

The store payment processing unit 513 causes the code reader 58 to read the special terminal display code displayed on the display unit 24 of the terminal 20 (Q9). Then, after performing code information acquisition processing to acquire information included in the read special terminal display code (Q11), the store payment processing unit 513 transmits the second payment request information including the acquired information to the communication I/O. It is transmitted to the server 10 by F54 (Q13).

When the payment management processing unit 113 receives the second payment request information from the store code reader device 50 via the communication I/F 14 (R9), the authentication skip determination processing unit 1139 performs a seventh authentication skip determination process (R11). ). Note that in order to distinguish from the authentication skip determination process in other embodiments, this will be referred to as a "seventh authentication skip determination process" for convenience.

In this seventh authentication skip determination process, the authentication skip determination processing unit 1139 determines whether the authentication process is skipped at the terminal 20 based on the authentication skip status information included in the second payment request information received from the store code reader device 50. Determine whether or not it has been done.

If the authentication process is not skipped by the terminal 20, the authentication skip determination processing unit 1139 determines that additional authentication is unnecessary. This is because the authentication process has already been completed on the terminal 20.
On the other hand, when the authentication process is skipped in the terminal 20, the authentication skip determination processing unit 1139 determines whether the authentication skip condition is successful or not based on the authentication skip condition included in the authentication skip condition data 156 in the storage unit 15. If the authentication skip condition is satisfied, it is determined that additional authentication is not necessary, and if the authentication skip condition is not satisfied, it is determined that additional authentication is necessary. This is because although the authentication process was skipped in the terminal 20, depending on the result of the authentication skip determination by the server 10, it may be better to have the terminal 20 perform additional authentication.

As a specific example, for example, due to a difference between the authentication skip settings on the terminal 20 side and the authentication skip settings on the server 10 side, the terminal 20 determines that the authentication processing should be skipped because the scheduled payment amount is not large. However, since the scheduled payment amount is large, the server 10 determines that there is a problem (risk) in having the terminal 20 skip the authentication process, so it cancels the authentication skip of the terminal 20 and causes the terminal 20 to perform additional authentication. There are cases.

Note that, unlike the above, if the authentication process is skipped by the terminal 20, the server 10 may trust the judgment of the terminal 20 and determine that additional authentication is not necessary. In this case, the server 10 side does not need to perform the authentication skip determination.

When it is determined that additional authentication is necessary in the seventh authentication skip determination process (G3; No), the payment management processing unit 113 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (G5). After receiving the authentication success information from the terminal 20 via the communication I/F 14 (G7), the payment management processing unit 113 performs payment processing (C11). Then, the payment management processing unit 113 moves the process to C13.

Note that in the above process, the terminal 20 generates a special terminal display code that includes the authentication skip status information, but the present invention is not limited to this.
For example, the terminal 20 may use special It is also possible to generate code for terminal display.

Specifically, by way of example and not limitation, in the special terminal display code generation process, the terminal 20 provides information regarding the price of the product that the user of the terminal 20 plans to purchase, and information regarding the product that the user of the terminal 20 plans to purchase. information, information about the region (area) where the user of the terminal 20 makes payments, information about the store where the user of the terminal 20 purchases products, information about the settings of the terminal 20 or the payment application, the lock status of the OS side of the terminal 20 (lock For special terminal display, it includes various information such as information regarding lock settings (ON/OFF), lock status (lock status) and lock settings (ON/OFF) on the payment application side of the terminal 20. It can also be configured to generate code.

For example, the terminal 20 generates a special terminal display code based on the user's operation, including the amount of products that the user of the terminal 20 plans to purchase and their total amount as the scheduled payment amount.

For example, the terminal 20 may display a special terminal display including product identification information for identifying the product purchased by the user of the terminal 20 and product type identification information for identifying the product type based on the user operation. Generate code for

Further, for example, the terminal 20 generates a special terminal display code including area information regarding the area where the terminal 20 is located based on the latest calculated position stored in the calculated position history data 288. Or, based on the user's operation, a special terminal display code is generated including the store identification information (store ID) of the store where the user of the terminal 20 purchases the product.

Further, for example, the terminal 20 may display a special terminal display including information on the authentication setting (ON/OFF) on the terminal 20 side and information on the authentication setting (ON/OFF) on the payment application side of the terminal 20. Generate code for

Further, for example, the terminal 20 can check the lock status (locked or not) on the OS side of its own terminal 20, the lock status (locked or not) on the payment application side, and, for example, the lock setting on the OS side of its own terminal 20. A special terminal display code is generated, including (ON/OFF) and lock settings (ON/OFF) on the payment application side.

The special terminal display code generated by the terminal 20 in this manner is displayed on the display section 24 of the terminal 20 and read by the store code reader device 50, as described above. Then, second payment request information including various information obtained by decoding data from the read special terminal display code is transmitted from the store code reader device 50 to the server 10. Then, the server 10 can perform the authentication skip determination based on the various types of information described above included in the second payment request information received from the store code reader device 50.
Note that the method for determining whether to skip authentication by the server 10 may or may not be performed based on the above-described embodiment and modification.

<Effects of third modification (2)>
In this modification, the terminal 20 (not limited to, an example of an information processing device) displays a special terminal display code (not limited to code information) regarding payment of IMS money (not limited to, but an example of electronic money) by the terminal 20. example). The terminal 20 stores information regarding the price of the product that the user of the terminal 20 plans to purchase, information regarding the product that the user of the terminal 20 plans to purchase, information regarding the region (area) where the user of the terminal 20 makes the payment, Information such as information regarding the store where the user purchases the product, information regarding whether or not the terminal 20 is locked, information regarding whether or not the payment application of the terminal 20 is locked, etc. (one example of information, not limited to) is acquired. Then, the terminal 20 generates a special terminal display code based on the acquired information, including information regarding the authentication process to be executed at the terminal 20 (not limited to this, but an example of information regarding authentication of the terminal user). It shows the configuration.
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can easily generate code information, including information related to authentication of a user of the terminal, based on acquired information. . Furthermore, information regarding the authentication of the user of the terminal can be provided to other devices via the generated code information.

Further, this modification shows a configuration in which the terminal 20 generates a special terminal display code including information regarding the authentication process executed by the terminal 20 described above.
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can easily generate code information including information related to authentication of a user of the terminal.

Furthermore, in this modification, the information included in the above special terminal display code includes authentication skip status information (not limited to this, but an example of information indicating that the user of the terminal has been authenticated by the terminal). ing.
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information indicating that the user of the terminal has been authenticated by the terminal.

Furthermore, this modification shows a configuration in which the information acquired by the terminal 20 includes information different from the authentication password (not limited to this, but an example of authentication information for authenticating the user of the terminal).
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information different from authentication information for authenticating a user of the terminal.

Furthermore, this modification shows a configuration in which the information different from the above-mentioned authentication password includes information regarding IMS money (not limited to this, but an example of information regarding electronic money).
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information regarding electronic money.

Furthermore, this modification shows a configuration in which the information different from the above-mentioned authentication password includes information regarding the region (area) where the user of the terminal 20 makes the payment (not limited to this, but an example of information regarding the location).
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information regarding a location. For example, by including information on the location where the terminal user makes payment as the location information, the information on the location where the terminal user makes payment can be provided to another device via the generated code information.

Furthermore, this modification shows a configuration in which the information different from the authentication password described above includes information regarding a product that the user of the terminal 20 plans to purchase (not limited to this, but an example of information regarding the product).
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information regarding a product.

In addition, in this modification, information different from the above authentication password is information regarding the authentication settings (ON/OFF) on the terminal 20 side and the authentication settings (ON/OFF) on the payment application side (not limited to the terminal or A configuration including an example of information related to application settings stored in a terminal is shown.
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information related to the settings of the terminal or an application stored in the terminal.

In addition, in this modification, information different from the above authentication password includes information regarding the lock status and lock settings of the terminal 20, information regarding the lock status and lock settings of the payment application of the terminal 20 (not limited to the terminal, A configuration including an example of information regarding the security of an application stored in a terminal is shown.
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can generate code information including information related to the security of the terminal or an application stored in the terminal.

Furthermore, this modification shows a configuration in which the information included in the special terminal display code is acquired by the server 10 (not limited to this, but an example of a server that manages electronic money payments).
As an example of the effect obtained by such a configuration, a terminal, which is a type of information processing device, can provide information regarding authentication of a user of the terminal to a server that manages electronic money payments.

In addition, in this modification, based on the information included in the special terminal display code, if the authentication skip condition is satisfied, the server 10 sends additional authentication request information (without limitation, the terminal executes the authentication of the terminal user). The communication I/F 14 of the server 10 does not send payment result information (an example of information indicating that a payment was made using electronic money) to the terminal 20 via the communication I/F 14 of the server 10. /F14 shows a configuration for transmitting to the terminal 20.
As an example of the effect obtained by such a configuration, a server that manages electronic money payments may transmit information regarding the authentication of the terminal user by the terminal based on information regarding the authentication of the terminal user to the server. Since the communication unit transmits payment information indicating that payment using electronic money has been made to the terminal without transmitting it to the terminal, the processing load on the server can be reduced.

<Third modification (3)>
The generation of the special terminal reading code described in the third embodiment can be performed on a store-by-store basis, as well as on a product-by-product or product-by-product basis as in the first modification (10). It is also possible to perform this on a per-type basis.

As an example and not a limitation, if the store wishes to skip the authentication for the product types "lunch box" and "beverage", for example, similar to the example shown in FIG. 10, special terminal reading code generation request information including the store ID, identification information of the product type (here, "lunch box" and "beverage"), sales amount information, and authentication skip request information is transmitted. Based on receiving the special terminal reading code generation request information from the store code reader device 50, the server 10 generates a special terminal reading code including authentication skip information for the product types "lunch box" and "beverage". generate.

On the other hand, as in the example shown in Figure 3-36, for example, if the store wishes to not skip authentication for the product type "gift product," instead of using a special terminal reading code that includes authentication skip information, Send terminal reading code generation request information requesting generation of a normal terminal reading code that does not include authentication skip information. Then, based on receiving the terminal reading code generation request information from the store code reader device 50, the server 10 generates a terminal reading code that does not include authentication skip information for the product type "gift product."

Furthermore, similar to <First Modification (10)>, within one product type, products for which authentication is to be skipped and products for which authentication is not to be skipped may be classified. As described above, in this example, the product type "lunch box" is classified into bento boxes with a sales amount of "200 yen," lunch boxes with a sales amount of "300 yen," and lunch boxes with a sales amount of "500 yen." Then, the server 10 generates a special terminal reading code that includes authentication skip information for products that skip authentication, and generates a normal terminal reading code that does not include authentication skip information for products that do not skip authentication. I'll do what I do.

<Effects of third modification (3)>
As an example of the effect obtained by this modification, the information processing device can generate code information including information related to authentication of a terminal user for each product sold at a store or each product type. Additionally, depending on the products and product types sold at the store, the code information may or may not include information related to the authentication of the terminal user, so code information can be generated according to the store's wishes. be able to.

<Fourth embodiment>
The fourth embodiment is an embodiment in which, by way of example and not limitation, a user of a terminal 20 uses a payment application to remit IMS money to a terminal 20 of a user registered as a friend in an IMS application. At this time, the remittance authentication required of the user is skipped if specific conditions are met.

Unless otherwise specified, "authentication" in this embodiment means to authenticate that the user of the terminal 20 is an authorized user in order to make a remittance, and "authentication processing" refers to means the process to achieve authentication.
In addition, "authentication skip conditions" means conditions for skipping the authentication process for remittances described above, unless otherwise specified, and "skip authentication process" refers to conditions for ignoring the processing instructions for authentication process. , which means processing the next command, that is, omitting the authentication process.
The content described in the fourth embodiment is applicable to any of the other embodiments.

<Functional configuration>
(1) Functional configuration of server FIG. 6-1 is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.
In addition to the server main processing section 111 and the IMS processing section 112, the payment management processing section 113 includes a remittance management processing section 115 as a functional section.

The remittance management processing unit 115, in accordance with the remittance management processing program 1517 stored in the storage unit 15, remits IMS money to the terminal 20 of another user who is registered as a friend in the IMS application, or controls the terminal of this other user. It has a function of executing remittance management processing, which is processing for managing money received from 20.

The remittance management processing unit 115 includes, by way of example and not limitation, a remittance processing unit 1151, a remittance source-side remittance result information transmission processing unit 1153, and a payment-receiving side remittance result information transmission processing unit 1155 as functional units.

The remittance processing unit 1151 performs remittance processing, which is a process of transmitting IMS money owned by the user of the first terminal 20 to the second terminal 20 based on remittance request information transmitted from the first terminal 20. It has the ability to execute.

The remittance source remittance result information transmission processing unit 1153 has a function of transmitting remittance result information, which is information regarding remittance results, to the first terminal 20 that is the remittance source of IMS money.

The deposit result information transmission processing unit 1155 for the deposit side has a function of transmitting deposit result information, which is information regarding the deposit result, to the second terminal 20, which is the IMS money deposit side. There is.

FIG. 6-2 is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
In addition to the IMS processing program 1512, the server main processing program 151 includes a remittance management processing program 1517, which is executed as a remittance management process, as a subroutine program.

In addition to the user registration data 153 and the store registration data 155, the storage unit 15 also stores an IMS user management database 161, an IMS group management database 163, and a money transfer management database 165.

In this embodiment, the user information stored and registered in the user registration data 153 will be described as user information shared between the IMS application and the payment application.

The IMS user management database 161 is a database for managing data related to IMS usage by users registered in the user registration data 153, and an example of its data structure is shown in FIG. 6-3.
The IMS user management database 161 stores individual IMS user management data for each of a plurality of users.

By way of example and not limitation, user content history data is stored in each user's IMS user management data in association with a user name and user ID.

User content history data is data related to the history of content sent and received between this user's terminal 20 and other users' terminals 20, and includes, by way of example and not limitation, content sent and received in this user's talk room. , data in which the date and time when the content was sent and received and the content number, which is identification information for identifying the content, are associated with each other is stored as a history.

The IMS group management database 163 is a database for managing data related to the use of IMS by a group consisting of multiple users registered in the user registration data 153. An example of the data structure is shown in Figure 6-4. show.
The IMS group management database 163 stores individual IMS group management data for each of a plurality of groups.

The IMS group management data for each group includes, by way of example and not limitation, the group name that is the name of this group, the group ID, the date and time of group creation, the number of people in the group, group user data, and group content history data. be remembered.

The group ID is an ID that functions as identification information for identifying this group, and an ID for uniquely identifying each group is stored and registered.

The group creation date and time is the date and time when this group was created. By way of example and not limitation, groups can be created arbitrarily by users using IMS, and a user who has created a group or a user who has joined a group can invite other users to the group. Users can be added to groups.

The total number of users included in this group is stored in the group number of people. Each time a new user joins a group, the number of people in the group is incremented and updated, and each time a user who has already joined the group leaves the group, the number of people in the group is subtracted and updated.

Group user data includes, by way of example and not limitation, the user names of users included in this group (hereinafter referred to as "group users"), the user IDs of this group users, and the information that this group user has joined this group. The date and time of group joining, which is the date and time of joining the group, are stored in association with each other.

Group content history data is data related to the history of content sent and received between the terminals 20 of group users included in this group, and includes, by way of example and not limitation, content sent and received in the talk room of this group, and content sent and received between the terminals 20 of group users included in this group. Data that associates the date and time of the content with a content number for identifying the content is stored as a history.

The remittance receipt management database 165 is a database for managing data regarding remittances and receipts, and an example of its data structure is shown in FIG. 6-5.
The remittance management database 165 stores individual remittance management data for each of a plurality of users.

The remittance receipt management data for each user includes a user ID, balance, IMS points, daily upper limit set amount, auto charge setting, remittance history data, and deposit history data.

Remittance history data is historical data regarding remittances from the user with this user ID, and includes, by way of example and not limitation, the remittance date and time, the remittance destination user ID that is the user ID of the remittance user, and the remittance The remittance amount, which is the amount received, is stored in association with the remittance amount.

The money receipt history data is historical data regarding money received by the user with this user ID, and includes, by way of example and not limitation, the date and time of money arrival, and the remittance source user, which is the user ID of the remittance source user. The ID and the amount of money received, which is the amount of money received, are stored in association with each other.

In this embodiment, the server 10 performs remittance processing based on the remittance function (send money) of the payment application. Specifically, by way of example and not limitation, the server 10 may, based on receiving remittance request information sent from the terminal 20 of the one user, contact the one user with another user who is registered as a friend in the IMS application. A process of remitting IMS money to the user's terminal 20 is performed.

The server 10 also performs remittance request processing based on the remittance request function (receiving remittance) of the payment application. Specifically, by way of example and not limitation, the server 10 receives remittance request information sent from the terminal 20 of the user, and sends the request information to the user who is registered as a friend in the IMS application. A process is performed to request the terminal 20 of the other user to remit money to the terminal 20 of the one user.

Further, the remittance request processing includes bill splitting request processing based on the bill splitting function of the payment application. Bill-splitting request processing is based on receiving bill-splitting request information from one user's terminal 20. This is a process of requesting the terminals 20 of a plurality of other users included in the same group as one user in an application for an amount equal to the amount specified by one user divided by the total number of users. The bill-splitting function allows users who are registered as friends in an IMS application or users who have formed a group in an IMS application to hold a dinner party or drinking party, for example, where one user who is the organizer can It is used when charging multiple users an amount equal to the total amount divided by the total number of participants.

(2) Functional configuration of terminal FIG. 6-6 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
The payment application processing section 213 includes a remittance request processing section 2138 as a functional section in addition to an authentication skip determination processing section 2135 and an authentication processing section 2137.

The remittance request processing unit 2138 has a function of executing a process of requesting the server 10 to remit money to another terminal 20 registered as a friend in the IMS application or a user to another terminal 20.

FIGS. 6-7 are diagrams showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment.
IMS application 282 includes, by way of example and not limitation, an IMS application processing program 2821 that is executed as an IMS application process, and IMS application data 2823.

IMS application data 2823 includes, by way of example and not limitation, friend data 2825, group data 2826, user content history data 2827, and group content history data 2828.

The friend data 2825 is data related to users who are registered as friends by the user of the own terminal 20, and includes, by way of example and not limitation, information such as the user name, user ID, icon image, profile, etc. of the user who is registered as a friend. be remembered.

The group data 2826 is data regarding the group to which the user of the own terminal 20 has joined, and includes, by way of example and not limitation, the group name of the group to which the user of the own terminal 20 has joined, the group ID, and the group name of the group to which the user of the own terminal 20 has joined. Information such as user names, user IDs, icon images, profiles, etc. of other included group users is stored.

The user content history data 2827 is data related to the history of content sent and received between the own terminal 20 and the terminals 20 of other users who are registered as friends, and includes, by way of example and not limitation, this user's talk room. Data that associates content sent and received, the date and time when the content was sent and received, and a content number that is identification information for identifying the content is stored as a history.

The group content history data 2828 is data related to the history of content sent and received between the terminals 20 of group users included in the group to which the user of the own terminal 20 has joined, and includes, by way of example and not limitation, the talk of this group. Data that associates content sent and received in the room, the date and time when the content was sent and received, and a content number for identifying the content is stored as a history.

The payment application program 284 includes an authentication skip determination processing program 2845 and an authentication processing program 2847 as subroutine programs, similar to the embodiment described above.

In addition, the payment application data 285 includes, by way of example and not limitation, in addition to the store data 2855, authentication skip condition data 2856, remittance payment data 2857, and location area registration data 2858.

In the position area registration data 2858, information regarding various positions and areas is stored by the control unit 21 based on the history of the calculated position of the own terminal 20 stored in the calculated position history data 288.

In the location area registration data 2858, for example, location information of the user's home location of the user's own terminal 20 is registered. By way of example and not limitation, the control unit 21 may store, in the calculated position history data 288, position information corresponding to the calculated position that is statistically most frequently stored during the time period from 10:00 p.m. on weekdays to 6:00 a.m. the next day. , is registered as the location information of the user's home of the own terminal 20.

Further, in the location area registration data 2858, for example, location information of the company (place of work) where the user of the terminal 20 works is registered. As an example and not a limitation, the control unit 21 may use its own location information corresponding to the calculated position that is statistically stored most often in the time period from 9:00 to 17:00 on weekdays in the calculated position history data 288. It is registered as the location information of the company (workplace) of the user of the terminal 20.

Further, in the location area registration data 2858, for example, location information of a remittance safe area, which is an area preset by the server 10 and is an area where remittance is safe, is registered. By way of example and not limitation, the server 10 can preset location information of a rural or rural area away from the city center as the location information of a remittance safe area.

Further, it is also possible to register the location information of a place that the user of the own terminal 20 frequently visits, for example, a place that the user of the own terminal 20 has visited a set number of times or more, as a remittance safe area. In this case, the control unit 21 may calculate, by way of example and not limitation, in addition to the above-mentioned home and office (workplace), calculated positions that occur more frequently than the set frequency and the set number of times in the calculated position history data 288. Calculated positions that have occurred the above number of times can be registered as places frequently visited by the user of the user's own terminal 20, including their positional information in the remittance safe area.

Furthermore, the user of his or her own terminal 20 can also register the location and area in the location area registration data 2858. For example, the user of his or her own terminal 20 may register the home location information of a person related to him or her (for example, a relative, a close friend, or a person associated with a company).

FIG. 6-8 is a diagram showing an example of the data structure of the authentication skip condition data 2856 in this embodiment.
This authentication skip condition data 2856 stores, by way of example and not limitation, a condition category number, a condition number, an authentication skip condition, and a degree of importance (priority) in association with each other.

<Condition Category No. “SP11”>
Condition category No. "SP11" is a "time" category, and includes, by way of example and not limitation, the authentication skip conditions of condition No. "SP11-1" and "SP11-2."

The authentication skip condition of condition No. "SP11-1" is defined as "the current date and time is within a set time from the last remittance date and time". This means that if the current date and time is within the set time from the last remittance date and time, the remittance will be made again in a short period of time, so authentication is omitted to improve user convenience. do.

In determining this authentication skip condition, by way of example and not limitation, the terminal 20 determines the current date and time based on the clock time measured by the clock unit 29A, and the last By acquiring the remittance date and time, it can be determined whether the current date and time is within a set time from the last remittance date and time.

As the authentication skip condition of condition No. "SP1-2", "the current time is included in the set time zone" is defined. By way of example and not limitation, the set time period can be set in advance by the user of the terminal 20. Specifically, for example, the user of the terminal 20 may set a time period during which he or she frequently remits money or a time period during which remittances are likely to be made (e.g., meal time) as a set time period. Authentication can be omitted when remittance is made during a set time period.

In determining this authentication skip condition, by way of example and not limitation, the terminal 20 obtains the current time based on the time measured by the clock unit 29A, and determines whether the current time is included in the set time zone. It is possible to make a judgment.

<Condition Category No. “SP12”>
Condition category number "SP12" is a category of "terminal/location", and includes, by way of example and not limitation, authentication skip conditions of condition numbers "SP12-1" to "SP12-4".

As the authentication skip condition of condition No. "SP12-1", "the location of the own terminal is not far from the location of the home" is defined. This is because if the location of the user's own terminal 20 is not far from the home location of the user of the user's own terminal 20, it is presumed that the remittance is safe (there is no problem in making the remittance). This means omitting authentication to improve convenience.

In determining this authentication skip condition, the terminal 20 acquires, by way of example and not limitation, the latest calculated position stored in the calculated position history data 288 and the home position registered in the position area registration data 2858. Then, it can be determined whether the distance between the calculated position of the own terminal 20 and the position of the home is less than or equal to the set distance (or less than the set distance).

As the authentication skip condition of condition No. "SP12-2", "the location of the own terminal is included in the remittance safe area" is defined. This is because if the location of your terminal 20 is included in the remittance safe area, it is presumed that the remittance is safe (there is no problem in making the remittance), so authentication is required to improve user convenience. Means omitted.

In determining this authentication skip condition, the terminal 20 acquires, by way of example and not limitation, the latest calculated position stored in the calculated position history data 288 and the safe remittance area registered in the position area registration data 2858. Then, it can be determined whether the calculated position of the own terminal 20 is included in the safe remittance area.

The authentication skip condition of condition No. "SP12-3" is defined as "the location of the terminal is not far from the location of the store compatible with the payment application". This is because if the location of your terminal 20 is not far from the location of a store (affiliated store) that can accept payments using a payment application, it is presumed that there is a need to send money. This means omitting authentication to improve user convenience. For example, there are cases where users of the terminal 20 and their friends go out to eat and drink at a store that supports payment applications, and then make payments using the payment application. In this case, if the payment application is equipped with a function to split the bill, there is a high possibility that the bill will be split between friends. Therefore, if the location of the user's own terminal 20 and the location of the store compatible with the payment application are not far apart, authentication can be skipped for the purpose of promoting splitting of bills.

In determining this authentication skip condition, the terminal 20 obtains, by way of example and not limitation, the latest calculated position stored in the calculated position history data 288 and the position of the affiliated store stored in the store data 2855. Then, it can be determined whether the distance between the calculated position of the own terminal 20 and the position of the affiliated store is less than or equal to the set distance (or less than the set distance).

The authentication skip condition of condition No. "SP12-4" is defined as "the location of the own terminal is not far from the location of the terminal that transmitted the bill splitting request". This means that if the location of your own terminal 20 is not far from the location of the terminal that sent the bill splitting request, the user of your own terminal 20 who receives the bill splitting request from the user of another terminal 20 will immediately transfer money. This means that authentication is omitted in order to improve user convenience.

In determining this authentication skip condition, the terminal 20 acquires the latest calculated position stored in the calculated position history data 288, by way of example and not limitation, and also informs the server 10 of the position of the terminal 20 that has transmitted the split bill request. The location of the terminal 20 that has sent the bill splitting request is received from the server 10 and acquired. Then, it can be determined whether the distance between the calculated position of the own terminal 20 and the position of the terminal 20 that transmitted the split bill request is less than or equal to the set distance (or less than the set distance).

<Condition Category No. “SP13”>
Condition category number "SP13" is a category of "amount", and includes, by way of example and not limitation, authentication skip conditions of condition numbers "SP13-1" to "SP13-4".

As the authentication skip condition of condition No. "SP13-1", "the daily maximum set amount is not exceeded" is defined.
The "daily upper limit set amount" is the upper limit set amount that is used as a threshold for the total amount of remittances already remitted (remitted amounts) in one day. In other words, if the total amount of remittances already remitted in one day does not exceed the daily upper limit set amount, authentication is omitted in order to improve user convenience.

Conversely, if the total amount of remittances that have already been remitted in a day exceeds the daily upper limit, authentication will be performed so that the terminal 20 can confirm that excessive remittances have been made. users can be notified, and overuse can be prevented. Additionally, when a minor or child sends money, parents can set restrictions on usage.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the daily upper limit set amount stored in the remittance receipt data 2857 and the daily remittance amount specified from the remittance history data. The total amount can be acquired, and it can be determined whether the total amount exceeds the daily upper limit setting amount.

As the authentication skip condition of condition No. "SP13-2", "balance is less than the set amount (or less than the set amount) & auto charge setting OFF" is defined. By way of example and not limitation, the set amount can be set in advance by the user of the terminal 20. This is for the convenience of the user, as if the balance is less than the set amount and the auto charge setting is "OFF", the user will not be able to make a large remittance, and the risk is considered to be low. Authentication is omitted to improve performance.

However, if the auto charge setting is "ON", IMS money is automatically replenished, allowing the user to make a large remittance, which poses a risk. Therefore, the conditions for authentication skip are that the balance is less than or equal to the set amount (or less than the set amount) and that the auto charge setting is "OFF".

In this case, if the auto charge setting is "ON", the authentication process will not be skipped in principle even if the balance is less than or equal to the set amount (or less than the set amount). However, as mentioned above, in order to improve user convenience, it is also possible to skip the authentication process even if the auto charge setting is "ON". In this case, by way of example and not limitation, the auto-charge setting OFF may be excluded from the authentication skip condition of condition No. "SP13-2" and set to "balance is less than or equal to the set amount (or less than the set amount)". In other words, even if the auto charge setting is "ON", it does not necessarily mean that authentication processing is required.If auto charge is "ON", even if the balance is less than the set amount (or less than the set amount) For example, there may be cases where authentication processing is performed, or there may be cases where authentication processing is not performed.

In determining this authentication skip condition, the terminal 20 acquires the balance and auto charge settings stored in the remittance/receipt data 2857, and determines that the balance is less than or equal to the set amount (or less than the set amount), by way of example and not limitation. In addition, it can be determined whether or not the auto charge setting is "OFF".

As the authentication skip condition of condition No. "SP13-3", "the frequency of remittance per month or the amount of remittance is within an appropriate range" is specified. For example, the threshold frequency is the average value, maximum value, or mode of the frequency of remittances per month during a predetermined period of the past (the past 6 months or the past year), and the average amount of remittances per month during the same predetermined period of the past. The value, maximum value, and mode are calculated as the threshold amount. Then, if the remittance frequency exceeds the threshold frequency or the remittance amount exceeds the threshold amount by performing remittance from now on, authentication is performed, and in other cases, authentication is omitted.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the remittance frequency and remittance amount calculated from the remittance history data stored in the remittance receipt data 2857, and the remittance amount stored in the storage unit 28. By acquiring the threshold frequency and threshold amount, it is possible to determine whether the remittance frequency exceeds the threshold frequency and whether the remittance amount exceeds the threshold amount.

Note that the above authentication skip condition may or may not be based on the number of times IMS Money has been remitted (number of remittances), rather than the frequency of IMS Money remittances (remittance frequency). Good too. In addition, it may or may not be possible to set separate conditions for remittance frequency being within an appropriate range, remittance frequency being within an appropriate range, and remittance amount being within an appropriate range. It's okay.

As the authentication skip condition of condition No. "SP3-4", "the scheduled remittance amount is less than or equal to the set amount (or less than the set amount)" is defined. The set amount can be set as a not-so-large amount, such as 10,000 yen or 20,000 yen, for example.
"Scheduled remittance amount" means the amount scheduled to be remitted from now on (the amount in an undetermined state before remittance). In other words, if the amount to be remitted is not very large, authentication is omitted to improve user convenience.

In determining this authentication skip condition, the terminal 20 obtains, by way of example and not limitation, the amount input by the user of the terminal 20 as the scheduled remittance amount, and if the scheduled remittance amount is less than or equal to the set amount (or less than the set amount) It can be determined whether or not.

<Condition Category No. “SP14”>
Condition category number "SP14" is a category of "remittance partner", and includes, by way of example and not limitation, the authentication skip conditions of condition numbers "SP14-1" to "SP14-3".

The authentication skip condition of condition No. "SP14-1" is defined as "the intended recipient is a close friend or relative." If the person to whom the remittance is planned is a close friend or relative of the user of the terminal 20, there is a rational reason for the remittance, so authentication is omitted to improve user convenience. It means to do.

In determining this authentication skip condition, the terminal 20 is determined to be a user who is registered as a friend based on the friend data 2825 of the IMS application 282 and the user content history data 2827, and the content is A user whose transmission/reception frequency exceeds a threshold frequency or whose content transmission/reception frequency exceeds a threshold frequency is determined to be a close friend of the user of the terminal 20. Also, by referring to the group data 2826 of the IMS application 282, groups whose group names include characters such as "family", "family", "relatives", "relatives", etc. are identified, and the group users included in the groups are identified. are determined to be relatives. If the intended recipients of remittance are these users, it is determined that this authentication skip condition is satisfied.

As the authentication skip condition of condition No. "SP14-2", "the intended recipient has a history of remittances in the past" is set. This means that if you have sent money to the person you are planning to send money to in the past, it is presumed that the person is someone you owe money to, so authentication is omitted to improve user convenience. do.

In determining this authentication skip condition, the terminal 20 refers to the remittance history data stored in the remittance receipt data 2857, by way of example and not limitation, and determines whether the remittance recipient has sent remittances at least once in the past. If it is determined that there has been a remittance, it is determined that this authentication skip condition is satisfied.

The authentication skip condition of condition No. "SP14-3" is defined as "there is a history of receiving money in the past from the intended remittance party". This is because if the person you are planning to send money to has received money in the past, it is assumed that the person is the person to whom you owe money, so in order to improve user convenience, authentication may be omitted. means.

<Condition Category No. “SP15”>
Condition category No. "SP15" is a "security" category, and includes, by way of example and not limitation, the authentication skip condition of condition No. "SP15-1."

“The terminal is locked or the payment application is locked” is defined as the authentication skip condition of condition No. “SP15-1”. This means that if the terminal 20 itself is locked or the payment application is locked, you may have to enter the terminal unlock password or the payment application unlock password to release the lock. Since authentication is required, this means that re-authentication is not required to improve user convenience.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the information on whether or not the own terminal 20 is locked, which is stored in the terminal data 286, and the payment application information stored in the payment application data 285. Information on whether the terminal is locked or not can be acquired to determine whether the terminal is locked or the payment application is locked.

<Condition Category No. “SP16”>
Condition category No. "SP16" is a category of "authentication settings", and includes, by way of example and not limitation, the authentication skip condition of condition No. "SP16-1".

As the authentication skip condition of condition No. "SP16-1", "authentication setting on the terminal side or authentication setting on the payment application side is OFF" is defined.
Authentication on the terminal side refers to authentication required of the user on the terminal 20 side, such as authentication for unlocking the terminal and authentication of the user.
On the other hand, authentication on the payment application side refers to authentication required of the user when remittance is made using the payment application.

This occurs when the terminal 20 side is set to not perform authentication required by the user on the terminal 20 side, such as authentication for unlocking the terminal or user authentication (setting OFF), or when the payment application side If the setting is such that the authentication required of the user is not performed when remittance using the payment application (setting OFF), it means that the authentication is omitted.

In determining this authentication skip condition, the terminal 20 uses, by way of example and not limitation, the authentication settings on the terminal side stored in the terminal data 286 and the authentication skip condition user setting data stored in the remittance/receipt data 2857. The condition-specific setting flag of the condition No. "SP16-1" is acquired, and it is determined whether at least one of the authentication settings on the terminal side and the authentication settings on the payment application side is "OFF". It can be done.

<Condition Category No. “SP17”>
Condition category No. "SP17" is a "situation judgment" category, and includes, by way of example and not limitation, the authentication skip condition of condition No. "SP17-1."

The authentication skip condition of condition No. "SP17-1" is defined as "There are terminals that have received bill splitting requests at the same time, and authentication is completed on more than the set number of terminals."
This means that when multiple terminals 20 including one's own terminal 20 receive bill split requests from other terminals 20 at the same time, remittances can be made at more than the set number of terminals 20 among the other terminals 20 other than one's own terminal 20. If the authentication for the terminal 20 is completed, it means that the authentication of the own terminal 20 is omitted.

In determining this authentication skip condition, the terminal 20 queries the server 10 for information on the authentication status of other terminals 20 that have received the same split bill request, and the terminal 20 inquires about the authentication status of the other terminal 20 from the server 10, by way of example and not limitation. information can be acquired to determine whether or not authentication has been completed on more than a set number of terminals 20.

Further, a degree of importance (priority) is determined in association with each of the above authentication skip conditions. Specifically, as an example and not a limitation, authentication skip conditions of condition No. "SP12-1" to "SP12-4" (condition category No. "SP12") and condition No. "SP14-1" to "SP14-3" are provided. ” (condition category No. “SP14”) and the authentication skip condition No. “SP16-1” are each given an importance level of “A”.

In addition, as an example and not a limitation, the authentication skip conditions of condition No. "SP11-1", condition No. "SP13-1", "SP13-2", "SP13-4", and condition No. "SP15-1" are also provided. An importance level of "B" is set for each of the authentication skip condition and the authentication skip condition of condition No. "SP17-1".

Furthermore, by way of example and not limitation, the importance level "C" is set for the authentication skip conditions of condition Nos. "SP11-2" and "SP13-3."

Note that in this embodiment, the degree of importance is set in association with the authentication skip condition, but the setting of this degree of importance is not an essential requirement, and the degree of importance does not need to be set. In other words, the importance column does not need to be provided in the authentication skip condition data 2856 described above.
In this case, in the authentication skip determination process, by way of example and not limitation, the success or failure of the authentication skip conditions is determined in an arbitrary order, and if any of the authentication skip conditions is met, it is determined that the authentication process is to be skipped. Just do it.

FIG. 6-9 is a diagram showing an example of the data structure of the remittance receipt data 2857.
The remittance receipt data 2857 includes, by way of example and not limitation, the user ID of the payment application, the authentication password which is the password for authentication, and the payment application lock which is the password to unlock the payment application. The cancellation password, IMS points, balance, daily maximum set amount, auto charge settings, remittance history data, payment history data, authentication skip condition settings, and authentication skip condition user setting data are stored. Ru.
Data other than the remittance history data and payment history data is the same as in the embodiment described above, and therefore will not be described again.

The remittance history data is data related to the remittance history of the user with this user ID, and includes, by way of example and not limitation, the date and time of remittance, which is the date and time of remittance, and the user ID of the user to whom the remittance is made. The remittance destination user ID and the remittance amount, which is the remitted amount, are stored in association with each other.

The money receipt history data is data related to the history of money receipt of the user with this user ID, and includes, by way of example and not limitation, the date and time of money receipt, which is the date and time when the money was received, and the date and time of the money transfer source user. The remittance source user ID, which is a user ID, and the amount of money received, which is the amount of money received, are stored in chronological order in association with each other.

<Remittance method>
A remittance method using a payment application in this embodiment will be described with reference to an example of a display screen displayed on the display unit 24 of the terminal 20.

(1) Normal remittance Figures 6-10 to 6-15 are screen diagrams for explaining the flow of remittance without skipping authentication when performing normal remittance.

FIG. 6-10 is a diagram showing an example of a talk room screen in the IMS application displayed on the display unit 24 of the terminal 20.
This talk room screen shows, by way of example and not limitation, that "User A.A" who is a user of his own terminal 20 talks with "User B.B" who is a user of another terminal 20 who is registered as a friend. Shows the talk room screen for doing so. At the bottom of the chat room screen, a ``remittance icon'' labeled ``remittance'' is displayed as a function of the payment application linked to the IMS application.

FIG. 6-11 is a diagram showing an example of a screen displayed when the "remittance icon" is touched by the user of the terminal 20 on the above talk room screen.
On this screen, a "remittance icon" indicating "send money" and a "remittance request icon" indicating "remit money" are displayed in a pop-up format in the center of the screen of the talk room screen. .
The remittance icon is an icon used when "user A.A" remits money to "user B.B". On the other hand, the remittance request icon is an icon used when "user A.A" requests remittance from "user B.B".

FIG. 6-12 is a diagram showing an example of a remittance screen that is displayed when the "remittance icon" is touched by the user of the terminal 20 on the above screen.
This remittance screen displays the user name and icon image of "User B.B", who is the recipient of the remittance, and below that is a display of the scheduled remittance amount to display the entered remittance amount along with the balance. column is displayed. Here, "3000 yen" is input and displayed as the scheduled remittance amount. Further, a "next icon" indicating "next" for proceeding to the next screen is displayed at the bottom of the screen.

FIG. 6-13 is a diagram showing an example of a remittance execution screen that is displayed when the "next icon" is touched by the user of the terminal 20 on the remittance screen described above.
On this remittance execution screen, the scheduled remittance amount (here, "3000 yen") is displayed in association with the user name and icon image of "User B.B", who is the intended remittance recipient, and below that, the input remittance amount is displayed. A message display field for displaying a message to the scheduled party is displayed. Further, below that, candidates for attached images to be sent to the intended recipient along with the message are displayed. At the bottom of the screen, a "remittance execution icon" for executing remittance is displayed.

FIG. 6-14 is a diagram showing an example of an authentication screen that is displayed when the "remittance execution icon" is touched by the user of the terminal 20 on the remittance execution screen described above.
If it is not determined in the authentication skip determination process that the authentication process is to be skipped, this authentication screen is displayed.
On this authentication screen, the text "Password" (authentication password) and the message "Please enter the password you are currently using." are displayed, and below that, a password display that displays the password you entered is displayed. A field and a keyboard for entering a password are displayed.

FIG. 6-15 is a diagram showing an example of a remittance completion screen that is displayed when the authentication result is "OK" in the authentication process based on the password input on the above authentication screen.
On this remittance completion screen, you can see the text "Remittance completed" in the center of the screen, as well as the details under "Remittance history." ” message and a “confirmation icon” to check the remittance history are displayed in a pop-up format.

6-16 and 6-17 are screen diagrams for explaining the flow of remittance when authentication is skipped.
Figure 6-16 shows the same remittance execution screen as Figure 6-13, and Figure 6-17 shows the same remittance completion screen as Figure 6-15.

If the "remittance execution icon" is touched by the user of the terminal 20 on the remittance execution screen in Figure 6-16, and if it is determined to skip the authentication process in the authentication skip determination process, the remittance completion screen in Figure 6-17 The display changes to . In other words, the display switches from the remittance execution screen to the remittance completion screen without displaying the authentication screen shown in FIG. 6-14.

(2) Remittance when bill splitting request is received FIG. 6-18 is a diagram showing an example of a group talk room screen in the IMS application displayed on the display unit 24 of the terminal 20.
This group talk room screen is a screen for sending and receiving content between the terminals 20 of group users included in the group, and "IMS talk room" is displayed at the top of the screen, and below that, the group name (here "Group X") and the number of group members included in this group (here (4) indicating "4 people") are displayed.

This group talk room screen is a group talk room screen displayed on the terminal 20 of "user B.B" included in group X, for example, and on the left side of the screen, terminals of other group users included in the same group are displayed. 20 to its own terminal 20 is displayed, and on the right side of the screen, content such as messages sent from its own terminal 20 to the terminals 20 of other group users is displayed.

Here, the message "[IMS Pay] Mr. A.A requested 3000 yen to split the bill." sent from the terminal 20 of "User A.A" included in the same group, and the message "User A.A. Contents including an attached image sent from the terminal 20 of "" are displayed.

FIG. 6-19 is a diagram showing an example of a remittance screen that is displayed when content is touched by the user of the terminal 20 on the group talk room screen.
When the content transmitted from the terminal 20 of "User A.A" on the above group talk room screen is touched by "User B.B" of his own terminal 20, the payment application is started and the payment application is activated, as shown in Figure 6-19. A remittance screen like this will be displayed.
This remittance screen displays the amount requested for remittance (in this case, "3000 yen") by splitting the bill, and the image sent from the terminal 20 of "User A.A." Below that, " A ``remittance icon'' that says ``Send money'' is displayed.

FIG. 6-20 is a diagram showing an example of a remittance execution screen that is displayed when the "remittance icon" is touched by the user of the terminal 20 on the remittance screen described above.
This remittance execution screen includes the user name and icon image of "User A.A", who is the intended remittance recipient, and a scheduled remittance amount display field where the inputted scheduled remittance amount (here, "3000 yen") is displayed. , and the balance are displayed. Additionally, a "remittance execution icon" for executing remittance is displayed at the bottom of the screen.

FIG. 6-21 is a diagram showing an example of a remittance completion screen that is displayed when the "remittance execution icon" is touched by the user of the terminal 20 on the remittance execution screen.
If it is not determined to skip the authentication process in the authentication skip judgment process, if the "remittance execution icon" is touched on the remittance execution screen above, the display will switch from the remittance execution screen to the authentication screen in Figure 6-20. .
On the other hand, if it is determined to skip the authentication process in the authentication skip determination process, the display switches from the remittance execution screen in Figure 6-20 to the remittance completion screen in Figure 6-21 without displaying the authentication screen. .

On this remittance completion screen, you can see the text "Remittance completed" in the center of the screen, as well as the details under "Remittance history." ” message and a “confirmation icon” to check the remittance history are displayed in a pop-up format.

<Processing>
6-22 and 6-23 are flowcharts showing an example of the flow of processing executed by each device in this embodiment.
In these figures, from the left side, the fifth payment application process, which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20A of “user A.A”, and the remittance management processing unit 115 of the server 10 are executed. A first remittance management process to be executed and a fifth payment application process which is an example of a payment application process to be executed by the payment application processing unit 213 of the terminal 20B of "user B.B" are shown.
Note that steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

First, the payment application processing unit 213 of the terminal 20A receives a remittance operation for the input/output unit 23 (S1). Then, the payment application processing unit 213 of the terminal 20A determines the received operation type (S3).

If the operation type is "remittance operation" (S3; remittance), the payment application processing unit 213 of the terminal 20A performs remittance settings, which are settings related to remittance, in accordance with the user's operation on the input/output unit 23 (S5). Then, the authentication skip determination processing unit 2135 of the terminal 20A performs an eighth authentication skip determination process (S7). Note that in order to distinguish from the authentication skip determination process in the modification and other embodiments, this will be conveniently referred to as "eighth authentication skip determination process."

In this eighth authentication skip determination process, the authentication skip condition stored in the authentication skip condition data 2856 of the storage unit 28 is satisfied using the same method as the first authentication skip determination process described in the first embodiment. Determine whether or not.

Next, the authentication skip determination processing unit 2135 of the terminal 20A performs processes A11 to A17 based on the determination result of the eighth authentication skip determination process.

Thereafter, the remittance request processing unit 2138 of the terminal 20A sends a remittance request including the user ID of the user of its own terminal 20, the user ID of the intended remittance party (receiving party), and the scheduled remittance amount via the communication I/F 22. The information is transmitted to the server 10 (S19).

The remittance management processing unit 115 of the server 10 determines whether remittance request information has been received from the terminal 20A through the communication I/F 14 (T1), and if it is determined that the remittance request information has been received (T1; Yes), the remittance processing is performed. Do it (T3). Specifically, by way of example and not limitation, it is determined whether the scheduled remittance amount can be remitted based on the balance of the remittance source user stored in the remittance receipt management database 165 of the storage unit 15. do. If the remittance is possible, the scheduled remittance amount is subtracted from the balance and updated, the remittance history data is updated, and the remittance result is marked as "successful". Further, the balance of the user on the money receiving side is updated by adding the scheduled remittance amount, and the money receiving history data is updated. On the other hand, if remittance is not possible, the remittance result is set as "failure".

Next, the remittance management processing unit 115 determines the remittance result of the remittance processing (T5). Then, if the remittance result is "successful" (T5; success), the remittance source remittance result information transmission processing unit 1153 transmits remittance source remittance success information to the terminal 20A via the communication I/F 14 (T7 ). Further, the money depositing result information transmission processing unit 1155 for the depositing side transmits depositing success information for the depositing side to the terminal 20B via the communication I/F 14 (T9).

On the other hand, if the remittance result is "failed" (T5; failure), the remittance source remittance result information transmission processing unit 1153 transmits remittance source remittance failure information to the terminal 20A via the communication I/F 14 (T11). ). Further, the depositing result information transmission processing unit 1155 for the depositing side transmits deposit failure information for the depositing side to the terminal 20B via the communication I/F 14 (T13). The remittance management processing unit 115 then ends the first remittance management process.

When the payment application processing unit 213 of the terminal 20A receives the remittance result information for the remittance source from the server 10 through the communication I/F 22 (S21), the payment application processing unit 213 performs remittance according to the type (success/failure) of the received remittance result information for the remittance source. The result information is displayed on the display unit 24 (S23). Then, the payment application processing unit 213 of the terminal 20A ends the fifth payment application process.

The payment application processing unit 213 of the terminal 20B determines whether or not the payment result information for the payment side has been received from the server 10 via the communication I/F 22 (U1), and if it is determined that the payment result information has been received (U1; Yes ), the display section 24 displays money deposit result information according to the type (success/failure) of the received deposit result information for the deposit side (U3). Then, the payment application processing unit 213 of the terminal 20B ends the fifth payment application process.

On the other hand, if it is determined in S3 that the operation type is "remittance request" (S3; remittance request), the payment application processing unit 213 of terminal A sets the remittance request-related settings according to the user's operation on the input/output unit 23. The remittance request setting is performed (S25).

Thereafter, the payment application processing unit 213 of the terminal 20A sends remittance request information including the user ID of the user of its own terminal 20, the user ID of the remittance requesting party, and the remittance requested amount to the server 10 via the communication I/F 22. Send (S27).

The remittance management processing unit 115 determines whether remittance request information has been received from the terminal 20A through the communication I/F 14 (T15), and if it is determined that the remittance request information has been received (T15; Yes), the remittance request information is The remittance request information including the included remittance request amount is transmitted via the communication I/F 14 to the terminal 20 (terminal 20B in this case) associated with the user ID of the remittance requesting party included in the remittance request request information (T17).

The payment application processing unit 213 of the terminal 20B determines whether remittance request information has been received from the server 10 through the communication I/F 22 (U4), and if it is determined that the remittance request information has been received (U4; Yes), the input/output unit 23, remittance settings, which are settings related to remittance, are performed (U5). Then, the authentication skip determination processing unit 2135 of the terminal 20B performs an eighth authentication skip determination process (S7).

Thereafter, the payment application processing unit 213 of the terminal 20B performs processes A11 to A17. Then, the remittance request processing unit 2138 of the terminal 20B sends remittance request information including the user ID of the user of its own terminal 20, the user ID of the intended remittance partner, and the scheduled remittance amount to the server 10 via the communication I/F 22. Send (U19).

The remittance management processing unit 115 of the server 10 determines whether remittance request information has been received from the terminal 20B through the communication I/F 14 (T19), and if it is determined that the remittance request information has been received (T19; Yes), the remittance processing is performed. Do it (T21). Then, the remittance management processing unit 115 performs the processing from T5 to T13.

When the payment application processing unit 213 of the terminal 20B receives the remittance result information for the remittance source from the server 10 through the communication I/F 22 (U21), the payment application processing unit 213 performs remittance according to the type (success/failure) of the received remittance result information for the remittance source. The result information is displayed on the display unit 24 (U23). Then, the payment application processing unit 213 of the terminal 20B ends the fifth payment application process.

When the payment application processing unit 213 of the terminal 20A receives the payment result information for the payment side from the server 10 via the communication I/F 22 (S29), the payment application processing unit 213 of the terminal 20A receives the payment result information for the payment side (success/failure). The display unit 24 displays deposit result information corresponding to the deposit result information (S31). Then, the payment application processing unit 213 of the terminal 20A ends the fifth payment application process.

<Effects of the fourth embodiment>
The fourth embodiment performs an authentication process (an example, not a limitation, but an example of a display process) regarding execution of authentication for a user of the terminal 20 on the display unit 24 (an example, not a limitation, of a display area) of the terminal 20, and Based on user authentication, information regarding remittance of IMS money is transmitted through the communication I/F 22 of the terminal 20 and is owned by another user (not limited to, but an example of the first user) who is registered as a friend in the IMS application. A terminal 20 that remits IMS money to another terminal 20 (an example, but not a limitation, of a first terminal) obtains the information. Then, the terminal 20 performs an authentication skip determination based on the acquired information, and if the authentication skip conditions are met, the authentication process is not performed and remittance request information (not limited to, an example of information related to remittance of electronic money) A configuration is shown in which the information is transmitted by the communication I/F 22.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal can easily transmit information regarding remittance of electronic money without performing display processing related to execution of authentication for the user of the terminal. . Furthermore, since the terminal does not need to perform display processing based on the acquired information, the processing load on the terminal can be reduced. Furthermore, since it is not necessary to perform display processing every time when remitting electronic money, remittances can be performed quickly and smoothly, and convenience for the user can be improved.

Furthermore, the fourth embodiment shows a configuration in which the information acquired by the above-mentioned terminal includes information different from the authentication password (not limited to, but an example of authentication information).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires authentication information different from the authentication information for authenticating the terminal user, so that the terminal displays information regarding execution of authentication to the terminal user. Since no processing is required, the processing load on the terminal can be reduced.

Furthermore, the fourth embodiment shows a configuration in which the information different from the above authentication password includes information regarding IMS money (not limited to this, but an example of information regarding electronic money).
As an example of the effect obtained by such a configuration, when the terminal remits electronic money, by acquiring information regarding the electronic money, the terminal does not need to perform display processing related to the execution of authentication for the terminal user. Processing load can be reduced.

Further, in the fourth embodiment, the above information regarding IMS money is information regarding the amount of IMS money associated with the terminal 20 or the user of the terminal 20 (without limitation, information regarding the amount of IMS money associated with the terminal or the user of the terminal The figure shows a configuration including an example of information regarding the amount of electronic money.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the amount of electronic money, thereby eliminating the need for display processing related to execution of authentication for the user of the terminal. The processing load on the terminal can be reduced. Further, since the information regarding the amount of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform processing related to remittance based on information regarding the appropriate amount of electronic money.

In addition, in the fourth embodiment, the information regarding the amount of IMS money described above is provided by the user (not limited to, an example of the first user) of another terminal 20 (not limited to, an example of the first terminal) who is registered as a friend. ) (an example of, but not limited to, information regarding remittance to the first user of the first terminal).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the remittance to the first user of the first terminal, and thereby performs display processing regarding execution of authentication for the user of the terminal. This reduces the processing load on the terminal.

Furthermore, the fourth embodiment shows a configuration in which the above information regarding the scheduled remittance amount includes the remittance amount to another user of another terminal 20.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the remittance to the first user of the first terminal, and thereby performs display processing regarding execution of authentication for the user of the terminal. This reduces the processing load on the terminal. Also, for example, if the amount of remittance to the first user of the first terminal is low, the risk is considered to be low, so safety can be ensured by not displaying processing related to the execution of authentication for the terminal user. At the same time, user convenience can be improved.

Further, the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process until the daily upper limit set amount (not a limitation, but an example of a set remittance amount) is exceeded.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal does not display information regarding execution of authentication until the set remittance amount is exceeded, so the processing load on the terminal can be reduced. At the same time, user convenience can be improved. On the other hand, if the remittance amount exceeds the set remittance amount when remitting electronic money, a display regarding the execution of authentication may be displayed, thereby alerting the user that the remittance amount has exceeded the set remittance amount.

Further, in the fourth embodiment, the above information regarding the amount of IMS Money is information regarding the balance of IMS Money associated with the terminal 20 or the user of the terminal 20 (without limitation, information regarding the balance of IMS Money associated with the terminal or the user of the terminal). The figure shows a configuration including an example of information regarding the balance of electronic money.
As an example of the effect obtained by such a configuration, when the terminal remits electronic money, by acquiring information regarding the balance of electronic money, the terminal does not need to perform display processing related to execution of authentication for the user of the terminal, The processing load on the terminal can be reduced. Further, since the information regarding the balance of electronic money is associated with the terminal or the user of the terminal, the terminal can appropriately perform processing related to remittance based on the information regarding the appropriate balance of electronic money.

Furthermore, the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process when the balance of IMS money is less than or equal to the set amount.
As an example of the effect obtained by such a configuration, when remitting electronic money, if the balance of electronic money is less than or equal to the set amount, the terminal does not display information regarding execution of authentication. , the processing load on the terminal can be reduced. In addition, for example, if the balance of electronic money is small, large remittances cannot be made and the risk is considered to be low. Therefore, by not displaying information regarding the execution of authentication, it is possible to ensure safety and improve user convenience. can improve sex.

In addition, in the fourth embodiment, the terminal 20 automatically charges electronic money to the terminal when the electronic money becomes less than or equal to the set amount (not limited to the auto charge setting of the terminal 20). (Example of settings made in 2015) is set to "OFF", the configuration shows a configuration in which authentication processing is performed when the balance of IMS money is less than or equal to the set amount.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal can automatically deposit electronic money when the amount of electronic money on the terminal is less than or equal to the set amount. If the terminal is set to do so, electronic money will be automatically deposited into the terminal when the amount becomes small, making it possible to send large sums of money, which poses a risk. Therefore, by displaying information regarding the execution of authentication, it is possible to alert the user that a large amount of remittance is possible.

Further, in the fourth embodiment, the above-mentioned information regarding IMS money includes information regarding the frequency or number of times remittances are made using IMS money (without limitation, information regarding the frequency or number of times remittances are performed using electronic money). It shows.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the frequency or number of remittances using electronic money, and thereby performs display processing related to execution of authentication for the user of the terminal. This reduces the processing load on the terminal. Also, for example, if the frequency of remittances using electronic money is high or the number of times is large, there is a high possibility that the same user is remitting remittances using electronic money, and the risk is considered to be low, so display processing is not necessary. By not doing so, it is possible to improve user convenience while ensuring safety.

Further, in the fourth embodiment, the above-mentioned information regarding IMS money includes information regarding other terminals 20 or users of other terminals 20 to whom the terminal 20 or the user of the terminal 20 has remitted money using IMS money. It shows.
As an example of the effect obtained by such a configuration, when the terminal remits electronic money, the terminal acquires information about the terminal or the user of the terminal who has made the remittance using electronic money, Since there is no need to perform display processing related to the execution of authentication for the user of the terminal, the processing load on the terminal can be reduced. In addition, if the user of the terminal has sent money to another terminal or is a user of another terminal, the risk is considered to be low, so security can be ensured by not displaying the data. At the same time, user convenience can be improved.

Furthermore, the fourth embodiment shows a configuration in which the above-mentioned information regarding IMS money includes the last remittance date and time (not limited to this, but an example of information regarding the time when remittance was performed using electronic money).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the time when the remittance is made using electronic money, thereby eliminating the need for display processing related to execution of authentication for the terminal user. Therefore, the processing load on the terminal can be reduced.

Furthermore, the fourth embodiment shows a configuration in which the terminal 20 does not perform the authentication process if the set time has elapsed from the above-mentioned final remittance date and time.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal does not need to display information regarding the execution of authentication if it is within the set time from the time the electronic money was remitted. The processing load on the terminal can be reduced. Also, for example, if a long time has not passed since the electronic money transfer, there is a high possibility that the same user will transfer money again, and the risk is considered to be low, so there will be no display regarding the execution of authentication. This makes it possible to improve user convenience while ensuring safety.

Furthermore, the fourth embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information regarding a place where remittance is made using IMS money (an example of information regarding a place where remittance is performed using electronic money, but is not limited to this). There is.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information about the place where the electronic money was sent, thereby eliminating the need for display processing related to execution of authentication for the terminal user. Therefore, the processing load on the terminal can be reduced.

Furthermore, the fourth embodiment shows a configuration in which the terminal 20 does not perform authentication processing based on information regarding the place where the remittance was made using IMS money and information regarding the location of the terminal 20.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal performs display processing related to the execution of authentication based on information regarding the place where the electronic money was transferred and information regarding the location of the terminal. Since this is not performed, the processing load on the terminal can be reduced. In addition, for example, if the location of the terminal is not far from the location where the user sent electronic money in the past, there is a high possibility that the user is attempting to send money at the same location, and the risk is considered to be low. By not displaying the execution information, it is possible to improve user convenience while ensuring safety.

Furthermore, the fourth embodiment shows a configuration in which the above-mentioned information regarding IMS money includes information regarding a place where authentication processing for remittance of IMS money is performed.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the location where the authentication for remittance of electronic money was performed, thereby improving the authentication for the user of the terminal. Since there is no need to perform display processing related to execution, the processing load on the terminal can be reduced. Additionally, for example, if it is a place where authentication for remittance of electronic money was performed in the past, there is a high possibility that the authentication will be performed again for the same user, and the risk is considered to be low. By not performing display processing, it is possible to improve user convenience while ensuring safety.

Furthermore, the fourth embodiment shows a configuration in which the information different from the authentication password described above includes information regarding the location.
As an example of the effect obtained by such a configuration, when remittance of electronic money, the terminal acquires information regarding the location, thereby eliminating the need for display processing related to the execution of authentication for the terminal user. The load can be reduced.

Furthermore, the fourth embodiment shows a configuration in which the above-mentioned information regarding the location includes information regarding a safe remittance area (not limited to this, but is an example of information on a location with high security).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information on a location with high security, thereby eliminating the need for display processing related to execution of authentication for the terminal user. The processing load on the terminal can be reduced. Further, by not performing display processing related to the execution of authentication for the user of the terminal based on information on a location with high security, it is possible to improve convenience for the user while ensuring safety.

Furthermore, the fourth embodiment shows a configuration in which the information regarding the above-mentioned locations includes information about locations visited by the user of the terminal a set number of times or more.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information on places that the terminal user has visited more than a set number of times, and displays information regarding the execution of authentication for the terminal user. Since no processing is required, the processing load on the terminal can be reduced. In addition, by not displaying information related to the execution of authentication for the terminal user based on the information of the places the terminal user has visited more than a set number of times, it is possible to improve user convenience while ensuring safety. can be improved.

Further, in the fourth embodiment, the above-mentioned location information includes at least one of the home location of the user of the terminal 20, the location of the company where the user of the terminal 20 works, and the home of a person related to the user of the terminal 20. It shows a configuration that includes two pieces of information.
As an example of the effect obtained by such a configuration, when remittance of electronic money, the terminal is configured to check the location of the terminal user's home, the location of the company where the terminal user works, and the home location of the person related to the terminal user. By acquiring at least one of these pieces of information, display processing related to the execution of authentication for the user of the terminal is not necessary, so that the processing load on the terminal can be reduced. In addition, display processing related to the execution of authentication for the terminal user based on at least one of the following information: the location of the terminal user's home, the location of the company where the terminal user works, and the home of a person related to the terminal user. By avoiding this, it is possible to improve user convenience while ensuring safety.

Further, the fourth embodiment shows a configuration in which the above-mentioned location information includes location information of a store that supports payment applications (not limited to this, but is an example of information regarding the location of a store where payments can be made using electronic money).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the location of a store where payment can be made with electronic money, thereby requiring the terminal to perform display processing related to execution of authentication for the user of the terminal. This reduces the processing load on the terminal. In addition, for example, if the location of a store where payments can be made with electronic money is not far from the location of the terminal, it is assumed that the users of the terminal will exchange money with friends when making payments at the store, which can be dangerous. Since the security is considered to be low, by not displaying information regarding the execution of authentication for the user of the terminal, it is possible to improve convenience for the user while ensuring safety.

Furthermore, the fourth embodiment shows a configuration in which the information different from the authentication password includes information regarding the remittance partner (not limited to this, but an example of information regarding the first user of the first terminal).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information regarding the first user of the first terminal, thereby eliminating the need for display processing related to execution of authentication for the user of the terminal. Therefore, the processing load on the terminal can be reduced.

In addition, in the fourth embodiment, the above information regarding the remittance partner includes, for example, that the remittance partner is a close friend or relative, that the remittance partner has a history of remittances in the past, and that the remittance partner has a history of receiving money in the past. The configuration includes information on the terminal (not limited to this, but an example of information related to the relationship with the user of the terminal).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information related to the relationship with the terminal user, thereby eliminating the need for display processing related to execution of authentication for the terminal user. Therefore, the processing load on the terminal can be reduced. Also, for example, if the user is closely related to the terminal user, the risk is considered to be low, so security can be ensured by not displaying information related to the execution of authentication for the terminal user. At the same time, user convenience can be improved.

Further, in the fourth embodiment, the information regarding the remittance partner is information indicating that the terminal 20 of the user of the terminal 20 is included in a group that can send and receive content in the IMS application (not limited to the terminal This shows a configuration including an example of information indicating that the user's terminal is included in a group that can send and receive messages.
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information indicating that the terminal is included in a group that can send and receive messages with the terminal of the terminal user. Since there is no need to perform display processing related to the execution of authentication for the user, the processing load on the terminal can be reduced. Also, for example, if the first user is included in a group that can send and receive messages with the terminal user's terminal, the risk is considered to be low, so display processing related to the execution of authentication for the terminal user should not be performed. By doing so, user convenience can be improved while ensuring safety.

Furthermore, in the fourth embodiment, the group in the above IMS application is the user of the terminal 20 (an example of the first terminal, not a limitation) to which the user of the terminal 20 sends money (an example of the first user, not a limitation). indicates a configuration that includes another user (not limited to, a second user) of another terminal 20 (not limited to, but an example of a second terminal), and is capable of transmitting and receiving content to and from this other user's terminal 20. ing.
As an example of the effect obtained by such a configuration, the terminal can send and receive messages to and from the second terminal of the second user included in the group.

Further, in the fourth embodiment, information different from the authentication password described above is information related to the terminal 20 or the settings of the payment application stored in the terminal 20 (not limited to the settings of the terminal or the application stored in the terminal). (Example of information regarding).
As an example of the effect obtained by such a configuration, when remitting electronic money, the terminal acquires information about the settings of the terminal or the application stored on the terminal, and thereby performs display processing related to the execution of authentication for the user of the terminal. This reduces the processing load on the terminal. Further, for example, if the information regarding the settings of the terminal or the application stored in the terminal is information set by the user, the user's intention can be respected and the user's convenience can be improved.

Further, in the fourth embodiment, information different from the above authentication password is information set on the terminal 20 indicating whether or not the terminal 20 is locked (not limited to, information set on the terminal, (Example of information regarding security) is shown.
As an example of the effect obtained by such a configuration, when remittance of electronic money, the terminal acquires information regarding the security of the terminal set on the terminal, and thereby prevents display processing related to execution of authentication for the terminal user. This reduces the processing load on the terminal. Further, for example, if the information related to the security of the terminal is information related to authentication of the user of the terminal, convenience for the user can be improved by omitting display processing related to execution of authentication for the user of the terminal.

Further, the fourth embodiment shows a configuration in which the terminal 20 receives information regarding remittance of IMS money to another user's terminal 20 (not limited to, an example of the first terminal) through the communication I/F 22. .
As an example of the effect obtained by such a configuration, the terminal can receive and acquire information regarding remittance of electronic money to the first terminal through the communication unit.

Further, the fourth embodiment shows a configuration in which the terminals include a plurality of terminals 20 that have received bill splitting requests at the same time, and when authentication is completed on more than a set number of terminals 20, the authentication process is skipped.
As an example of the effect obtained by such a configuration, information sent from a server that manages electronic money remittances is transmitted based on the authentication of the user of the second terminal that has received the information regarding the electronic money remittance to the first terminal. Sent. Therefore, the terminal can acquire information sent from the server that manages electronic money remittance based on the fact that the user of the second terminal has been authenticated.

<Fourth modification (1)>
In the fourth embodiment, the terminal 20 executes the authentication skip determination as to whether or not to skip the authentication process for remittance, but the present invention is not limited to this. In the second embodiment, a configuration was shown in which the server 10 executes the authentication skip determination as to whether or not the terminal 20 should skip the authentication process for payment. It is also possible to have the server 10 execute the authentication skip determination as to whether or not to skip the authentication.

FIG. 6-24 is a diagram showing an example of the data structure of the authentication skip condition data 166 stored in the storage unit 15 of the server 10 in this modification. This authentication skip condition data 166 is data in which authentication skip conditions, which are conditions for causing the terminal 20 to skip the authentication process for remittance, are defined. This data structure is similar to the authentication skip condition data 2856 of the terminal 20, but the contents are partially different. The following description focuses on different conditions.

<Condition Category No. “SP15-2”>
The authentication skip condition of condition number "SP15-2" included in condition category number "SP15 (security)" is defined as "the trust score of the terminal user is 80 points or higher." This allows the authentication process of the terminal 20 to be skipped when the credit score of the user of the terminal 20 stored in the credit score data 158 is 80 points or higher, that is, when the trust of the user of the terminal 20 has reached a certain level. It means that.

In this determination, the terminal 20 acquires the credit score of the user of the terminal 20 who is scheduled to remit money from among the credit scores stored in the credit score data 158. Then, it is determined whether the acquired credit score is 80 points or more.

Other conditions are similar to the authentication skip condition data 2856 of the terminal 20, but in this modification, unlike the fourth embodiment, the server 10 performs authentication skip determination processing for remittance. Therefore, the server 10 stores user information stored in the user registration data 153 of the storage unit 15, store information stored in the store registration data 155, IMS user management data stored in the IMS user management database 161, IMS Server management information such as IMS group management data stored in the group management database 163 and remittance management data stored in the remittance management database 165 is obtained. Further, the server 10 requests the terminal 20 to obtain information that is not managed by the server 10, such as location information of the terminal 20 (terminal location information). The server 10 then performs an authentication skip determination based on the acquired information.

FIG. 6-25 is a flowchart showing an example of the flow of processing executed by each device in this modification.
In this figure, from the left, the sixth payment application process, which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20A, and the second remittance management process executed by the remittance management unit 115 of the server 10. , a sixth payment application process which is an example of the payment application process executed by the payment application processing unit 213 of the terminal 20B, and the portion corresponding to FIG. 6-22 is extracted.
Note that steps that are the same as those in the flowcharts that have already been provided are given the same reference numerals, and repeated explanations will be omitted.

After the payment application processing unit 213 of the terminal 20A performs remittance settings in S5, it transmits remittance request information to the server 10 via the communication I/F 22 (S19).

If the remittance management processing unit 115 of the server 10 determines that remittance request information has been received from the terminal 20A through the communication I/F 14 (T1; Yes), it performs a ninth authentication skip determination process (W1). Note that, in order to distinguish from the authentication skip determination process in other embodiments, this will be referred to as a "ninth authentication skip determination process" for convenience.

Specifically, in the same manner as in the fourth embodiment, the success or failure of the authentication skip condition included in the authentication skip condition data (not shown) stored in the storage unit 15 is determined by various server management methods obtained from the storage unit 15. The determination is made based on the information and the information requested and obtained from the terminal 20.

After performing the ninth authentication skip determination process, the remittance management processing unit 115 determines whether or not it has been determined to skip the authentication process (W3). If it is determined that the authentication process is to be skipped (W3; Yes), the remittance management processing unit 115 moves the process to T3.

On the other hand, if it is determined not to skip the authentication process (W1: No), the remittance management processing unit 115 transmits additional authentication request information to the terminal 20 via the communication I/F 14 (W5).

The payment application processing unit 213 of the terminal 20A determines whether or not additional authentication request information has been received from the server 10 via the communication I/F 22 (V1), and if it is determined that the additional authentication request information has not been received (V1; No), S21 Transfer processing to. In this case, the authentication process at the terminal 20 is skipped.

On the other hand, if it is determined that additional authentication request information has been received from the server 10 through the communication I/F 22 (V1; Yes), the payment application processing unit 213 executes the processes A13 to A17. In this case, the authentication process is executed at the terminal 20.

If the authentication result is "OK" in the authentication process (A15; Yes), the payment application processing unit 213 transmits authentication success information to the server 10 via the communication I/F 22 (V3).

When the remittance management processing unit 115 receives the authentication success information from the terminal 20 via the communication I/F 14 (W7), it executes the process of T3. That is, after receiving information indicating that the authentication was successful from the terminal 20, the remittance process is performed (T3). Then, the remittance management processing unit 115 moves the process to T5.

<Effects of fourth modification (1)>
In this modification, the server 10 receives, through the communication I/F 14, remittance request information regarding IMS money remittance by the terminal 20 (not limited to, an example of first information regarding electronic money remittance), and additional authentication request information ( An example, but not limited to, information regarding authentication of a user of the terminal) is transmitted to the terminal 20 via the communication I/F 14. Further, the server 10 receives authentication success information (not limited to this, but an example of information indicating that the user of the terminal has been authenticated) through the communication I/F 14. Then, based on the authentication success information, the server 10 transmits remittance result information for the remittance source (an example of remittance information indicating that a remittance using electronic money has been made, but is not limited to this) to the terminal 20 via the communication I/F 14. Based on the authentication success information and the remittance request information, the remittance recipient's terminal 20 (not limited to, but an example of second information regarding remittance of electronic money) for the remittance side is sent to the remittance party's terminal 20 (not limited to, (an example of a terminal different from the terminal) via the communication I/F 14. At this time, the server 10 transmits additional authentication request information to the terminal 20 via the communication I/F 14 based on the acquisition of information different from the authentication password (an example of authentication information for authenticating the user, not limited to this). First, a configuration is shown in which remittance result information for the remittance source is transmitted to the terminal 20 via the communication I/F 14.
As an example of the effect obtained by such a configuration, when remittance of electronic money, the server acquires information different from the authentication information for authenticating the terminal user. Since the data is not sent to the server, the processing load on the server can be reduced. Further, remittance information can be sent to the terminal without sending information related to authentication of the user of the terminal to the terminal.

<Fourth modification (2)>
In the above, the server 10 may or may not change the authentication skip condition based on the trust score of the user of the terminal 20.

Specifically, by way of example and not limitation, the server 10 increases the "setting time" in the authentication skip condition of the condition No. "SP11-1" of the authentication skip condition data 166 as the credit score of the user of the terminal 20 increases. You may or may not do so.

More specifically, by way of example and not limitation, the set time when the credit score is 0 points is set as "2 hours". Further, a threshold value that is an integral multiple of 10 points (10 points, 20 points, . . . , 100 points) is set as a credit score threshold. Then, each time the credit score of the user of the terminal 20 reaches a threshold, the set time can be set longer by one hour.

Further, as an example and not a limitation, the server 10 increases the "daily upper limit set amount" in the authentication skip condition of condition No. "SP13-1" of the authentication skip condition data 166 as the credit score of the user of the terminal 20 increases. You may or may not do so. More specifically, as an example and not a limitation, the daily upper limit set amount when the credit score is 0 points is set as "0 yen". Further, a threshold value that is an integral multiple of 10 points (10 points, 20 points, . . . , 100 points) is set as a credit score threshold. Then, each time the credit score of the user of the terminal 20 reaches a threshold, the daily upper limit setting amount can be set higher by 5000 yen.

<Effects of fourth modification (2)>
As an example of the effect obtained by this modification, the server can change the authentication skip condition based on the trustworthiness of the user of the terminal. For example, user convenience can be improved by changing the authentication skip condition so that the higher the trustworthiness of the user of the terminal, the more likely it is that the authentication process will be skipped.

<Fourth modification (3)>
In the fourth embodiment, information regarding remittances sent from the server 10 is stored in the storage unit 28 of the terminal 20 as remittance history data, and the terminal 20 determines whether to skip authentication based on the information regarding remittances included in this remittance history data. However, it is not limited to this.

Specifically, remittance history data may not be stored in the storage unit 28 of the terminal 20. In this case, the terminal 20 may or may not request information necessary for the authentication skip determination from the server 10 and perform the authentication skip determination based on the information acquired from the server 10.

<Effects of fourth modification (3)>
As an example of the effect obtained by this modification, since there is no need to store information regarding the history of remittances using electronic money in the terminal, the storage capacity of the terminal can be saved.

<Fourth modification (4)>
In the fourth embodiment, the daily upper limit setting amount is set as a threshold value for the total amount of remitted amounts (remitted amounts) in that one day, but the amount is not limited to this. Specifically, as an example and not a limitation, the daily maximum amount is the sum of the total amount of money that has been remitted in that day (remittance amount) and the amount that you are about to remit (scheduled remittance amount). The upper limit amount may or may not be set as the threshold amount.

Furthermore, the upper limit setting amount does not necessarily have to be the upper limit setting amount for one day, but may be the upper limit setting amount for a predetermined period in the past (the past week, the past two weeks, the past month, etc.). You don't have to.

In addition, the upper limit set amount is the amount set for the amount you are about to remit (scheduled remittance amount), that is, the amount to be remitted at one time, and the authentication skip that "the scheduled remittance amount is less than or equal to the set amount (or less than the set amount)" It is also possible to perform authentication skip determination based on conditions. By doing so, the authentication process can be skipped when the user of the terminal 20 remits a small amount.

<Effects of fourth modification (4)>
As an example of the effect obtained by this modification, whether or not to display information regarding the execution of authentication takes into account not only the amount remitted in the past (remittance amount) but also the amount to be remitted in the future (scheduled remittance amount). can be determined.

Furthermore, user convenience can be improved by not displaying information regarding execution of authentication until the amount of one remittance exceeds a set amount.

<Fourth modification (5)>
The various authentication skip conditions described in the fourth embodiment are merely examples, and can be added, deleted, or changed as appropriate.

Specifically, by way of example and not limitation, the authentication skip condition that "the current date and time is within a set time from the last remittance date and time" may be changed to "the current date and time is within a set time from the last authentication date and time."
In addition, the "final authentication date and time" in this case is not necessarily limited to the date and time when the authentication for remittance was last performed, and is not limited to, but is for example, The date and time when the last authentication was performed, the last time when the authentication to unlock the OS side of the terminal 20 was performed, the last time when the authentication to unlock the payment application side was performed. The date and time when a type of authentication other than remittance authentication was last performed can also be set as the "last authentication date and time" in the above authentication skip condition.

<Effects of fourth modification (5)>
As an example of the effect obtained by this modification, when remittance of electronic money, the terminal not only applies when the remittance authentication is within the set time from the last time the remittance authentication was performed, but also when the remittance authentication is Even if the set time has elapsed since the last time a different type of authentication was performed, the display regarding the execution of authentication is not displayed, so that user convenience can be further improved.

1 communication system 10 server 20 terminal 30 network 40 store POS system 50 store code reader device 60 code register 70 store server

Claims (13)

A program executed by a terminal that performs processing related to payments using electronic money,
acquiring, by a control unit of the terminal, first information regarding a location that is different from authentication information for authenticating a user of the terminal;
The control unit may perform display processing regarding execution of the authentication for the user of the terminal based on the first information and the acquisition of code information for making a payment using electronic money, or the reading of the code information. is executed by said terminal,
When the first information includes information regarding a set location, the display process may include displaying the electronic currency by the terminal between the time the payment is made at the set location and the set time elapses. When the payment is made, the processing includes a process of displaying information regarding the execution of the authentication. The program according to claim 1,
The set time can be changed. The program according to claim 1 or claim 2,
The set location is a second location,
When the first information includes information regarding a first location different from the second location, the control unit may control not to perform the display process regarding execution of the authentication for the user of the terminal. Executed by the terminal. 4. The program according to claim 3,
The first location includes a location that is frequently used by the user of the terminal. The program according to claim 3 or 4,
The first location includes a location near the home of the user of the terminal. The program according to any one of claims 1 to 5,
The information regarding the location includes information regarding the location where the product is purchased. 7. The program according to claim 6,
The information regarding the place where the product is purchased includes information regarding the store that sells the product. 4. The program according to claim 3,
When the first information includes information regarding the first location, the code information for making the payment using electronic money is displayed on the terminal without performing the display processing related to the execution of the authentication for the user of the terminal. be displayed in the section;
Based on the reading of the code information by the code reader, the terminal receives second information regarding the electronic money payment by the communication unit of the terminal. The program according to any one of claims 1 to 8,
Displaying on a display unit of the terminal a display related to reading the code information is executed by the terminal;
The first information is acquired by the control unit based on reading the code information. The program according to any one of claims 1 to 9,
The set location is set by a server that sends the code information to the terminal. The program according to any one of claims 1 to 10,
When the first information includes information regarding a set location, the display process may include displaying the electronic currency by the terminal between the time the payment is made at the set location and the set time elapses. The method includes a process of displaying information regarding the execution of the authentication when the payment is made, and a process of not displaying the information regarding the execution of the authentication when the set time has elapsed. An information processing method for a terminal that performs processing related to payment using electronic money, the method comprising:
acquiring, by a control unit of the terminal, first information regarding a location that is different from authentication information for authenticating a user of the terminal;
The control unit may perform display processing regarding execution of the authentication for the user of the terminal based on the first information and the acquisition of code information for making a payment using electronic money, or the reading of the code information. including
When the first information includes information regarding a set location, the display process may include displaying the electronic currency by the terminal between the time the payment is made at the set location and the set time elapses. When the payment is made, the processing includes a process of displaying information regarding the execution of the authentication. A terminal that processes payments using electronic money,
Obtaining first information regarding a location that is different from authentication information for authenticating the user of the terminal, and obtaining the first information and code information for making a payment using the electronic money, or reading the code information. a control unit that performs display processing regarding execution of the authentication for the user of the terminal based on the above,
When the first information includes information regarding a set location, the display process may include displaying the electronic currency by the terminal between the time the payment is made at the set location and the set time elapses. When the payment is made, the processing includes a process of displaying information regarding the execution of the authentication.

Images