KR102891264B1 - Information processing method, program, terminal - Google Patents

Abstract

A method for processing information of a terminal for executing payment processing based on first information for performing payment by code image includes receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal by a control unit of the terminal, and displaying a first code image based on the first information and visual information in a display area of the terminal, wherein the visual information includes visual information based on display of the first code image in the display area, and wherein payment is executed by the server based on the first information and visual information received by the server based on display of the first code image.

Description

Information processing method, program, terminal

The present invention relates to an information processing method, program, and terminal.

Recently, services that enable management of electronic money (e-money) for terminals or users, as well as payments using e-money, are becoming widespread, using applications that can be run on devices such as smartphones. For example, Patent Document 1 discloses a technology for paying for purchases of goods. However, e-money payments can be inconvenient, for example, due to the terminal's communication environment or conditions.

Patent Document 1: Japanese Patent Application Laid-Open No. 2002-176671

According to a first aspect of the present invention, an information processing method of a terminal for executing processing related to payment based on first information for performing payment by code image includes receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal by a control unit of the terminal, and displaying a first code image based on the first information and time information in a display area of the terminal, wherein the time information includes time information based on display of the first code image in the display area, and payment is executed by the server based on the first information and time information received by the server based on display of the first code image.

According to a second aspect of the present invention, a program executed by a computer of a terminal for executing processing related to payment based on first information for performing payment by code image includes receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal, and displaying a first code image based on the first information and time information in a display area of the terminal, wherein the time information includes time information based on display of the first code image in the display area, and payment is executed by the server based on the first information and time information received by the server based on display of the first code image.

According to a third aspect of the present invention, a terminal for executing processing related to payment based on first information for performing payment by code image comprises a communication unit for receiving first information transmitted from a server, a control unit for controlling storing the received first information in a storage unit of the terminal, and a display unit for displaying a first code image based on the first information and time information, wherein the time information includes time information based on display of the first code image on the display unit, and payment is executed by the server based on the first information and time information received by the server based on display of the first code image.

According to a fourth aspect of the present invention, a terminal for executing processing related to payment based on first information for performing payment by code image comprises a processor for reading a program from a memory storing the program and executing processing based on the program, wherein the processor executes the steps of receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal, and displaying a first code image based on the first information and time information in a display area of the terminal, wherein the time information includes time information based on display of the first code image in the display area, and the payment is executed by the server based on the first information and time information received by the server based on display of the first code image.

According to a fifth aspect of the present invention, an information processing method of a server for executing payment of a terminal that performs processing related to payment based on first information for performing payment by a code image includes transmitting the first information to the terminal through a communication unit of the server, and receiving, through the communication unit, first information and time information based on the first code image transmitted from the code reading device based on the first information and time information displayed in the display area of the terminal and read by the code reading device, and performing payment based on the first information and time information and time information based on reading of the first code image by the code reading device, wherein the time information includes time information based on display of the first code image in the display area.

According to a sixth aspect of the present invention, an information processing method of a terminal for executing processing related to payment based on first information for performing payment by code image includes receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal by a control unit of the terminal, and displaying a second code image based on the first information and second information different from the first information in a display area of the terminal, and the payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image.

According to a seventh aspect of the present invention, a program executed by a computer of a terminal for executing processing related to payment based on first information for performing payment by code image includes receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal, and displaying a first code image based on the first information and second information different from the first information in a display area of the terminal, wherein payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image.

According to an eighth aspect of the present invention, a terminal for executing processing related to payment based on first information for performing payment by code image comprises a communication unit for receiving first information transmitted from a server, a control unit for controlling storing the received first information in a storage unit of the terminal, and a display unit for displaying a first code image based on the first information and second information different from the first information, and payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image.

According to a ninth aspect of the present invention, a terminal for executing processing related to payment based on first information for performing payment by code image comprises a processor for reading a program from a memory in which the program is stored and executing processing based on the program, wherein the processor executes the steps of receiving first information transmitted from a server through a communication unit of the terminal, storing the received first information in a storage unit of the terminal, and displaying a first code image based on the first information and second information different from the first information in a display area of the terminal, and the payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image.

According to a tenth aspect of the present invention, an information processing method of a server for executing payment of a terminal that performs processing related to payment based on first information for performing payment by a code image includes transmitting the first information to the terminal through a communication unit of the server, receiving, through the communication unit, first information and second information based on the first code image transmitted from the code reading device based on the first information displayed in the display area of the terminal and second information different from the first information, and performing payment based on the first information and the second information and third information stored in the storage unit of the server and associated with the first information.

[Figure 1] A drawing showing an example of the configuration of a communication system in one embodiment.
[Figure 2] A drawing showing an example of a system configuration of a store POS system in one embodiment.
[Figure 3a] A flowchart showing an example of a processing flow executed by various devices in one aspect of the embodiment.
[Fig. 3b] A drawing showing an example of a terminal display screen in one embodiment.
[Fig. 3c] A drawing showing an example of a terminal display screen in one embodiment.
[Fig. 3d] A flowchart showing an example of a processing flow executed by various devices in one aspect of the embodiment.
[Figure 4a] A drawing showing an example of a function realized by the control unit of the server according to the first embodiment.
[Figure 4b] A drawing showing an example of information stored in a storage unit of a server according to the first embodiment.
[Figure 4c] A diagram showing an example of user registration data according to the first embodiment.
[Fig. 4d] A diagram showing an example of store registration data according to the first embodiment.
[Figure 4e] A diagram showing an example of a payment management database according to the first embodiment.
[Fig. 4f] A drawing showing an example of a function realized by the control unit of the terminal according to the first embodiment.
[Fig. 4g] A drawing showing an example of information stored in a storage unit of a terminal according to the first embodiment.
[Fig. 4h] A drawing showing an example of payment data according to the first embodiment.
[Fig. 4i] A drawing showing an example of a display screen of a terminal according to the first embodiment.
[Fig. 4j] A drawing showing an example of a display screen of a terminal according to the first embodiment.
[Fig. 4k] A drawing showing an example of a display screen of a terminal according to the first embodiment.
[Fig. 4l] A flowchart showing an example of a processing flow executed by various devices according to the first embodiment.
[Fig. 4m] A drawing showing an example of a terminal display screen according to the first modified example.
[Fig. 4n] A drawing showing an example of a display screen of a terminal according to the first modified example.
[Fig. 4o] A drawing showing an example of a terminal display screen according to the first modified example.
[Figure 5a] A drawing showing an example of information stored in a storage unit of a terminal according to the second embodiment.
[Figure 5b] A flowchart showing an example of a processing flow executed by various devices according to the second embodiment.
[Fig. 5c] A drawing showing an example of a function realized by a control unit of a terminal according to a second modified example.
[Fig. 5d] A drawing showing an example of information stored in a storage unit of a terminal according to a second modified example.
[Figure 6a] A drawing showing an example of a display screen of a terminal according to the third embodiment.
[Fig. 6b] A drawing showing an example of a display screen of a terminal according to the third embodiment.
[Figure 6c] A flowchart showing an example of a processing flow executed by various devices according to the third embodiment.
[Fig. 6d] A drawing showing an example of a terminal display screen according to the third modified example.
[Figure 7a] A drawing showing an example of information stored in a storage unit of a terminal according to the fourth embodiment.
[Figure 7b] A diagram showing an example of code supplementary condition data for the fourth embodiment.
[Fig. 8a] A drawing showing an example of information stored in a storage unit of a terminal according to the fifth embodiment.
[Fig. 8b] A drawing showing an example of display mode setting data according to the fifth embodiment.
[Fig. 8c] A drawing showing an example of display mode setting data according to the fifth embodiment.
[Fig. 8d] A drawing showing an example of a display screen of a terminal according to the fifth embodiment.
[Figure 8e] A drawing showing an example of a display screen of a terminal according to the fifth embodiment.
[Fig. 8f] A drawing showing an example of a display screen of a terminal according to the fifth embodiment.
[Fig. 8g] A drawing showing an example of a display screen of a terminal according to the fifth embodiment.
[Figure 9a] A diagram showing an example of store registration data according to the sixth embodiment.
[Fig. 9b] A drawing showing an example of a function realized by the control unit of the terminal according to the sixth embodiment.
[Fig. 9c] A drawing showing an example of information stored in a storage unit of a terminal according to the sixth embodiment.
[Fig. 9d] A drawing showing an example of payment data according to the sixth embodiment.
[Figure 9e] A diagram showing an example of authentication skip condition data according to the sixth embodiment.
[Fig. 9f] A flowchart showing an example of a processing flow executed by various devices according to the sixth embodiment.
[Figure 9g] A diagram showing an example of authentication skip condition data for the sixth modified example.
[Figure 10] A flowchart showing an example of a processing flow executed by various devices according to the seventh embodiment.
[Figure 11a] A diagram showing an example of a payment management database according to the 8th embodiment.
[Fig. 11b] A diagram showing an example of code management data according to the 8th embodiment.

Compliance with Legal Matters

Please note that the disclosures described in this specification are subject to compliance with the legal requirements of the country of implementation necessary for the implementation of the present invention, such as confidentiality of communications.

An embodiment for implementing an information processing method and the like according to the present invention is described with reference to the drawings.

[System Configuration]

Fig. 1 is a drawing showing an example of the configuration of a communication system (1) according to one embodiment of the present invention.

As disclosed in Fig. 1, the communication system (1) is connected to a server (10), a terminal (20) (terminal (20A), terminal (20B), terminal (20C), …) and a store POS system (40) via a network (30).

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

The network (30) serves to connect one or more terminals (20), one or more servers (10), and one or more store POS systems (40). In other words, the network (30) refers to a communication network that provides a connection path so that data can be transmitted and received after the various devices described above are connected.

One or more portions of the network (30) may be a wired network or a wireless network, or may not be. The 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 (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular network, integrated service digital networks (ISDN), a wireless LAN, long term evolution (LTE), code division multiple access (CDMA), Bluetooth (registered trademark), satellite communications, or a combination of two or more thereof. The network (30) may include one or more networks (30).

The terminal (20) (terminal (20A), terminal (20B), terminal (20C), …) (not limited to, an example of a terminal or an information processing device) may be any terminal that is an information processing terminal capable of realizing the functions described in each embodiment. The terminal (20) includes, but is not limited to, a smartphone, a mobile phone (feature phone), a computer (not limited to, a desktop, a laptop, a tablet, etc.), a media computer platform (not limited to, a cable, satellite set set-top box, a digital video recorder), a portable computer device (not limited to, a PDA (personal digital assistant), an e-mail client, etc.), a wearable terminal (glasses-type device, watch-type device, etc.), or another type of computer, or a communication platform. In addition, the terminal (20) may also be expressed as an information processing terminal.

Since the configurations of the terminal (20A), the terminal (20B), and the terminal (20C) are basically the same, the following description will focus on the terminal (20). In addition, if necessary, the terminal used by the user X is expressed as the terminal (20X), and the user information in a given service corresponding to the user X or the terminal (20X) is expressed as the user information X. In addition, the user information is the user information corresponding to the account used by the user in the given service. The user information includes, as an example and not a limitation, information corresponding to the user, such as the user's name, the user's icon image, the user's age, the user's gender, the user's address, the user's hobbies, and the user's identifier, which are input by the user or provided by the given service, and may be any one of these or a combination thereof, or may not be the same.

A server (10) (not limited to, an example of a server, an information processing device, or an information management device) has a function of providing a predetermined service to a terminal (20). The server (10) may be any information processing device capable of implementing the functions described in each embodiment. The server (10) includes, by way of non-limiting examples, a server device, a computer (not limited to, a desktop, a laptop, a tablet, etc.), a media computer platform (not limited to, a cable or satellite set-top box, a digital video recorder), a portable computer device (not limited to, a PDA, an e-mail client, etc.), or another type of computer or communication platform. In addition, the server (10) may also be expressed as an information processing device. In cases where 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 each be expressed as an information processing device.

In the embodiment described below, the server (10) is described as having a function of providing a payment service by a payment application.

The store POS system (40) is a POS system introduced and used in a store that is affiliated with a business operator that operates a server (10).

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) is described.

(1) Terminal HW configuration

Figure 1 shows an example of the HW configuration of a terminal (20).

The terminal (20) is equipped with 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), a clock unit (29A), and a position calculation information detection unit (29B). Each component of the HW of the terminal (20) is connected to each other via a bus (B), as an example and not a limitation. In addition, the HW configuration of the terminal (20) does not need to include all components. As an example and not a limitation, the terminal (20) may have a configuration that excludes individual components or multiple components, such as a microphone (25) and a camera (27), or it may not have to be configured that way.

The communication I/F (22) transmits and receives various data via the network (30). The communication may be performed by either wired or wireless means, and any communication protocol may be used as long as communication can be performed between the two. The communication I/F (22) has a function of communicating with various devices such as a 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). In addition, the communication I/F (22) receives various data transmitted from various devices such as the server (10) and transmits the data to the control unit (21). In addition, the communication I/F (22) may be simply expressed as a communication unit. In addition, when the communication I/F (22) is configured as 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 in the terminal (20). The input/output unit (23) may be integrated into the input/output unit, may be separated into the input/output unit and the output unit, or may not be integrated into the input/output unit and the output unit.

The input unit is realized by any one or a combination of all types of devices capable of receiving input from a user and transmitting information about the input to the control unit (21). The input unit includes, but is not limited to, hardware keys such as a touch panel, a touch display, a keyboard, a pointing device such as a mouse, a camera (for operation input via video), and a microphone (for operation input via voice).

The output unit is realized by any one or a combination of all types of devices capable of outputting the processing results processed in the control unit (21). The output unit includes, but is not limited to, a touch panel, a touch display, a speaker (voice output), a lens (but is not limited to, a 3D (three dimensions) output or hologram output), a printer, etc., as examples.

The display unit (24) is realized by any one or a combination of all types of devices capable of displaying according to display data written in the frame buffer. The display unit (24) includes, as non-limiting examples, a touch panel, a touch display, a monitor (as non-limiting examples, a liquid crystal display or an organic electroluminescence display (OELD)), a head-mounted display (HMD), projection mapping, a hologram, a device capable of displaying images or text information in the air (which may or may not be a vacuum). In addition, the display unit (24) may or may not be capable of displaying display data in 3D.

If the input/output unit (23) is a touch panel, the input/output unit (23) and the display unit (24) may be arranged facing each other with approximately the same size and shape.

The clock unit (29A) is a built-in clock of the terminal (20) and outputs time information (timekeeping information). The clock unit (29A) is composed of, but is not limited to, a clock using a crystal oscillator. The clock unit (29A) may also be expressed as, but is not limited to, a timekeeping unit or a time information detection unit.

In addition, the clock part (29A) may or may not be equipped with a clock that applies the NITZ (Network Identity and Time Zone) standard.

The location calculation information detection unit (29B) is a functional unit that detects (measures) information (hereinafter referred to as “location calculation information”) necessary for the control unit (21) to calculate (measure) the location of its own terminal (20). The location calculation information detection unit (29B) may also be expressed as a location calculation sensor unit, as an example and not a limitation.

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

The satellite positioning unit includes, as an example and not a limitation, an RF receiver circuit that converts an RF (Radio Frequency) signal including a positioning satellite signal transmitted from a positioning satellite received from an antenna not shown into a digital signal, or a baseband processing circuit that performs correlation processing or the like on a digital signal output from the RF receiver circuit to capture a positioning satellite signal and outputs information such as satellite orbit data or time data extracted from the positioning satellite signal as position calculation information.

The inertial measurement device includes an inertial sensor, which is a sensor that detects information necessary to calculate the position of a terminal (20) through inertial navigation operations. The inertial sensor includes, but is not limited to, a three-axis acceleration sensor or a three-axis gyro sensor, and outputs acceleration detected by the acceleration sensor and angular velocity detected by the gyro sensor as information for calculating the position.

The control unit (21) comprises a physically structured circuit to execute functions realized by code or commands included in the program, and is realized by a data processing device built into the hardware, as an example and not a limitation. Therefore, the control unit (21) may or may not be expressed as a control circuit.

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

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

The terminal (20) stores a program (P) in the storage unit (28), and by executing this program (P), the control unit (21) executes processing as a part included in the control unit (21). That is, the program (P) stored in the storage unit (28) causes the terminal (20) to realize the function executed by the control unit (21). In addition, this program (P) may or may not be expressed as a program module.

A microphone (25) is used to input voice data. A speaker (26) is used to output voice data. A camera (27) is used to acquire video data.

(2) Server HW configuration

Figure 1 shows an example of the HW configuration of a server (10).

The server (10) is equipped with a control unit (11) (CPU), a storage unit (15), a communication I/F (14) (interface), an input/output unit (12), a display (13), and a clock unit (19). Each component of the HW of the server (10) is interconnected via a bus (B), as an example and not a limitation. In addition, the HW of the server (10) does not necessarily include all components as a HW configuration of the server (10). As an example and not a limitation, the HW of the server (10) may or may not have a configuration excluding the display (13).

The control unit (11) has a physically structured circuit to execute a function realized by a code or command included in a program, and is realized by a data processing device built into hardware, as an example and not a limitation.

The control unit (11) is typically a central processing unit (CPU), but may also be a microprocessor, processor core, multiprocessor, ASIC FPGA, or other such devices. In the present invention, the control unit (11) is not limited to these.

The storage unit (15) has the function of storing various programs and data required 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 invention, the storage unit (15) is not limited to these. Furthermore, the storage unit (15) may or may not be expressed as memory.

The communication I/F (14) transmits and receives various data via the network (30). The communication may be performed by either wired or wireless means, and any communication protocol may be used as long as communication can be performed between the two. The communication I/F (14) has a function of performing communication with various devices such as terminals (20) via the network (30). The communication I/F (14) transmits various data to various devices such as terminals (20) according to instructions from the control unit (11). In addition, the communication I/F (14) receives various data transmitted from various devices such as terminals (20) and transmits the data to the control unit (11). In addition, the communication I/F (14) may be simply expressed as a communication unit. In addition, when the communication I/F (14) is configured as 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 about the input to the control unit (11). The input/output unit (12) is typically realized by hardware keys such as a keyboard or a pointing device such as a mouse. In addition, the input/output unit (12), as a non-limiting example, may include a touch panel, a camera (for operation input via video), or a microphone (for operation input via voice), or it may not be necessary. However, in the present invention, the input/output unit (12) is not limited to these.

The display (13) is typically realized as a monitor (for example, but not limited to, a liquid crystal display or an organic electroluminescence display (OELD)). In addition, the display (13) may or may not be a head-mounted display (HMD). In addition, the displays (13) may or may not be capable of displaying display data in 3D. In the present invention, 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 (time information). The clock unit (19) is configured to include, but is not limited to, a hardware clock such as an RTC (Real Time Clock) or a system clock. The clock unit (19) may also be expressed as, but is not limited to, a time unit or a time information detection unit.

(3) Store POS system configuration

Figure 2 shows an example of the system configuration of a store POS system (40).

The store POS system (40) is a POS system introduced and used in a store affiliated with a business operator that operates a server (10), and includes, as an example and not a limitation, a store code reader device (50), a code register (60), and a store server (70).

The store code reader device (50) is connected to a code register (60) or a store server (70) through a POS communication I/F (57) (as an example and not a limitation, a wired communication I/F or a wireless communication I/F of the store), and can read a terminal display code image displayed on the display unit (24) of the terminal (20) during accounting at the code register (60). Then, based on the reading of the terminal display code image, payment request information is transmitted to the server (10) through the communication I/F (54), and after payment is made at the server (10), information regarding the payment result (e.g., a store payment completion notification described later) is received from the server (10) through the communication I/F (54).

The store code reader device (50) is provided with, as an example and not a limitation, a control unit (51), an input/output unit (52), a display unit (53), a communication I/F (54), a storage unit (55), a sound output unit (56), a POS communication I/F (57), a code reader (58), and a clock unit (59).

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

The code register (60) is, for example and not limitation, connected to a store code reader device (50) or a store server (70) through a POS communication I/F (57), and issues a receipt printed with information such as the total amount of goods sold or the balance of electronic money of the terminal (20) user based on a store payment completion notification received by the store code reader device (50) from the server (10). In addition, for example and not limitation, the code register (60) may be configured to be integrated with the code register (60) or may be configured to have a display that is provided separately from the code register (60) and faces the customer side. The code register (60) is a register configured to be compatible with a payment application, and may also be referred to as a payment application-compatible terminal.

The store server (70) manages various types of information, such as, but not limited to, store information about the store itself, information about products sold in the store itself, information about services provided in the store itself, and information about sales resulting from product sales or service provision in the store itself. The store server (70) is configured to be able to communicate with a store code reader device (50) or code register (60) via a POS communication I/F (57), and is also configured to be able to communicate with external devices such as a server (10) via a network (30).

In addition, 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) through the code register (60). For example, the store payment completion notification received by the store code reader device (50) from the server (10) may be transmitted to the code register (60) and then transmitted from the code register (60) to the store server (70).

(4) Other

The server (10) stores the program (P) in the storage unit (15), and by executing this program (P), the control unit (11) executes processing as a part included in the control unit (11). That is, the program (P) stored in the storage unit (15) enables 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 goes for other devices.

In each embodiment of the present invention, it is described that this is realized by the CPU of the terminal (20) and/or server (10) executing the program (P).

The same goes for other devices.

In addition, the control unit (21) of the terminal (20) and/or the control unit (11) of the server (10) may or may not implement each process by a logic circuit (hardware) formed by an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)), etc., or a dedicated circuit, in addition to a CPU having a control circuit. In addition, these circuits may or may not be implemented by one or more integrated circuits, and a plurality of processes shown in each embodiment may or may not be implemented by a single integrated circuit. In addition, LSI is sometimes referred to as VLSI, super LSI, ultra LSI, etc. depending on the difference in integration level. Therefore, the control unit (21) may or may not be expressed as a control circuit.

The same goes for other devices.

In addition, the program (P) of each embodiment of the present invention (as an example and not a limitation, a software program, a computer program or a program module) may or may not be provided in a state stored on a computer-readable storage medium. The storage medium may store the program (P) in a “non-transitory tangible medium.” In addition, the program (P) may or may not be for realizing the functions of each embodiment of the present invention. In addition, the program (P) may or may not be a so-called difference file (differential program) that can realize the functions of each embodiment of the present invention by combination with a program (P) already recorded on the storage medium, or it may or may not be a so-called difference file.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (including, but not limited to, field-programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), hard disk drives (HDDs), hybrid hard drives (HHDs), optical disks, optical disk drives (ODDs), magneto-optical disks, magneto-optical drives, floppy diskettes, floppy disk drives (FDDs), magnetic tapes, solid-state drives (SSDs), RAM drives, secure digital cards or drives, any other suitable storage medium, or a suitable combination of two or more thereof. The storage medium may be volatile, non-volatile, or a combination of volatile and non-volatile, as appropriate. In addition, the storage medium may be any device or medium that can store a program (P), and is not limited to these examples. In addition, the storage medium may or may not be referred to as a memory.

The server (10) and/or terminal (20) can realize the functions of a plurality of functional units shown in each embodiment by reading a program (P) stored in a storage medium and executing the read program (P).

The same goes for other devices.

In addition, the program (P) of the present invention may or may not be provided to the server (10) and/or terminal (20) via any transmission medium (communication network, etc.) capable of transmitting the program. The server (10) and/or terminal (20) realizes the functions of the plurality of functional units shown in each embodiment by executing the program (P) downloaded via the Internet, etc., as an example and not a limitation.

The same goes for other devices.

delete

At least some of the processing in the server (10) and/or terminal (20) may be realized by cloud computing consisting of one or more computers, or may not be realized by cloud computing.

At least part of the processing in the terminal (20) may be configured to be performed by the server (10), or it may not be. In this case, at least part of the processing in each functional unit of the control unit (21) of the terminal (20) may be configured to be performed by the server (10), or it may not be.

At least part of the processing in the server (10) may be configured to be performed by the terminal (20), or it may not be. In this case, at least part of the processing in each functional unit of the control unit (11) of the server (10) may be configured to be performed by the terminal (20), or it may not be.

Unless explicitly stated, the configuration of the judgment in the embodiment of the present invention is not mandatory, and may be such that a predetermined process is performed when the judgment condition is met, or a predetermined process is performed when the judgment condition is not met, or may not be such.

In addition, the program of the present invention is implemented using, as examples and not limitation, script languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), and markup languages such as HTML5.

Additionally, the expression "via communication I/F" is used appropriately in this specification. This indicates that the device transmits and receives various information or data via the communication I/F (via the communication unit) based on the control of a control unit (processor, etc.), as an example and not a limitation.

<Example 1>

Recently, applications (application software) related to network services, such as applications for electronic payment using electronic money (payment applications), applications for remittance of electronic money (remittance applications), or payment applications that integrate some or all of the functions of these applications, are becoming widespread, and terminal (20) users can use these applications to receive various services related to electronic money.

The embodiment described below is, by way of example and not limitation, an embodiment in which a terminal (20) user makes a payment using a payment application stored and executed on the terminal (20). Specifically, a technology is proposed that enables appropriate payment even offline.

Hereinafter, a business operator providing payment services through a payment application is referred to as a "payment service operator." Furthermore, the payment service operator may or may not be referred to as a business operator providing a payment application or a server (10).

In addition, the following description describes a server (10) operated and managed by a payment service provider. In addition, the name of the payment application is appropriately referred to as "Payment App" and described below.

In addition, the payment application may be provided by the server (10) as a standalone application that does not have the functionality of a so-called messaging service (MS), or may be provided by the server (10) as a composite application that has the functionality of an MS. In addition, the messaging service may or may not include an instant messaging service (IMS) that enables the transmission and reception of content such as simple messages between terminals (20).

In addition, the payment application may be provided by the server (10) as a standalone application that does not have the function of a so-called social networking service (SNS), or may be provided by the server (10) as a composite application that has the function of an SNS.

Furthermore, MS (including IMS) can be considered a form of SNS. Therefore, MS and SNS can be distinguished, or not.

Additionally, stores affiliated with payment service providers are referred to as “affiliated stores (affiliated stores)” and are indicated as “affiliated store S1”, “affiliated store S2”, etc. in Figure 1.

In addition, “electronic money” means electronic money that is distinct from physical money and is owned by a terminal (20) managed by a payment application or a user of a terminal (20), and “payment” means electronic payment using this electronic money.

Additionally, electronic money may be expressed as “electronic money” or “digital currency (digital currency),” or it may not be expressed as such.

Additionally, as “electronic money” or “digital currency”, either legal tender or virtual currency may be used.

Additionally, “electronic money” or “digital currency” may also include cryptocurrencies (cryptocurrencies).

Additionally, virtual currency may include physical currency such as coupons.

The contents described in the first embodiment can be applied to any of the other embodiments.

Payment Method

(1) Online payment

First, as a sun, we will explain the online payment method with reference to the flow chart.

Hereinafter, "online" refers to whether a terminal (20) can communicate with a server (10), and "online status" refers to this online status. In addition, "online payment" refers to payment being made by the server (10) in an online status.

In addition, in the following, communication between the terminal (20) and the server (10) is realized by a first communication method using a frequency band different from wireless LAN communication, which is realized by way of a non-limiting example, such as a base station installed by a communication company (communication carrier). The first communication method includes, by way of a non-limiting example, packet communication (so-called mobile data communication in the terminal (20).

Additionally, as a communication method, a second communication method different from the first communication method may or may not be used. The second communication method includes, but is not limited to, wireless LAN (e.g., WiFi (registered trademark)).

In addition, the ability of the terminal (20) and the server (10) to communicate through at least one of the first communication method and the second communication method may or may not be defined as an “online state.”

Figure 3a is a flowchart illustrating an example of a processing flow executed by each device in this case. From left to right, examples of processing executed by the control unit (21) of the terminal (20), processing executed by the control unit (51) of the store code reader device (50), and processing executed by the control unit (11) of the server (10) are illustrated.

Each step in each process is represented by a combination of capital letters and numbers, and the term “step” is omitted in this specification.

In addition, the flowchart described below is merely an example of the processing in this embodiment, and some steps in the flowchart described below may not be executed, and additional steps may be inserted.

These also apply to other flowcharts in this specification.

First, the control unit (21) transmits code generation request information for requesting generation of a code for terminal display to the server (10) via the communication I/F (22) (A110).

Hereinafter, as an example and not a limitation, “code information” is explained as a concept including information stored in a code image through encoding or the like, information stored in a code image (hereinafter referred to as “original information” in the sense of original information), and a “code image” in which the original information is stored. In other words, “code information” includes “original information” and “code images.”

“Original information” may be expressed as “encoding information” or “storage information,” or it may not be expressed as such.

In addition, in the following, as an example and not a limitation, the term “code” is considered to have substantially the same meaning as “code information.”

However, these definitions are merely examples and are not limited to these.

For example, the term “code information” may be used to mean “source information,” or it may not be used to mean “source information.”

Also, for example, the term "code" may or may not be used to mean "code image."

In this embodiment, as an example of the above-mentioned original information, a "payment number" is exemplified, which is a random number of a predetermined number of digits and is a number uniquely generated for each terminal (20) that is the transmitter of the code generation request information by the server (10) or for each terminal (20) user. The payment number is information associated with the terminal (20) or the terminal (20) user, and can also be said to be information used for payment by the server (10).

Hereinafter, the payment code generated by the server (10) based on the code generation request information is referred to as a “terminal display code,” and the code image of this terminal display code is referred to as a “terminal display code image.”

Although the details will be described later, the above payment number is stored in the code image for terminal display.

The payment number or terminal display code image is an example of “first information” for making payment using a code image, and is transmitted from the server (10).

Hereinafter, an example is given in which information requesting the server (10) to generate the above-described code image for terminal display is used as code generation request information. That is, this processing is, as an example and not a limitation, a request for generation of a code image for terminal display from a terminal (20) to a server (10), and A110 transmits code generation request information requesting generation of a code image for terminal display to the server (10).

Additionally, in this specification, “terminal display code” is described as a code used for payment in the payment type “terminal code display.”

In the payment type "terminal code display", when a terminal (20) user makes a payment at a store, etc., the user uses the payment application stored in the terminal (20) to present the terminal display code image displayed on the terminal (20) to the store's code register (60) to the staff. Then, payment is realized by reading this terminal display code image with a store code reader device (50), etc.

Since the code for terminal display is a code (code image) presented by the terminal (20) user to the staff of a store, etc., it can also be expressed as “presentation code” or “user presentation code.”

The code generation request information transmitted from A110 may include, but is not limited to, identification information for identifying a terminal (20) or a user of the terminal (20). For example, terminal identification information for identifying one's own terminal (20) (e.g., terminal ID), user identification information for identifying one's own terminal (20) (e.g., user ID), account information for a payment application (e.g., application ID), and the like are included here.

When code generation request information is received from the terminal (20) by the communication I/F (14) (C110), the control unit (11) executes code generation processing for terminal display (C120).

Specifically, as an example and not a limitation, a method (algorithm) for generating a random number of a predetermined number of digits (e.g., about 10 to 12 digits) is used to generate a random number of a predetermined number of digits as a payment number. Then, as an example and not limitation, a terminal display code image including at least the payment number as original information is generated. More specifically, at least the payment number is encoded and graphically generated, and a terminal display code image represented as an image of a two-dimensional code (e.g., QR code) is generated. In addition, identification information of the terminal (20) or the terminal (20) user included in the received code generation request information and the generated payment number are associated and stored in the storage unit (15).

Next, the control unit (11) transmits the generated terminal display code (in this example, a terminal display code image) to the terminal (20) via the communication I/F (14) (C130). The terminal (20) receives the terminal display code (in this example, a terminal display code image) from the server (10) via the communication I/F (22) (A130). In this case, the control unit (21), as an example and not a limitation, displays the received terminal display code image on the display unit (24).

After that, when the terminal display code image displayed on the display unit (24) is presented to a store employee or the like by the user of the terminal (20), the control unit (51) performs control to have the terminal display code image displayed on the display unit (24) of the terminal (20) be read by a code reader (58) (B150).

Thereafter, the control unit (51) accesses the server (10) through the communication I/F (54) using an application interface (API) or the like related to the payment application provided (distributed) by the payment service provider, and transmits payment request information including at least a payment number acquired by decoding from a read terminal display code image, identification information for identifying a store or store code reader device (50) (hereinafter referred to as “store identification information”), and an amount to be paid (hereinafter referred to as “amount to be paid”) to the server (10) through the communication I/F (54) (B160).

When payment request information is received from the store code reader device (50) by the communication I/F (14) (C160), the control unit (11) performs payment processing (C170). Specifically, it is determined whether the payment number included in the received payment request information is stored in the storage unit (15) in association with the identification information of the terminal (20) or the user of the terminal (20). If so, it is determined that “payment is possible,” and payment is made by subtracting the payment amount from the electronic money balance (electronic money balance associated with the application ID of the payment application) (hereinafter, simply referred to as “balance”) of the terminal (20) or the user of the terminal (20) identified by the identification information stored in association with the payment number.

Thereafter, the control unit (11) transmits a store payment completion notification (hereinafter referred to as a “store payment completion notification”) to the store code reader device (50) via the communication I/F (14) (C180). The store payment completion notification includes, but is not limited to, store payment information such as the intent that payment has been completed (successfully), the date and time of payment (payment date and time), and the amount paid (payment amount).

In addition, the control unit (11) transmits a terminal payment completion notification (hereinafter referred to as a "terminal payment completion notification") to the terminal (20) via the communication I/F (14) (C190). The terminal payment completion notification includes, but is not limited to, payment information for the terminal, such as a notification that payment has been completed (successfully), the date and time of payment (payment date and time), store identification information of the store where payment was made (payment store identification information), and the amount paid (payment amount). Then, the control unit (11) terminates the processing.

In addition, in this case, when payment by the server (10) is successful, a payment completion notification for the store and a payment completion notification for the terminal are transmitted from the server (10). However, there are cases where the server (10) cannot perform payment due to insufficient balance, etc. In this case, it is preferable to transmit a notification indicating that payment could not be performed (e.g., payment error notification, payment NG notification) to the store code reader device (50) and the terminal (20).

The same applies to other treatments.

When a payment completion notification for the store is received from the server (10) via the communication I/F (54) (B180), the control unit (51) terminates processing.

In addition, when a terminal payment completion notification is received from the server (10) via the communication I/F (22), the control unit (21) updates the balance stored in the terminal (20) as payment application data based on the received terminal payment completion notification. In addition, the control unit (21) displays the payment result on the display unit (24) (A190). Then, the control unit (21) terminates the processing.

FIG. 3b is a drawing showing an example of a main screen displayed in a payment application running on a terminal (20).

This main screen is the display screen that appears when the payment application is launched. The name of the payment application, "Payment App," is displayed at the top of the screen. Within the frame below, the balance (in this case, "3,000 yen") is displayed, and next to it is a recharge button for recharging (adding) electronic currency. Below that, several function icons corresponding to the various functions of the payment application are displayed.

Among these function icons, the icon marked as "code" is, by way of example and not limitation, a "code icon" for displaying a code display screen on the display unit (24). When this code icon is touched by a terminal (20) user, by way of example and not limitation, code generation request information is transmitted from the terminal (20) to the server (10), and a code for terminal display is generated by the server (10). Then, the generated terminal display code is transmitted from the server (10) to the terminal (20), and the code display screen shown in Fig. 3c is displayed on the display unit (24) of the terminal (20).

Figure 3c is a drawing showing an example of a code display screen.

This code display screen displays the word "Code" at the top of the screen, and below that, a points tab is displayed to set the payment method, the points the user owns, and whether to use those points for payment.

In addition, below that, as code images of terminal display codes acquired from the server (10), a one-dimensional terminal display code image displayed as a barcode and a two-dimensional terminal display code image QC0 displayed as a QR code are displayed in different areas within the display screen, respectively. In addition, below the barcode, as an example, a 12-digit payment number is displayed.

Additionally, in this example, the terminal display code displayed on the code display screen has a set expiration date (hereinafter referred to as the "code usage period") within which payment can be made using the code. As a non-limiting example, the code usage period can be defined as "the date and time after a specified period of time (e.g., "5 minutes") has elapsed from the time (date and time) at which the terminal display code is displayed (display begins) on the terminal (20)." The specified period can be appropriately changed.

The code usage period is a period based on the code display time (code display date and time) on the terminal (20) side, and since it is a period for displaying a code for terminal display on the terminal (20), it can also be expressed as “code display period.”

Additionally, the regulation time can also be expressed as “code display time”.

In addition, the remaining time until the code expiration date is displayed in a countdown format below the two-dimensional terminal display code image QC0. This remaining time is displayed based on information measured by the clock section (29A) of the terminal (20). When the remaining time reaches "0", the terminal display code becomes unusable, and when making a payment, it is necessary to re-acquire the terminal display code from the server (10).

The terminal (20) user presents the code display screen of Fig. 3c to the store employee using the code register (60) by the code expiration date, and makes payment by having the store code reader (50) read the code image for terminal display. In this case, the store code reader (50) accesses the server (10) via the communication I/F (54) using the API described above, and transmits the information required for payment to the server (10). Accordingly, payment is processed by the server (10).

In addition, as described above, if the terminal (20) is configured to display a code display screen on the display unit (24) at the timing when the terminal (20) receives a terminal display code from the server (10), as an example and not a limitation, when the server (10) generates a terminal display code image, the code usage period may be stored in association with the generated terminal display code image, and the associated code usage period may be notified to the terminal (20), so that the server (10) and the terminal (20) can share information on the code usage period.

While the processing for realizing online payment has been exemplified so far, applying the above processing requires that the terminal (20) and server (10) be in a state where communication is possible (online). Of course, it is also necessary that the store code reader device (50) and the server (10) be in a state where communication is possible.

However, when making a payment in a location with poor radio conditions such as underground, or in a situation where the lines are congested such as at an event venue, or when the communication volume of the terminal (20) exceeds a certain amount for a certain period of time (e.g., one month) and there is a communication restriction or communication speed restriction, it is assumed that the terminal (20) and the server (10) may be unable to communicate (or have communication difficulties), making it difficult to make a payment. Therefore, the following exemplifies a method for making a payment even in such cases.

(2) Offline payment

An offline payment method as one embodiment of the method of the present invention is described with reference to a flowchart.

Hereinafter, "offline" indicates that the terminal (20) cannot communicate with the server (10), and "offline state" indicates this offline state. In addition, "offline payment" indicates that payment is made by the server (10) in the offline state. In addition, it is assumed that the store code reader device (50) can communicate with the server (10).

In addition, in the following, a payment code processed (including processing, generation, display, etc.) on the terminal (20) side based on a terminal display code generated by a server (10) is referred to as an “extended terminal display code,” and a code image of this extended terminal display code is referred to as an “extended terminal display code image.”

The extended terminal display code is a code used for payment in the payment type "terminal code display", similar to the terminal display code, but is not limited to online payments and can also be used for offline payments.

Additionally, the code for extended terminal display can be used not only for offline payments but also for online payments. That is, it is not essential for the terminal (20) to determine (detect) whether it is offline, and it is possible to enable payment using the code for extended terminal display regardless of whether it is online or offline.

This is also true for other treatments.

Figure 3d is a flowchart illustrating an example of the processing flow executed by each device in this case. The drawing is similar to the flowchart described above.

The flowchart of Fig. 3d is a modified version of the flowchart of Fig. 3a, written in offline specifications. The flowchart of Fig. 3a differs, by way of example and not limitation, in processing steps in an online state (e.g., A240), in processing steps in an offline state (e.g., A250, B250, B280), and in processing steps when returning from an offline state to an online state (e.g., A290, C290).

After A130, the control unit (21) stores the received terminal display code (in this example, a terminal display code image) in the storage unit (28) (A240).

Here, “stock” means storing the received terminal display code in a storage unit (28) to make it available for later use.

Additionally, in this specification, "stock" is sometimes simply expressed as "storage." Furthermore, stocking terminal display codes is also expressed as "storing terminal display codes in terminal display code stock data."

In this process, in order to enable offline payment, a terminal display code (in this example, a terminal display code image) acquired from a server (10) in an online state is stored in the storage unit (28) of the terminal (20). Then, when payment in an offline state becomes necessary, the stored terminal display code is used to enable payment without the need to communicate with the server (10).

To be specific, after A240, it is said to have gone offline.

Here, the terminal (20) detects that it has become offline by any of the following methods, as an example and not a limitation.

(A) During execution of a payment application on a terminal (20), a connection confirmation request is transmitted from the server (10) to the terminal (20) at regular or specific timings, and a connection response including identification information (e.g., application ID) is transmitted from the terminal (20) to the server (10) in response to the connection confirmation request. In this case, if the control unit (21) of the terminal (20) does not receive a connection confirmation request from the server (10), it determines that the terminal (20) has entered an offline state.

(B) During execution of a payment application on a terminal (20), a connection notification including identification information (e.g., application ID) is transmitted from the terminal (20) to the server (10) at regular or specific timings, and a connection confirmation is transmitted from the server (10) to the terminal (20) in response to the connection notification. In an offline state, a connection notification cannot be transmitted from the terminal (20) to the server (10). Therefore, as an example and not a limitation, the control unit (21) of the terminal (20) determines that the terminal (20) has entered an offline state when it detects the occurrence of a transmission error of the connection notification.

In addition, the terminal (20) may, as an example and not a limitation, use a library or application that acquires the connection status of the network to acquire information about the communication status of its own terminal (20) and determine whether it has entered an offline state, or it may not do so.

In an offline state, when a terminal display code image stocked in A240 is displayed on the display unit (24) (A250) and presented by a user to a store employee, etc., the control unit (51) controls the code reader (58) to read the terminal display code image displayed on the display unit (24) of the terminal (20) (B250). Then, the control unit (51) proceeds to processing at B160.

After B160, when a store payment completion notification is received from the server (10) by the communication I/F (54) (B280), based on the received store payment completion notification, the store staff orally notifies the terminal (20) user that the offline payment has been completed (successful).

After C180, the control unit (11) transmits a terminal payment completion notification to the terminal (20) (C290). However, in the offline state, the terminal (20) cannot receive the terminal payment completion notification. When the terminal (20) returns to the online state, the terminal payment completion notification transmitted from the server (10) is received by the terminal (20). Then, when the terminal payment completion notification is received from the server (10) via the communication I/F (22), the control unit (21) displays the payment result on the display unit (24) based on the received terminal payment completion notification (A290).

The processing described above is an example of processing for offline payment.

Here, since the terminal display code is a one-time use code, it is considered that, as with online payments, a code usage period should be set for the terminal display code for offline payments as well.

However, this method cannot be directly applied to offline payments. This is because, in an online state, the server (10) communicates with the terminal (20) and can recognize that a terminal display code is displayed on the terminal (20), and thus, based on the clock information of the clock unit (19) of the server (10), it can determine whether the code's expiration date has expired. However, in an offline state, the server (10) cannot communicate with the terminal (20), and therefore cannot recognize that a terminal display code is displayed on the terminal (20).

Specifically, in an online state, when a payment application is launched on a terminal (20), identification information (e.g., application ID) for identifying the terminal (20) or the user of the terminal (20) is transmitted from the terminal (20) to the server (10), as an example and not a limitation. Thereby, the server (10) can recognize that the payment application has been launched on the terminal (20). However, in an offline state, even if the payment application has been launched, identification information cannot be transmitted from the terminal (20) to the server (10). Therefore, even if a terminal display code is displayed on the terminal (20), the server (10) cannot recognize this and thus cannot specify the code usage period.

Additionally, for example, a malicious user may save the terminal display code image displayed in the payment application of his/her terminal (20) by taking a screenshot of his/her terminal (20), etc., and make a payment using the saved terminal display code image.

In addition, there is a possibility that the terminal display code image displayed within the payment application of one user terminal (20) may be photographed by another user using a camera of the user terminal (20) and payment may be made.

<Function Configuration>

(1) Server function configuration

Fig. 4a is a drawing showing an example of a function realized by the control unit (11) of the server (10) in this embodiment.

Hereinafter, a case is exemplified in which a terminal (20) user uses a payment application stored in the terminal (20) to make a payment by the aforementioned payment type “terminal code display”, as an example and not a limitation.

The server (10) is equipped with a payment management processing unit (111) as a function realized by the control unit (11).

The payment management processing unit (111) is equipped with a function of executing payment management processing for managing various information or data related to a payment application running on a terminal (20) or for managing payment using electronic money of a terminal (20) or a terminal (20) user, according to a payment management processing program (151) stored in a storage unit (15).

The payment management processing unit (111) includes, as functional units, a terminal display code generation processing unit (1111) that generates a terminal display code by terminal display code generation processing and a payment processing unit (1113) that executes payment by payment processing, as examples and not as limitations.

The terminal display code generation processing unit (1111) generates a terminal display code image displayed as a two-dimensional code, as an example and not a limitation. A two-dimensional code is a code of a display method that has information in the horizontal and vertical directions, and includes a matrix-type code (hereinafter referred to as a "matrix code") in which small squares are arranged vertically, horizontally, and horizontally, and a stack-type code (hereinafter referred to as a "stack code") in which a plurality of one-dimensional codes (as an example and not a limitation, a barcode) are overlapped vertically.

In this embodiment, for the sake of simplicity of explanation, the QR code (registered trademark), which is an example of a widely used matrix code, is explained as an example of a code for terminal display.

Also, unlike the present embodiment, other than the QR code, matrix codes such as SP code, vericode, maxicode, CP code, and chameleon code may or may not be used. Furthermore, various stack codes other than the matrix code may or may not be used.

In addition, the terminal display code generation processing unit (1111) may generate a one-dimensional code (a barcode, for example, but not limited to) in addition to a two-dimensional code (a QR code, for example, but not limited to) as the terminal display code, or may not be configured to do so. This is because some stores may not support reading of two-dimensional codes but may support reading of one-dimensional codes.

The payment processing unit (1113) has a function of performing payment processing based on, for example and not limitation, information transmitted from a store POS system (40) or information transmitted from a terminal (20).

FIG. 4b is a drawing showing an example of information stored in the storage unit (15) of the server (10) in this embodiment.

In the storage unit (15), as an example and not a limitation, a payment management processing program (151) that is read by the control unit (11) and executed as a payment management process is stored as a program.

In addition, in the storage unit (15), as examples and not limitation, user registration data (153), store registration data (155), payment management database (157), and code management data (159) are stored as data.

User registration data (153) is terminal (20) and terminal (20) user registration data using the payment service, and an example of the data configuration is shown in Fig. 4c.

User registration data (153) is stored in association with, but not limited to, user name, terminal phone number, terminal email address, application ID, authentication password, and other registration information.

The user name is the name of the terminal (20) user who uses the payment service, and the name registered by the terminal (20) user when using the payment service is stored.

The terminal phone number is the phone number of the user terminal (20) of this user name, and the phone number of the terminal (20) registered when the terminal (20) user uses the payment application is stored.

The terminal mail address is the mail address of the user terminal (20) of this user name, and the mail address of the terminal (20) registered when the terminal (20) user uses the payment application is stored.

A terminal phone number or terminal email address is an example of identification information (hereinafter referred to as “terminal identification information”) for identifying a terminal (20).

The application ID is an account (account information) of a payment application and is an ID that identifies a terminal (20) or a terminal (20) user. This application ID is, by way of example and not limitation, a unique ID set and stored by the server (10).

The authentication password is an authentication password that the user is required to enter when performing payment authentication processing (hereinafter, simply referred to as “authentication processing”) on the user terminal (20) of this user name, and the password set by the user is stored.

Additionally, payment authentication processing is not mandatory and can be omitted. In this case, there is no need to store the authentication password in the registration data (153).

Other registration information is other registration information of the user with this user name, and includes, but is not limited to, user icon images, which are image data of icons used by the user in payment applications, and the user's profile.

Store registration data (155) is registration data of a store affiliated with a business operator (business operator of the server (10)) providing a payment application. An example of the data structure of store registration data (155A), which is an example of this store registration data (155), is shown in Fig. 4d.

In the store registration data (155A), for example and not limitation, the industry, store name, store location information, store POS system information, and store ID are stored in association with store information.

The industry category stores the store's business type. This category includes, but is not limited to, various business types, such as "convenience store," "supermarket," "pharmacy," "tavern," "department store," "restaurant," "bookstore," and "watch store."

In the store name, the store names of stores included in (belonging to) each industry are stored for each industry.

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

The store POS system information stores information about the store POS system (40) used in this store. This store POS system information includes, by way of example and not limitation, information required for the server (10) to communicate with the store code reader device (50) or the store server (70).

The store POS system (40) may, for example and not limitation, acquire in advance a software package for a payment application provided (distributed) from the server (10) for processing in conjunction with the server (10), store the software package in the store code reader device (50) or the store server (70), and call and use this software package from a payment processing program in the store. An application programming interface (API) is one example, and the store code reader device (50) transmits information to the server (10) by, for example, initiating the API, and realizes receiving information from the server (10).

In addition, the server (10) may receive, as a non-limiting example, information such as the store's industry, store name, store location information, store POS system information, etc., from the store server (70) of the store and store the information in the store registration data (155).

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

Store ID is an example of store identification information.

The payment management database (157) is a database that stores data for managing payment information of each terminal (20) user in a stacked form, and an example of the configuration of the payment management database (157A) is shown in FIG. 4e.

The payment management database (157A) stores payment management data generated for each terminal (20) or each terminal (20) user.

Each payment management data store, for example and not limited to, application ID, balance, points, daily limit setting amount, automatic recharge setting, and payment history data.

The application ID stores the application ID stored in the user registration data (153).

The balance is stored in the application ID.

Points are stored in the payment application, which can be accumulated through various services related to the application or at merchants affiliated with the payment application. Points are valued at 1 yen per point, and can be exchanged for gift certificates, merchandise, and other items. They can also be redeemed for cash through the payment application and used for payments.

The daily limit amount is stored as the daily upper limit of the amount that can be used for payment by the terminal (20) or terminal (20) user owning this application ID.

The automatic recharge setting is a setting for whether or not electronic money will be automatically replenished (automatic recharge) when the balance is low (e.g., "500 yen") or "0 yen." If the automatic recharge setting is made by the terminal (20) user, "ON" is stored, and otherwise, "OFF" is stored. As an example and not a limitation, automatic recharge can be made from a bank account registered by the terminal (20) user.

Payment history data is data regarding the payment history of the user of this application ID, and as an example and not a limitation, for this application ID, the payment date and time, which is the date and time when payment was made by the server (10), the store ID, which is the ID of the store where payment was made, the payment store name, which is the store name of the store ID, and the payment amount, which is the amount paid, are related and stored in a time series.

Additionally, the payment management data described above does not necessarily need to store all of the information listed above. For example, some or all of the following information may not be stored in the payment management data: points, daily limit, and automatic recharge settings.

In addition, it is possible to transmit payment details information to the terminal (20) each time a payment is made and store it in the terminal (20), so that payment details data is not stored in the server (10).

Code management data (159) is data for managing a code (a code for terminal display in this embodiment), and as an example and not a limitation, data is stored in which the application ID stored in the user registration data (153) and the original information (e.g., payment number) of the code image for terminal display generated for the terminal (20) or the terminal (20) user identified by the application ID are related.

In addition, instead of the application ID, terminal identification information such as the terminal phone number stored in the user registration data (153) may be stored in the code management data (159), or it may not be necessary.

(2) Functional configuration of the terminal

FIG. 4f is a drawing showing an example of a function realized by the control unit (21) of the terminal (20) in this embodiment.

The terminal (20) is equipped with a payment application processing unit (211) as a function realized by the control unit (21).

The payment application processing unit (211) has a function of executing payment application processing for payment-related processing based on payment application software (281) stored in the storage unit (28).

The payment application processing unit (211) includes, as functional units, an extended terminal display generation processing unit (2111) that executes code generation processing for extended terminal display, and a code display processing unit (2113) that executes code display processing, as examples and not limitations.

In this embodiment, the processing related to payment is a concept that includes, as an example and not a limitation, a processing of obtaining a terminal display code from a server (10) (including a processing of requesting the server (10) to generate a terminal display code or a processing of receiving a generated terminal display code from the server (10), a processing of stocking a terminal display code obtained from the server (10), a processing of displaying a stocked terminal display code image, a processing of generating an extended terminal display code image based on the stocked terminal display code (an extended terminal display code generation processing), a processing of displaying an extended terminal display code image (a code display processing), a processing of obtaining a terminal payment completion notification from the server (10), and the like, and more specifically, an overall processing executed on a terminal (20) as a related processing after performing a payment.

FIG. 4g is a drawing showing an example of information stored in the storage unit (28) of the terminal (20) in this embodiment.

In the storage unit (28), payment application software (281) is stored as application software acquired by downloading in advance from the server (10), for example, but not limited to.

Payment application software (281) includes, by way of example and not limitation, a payment application program (282) and payment application data (283).

Payment application data (283) stores various data used in payment application software. This payment application data (283) stores, for example, but not limited to, terminal display code stock data (2831), payment data (2832), and store data (2833).

The terminal display code stock data (2831) stores data of the terminal display code acquired from the server (10) in an online state.

Payment data (2832) is payment data stored in the terminal (20), and the configuration of payment data (2832A), which is an example, is shown in Fig. 4h.

Payment data (2832A) stores, for example but not limited to, application ID, points, balance, daily limit setting amount, automatic recharge setting, and payment history data.

The control unit (21) stores in a time series manner in payment history data, based on a payment completion notification for the terminal received from the server (10) after returning to an online state, for example, but not limited to, the payment date and time, which is the date and time of payment by the server (10), the store ID, which is the ID of the store where payment was made by the server (10), the payment store name, which is the name of the store of the store ID, and the payment amount, which is the amount paid by the server (10).

In the store data (2833), various store information stored in the store registration data (155A) of the server (10) is stored, as an example and not a limitation.

Store data (2833) may be updated by transmitting the latest store information from the server (10) to the terminal (20) at the update timing of the payment application software (281), as an example and not a limitation.

Additionally, terminal data (289) is stored in the storage unit (28), as an example and not a limitation.

Terminal data (289) is data regarding the terminal (20), and includes, as examples and not limitation, terminal identification information such as the terminal phone number or terminal mail address, and various setting information on the terminal (20) side.

<Example of display screen>

FIG. 4i is a drawing showing an example of the main screen of a payment application displayed on the display unit (24) of a terminal (20) in this embodiment.

The configuration of this main screen is the same as that of Fig. 3b, and here, the state in which the “code icon” is touched by the terminal (20) user is displayed.

Fig. 4j is a drawing showing an example of a code display screen displayed on the display unit (24) of the terminal (20) in this embodiment. This code display screen is, by way of example and not limitation, displayed when a "code icon" is touched in an offline state, as in Fig. 4i.

In this code display screen, the code images of the first extended terminal display code, which is the extended terminal display code in this embodiment, are displayed in different areas within the display screen, including a one-dimensional first extended terminal display code image displayed as a barcode and a two-dimensional first extended terminal display code image QC1 displayed as a QR code. In addition, a payment number displayed as a 12-digit number is displayed below the one-dimensional first extended terminal display code image.

The code image for the first extended terminal display (not limited to, but an example of the first code image based on the first information and the visual information) is a code image in which the original information (in this example, a payment number) stored in the code image for the terminal display received from the server (10) and stocked in the terminal (20) and the visual information (in this example, timestamp information) generated on the terminal (20) side are encoded.

Here, timestamp information is information indicating the time, date, and time when a specific incident (specific event) occurred, and at the same time, it serves as an electronic time certificate to prove that information or data (here, the first extended terminal display code) related to the timestamp information definitely existed at a certain time.

In this example, "the display of the code image for the first extended terminal display on the display unit (24) of the terminal (20)" is a specific event, and the control unit (21) of the terminal (20) generates timestamp information including the time at which the code image for the first extended terminal display was displayed (display started) (hereinafter referred to as "code display time"). The code display time or timestamp information is an example of "time information" and is generated based on information recorded by the clock unit (29A) of the terminal (20).

Depending on the code display time, a payment period (hereinafter referred to as the "first code usage period") is determined using the code image for the first extended terminal display. In this embodiment, as an example and not a limitation, the first code usage period is set to be "the time after the first specified time (e.g., "5 minutes") has elapsed from the code display time (code display date and time). The first specified time can be appropriately changed.

The first code usage period is a period based on the code display time (code display date and time) on the terminal (20) side, and since it is a period for displaying a code for extended terminal display on the terminal (20), it can also be expressed as “first code display period.”

Additionally, the first regulation time can also be expressed as “first code display time”.

In addition, instead of or in addition to the code usage period or code display period, a code usage period or code display period may be set, or may not be required. For example, if the code image for extended terminal display is read by a store code reader device (50) or the like within the code usage period or code display period, payment is enabled, whereas if the code for extended terminal display is read by a store code reader device (50) or the like after the code usage period or code display period has elapsed, payment is disabled.

Additionally, the code usage period (code display period) may be used to mean “period,” or it may not be used.

For example, the above first code usage period may be defined as “the period from the time of code display (date and time of code display) until the first specified time has elapsed,” as an example and not a limitation, or it may not be defined as such.

When making an offline payment, the terminal (20) user presents the code display screen of Fig. 4j to the store staff by the code register (60) by the first code usage period, and makes a payment by having the store code reader device (50) read the code image for the first extended terminal display. In this case, the store code reader device (50) transmits payment request information including information (in this example, payment number and timestamp information) acquired by decoding from the read first extended terminal display code image to the server (10), so that the server (10) makes the payment.

FIG. 4k is a drawing showing an example of a payment result screen displayed on a display unit (24) based on a payment completion notification for a terminal received from a server (10) after returning from an offline state to an online state.

This payment result screen displays the text “Payment Complete” in the center of the code display screen of Figure 4j, along with the message “You can check the details from “Payment Details”,” and a “Confirmation Icon” for checking the payment details in a pop-up format.

In the above display screen example, the convenience of the user can be improved because the code display screen can be displayed, for example, by touching the code icon, without the terminal (20) user being aware of whether the user is in an online or offline state.

<Processing>

Figure 4l is a flowchart showing an example of a processing flow executed by each device in this embodiment. From the left, in order, the first payment application processing, which is an example of payment application processing executed by the control unit (21) of the terminal (20), the first store payment processing, which is an example of store payment processing executed by the control unit (51) of the store code reader device (50), and the first payment management processing, which is an example of payment management processing executed by the control unit (11) of the server (10), are shown.

The flowchart of Fig. 4l is a partially revised version of the flowchart of Fig. 3d. The flowchart of Fig. 3d is, by way of example and not limitation, different in the offline processing steps (e.g., A350, B350, B360).

This processing uses, for example, the identification information for identifying the terminal (20) or the terminal (20) user as the aforementioned application ID.

In A240, the control unit (21) stores the terminal display code in the terminal display code stock data (2831) of the storage unit (28).

In an offline state, as an example and not a limitation, when a code display operation is performed by a terminal (20) user, the code generation processing unit (2111) for extended terminal display performs the code generation processing (X) for extended terminal display, and at the same time, the code display processing unit (2113) performs the code display processing (X) (A350).

The code generation process (X) for extended terminal display generates, as an example and not a limitation, the first extended terminal display code image described above. Specifically, the payment number acquired by decoding from the terminal display code image stocked in the terminal display code stock data (2831) and the timestamp information generated by the control unit (21) are encoded and graphicized (imaged) to generate the first extended terminal display code image.

In addition, some stores may not support reading of two-dimensional codes, but may support reading of one-dimensional codes. In this case, the terminal display code generation processing unit (1111) may or may not generate a first extended terminal display code image displayed as a one-dimensional code (as an example, but not limited to, a barcode) in addition to a two-dimensional code (as an example, but not limited to, a QR code).

Additionally, instead of the code display time, it is possible to generate timestamp information including the "code display date and time" that includes date information in addition to the time, or it is not necessary to do so.

Additionally, to prevent third parties from deciphering the original information, the payment number or timestamp information may be encoded as encrypted information, or may not be used.

Additionally, rather than encoding timestamp information, it is possible to encode the code display time or the code display date and time itself, or it is not necessary to do so.

In the code display processing (X), as an example and not a limitation, a code display screen including at least a code image for the first extended terminal display is displayed on the display unit (24).

In addition, as described above, in the case where a two-dimensional first extended terminal display code image is generated in the code generation process (X) for extended terminal display, as an example and not a limitation, the two-dimensional first extended terminal display code image can be displayed.

In addition, in the case where a one-dimensional first extended terminal display code image is also generated in the code generation process (X) for the extended terminal display, as an example and not a limitation, in addition to the two-dimensional first extended terminal display code image, the one-dimensional first extended terminal display code image can be displayed. In this case, the payment number may be displayed together near the one-dimensional first extended terminal display code image, or it may not be displayed so.

Thereafter, when the code image for the first extended terminal display displayed on the display unit (24) is presented to a store employee or the like by a user of the terminal (20), the control unit (51) performs control to cause the code image for the first extended terminal display displayed on the display unit (24) of the terminal (20) to be read by a code reader (58) (B350).

The control unit (51) accesses the server (10) via the communication I/F (54). Then, the control unit (51) transmits payment request information including at least the payment number and timestamp information acquired by decoding, store identification information, and the payment amount to be paid to the server (10) via the communication I/F (54) (B360).

When payment request information is received from the store code reader device (50) via the communication I/F (14) (C160), the control unit (11) performs payment processing (C370).

Specifically, it is determined whether the payment number included in the received payment request information is stored in the code management data (159) in association with the application ID. In addition, it is determined whether the time difference between the current time (time at the time of payment) recorded by the clock unit (19) of the server (10) and the code display time specified from the timestamp information included in the received payment request information is less than or equal to the first specified time (or may be less than; hereinafter the same shall apply). Then, if these conditions are met, it is determined that “payment is possible”, and the payment amount is deducted from the balance stored in the payment management data of the application ID in the payment management database (157A) to perform payment.

<code>

The above processing shows an example in which the terminal (20) requests the server (10) to generate a code image for terminal display, and the code image for terminal display generated by the server (10) is transmitted to the terminal (20), but is not limited thereto. For example, the terminal (20) may request the server (10) to generate original information (in this example, a payment number), and the original information generated by the server (10) may be transmitted to the terminal (20), or it may not be necessary to do so.

Specifically, in the processing of FIG. 3a, at A110, the control unit (21) transmits code generation request information requesting the server (10) to generate raw information. Then, based on this code generation request information, the control unit (11) generates raw information at C120 and transmits the raw information generated at C130 to the terminal (20).

In A130, when raw information is received from the server (10), the control unit (21) generates a code image for terminal display based on the received raw information. Then, the control unit (21) displays the generated code image for terminal display on the display unit (24).

Likewise, in the processing of FIG. 3d, when raw information is received from the server (10) at A130, the control unit (21) stores the received raw information in the terminal display code stock data (2831) at A240. Then, the control unit (21) reads the stored raw information from the terminal display code stock data (2831) and generates a terminal display code image based on the read raw information. Then, at A250, the control unit (21) displays the generated terminal display code image on the display unit (24).

Likewise, in the processing of FIG. 4l, when raw information is received from the server (10) at A130, the control unit (21) stores the received raw information in the terminal display code stock data (2831) at A240. Then, the control unit (21) reads the stocked raw information from the terminal display code stock data (2831) at A350, and generates a first extended terminal display code image including the read raw information and the timestamp information generated by the control unit.

In addition, unlike the above, the terminal (20) requests the server (10) to generate a code image for terminal display, and the code image for terminal display generated by the server (10) is transmitted to the terminal (20), but on the terminal (20) side, instead of stocking the code image for terminal display received from the server (10), the original information acquired by decoding from the code image for terminal display received from the server (10) may be stocked, or it may not be necessary to do so.

<Effect of the first embodiment>

According to the first embodiment, as an example and not a limitation, in offline payments, the server can process payment based on visual information such as the time of code display. Furthermore, by preserving the terminal display code image displayed on the terminal (20) through a screen shot or the like, fraudulent payment can be prevented.

Specifically, in the first embodiment, the terminal (20) receives a payment number (or a terminal display code image including the payment number) (not limited to, an example of the first information) transmitted from the server (10) through the communication I/F (22). Then, the terminal (20) stores the received payment number in the storage unit (28) through the control unit (21). In addition, the terminal (20) displays a first extended terminal display code image (not limited to, an example of the first code image) based on the stored payment number and timestamp information (not limited to, an example of time information) in one area (not limited to, an example of the display area) of the code display screen. The timestamp information includes code display time information, and the payment is configured to be executed by the server (10) based on the payment number and timestamp information received by the server (10) based on the display of the first extended terminal display code image.

As an example of the effect obtained by such a configuration, first information transmitted from a server is stored in a storage unit of a terminal, and a first code image based on the stored first information and time information is displayed in a display area of the terminal. The time information includes time information based on the display of the first code image in the display area, and payment is executed by the server based on the first information and time information received by the server based on the display of the first code image. Therefore, for example, it becomes possible to perform offline payment through the server based on time information and first information previously stored in the storage unit of the terminal, thereby improving convenience for the terminal user.

In addition, the first embodiment shows a configuration in which the code image for the first extended terminal display (not limited to, an example of the first code image) is one code image based on the payment number and timestamp information.

As an example of the effect obtained by such a configuration, by displaying one code image based on the first information and the visual information, payment can be made simply by having an external code reader read one code image displayed in the display area of the terminal.

In addition, in the first embodiment, payment is performed based on a code image for displaying the first extended terminal being read by a code reading device such as a store, and a payment number and timestamp information are transmitted to the server (10), and a configuration is shown in which payment is executed by the server (10) based on the payment number and timestamp information.

As an example of the effect obtained by such a configuration, payment is executed by the server based on the first information and the visual information by sending the first information and the visual information to the server based on the first code image being read by the code reading device, so that payment can be easily made to the server based on the first code image displayed in the display area of the terminal.

In addition, the first embodiment has a processor that reads a payment application program (282) from a memory storing a payment application program (282) (not limited to, but an example of a program) of a terminal (20) and executes payment application processing based on the payment application program (282). Then, the processor receives a payment number (not limited to, but an example of first information) transmitted from a server (10) through a communication I/F (22), stores the received payment number in a storage unit (28), and displays a first extended terminal display code image (not limited to, but an example of the first code image) based on the payment number and timestamp information (not limited to, but an example of time information) in one area of a code display screen (not limited to, but an example of a display area of the terminal). The timestamp information includes code display time information, and the payment indicates a configuration executed by the server (10) based on the payment number and timestamp information received by the server (10) based on the display of the code image for the first extended terminal display.

As an example of the effect obtained by such a configuration, it becomes possible to perform offline payment to a server based on visual information and first information stored in advance in the terminal's storage, thereby improving convenience for terminal users.

<Variation 1 (1)>

In the first embodiment, the terminal (20) generates a code image for a first extended terminal display in which visual information is encoded, and the generated code image for a first extended terminal display is read by a store code reader device (50), so that visual information acquired by decoding is transmitted from the store code reader device (50) to the server (10), but is not limited thereto.

Specifically, it is possible not to encode the visual information into the code image for the first extended terminal display. In this case, for example, even if communication cannot be performed using the first communication method described above, if communication can be performed using the second communication method, the visual information is transmitted from the terminal (20) to the store code reader device (50) using the second communication method. Alternatively, if a short-range wireless communication method such as Bluetooth or infrared communication can be used, the visual information is transmitted from the terminal (20) to the store code reader device (50) using these communication methods. Alternatively, the visual information may be displayed separately from the code image on the display unit (24) of the terminal (20), so that the user of the terminal (20) presents the display screen to a store employee, etc., whereby the store employee, etc., manually inputs the visual information into the store code reader device (50). In addition, the visual information may be transmitted from the store code reader device (50) to the server (10).

<Variation 1 (2)>

In the first embodiment, the “time information” of the present invention is the time (code display time) or date (code display date) at which the terminal display code image is displayed on the terminal (20), or timestamp information including these, but is not limited thereto.

First, the "visual information" in the present invention is not limited to indicating a pinpoint timing such as an arbitrary time or date, and may or may not be a time (length of time) expressed in a certain time span as the "visual information." In this case, as an example and not a limitation, the time (length of time) at which a terminal display code image is displayed on the terminal (20) may or may not be used as the visual information to perform the same processing as described above.

In addition, as an example and not a limitation, the time (code generation time) or date (code generation time) at which the terminal (20) generates a code image for terminal display, the time or date at which the terminal (20) begins preparations for displaying the code for terminal display on the display unit (24) as an internal process, and the time or date at which the preparations are completed may be used as “time information” to perform the same processing as described above, or may not be used in this manner.

<Variation 1 (3)>

In the first embodiment, the server (10) may perform payment processing based on the time of code display and the time information of reading the code image for terminal display by the store code reader device (50), or may not do so.

In this case, as an example and not a limitation, in the processing of FIG. 4l, the control unit (51) of the store code reader device (50) reads the code image for the first extended terminal display at B350, and then accesses the server (10) via the communication I/F (54) at B360. Then, the control unit (51) transmits payment request information including at least the payment number and timestamp information acquired by decoding, the time at which the code image for the first extended terminal display was read by the store code reader device (50) (hereinafter referred to as “code reading time”), store identification information, and the expected payment amount to the server (10) via the communication I/F (54).

When payment request information is received from the store code reader device (50) via the communication I/F (14) (C160), the control unit (11) performs payment processing (C370). In this payment processing, the control unit (11) performs the following processing, as an example and not a limitation.

(A) First, it is determined whether the time difference between the time of the clock (19) of the server (10) (current time, time at the time of payment) and the code display time specified from the timestamp information included in the received payment request information is less than or equal to the first specified time.

(B) Second, it is determined whether the difference between the code reading time and code display time included in the received payment request information is less than or equal to the first stipulated time.

And, the control unit (11) determines that “payment is possible” when both conditions (A) and (B) above are met, as an example and not a limitation.

Also, here, the server (10) determines whether payment is possible based on the reading time (code reading time) of the code image for the first extended terminal display by the store code reader device (50), but it is not limited to this.

Specifically, as an example and not a limitation, the server (10) may determine whether payment is possible based on the time (payment request information transmission time) at which payment request information is transmitted to the server (10) by the store code reader device (50) as “visual information based on reading of a code image by a code reader device”, or may not do so.

In addition, as an example and not a limitation, as “visual information based on reading of a code image by a code reading device”, the server (10) may determine whether payment is possible based on the time at which payment request information is received from the store code reader device (50) (time at which payment request information is received), or it may not be necessary to do so.

In addition, as an example and not a limitation, the server (10) may determine whether payment is possible based on the time at which it recognizes that payment request information has been transmitted from the store code reader device (50) or the time at which information included in the received payment request information is identified, as “visual information based on reading of a code image by a code reader device”, or it may not be required to do so.

<Effect of Variation 1 (3)>

In this modified example, payment is performed based on the time information on the terminal (20) side and the time information of reading the code image for the first extended terminal display by the store code reader device (50) (not limited to, but an example of time information based on reading the first code image by the code reader device). This configuration is executed by the server (10).

As an example of the effect obtained by such a configuration, payment can be appropriately made by the server based on visual information based on reading of the first code image by the visual information and code reading device.

In addition, in this modified example, payment represents a configuration executed by the server (10) when the time information on the terminal (20) side and the reading time information of the code image for the first extended terminal display by the store code reader device (50) (not limited to, an example of time information based on the reading of the first code image by the code reading device) are within the expiration date set in the server (10).

As an example of the effect obtained by such a configuration, even if an error occurs in the visual information based on the reading of the first code image by the visual information and the code reading device, payment can be made after the server appropriately determines whether to pay based on the validity period set on the server.

In addition, in this modified example, the server (10) transmits a payment number (not limited to, but an example of the first information) to the terminal (20) via the communication I/F (14). Then, the server (10) receives, via the communication I/F (14), a payment number and time stamp information based on the first extended terminal display code image (not limited to, but an example of the first code image) read by the store code reader device (50) based on the payment number and time stamp information (not limited to, but an example of time information). Then, the server (10) shows a configuration in which payment is performed based on the code display time specified from the payment number and time stamp information and the code reading time by the store code reader device (50).

As an example of the effect obtained by such a configuration, the server can perform payment without error based on the first information, the visual information, and the visual information based on the reading of the first code image by the code reading device.

In addition, in the payment processing described above, the control unit (11) of the server (10) may determine whether to perform payment as follows, or may not do so.

(a) It is determined whether the time difference between the time of the clock (19) of the server (10) (current time, time at the time of payment) and the code display time specified from the timestamp information included in the received payment request information is less than or equal to the first specified time.

(b) It is determined whether the time difference between the time of the clock (19) of the server (10) (current time, time at the time of payment) and the time of reading the code included in the received payment request information is less than or equal to the first specified time.

And, the server (10) determines that “payment is possible” when the condition of (a) above is met, or when the condition of (a) above is not met but the condition of (b) is met.

By doing this, for example, when a specified time has elapsed from a time specified by visual information, but a specified time has not elapsed from the time of reading the first code image by the code reading device, payment can be made on the server.

<Variation 1 (4)>

It is possible to store one code acquired from the server (10) in an online state in the terminal display code stock data (2831) of the storage unit (28) of the terminal (20), but it is also possible to store multiple codes (2 or more) acquired from the server (10) in an online state.

By doing this, since multiple codes can be stored in the terminal (20), even if offline payments must be made multiple times, it becomes possible to proceed with the payment immediately, thereby improving user convenience.

<Variation 1 (5)>

In the first embodiment, the "first information" of the present invention is defined as a payment number or a terminal display code image including the payment number. However, this is not limiting. For example, a token, which is a type of authentication information, or a terminal display code image including the token may be referred to as the "first information" of the present invention.

In this case, rather than including the payment number in the code image for the extended terminal display, a token issued using a method (algorithm) for generating random tokens may be included in the code image for the extended terminal display, or it may not be necessary to do so. In this case, it is preferable that the server (10) store identification information for identifying the terminal (20) or the user of the terminal (20) in the storage unit (15) in association with the issued token.

A "token" is, by way of example and not limitation, a type of authentication information used by a server (10) to authenticate that a terminal (20) or a terminal (20) user is a regular terminal (20) or a regular terminal (20) user. "Authentication information" is information issued by a certification authority, and the above token functions as authentication information issued by the server (10) as a certification authority to authenticate a terminal (20) or a terminal (20) user.

Additionally, tokens can be expressed as, for example, "random tokens," "access tokens," or "payment tokens." Because tokens are issued randomly, as described above, each time a terminal display code is generated, a different token is generated. Therefore, tokens function as so-called one-time passwords.

In addition, the store code reader device (50) that reads the terminal display code image in addition to the payment number or token may include information such as a URL (Uniform Resource Locator) for accessing a payment page, which is a type of web page provided by the server (10), as an example of access information for accessing a website or web page provided by the server (10), or may not include such information.

<Variation 1 (6)>

In processing A130 of FIG. 3d, at the timing when the terminal (20) receives the terminal display code from the server (10), processing A240 and A250 may be performed to display the terminal display code on the display unit (24), or it may not be necessary to do so.

In addition, in processing A130 of FIG. 4l, at the timing when the terminal (20) receives the terminal display code from the server (10), processing A240 and A350 may be performed to display the first extended terminal display code on the display unit (24), or it may not be necessary to do so.

In this case, as an example and not a limitation, when a code icon is touched on the main screen of the payment application (e.g., FIG. 3b), the display may be switched to a code display screen for a terminal display code or a code display screen for a first extended terminal display code (e.g., FIG. 4j).

<Variation 1 (7)>

The display screen of the payment application described in the first embodiment is merely an example and can be appropriately designed and changed.

Figure 4m is a drawing showing an example of the main screen of the payment application displayed on the display unit (24) of the terminal (20) in this modified example.

This main screen displays a "Code (Offline) Icon" that is displayed separately from the "Code Icon" mentioned above, and is indicated as "Code (Offline)".

In this modified example, the “code icon” is an icon for displaying the code display screen in online state, and the “code (offline) icon” is an icon for displaying the code display screen in offline state.

FIG. 4n is a drawing showing an example of a code display screen displayed on the display unit (24) of the terminal (20) in this modified example. This code display screen is displayed when the code (offline) icon is touched on the main screen above.

This code display screen displays “Code (Offline)” at the top of the screen, and below that displays the same information as the code display screen of Fig. 4j.

In this display screen example, when it is detected that the terminal (20) is offline, an extended terminal display code is displayed on the code display screen according to user operation, and offline payment can be made using this extended terminal display code.

<Variation 1 (8)>

The code display screen described in the first embodiment is merely an example and can be appropriately designed and changed.

For example, due to limitations on the amount of information that can be stored in a code image, it may be difficult to encode both primary information and visual information. Therefore, it is also possible to generate and display two code images for extended terminal displays that encode these pieces of information separately.

Figure 4o is a drawing showing an example of a code display screen in this modified example.

In this code display screen, two code images, a two-dimensional second extended terminal display code image QC2 and a two-dimensional third extended terminal display code image QC3, are displayed side by side as code images for extended terminal display in this modified example.

The second extended terminal display code image QC2 is, by way of example and not limitation, a code image in which original information (in this example, a payment number) is encoded and stored in the terminal display code image received from the server (10) and stocked in the terminal (20).

The code image QC3 for the third extended terminal display is, by way of example and not limitation, a code image in which visual information (timestamp information in this example) generated on the terminal (20) side is encoded.

In addition, the arrangement of the code image QC2 for the second extended terminal display and the code image QC3 for the third extended terminal display on the code display screen of FIG. 4o is merely an example and can be appropriately changed. In addition to horizontal arrangement, they can also be arranged vertically or diagonally. Furthermore, the display positions of the two code images can be reversed.

In this modified example, in the code generation processing (X) for extended terminal display of FIG. 4l, the code generation processing unit (1111) for terminal display generates a second extended terminal display code image and a third extended terminal display code image.

Specifically, if a terminal display code image is stocked in the terminal display code stock data (2831), this is used as a second extended terminal display code image. On the other hand, if a payment number is stocked in the terminal display code stock data (2831), the payment number is encoded (encoded) and graphicized (imaged) to generate a second extended terminal display code image.

Additionally, based on the information displayed by the clock unit (29A), timestamp information including the code display time is generated. Then, the generated timestamp information is encoded and graphicized (imaged) to generate a code image for the third extended terminal display.

In addition, some stores may not support reading of two-dimensional codes, but may support reading of one-dimensional codes. In this case, the terminal display code generation processing unit (1111) may or may not generate a second extended terminal display code image and a third extended terminal display code image displayed as a one-dimensional code (a barcode, for example, but not limited to) in addition to a two-dimensional code (a QR code, for example, but not limited to), or may not generate such a code image.

When making an offline payment, the terminal (20) user presents the code display screen of FIG. 4o to the store employee by the code register (60) by the first code expiration date, and makes a payment by having the store code reader device (50) read the code image for the second extended terminal display and the code image for the third extended terminal display. In this case, the store code reader device (50) transmits payment request information including information obtained by decoding from the read second extended terminal display code image (a payment number in this example) and information obtained by decoding from the read third extended terminal display code image (timestamp information in this example) to the server (10), so that the server (10) makes the payment.

In addition, the second extended terminal display code image and the third extended terminal display code image are not limited to a method of reading them individually by the store code reader device (50), and based on detecting that the second extended terminal display code image and the third extended terminal display code image are within one frame of the code reader (58), the two extended terminal display code images may be read together (organized), or they may not be read in that manner.

<Effect of the first variation (8)>

In this modified example, the code image for extended terminal display (not limited to, an example of the first code image) represents a configuration including a code image for second extended terminal display (not limited to, an example of the second code image) displayed in one area of the code display screen (not limited to, an example of the first area) and a code image for third extended terminal display (not limited to, an example of the third code image) displayed in another area of the code display screen (not limited to, an example of the second area).

As an example of the effect obtained by such a configuration, by displaying a second code image based on the first information in a first area and a third code image based on visual information in a second area, for example, even when it is difficult to include visual information in the code image, the third code image can be read by an external reading device, thereby transmitting the visual information to the server and making a payment.

In addition, in addition to the above, as a non-limiting example, information such as the remaining time until the first code expiration date may be displayed based on information displayed by the clock section (29A) of the terminal (20) in a different area from the area where the code image for the extended terminal display is displayed, or it may not be necessary to do so.

<Example 2>

In the first embodiment, an example of a method for implementing offline payment was described. However, if there is a discrepancy between the time displayed on the clock unit (29A) of the terminal (20) and the time displayed on the clock unit (19) of the server (10), the above method may not be applicable as is.

Specifically, for example, if the time displayed in the clock section (29A) of the terminal (20) differs from the time displayed in the clock section (19) of the server (10) due to an accumulation of errors, or if the user is in a foreign country and the time of the terminal (20) differs from the standard time of Japan, there is a possibility that the above method cannot be applied as is.

In addition to this type of time error, there is also a risk that a malicious user may manipulate the time of his/her terminal (20) to return it to a past time, thereby causing an unfair payment to be made to the server (10).

The contents described in the second embodiment can be applied to any of the other embodiments or any of the other modified examples.

Additionally, the same symbols are given to components that are identical to those in the previous example and further explanation is omitted.

FIG. 5a is a diagram showing an example of information stored in a storage unit (28) of a terminal (20) in this embodiment.

In this embodiment, terminal data (289) includes terminal setting data (2891). In addition, terminal setting data (2891) includes, as an example and not a limitation, time adjustment setting data (2892).

The time adjustment setting data (2892) is setting data regarding the clock section (29A) of the terminal (20), and as an example and not a limitation, information indicating whether the setting for automatically adjusting the time of the clock section (29A) in the terminal (20) (hereinafter referred to as “time automatic adjustment”) has been made (e.g., the time automatic adjustment setting “ON”/“OFF” on the terminal (20) side) is stored.

As a method for automatic time adjustment, examples that can be applied include, but are not limited to, a method using a time synchronization protocol such as NTP, or a method of synchronizing the time using a satellite positioning system such as GPS.

<Processing>

Fig. 5b is a flowchart illustrating an example of a processing flow executed by each device in this embodiment. From left to right, the diagrams illustrate a second payment application processing, which is an example of payment application processing executed by the control unit (21) of the terminal (20), a first store payment processing, which is an example of store payment processing executed by the control unit (51) of the store code reader device (50), and a first payment management processing, which is an example of payment management processing executed by the control unit (11) of the server (10).

The flowchart of Fig. 5b is the flowchart of Fig. 4l with the addition of step A445.

After A240, in an offline state, if a code display operation is performed by a terminal (20) user, for example and not limitation, the control unit (21) refers to the time adjustment setting data (2892) of the storage unit (28) to determine whether the time automatic adjustment setting is set to "ON" (A445). If it is determined to be "ON" (A445: Yes), the control unit (21) moves the processing to A350.

Meanwhile, if it is determined that the setting of automatic visual adjustment is not set to “ON” (is set to “OFF”) (A445: No), the control unit (21) does not perform the processing after A350 and ends the processing of the second payment application.

<Effect of the second embodiment>

In the second embodiment, the terminal (20) performs the setting of the automatic time adjustment of the clock section (29A) (not limited to, but an example of the setting related to automatic time adjustment of the terminal). In addition, the code image for the first extended terminal display (not limited to, but an example of the first code image) indicates a configuration displayed on the display section (24) when the setting of the automatic time adjustment is set to "ON".

As an example of the effect achieved by this configuration, settings for automatic time adjustment of the terminal can be performed on the terminal. Furthermore, the first code image is displayed in the display area based on the settings for automatic time adjustment. Therefore, for example, if the settings for automatic time adjustment are configured, the first code image can be displayed on the terminal to enable payment. However, if the settings for automatic time adjustment are not configured, the first code image can be prevented from being displayed on the terminal and payment can be made. This allows for appropriate payment to be processed on the server even in cases where there is a discrepancy between the terminal's time and the server's time, or in cases where the terminal user engages in fraudulent activity.

<Variation 2 (1)>

In the second embodiment, when making an offline payment, the terminal (20) may or may not provide a notification to the terminal (20) user to confirm whether automatic time adjustment is turned “ON”.

FIG. 5c is a drawing showing an example of a function realized by the control unit (21) of the terminal (20) in this modified example.

The payment application processing unit (211) of the control unit (21) includes, as a functional unit, a code generation processing unit (2111) for extended terminal display and a code display processing unit (2113), and, as an example and not a limitation, a time automatic adjustment confirmation notification processing unit (2114).

The automatic time adjustment confirmation notification processing unit (2114) has a function of notifying the user of its terminal (20) to confirm whether the setting of the clock unit (29A) is automatic time adjustment.

In this case, the automatic time adjustment confirmation notification processing unit (2114) displays, on the display unit (24), a confirmation screen for automatic time adjustment that includes a message for confirming to the terminal (20) user whether the setting for automatic time adjustment is “ON”, prior to A445 of the processing of FIG. 5b, as an example and not a limitation.

By doing this, when making an offline payment, the terminal user can be informed of the terminal's automatic time adjustment settings. In this case, for example, if the automatic time adjustment setting is set to "OFF," the terminal user can set the automatic time adjustment setting to "ON." This allows the first code image to be displayed on the display unit (24) and read by a code reader, thereby allowing payment to be made to the server (10).

<Variation 2 (2)>

In addition to the method described in the second embodiment, it is also possible to use the following method as an example and not as a limitation.

FIG. 5d is a drawing showing an example of information stored in the storage unit (28) of the terminal (20) in this modified example.

In the payment application data (283) of the storage unit (28), in addition to the terminal display code stock data (2831), as an example and not a limitation, reference time data (2834) and output time data (2835) are stored.

In this modified example, the control unit (21) of the terminal (20) requests the server (10) to transmit time information from the server (10) in an online state as a function of the payment application, for example and not limitation, and acquires time information from the server (10). Alternatively, time information is automatically transmitted from the server (10) to the terminal (20) at regular timings (e.g., once a day) or at specific timings (e.g., when the payment application is started).

The control unit (21) stores the time information acquired from the server (10) as “reference time information” and as reference time data (2834) in the payment application data (283). That is, the reference time information is stored within the payment application. Then, the control unit (21) calculates the current time by counting the time from the time indicated by the reference time information (hereinafter referred to as “reference time”) within the payment application (in the background when the payment application is not running), and stores the calculated time data (2835) in the payment application data (283) as the calculated time information.

In this case, the control unit (21), even when in an offline state, calculates the current time by counting the time from the reference time. Then, in the code generation process (X) (A350) for the extended terminal display of Fig. 4l, a first extended terminal display code image including the most recent calculated time information stored in the calculated time data (2835) is generated.

Here, calculating the time within the payment application is because, as described above, there may be cases where a malicious user may fraudulently perform a payment by reverting the time of his/her terminal (20) to a past time, etc., but in such cases, the clock on the OS (Operating System) side of the terminal (20) is easily manipulated. That is, in this modified example, when performing an offline payment, processing is performed based on time information calculated based on reference time information within the payment application, rather than using time information on the OS side.

In addition, since it is assumed that the user of the terminal (20) is in a foreign country, as an example and not a limitation, time information including time zone information may be transmitted from the server (10) to the terminal (20), or it may not be necessary to do so.

In addition, although the current time is calculated based on the reference time information within the payment application here, it is possible to correct the time displayed in the clock unit (29A) based on the reference time information, or to perform a process to synchronize the time displayed in the clock unit (29A) with the time displayed by the clock unit (19) of the server (10), or it is not necessary to do so.

This modified example shows a configuration in which a terminal (20) acquires time information (not limited to, but an example of information regarding a reference time) managed by a server (10) through a control unit (21). Furthermore, the terminal (20) performs offline payment processing based on time information calculated based on the acquired time information.

As an example of the effect obtained by such a configuration, the terminal processes information based on information about the reference time acquired from the server by the control unit as time information, thereby enabling the server to appropriately make a payment even if there is an error between the time of the terminal and the time of the server, or if the terminal user has committed fraud.

<Example 3>

As described above, the terminal display code image is an image displayed on the display unit (24) of the terminal (20). Therefore, there is a risk of fraud (abuse), such as, for example, a malicious third party taking a picture of the terminal display code image displayed on the display unit (24) of another person's terminal (20) with a camera, stealing the terminal display code image, and making a payment using the stolen terminal display code image.

In addition, in online payments, if a short period of time (e.g., "5 minutes") is set as the time during which the terminal display code can be used for payment (the aforementioned specified time), the terminal display code can only be used for that short period of time, so it is thought that the possibility of the terminal display code being stolen by hackers or the like is low.

However, in offline payment, as described above, a terminal display code is acquired from a server (10) in an online state, stored in a terminal (20), and when payment is required in an offline state, the stored terminal display code can be read and used. Therefore, since the terminal display code can be stored in the terminal (20) for a long period of time, there is a risk that the terminal display code may be stolen by hackers or the like and used for fraudulent payment.

Additionally, depending on the user, the terminal display code image displayed on the user's terminal (20) may be preserved by means of a screenshot, etc. In this case, it is assumed that the user (the first user) has requested the server (10) to update the terminal display code (hereinafter, appropriately referred to as "refresh"). Then, the server (10) deletes the association between the payment number of the terminal display code and the first user.

However, since payment numbers are finite, there is a possibility that the same payment number may be associated with another user's (second user's) account at some point in the future. In this case, if the first user makes a payment using a terminal display code image saved through a screenshot or similar, the payment number will already be associated with the second user's account, resulting in the payment being processed from that user's account. This process of making a payment from another account based on a code with the same payment number is called "code reuse."

The contents described in the third embodiment can be applied to any of the other embodiments or any of the other modified examples.

Additionally, the same symbols are given to components that are identical to those in the previous example and further explanation is omitted.

FIG. 6a is a drawing showing an example of the main screen of a payment application displayed on the display unit (24) of a terminal (20) in this embodiment.

The configuration of this main screen is the same as that of Fig. 3b, and here, the state in which the “code icon” is touched by the user of the terminal (20) is displayed.

FIG. 6b is a drawing showing an example of a code display screen displayed on the display unit (24) of the terminal (20) in this embodiment.

In this code display screen, as the code images for the extended terminal display in this embodiment, a one-dimensional fourth extended terminal display code image displayed as a barcode and a two-dimensional fourth extended terminal display code image QC4 displayed as a QR code are displayed in different areas within the display screen. In addition, a payment number displayed as a 12-digit number is displayed below the one-dimensional fourth extended terminal display code image.

The code image for the 4th extended terminal display (not limited to, but an example of a first code image based on the first information and second information different from the first information) is a code image in which the original information (in this example, a payment number) stored in the code image for the terminal display received from the server (10) and stocked in the terminal (20) and identification information (in this example, an application ID) for identifying the terminal (20) or the user of the terminal (20) are encoded.

Identification information for identifying a terminal (20) or a user of the terminal (20) is an example of second information different from the first information.

In this embodiment, the code image for the fourth extended terminal display is generated by the extended terminal display code generation processing unit (2111) of the control unit (21) based on the payment number acquired from the server (10) in an online state and stored in the storage unit (28) and the application ID stored in the storage unit (28).

When making an offline payment, the terminal (20) user presents the code display screen of Fig. 6b to the code register (60) to the store employee and makes the payment by having the store code reader device (50) read the code image for the fourth extended terminal display. In this case, the store code reader device (50) transmits payment request information including information (in this example, the payment number and application ID) acquired by decoding from the read code image for the fourth extended terminal display to the server (10), so that the server (10) makes the payment.

In addition, as described in the first embodiment and elsewhere, if a code usage period (code display period) is to be determined, time information also needs to be included in the code image for extended terminal display. In this case, as an example and not a limitation, it is preferable for the terminal (20) to generate a fourth extended terminal display code image that encodes time information (timestamp information, code display time, etc.) in addition to the payment number and application ID.

Fig. 6c is a flowchart illustrating an example of a processing flow executed by each device in this embodiment. From left to right, the diagrams illustrate the third payment application processing, which is an example of payment application processing executed by the control unit (21) of the terminal (20), the first store payment processing, which is an example of store payment processing executed by the control unit (51) of the store code reader device (50), and the first payment management processing, which is an example of payment management processing executed by the control unit (11) of the server (10).

The flowchart of Fig. 6c is a description in which step A350 in the flowchart of Fig. 4l is rewritten as A550, step B350 as B550, step B360 as B560, step C120 as C520, step C160 as C560, and step C370 as C570.

After C110, the control unit (11) performs a process for generating a code for terminal display (C520). Specifically, the control unit (11) generates a code image for terminal display that includes, as an example and not a limitation, at least a payment number as raw information. More specifically, the control unit (11) generates a code image for terminal display that represents at least a two-dimensional code (e.g., a QR code) by encoding and graphicizing the payment number. In addition, the control unit (11) associates identification information (e.g., an application ID) for identifying the terminal (20) or the terminal (20) user included in the received code generation request information with the generated payment number and stores it in the storage unit (15).

After A240, in an offline state, as an example and not a limitation, when a code display operation is performed by a terminal (20) user, the code generation processing unit (2111) for extended terminal display performs code generation processing (Y) for extended terminal display, and the code display processing unit (2113) performs code display processing (Y) (A550).

In the code generation process (Y) for extended terminal display, as an example and not a limitation, a fourth extended terminal display code image including a payment number and an application ID is generated based on information acquired by decoding from a terminal display code image stored (stocked) in terminal display code stock data (2831). In this case, as described above, time information (time stamp information, code display time, etc.) may also be included.

In addition, the identification information for identifying the terminal (20) or the terminal (20) user is not limited to the application ID, and as an example that is not limited thereto, the terminal identification information for identifying one's own terminal (20) (e.g., terminal ID) or the user identification information for identifying one's own terminal (20) (e.g., user ID) may be used, or may not be used.

Additionally, to prevent third parties from deciphering information stored in the code image for the 4th extended terminal display, the payment number or identification information may be encoded or not.

In addition, in the code display processing (Y), as an example and not a limitation, a code display screen in which the payment number and the code image for the 4th extended terminal display are displayed in different areas is displayed on the display unit (24).

In addition, in the case where a two-dimensional fourth extended terminal display code image is generated in the code generation process (Y) for extended terminal display, as an example and not a limitation, the two-dimensional extended terminal display code image can be displayed.

In addition, in the code generation process (Y) for extended terminal display, if a one-dimensional fourth extended terminal display code is also generated, as an example and not a limitation, in addition to a two-dimensional fourth extended terminal display code image, a one-dimensional fourth extended terminal display code image can be displayed.

After that, when the code image for the 4th extended terminal display displayed on the display unit (24) is presented to a store employee or the like by a user of the terminal (20), the control unit (51) performs control to have the code reader (58) read the code image for the 4th extended terminal display displayed on the display unit (24) of the terminal (20) (B550).

Thereafter, the control unit (51) accesses the server (10) via the communication I/F (54). Then, the control unit (51) transmits payment request information including at least the payment number and application ID acquired by decoding, store identification information, and the payment amount to be paid to the server (10) via the communication I/F (54) (B560).

When payment request information is received from the store code reader device (50) by the communication I/F (14) (C560), the control unit (11) performs payment processing (C570).

Specifically, it is determined whether the payment number included in the received payment request information is stored in the code management data (159) in association with the application ID. If it is determined to be stored, it is determined whether the combination of the payment number and application ID that can be associated with it matches the combination of the payment number and application ID included in the received payment request information. If they match, it is determined that "payment is possible," and the payment amount is deducted from the balance stored in the payment management data of the application ID to make the payment.

In addition, in the above payment processing, rather than determining that “payment is possible” when the combination of the stored payment number and application ID matches the combination of the payment number and application ID included in the received payment request information, it may be determined that “payment is possible” when the stored application ID matches the application ID included in the received payment request information, or it may not be determined that “payment is possible”.

<Effect of the Third Example>

According to the third embodiment, it is possible to prevent the terminal display code from being stolen by hackers or the like and used for fraudulent payment, or the code from being reused, for example, due to the terminal display code being stored in the terminal (20) for a long period of time.

Specifically, in the third embodiment, the terminal (20) receives a payment number (not limited to, an example of the first information) transmitted from the server (10) by the communication I/F (22). Then, the terminal (20) stores the payment number received by at least the control unit (21) in the storage unit (28). In addition, the terminal (20) displays a fourth extended terminal display code image (not limited to, an example of the first code image) based on the received payment number and application ID (not limited to, an example of second information different from the first information) in one area of the code display screen (not limited to, an example of the display area). Then, the payment represents a configuration that is executed by the server (10) based on the payment number and application ID received by the server (10) based on the fourth extended terminal display code image.

As an example of the effect obtained by such a configuration, first information transmitted from a server is stored in the storage of the terminal, and a first code image based on the first information and second information different from the first information is displayed in the display area of the terminal. Then, payment is executed by the server based on the first information and second information received by the server based on the display of the first code image. Therefore, for example, the server can perform offline payment based on the second information and the first information previously stored in the storage of the terminal, thereby improving convenience for the terminal user.

Additionally, the third embodiment shows a configuration in which the code image for the fourth extended terminal display (not limited to, but an example of the first code image) is one code image based on the payment number and application ID.

As an example of the effect obtained by such a configuration, payment can be easily made by simply having an external code reader read a single code image displayed in the display area of the terminal by displaying a single code image based on the first information and the second information.

In addition, in the third embodiment, payment is performed based on the code image for the fourth extended terminal display being read by a code reading device such as a store, and the payment number and application ID are transmitted to the server (10), and the configuration is executed by the server (10) based on the payment number and application ID.

As an example of the effect obtained by such a configuration, payment is executed on the server based on the first information and the second information by sending the first information and the second information to the server based on the first code image being read by the code reading device, so that payment can be easily made to the server based on the first code image displayed in the display area of the terminal.

In addition, in the third embodiment, the payment is configured to be executed by the server (10) based on an application ID (not limited to, but an example of the second information) received from the server (10) and an application ID (not limited to, but an example of the third information) stored in the storage (15) of the server (10) and associated with a payment number.

As an example of the effect obtained by such a configuration, payment can be easily and appropriately made to the server based on the second information and the third information stored on the server and related to the first information.

In addition, in the third embodiment, the payment is executed by the server (10) when the application ID (not limited to, but an example of the second information) received from the server (10) matches the application ID (not limited to, but an example of the third information) associated with the payment number stored in the storage (15) of the server (10).

As an example of the effect obtained by this configuration, if the second information and the third information match, payment can be made to the server without error because the payment is executed by the server.

Additionally, in the third embodiment, the identification information for identifying the terminal (20) or the terminal (20) user represents a configuration of an application ID, a terminal ID, or a user ID.

As an example of the effect obtained by such a configuration, by using identification information for identifying a terminal or terminal user as the second information, it is possible to confirm to the server whether the terminal or terminal user scheduled for payment is a legitimate terminal or legal terminal user.

In addition, the third embodiment has a processor that reads a payment application program (282) from a memory storing a payment application program (282) (not limited to, but an example of a program) of a terminal (20) and executes payment application processing based on the payment application program (282). Then, the processor receives a payment number (not limited to, but an example of the first information) transmitted from a server (10) through a communication I/F (22), stores the received payment number in a storage unit (28), and displays a fourth extended terminal display code image (not limited to, but an example of the first code image) based on the payment number and the application ID (not limited to, but an example of second information different from the first information) in one area of a code display screen (not limited to, but an example of a display area of the terminal). And, payment is a configuration executed by the server (10) based on the payment number and application ID received by the server (10) based on the display of the code image for the 4th extended terminal display.

As an example of the effect obtained by such a configuration, for example, convenience of the terminal user can be improved by enabling the server to perform offline payment based on the second information and the first information previously stored in the terminal's storage.

In addition, in the third embodiment, the server (10) transmits a payment number (not limited to, but an example of the first information) to the terminal (20) via the communication I/F (22). In addition, the server (10) receives a payment number and an application ID based on the first code image transmitted from the store code reader device (50) based on a fourth extended terminal display code image (not limited to, but an example of the first code image) based on the payment number and the application ID (not limited to, but an example of the second information different from the first information) displayed in one area (not limited to, but an example of the display area) of the code display screen of the terminal (20), which is read by the store code reader device (50), via the communication I/F (14). And, the server (10) stores the payment number, application ID, and code management data (159), and shows a configuration that performs payment based on the application ID associated with the payment number (not limited to, an example of third information associated with the first information and stored in the storage section of the server).

As an example of the effect obtained by such a configuration, the server can perform payment without error based on first information, second information, and third information stored in the storage of the server and related to the first information.

<Third Variation (1)>

In the third embodiment, the "second information" of the present invention is information such as terminal identification information (e.g., terminal ID) for identifying the terminal (20), user identification information (e.g., user ID) for identifying the user of the terminal (20), or account information of the payment application (e.g., application ID), but is not limited thereto. For example, a randomly generated number (hereinafter referred to as a "special number") different from the aforementioned payment number (first information), or a token (hereinafter referred to as a "special token") different from the aforementioned token may be issued by the terminal (20), and these pieces of information may be used as the "second information", or may not be used.

In this case, as an example and not a limitation, when sending code generation request information from a terminal (20) to a server (10) in an online state, the above-mentioned special number or special token is sent to the server (10). In addition, the server (10) may store the special number or special token received from the terminal (20) and the payment number in association with each other during the terminal display code generation process. Alternatively, in addition to the application ID and the payment number, the special number or special token received from the terminal (20) may be stored in association with each other.

In addition, as an example and not a limitation, the above-mentioned special number or special token may be issued by the server (10) and transmitted to the terminal (20), or it may not be necessary to do so. In this case, the server (10) may store the issued special number or special token in association with the payment number during the terminal display code generation process. Alternatively, the server may store the issued special number or special token in association with the application ID and payment number.

In this case, the server (10) may generate a terminal display code image encoding a special number or special token and transmit it to the terminal (20), or may not do so.

In addition, the special number or special token may not be included in the terminal display code image, and the server (10) may transmit the special number or special token to the terminal (20) separately from the terminal display code in which the payment number is encoded, or may not do so.

Here, the above-mentioned special number must be different from the payment number. Therefore, as an example, but not a limitation, the special number can be a number with fewer digits than the payment number. For example, if the payment number is 10 to 12 digits, the special number can be a number with fewer than 10 digits (e.g., 6 to 9 digits).

Additionally, as previously mentioned, a token may be included in the terminal display code or extended terminal display code instead of the payment number. In this case, the token included in the terminal display code or extended terminal display code and the special token mentioned above must be different.

<Effect of the third variation (1)>

This modified example shows a configuration in which a special number or special token (not limited to, but an example of the second information) is generated by the terminal (20) and transmitted to the server (10).

As an example of the effect obtained by such a configuration, the terminal can make a payment to the server based on the generated second information.

In addition, in this modified example, a special number or a special token (not limited to, but an example of the second information) is shown as a configuration in which it is sent from the server (10) to the terminal (20).

As an example of the effect obtained by this configuration, the terminal can easily obtain second information from the server.

In addition, this modified example shows a configuration in which the special number (not limited to, but an example of the second information) is code information of a number different from the payment number (not limited to, but an example of code information different from the first information), and the special token (not limited to, but an example of the second information) is code information different from the token (not limited to, but an example of code information different from the second information).

As an example of the effect obtained by such a configuration, by using code information different from the first information as the second information, payment can be made to the server without error.

<Third Variation (2)>

In addition to the method described in the third embodiment, the following method may be used.

Specifically, the terminal (20) transmits code generation request information to the server (10) when it is online at regular timings (e.g., once every 3 hours, once every 6 hours, once every 12 hours, once a day), and receives a terminal display code from the server (10). Then, from the received terminal display code, the terminal display code stored in the terminal display code stock data (2831) is updated (refreshed).

Additionally, at a specific timing, a terminal display code may be acquired from the server (10) and refreshed. Specifically, as an example and not a limitation, when the elapsed time since the previous payment application was executed on the terminal (20) exceeds a set time, the terminal (20) automatically acquires a terminal display code from the server (10) and refreshes the terminal.

In addition, it is possible to display an operation image, such as a refresh button or a refresh icon, on the display screen of the payment application, and enable the terminal (20) user to obtain a terminal display code from the server (10) and refresh the terminal at any time while online by manipulating these operation images. In this case, for example, if the terminal (20) user feels in danger, the operation image can be manipulated to perform a refresh.

<Third Variation (3)>

The visual information described in the first embodiment and the first modified example may be included in the second extended terminal display code together with identification information such as an application ID, or may not be included. In this case, the contents described in the first embodiment and the contents described in the first modified example (1) to the first modified example (5) may be applied, respectively.

<Third Variation (4)>

The code display screen described in the third embodiment is merely an example and can be appropriately designed and changed.

For example, due to limitations on the amount of information that can be stored in a code image, it may be difficult to encode both the first information and the second information. Therefore, it is also possible to generate and display two code images for extended terminal displays that encode these pieces of information separately.

Figure 6d is a drawing showing an example of a code display screen in this modified example.

In this code display screen, two code images are displayed side by side as code images for extended terminal display: a two-dimensional fifth extended terminal display code image QC5 and a two-dimensional sixth extended terminal display code image QC6.

The code image QC5 for the fifth extended terminal display is, by way of example and not limitation, a code image in which the original information (in this example, a payment number) stored in the code image for the terminal display received from the server (10) and stocked in the terminal (20) is encoded.

The code image QC6 for the 6th extended terminal display is, by way of example and not limitation, a code image in which identification information (in this example, an application ID) for identifying a terminal (20) or a user of the terminal (20) is encoded.

In addition, the arrangement of the code image QC5 for the fifth extended terminal display and the code image QC6 for the sixth extended terminal display on the code display screen of FIG. 6d is merely an example and can be appropriately changed. In addition to horizontal arrangement, they can also be arranged vertically or diagonally. Furthermore, the display positions of the two code images can be reversed.

In this modified example, in the code generation process (Y) for extended terminal display of FIG. 6c, the code generation process unit (1111) for terminal display generates a fifth extended terminal display code image and a sixth extended terminal display code image.

Specifically, if a terminal display code image is stocked in the terminal display code stock data (2831), this is used as the 5th extended terminal display code image. On the other hand, if a payment number is stocked in the terminal display code stock data (2831), the payment number is encoded (encoded) and graphicized (imaged) to create a 5th extended terminal display code image.

In addition, the application ID stored in the storage unit (28) is encoded and graphicized to create a code image for the 6th extended terminal display.

In addition, some stores may not support reading of two-dimensional codes, but may support reading of one-dimensional codes. In this case, the terminal display code generation processing unit (1111) may or may not generate a second extended terminal display code image and a sixth extended terminal display code image displayed as a one-dimensional code (a barcode, for example, but not limited to) in addition to a five-dimensional code (a QR code, for example, but not limited to), or may not generate such a configuration.

When making an offline payment, the terminal (20) user presents the code display screen of Fig. 6d to the store employee using the code register (60), and makes a payment by having the store code reader device (50) read the code image for the fifth extended terminal display and the code image for the sixth extended terminal display. In this case, the store code reader device (50) transmits payment request information including information obtained by decoding from the read code image for the fifth extended terminal display (a payment number in this example) and information obtained by decoding from the read code image for the sixth extended terminal display (an application ID in this example) to the server (10), so that the server (10) makes a payment.

In addition, the code image for the 5th extended terminal display and the code image for the 6th extended terminal display are not limited to the method of being read individually by the store code reader device (50), and based on detection that the code image for the 5th extended terminal display and the code image for the 6th extended terminal display are within one frame of the code reader (58), the two code images for the extended terminal display may be read together (organized), or they may not be read in that manner.

<Effect of the third variation (4)>

This modified example shows a configuration in which a code image for extended terminal display (not limited to, an example of the first code image) includes a code image for fifth extended terminal display (not limited to, an example of the second code image) displayed in one area of the code display screen (not limited to, an example of the first area) and a code image for sixth extended terminal display (not limited to, an example of the third code image) displayed in another area of the code display screen (not limited to, an example of the second area).

As an example of the effect obtained by such a configuration, by displaying a second code image based on the first information in a first area and displaying a third code image based on the second information in a second area, even when it is difficult to include the second information in the code image, for example, by reading the third code image with an external reading device, the second information can be sent to the server to make a payment.

In addition to the above, as an example and not a limitation, identification information such as an application ID may or may not be displayed in an area different from the area where the code image for the extended terminal display is displayed.

<Example 4>

The fourth embodiment is an embodiment of supplementing a terminal display code according to the establishment of a predetermined condition, with respect to the content of storing and stocking a terminal display code transmitted from a server (10) in a storage unit (28) of a terminal (20).

The contents described in the fourth embodiment can be applied to any of the other embodiments or any of the other modified examples.

Additionally, the same symbols are given to components that are identical to those in the previous example and further explanation is omitted.

FIG. 7a is a diagram showing an example of information stored in a storage unit (28) of a terminal (20) in this embodiment.

In this embodiment, the payment application data (283) includes, as an example and not a limitation, code supplement condition data (2838).

Code supplement condition data (2838) is data in which conditions for supplementing a terminal display code (hereinafter referred to as “code supplement condition”) are set, and an example of the data configuration is shown in Fig. 7b.

In the code supplement condition data (2838), as an example and not a limitation, the condition type, condition No, and code supplement condition are stored in association with each other.

The condition type is the type of code supplementary condition, and as non-limiting examples, "CP1 (Communication)" and "CP2 (Other)" are included here.

Condition No is the number of the code supplementary condition included in that condition type.

The code supplement condition is the content of the code supplement condition corresponding to that condition No.

Explain in detail.

(A) Condition type “CP1 (communication)”

For the condition type "CP1 (communication)", the conditions "CP1-1" to "CP1-3" are set as examples, not as limitations.

"CP1-1" is a condition that sets the code supplement condition to "offline payment and receipt of terminal payment completion notification." This is a condition indicating that a terminal display code is supplemented when offline payment is performed by the server (10), the terminal (20) returns from an offline state to an online state, and a terminal payment completion notification is received from the server (10). That is, using the terminal display code acquired from the server (10) and stored in the terminal display code stock data (2831), a terminal display code different from the terminal display code acquired from the server (10) is acquired based on the completion of offline payment by the server (10).

In this case, as an example and not a limitation, offline payment is made by the server (10), and after receiving a payment completion notification for the terminal from the server (10), a request requesting a terminal display code is transmitted from the terminal (20) to the server (10), and upon receiving the request, the terminal display code transmitted from the server (10) can be stored in the terminal display code stock data (2831).

In addition, even if a terminal payment completion notification is received from the server (10) after returning from an offline state to an online state, there are cases where the communication status of the terminal (20) is unstable. Therefore, after receiving a terminal payment completion notification from the server (10), the terminal display code may be requested and acquired from the server (10) at a timing when communication is turned "ON" or at a timing when the communication status is stable, or it may not be necessary to do so.

"CP1-2" is a condition that sets the code supplementation condition to "launching the payment application and establishing communication with the server." This is a condition indicating that a terminal display code is supplemented when the payment application is launched on the terminal (20) and a communication connection is established with the server (10).

In this case, as an example and not a limitation, when a payment application is launched on a terminal (20) and a communication connection is established with a server (10), a request requesting a terminal display code is transmitted from the terminal (20) to the server (10). Then, the terminal (20) can store the terminal display code transmitted from the server (10) in terminal display code stock data (2831) according to the request.

In addition, in the above, when the payment application is launched in the terminal (20) and a communication connection is established with the server (10), a request is transmitted from the terminal (20) to the server (10) requesting a terminal display code and the latest balance. Then, the terminal (20) may store the terminal display code transmitted from the server (10) in the terminal display code stock data (2831) in response to the request, and may also update the balance stored in the payment application data (283) of the terminal (20) based on the latest balance transmitted from the server (10) in response to the request, or may not do so.

“CP1-3” is a condition that sets the code supplement condition as “change in electromagnetic environment.”

Also, since radio waves are generally used for communication, it may be referred to as "change in radio wave environment." It may also be referred to as "change in communication environment." This is a condition indicating that a terminal display code is supplemented when the electromagnetic wave environment of the terminal (20) changes.

As an example and not a limitation, the electromagnetic environment of the terminal (20) is divided into three types: “strong electromagnetic environment,” “medium electromagnetic environment,” and “weak electromagnetic environment” based on the intensity of the electromagnetic wave (intensity of the radio wave). Here, the intensity of the electromagnetic wave can be expressed as an index value such as an electric field intensity, a magnetic field intensity, and a power density (power flux density), as an example and not a limitation. These index values can also be referred to as the intensity of the signal received at the terminal (20) (signal intensity, received signal intensity).

As an example and not a limitation, in the case where the electromagnetic environment of the terminal (20) is detected to have changed from a “medium electromagnetic environment” to a “weak electromagnetic environment” based on the intensity of the electromagnetic waves, since there is a possibility of going offline, the terminal display code may be supplemented. In this case, as an example and not a limitation, when a change in the electromagnetic environment is detected, a request requesting a terminal display code may be transmitted from the terminal (20) to the server (10), and upon receiving the request, the terminal display code transmitted from the server (10) may be stored in the terminal display code stock data (2831).

In addition, the determination of changes in the above-mentioned electromagnetic environment may be performed based on the intensity of the electromagnetic wave indicated by the above-mentioned index value, or may not be performed in this manner. For example, a threshold intensity corresponding to a weak electric field may be set for the intensity of the electromagnetic wave, and when the intensity of the electromagnetic wave becomes lower than the threshold intensity (or lower than the threshold intensity), it may be determined that the electric field environment has changed, or may not be performed in this manner.

(B) Condition type “CP2 (Other)”

For the condition type "CP2 (Other)", the conditions "CP2-1" to "CP2-3" are set as examples, not as limitations.

"CP2-1" is a condition that sets the code supplement condition to "reception of push notification and detection of code supplement operation." Push notification refers to, by way of example and not limitation, a notification for confirming the stock of terminal display codes transmitted from the server (10) at regular timings, or a notification for confirming the user's desire to acquire a terminal display code. This is a condition indicating that a terminal display code is supplemented when the terminal (20) receives a push notification from the server (10) and, based on the received push notification, detects an operation for supplementing a terminal display code to the input section by the terminal (20) user (hereinafter referred to as a "code supplement operation").

"CP2-2" is a condition that sets the code supplement condition to "code supplement operation detection." This is a condition that indicates that a code for terminal display is supplemented when a code supplement operation to the input section by a terminal (20) user is detected.

"CP2-3" is a condition that sets the code supplementation condition as "detection of a balance update operation." This condition indicates that a terminal display code is supplemented when an operation to update the balance available for payment using a payment application (hereinafter referred to as a "balance update operation") by a terminal (20) user is detected.

While offline, the terminal (20) cannot communicate with the server (10). Therefore, when an offline payment is made, the balance managed by the server (10) is updated. However, until the terminal returns to the online state and a payment completion notification for the terminal is received from the server (10), the balance stored on the terminal (20) is not updated. Therefore, the balance displayed on the payment application's application screen may not be the most recent balance.

There, under the condition of "CP2-3", when the terminal (20) detects a balance update operation in the input section by the user while the payment application is running, it transmits a request to the server (10) requesting a terminal display code. Then, upon receiving the request, it stores the terminal display code transmitted from the server (10) in the terminal display code stock data (2831).

In addition, the condition for replenishing the code of "CP2-3" may be set to "execute balance update", and the terminal (20) may communicate with the server (10) and update the balance based on the detection of a balance update operation within the payment application, thereby replenishing the terminal display code, or it may not be necessary to do so.

In addition, as described above, when the terminal (20) returns from an offline state to an online state, it receives a terminal payment completion notification from the server (10). In this case, the terminal (20) may update its balance based on the terminal payment completion notification received, and may supplement the terminal display code based on the execution of this balance update, or may not do so.

The control unit (21) of the terminal (20) determines, based on the code supplement condition data (2838), whether at least one of the above-described multiple code supplement conditions has been met, for example and not limitation. If it determines that the condition has been met, it transmits a request to the server (10) requesting a terminal display code. Upon receiving the request, it stores the terminal display code transmitted from the server (10) in the terminal display code stock data (2831).

In addition, the above code supplement conditions are merely examples, and conditions other than these may be set.

Additionally, as an example and not a limitation, a condition combining two or more of the above code supplement conditions may be set as a code supplement condition.

In addition, as an example and not a limitation, it is also possible to set the terminal (20) user to select which of the above code supplement conditions to apply.

<Effect of Example 4>

In the fourth embodiment, the terminal (20) receives, through the communication I/F (22), a payment number (not limited to, an example of the first information) different from the payment number, based on the completion of payment by the server (10) based on the payment number (not limited to, an example of the first information) acquired from the server (10) in an offline state in advance (not limited to, an example of the second information different from the first information). In addition, the terminal (20) is configured to store the received payment number in the storage unit (28).

As an example of the effect obtained by such a configuration, even if the first information is consumed by the completion of payment based on the first information, the terminal receives second information different from the first information and stores it in the storage unit, thereby making it possible to make a separate payment based on the stored second information, thereby improving user convenience.

In addition, the fourth embodiment shows a configuration in which the terminal (20) receives a payment number different from the above payment number through the communication I/F (22) based on the communication status of the communication I/F (22).

As an example of the effect obtained by such a configuration, the terminal can receive second information different from the first information through the communication unit, for example, when the communication conditions of the communication unit are improved.

In addition, the fourth embodiment shows a configuration in which, when communication is performed by the terminal (20) through the communication I/F (22), a request requesting a payment number different from the above payment number is transmitted to the server (10) through the communication I/F (22).

As an example of the effect obtained by such a configuration, when communication is performed by the communication unit, the terminal can transmit information for obtaining second information to the server through the communication unit and receive the second information from the server.

In addition, in the fourth embodiment, the terminal (20) is configured to receive a payment number different from the above payment number through the communication I/F (22) based on a balance update operation (not limited to, but an example of an input regarding balance update of electronic money usable for payment) by the terminal (20) user.

As an example of the effect obtained by such a configuration, since second information different from the first information is received through the communication unit based on an input by the terminal user regarding an update of the balance of electronic money available for payment, it becomes possible to acquire the second information based on an input by the terminal user, thereby improving user convenience.

<Variation 4>

In the fourth embodiment, rather than having the server (10) transmit a terminal display code to the terminal (20) in response to a request from the terminal (20), the server (10) may transmit a terminal display code to the terminal (20) without a request from the terminal (20), or may not do so.

In this specification, the server (10) transmitting information (or data) to the terminal (20) without a request from the terminal (20) (the server (10) voluntarily transmitting information (or data)) is referred to as “push transmission.”

In this case, as an example and not a limitation, a terminal display code (a terminal display code image or a payment number) is pushed from the server (10) to the terminal (20) at regular timings (e.g., once a day) or at specific timings (e.g., when a payment application is started). Then, the terminal (20) stores the terminal display code transmitted from the server (10) in the terminal display code stock data (2831).

This modified example shows a configuration in which a payment number (not limited to, but an example of second information different from the first information) is push-transmitted from a server (10) to a terminal (20).

As an example of the effect obtained by such a configuration, second information different from the first information can be obtained from the server without the need to make a request from the terminal to the server.

<Example 5>

As described in the fourth embodiment, the terminal (20) cannot communicate with the server (10) while offline. Therefore, when an offline payment is made, the balance managed by the server (10) is updated, but the balance stored on the terminal (20) is not updated until the terminal returns to the online state and receives a payment completion notification from the server (10). In other words, the balance displayed on the payment application's application screen may not be the most recent balance.

The fifth embodiment is an embodiment of a method for solving such a problem.

The contents described in the fifth embodiment can be applied to any of the other embodiments or any of the other modifications.

Additionally, the same symbols are given to components that are identical to those in the previous example and further explanation is omitted.

(1) Current Affairs Notice

The control unit (21) of the terminal (20), as an example and not a limitation, when displaying the various extended terminal display codes described above on the display unit (24), provides a notification indicating the possibility that the balance is not up to date, regardless of whether electronic money is used.

Specifically, as an example and not a limitation, a message such as "The balance of your electronic currency may not be up to date" or "Please update your electronic currency balance" is displayed on the code display screen. Alternatively, a message of similar intent is output as sound from the speaker (26).

Additionally, as another example, as a warning that the balance may be inaccurate, the control unit (21) of the terminal (20) measures the elapsed time after the terminal (20) changes from an online state to an offline state. Then, the control unit (21) changes the display mode of the balance based on the measured elapsed time.

FIG. 8a is a drawing showing an example of information stored in a storage unit (28) of a terminal (20) in this embodiment.

In this embodiment, the payment application data (283) stores display mode setting data (2836).

Display mode setting data (2836) is data that sets the display mode of the balance in the payment application. An example of the data configuration of display mode setting data (2836A) is shown in Fig. 8b.

In the display form setting data (2836A), for example and not limitation, an elapsed time condition, which is a condition for elapsed time, and a mark type, which is a type of mark additionally displayed on the balance when the elapsed time condition is satisfied, are stored in association with each other. Here, the elapsed time is expressed as "t", and the threshold values for the elapsed time are expressed as threshold times "t1, t2".

The first elapsed time condition is "t<t1", and the mark type is set to "None." This indicates that if the elapsed time t is shorter than the threshold time t1, the possibility of an incorrect balance is low, and therefore no mark is displayed.

The second elapsed time condition is "t1≤t≤t2", and a "question mark" is specified as the mark type. This indicates that if the elapsed time t is greater than or equal to the threshold time t1 and less than or equal to the threshold time t2, there is a medium probability that the balance is incorrect, and thus a "question mark" is additionally displayed on the balance.

The third elapsed time condition is "t2<t", and the mark type is set to "Danger Mark." This indicates that if the elapsed time t is longer than the critical time t2, the balance is likely to be inaccurate, and a "Danger Mark" is additionally displayed on the balance.

FIG. 8c is a diagram showing an example of the configuration of display mode setting data (2836B), which is another example of display mode setting data (2836).

In the display mode setting data (2836B), as an example and not a limitation, an elapsed time condition and the display color of the balance (at least one of the balance text and value) when the elapsed time condition is satisfied are stored in association with each other. In the drawing, it is the same as in Fig. 8b.

The first elapsed time condition is "t<t1", and the balance display color is set to "blue." This indicates that if the elapsed time t is shorter than the critical time t1, the balance is unlikely to be accurate, and thus the balance is displayed in "blue."

The second elapsed time condition is "t1≤t≤t2", and the balance display color is set to "yellow." This indicates that if the elapsed time t is greater than or equal to the critical time t1 and less than or equal to the critical time t2, the possibility of the balance being incorrect is considered medium, and the balance is displayed in "yellow."

The third elapsed time condition is "t2<t", and the balance display color is set to "red." This indicates that if the elapsed time t is longer than the critical time t2, the balance is likely to be inaccurate, and thus the balance is displayed in "red."

Also, the threshold time can be set appropriately, but as an example, not a limitation, times such as “t1=30 minutes” and “t2=3 hours” can be set.

Fig. 8d is a drawing showing an example of a code display screen in this case. Here, a case in which display is performed based on the display mode setting data (2836A) of Fig. 8b is exemplified.

This code display screen is an example of a code display screen displayed offline. In this example, the balance is undetermined, so the words "Undetermined Balance" appear next to the payment method at the top of the screen, followed by the balance value.

The code display screen above shows the case where the elapsed time condition "t<t1" is established, and since the elapsed time t is shorter than the critical time t1, no mark is displayed on the unconfirmed balance.

The code display screen of the interruption indicates a case where the elapsed time condition "t1≤t≤t2" is established, and since the elapsed time t is greater than or equal to the critical time t1 and also less than or equal to the critical time t2, a question mark (in this example, a ? in a circle) is displayed next to the value of the unconfirmed balance.

The code display screen below shows the case where the elapsed time condition "t2<t" is established, and since the elapsed time t is longer than the critical time t2, a risk mark (in this example, inside a triangle!) is displayed next to the value of the uncertain balance.

In addition to the above, as an example and not a limitation, the display color of the balance may be the same, and as the elapsed time increases, the display color of the balance may become darker, or it may not be necessary to do so.

In addition to the above, as a non-limiting example, the thickness of the characters indicating the balance may be changed based on the elapsed time, or it may not be necessary to do so.

(2) Notification of balance renewal timing

Since the timing at which the balance was last updated is notified to the terminal (20) user, the control unit (21) of the terminal (20) displays, as an example and not a limitation, when displaying the balance in a payment application, one of the following information: the date at which the balance was last updated, the time at which the balance was last updated, and the time at which the balance was last updated, along with the balance, on the screen of the display unit (24) (e.g., a code display screen).

(3) Balance update by terminal

Since the balance is updated to the latest value, the control unit (21) of the terminal (20) obtains the latest balance from the server (10) when a specific condition is met and updates the balance stored in the payment application data (283).

Specifically, as an example and not a limitation, when returning to an online state after performing a payment procedure in an offline state, the control unit (21) of the terminal (20) transmits a request requesting the latest balance to the server (10). Then, upon receiving this request, the balance stored in the payment application data (283) is updated with the balance transmitted from the server (10).

In addition, when returning to an online state and the terminal (20) receives a terminal payment completion notification from the server (10), it is possible to update the balance stored in the payment application data (283) based on the received terminal payment completion notification. Therefore, when the balance is updated by performing the above processing, the control unit (21) may or may not update the balance when receiving a terminal payment completion notification.

In addition, the balance may be updated by performing the above processing at the time of returning to the online state even before receiving a payment completion notification for the terminal from the server (10), or it may not be necessary to do so.

In addition, in relation to the code supplement condition of condition No. "CP2-3" of code supplement condition data (2838) (Fig. 7b), when the control unit (21) detects a balance update operation for the input unit within the payment application in an online state, it transmits a request requesting the latest balance to the server (10). Then, upon receiving this request, it updates the balance stored in the payment application data (283) with the balance transmitted from the server (10).

In addition, the control unit (21) transmits a request for the latest balance to the server (10) at the time when the payment application is started and a communication connection is established with the server (10). Then, upon receiving this request, the control unit (21) updates the balance stored in the payment application data (283) with the balance transmitted from the server (10).

Also, in this case, the server (10) notifies the terminal (20) that the balance may not be up-to-date at regular intervals (e.g., once a day) or at specific intervals (e.g., when the payment application is started) by a push notification or the like. Then, based on this notification, when a balance update operation is detected in the input section within the payment application, a request requesting the latest balance may be transmitted to the server (10) to acquire the balance from the server (10), or it may not be necessary to do so.

In addition, as an example and not a limitation, the latest balance may be pushed from the server (10) to the terminal (20) at regular timings (e.g., once a day) or at specific timings (e.g., when the payment application is started), and the terminal (20) may acquire the pushed-transmitted balance, or it may not be necessary to do so.

(4) UI for balance modification

Next, we will describe the user interface (UI) for modifying the balance.

The control unit (21) displays, as an example and not a limitation, an image that can be operated by the terminal (20) user and used to modify the balance (hereinafter referred to as “balance modification image”) on a screen (e.g., a code display screen) where the balance is displayed within a payment application.

Fig. 8e is a drawing showing an example of a display screen displayed on a terminal (20) in this case. Here, a screen corresponding to the code display screen shown in Fig. 8d is shown.

On this code display screen, under the unconfirmed balance of the payment method, a balance modification button labeled “Modify displayed balance” is displayed as an example of an image for modifying the balance.

When this balance modification button is touched by the terminal (20) user, the terminal (20) user can modify the value of the unconfirmed balance. Specifically, as an example and not a limitation, when a screen corresponding to the code display screen at the bottom of Fig. 8e is displayed, for example, as shown at the top of Fig. 8f, when the balance modification button is touched by the terminal (20) user, for example, as shown at the bottom of Fig. 8f, a numeric keypad for the terminal (20) user to input numbers is displayed, and at the same time, an input balance display box is displayed in which the value of the balance entered from the numeric keypad is displayed. The input balance display box includes, as an example and not limitation, a message saying "Please enter the balance after use," a display box in which the value of the entered balance is displayed, an OK button for confirming the value of the balance, and a Cancel button for canceling the modification of the balance.

When the OK button is touched, the control unit (21) modifies the display of the unconfirmed balance value. For example, as shown in FIG. 8f, if the unconfirmed balance is "3,000 yen" and the terminal (20) user inputs "2,600" using the numeric keypad and touches the OK button, the display of the unconfirmed balance value is modified to "2,600 yen", as shown in the upper part of FIG. 8g, for example.

Upon returning to online mode, the terminal (20) confirms the value of the unconfirmed balance based on information transmitted from the server (10) (e.g., a terminal payment completion notification). In this case, the modified unconfirmed balance may differ from the latest balance value managed by the server (10) due to reasons such as the terminal (20) user misrecognizing the amount to be paid. In this case, the control unit (21) adjusts and updates the modified unconfirmed balance value to the correct value based on the information transmitted from the server (10).

For example, if the balance of "2,600 yen" shown at the top of Fig. 8g is incorrect by 100 yen, for example, as shown at the bottom of Fig. 8g, the unconfirmed balance value is adjusted and updated to "2,500 yen" and displayed, thereby confirming the balance, and at the same time, the text of "unconfirmed balance" is changed to the text of "balance" and displayed, and the button for correcting the balance is also deleted.

(5) UI for balance update

The control unit (21) may, as an example and not a limitation, display an image that is operable by the terminal (20) user and is used to update the balance (hereinafter referred to as a “balance update image”) on a screen (e.g., a code display screen) where the balance is displayed within a payment application.

Specifically, the control unit (21) may, as an example and not a limitation, display a balance update button for modifying the balance next to the display of the balance of the payment method on the code display screen as an example of an image for modifying the balance.

When the balance update button (MB) is touched while online, the control unit (21) transmits a request requesting the latest balance to the server (10). Then, upon receiving this request, the balance stored in the payment application data (283) is updated with the balance transmitted from the server (10), and at the same time, the balance value next to the balance update button is updated with the balance value transmitted from the server (10).

The code display screen displays a code image in addition to the balance, but even when the balance update button is touched, code generation request information is not transmitted from the terminal (20) to the server (10), and the displayed code image is not updated. In other words, the display is updated for only a portion of the code display screen (partial area). By doing so, the displayed code image can be read as is by the store code reader (50) and the server (10) can process the payment, thereby shortening the time required for payment compared to a case where the code is also updated.

(6) Presentation of balance by store

In C180 of FIG. 4l, the control unit (11) of the server (10) includes the latest balance associated with the terminal (20) that performed the payment or the terminal (20) user in a store payment completion notification and transmits it to the store code reader device (50). Then, when the store payment completion notification is received from the server (10) in B280, the store code reader device (50) displays the received store payment completion notification (including the latest balance) on the display unit (53). Then, the store staff or the like presents the store payment completion notification displayed on the display unit (53) to the user.

In this case, the terminal (20) user, after confirming the presented store payment completion notification, performs an operation to modify the balance within the payment application of his/her terminal (20) to modify the balance to the latest balance.

Other

The screen displaying balance information within a payment application is not limited to the code display screen. For example, as illustrated in Figure 3b, balance information may also be displayed on the main screen of the payment application. In this case, as an example and not a limitation, the image for modifying or updating the balance may be displayed on the main screen instead of or in addition to the code display screen, and the balance may be modified or updated based on the image for modifying or updating the balance displayed on the main screen.

<Effect of Example 5>

In the fifth embodiment, a configuration is shown in which the terminal (20) displays balance information of electronic money that can be used for payment on the screen of the payment application.

As an example of the effect obtained by this configuration, the balance of electronic money available for payment can be notified to the user of the terminal by displaying the balance information of electronic money available for payment in the display area of the terminal.

In addition, in the fifth embodiment, the terminal (20) receives balance information of electronic money from the server (10) through the communication I/F (22) by the control unit (21) based on the communication status of the communication I/F (22). In addition, the terminal (20) is configured to display the received balance information of electronic money on a screen within the payment application.

As an example of the effect obtained by such a configuration, the terminal can appropriately receive balance information from the server through the communication unit by the control unit based on the communication status of the communication unit, and then display the information in the display area to notify the terminal user.

In addition, in the fifth embodiment, the terminal (20) is configured to display on the payment application screen any one of information on the date the balance was last updated (not limited to, but an example of information on the date when the balance information is displayed in the display area), information on the time when the balance was last updated (not limited to, but an example of information on the time when the balance information is displayed in the display area), and information on the date and time when the balance was last updated (not limited to, but an example of information on the date and time when the balance information is displayed in the display area).

As an example of the effect obtained by such a configuration, the terminal can notify the user by displaying information about the date on which the balance information is displayed in the display area or information about the time on which the balance information is displayed in the display area.

In addition, in the fifth embodiment, the terminal (20) shows a configuration in which the balance displayed on the code display screen is modified based on a user operation (not limited to, but an example of an input related to modification of balance information) on an image for modifying the balance, such as a balance modification button.

As an example of the effect obtained by such a configuration, the balance displayed in the display area of the terminal can be easily and appropriately modified based on an input regarding modification of balance information.

In addition, the fifth embodiment shows a configuration in which the terminal (20) displays an image for updating balance, such as a button for updating balance (not limited to, an example of a display for updating balance information by input from a terminal user).

As an example of the effect obtained by such a configuration, by displaying a display for updating balance information by input from a terminal user in the display area of the terminal, the terminal user can easily update the balance, thereby improving user convenience.

In addition, in the fifth embodiment, the terminal (20) displays the balance on the code display screen, and displays an image for updating the balance (not limited to, an example of a display for updating balance information by input from the terminal user) on the code display screen. In this case, the terminal (20) displays the code display (not limited to, an example of the first display) on one area (not limited to, an example of the third area) of the code display screen, and displays the balance on another area (not limited to, an example of the fourth area) of the code display screen. In addition, based on a user operation on the image for updating the balance, a configuration is shown in which the balance displayed in another area is updated while the code display is displayed in one area.

As an example of the effect obtained by such a configuration, since the balance information displayed in the fourth area can be updated while the first display is displayed in the third area based on an input by the terminal user for a display for updating the balance information, only the balance information displayed in the fourth area can be updated without having to update the first display displayed in the third area.

<Variation 5>

Regarding the balance modification or change described in the fifth embodiment, even if the terminal (20) is offline, the store POS system (40) can communicate with the server (10). Therefore, as an example and not a limitation, the receipt issued from the code register (60) prints the latest balance (accurate balance) of the terminal (20) user. Furthermore, as an example and not a limitation, the balance entered into the code register (60) or the balance displayed therein becomes the latest balance of the terminal (20) user.

Here, as an example and not a limitation, the store code reader device (50) determines whether the payment is offline. As described above, the terminal display code image includes a payment number, while the extended terminal display code image includes a payment number and time information. Therefore, the store code reader device (50) can determine offline payment, as an example and not a limitation, if the information acquired by decoding from the read code image includes a payment number and time information.

In addition, as an example and not a limitation, the server (10) determines offline payment based on payment request information including a payment number and time information received from the store code reader device (50). In addition, the server (10) may transmit a store payment completion notification including information indicating offline payment to the store code reader device (50) after performing payment processing, thereby causing the store code reader device (50) to determine offline payment.

If it is determined to be an offline payment, the store code reader device (50) outputs information indicating that it is an offline payment to the code register (60), as an example and not a limitation. In this case, the code register (60) may print, as an example and not a limitation, the balance on the issued receipt and information indicating that the balance is different from the balance displayed on the terminal (20).

Likewise, if it is determined to be an offline payment, the store code reader device (50) outputs information indicating that it is an offline payment to the code register (60), as an example and not a limitation. In this case, the code register (60) may display, as an example and not a limitation, the balance and information indicating that the balance is different from the balance displayed on the terminal (20) on a display or the like facing the customer side.

In addition, in this case, it is possible or not to have a store employee or the like verbally notify the user of the terminal (20) that the balance printed on the receipt or the balance displayed on the display is different from the balance displayed on the terminal (20) or that the balance displayed on the terminal (20) is not the correct balance.

<Example 6>

The sixth embodiment is an embodiment in which authentication processing is performed at a terminal (20) when performing offline payment. Furthermore, when performing this authentication processing, if a specific condition is met, the authentication processing is skipped.

In this embodiment, “authentication” means, unless otherwise specified, authenticating that the terminal (20) user is a regular user in order to make a payment, and “authentication processing” means processing for realizing this authentication for payment.

In addition, “authentication skip condition” means a condition for skipping the above payment authentication processing unless otherwise specified, and “skip authentication processing” means ignoring the processing command of authentication processing and processing the next command, i.e., omitting authentication processing.

FIG. 9A is a diagram showing an example of the data configuration of store registration data (155B), which is an example of store registration data (155) stored in the storage unit (15) of the server (10) in this embodiment.

This store registration data (155B) is the registration data of the affiliated store, similar to the store registration data (155A) (Fig. 4d) described above, but the data configuration is partially different.

Specifically, in the store registration data (155B), in addition to the industry, store name, store location information, store POS system information, and store ID, a first specific industry flag and a second specific industry flag are stored in association with each other.

The first specific industry flag is a flag indicating whether this industry is a first type of specific industry (hereinafter referred to as "the first specific industry") set in advance. "ON" is stored for industries that fall under the first specific industry, and "OFF" is stored for industries that do not fall under the first specific industry. The first specific industry can be set in advance on the server (10) side as an example, not a limitation. In this example, "convenience store" and "supermarket," which are industries frequently used by many users, are set as the first specific industries.

The second specific industry flag is a flag indicating whether this industry falls within a second type of specific industry (hereinafter referred to as "the second specific industry") set in advance. "ON" is stored for industries that fall within the second specific industry, and "OFF" is stored for industries that do not fall within the second specific industry. The second specific industry may also be set in advance on the server (10) side, as an example and not a limitation. In this example, "pubs," which are industries at high risk of users losing their terminals (20), are set as the second specific industry.

Fig. 9b is a drawing showing an example of a function realized by the control unit (21) in this embodiment.

The payment application processing unit (211) of the control unit (21) includes an authentication processing unit (2115) and an authentication skip determination processing unit (2117). In addition, the control unit (21) includes a location calculation processing unit (217).

The authentication processing unit (2115) has a function of executing authentication processing to verify whether the terminal (20) user is a regular user when making an offline payment.

In the authentication process, as an example and not a limitation, as a display process for executing authentication for a terminal (20) user, a process is performed to display an authentication screen for having the terminal (20) user input an authentication password on the display unit (24), and it is determined whether the authentication password input on this authentication screen matches the authentication password registered in the storage unit (28).

In this embodiment, the authentication processing unit (2115) executes authentication processing at a timing before executing processing of A350 in the processing of FIG. 4l or at a timing before executing processing of A550 in the processing of FIG. 6c, as an example and not a limitation.

The authentication skip decision processing unit (2117) includes a function for executing authentication skip decision processing, which is processing for determining whether to skip the authentication processing executed by the authentication processing unit (2115).

In this embodiment, the authentication skip decision processing unit (2117) executes the authentication skip decision processing at a timing before the authentication processing by the above authentication processing unit (2115) is executed, as an example and not a limitation.

The position calculation processing unit (217) includes a function of executing a position calculation process, which is a process for calculating the position of its 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, for example, satellite orbit data or time data output from a satellite positioning sensor (satellite positioning unit) included in the position calculation information detection unit (29B), to calculate the position of its own terminal (20). In addition, the position calculation processing unit (217) performs inertial navigation calculations based on information on acceleration or angular velocity output from an inertial measurement sensor (inertial measurement unit) included in the position calculation information detection unit (29B), to calculate the position of its own terminal (20).

Also, unlike the present embodiment, as an example and not a limitation, a processing device or an operation device (e.g., CPU or DSP) may be provided in the position calculation information detection unit (29B), and the position calculation information detection unit (29B), rather than the control unit (21) of the terminal (20), may calculate and output the position of the terminal (20), or it may not be necessary.

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

FIG. 9c is a drawing showing an example of information stored in the storage unit (28) of the terminal (20) in this embodiment.

In the storage unit (28), in addition to payment application software (281) and terminal data (289), as an example and not a limitation, a location calculation processing program (287) executed by location calculation processing and calculation terminal location history data (288) are stored.

In addition to the terminal display code stock data (2831), payment data (2832), and store data (2833), as an example and not a limitation, authentication skip condition data (2837) is stored in the payment application data (2833).

FIG. 9d is a diagram showing an example of the data configuration of payment data (2832B), which is an example of payment data (2832) in this embodiment.

In addition to the information stored in the payment data (2832A) (Fig. 4h), the payment data (2832B) stores an authentication password and a payment application unlock password.

In addition, in this embodiment, various store information stored in the store registration data (155A) (Fig. 9a) of the server (10) is stored in the store data (2833), as an example and not a limitation.

In the output terminal position history data (288), as an example and not a limitation, the history of the position of the terminal (20) (hereinafter referred to as “output terminal position”) calculated by the position calculation processing unit (217) performing position calculation processing every predetermined time (e.g., “1 minute”, “5 minutes”, or “10 minutes”) is stored.

In addition, in the present embodiment, the terminal data (289) includes, as examples and not limitation, information such as the lock setting “ON/OFF” on the OS side of the terminal (20), the terminal unlock password for unlocking the OS side of the terminal (20), and the terminal authentication setting “ON/OFF”.

Authentication skip condition data (2837) is data for which authentication skip conditions are set, and an example of the data configuration is shown in Fig. 9e.

Authentication skip condition data (2837) stores in association the condition category No, which is the category number of the authentication skip condition, the condition No, which is the number of the authentication skip condition included in the category of this condition category No, the authentication skip condition of this condition No, the application status indicating whether to apply and determine whether to apply this authentication skip condition, and the importance (priority) of this authentication skip condition. Hereinafter, each authentication skip condition and its determination method will be described in detail.

<Condition Category No. 「SP1」>

Condition category No. 「SP1」 is a category of 「Time」, and as an example and not a limitation, the authentication skip conditions of condition No. 「SP1-1」, 「SP1-2」 are included here.

As a condition for skipping authentication for Condition No. 「SP1-1」, 「the current date and time is within the set time from the final payment date and time」 is set.

The "Final Payment Date" refers to the date and time of the last payment (the most recent payment date and time), regardless of whether authentication processing was skipped on the terminal (20). This means that if the current date and time is within a set time (e.g., "within 1 hour") of the final payment date and time, authentication is omitted to enhance user convenience, as payment is processed again within a short period of time.

In the judgment of this authentication skip condition, as an example and not a limitation, the authentication skip judgment processing unit (2117) may acquire the current date and time based on the clock time displayed in the clock unit (29A) and the final payment date and time stored in the payment history data of the payment data (2832B), and determine whether the current date and time is within a set time from the final payment date and time.

As an authentication skip condition for condition No. "SP1-2", "the current time is included in the set time zone" is set. The set time zone is not limited, but can be preset by the user of the terminal (20) as an example. Specifically, for example, the user of the terminal (20) can skip authentication when making a payment during the set time zone by setting the time zone in which he or she frequently makes payments as the set time zone.

In the judgment of this authentication skip condition, as an example and not a limitation, the authentication skip judgment processing unit (2117) may obtain the current time based on the clock time shown in the clock unit (29A) and determine whether the current time is included in the set time zone.

<Condition Category No. 「SP2」>

Condition category No. 「SP2」 is a category of 「store/place」, and as an example and not a limitation, the authentication skip conditions of condition No. 「SP2-1」∼「SP2-4」are included here.

In the offline state, there are cases where the position calculation processing unit (217) cannot perform position calculation using a satellite positioning system. In this case, in the offline state, the position calculation processing unit (217) calculates and specifies the terminal position of its own terminal (20) based on, but not limited to, the above-described inertial navigation operation or a beacon signal transmitted from a beacon installed in the above-described affiliated store, and stores it in the calculation terminal position history data (288). Then, based on the history of the calculation terminal position stored in the calculation terminal position history data (288) or the most recent calculation terminal position, it determines whether the following authentication skip conditions are met. In addition, the beacon signal can be received by, but not limited to, turning the Bluetooth function “ON” in the terminal (20).

As a condition for skipping authentication for Condition No. "SP2-1", "Payment or authentication for payment has been performed in the past at the store where payment is scheduled to be made" is set.

"Payment-Planned Store" refers to a store where payment is scheduled to be made in the future (or a store where payment is still pending). This means that if a store has previously processed a payment or completed authentication, authentication will be omitted to enhance user convenience.

In the judgment of this authentication skip condition, the authentication skip judgment processing unit (2117) may, as an example and not a limitation, acquire the history and recent calculation terminal positions of calculation terminal positions stored in the calculation terminal position history data (288) and the payment date and time stored in the payment details data of the payment data (2832B), and determine whether there is a calculation terminal position that matches the recent calculation terminal position among the calculation terminal positions corresponding to the same date and time as the past payment date and time.

As a condition for skipping authentication for Condition No. "SP2-2," "the payment-planned store is a set store" is specified. The set store can be set in advance on the server (10) side, as a basic rule. As a non-limiting example, the server (10) can statistically aggregate stores with a high user frequency and set them as set stores. This means that authentication is skipped at stores with a high user frequency to improve user convenience.

In addition, it may be possible to set a preset store on the terminal (20) side, rather than on the server (10) side. For example, a terminal (20) user may set a frequently used store as a preset store on the terminal (20). In addition, for example, a terminal (20) user may set a store near the home as a preset store, considering it safe for a specific type of store (e.g., a convenience store), but may not set other stores as preset stores, considering it dangerous.

In the judgment of this authentication skip condition, the authentication skip judgment processing unit (2117) may, as an example and not a limitation, acquire the history of the calculation terminal location stored in the calculation terminal location history data (288), the payment store name stored in the payment details data of the payment data (2832B), and the store information stored in the store data (2833), and determine whether there is a calculation terminal location that matches the recent calculation terminal location among the calculation terminal locations corresponding to the same date and time as the payment date and time at the set store in the past.

As a condition for skipping authentication for Condition No. "SP2-3", "the store where payment is scheduled to be made is a store of the first specific industry" is specified.

The first specific industry category, by way of example and not limitation, can be defined as a category frequently visited by many users, such as a "convenience store" or a "supermarket." When making payments at these stores, authentication is omitted to enhance user convenience.

In the judgment of this authentication skip condition, the authentication skip judgment processing unit (2117) may, as an example and not a limitation, acquire the history of the output terminal location stored in the output terminal location history data (288), the payment store name stored in the payment details data of the payment data (2832B), and the first specific industry flag stored in the store data (2833), and determine whether there exists an output terminal location that matches the most recent output terminal location among the output terminal locations corresponding to the same date and time as the past payment date and time in a store where the first specific industry flag is "ON".

As a condition for skipping authentication for Condition No. "SP2-4", "a set time has passed since the payment date at a store of the second specific industry" is set. As described above, the second specific industry can be set to an industry where the user has a high risk of losing the terminal (20), such as a "tavern." In addition, the set time can be set to, for example, "3 hours," "6 hours," or "12 hours." This means that when payment is made at a store where the user has a high risk of losing the terminal (20), authentication is required until the set time has passed since the payment date, but if the set time has passed since the payment date, authentication is skipped.

In the judgment of this authentication skip condition, the authentication skip judgment processing unit (2117) may, as an example and not a limitation, acquire the current date and time based on the clock time displayed in the clock unit (29A), the payment date and time stored in the payment history data of the payment data (2832B), and the second specific industry flag stored in the store data (2833) to determine whether the current date and time in a store where the second specific industry flag is "ON" exceeds the set time from the payment date and time.

<Condition Category No. 「SP3」>

Condition category No. 「SP3」 is a category of 「Amount」, and as an example and not a limitation, the authentication skip conditions of condition No. 「SP3-1」, 「SP3-2」 are included here.

As a condition for skipping authentication for Condition No. 「SP3-1」, 「not exceeding the daily limit amount」 is set.

The "Daily Limit" is the upper limit set as a threshold for the total amount of payments already made (the amount of completed payments) on that day. This means that if the total amount of payments already made on that day does not exceed the daily limit, authentication is omitted to enhance user convenience.

Conversely, if the total amount of payments already made on a given day exceeds the daily limit, requiring authentication can help prevent excessive spending. Furthermore, if a minor or other individual makes a payment, a guardian can restrict their use.

In the judgment of this authentication skip condition, the authentication skip judgment processing unit (2117) may, as an example and not a limitation, acquire the sum of the daily limit set amount stored in the payment data (2832B) and the daily payment amount specified from the payment history data, and determine whether the sum exceeds the daily limit set amount.

As a condition for skipping authentication for Condition No. "SP3-2", "the balance is equal to or less than the set amount (or less than the set amount), and the automatic recharge setting is OFF" is set. The set amount is not limited, but can be set in advance by the terminal (20) user as an example. This means that if the balance is equal to or less than the set amount (or less than the set amount), the user cannot purchase expensive products through payment, which is considered low risk, and therefore, authentication is skipped to improve user convenience.

However, if the auto-recharge setting is set to "ON," the digital currency will be automatically replenished, allowing users to purchase expensive items with the card, which poses a risk. Therefore, in addition to the balance being below the set amount (or less than the set amount), the auto-recharge setting must be set to "OFF" to skip authentication.

Also, in this case, if the automatic recharge setting is "ON", authentication processing will not be skipped in principle even if the balance is equal to or less than the set amount. However, as described above, in consideration of improving user convenience, authentication processing may be skipped even if the automatic recharge setting is "ON". In this case, as an example and not a limitation, it is sufficient to exclude the automatic recharge setting OFF from the authentication skip conditions of the above condition No. "SP3-2" and set it to "the balance is equal to or less than the set amount". In other words, even if the automatic recharge setting is "ON", authentication processing is not necessarily required. In the case where the automatic recharge is "ON" and the balance is equal to or less than the set amount, authentication processing may be performed, or it may not be performed.

In determining this authentication skip condition, the authentication skip determination processing unit (2117) may, as an example and not a limitation, acquire the balance and automatic recharge settings stored in the payment data (2832B) and determine whether the balance is equal to or less than the set amount and whether the automatic recharge setting is “OFF”.

<Condition Category No. 「SP4」>

Condition category No. 「SP4」 is a category of 「Product」, and as an example and not a limitation, the authentication skip conditions of condition No. 「SP4-1」, 「SP4-2」 are included here.

As a condition for skipping the certification of Condition No. "SP4-1", "the product to be purchased is a daily consumer good" is specified.

"To-be-purchased items" refers to items that are scheduled for purchase by making payment in the future (items whose status is still unconfirmed before payment). In other words, if the items scheduled for purchase by making payment in the future are daily necessities, authentication is omitted to improve user convenience.

As a condition for skipping authentication for Condition No. "SP4-2", "Purchase history of the product to be purchased" is set. This means that if the product to be purchased matches a product that the user of the terminal (20) has purchased at least once, authentication is skipped to improve user convenience.

<Condition Category No. 「SP5」>

Condition category No. 「SP5」 is a category of 「Security」, and as an example and not a limitation, the authentication skip condition of condition No. 「SP5-1」 is included here.

As an authentication skip condition for Condition No. "SP5-1", "terminal locked or payment application locked" is set. This means that when the OS side of the terminal (20) is locked or the payment application side is locked, authentication such as entering the terminal unlock password or payment application unlock password is required to unlock these states. Therefore, this means that payment authentication is not required to improve user convenience.

In determining this authentication skip condition, the authentication skip determination processing unit (2117) may, as an example and not a limitation, acquire information on whether the OS side of the terminal (20) is locked or not stored in the terminal data (289) and information on whether the payment application side is locked or not stored in the payment application data (283), and determine whether the terminal is locked or the payment application is locked.

Condition category No. 「SP6」is a category of 「Authentication Settings」, and as an example and not a limitation, the authentication skip condition of condition No. 「SP6-1」is included here.

As an authentication skip condition of Condition No. 「SP6-1」, 「Authentication setting OFF on the terminal side, or authentication setting OFF on the payment application side」 is set.

Terminal-side authentication refers to various authentications required of a user on the terminal (20) side, including user authentication. Payment application-side authentication refers to authentication required of a user when making a payment using a payment application.

This means that authentication is omitted when a setting is made to omit authentication on the terminal (20) side by the terminal (20) user, or when a setting is made to omit authentication on the payment application side.

In the judgment of this authentication skip condition, the authentication skip judgment processing unit (2117) may, as an example and not a limitation, acquire the terminal-side authentication settings stored in the terminal data (289) and the payment application-side authentication settings stored in the payment application data (283) and determine whether at least one of the terminal-side authentication settings and the payment application-side authentication settings is “OFF”.

Although multiple authentication skip conditions have been exemplified so far, in this embodiment, as an example and not a limitation, for each of these authentication skip conditions, an application status indicating whether or not the authentication skip condition can be applied is determined.

In this embodiment, the authentication skip conditions of condition No. "SP4-1" and "SP4-2" are set to "×" (not applicable). This is because, in order to determine these authentication skip conditions, the terminal (20) needs to obtain information regarding the product to be purchased. However, fundamentally, the terminal (20) cannot obtain information regarding the product to be purchased, and cannot determine whether the product to be purchased is a daily consumer good or whether there is a purchase history for the product to be purchased.

However, if the terminal (20) can obtain information about the product to be purchased, these authentication skip conditions are applicable and marked as "○". Details on this are described later in a modified example.

In addition, in this embodiment, as an example and not a limitation, for each of the above authentication skip conditions, an “importance” (also called “priority” indicating the degree to which the authentication skip condition is preferentially applied) is determined as an indicator value indicating the degree of importance of the authentication skip condition.

Importance is expressed in three levels, from "A" to "C", as an example and not a limitation, with "A" being the most important and "C" being the least important.

Specifically, as an example and not a limitation, the authentication skip conditions of conditions No. 「SP1-1」, 「SP2-1」, 「SP2-4」, 「SP3-1」, 「SP3-2」, 「SP5-1」, and 「SP6-1」 are assigned importance 「A」, the authentication skip conditions of conditions No. 「SP2-2」, 「SP2-3」 are assigned importance 「B」, and the authentication skip condition of condition No. 「SP1-2」 is assigned importance 「C」. In addition, in this embodiment, since the authentication skip conditions of conditions No. 「SP4-1」, 「SP4-2」 are not applicable, the importance is assigned 「-(none)」.

Furthermore, the above-mentioned importance settings are merely examples, and it is of course possible to change them as appropriate. Furthermore, in this example, while the application and importance are determined for each authentication skip condition (for each condition No.), alternatively, the application and importance may be determined for each authentication skip condition category (condition category No.), or may not be determined at all.

In addition, in the above authentication skip condition data (2837), a column for application or non-application may not be provided, and only applicable authentication skip conditions may be specified as authentication skip condition data (2837).

Additionally, in this example, importance is set in relation to the authentication skip condition, but this setting of importance is not mandatory, and it is possible to not set importance. In other words, the importance field may not be provided in the authentication skip condition data (2837) above.

In this case, in the authentication skip judgment processing, as an example and not a limitation, it is good to determine whether the authentication skip conditions are met in any order, and if any one of the authentication skip conditions is met, to determine that the authentication processing is skipped.

Information indicated by the category of authentication skip conditions in the above authentication skip condition data (2837) or information used to determine each authentication skip condition included in each category is included in information regarding electronic money.

Specifically, for example, the category of "SP1 (time)" includes information about the time at which payment was made with electronic money, but this information can be broadly said to be information about electronic money.

Also, for example, the category of "SP2 (store/place)" includes information about places where payments were made with electronic money or information about stores where payments were made with electronic money, but such information can be broadly said to be information about electronic money.

Also, for example, the category of "SP3 (amount)" includes information about the amount of electronic money, but this information can be broadly said to be information about electronic money.

Also, for example, the category of "SP4 (Products)" includes information about products purchased with electronic money, but this information can be broadly said to be information about electronic money.

Also, the meaning of the term “information about ~” is the same for other examples, so an explanation for each case is omitted.

<Processing>

Fig. 9f is a flowchart illustrating an example of a processing flow executed by each device in this embodiment. From left to right, the diagrams illustrate the third payment application processing, which is an example of payment application processing executed by the control unit (21) of the terminal (20), the first store payment processing, which is an example of store payment processing executed by the control unit (51) of the store code reader device (50), and the first payment management processing, which is an example of payment management processing executed by the control unit (11) of the server (10).

The flowchart of Fig. 9f adds steps A640 to A660 to the flowchart of Fig. 4l.

Also, although this example illustrates adding steps A640 to A660 to the flowchart of FIG. 4l, these steps can also be added to other flowcharts (e.g., the flowchart of FIG. 3a, the flowchart of FIG. 3d, the flowchart of FIG. 5b, the flowchart of FIG. 6c, the flowchart of FIG. 10, etc.).

After A240, when the offline state is reached and, for example, a code display operation is performed by the user of the terminal (20), the authentication skip determination processing unit (2117) performs authentication skip determination processing (A640).

Specifically, as an example and not a limitation, among the authentication skip conditions in which "○" is associated with the application or non-application of authentication skip condition data (2837) and stored, as an example and not limitation, an authentication skip condition in which "A" or "B" is associated with the importance is determined as the authentication skip condition to be applied. Then, information necessary for judging each determined authentication skip condition is acquired, and whether or not the authentication skip condition is established is determined. The information necessary for judging each authentication skip condition and the judging method are as described above. Then, as an example and not limitation, if at least one authentication skip condition is established, it is determined that authentication processing is skipped, and in other cases, it is determined that authentication processing is not skipped.

In addition, the method for determining the above authentication skip conditions or the method for determining whether the authentication skip conditions are met are merely examples and are not limited thereto.

Specifically, as an example and not a limitation, only authentication skip conditions with an importance level of "A" may be determined as applicable authentication skip conditions, or they may not be so. Furthermore, authentication skip conditions with an importance level of "C" may also be included in the applicable authentication skip conditions, or they may not be so.

In addition, as an example and not a limitation, for an authentication skip condition in which “A” is associated with importance, it is determined that authentication processing is skipped if at least one authentication skip condition is satisfied, but for an authentication skip condition in which “B” is associated with importance, it is determined that authentication processing is skipped if all authentication skip conditions are satisfied, or it is not necessary to do so.

Thereafter, the control unit (21) determines whether the authentication processing is determined to be skipped in the authentication skip determination processing (A650). If it is determined not to skip the authentication processing (A650: No), the authentication processing unit (2115) performs the authentication processing (A660).

Specifically, as an example and not a limitation, an authentication screen is displayed on the display unit (24) and the user is prompted to enter an authentication password. Then, it is determined whether the entered authentication password matches the authentication password stored in the payment data (2832B). If they match, the authentication result is set to "OK"; if they do not match, the authentication result is set to "NG".

If the authentication result is determined as "NG" in the authentication process, the control unit (21) performs error processing (not shown) as an example and not a limitation. Specifically, as an example and not limitation, a notification is issued prompting the user to re-enter the authentication password, and the authentication process is performed again. On the other hand, if the authentication result is determined as "OK" in the authentication process, the control unit (21) moves the processing to A350.

Additionally, if it is determined that authentication processing is to be skipped (A650: Yes), the control unit (21) skips the authentication processing of A660 and moves the processing to A350.

<Effect of Example 6>

The sixth embodiment shows a configuration in which a terminal (20) acquires an authentication password (not limited to, but an example of information about a terminal user) through a control unit (21). Then, the terminal (20) executes authentication processing through the control unit (21) based on the acquired authentication password. Then, the terminal (20) executes code generation processing for extended terminal display or code display processing (not limited to, but an example of processing related to payment) through the control unit (21) based on the authentication processing.

As an example of the effect obtained by such a configuration, payment security can be enhanced by performing payment processing after performing user authentication processing based on information about the acquired terminal user.

In addition, the sixth embodiment shows a configuration in which information for determining whether the terminal (20) skips authentication processing for authenticating the terminal (20) user (not limited to, information for skipping processing related to terminal user authentication) is acquired by the control unit (21). In addition, when this information is acquired, the authentication processing is skipped and a code display (not limited to, an example of the first display) is displayed in one area, and when this information is not acquired, authentication processing is performed and a code display is displayed in one area.

As an example of the effect obtained by such a configuration, if the terminal obtains information for skipping the processing related to the authentication of the terminal user from the control unit, the terminal skips the processing related to the authentication of the terminal user and displays the first display in the display area, thereby shortening the time required for payment. On the other hand, if the terminal does not obtain information for skipping the processing related to the authentication of the terminal user from the control unit, the terminal performs the processing related to the authentication of the terminal user and displays the first display in the display area, thereby confirming that the terminal user is a regular user, and then the first display can be displayed in the display area.

In this embodiment, authentication can be performed or skipped even in an offline state after a skip authentication decision is made on the terminal (20), not limited to an online state. Furthermore, since the skip authentication decision or authentication is made on the terminal side rather than on the server side, the execution/non-execution of authentication can be switched on the terminal side even in an offline state.

Furthermore, in this embodiment, authentication skip determination and authentication are performed on the terminal side, not on the server side, both offline and online. Accordingly, the terminal avoids unnecessary communication with the server, enabling quick and smooth payment processing.

<Variation 6 (1)>

In the sixth embodiment, the type of authentication for the terminal (20) user is set to password authentication, and the display processing related to the execution of this authentication is set to processing for displaying an authentication screen for entering an authentication password, but this is not limited to this. In addition, for example, the type of authentication for the terminal (20) user is set to biometric authentication such as face authentication, fingerprint authentication, or voice authentication, and the processing for displaying an authentication screen required for performing these biometric authentications may or may not be set to display processing related to the execution of authentication for the terminal user.

In addition, as an example and not a limitation, the process of displaying an authentication screen in the authentication process for obtaining an account, such as an application ID of a payment application, may or may not be performed as display processing regarding the execution of authentication for the terminal user. In addition, if the result of this authentication process is "OK," the terminal (20) may or may not receive an account for using the payment application from the server (10) as information regarding payment using electronic money.

<Effect of Variation 6 (1)>

As an example of the effect of this modified example, the terminal can simply receive information regarding payment using electronic money without displaying processing regarding authentication execution for the terminal user, even for authentication other than authentication using an authentication password.

In addition, the terminal can simply obtain the information necessary to use the payment service as information regarding payment using electronic money without performing any display processing regarding the execution of authentication for the terminal user.

<Variation 6 (2)>

In the sixth embodiment, store location information is included in the store data (2833), and the terminal (20) may or may not perform an authentication skip determination based on the store location indicated by the store location information included in the store data (2833) and the calculated terminal location calculated by the location calculation processing unit (217).

Specifically, for example, when determining the authentication skip condition of "the payment scheduled store is the set store" of condition No. "SP2-2" included in condition category No. "SP2", it is possible to determine whether the most recent calculated terminal location of the terminal (20) matches the location of the set store stored in the store data (2833).

The same applies to other authentication skip conditions regarding stores and locations.

<Effect of Variation 6 (2)>

As an example of the effect obtained by this modified example, the terminal can simply determine whether the authentication skip condition is established based on the terminal location information produced by its own terminal (20) and the store location information stored in advance.

<Variation 6 (3)>

The authentication skip conditions described in the sixth 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 "the current date and time is within the set time from the final payment date and time" in condition No. "SP1-1" can also be changed to "the current date and time is within the set time from the final authentication date and time." This is because, for example, a case can be considered where a terminal (20) user performs authentication at the terminal (20) when purchasing a certain product (e.g., a lunch box), and then immediately needs to authenticate again at the terminal (20) to purchase another product (e.g., coffee).

In addition, the above-mentioned "final authentication date and time" is not necessarily limited to the date and time when payment authentication was last performed, and as a non-limiting example, the date and time when remittance authentication was last performed in the case of individual remittance of electronic money, the date and time when authentication was last performed to unlock the OS side of the terminal (20), the date and time when authentication was last performed to unlock the payment application side, and other types of authentication other than payment authentication may also be referred to as the "final authentication date and time" under the above-mentioned authentication skip condition.

Furthermore, as a non-limiting example, the "last payment date and time" in the authentication skip condition of condition No. "SP1-1" can also be referred to as the "last recharge date and time," which is the most recent time the user recharged electronic money, or the "last payment-related operation date and time," which is the most recent time the user performed a payment-related user operation within the payment application. If not much time has passed since the electronic money was last recharged, it is likely that the user recharged the electronic money for payment, and therefore it is reasonable to skip the authentication process. Furthermore, if not much time has passed since the last payment-related user operation within the payment application, it is likely that the user performed the operation with the intention of making a payment, and therefore it is reasonable to skip the authentication process.

Additionally, the "set time zone" in the authentication skip condition of Condition No. "SP1-2" can include specific days of the week or dates. For example, and not as a limitation, specific days of the week can be set to Saturday or Sunday. This is because many users go out for shopping or dining on Saturdays and Sundays, which tends to increase the opportunity to make payments. Furthermore, specific dates can be set to Christmas (including Christmas Eve), the Lunar New Year holiday, or Golden Week. Many users go out to buy gifts or have dinner on Christmas. Many users go out to buy Lunar New Year gifts during the Lunar New Year holiday. Furthermore, many users go out for outings during Golden Week. Therefore, it is expected that the opportunity to make payments will increase.

Additionally, there is a risk that a terminal (20) user may purchase a high-priced product through a third party's payment method and then cash out the product. Therefore, as a non-limiting example, an authentication skip condition such as "the store where payment is to be made does not sell products with high liquidity" can be added. Products with high liquidity include, for example, jewelry or wristwatches. If payment is to be made at a store that sells such products (e.g., a gold shop or watch shop), the terminal (20) can be configured not to skip the authentication process.

Additionally, it may be possible to add an authentication skip condition related to weather or climate. For example, on rainy or snowy days, the risk of losing the terminal (20) increases due to the increased number of users using public transportation. Therefore, as a non-limiting example, an authentication skip condition such as "the weather on that day is not rainy or snowy" could be added, preventing authentication processing from being skipped on rainy or snowy days.

<Effect of Variation 6 (3)>

As an example of the effect obtained by this modified example, the terminal can further improve user convenience by not displaying an indication regarding the execution of authentication not only when payment authentication is performed within a set time period from the last time of payment authentication in payment using electronic money, but also when a type of authentication other than payment authentication is performed within a set time period from the last time of payment authentication.

In addition, when making a payment using electronic money, if the time period from the last time of depositing electronic money is within a set time period, or if the time period from the last time of payment-related operations within the application is within a set time period, user convenience can be further improved by not displaying the execution of authentication.

Additionally, user convenience can be further improved by not displaying indications regarding the execution of authentication on certain days of the week or on certain dates.

In addition, by not performing display processing regarding the execution of authentication for terminal users based on information that takes into account the user's risk, it is possible to realize appropriate payment that takes into account the balance between user convenience and risk.

<Variation 6 (4)>

In the sixth embodiment, since the terminal (20) cannot obtain information about the product to be purchased, the authentication skip condition of “SP4 (product)” cannot be applied. However, it can be made applicable by, for example, the following method.

Specifically, as an example and not a limitation, software for enabling identification of the type of product is stored in advance in the storage unit (28) of the terminal (20) based on a photographed image captured by an imaging device (or imaging unit) such as a camera (hereinafter referred to as “application camera”) equipped as a function of a payment application or a camera (27) equipped as a function of the terminal (20).

The terminal (20), according to user operation, activates the application camera or camera (27) to capture an image of a product to be purchased. That is, the terminal (20) user captures an image of a product to be purchased using the application camera or camera (27) according to the store's code register (60). Then, the terminal (20) performs a product type identification process to identify the type of product from the captured image.

Figure 9g is a diagram illustrating an example of authentication skip condition data (2837) in this case. This data structure is similar to the authentication skip condition data (2837) of Figure 9e, but the portion surrounded by a thick black border is different.

Specifically, for the authentication skip condition "Product to be purchased is a daily consumer good" in Condition No. "SP4-1," "○" is set for applicability. This is because, by utilizing the above method, it becomes possible to identify the product type at the terminal (20), and based on the identified product type, it is possible to determine whether the product to be purchased is a daily consumer good. Furthermore, as an example, "B" is set as the priority.

In addition, regarding the authentication skip condition of "Purchase history of product to be purchased" in condition No. "SP4-2", "○" is set for application or non-application. This is because, by utilizing the above method, it becomes possible to identify the type of product at the terminal (20), and by storing the history of the identified product type in the storage unit (28), it is possible to determine whether or not there is a purchase history of the product to be purchased. In addition, as an example, "B" is set for importance.

In addition, as described above, in addition to taking a picture of a product to be purchased with the camera of the terminal (20), for example, a camera may be provided in the store code reader device (50) and the user of the terminal (20) may be made to take a picture of a product to be purchased with the camera of the store code reader device (50).

In this case, as an example and not a limitation, the store code reader device (50) identifies the type of product to be purchased based on an image captured by a camera. Then, information on the type of product to be purchased can be transmitted to the terminal (20).

Additionally, as another method, the store code reader device (50) transmits data of a photographed image captured by a camera to the terminal (20). Furthermore, the terminal (20) may identify the type of product to be purchased based on the data of the photographed image received from the store code reader device (50).

In this case, for example, even if communication cannot be performed by the first communication method described above, if communication can be performed by the second communication method, information or data regarding the product can be transmitted from the store code reader device (50) to the terminal (20) by the second communication method. Alternatively, if a short-range wireless communication method such as Bluetooth or infrared communication can be used, information or data regarding the product can be transmitted from the store code reader device (50) to the terminal (20) by these communication methods.

<Effect of Variation 6 (4)>

In this modified example, information other than the authentication password described above represents a configuration that includes information about products sold in the store (not limited to, but an example of information about 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 terminal user based on information about the product, so the processing load of the terminal can be reduced.

In addition, in this modified example, the terminal (20) acquires a photographed image of a product to be purchased taken by the application camera or camera (27) of the terminal (20) (not limited to, an example of an imaging device), and shows a configuration in which authentication processing is not performed based on the acquired photographed image.

As an example of the effect achieved by this configuration, the terminal can reduce its processing load by not displaying indications regarding the execution of authentication based on the product image captured by the imaging device. For example, if the product identified from the image captured by the imaging device is a product with a past purchase history or a specific type of product, not displaying indications regarding the execution of authentication can improve user convenience.

In addition, in this modified example, information other than the authentication password described above is configured to include information about a product to be purchased (not limited to, but an example of information about a product to be purchased by a terminal user).

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 the product purchased by the terminal user, so the processing load of the terminal can be reduced.

In addition, this modified example shows a configuration in which information on a product to be purchased by a terminal (20) user is acquired, and authentication processing is not performed when it is determined that there is a purchase history of the product to be purchased.

As an example of the benefits achieved by this configuration, the terminal can reduce its processing load by not displaying an authentication prompt if the product matches a product the user has purchased at least once. Furthermore, since purchasing the same product is considered less risky, the prompt for authentication is not displayed, thereby ensuring security while improving user convenience.

In addition, this modified example shows a configuration in which information on a product to be purchased by a terminal (20) user is acquired, and authentication processing is not performed when the product to be purchased is determined to be a daily consumer good.

As an example of the benefits achieved by this configuration, the terminal can reduce its processing load by not displaying authentication information when the product being purchased is a daily consumer good. Furthermore, since the risk associated with purchasing daily consumer goods is considered low, not displaying authentication information can enhance user convenience while ensuring safety.

In addition to the above, as a method of identifying a product or the type of product purchased by a terminal (20) user using the terminal (20), a method using non-contact communication may be applied as an example and not a limitation.

Specifically, and not by way of limitation, as an example, RF tags (e.g., IC tags) storing product identification information or product type identification information are embedded in each product or type of product sold in a store. Furthermore, a terminal (20) is equipped with an RF tag-compatible reader/writer. The terminal (20) then scans the RF tags embedded in products purchased by a user with radio waves and acquires product identification information or product type identification information stored in the RF tags, thereby identifying the products purchased by the user or the product type thereof.

<Example 7>

In the case of offline payment, if the terminal (20) does not receive a terminal payment completion notification from the server (10) when returning to the online state, the terminal (20) user cannot know that the payment has been successfully completed. Therefore, even if the user recognizes that the payment has been successfully completed by receiving a store payment completion notification from the server (10) by means of, for example, a store code reader device (50), it is conceivable that a malicious store employee or the like may verbally point out to the terminal (20) user that an error has occurred, thereby forcing cash payment, thereby committing fraud.

The contents described in the seventh embodiment can be applied to any of the other embodiments or any of the other modified examples.

Additionally, the same symbols are given to components that are identical to those in the previous example and further explanation is omitted.

Fig. 10 is a flowchart showing an example of a processing flow executed by each device in this embodiment. From the left, in order, the third payment application processing, which is an example of payment application processing executed by the control unit (21) of the terminal (20), the second store payment processing, which is an example of store payment processing executed by the control unit (51) of the store code reader device (50), and the first payment management processing, which is an example of payment management processing executed by the control unit (11) of the server (10), are shown.

The flowchart of Fig. 10 is the flowchart of Fig. 4l with the step B390 added.

At B280, when a payment completion notification for the store is received from the server (10) via the communication I/F (54), the control unit (51) performs a payment completion confirmation notification process (B390). Specifically, for example, a voice or a sound effect (e.g., a chime sound "ping pong" or a cash register sound "charin") indicating that the payment has been completed (successfully) is output from the sound output unit (56). By doing so, the terminal (20) user can confirm that the payment has been successfully completed by the sound output from the store code reader (50).

Additionally, the control unit (51) may display a payment completion confirmation screen including a message indicating that payment has been completed (successful) on the display unit (53). In this case, as an example and not a limitation, the store may prepare a payment completion confirmation screen for its own use and, upon completion of payment, be required to present the payment completion confirmation screen to the customer. By doing so, the terminal (20) user can confirm that payment has been completed successfully through the screen displayed on the store code reader (50).

In addition, rather than displaying the payment completion confirmation screen on the display unit (53) of the store code reader device (50), as an example and not a limitation, the payment completion confirmation screen may be displayed on a display that is integrated with the code register (60) or provided separately from the code register (60) and faces the customer side, or it may not be necessary to do so.

<Effect of Example 7>

According to the seventh embodiment, for example, since the store notifies the terminal (20) user that an offline payment has been made, fraud on the store side can be prevented, while at the same time, user convenience can be improved.

<Example 8>

The eighth embodiment is an embodiment of a method for dealing with a case where there is a doubt about the result of an offline payment.

The contents described in the eighth embodiment can be applied to any of the other embodiments or any of the other modified examples.

Additionally, the same symbols are given to components that are identical to those in the previous example and further explanation is omitted.

FIG. 11A is a diagram showing an example of the configuration of a payment management database (157B), which is an example of a payment management database (157) stored in a storage unit (15) of a server (10) in this embodiment.

The payment management database (157B) stores payment management data generated for each terminal (20) or each terminal (20) user.

Each payment management data includes, but is not limited to, application ID, balance, points, daily limit, automatic recharge settings, payment history data, and, for example, credit scores.

A credit score is a numerical value or ranking that represents the social credit of a terminal (20) user.

The credit score is calculated based on, but not limited to, the payment performance, age, employment type, annual salary, etc. of the terminal (20) user, and is updated periodically.

As an example, but not a limitation, credit scores can be quantified as a score from "0" to "100", with a credit score of "100" indicating the user's highest social credit and a credit score of "0" indicating the user's lowest social credit.

FIG. 11b is a drawing showing an example of the configuration of code management data (159B), which is an example of code management data (159) stored in the storage unit (15) of the server (10) in this embodiment.

In the code management data (159B), for example and not limitation, the code generation date and time, application ID, and payment number are stored in a time series.

In this embodiment, after processing a payment in an offline state, the server (10) determines the credit score stored in the payment management data associated with the application ID. As an example and not a limitation, if the determined credit score is below a set threshold (or below a predetermined threshold), a payment confirmation notification is sent to the terminal (20) to confirm to the terminal user whether the payment was made incorrectly. The terminal (20) receives this payment confirmation notification after returning to an online state.

In this case, the above threshold score may or may not be changed based on the relationship between the credit score and the payment amount. Specifically, as a non-limiting example, the higher the payment amount, the higher the threshold score, making it easier to send a payment confirmation notification to the terminal (20). Conversely, the lower the payment amount, the lower the credit score, making it more difficult to send a payment confirmation notification to the terminal (20).

In addition, after performing payment processing in an offline state, the server (10) refers to the code management data (159B) and determines the code generation date and time stored in association with the application ID and payment number that performed the payment processing. As an example and not a limitation, if the elapsed time from the determined code generation date and time to the payment processing date and time is equal to or greater than a set threshold time (or exceeds the threshold time), a payment confirmation notification is transmitted to the terminal (20) to confirm to the terminal (20) user whether the payment was made incorrectly. The terminal (20) receives this payment confirmation notification after returning to an online state.

In this case, the threshold time may or may not be changed based on the relationship between the elapsed time and the payment amount. Specifically, as a non-limiting example, the higher the payment amount, the shorter the threshold time, making it easier for the payment confirmation notification to be transmitted to the terminal (20). Conversely, the lower the payment amount, the longer the threshold time, making it more difficult for the payment confirmation notification to be transmitted to the terminal (20).

Upon receiving a payment confirmation notification, the control unit (21) of the terminal (20) displays the received payment confirmation notification on the display unit (24), for example and not limitation. In this case, the terminal (20) user checks the contents of the payment confirmation notification to determine whether the payment was made properly. If the user determines that the payment was not proper, the user uses his/her terminal (20) to contact the server (10) regarding an objection to the payment.

<Effect of Example 8>

According to the eighth embodiment, if an offline payment is made by the server, the terminal returns to the online state based on the fulfillment of the conditions, receives payment confirmation information from the server, and notifies the user. This allows the terminal user to verify whether there are any suspicious aspects to the payment. Furthermore, if there are any suspicious aspects, the user can raise an objection using their terminal.

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 (51)

An information processing method of a terminal that executes processing related to payment based on first information for making payment by code image,
Receiving the first information transmitted from the server through the communication unit of the terminal,
Storing the received first information in the storage unit of the terminal by the control unit of the terminal,
Including displaying the first information and the first code image based on the time information in the display area of the terminal,
The above visual information includes visual information based on the display of the first code image in the display area,
The above payment is executed by the server based on the first information and the visual information received by the server based on the display of the first code image,
The setting for automatic adjustment of the time of the above terminal is executed by the above terminal,
The above first code image is displayed in the display area when the setting for performing the automatic adjustment is made on the terminal based on the setting for the automatic adjustment, but is not displayed in the display area when the setting for performing the automatic adjustment is not made on the terminal.
How to process information. In the first paragraph,
The first code image includes a second code image based on the first information displayed in the first area of the display area, and a third code image based on the visual information displayed in the second area of the display area.
How to process information. In the first paragraph,
The above first code image is one code image based on the first information and the visual information.
How to process information. In any one of claims 1 to 3,
The payment is made based on the first code image being read by a code reading device, the first information and the visual information being sent to the server, and the payment is executed by the server based on the first information and the visual information.
How to process information. In paragraph 4,
The payment is executed by the server based on the visual information and the visual information based on the reading of the first code image by the code reading device.
How to process information. In paragraph 5,
The above payment is executed by the server when the visual information and the visual information based on the reading of the first code image by the code reading device are within the validity period set by the server.
How to process information. delete In any one of claims 1 to 3,
Including obtaining information about the reference time from the above server by the above control unit,
The above visual information is information based on information about the reference time.
How to process information. In any one of claims 1 to 3,
Based on the completion of the payment based on the first information, receiving second information different from the first information through the communication unit,
Including storing the received second information in the storage unit,
How to process information. In paragraph 9,
Including transmitting the second information through the communication unit based on the communication status of the communication unit,
How to process information. In paragraph 10,
In the case where communication is performed by the communication unit, including transmitting information for obtaining the second information to the server through the communication unit,
How to process information. In paragraph 10,
The second information is transmitted by push from the server.
How to process information. In any one of claims 1 to 3,
Receiving second information different from the first information through the communication unit based on an input regarding an update of the balance of electronic money available for payment by the terminal user;
Including storing the received second information in the storage unit,
How to process information. In any one of claims 1 to 3,
Including displaying the balance information of electronic money available for the above payment in the display area,
How to process information. In paragraph 14,
Based on the communication status of the communication unit, the control unit receives the balance information from the server through the communication unit,
Including displaying the received balance information in the display area,
How to process information. In paragraph 14,
Including displaying information about the date on which the balance information is displayed in the display area, or information about the time on which the balance information is displayed in the display area, in the display area.
How to process information. In paragraph 14,
Based on the input regarding the modification of the balance information, including modifying the balance displayed in the display area,
How to process information. In paragraph 14,
Including displaying a display for updating the balance information by input from the terminal user in the display area,
How to process information. In the first paragraph,
Displaying the balance information of electronic money available for the above payment in the above display area, and
Displaying a display for updating the balance information by the terminal user input in the display area,
Displaying the first code image in the third area of the display area, and displaying the balance information in the fourth area of the display area;
Based on an input by the terminal user for a display for updating the balance information, including updating the balance information displayed in the fourth area while the first code image is displayed in the third area,
How to process information. In any one of paragraphs 1 to 3 and paragraph 19,
Acquiring information about the terminal user by the control unit,
Based on the information about the acquired terminal user, the process of authenticating the user is executed by the control unit,
Based on the processing for authenticating the user, including executing the processing related to the payment by the control unit,
How to process information. In any one of paragraphs 1 to 3 and paragraph 19,
Acquiring information for skipping the authentication process of the terminal user by the control unit,
In the case where the information for skipping is acquired, the processing related to authentication of the terminal user is skipped and the first code image is displayed in the display area, and in the case where the information for skipping is not acquired, the processing related to authentication of the terminal user is performed and the first code image is displayed in the display area.
How to process information. A program stored in a computer-readable storage medium, which is executed by a computer of a terminal that executes processing related to the payment based on first information for making a payment by code image,
Receiving the first information transmitted from the server through the communication unit of the terminal,
Storing the received first information in the storage unit of the terminal,
Including displaying the first information and the first code image based on the visual information in the display area of the terminal,
The above visual information includes visual information based on the display of the first code image in the display area,
The above payment is executed by the server based on the first information and the visual information received by the server based on the display of the first code image,
The setting for automatic adjustment of the time of the above terminal is executed by the above terminal,
The above first code image is displayed in the display area when the setting for performing the automatic adjustment is made on the terminal based on the setting for the automatic adjustment, but is not displayed in the display area when the setting for performing the automatic adjustment is not made on the terminal.
A program stored on a computer-readable storage medium. A terminal that executes processing related to payment based on first information for making payment by code image,
A communication unit that receives the first information transmitted from the server,
A control unit that controls storing the received first information in the storage unit of the terminal,
A display unit is provided that displays a first code image based on the first information and visual information,
The above visual information includes visual information based on the display of the first code image on the display unit,
The above payment is executed by the server based on the first information and the visual information received by the server based on the display of the first code image,
The setting for automatic adjustment of the time of the above terminal is executed by the above control unit,
The above first code image is displayed on the display unit when the setting for performing the automatic adjustment is made on the terminal based on the setting for the automatic adjustment, but is not displayed on the display unit when the setting for performing the automatic adjustment is not made on the terminal.
Terminal. A terminal that executes processing related to payment based on first information for making payment by code image,
A processor is provided that reads the program from a memory storing the program and executes processing based on the program.
The above processor,
Receiving the first information transmitted from the server through the communication unit of the terminal,
Storing the received first information in the storage unit of the terminal,
Executing the process of displaying the first code image based on the first information and the visual information in the display area of the terminal,
The above visual information includes visual information based on the display of the first code image in the display area,
The above payment is executed by the server based on the first information and the visual information received by the server based on the display of the first code image,
The setting for automatic adjustment of the time of the above terminal is executed by the above processor,
The above first code image is displayed in the display area when the setting for performing the automatic adjustment is made on the terminal based on the setting for the automatic adjustment, but is not displayed in the display area when the setting for performing the automatic adjustment is not made on the terminal.
Terminal. An information processing method of a server that executes the payment of a terminal that performs processing related to the payment based on first information for making a payment by code image,
Transmitting the first information to the terminal through the communication section of the server,
Based on the first information displayed in the display area of the terminal and the first code image based on visual information being read by the code reading device, receiving the first information and the visual information based on the first code image transmitted from the code reading device through the communication unit,
Including performing the payment based on the first information, the visual information and the visual information based on the reading of the first code image by the code reading device,
The above visual information includes visual information based on the display of the first code image in the display area,
The setting for automatic adjustment of the time of the above terminal is executed by the above terminal,
The above first code image is displayed in the display area when the setting for performing the automatic adjustment is made on the terminal based on the setting for the automatic adjustment, but is not displayed in the display area when the setting for performing the automatic adjustment is not made on the terminal.
How to process information. An information processing method of a terminal that executes processing related to payment based on first information for making payment by code image,
Receiving the first information transmitted from the server through the communication unit of the terminal,
Storing the received first information in the storage unit of the terminal by the control unit of the terminal,
Including displaying a first code image based on the first information and second information different from the first information in the display area of the terminal,
The above payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image,
After the payment is completed based on the first information, the terminal receives third information for payment using a code image, which is different from the first information, based on the communication status of the communication unit, and stores the received third information in the storage unit by the control unit.
The second information is identification information for identifying the terminal or the user of the terminal.
How to process information. In paragraph 26,
The first code image includes a second code image based on the first information displayed in the first area of the display area, and a third code image based on the second information displayed in the second area of the display area.
How to process information. In paragraph 26,
The above first code image is one code image based on the first information and the second information.
How to process information. In any one of paragraphs 26 to 28,
The payment is made based on the first code image being read by a code reading device, the first information and the second information being transmitted to the server, and the payment is executed by the server based on the first information and the second information.
How to process information. In paragraph 29,
The above payment is executed by the server based on the second information and the fourth information associated with the first information and stored in the server.
How to process information. In paragraph 30,
The above payment is executed by the server when the second information and the fourth information match.
How to process information. In any one of paragraphs 26 to 28,
The third information is transmitted from the server.
How to process information. delete delete delete delete In any one of paragraphs 26 to 28,
In the case where communication is performed by the communication unit, including transmitting information for obtaining the third information to the server through the communication unit,
How to process information. In any one of paragraphs 26 to 28,
The third information is transmitted by push from the server.
How to process information. In any one of paragraphs 26 to 28,
Based on the input regarding the update of the balance of electronic money available for payment by the terminal user, the third information is received through the communication unit.
How to process information. In any one of paragraphs 26 to 28,
Including displaying the balance information of electronic money available for the above payment in the display area,
How to process information. In paragraph 40,
Based on the communication status of the communication unit, the control unit receives the balance information from the server through the communication unit,
Including displaying the received balance information in the display area,
How to process information. In paragraph 40,
Including displaying information about the date on which the balance information is displayed in the display area, or information about the time on which the balance information is displayed in the display area, in the display area.
How to process information. In paragraph 40,
Based on the input regarding the modification of the balance information, including modifying the balance displayed in the display area,
How to process information. In paragraph 40,
Including displaying a display for updating the balance information by input from the terminal user in the display area,
How to process information. In paragraph 26,
Displaying the balance information of electronic money available for the above payment in the above display area, and
Displaying a display for updating the balance information by the terminal user input in the display area;
Displaying the first code image in the third area of the display area, and displaying the balance information in the fourth area of the display area;
Based on an input of the terminal user for a display for updating the balance information, including updating the balance information displayed in the fourth area while the first code image is displayed in the third area,
How to process information. In any one of paragraphs 26 to 28 and paragraph 45,
Acquiring information about the terminal user by the control unit,
Based on the information about the acquired terminal user, the process of authenticating the user is executed by the control unit,
Based on the processing for authenticating the user, including executing the processing related to the payment by the control unit,
How to process information. In any one of paragraphs 26 to 28 and paragraph 45,
Acquiring information for skipping the authentication process of the terminal user by the control unit,
In the case where the information for skipping is acquired, the processing related to authentication of the terminal user is skipped and the first code image is displayed in the display area, and in the case where the information for skipping is not acquired, the processing related to authentication of the terminal user is performed and the first information is displayed in the display area.
How to process information. A program stored in a computer-readable storage medium, which is executed by a computer of a terminal that executes processing related to the payment based on first information for making a payment by code image,
Receiving the first information transmitted from the server through the communication unit of the terminal,
Storing the received first information in the storage unit of the terminal,
Including displaying a first code image based on the first information and second information different from the first information in the display area of the terminal,
The above payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image,
After the payment is completed based on the first information, the terminal receives third information for payment using a code image, which is different from the first information, based on the communication status of the communication unit, and stores the received third information in the storage unit by the control unit of the terminal.
The second information is identification information for identifying the terminal or the user of the terminal.
A program stored on a computer-readable storage medium. A terminal that executes payment processing based on first information for payment by code image,
A communication unit that receives the first information transmitted from the server,
A control unit that controls storing the received first information in the storage unit of the terminal,
A display unit is provided that displays a first code image based on the first information and second information different from the first information.
The above payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image,
After the payment is completed based on the first information, third information for payment using a code image, different from the first information, is received by the communication unit based on the communication status of the communication unit,
The received third information is stored in the storage unit by the control unit,
The second information is identification information for identifying the terminal or the user of the terminal.
Terminal. A terminal that executes payment processing based on first information for payment by code image,
A processor is provided that reads the program from the memory where the program is stored and executes processing based on the program.
The above processor,
Receiving the first information transmitted from the server through the communication unit of the terminal,
Storing the received first information in the storage unit of the terminal,
Executing a method of displaying a first code image based on the first information and second information different from the first information in the display area of the terminal,
The above payment is executed by the server based on the first information and the second information received by the server based on the display of the first code image,
The processor causes the terminal to receive third information for payment using a code image, which is different from the first information, based on the communication status of the communication unit after the payment is completed based on the first information, and to store the received third information in the storage unit by the control unit of the terminal.
The second information is identification information for identifying the terminal or the user of the terminal.
Terminal. An information processing method of a server that executes the payment of a terminal that performs processing related to the payment based on first information for making a payment by code image,
Transmitting the first information to the terminal through the communication section of the server,
Based on the first information displayed in the display area of the terminal and the second information different from the first information, the first code image is read by the code reading device, and the first information and the second information based on the first code image transmitted from the code reading device are received through the communication unit,
Including performing the payment based on the first information, the second information, and the third information stored in the storage of the server and related to the first information,
After the payment is completed based on the first information, the terminal receives third information for payment using a code image, which is different from the first information, based on the communication status of the communication unit of the terminal, through the communication unit of the terminal, and stores the received third information in the storage unit of the terminal through the control unit of the terminal.
The second information is identification information for identifying the terminal or the user of the terminal.
How to process information.