JP7761985B2 - Program, information processing method, terminal - Google Patents

Description

This disclosure relates to information processing methods, programs, terminals, and servers.

Recently, services that use applications that can be executed on devices such as smartphones to manage the device or the device user's electronic currency (electronic money) and enable payments using electronic currency are becoming increasingly popular. For example, Patent Document 1 discloses technology for settling the purchase amount of goods. However, payments using electronic currency can be inconvenient in some cases, for example, due to the device's communication environment or communication conditions, making them inconvenient to use.

Japanese Patent Application Laid-Open No. 2002-176671

According to a first aspect of the present invention, a program executed by a terminal that executes processing related to payment based on code information receives first code information associated with a first expiration date by the server from the server via a communication unit of the terminal, stores the received first code information in a memory unit of the terminal by a control unit of the terminal, and executes processing related to payment based on the first code information by the control unit, and the payment is executed by the server based on the time based on the processing related to payment and the first expiration date.
According to a second aspect of the present invention, an information processing method for a terminal that executes processing related to payment based on code information includes receiving first code information associated with a first expiration date by the server from the server via a communication unit of the terminal, storing the received first code information in a memory unit of the terminal, and executing processing related to payment based on the first code information, wherein the payment is executed by the server based on a time based on the processing related to payment and the first expiration date.
According to a third aspect of the present invention, a terminal that executes a payment-related process based on code information includes a communication unit that receives, from a server, first code information associated with a first expiration date by the server, and a control unit that controls the storage of the received first code information in a memory unit of the terminal, and the control unit executes the payment-related process based on the first code information, and the payment is executed by the server based on the time based on the payment-related process and the first expiration date.
According to a fourth aspect of the present invention, a terminal that executes processing related to payment based on code information includes a processor that reads a program stored in memory and executes processing based on the program, and the processor executes a process of receiving first code information associated with a first expiration date by the server from the server via a communication unit of the terminal, a process of storing the received first code information in memory, and a process related to payment based on the first code information, and the payment is executed by the server based on the time based on the processing related to payment and the first expiration date.
According to a fifth aspect of the present invention, a program executed by a server that manages payments based on code information is executed by the server to associate first code information with a first expiration date and store the first code information in a memory unit of the server by a control unit of the server, transmit the first code information to a terminal that performs processing related to the payment via a communication unit of the server, receive the first code information and information on the time based on the processing related to the payment performed based on the first code information via the communication unit, and perform processing of the payment by the control unit based on the first expiration date associated with the received first code information and the time based on the processing related to the payment.
According to a sixth aspect of the present invention, an information processing method of a server that manages payments based on code information includes associating first code information with a first expiration date and storing them in a memory unit of the server, transmitting the first code information to a terminal that performs processing related to the payment via a communication unit of the server, receiving the first code information and information on the time based on the processing related to the payment performed based on the first code information via the communication unit, and processing the payment based on the first expiration date associated with the received first code information and the time based on the processing related to the payment.
According to a seventh aspect of the present invention, a server that manages payments based on code information includes a memory unit that stores first code information and a first expiration date in association with each other, a communication unit that transmits the first code information to a terminal that performs payment-related processing and receives the first code information and information on the time based on the payment-related processing performed based on the first code information, and a control unit that performs payment processing based on the first expiration date associated with the received first code information and the time based on the received payment-related processing.
According to an eighth aspect of the present invention, a server that manages payments based on code information includes a processor that reads a program stored in a memory and executes processing based on the program, and the processor executes the following processes: a process of associating first code information with a first expiration date and storing them in memory; a process of transmitting the first code information to a terminal that performs processing related to the payment and receiving information on the first code information and the time based on the processing related to the payment performed based on the first code information; and a process of payment based on the first expiration date associated with the received first code information and the time based on the processing related to the payment.

FIG. 1 is a diagram illustrating an example of the configuration of a communication system according to an embodiment. FIG. 1 is a diagram illustrating an example of a system configuration of a store POS system according to an embodiment. 10 is a flowchart showing an example of the flow of processes executed by various devices according to an embodiment. FIG. 10 is a diagram illustrating an example of a display screen of a terminal according to an embodiment. FIG. 10 is a diagram illustrating an example of a display screen of a terminal according to an embodiment. 10 is a flowchart showing an example of the flow of processes executed by various devices according to an embodiment. FIG. 3 is a diagram showing an example of functions realized by a control unit of the server according to the first embodiment. FIG. 4 is a diagram showing an example of information stored in a storage unit of the server according to the first embodiment. FIG. 4 is a diagram showing an example of user registration data according to the first embodiment. FIG. 4 is a diagram showing an example of store registration data according to the first embodiment. FIG. 2 is a diagram showing an example of a payment management database according to the first embodiment. FIG. 3 is a diagram showing an example of a code management database according to the first embodiment. FIG. 2 is a diagram showing an example of functions realized by a control unit of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of information stored in a storage unit of the terminal according to the first embodiment. FIG. 10 is a diagram showing an example of code stock data for first terminal display according to the first embodiment. FIG. 10 is a diagram showing an example of payment data according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. FIG. 4 is a diagram showing an example of a display screen of the terminal according to the first embodiment. 4 is a flowchart showing an example of the flow of processing executed by various devices according to the first embodiment. FIG. 10 is a diagram showing an example of second terminal display code stock data according to the first modified example. FIG. 10 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 10 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 10 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 10 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 10 is a diagram showing an example of a display screen of a terminal according to a first modified example. FIG. 10 is a diagram showing an example of a display screen of a terminal according to a first modified example. 4 is a flowchart showing an example of the flow of processing executed by various devices according to the first embodiment. FIG. 10 is a diagram showing an example of information stored in a storage unit of a terminal according to a second embodiment. 10 is a flowchart showing an example of the flow of processes executed by various devices according to the second embodiment. FIG. 11 is a diagram showing an example of information stored in a storage unit of a terminal according to a second modified example. FIG. 10 is a diagram showing an example of code update condition data according to a second modified example. 10 is a flowchart showing an example of the flow of processes executed by various devices according to a second modified example. FIG. 11 is a diagram showing an example of information stored in a storage unit of a server according to a third embodiment. FIG. 13 is a diagram showing an example of an account management database according to the third embodiment. 13 is a flowchart showing an example of a first code display process according to the fourth embodiment. 13 is a flowchart showing an example of a second code display process according to the fourth embodiment. 13 is a flowchart showing an example of a third code display process according to the fourth embodiment. FIG. 13 is a diagram showing an example of a code management database according to the fifth embodiment.

<Compliance with legal matters>
It should be noted that the disclosures set forth herein are subject to compliance with the laws of the country of implementation, such as communications privacy, as required for the implementation of the disclosures.

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

[System configuration]
FIG. 1 is a diagram illustrating an example of a configuration of a communication system 1 according to an embodiment of the present disclosure.
As shown in FIG. 1, in the communication system 1, a server 10, terminals 20 (terminal 20A, terminal 20B, terminal 20C, . . . ), and a store POS system 40 are connected via a network 30.

The server 10 provides a service to enable users' terminals 20 to send and receive content, including messages, between terminals 20 via the network 30. The server 10 also provides a service (hereinafter referred to as a "payment service") that communicates with the terminals 20 to enable electronic payments (an example of payment, but not limited to these). There is no limit to the number of terminals 20 that can be connected to the network 30.

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 communications network that provides connection paths so that the various devices mentioned above can connect and send and receive data.

One or more portions of network 30 may or may not be a wired network or a wireless network. Network 30 may include, by way of example and not limitation, an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (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), wireless LAN, long term evolution (LTE), code division multiple access (CDMA), Bluetooth (registered trademark), satellite communications, etc., or a combination of two or more thereof. Network 30 may include one or more networks 30.

Terminal 20 (terminal 20A, terminal 20B, terminal 20C, ...) (not limited to, examples of terminals or information processing devices) may be any information processing terminal capable of implementing the functions described in each embodiment. Terminal 20 includes, but is not limited to, smartphones, mobile phones (feature phones), computers (not limited to, for example, desktops, laptops, tablets, etc.), media computer platforms (not limited to, for example, cable or satellite set-top boxes, digital video recorders, etc.), handheld computing devices (not limited to, for example, personal digital assistants (PDAs), email clients, etc.), wearable devices (glasses-type devices, watch-type devices, etc.), or other types of computers or communication platforms. Terminal 20 may also be referred to as an information processing terminal.

Because terminals 20A, 20B, and 20C are basically configured the same, the following description will focus on terminal 20. Where necessary, the terminal used by user X will be referred to as terminal 20X, and user information for a specified service associated with user X or terminal 20X will be referred to as user information X. User information is user information associated with the account used by the user for a specified service. User information includes, by way of example and not limitation, information associated with the user, such as the user's name, user icon image, user age, user gender, user address, user hobbies and interests, and user identifier, which is input by the user or assigned by the specified service, and may be any one or a combination of these.

The server 10 (which is an example, but not limited to, of a server, information processing device, or information management device) has the function of providing a predetermined service to the terminal 20. The server 10 may be any information processing device capable of implementing the functions described in each embodiment. Examples of the server 10 include, but are not limited to, a server device, a computer (such as, but not limited to, a desktop, laptop, or tablet), a media computer platform (such as, but not limited to, a cable or satellite set-top box or digital video recorder), a handheld computer device (such as, but not limited to, a PDA or email client), or other types of computers or communication platforms. The server 10 may also be referred to as an information processing device. If there is no need to distinguish between the server 10 and the terminal 20, the server 10 and the terminal 20 may or may not each be referred to as an information processing device.

In the embodiment described below, the server 10 is described as having the function of providing payment services using a payment application.

The store POS system 40 is a POS system that is introduced and used in a store that is affiliated with the business that operates the server 10 .
The store POS system 40 includes, by way of example and not limitation, a store code reader device 50, a code register 60, and a store server 70.

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

(1) HW Configuration of Terminal FIG. 1 shows an example of the HW configuration of the terminal 20.
The terminal 20 includes a control unit 21 (CPU: central processing unit), a memory 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. The HW components of the terminal 20 are connected to each other via a bus B, for example and not as a limitation. It is not essential that the HW configuration of the terminal 20 includes all of the components. For example and not as a limitation, the terminal 20 may or may not be configured such that individual components, such as the microphone 25, the camera 27, or multiple components, are detachable.

The communication I/F 22 sends and receives various data via the network 30. Communication may be performed either wired or wirelessly, and any communication protocol may be used as long as mutual communication is possible. The communication I/F 22 has the function of communicating with various devices, such as the server 10, via the network 30. The communication I/F 22 transmits various data to various devices, such as the server 10, in accordance with instructions from the control unit 21. The communication I/F 22 also receives various data transmitted from various devices, such as the server 10, and transmits it to the control unit 21. The communication I/F 22 may also be simply referred to as a communication unit. Furthermore, if the communication I/F 22 is configured as a physically structured circuit, it may also be referred to 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 the results of processing performed by the terminal 20. The input/output unit 23 may be an integrated input unit and an output unit, or may be separate input and output units, or may not be so.

The input unit is realized by any one or combination of devices of any type that can accept input from a user and transmit information related to the input to the control unit 21. Examples of input units include, but are not limited to, hardware keys such as a touch panel, touch display, and keyboard, pointing devices such as a mouse, a camera (for inputting operations via moving images), and a microphone (for inputting operations via voice).

The output unit may be any one or a combination of any type of device capable of outputting the results of processing performed by the control unit 21. Examples of output units include, but are not limited to, touch panels, touch displays, speakers (audio output), lenses (for example, but not limited to, 3D (three dimensions) output and hologram output), printers, etc.

The display unit 24 is realized by any one of or a combination of any type of device capable of displaying according to the display data written to the frame buffer. Examples of the display unit 24 include, but are not limited to, touch panels, touch displays, monitors (such as, but not limited to, liquid crystal displays and organic electroluminescence displays (OLEDs)), head-mounted displays (HDMs), projection mapping, holograms, and devices capable of displaying images, text information, etc. in air (which may or may not be a vacuum). Note that these display units 24 may or may not be capable of displaying display data in 3D.

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 and have 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 configured, for example and without limitation, with a clock that uses a quartz oscillator. The clock unit 29A can also be referred to, for example and without limitation, as a timekeeping unit or a time information detection unit.

Note that the clock unit 29A may or may not have a clock that conforms to the NITZ (Network Identity and Time Zone) standard or the like.

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

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

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

The inertial measurement unit has an inertial sensor that detects information necessary to calculate the position of the terminal 20 using inertial navigation calculations. Examples of inertial sensors include, but are not limited to, a three-axis acceleration sensor and a three-axis gyro sensor, and output the acceleration detected by the acceleration sensor and the angular velocity detected by the gyro sensor as information for position calculation.

The control unit 21 has circuits physically structured to execute the functions realized by the code or instructions contained in the program, and is realized, for example and without limitation, by a data processing device built into hardware. As such, the control unit 21 may or may not be described as a control circuit.

The control unit 21 may include, by way of example and not limitation, a central processing unit (CPU), a microprocessor, a processor core, a multiprocessor, an application-specific integrated circuit (ASIC), or 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, but is not limited to, 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). Furthermore, the storage unit 28 may or may not be referred to as memory.

The terminal 20 stores the program P in the memory unit 28, and by executing this program P, the control unit 21 executes the processing of each unit included in the control unit 21. In other words, the program P stored in the memory unit 28 causes the terminal 20 to realize each function executed by the control unit 21. Furthermore, this program P may or may not be expressed as a program module.

The microphone 25 is used to input audio data. The speaker 26 is used to output audio data. The camera 27 is used to acquire video data.

(2) HW Configuration of Server FIG. 1 shows an example of the HW configuration of the server 10. As shown in FIG.
The server 10 includes 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. The components of the HW of the server 10 are connected to each other via a bus B, for example and not as a limitation. Note that the HW of the server 10 does not necessarily have to include all the components as a configuration of the HW of the server 10. For example and not as a limitation, the HW of the server 10 may or may not be configured such that the display 13 is detachable.

The control unit 11 has circuits physically structured to execute the functions realized by the code or instructions contained in the program, and is realized, for example but not limited to, by a data processing device built into hardware.

The control unit 11 is typically a central processing unit (CPU), but may also be a microprocessor, processor core, multiprocessor, ASIC, or FPGA, or may not be one of these. In this disclosure, 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 an HDD, SSD, or flash memory. However, in this disclosure, the storage unit 15 is not limited to these. Furthermore, the storage unit 15 may or may not be referred to as memory.

The communication I/F 14 sends and receives various data via the network 30. Communication may be performed either wired or wirelessly, and any communication protocol may be used as long as mutual communication is possible. The communication I/F 14 has the function of communicating with various devices such as the terminal 20 via the network 30. The communication I/F 14 transmits various data to various devices such as the terminal 20 in accordance with instructions from the control unit 11. The communication I/F 14 also receives various data transmitted from various devices such as the terminal 20 and transmits it to the control unit 11. The communication I/F 14 may also be simply referred to as a communication unit. If the communication I/F 14 is configured as a physically structured circuit, it may also be referred to 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 combination of all types of devices that can accept input from a user and transmit information related to 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. Note that the input/output unit 12 may or may not include, for example and without limitation, a touch panel, a camera (for inputting operations via video images), or a microphone (for inputting operations via voice). However, in the present disclosure, the input/output unit 12 is not limited to these.

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

The clock unit 19 is a built-in clock of the server 10 and outputs time information (timekeeping information). The clock unit 19 is configured to include, for example and without limitation, an RTC (Real Time Clock) as a hardware clock, a system clock, etc. The clock unit 19 can also be referred to as, for example and without limitation, a timekeeping unit or a time information detection unit.

(3) System Configuration of Store POS System FIG. 2 shows an example of the system configuration of the store POS system 40. As shown in FIG.
The store POS system 40 is a POS system that is installed and used in a store that is affiliated with the business that operates the server 10, and includes, by way of example and not 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 the code register 60 and store server 70 via a POS communication I/F 57 (for example, but not limited to, a wired communication I/F or wireless communication I/F within the store), and reads the terminal display code image displayed on the display unit 24 of the terminal 20 during a transaction at the code register 60. Based on the terminal display code image read, it then sends payment request information to the server 10 via the communication I/F 54, and after the payment is made on the server 10, it receives information regarding the payment result (for example, a store payment completion notification, described below) from the server 10 via the communication I/F 54.

The store code reader device 50 includes, by way of example and not limitation, a control unit 51, an input/output unit 52, a display unit 53, a communication I/F 54, a memory 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 two-dimensional codes, and in this specification includes a two-dimensional code reader (e.g., a QR code reader) for reading a terminal display code such 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.

By way of example and not limitation, the code register 60 is communicatively connected to the store code reader device 50 and store server 70 via the POS communication I/F 57, and issues a receipt on which information such as the total amount of the items sold and the electronic currency balance of the user of the terminal 20 is printed, based on the store payment completion notification received by the store code reader device 50 from the server 10. Also, by way of example and not limitation, the code register 60 may be provided integrally with or separately from the code register 60, forming a display with its display surface facing the customer. The code register 60 is a cash register configured to be compatible with payment applications, and can also be referred to as a payment application-compatible stationary 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 at the store, information about services provided at the store, and information about sales revenue from the sale of products and the provision of services at the store. The store server 70 is configured to be able to communicate with the store code reader device 50 and code register 60 via the POS communication I/F 57, and is also configured to be able to communicate with external devices such as the server 10 via the network 30.

The store server 70 does not necessarily need to be configured to be able to communicate directly with the store code reader device 50; it may be configured to be able to communicate with the store code reader device 50 via the code register 60. For example, the store payment completion notification received by the store code reader device 50 from the server 10 can be sent to the code register 60, and then sent from the code register 60 to the store server 70.

(4) Others The server 10 stores the program P in the storage unit 15, and by executing this program P, the control unit 11 executes the processes of each unit included in the control unit 11. In other words, the program P stored in the storage unit 15 causes the server 10 to realize each function executed by the control unit 11. This program P may or may not be expressed as a program module.
The same applies to other devices.

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

The control unit 21 of the terminal 20 and/or the control unit 11 of the server 10 may or may not realize each process not only by a CPU having a control circuit, but also by a logic circuit (hardware) formed in an integrated circuit (IC (Integrated Circuit) chip, LSI (Large Scale Integration)), or a dedicated circuit. These circuits may be realized by one or more integrated circuits, and multiple processes shown in each embodiment may or may not be realized by a single integrated circuit. LSIs are sometimes referred to as VLSIs, super LSIs, ultra LSIs, etc., depending on the level of integration. Therefore, the control unit 21 may or may not be referred to as a control circuit.
The same applies to other devices.

Furthermore, the program P (which may be, for example and not by way of limitation, a software program, computer program, or program module) of each embodiment of the present disclosure may or may not be provided in a state stored on a computer-readable storage medium. The storage medium may store the program P on a "non-transitory tangible medium." Furthermore, the program P may or may not be intended to realize part of the functions of each embodiment of the present disclosure. Furthermore, the program P may or may not be a so-called differential file (differential program) that can realize the functions of each embodiment of the present disclosure in combination with a program P already recorded on a storage medium.

The storage medium may include one or more semiconductor-based or other integrated circuits (ICs) (such as, by way of example and not limitation, a field programmable gate array (FPGA) or an application-specific IC (ASIC)), a hard disk drive (HDD), a hybrid hard drive (HHD), an optical disk, an optical disk drive (ODD), a magneto-optical disk, a magneto-optical drive, a floppy diskette, a floppy disk drive (FDD), a magnetic tape, a solid-state drive (SSD), a RAM drive, a secure digital card, or a drive, 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. Note that the storage medium is not limited to these examples and may be any device or medium capable of storing the program P. Furthermore, the storage medium may or may not be referred to as memory.

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

Furthermore, the program P of the present disclosure may or may not be provided to the server 10 and/or the terminal 20 via any transmission medium capable of transmitting a program (such as a communication network or broadcast waves). For example and not by way of limitation, the server 10 and/or the terminal 20 executes the program P downloaded via the Internet or the like to realize the functions of the multiple functional units shown in each embodiment.
The same applies to other devices.

In addition, each embodiment of the present disclosure may be realized in the form of a data signal in which the program P is embodied by electronic transmission.
At least a part of the processing in the server 10 and/or the terminal 20 may or may not be realized by cloud computing configured by one or more computers.
At least a part of the processing in the terminal 20 may or may not be performed by the server 10. In this case, at least a part of the processing of each functional unit of the control unit 21 of the terminal 20 may or may not be performed by the server 10.
At least a part of the processing in the server 10 may or may not be performed by the terminal 20. In this case, at least a part of the processing of each functional unit of the control unit 11 of the server 10 may or may not be performed by the terminal 20.
Unless explicitly stated otherwise, the judgment configuration in the embodiments of the present disclosure is not essential, and a predetermined process may or may not be performed when the judgment condition is met, or when the judgment condition is not met.

The programs disclosed herein may be implemented using, but are not limited to, scripting languages such as ActionScript and JavaScript (registered trademark), compiler languages such as Objective-C and Java (registered trademark), and markup languages such as HTML5.

Furthermore, the expression "through a communication I/F" is used where appropriate in this specification. This indicates, by way of example and not limitation, that a device sends and receives various information and data via a communication I/F (via a communication unit) based on the control of a control unit (e.g., a processor).

In addition, in this specification, the term "deadline" is explained as indicating a certain period of time. However, the term "period" may be used instead of the term "deadline."
The term "deadline" may also be used to mean the time or date when a period ends (a specific time or date).

First Example
In recent years, applications (application software) related to network services, such as applications for electronic payments using electronic currency (payment applications) and applications for transferring electronic currency (remittance applications), as well as payment applications that combine some or all of the functions of these applications, have become popular, and users of terminal 20 are now able to receive various services related to electronic currency using these applications.

The embodiment described below is an example, not a limitation, in which a user of terminal 20 makes a payment using a payment application stored and executed on terminal 20. Specifically, we propose a method that allows payments to be made appropriately even offline.

In the following, the business providing the payment service using the payment application will be referred to as the "payment service business." Note that the payment service business may or may not be referred to as the business providing the payment application or the business of server 10.

In the following description, it is assumed that the server 10 is operated and managed by the payment service provider. In the following description, the name of the payment application will be referred to as "Payment App" where appropriate.

The payment application may be provided by the server 10 as a standalone application without the functionality of a so-called messaging service (MS), or as a composite application with MS functionality. The messaging service may or may not include an instant messaging service (IMS), which enables the sending and receiving of content such as simple messages between terminals 20.

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

Note that MS (including IMS) can also be considered one form of SNS. Therefore, MS and SNS may or may not be distinguished.

In addition, stores that are affiliated with payment service providers are called "affiliated stores (affiliated stores)," and are shown in Figure 1 as "affiliated store S1," "affiliated store S2," etc.

Furthermore, "electronic currency" refers to electronic currency that is distinct from physical currency and is owned by a terminal 20 or a user of a terminal 20, and is managed by a payment application. "Payment" refers to electronic payment using this electronic currency.

Electronic currency may or may not be expressed as "electronic money" or "digital currency (digital currency)."
Furthermore, as "electronic currency (electronic money)" or "digital currency (digital money)", legal tender or virtual currency may be used.
Furthermore, "electronic currency (electronic money)" and "digital currency (digital money)" may include cryptocurrency (crypto assets).
Virtual currency may also include physical currency such as coupons.

<Payment method>
(1) Online Payment First, as one aspect, a method for online payment will be described with reference to a flowchart.

In the following, "online" means that the terminal 20 is able to communicate with the server 10, and "online state" means this online state. Furthermore, "online payment" means that payment is made by the server 10 while online.

In the following, it is assumed, by way of example and not limitation, that communication between terminal 20 and server 10 is achieved by a first communication method that uses a frequency band different from wireless LAN communication and is achieved via a base station or the like installed by a telecommunications company (communications carrier). The first communication method includes, by way of example and not limitation, packet communication (so-called mobile data communication on terminal 20).

Furthermore, a second communication method different from the first communication method may or may not be used as the communication method. Examples of the second communication method include, but are not limited to, wireless LAN (e.g., Wi-Fi (registered trademark)).

Furthermore, the ability of the terminal 20 and the server 10 to communicate using at least one of the first and second communication methods may or may not be defined as an "online state."

Figure 3-1 is a flowchart showing an example of the flow of processing executed by each device in this case. From the left, it shows an example of processing executed by the control unit 21 of the terminal 20, the control unit 51 of the store code reader device 50, and the control unit 11 of the server 10.

Each step in each process is indicated by a combination of an uppercase letter and a number, and the term "step" is omitted in this specification.
Furthermore, the flowcharts described below are merely examples of the processing in this embodiment, and some steps in the flowcharts described below may not be executed, or additional steps may be inserted.
The same applies to other flowcharts in this specification.

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

In the following, by way of example and not limitation, "code information" will be described as a concept including information stored in a code image by encoding or the like (hereinafter referred to as "original information" in the sense of the original information), and the "code image" in which the original information is stored. In other words, "code information" includes "original information" and "code image."
The "original information" may or may not be expressed as "encoded information" or "stored information."

Furthermore, in the following, when we refer to "code" as an example and not as a limitation, we will assume that it has substantially the same meaning as "code information."

However, these definitions are merely examples and are not intended to be limiting.
For example, the term "code information" may or may not be used to mean "original information."
Also, for example, the term "code" may or may not be used to mean "code image."

In this embodiment, an example of the above-mentioned source information is a "payment number," which is a random number of a predetermined number of digits that is uniquely generated by the server 10 for each terminal 20 that has sent the code generation request information, or for each user of the terminal 20. The payment number is information associated with the terminal 20 or the user of the terminal 20, and can also be considered information used for payment by the server 10.

Hereinafter, the payment code generated by server 10 based on the code generation request information will be referred to as the "terminal display code," and the code image of this terminal display code will be referred to as the "terminal display code image."

Details will be described later, but the terminal display code image stores the above-mentioned payment number.
The payment number and the terminal display code image are examples of “first information” for making a payment using a code image, and are transmitted from the server 10 .

The following describes an example in which the code generation request information is information requesting the server 10 to generate the above-mentioned terminal display code image. In other words, in this process, by way of example and not limitation, the terminal 20 requests the server 10 to generate a terminal display code image, and A110 transmits code generation request information requesting the generation of the terminal display code image to the server 10.

In addition, in this specification, the "terminal display code" is explained as a code used for payment with the payment type "terminal code display."
In the "terminal code display" payment type, when a user of the terminal 20 makes a payment at a store or the like, the user uses a payment application stored in the terminal 20 to present a terminal display code image displayed on the terminal 20 to a store clerk at the store's code register 60. The terminal display code image is then read by a store code reader device 50 or the like to complete the payment.
The terminal display code is a code (code image) that is presented by the user of the terminal 20 to a store clerk at a store or the like, and therefore can also be expressed as a "presentation code" or a "user presentation code."

The code generation request information sent by A110 may include, by way of example and not limitation, identification information for identifying the terminal 20 or the user of the terminal 20. For example, this may include terminal identification information (e.g., a terminal ID) for identifying the own terminal 20, user identification information (e.g., a user ID) for identifying the user of the own terminal 20, account information for the payment application (e.g., an application ID), etc.

When code generation request information is received from the terminal 20 via the communication I/F 14 (C110), the control unit 11 performs a terminal display code generation process (C120).

Specifically, by way of example and not limitation, a method (algorithm) for generating random numbers of a predetermined number of digits (for example, approximately 10 to 12 digits) is used to generate a random number of digits as a payment number. Then, by way of example and not limitation, a code image for terminal display is generated that includes at least the payment number as source information. More specifically, at least the payment number is encoded and visualized to generate a code image for terminal display represented by an image of a two-dimensional code (for example, a QR code). Furthermore, identification information for the terminal 20 or the user of the terminal 20 included in the received code generation request information is associated with the generated payment number and stored in the memory 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, by way of example and not limitation, causes the received terminal display code image to be displayed on the display unit 24.

After that, when the user of the terminal 20 presents the terminal display code image displayed on the display unit 24 to a store clerk or the like, 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 (B150).

Then, the control unit 51 accesses the server 10 via the communication I/F 54 using an application interface (API) associated with the payment application provided (distributed) by the payment service provider, and transmits payment request information to the server 10 via the communication I/F 54, the payment request information including at least the payment number obtained by decoding the read terminal display code image, identification information for identifying the store or store code reader device 50 (hereinafter referred to as "store identification information"), and the amount to be paid (hereinafter referred to as "planned payment amount") (B160).

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 (C170). Specifically, it determines whether the payment number included in the received payment request information is stored in the memory unit 15 in association with the identification information of the terminal 20 or the user of the terminal 20. If it is stored, it determines that "payment is possible" and makes the payment by subtracting the planned payment amount from the electronic currency balance (electronic currency 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 from the identification information stored in association with the payment number.

The control unit 11 then sends a store-specific payment completion notification (hereinafter referred to as the "store-specific payment completion notification") to the store code reader device 50 via the communication I/F 14 (C180). The store-specific payment completion notification includes, by way of example and not limitation, store-specific payment information such as a notice that the payment has been completed (successful), the date and time of the payment (payment date and time), and the amount paid (payment amount).

The control unit 11 also sends a terminal-specific payment completion notification (hereinafter referred to as the "terminal-specific payment completion notification") to the terminal 20 via the communication I/F 14 (C190). The terminal-specific payment completion notification includes, by way of example and not limitation, information that the payment has been completed (successful), as well as terminal-specific payment information such as the date and time of the payment (payment date and time), store identification information for the store where the payment was made (payment store identification information), and the amount paid (payment amount). The control unit 11 then terminates processing.

Here, when the payment by the server 10 is successful, the server 10 sends a store payment completion notice and a terminal payment completion notice, but there are cases where the server 10 is unable to perform the payment due to insufficient balance, etc. In this case, it is sufficient to send a notice to the effect that the payment could not be performed (for example, a payment error notice or a payment NG notice) to the store code reader device 50 and the terminal 20.
The same applies to other processes.

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

Furthermore, 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. The control unit 21 also causes the display unit 24 to display the payment result (A190). Then, the control unit 21 ends the processing.

FIG. 3B is a diagram showing an example of a top screen displayed by the payment application executed on the terminal 20.
This top screen is the display screen that appears when the payment application is launched, and the name of the payment application, "Payment APP," is displayed at the top of the screen. The balance (here, "3,000 yen") is displayed in a box below it, and next to it is a charge button for charging (adding) electronic currency. Also below that, multiple function icons corresponding to various functions of the payment application are displayed.

Of these functional icons, the icon labeled "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 user of the terminal 20, by way of example and not limitation, code generation request information is sent from the terminal 20 to the server 10, and a terminal display code is generated by the server 10. The generated terminal display code is then sent from the server 10 to the terminal 20, and the code display screen shown in Figure 3-3 is displayed on the display unit 24 of the terminal 20.

FIG. 3C is a diagram showing an example of the code display screen.
This code display screen displays the word "Code" at the top of the screen, and below that are the payment method, the points the user has, and a points tab for setting whether or not to use those points to make a payment.

Furthermore, below that, as code images of the terminal display code obtained from the server 10, a one-dimensional terminal display code image represented by a barcode and a two-dimensional terminal display code image QC0 represented by a QR code are displayed in different areas of the display screen. Also, as an example, a 12-digit payment number is displayed below the barcode.

In addition, in this example, the terminal display code displayed on the code display screen has a deadline for displaying the code (hereinafter referred to as the "code display deadline").

The code display period is, by way of example and not limitation, the period during which the terminal display code is displayed on the terminal 20. The code display period can be, by way of example and not limitation, "the period from the date and time the terminal display code is displayed (display begins) on the terminal until the code display time has elapsed." The code display time can be changed as appropriate, but, by way of example and not limitation, it can be set to "5 minutes."

Below the two-dimensional terminal display code image QC0, an update mark and the word update are displayed in countdown format along with the remaining time until the code display period expires. This remaining time is displayed based on the information measured by the clock unit 29A of the terminal 20.
When the remaining time reaches "0", the code display screen is closed and the terminal display code is hidden. If the user of terminal 20 subsequently wishes to make a payment, he or she will need to re-acquire the terminal display code from server 10.

The user of terminal 20 presents the code display screen shown in Figure 3-3 to a store clerk at the code register 60 within the code display deadline, and makes a payment by having the store code reader device 50 read the terminal display code image. In this case, the store code reader device 50 accesses the server 10 via the communication I/F 54 using the API or the like described above, and sends the information necessary for the payment to the server 10. The payment process is then carried out by the server 10.

So far, we have provided examples of processes for realizing online payments, but in order to apply the above processes, the terminal 20 and server 10 must be able to communicate (online state). Of course, the store code reader device 50 and server 10 must also be able to communicate.

However, when making a payment in a location with poor signal reception, such as underground, or when making a payment in a situation where the lines are congested, such as at an event venue, or when the amount of communication on the terminal 20 exceeds a certain amount over a certain period of time (e.g., one month) and communication or speed restrictions are imposed, it is conceivable that communication between the terminal 20 and the server 10 may become impossible (or difficult) to communicate, making it difficult to make a payment. Therefore, the following provides an example of a method for making a payment even in such cases.

(2) Offline Payment An offline payment method as one aspect of the method of the present disclosure will be described with reference to a flowchart.
In the following, "offline" means that the terminal 20 cannot communicate with the server 10, and "offline state" refers to this offline state. Also, "offline payment" means that payment is made by the server 10 in the offline state. Also, it is assumed that the store code reader device 50 can communicate with the server 10.

Figure 3-4 is a flowchart showing an example of the processing flow executed by each device in this case. The diagram should be interpreted in the same way as the flowchart described above.

The flowchart in Figure 3-4 is the flowchart in Figure 3-1 rewritten to offline specifications. It differs from the flowchart in Figure 3-1 in, for example and not by way of limitation, the processing steps in the online state (e.g., A240), the processing steps in the offline state (e.g., A250, B250, B280), and the processing steps when returning from the offline state to the 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 memory unit 28 (A240).

Here, "stock" means that the received terminal display code is stored in the storage unit 28 so that it can be used later.
In this specification, "stock" may be simply expressed as "storage." Storing a terminal display code may also be expressed as "storing the terminal display code in terminal display code stock data."

In this process, to enable offline payments, the terminal display code (in this example, a terminal display code image) obtained from the server 10 while online is stored in the memory unit 28 of the terminal 20. Then, when offline payment becomes necessary, the stored terminal display code can be used to make the payment without the need to communicate with the server 10.

A more specific explanation will be given below. Assume that the system goes offline after A240.
Here, the terminal 20 detects that it has gone offline by any of the following methods, for example and not by way of limitation.

(A) While the payment application is running on the terminal 20, the server 10 sends a connection confirmation request to the terminal 20 at regular or specific times, and the terminal 20 responds to the connection confirmation request by sending a connection response including identification information (e.g., an application ID) to the server 10. In this case, the control unit 21 of the terminal 20 determines that it has gone offline when it no longer receives a connection confirmation request from the server 10.

(B) While the payment application is running on the terminal 20, the terminal 20 sends a connection notification including identification information (e.g., an application ID) to the server 10 at regular or specific times, and the server 10 sends a connection confirmation to the terminal 20 in response to the connection notification. In an offline state, the terminal 20 cannot send a connection notification to the server 10. Therefore, as a non-limiting example, the control unit 21 of the terminal 20 determines that the terminal 20 has entered an offline state when it detects a connection notification transmission error.

Incidentally, the terminal 20 may, but is not limited to, use a library or application that acquires network connection status to acquire information about the communication status of its own terminal 20 and determine whether it has entered an offline state, but this is not a requirement.

In the offline state, when the terminal display code image stored in A240 is displayed on the display unit 24 (A250) and presented by the user to a store clerk or other person, 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). The control unit 51 then proceeds to B160.

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

After C180, the control unit 11 sends a terminal payment completion notification to the terminal 20 (C290). However, in an offline state, the terminal 20 cannot receive the terminal payment completion notification. When the terminal 20 returns to an online state, the terminal payment completion notification sent 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 above-described process is an example of a process for performing offline payment.
In offline payment, as described above, in the online state, the terminal display code generated by the server 10 is stored in the terminal 20. Then, when the terminal 20 goes offline, the stored terminal display code is used to make the payment.

Here, in offline payments, as described above, the terminal display code generated by the server 10 is stored on the terminal 20. In this case, there may be cases where the user of the terminal 20 keeps the stored terminal display code for a long period of time without using it. In such cases, the terminal 20, or the user of the terminal 20, and the terminal display code are associated (linked) for a long period of time.

As a result of this, there is a risk that, for example, a terminal display code stored on terminal 20 could be stolen by a hacker, or that when a code image of a terminal display code stored on terminal 20 is displayed on terminal 20, that code image could be photographed by a camera on another user's terminal 20, and used for fraudulent payments.

<Functional configuration>
(1) Functional Configuration of Server FIG. 4A is a diagram showing an example of functions realized by the control unit 11 of the server 10 in this embodiment.

The following example illustrates, by way of example and not limitation, a case in which a user of terminal 20 makes a payment using the payment application stored on terminal 20 with the aforementioned payment type "Display terminal code."

The server 10 has a payment management processing unit 111 as a function realized by the control unit 11.

The payment management processing unit 111 has the function of managing various information and data related to the payment application executed by the terminal 20, and executing payment management processing to manage payments made by the terminal 20 or the user of the terminal 20 using electronic currency, in accordance with the payment management processing program 151 stored in the memory 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 through a terminal display code generation process, a payment processing unit 1113 that executes payment through a payment process, and a code expiration date management processing unit 1115 that sets and manages the code expiration date, by way of example and not limitation.

The terminal display code generation processing unit 1111 generates a terminal display code image represented by a two-dimensional code, for example and not by way of limitation. A two-dimensional code is a display code that has information in both 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 and horizontally, and a stack-type code (hereinafter referred to as a "stack code") in which multiple one-dimensional codes (for example and not by way of limitation, barcodes) are stacked one on top of the other.

In this example, for simplicity, QR Code (registered trademark), a widely used example of a matrix code, will be used as an example of a terminal display code.

Note that, unlike this embodiment, matrix codes other than QR codes, such as SP codes, VeriCode, MaxiCode, CP codes, and Chameleon codes, may or may not be used. Also, instead of matrix codes, various stack codes may or may not be used.

Furthermore, the terminal display code generation processing unit 1111 may or may not generate a one-dimensional code (a barcode, for example and not limitation) as the terminal display code in addition to a two-dimensional code (a QR code, for example and not limitation). This is because some stores may not be able to read two-dimensional codes but may be able to read one-dimensional codes.

The payment processing unit 1113 has the function of performing payment processing based on, for example but not limited to, information sent from the store POS system 40 and information sent from the terminal 20.

FIG. 4B is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
The storage unit 15 stores, as a program, a payment management processing program 151 that is read by the control unit 11 and executed as payment management processing, as a non-limiting example.

Furthermore, the memory unit 15 stores, by way of example and not limitation, the following data: user registration data 153, store registration data 155, payment management database 157, and code management database 159.

The user registration data 153 is registration data of the terminal 20 that uses the payment service and the user of the terminal 20, and an example of the data configuration is shown in FIG. 4-3.
In the user registration data 153, for example, but not limited to, a user name, a terminal phone number, a terminal email address, an application ID, an authentication password, and other registration information are stored in association with each other.

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

The terminal phone number is the phone number of the terminal 20 of the user of this username, and the phone number of the terminal 20 registered when the user of the terminal 20 uses the payment application is stored.
The terminal email address is the email address of the terminal 20 of the user of this username, and the email address of the terminal 20 registered when the user of the terminal 20 uses the payment application is stored.
The terminal telephone number and the terminal email address are examples of identification information for identifying the terminal 20 (hereinafter referred to as "terminal identification information").

The application ID is the payment application account (account information) and is an ID that can identify the terminal 20 or the user of the terminal 20. As a non-limiting example, this application ID is a unique ID that is 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 terminal 20 of the user with this username, and the password set by the user is stored.

Note that payment authentication processing does not necessarily have to be performed, and it is possible to omit it. In this case, there is no need to store the authentication password in the user registration data 153.

Other registration information is other registration information for the user of this username, and includes, but is not limited to, a user icon image, which is image data of an icon used by the user in the payment application, and the user's profile.

The store registration data 155 is registration data of stores that are affiliated with the business that provides the payment application (the business of the server 10). An example of the data configuration of store registration data 155A, which is an example of this store registration data 155, is shown in FIG. 4-4.
In the store registration data 155A, for example, but not limited to, the business type, store name, store location information, store POS system information, and store ID are stored in association with each other as store information.

The business type of the store is stored in the business type field. Examples of business types include, but are not limited to, "convenience store," "supermarket," "pharmacy," "izakaya," "department store," "restaurant," "bookstore," and "watch shop."

For each industry, the store name stores the names of stores that belong to that industry.

Store location information stores location information for the location of the store with this store name (hereinafter referred to as "store location information"). This store location information may represent the store's location using two-dimensional or three-dimensional position coordinates, or it may represent the store's location using 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 necessary for the server 10 to communicate with the store code reader device 50 and the store server 70.

The store POS system 40 performs processing in conjunction with the server 10. For example, and not by way of limitation, a software package for a payment application provided (distributed) by the server 10 can be acquired in advance and stored in the store code reader device 50 or the store server 70, and this software package can then be called and used from the store's payment processing program. One example is an application programming interface (API), and the store code reader device 50 can, for example, activate the API to send information to and receive information from the server 10.

Furthermore, the server 10 can receive information such as, but not limited to, the store's industry, store name, store location information, store POS system information, etc. from the store's store server 70 and store it in the store registration data 155.

The store ID is an ID that functions as identification information for identifying the store of this store name. As an example, and not a limitation, the store ID is set and stored by the server 10 as a unique ID for each store.
The store ID is an example of store identification information.

The settlement management database 157 is a database that cumulatively stores data for managing information relating to settlements made by users of each terminal 20, and an example of the structure of a settlement management database 157A is shown in FIG. 4-5.
The settlement management database 157A stores settlement management data generated for each terminal 20 or for each user of the terminal 20.

Each payment management data may store, by way of example and not limitation, the application ID, balance, points, daily limit, auto-charge settings, and payment history data.

The application ID is stored as the application ID stored in the user registration data 153 .
The balance field stores the balance associated with this application ID.

Points are stored as points that can be accumulated through various services associated with the payment application or at affiliated stores affiliated with the payment application operator. By way of example and not limitation, points have a value equivalent to 1 yen per point and can be exchanged for gift certificates, merchandise, etc., or can be converted into cash in the payment application and used for payments.

The daily limit setting stores the maximum amount that can be used for payments by the terminal 20 that owns this application ID, or the user of the terminal 20.

The auto-charge setting is a setting for whether or not electronic currency is automatically replenished (auto-charged) when the balance is low (for example, "500 yen") or reaches "0 yen." If auto-charge is set by the user of terminal 20, "ON" is stored; otherwise, "OFF" is stored. As a non-limiting example, auto-charge can be performed from a bank account or the like registered by the user of terminal 20.

Payment history data is data related to the payment history of the user of this application ID. By way of example and not limitation, for this application ID, the payment date and time (the date and time when the payment was made by server 10), the store ID (the ID of the store where the payment was made), the payment store name (the name of the store associated with that store ID), and the payment amount (the amount paid) are stored in chronological order in association with each other.

It is not necessary to store all of the above information in the payment management data. For example, and not by way of limitation, some or all of the points, daily upper limit amount, and auto-charge settings may not be stored in the payment management data.
Furthermore, each time a payment is made, payment history information may be transmitted to the terminal 20 and stored in the terminal 20, and the server 10 may not store the payment history data.

The code management database 159 is a database for managing codes (terminal display codes in this embodiment), and an example of the data structure is shown in FIG.
The code management database 159 stores, by way of example and not limitation, code management data generated for each application ID of a payment application.

Each code management data stores an application ID, and by way of example and not limitation, the code generation date and time, code number, payment number, and code expiration date are associated and stored in chronological order.

The code generation date and time is stored as the date and time when the terminal display code was generated based on the information kept by the clock unit 19.
The code number stores a number for identifying the code. For example, serial numbers are set and stored in chronological order.
The settlement number stores the settlement number issued when the terminal display code is generated.

The code expiration date is the date by which a payment using the terminal display code is valid, and is managed by the server 10 for each generated terminal display code.
For example, the date and time when the server 10 generates a terminal display code is referred to as the "code generation date and time," and the validity period of the code set by the server 10 is referred to as the "code validity period." In this case, as a non-limiting example, the "period from the code generation date and time until the code validity period has elapsed" is set and stored as the code validity period by the code validity period management processing unit 1115.

The code expiration date is a period set by the server 10, and can also be considered the period during which payments can be made using the terminal display code.

Here, the code validity period can be changed as appropriate, but as a non-limiting example, it is possible to set the period to "6 hours,""12hours,""18hours," or "24 hours."
However, if the code validity period is set too long, the terminal 20 or the user of the terminal 20 will be associated (linked) with the terminal display code for a long period of time, which may result in the problems described above. For this reason, the code validity period may be set to around 24 hours at most.

As a non-limiting example, the data of the terminal display code stored in the code management data may be deleted from the code management data after a payment process is performed using the terminal display code.
Also, by way of example and not limitation, when the code expiration date associated with the terminal display code has passed, the terminal display code may be deleted from the code management data.

As described above, instead of deleting the data of unusable terminal display codes from the code management data, for example and not by way of limitation, a flag "Usable/Unusable" indicating whether the terminal display code can be used is set in association with the data of the terminal display code. Then, for terminal display codes that have become unusable, the flag may be set to "Unusable," but this is not required.

Furthermore, among the above, for example, the code generation date and time may not be stored in the code management data.
Furthermore, instead of or in addition to the application ID, terminal identification information such as a terminal telephone number stored in the user registration data 153 may or may not be stored in the code management data.

(2) Functional Configuration of Terminal FIG. 4-7 is a diagram showing an example of functions realized by the control unit 21 of the terminal 20 in this embodiment.
The terminal 20 has a payment application processing unit 211 as a function realized by the control unit 21 .

The payment application processing unit 211 has the function of executing payment application processing to perform payment-related processing based on the payment application software 281 stored in the memory unit 28.

The payment application processing unit 211 includes, as a functional unit, a code display processing unit 2113 that executes code display processing, for example and not by way of limitation.

In this embodiment, the term "payment-related processing" refers to, but is not limited to, processing related to making a payment, such as obtaining a terminal display code from server 10 (including requesting server 10 to generate a terminal display code and receiving the generated terminal display code from server 10), storing a terminal display code obtained from server 10, displaying a stored terminal display code image (code display processing), and obtaining a terminal payment completion notification from server 10. More specifically, this concept includes all processing executed on terminal 20 as processing related to making a payment.

4-8 are diagrams showing examples of information stored in the storage unit 28 of the terminal 20 in this embodiment.
In the storage unit 28, as an example and not by way of limitation, payment application software 281 is stored as application software acquired in advance from the server 10 by downloading or the like.

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 by the payment application software. By way of example and not limitation, this payment application data 283 stores terminal display code stock data 2831, payment data 2832, and store data 2833.

The terminal display code stock data 2831 is data that stores terminal display codes obtained from the server 10 when online, and an example of the data structure of the first terminal display code stock data 2831A is shown in Figure 4-9.
The terminal display code stock data 2831 stores, by way of example and not limitation, the code reception date and time, the code number, the code data, and the code expiration date in association with each other.

As a non-limiting example, the date and time when the terminal 20 received the terminal display code from the server 10 is stored as the code reception date and time.
The code number stored in the code field is the code number that the terminal 20 received from the server 10 along with the terminal display code.
As a non-limiting example, the code data stores data of a code image of a terminal display code received by the terminal 20 from the server 10 .
The code expiration date is, by way of example and not limitation, stored as the code expiration date, which is set in association with the terminal display code that the terminal 20 receives from the server 10 together with the terminal display code.

As an example, but not by way of limitation, the data of the terminal display code stored in the first terminal display code stock data 2831A can be deleted from the first terminal display code stock data 2831A after the payment process is performed by the server 10 using the terminal display code and a terminal payment completion notification is received from the server 10 (in the case of an offline payment, after returning to an online state and receiving a terminal payment completion notification from the server 10).
Also, by way of example and not limitation, if the code expiration date associated with the terminal display code has passed, the code may be deleted from the first terminal display code stock data 2831A.

As described above, instead of deleting the data of a terminal display code that has become unusable from the first terminal display code stock data 2831A, for example and not by way of limitation, the data of the terminal display code is associated with the data and a flag indicating whether the terminal display code can be used or not is set to "usable/unusable." Then, for terminal display codes that have become unusable, the flag may or may not be set to "unusable."

Furthermore, among the above, for example, the code reception date and time and the code expiration date may not be stored in the first terminal display code stock data 2831A.

In addition, in this embodiment, the code expiration date associated with the terminal display code is transmitted from the server 10 to the terminal 20, but alternatively, it is also possible to prevent the code expiration date associated with the terminal display code from being transmitted from the server 10 to the terminal 20.
In this case, the first terminal display code stock data 2831A may not store the code expiration date, but may store, for example and without limitation, the code reception date and time, the code number, and the code data in association with each other. This will be described later in a modified example.

Furthermore, instead of or in addition to the code reception date and time, the date and time when the terminal display code received from the server 10 was stored in the first terminal display code stock data 2831A (hereinafter referred to as the "code storage date and time") may be stored, but this is not a limitation.

Furthermore, as will be described in more detail below, the code data does not necessarily have to store the code image data of the terminal display code; instead of or in addition to this, the original information of the terminal display code (in this embodiment, the payment number) may be stored, or it is not necessary to do so.

The payment data 2832 is data for payment stored in the terminal 20, and the configuration of payment data 2832A, which is an example of such data, is shown in FIG. 4-10.
The payment data 2832A stores, by way of example and not limitation, an application ID, points, balance, daily upper limit set amount, auto-charge settings, and payment history data.

Based on the terminal payment completion notification received from server 10 after returning to an online state, the control unit 21 associates, for example but not limited to, the payment date and time (the date and time when the payment was made by server 10), the store ID (the ID of the store where the payment was made by server 10), the payment store name (the name of the store associated with that store ID), and the payment amount (the amount paid by server 10) and stores them in chronological order in the payment history data.

Store data 2833 stores, by way of example and not limitation, various store information stored in store registration data 155A on server 10.

By way of example and not limitation, the store data 2833 can be updated by delivering the latest store information from the server 10 to the terminal 20 when the payment application software 281 is updated.

In addition, the storage unit 28 stores terminal data 289, for example and not by way of limitation.
The terminal data 289 is data relating to this terminal 20, and includes, but is not limited to, terminal identification information such as a terminal telephone number and a terminal email address, and various setting information on the terminal 20 side.

<Display screen example>
FIG. 4-11 is a diagram showing an example of the top screen of the payment application displayed on the display unit 24 of the terminal 20 in this embodiment.
The configuration of this top screen is the same as that of FIG. 3B, and here, the state in which the "code icon" has been touched by the user of the terminal 20 is shown.

Figure 4-12 shows 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 displayed, by way of example and not limitation, when the "code icon" is touched in offline mode, as shown in Figure 4-11.

On this code display screen, the terminal display code stored in the memory unit 28 of the terminal 20 is read, and the code images are displayed in different areas of the display screen: a one-dimensional first terminal display code image represented by a barcode, and a two-dimensional first terminal display code image QC1 represented by a QR code. In addition, a 12-digit payment number is displayed below the one-dimensional first terminal display code image.

When making an offline payment, the user of terminal 20 presents the code display screen described above to a store clerk at code register 60 and makes the payment by having the store code reader device 50 read the terminal display code image. In this case, the store code reader device 50 sends payment request information to server 10, including, by way of example and not limitation, information obtained by decoding the read terminal display code image (in this example, the payment number) and information about the time the terminal display code image was read, and causes server 10 to make the payment. Details will be described later.

FIG. 4-13 is a diagram showing an example of a payment result screen displayed on the display unit 24 based on the terminal payment completion notice received from the server 10 after returning from the offline state to the online state.
On this payment result screen, the center of the code display screen in Figure 4-12 displays the message "Payment Completed" along with the message "Details can be viewed in Payment History.", along with a pop-up "Confirmation Icon" for viewing the payment history.

In the above display screen example, the user of terminal 20 can display the code display screen by touching the code icon, for example, without having to be aware of whether the device is online or offline, thereby improving user convenience.

<Processing>
4-14 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. From the left, it shows a first payment application process which is an example of payment application processing executed by the control unit 21 of the terminal 20, a first store payment process 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 process which is an example of payment management processing executed by the control unit 11 of the server 10.

The flowchart in Figure 4-14 is a partial rewrite of the flowchart in Figure 3-4. It differs from the flowchart in Figure 3-4 in steps A330 to A350, B350, B360, C320, C330, C370, etc., by way of example and not limitation.

In this process, as an example, the identification information for identifying the terminal 20 or the user of the terminal 20 will be described as the aforementioned application ID.

After C110, the control unit 11 of the server 10 performs a terminal display code generation process (C320). Specifically, by way of example and not limitation, a method (algorithm) for generating random numbers of a predetermined number of digits (for example, 10 to 12 digits) is used to generate a random number of digits as a payment number. Then, by way of example and not limitation, a terminal display code image is generated that includes at least the payment number as source information. More specifically, at least the payment number is encoded and converted into a graphic (image) to generate a terminal display code image represented as a two-dimensional code (for example, a QR code) image.

Then, in the code management database 159, the code management data for the application ID included in the received code generation request information is stored in association with the code generation date and time based on the timing information of the clock unit 19, the set code number, the generated payment number, and the code expiration date set for the generated terminal display code.

Next, the control unit 11 sends the generated terminal display code (in this example, a code image) along with the code number and the code expiration date set for that terminal display code to the terminal 20 via the communication I/F 14 (C330).

When the terminal display code (in this example, a terminal display code image) and the code expiration date are received from the server 10 via the communication I/F 22 (A330), the control unit 21 of the terminal 20 stores the received terminal display code (in this example, a terminal display code image) (A340). Specifically, the code data of the received terminal display code and the received code expiration date are stored in the first terminal display code storage data 2831A in association with, by way of example and not limitation, the code reception date and time.

In the offline state, for example and not by way of limitation, when a code display operation is performed by the user of the terminal 20, the code display processing unit 2113 performs code display processing (A350). Specifically, for example and not by way of limitation, the code data of the terminal display code stored in the first terminal display code stock data 2831A is read out, and a code display screen including a terminal display code image is displayed on the display unit 24.

After that, when the user of the terminal 20 presents the terminal display code image displayed on the display unit 24 to a store clerk or the like, 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 (B350).

Then, the control unit 51 accesses the server 10 via the communication I/F 54 using the aforementioned application interface (API) or the like, and transmits payment request information to the server 10 via the communication I/F 54, including at least the payment number obtained by decoding the read terminal display code image, store identification information, the planned payment amount, and the time the terminal display code image was read (hereinafter referred to as the "code read time") (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 determines whether the payment number included in the received payment request information is stored in code management database 159 in association with the application ID. If it determines that it is stored, it then determines whether the code read time included in the received payment request information is within the code expiration date stored in association with the payment number in the code management data for that application ID. If this condition is met, it determines that "payment is possible" and makes the payment by subtracting the planned payment amount from the balance stored in the payment management data for that application ID in payment management database 157A.

The terminal display code stored in terminal 20 can be used not only for offline payments, but also for online payments. In other words, it is not necessary for terminal 20 to determine (detect) whether it is offline, and payments can be made using the terminal display code stored in terminal 20 regardless of whether it is online or offline.

<Code>
In the above process, an example has been shown in which the terminal 20 requests the server 10 to generate a terminal display code image, and the terminal display code image generated by the server 10 is transmitted to the terminal 20, but this is not limiting. For example, the terminal 20 may request the server 10 to generate original information (a payment number in this example), and the original information generated by the server 10 may or may not be transmitted to the terminal 20.

Specifically, in the process of FIG. 3-1, at A110, the control unit 21 sends code generation request information requesting the server 10 to generate raw information. Then, based on this code generation request information, at C120, the control unit 11 generates raw information, and at C130, sends the generated raw information to the terminal 20.

When the original information is received from the server 10 at A130, the control unit 21 generates a terminal display code image based on the received original information. The control unit 21 then displays the generated terminal display code image on the display unit 24.

Similarly, in the processing of FIG. 3-4, 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. The control unit 21 then 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.

Similarly, in the processing of FIG. 4-14, when the original information and code expiration date are received from the server 10 at A330, the control unit 21 stores the received original information and code expiration date in the first code stock data for terminal display 2831A at A340. Then, when the user of the terminal 20 performs an operation to display a code while offline, the control unit 21 reads the stored original information from the first code stock data for terminal display 2831 and generates a code image for terminal display based on the read original information. Then, at A350, the control unit 21 displays a code display screen including the generated code image for terminal display on the display unit 24.

Also, unlike the above, the terminal 20 requests the server 10 to generate a terminal display code image, and the terminal display code image generated by the server 10 is sent to the terminal 20. However, rather than stocking the terminal display code image received from the server 10, the terminal 20 may or may not stock the original information obtained by decoding the terminal display code image received from the server 10.

<Effects of the First Embodiment>
According to the first embodiment, the terminal receives code information associated with an expiration date by the server from the server, stores the received code information in a storage unit, and executes a payment process based on the stored code information, thereby realizing offline payment.

Specifically, in the first embodiment, the terminal 20 receives, from the server 10 via the communication I/F 22, a terminal display code image and a payment number (not limiting, an example of first code information) associated with a code expiration date (not limiting, an example of a first expiration date) by the server 10. Then, the terminal 20 stores the received terminal display code image and payment number in the storage unit 28 by the control unit 21.
In addition, the terminal 20 executes a code display process (not limited to this, but an example of a process related to payment) using the control unit 21 to display a terminal display code image on the display unit 24 based on the stored terminal display code image and payment number.
The payment is performed by the server 10 based on the code reading time (not limited to, but an example of a time based on processing related to payment) when the terminal display code image displayed in the code display process is read by the store code reader device 50, and the code expiration date.
As an example of the effect obtained by such a configuration, even if the communication environment or communication conditions of the terminal are poor or unstable, the server can properly perform payment based on the time based on the payment processing and the first expiration date. Furthermore, for example, since payment can be prevented from being performed unless it is within the first expiration date associated with the first code information, it is possible to prevent the code information stored in the terminal from being stolen by a hacker or the like, or to prevent a code image corresponding to the code information stored in the terminal from being photographed by a camera or the like on another user's terminal when the code image is displayed on the terminal and used for fraudulent payment.

In addition, in the first embodiment, the terminal 20 includes a processor that reads a payment application program 282 (not limiting, but an example of a program) stored in memory and executes payment application processing based on the payment application program 282.
The processor performs the following processes: receiving from the server 10 a terminal display code image and a payment number (not limited to, but an example of first code information) associated with a code expiration date (not limited to, but an example of first expiration date) by the server 10; storing the received terminal display code image and payment number in memory; and displaying a code based on the stored terminal display code image and payment number (not limited to, but an example of payment-related processing).
The payment is performed by the server 10 based on the code reading time (not limited to, but an example of a time based on processing related to payment) when the terminal display code image displayed in the code display process is read by the store code reader device 50, and the code expiration date.
With this configuration, the same effects as above can be obtained.

In the first embodiment, the terminal 20 receives the terminal display code and its code expiration date (not limited to this, but an example of information related to the first expiration date) from the server 10 via the communication I/F 22. Then, the control unit 21 associates the received code expiration date with the terminal display code and stores it in the terminal display code stock data 2831.
As an example of the effect obtained by such a configuration, it becomes possible for the terminal to know the first expiration date associated with the first code information by the server.

In addition, in the first embodiment, the server 10 associates a terminal display code image and a payment number (not limited to, but an example of the first code information) with a code expiration date (not limited to, but an example of the first expiration date) and stores them in the code management data.
The server 10 transmits the terminal display code image and the payment number to the terminal 20 performing the code display process via the communication I/F 14, and receives the payment number and the code reading time (not limited to this, but an example of the time based on the payment processing) when the terminal display code image displayed in the code display process is read by the store code reader device 50 via the communication I/F 14.
The server 10 then has a configuration in which the control unit 11 performs the payment process based on the code expiration date associated with the received payment number and the received code reading time.
As an example of the effect obtained by such a configuration, even if the communication conditions or communication environment of the terminal are poor, the server can appropriately perform payment based on the first code information associated with the received first code information and the time based on the payment-related processing executed on the terminal.

In addition, in the first embodiment, the server 10 is equipped with a processor that reads out a payment management processing program 151 (not limited to, but an example of a program) stored in memory and executes payment management processing based on the payment management processing program 151.
The processor is configured to perform the following processes: associate a terminal display code image and a payment number (not limited to, but an example of first code information) with a code expiration date (not limited to, but an example of first expiration date) and store them in code management data; send the terminal display code image and the payment number to the terminal 20 performing the code display process and receive the payment number and the code reading time (not limited to, but an example of time based on processing related to payment) when the terminal display code image displayed in the code display process is read by the store code reader device 50; and perform payment processing based on the code expiration date associated with the received payment number and the received code reading time.
With this configuration, the same effects as above can be obtained.

<First Modification Example (1)>
In the first embodiment, the period from when the code is displayed until the code display time has elapsed is defined as the "code display deadline", but the present invention is not limited to this.
As a non-limiting example, the "code display deadline" may be defined as the time or date at which the period from when the code is displayed until the code display time has elapsed.

Similarly, in the first embodiment, the period from the code generation date and time until the code validity period has elapsed is defined as the "code validity period", but this is not limiting.
By way of example and not limitation, the "code expiration date" may be defined as the time or date at which the period from when the code is displayed until the code display time has elapsed.

In addition, rather than using the code generation date and time as the start date and time of the code expiration date, the date and time when the server 10 transmits the terminal display code to the terminal 20 (hereinafter referred to as the "code transmission date and time") may, but does not have to, be the start date and time of the code expiration date. In other words, the code expiration date may, but does not have to, be the "period from the code transmission date and time until the code validity period has elapsed." In this case, the server 10 may store the code expiration date in the code management data after transmitting the terminal display code to the terminal 20.

<First Modification Example (2)>
In the first embodiment, the server 10 transmits a terminal display code (not limited to this, but an example of code information) and a code expiration date (not limited to this, but an example of information regarding the expiration date), which are then received by the terminal 20, but this is not limited to this.

Specifically, by way of example and not limitation, the code expiration date is stored in advance in the payment application data 283 of the terminal 20. Then, by way of example and not limitation, the code generation date and time (a non-limiting example of information related to the expiration date) may be transmitted from the server 10, and the terminal 20 may, or may not, receive the code generation date and time from the server 10. In this case, the terminal 20 can determine the code expiration date based on the received code generation date and time and the code expiration date stored in the payment application data 283.

As mentioned above, the code transmission date and time can also be set to the date and time when the code expiration date starts, and this also applies in this case. In other words, the date and time when the code expiration date starts is sent from the server 10 to the terminal 20 as information about the expiration date. The terminal 20 can then determine the code expiration date based on the code expiration time and the date and time when the received code expiration date starts.

As another example, and not by way of limitation, the date and time when the code expiration date will expire can be transmitted from the server 10 to the terminal 20 as information regarding the expiration date. The terminal 20 can then determine the code expiration date based on the code expiration time and the date and time when the received code expiration date will expire.

<First Modification Example (3)>
In the first embodiment, the code expiration date associated with the terminal display code is transmitted from the server 10 to the terminal 20, but the present invention is not limited to this.

Specifically, by way of example and not limitation, the code expiration date associated with the terminal display code may not be transmitted from the server 10 to the terminal 20, and the terminal 20 may not know the code expiration date set by the server 10. In this case, the terminal display code stock data 2831 (first terminal display code stock data 2831A and second terminal display code stock data 2831B) may not store the code expiration date, but may store, by way of example and not limitation, the code reception date and time, the code number, and the code data in association with each other.

In this case, the terminal 20 may or may not set a temporary code expiration date (hereinafter referred to as the "temporary code expiration date"). Specifically, and by way of example and not limitation, the temporary code expiration date may or may not be set to "the period from the code reception date and time (or code storage date and time) until the code expiration time has elapsed." In this case, the terminal 20 may or may not use the set temporary code expiration date to execute the processing described in each embodiment and each variant example.

<First Modification Example (4)>
The terminal display code stock data 2831 in the memory unit 28 of the terminal 20 may store one code obtained from the server 10 while online, or may store multiple (two or more) codes obtained from the server 10 while online.

FIG. 4-15 is a diagram showing an example of the second terminal display code stock data 2831B in this case.
The second terminal display code stock data 2831B stores data for multiple terminal display codes. Specifically, by way of example and not limitation, the code reception date and time, code number, code data, and code expiration date are associated and stored in chronological order.

In this case, in the code display process, the control unit 21 of the terminal 20 can, by way of example and not limitation, read out the code data of the oldest terminal display code among the terminal display codes stored in the second terminal display code stock data 2831B, and display a code display screen including an image of that terminal display code on the display unit 24.

This allows multiple codes to be stored on the terminal 20, so even if multiple offline payments need to be made, the payments can be made immediately, improving user convenience.

<First Modification Example (5)>
In the first embodiment, the "code information" in the present disclosure is a payment number or a terminal display code image including a payment number, but is not limited to this. For example, a token, which is a type of authentication information, or a terminal display code image including a token can also be the "code information" in the present disclosure.

In this case, rather than including the payment number in the terminal display code image, a token issued using a method (algorithm) for generating random tokens may be included in the terminal display code image, but this is not a limitation. In this case, the server 10 may associate the issued token with identification information for identifying the terminal 20 or the user of the terminal 20 and store it in the code management data of the code management database 159 in the storage unit 15.

By way of example and not limitation, a "token" is a type of authentication information used by the server 10 to authenticate that the terminal 20 or the user of the terminal 20 is a legitimate terminal 20 or a legitimate user of the terminal 20. "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 the terminal 20 or the user of the terminal 20.

The token can also be referred to as, for example, a "random token," an "access token," or a "payment token." Because the token is issued randomly as described above, it will be different each time a terminal display code is generated. For this reason, the token functions as a one-time password, so to speak.

In addition to the payment number and token, the store code reader device 50 that reads the terminal display code image may, or may not, include information such as a uniform resource locator (URL) 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.

<First Modification Example (6)>
On the code display screen, information on the code display expiration date and information on the code expiration date may or may not be displayed in an area different from the area where the terminal display code image is displayed.

The information on the code display deadline includes, but is not limited to, information such as "code display deadline,""remaining time of code display deadline,""time or date when the code display deadline ends," and "code display time."
The information on the code display expiration date may be referred to as information on the code display expiration date.

Furthermore, the code expiration date information includes, but is not limited to, information such as "code expiration date,""remaining time until code expiration date,""time or date when code expiration date ends," and "code validity period."
The code expiration date information may be referred to as information relating to the code expiration date.

FIG. 4-16 is a diagram showing an example of a code display screen in this modified example.
In this code display screen, by way of example and not limitation, the remaining time until the code display expiration date is displayed below the two-dimensional first terminal display code image QC1.
The remaining time until the code display deadline is displayed and updated based on the time measured by the clock unit 29A, using the time when the code display screen is displayed (the time when the display starts) as a reference, as an example and not a limitation.

In this display example, the remaining time until the code display deadline is displayed in the same manner as in Figure 3-3 to make it easier for users to understand, but the remaining time until the code display deadline may or may not be displayed in a manner different from that shown in Figure 3-3.

FIG. 4-17 is a diagram showing an example of a code display screen in this modified example.
On this code display screen, by way of example and not limitation, an hourglass mark (image) is displayed on top of the two-dimensional first terminal display code image QC1, along with the remaining time until the first code expiration date associated with the first terminal display code image.

The remaining time until the first code expiration date is displayed and updated based on, for example and not by way of limitation, the code expiration date associated with the terminal display code stored in the terminal display code stock data 2831 and the time measured by the clock unit 29A.

FIG. 4-18 is a diagram showing an example of a code display screen in this modified example.
This code display screen is a combination of the code display screens of FIGS. 4-16 and 4-17.
Specifically, by way of example and not limitation, the remaining time until the first code expiration date and the remaining time until the first code display date are displayed above and below the first terminal display code image QC1, respectively.

FIG. 4-19 is a diagram showing an example of a code display screen in this modified example.
This code display screen is almost the same as that shown in FIG. 4-18, but the code expiration date information is displayed differently.
Specifically, as information on the code expiration date, the text "Valid for 12 hours from 9:00 on 2019/06/10" is displayed, as a non-limiting example, to indicate that the first terminal display code is valid from the time the code expiration date starts until the code validity time has elapsed.

The code display screens in Figures 4-16 to 4-19 can be code display screens displayed in offline mode, or code display screens displayed in online mode.

Instead of displaying the code expiration date information, the temporary code expiration date information described above may or may not be displayed, by way of example and not limitation.

<Effects of the first modified example (6)>
This modified example shows a configuration in which the terminal 20 displays information such as the code expiration date and the remaining time until the code expiration date (this is not a limitation, but an example of information about the first expiration date) in an area within the code display screen (this is not a limitation, but an example of the display area of the terminal).
As an example of the effect obtained by such a configuration, information on the first expiration date can be notified to the user of the terminal.

In addition, this modified example shows a configuration in which the terminal 20 displays information such as the code expiration date and the remaining time until the code expiration date (not limited to this, but an example of information about the first expiration date), as well as a terminal display code image and payment number (not limited to this, but an example of first code information) stored in the terminal 20 in an area within the code display screen (not limited to this, but an example of the display area of the terminal).
As an example of the effect obtained by such a configuration, the first expiration date information and the first code information can be notified to the user of the terminal, thereby improving user convenience.

In addition, this modified example shows a configuration in which, when the terminal 20 is offline, it displays information such as the code expiration date and the remaining time until the code expiration date (this is not a limitation, but an example of information about the first expiration date) in an area within the code display screen (this is not a limitation, but an example of the display area of the terminal).
As an example of the effect obtained by such a configuration, information on the first expiration date can be displayed in the display area of the terminal based on the communication status of the terminal. For example, even if the communication environment or communication status of the terminal is poor or unstable, the information on the first expiration date can be displayed in the display area of the terminal, thereby improving user convenience.

In addition, this modified example shows a configuration in which the terminal 20 displays, in an area within the code display screen, a terminal display code image and a payment number (not limited to, but an example of the first code information) stored in the terminal 20, as well as information such as the code display expiration date and the remaining time until the code display expiration date (not limited to, but an example of the expiration date for which the first code information can be used, which is different from the first expiration date).
As an example of the effect obtained by such a configuration, it is possible to notify the terminal user of the first code information and a time limit during which the first code information can be used, which is different from the first expiration date.

<First Modification Example (7)>
The display screen of the payment application explained in the first embodiment is merely an example, and the design can be changed as appropriate.

FIG. 4-20 is a diagram showing an example of the top screen of the payment application displayed on the display unit 24 of the terminal 20 in this modified example.
In addition to the aforementioned "code icon," this top screen also displays a "code (offline) icon" labeled "code (offline)."

In this variant, the "code icon" is an icon for displaying the code display screen when online, and the "code (offline) icon" is an icon for displaying the code display screen when offline.

4-21 is a diagram 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 top screen.
This code display screen displays "Code (offline)" at the top of the screen, and below that, the same information as in the code display screen of Figure 4-10 is displayed.

In this example display screen, when the terminal 20 detects that it is offline, the stored terminal display code is displayed on the code display screen in accordance with user operation. This terminal display code can then be used to perform offline payments.

<First Modification Example (8)>
In the process A130 of Figure 3-4, when the terminal 20 receives the terminal display code from the server 10, the processes 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.

Furthermore, in the process A330 of Figure 4-14, when the terminal 20 receives the terminal display code and the code expiration date from the server 10, the processes A340 and A350 may be performed to display the terminal display code on the display unit 24, but this is not required.

In this case, by way of example and not limitation, when the code icon is touched on the top screen of the payment application (e.g., Figure 3-2), the display can be switched to a code display screen for the terminal display code.

<First Modification Example (9)>
In the first embodiment, the case where the code reading time is the "time based on the payment processing" has been described as an example, but the present invention is not limited to this.

First, instead of the time the code was read, the date and time the code was read, including the date information, may or may not be used as the "time based on the payment-related processing."

In addition, the time (hereinafter referred to as the "code display time") or date and time (hereinafter referred to as the "code display date and time") when the terminal display code stored on terminal 20 is displayed on terminal 20 may, or may not, be used as the "time based on the payment-related processing."

However, when online, the server 10 is in communication with the terminal 20 and can recognize that the terminal display code has been displayed on the terminal 20. Therefore, the server 10 can determine the code display time and the code display date and time based on the timing information of the clock unit 19.
However, in the offline state, the server 10 cannot communicate with the terminal 20, so the server 10 does not know whether the terminal display code has been displayed on the terminal 20, and is therefore unable to identify the code display time or the code display date and time.
Therefore, by way of example and not limitation, the following processing is performed.

Figure 4-22 is a flowchart showing an example of the processing flow executed by each device in this modified example. From the left, it shows a second payment application process, which is an example of payment application processing executed by the control unit 21 of the terminal 20, a second store payment process, which is an example of store payment processing executed by the control unit 51 of the store code reader device 50, and a second payment management process, which is an example of payment management processing executed by the control unit 11 of the server 10.

The flowchart in Figure 4-22 is a partial rewrite of the flowchart in Figure 3-4. It differs from the flowchart in Figure 3-4 in the offline processing steps (e.g., A450, B450, B460, C470), for example and not by way of limitation.

In this process, as an example, the identification information for identifying the terminal 20 or the user of the terminal 20 will be described as the aforementioned application ID.

After A240, when the user of terminal 20 performs a code display operation in the offline state, for example and not by way of limitation, the control unit 21 performs an extended terminal display code generation process, and the code display processing unit 2113 performs a code display process (A450).

Here, the payment code processed (including processing, generation, display, etc.) on the terminal 20 side based on the terminal display code stored in A240 is referred to as the "extended terminal display code," and the code image of this extended terminal display code is referred to as the "extended terminal display code image."

Like the terminal display code, the extended terminal display code is a code used for payments with the "Terminal Code Display" payment type, but it can also be used for offline payments.

The extended terminal display code can be used not only for offline payments, but also for online payments. In other words, it is not necessary for the terminal 20 to determine (detect) whether it is offline, and payments can be made using the extended terminal display code regardless of whether it is online or offline.

In the extended terminal display code generation process, a code image for extended terminal display is generated, by way of example and not limitation. Specifically, the payment number obtained by decoding the terminal display code image stored in the terminal display code stock data 2831, or the payment number stored in the terminal display code stock data 2831 and the timestamp information generated by the control unit 21 are encoded and converted into a graphic (image) to generate the extended terminal display code image.

Here, timestamp information refers to information that indicates the date, time, and time when a specific event occurred, and also functions as an electronic time certificate that proves that the information or data associated with that timestamp information (in this case, the extended terminal display code) definitely existed at a certain time.

In this example, the specific event is "the display of a code image for extended terminal display on the display unit 24 of the terminal 20," and the control unit 21 of the terminal 20 generates timestamp information including the code display time, which is the time when the code image for extended terminal display was displayed (when display began). The code display time and timestamp information are examples of "time information," and are generated based on information kept by the clock unit 29A of the terminal 20.

Note that some stores may not be able to read two-dimensional codes, but may be able to read one-dimensional codes. Therefore, it may be possible to generate a code image for display on an extended terminal that is represented by 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).

In addition, instead of the code display time, timestamp information may be generated that includes a "code display date and time" that includes date information in addition to the time, but this is not required.

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

Also, instead of encoding timestamp information, the code display time or the code display date and time itself may be encoded, or it may not be necessary to do so.

In the code display process, by way of example and not limitation, a code display screen including at least a code image for displaying an extended terminal is displayed on the display unit 24.

As described above, if a two-dimensional code image for extended terminal display is generated in the process of generating a code for extended terminal display, the two-dimensional code image for extended terminal display can be displayed, for example and not as a limitation.

Furthermore, if a one-dimensional code image for displaying an extended terminal is also generated in the process of generating a code for displaying an extended terminal, then, by way of example and not limitation, it is possible to display the one-dimensional code image for displaying an extended terminal in addition to the two-dimensional code image for displaying an extended terminal. In this case, the payment number may or may not be displayed next to the one-dimensional code image for displaying an extended terminal.

After that, when the user of the terminal 20 presents the code image for displaying the extended terminal displayed on the display unit 24 to a store clerk or the like, the control unit 51 controls the code reader 58 to read the code image for displaying the extended terminal displayed on the display unit 24 of the terminal 20 (B450).

The control unit 51 accesses the server 10 via the communication I/F 54. The control unit 51 then transmits payment request information, including at least the payment number and timestamp information obtained by decoding, store identification information, and the planned payment amount, to the server 10 via the communication I/F 54 (B460).

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 (C470).

Specifically, it determines whether the payment number included in the received payment request information is stored in code management database 159 in association with the application ID. If it determines that it is stored, it then determines whether the code display time identified from the timestamp information included in the received payment request information is within the code expiration date stored in association with the payment number in the code management data for that application ID. If this condition is met, it determines that "payment is possible" and makes the payment by subtracting the planned payment amount from the balance stored in the payment management data for that application ID in payment management database 157A.

In addition, if it is also desired to determine whether the payment is within the aforementioned code display deadline, then, as a non-limiting example, the difference between the time measured by the clock unit 19 of the server 10 and the code display time determined from the timestamp information included in the received payment request information can be compared with the code display time to also determine whether the payment is within the code display deadline.

<Second Example>
In the first embodiment, the server 10 performs the payment based on the code expiration date. However, the user of the terminal 20 may not always be able to perform the procedure to have the server 10 perform the payment within the code expiration date.
Furthermore, if the code expiration date has passed, it is necessary to obtain the terminal display code again from the server 10, but this task may be troublesome for some users.

The contents described in the second embodiment can be applied to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 5A is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this embodiment.
In this embodiment, the payment application program 282 includes, as a subroutine program, a terminal side code update processing program 2821 that is executed as a terminal side code update processing, by way of example and not limitation.

<Processing>
5-2 is a flowchart showing an example of the flow of processing executed by each device in this embodiment. The left side shows the terminal-side code update processing executed by the control unit 21 of the terminal 20, and the right side shows the server-side code update processing executed by the control unit 11 of the server 10. These processes are, by way of example and not limitation, processes executed as sub-processes (e.g., executed in the background) of the aforementioned payment application processing of the terminal 20 and the aforementioned payment management processing of the server 10.

First, the control unit 21 performs a code update condition determination process (D110). Specifically, by way of example and not limitation, it determines whether the time kept by the clock unit 29A of the terminal 20 (hereinafter referred to as the "terminal time") is a set time before the expiration date (date and time) of the code associated with the terminal display code stored in the terminal display code stock data 2831.

The set time may be set based on, for example and not by way of limitation, a code validity time.
For example, if the code validity period is "12 hours," the set time can be set to half of that, "6 hours," and if the code validity period is "24 hours," the set time can be set to half of that, "12 hours." It is desirable to set the time with some leeway in order to update the terminal display code.

It should be noted that rather than determining whether the time from the time the code expiration date ends to the time before the set time, it is possible, but not limited to, to determine whether the set time has passed from the time the code was received (code date and time) or the time the code was stored (code date and time), or it is not necessary to do so.
That is, the time (reference time) used as the reference for determining whether the code update condition is met may be the time when the code validity period ends, or the time when the code is received or stored.

When applying the first terminal display code stock data 2831A, one terminal display code is stored, so this terminal display code is the target and D110 determination is made based on the code expiration date associated with this terminal display code.

On the other hand, when applying the second terminal display code stock data 2831B, since multiple terminal display codes are stored, it is sufficient to perform a D110 determination for each of these multiple terminal display codes based on the code expiration date associated with each terminal display code.

If the time is before the set time, the control unit 21 determines that the code update condition is met.

If it is determined that the code update condition is met (D120: YES), the control unit 21 determines whether the device is online (D130). If it is determined that the device is online (D130: YES), the control unit 21 sends code update request information, which includes, by way of example and not limitation, the application ID and the code number of the terminal display code requesting the update, to the server 10 via the communication I/F 22 (D160).

Here, the "code update request information" is information for requesting (or applying for) an update (or re-acquisition) of the terminal display code stored in terminal 20, and can also be considered a request for updating the code information.
The "code update request information" can also be considered as information requesting transmission of an updated terminal display code (new terminal display code).

The control unit 11 of the server 10 determines whether code update request information has been received from the terminal 20 (E110). If it is determined that the request has been received (E110: YES), the control unit 11 performs terminal display code update processing (E120).

Specifically, by way of example and not limitation, the code management data for the application ID included in the received code update request information is referenced in the code management database 159 of the storage unit 15. It is then determined whether the code number included in the received code update request information exists in that code management data, and if it is determined that the code number exists, a process similar to the terminal display code generation process described above is performed to generate an updated terminal display code. The code generation date and time, payment number, and code expiration date stored in the code management data in association with that code number are then updated. Hereinafter, the terminal display code updated in this manner will be referred to as the "updated terminal display code."

Next, the control unit 21 transmits the updated terminal display code and its code expiration date to the terminal 20 via the communication I/F 14 (E170).

The control unit 11 then determines whether to terminate the processing (E190), and if it determines to continue the processing (E190: NO), it returns to E110. If it determines to terminate the processing (E190: YES), it terminates the server-side code update processing.

Also, if no code update request information is received from the terminal 20 (E110: NO), the control unit 11 proceeds to E190.

When the communication I/F 22 receives an updated terminal display code and its code expiration date from the server 10 (D170), the control unit 21 updates the code reception date and time, code data, and code expiration date stored in the terminal display code stock data 2831 in association with the corresponding code number (D180). By performing this update process, the terminal display code to be updated (old terminal display code) becomes unusable (cannot be used).

In D180, the received updated terminal display code and its code expiration date may be stored as separate data (new data) in the terminal display code stock data 2831, and a process may be performed to set an "unusable" flag for the terminal display code to be updated, so that the terminal display code to be updated (old terminal display code) becomes unusable, or this may not be necessary.

The control unit 21 then determines whether to terminate the process (D190), and if it determines to continue the process (D190: NO), it returns to D110. If it determines to terminate the process (D190: YES), it terminates the terminal-side code update process.

Furthermore, if it is determined that the code update condition is not met (D120: NO), or if it is determined that the device is not online (D130: NO), the control unit 11 proceeds to D190.

In this process, if the terminal display code is updated, the terminal 20 may display information indicating that the terminal display code has been updated (for example, a message indicating that the terminal display code has been updated or an image indicating that the terminal display code has been updated) on the display unit 24 via push notification, or, if a payment application is running, may display the information on the payment application screen of the display unit 24.

<Effects of the Second Example>
In the second embodiment, the terminal 20 receives an updated terminal display code (not limited to, an example of second code information) different from a terminal display code (not limited to, an example of first code information) stored in advance on the terminal 20, based on the code expiration date (not limited to, an example of first expiration date) associated with the terminal display code, from the server 10 via the communication I/F 22. The updated terminal display code is then associated by the server 10 with a code expiration date (not limited to, an example of second expiration date) different from the code expiration date associated with the terminal display code.
As an example of the effect obtained by such a configuration, second code information associated by the server with a second expiration date different from the first expiration date based on information regarding the first expiration date is received from the server, making it possible, for example, to obtain the second code information from the server before the first expiration date has elapsed, thereby improving user convenience.

In the second embodiment, the terminal 20 receives the code expiration date (not limited to this, but an example of information relating to the first expiration date) together with the terminal display code from the server 10 via the communication I/F 22. The control unit 21 then associates the received code expiration date with the terminal display code and stores it in the terminal display code stock data 2831.
As an example of the effect obtained by such a configuration, it becomes possible for the terminal to know the first expiration date associated with the first code information by the server.

In addition, the second embodiment shows a configuration in which the terminal 20 transmits code update request information (not limited to, but an example of information requesting the transmission of second code information) to the server 10 via the communication I/F 22 based on the code expiration date associated with the terminal display code previously stored in the terminal 20.
As an example of the effect obtained by such a configuration, it is possible to request the server to transmit the second code information at an appropriate timing based on the information regarding the first expiration date.

In addition, the second embodiment shows a configuration in which an updated terminal display code (not limited to, but an example of second code information) is received from the server 10 via the communication I/F 22 before the code expiration date (not limited to, but an example of the first expiration date) associated with a terminal display code (not limited to, but an example of the first code information) previously stored in the terminal 20 expires.
As an example of the effect obtained by such a configuration, the second code information can be received from the server before the first expiration date has elapsed.

In addition, the second embodiment shows a configuration in which, based on receiving an updated terminal display code, the terminal 20 performs, via the control unit 21, a process of updating the terminal display code to be updated and its code expiration date using the received updated terminal display code and its code expiration date (this is not a limitation, but an example of a process that makes the first code information unusable), and a process of setting an ``unusable'' flag for the terminal display code to be updated (this is not a limitation, but an example of a process that makes the first code information unusable).
As an example of the effect obtained by such a configuration, the first code information can be made unusable based on the reception of the second code information, thereby preventing old first code information that has been stored in the memory unit in advance from being used for payment.

<Second Modification Example (1)>
In the second embodiment, whether or not the code update condition is met is determined based on the code expiration date of the terminal display code stored in advance in the terminal 20. However, the present invention is not limited to this. The code update condition can be set or changed as appropriate.

FIG. 5C is a diagram showing an example of information stored in the storage unit 28 of the terminal 20 in this modification.
In this variation, the payment application data 283 includes, by way of example and not limitation, user schedule data 2834 and code update condition data 2835 .

User schedule data 2834 is data that stores information about the schedule of the user of terminal 20 (hereinafter referred to as "user schedule information"). User schedule information is set and updated in accordance with operations by the user of terminal 20.

The code update condition data 2835 is data in which code update conditions are set, and an example of the data configuration is shown in FIG. 5-4.
In the code update condition data 2835, as an example and not a limitation, a condition type, a condition number, and a code update condition are set in association with each other.

<Condition type "CK1">
The condition type "CK1" is a "time" category, and includes, by way of example and not limitation, code update conditions with condition numbers "CK1-1" to "CK1-3".

The code update condition for condition No. "CK1-1" is set as "the terminal clock time reaches the first set time before the code expiration date expires."
This is the same condition as the code update condition determined in the second embodiment.
However, the first set time does not necessarily have to be half the code valid time, and can be set or changed as appropriate.

The code update condition for condition No. "CK1-2" is set as "the terminal clock time reaches the set time (set time zone)."
This indicates that the code update condition is determined to be met when the terminal clock time reaches the set time or when the terminal clock time reaches a time included in the set time period.
The set time and set time period can be changed as needed. For example, a time such as "midnight" or "6:00 in the morning" can be set as the set time, and a time period such as late night can be set as the set time period.

The code update condition for condition No. "CK1-3" is set as "a second set time has elapsed since the code was last updated."
This indicates that it is determined that the code update condition is met when the second set time has elapsed since the terminal display code stored in the terminal 20 was last updated.
The second set time can be changed as needed, but must be set to a time shorter than the code valid time.

<Condition type "CK2">
The condition type "CK2" is a "user" category, and includes, by way of example and not limitation, code update conditions with condition numbers "CK2-1" to "CK2-2".

The code update condition for condition No. "CK2-1" is set to "a code update request operation by the user." This indicates that the code update condition is determined to be met when the user of the terminal 20 performs an operation to request an update of the terminal display code (hereinafter referred to as a "code update request operation").
This condition can also be called a "user action" type condition.

The code update condition for condition No. "CK2-2" is defined as "The recommended time for update has arrived based on the user schedule information (or payment information)." This indicates that the code update condition is determined to be met when the recommended time for update has arrived based on the user schedule information stored in user schedule data 2834.

For example, if the user of terminal 20 regularly (e.g., on certain days of the week or certain days of the month) shops and makes payments at a store located in an area where communication conditions are unstable (such as on sale days), or if the user regularly visits an underground bar to drink and make payments, it is likely that the user of terminal 20 will also use the same store to make payments the next time.

The terminal 20 then estimates the timing (time or date and time) when the next payment will likely be made based on the user's schedule information history (e.g., the user schedule information history included in the user schedule data 2834). Then, by setting a timing before that timing (e.g., before departure, at the time of departure, or before arrival at the destination) as the recommended update timing, the terminal display code can be updated at that timing.

Instead of or in addition to estimating the timing when the next payment is likely to be made based on the user's schedule information history, the timing when the next payment is likely to be made may be estimated based on the user's payment information (e.g., payment history data included in payment data 2832).
These conditions can also be called conditions of the types "schedule,""payment," and "history."

<Condition type "CK3">
The condition type "CK3" is a category of "location" and includes, by way of example and not limitation, code update conditions of condition numbers "CK3-1" to "CK3-2." These conditions can also be referred to as conditions of the type "terminal location,""userlocation," or "location."

The code update condition for condition No. "CK3-1" is set to "the calculated terminal position is near the set store." This indicates that the code update condition is determined to be met when the position of the terminal 20 calculated based on the position calculation information detected by the position calculation information detection unit 29B (hereinafter referred to as the "calculated terminal position") is near the set store.

Note that the calculated terminal position is the calculated position of the terminal 20, but if the user is carrying the terminal 20, the calculated position of the terminal 20 is the same as the position of the user of the terminal 20. In other words, assuming that the user is carrying the terminal 20, the position of the terminal 20 and the position of the user of the terminal 20 can be said to be essentially synonymous.

By way of example and not limitation, the set store can be set in advance on the terminal 20 side or on the server 10 side. For example, a store located in a place with poor communication environment, such as an underground area, can be set as a set store on the terminal 20 side in response to an operation by the user of the terminal 20, or on the server 10 side. In this case, the terminal display code can be updated when the terminal position approaches the set store.

The code update condition for condition No. "CK3-2" is set to "the calculated terminal position is within a set range." This indicates that the code update condition is determined to be met if the calculated terminal position is within the set range.

For example, an event may be held in which stores that accept payments using a payment application are set up, and since many people visit the event venue where such an event is held and use terminal 20 within the venue, there is a possibility that communication conditions may become poor.
Furthermore, if the event is held underground, for example, it may be impossible to communicate.

Therefore, for example, but not limited to, a predetermined range (for example, within a 1 km radius) centered on the event venue where the event is being held is set as the set range on the terminal 20 side or the server 10 side. In this case, the terminal display code can be updated when the terminal position enters the predetermined range (when the user of terminal 20 approaches the event venue).

<Condition type "CK4">
The condition type "CK4" is an "urgent" category, and includes, by way of example and not limitation, the code update condition of condition number "CK4-1." This condition can also be said to be a condition of the type "social situation."

The code update condition for condition No. "CK4-1" is set to "disaster information/disaster prevention information reception." This indicates that the code update condition is determined to be met when the terminal 20 receives disaster information/disaster prevention information such as earthquake disaster information, meteorological disaster information, flood information, or landslide disaster information.

When a disaster occurs, it is expected that the communications infrastructure will cease to function and the terminal 20 will go offline. Therefore, when the terminal 20 receives disaster information or disaster prevention information, the terminal display code will be updated.

In this embodiment, the control unit 21 of the terminal 20 determines whether the code update condition is met based on the code update condition data 2835 in D110 of the terminal-side code update process in Figure 5-2. Then, by way of example and not limitation, if at least one code update condition is met, it is determined that the code update condition is met.

In the code update condition data 2835, a priority is set in association with each code update condition. If at least one of the code update conditions associated with a priority higher than a predetermined priority (threshold priority) is met, the code update condition may or may not be determined to be met.

In addition, which code update conditions to apply from among those defined in the code update condition data 2835 may be set in advance on the terminal 20 side or the server 10 side. In this case, if at least one of the code update conditions set to be applied is met, it may or may not be determined that the code update condition is met.

<Effects of the second modified example (1)>
This modified example shows a configuration in which the terminal 20 receives, via the communication I/F 22, an updated terminal display code (not limited to, but an example of third code information) that is sent from the server 10 based on the set time and to which a new code expiration date (not limited to, but an example of a third expiration date) is associated by the server 10.
As an example of the effect obtained by such a configuration, the terminal can receive, via the communication unit, third code information associated with a third expiration date by the server, which is sent from the server based on the set time.

In addition, this modified example shows a configuration in which the terminal 20 receives, via the communication I/F 22, an updated terminal display code (not limited to, but an example of fourth code information) associated with a new code expiration date (not limited to, but an example of fourth expiration date) by the server 10, which code is sent from the server 10 based on information about the user of the terminal 20 (e.g., user schedule information, user payment history, location of the terminal 20 (user of the terminal 20), etc.).
As an example of the effect obtained by such a configuration, the communication unit can receive fourth code information, which is transmitted from the server based on the information of the user of the terminal and to which the fourth expiration date is associated by the server.

In addition, this modified example shows a configuration in which the terminal 20 receives, via the communication I/F 22, an updated terminal display code (not limited to, but an example of the fifth code information) associated with a new code expiration date (not limited to, but an example of the fifth expiration date) by the server 10, which code is sent from the server 10 based on disaster information.
As an example of the effect obtained by such a configuration, the terminal can receive, via the communication unit, fifth code information to which a fifth expiration date is associated by the server, which is sent from the server based on information regarding the disaster acquired by the server.

<Second Modification Example (2)>
In the second embodiment, the terminal 20 requests the server 10 to update the terminal display code, but this is not limiting. Instead of requesting an update of the terminal display code, the terminal 20 may request the server 10 to extend the code expiration date associated with the stored terminal display code.

Figure 5-5 is a flowchart showing an example of the flow of processing executed by each device in this modified example. The left side shows the terminal-side code expiration date extension processing executed by the control unit 21 of the terminal 20, and the right side shows the server-side code expiration date extension processing executed by the control unit 11 of the server 10. These processes are, by way of example and not limitation, processes executed in the background in the aforementioned payment application processing of the terminal 20 and the aforementioned payment management processing of the server 10, respectively.

First, the control unit 21 performs a code expiration date extension condition determination process (D210). The code expiration date extension conditions can be, by way of example and not limitation, the same conditions as the code update conditions shown in Figure 5-4.

When applying the first terminal display code stock data 2831A, one terminal display code is stored, so this terminal display code is the target and D210 determination is made based on the code expiration date associated with this terminal display code.

On the other hand, when applying the second terminal display code stock data 2831B, since multiple terminal display codes are stored, it is sufficient to perform the D210 determination for each of these multiple terminal display codes based on the code expiration date associated with each terminal display code.

If it is determined that the code expiration date extension condition is met (D220: YES), the control unit 21 determines whether the device is online (D230). If it is determined that the device is online (D230: YES), the control unit 21 performs authentication processing (D240).

Specifically, by way of example and not limitation, an authentication screen is displayed on the display unit 24, and the user is prompted to enter an authentication password. It is then determined whether the entered authentication password matches an authentication password previously registered and stored in the payment application data 283. If they match, the authentication result is deemed "OK," and if they do not match, the authentication result is deemed "NG."

If the authentication result is "OK" (D250: YES), the control unit 21 sends code expiration date extension request information, which includes, by way of example and not limitation, the application ID and the code number of the terminal display code requesting an extension of the code expiration date, to the server 10 via the communication I/F 22 (D260).

Here, the "code expiration date extension request information" is information requesting (applying for) an extension of the code expiration date associated with the terminal display code stored in the terminal 20, and can also be considered a request for an extension of the code expiration date.
The "code expiration date extension request information" can also be said to be information requesting transmission of an extended code expiration date.

The control unit 11 of the server 10 determines whether or not code expiration date extension request information has been received from the terminal 20 (E210). If it is determined that the request has been received (E210: YES), the control unit 11 performs code expiration date extension processing (E220).

Specifically, by way of example and not limitation, the code management data for the application ID included in the received code expiration date extension request information is referenced in the code management database 159 of the storage unit 15. It is then determined whether the code number included in the received code expiration date extension request information is stored in that code management data, and if it is determined that the code number is stored, the code expiration date stored in association with that code number is extended and updated. Hereinafter, the code expiration date extended in this manner will be referred to as the "extended code expiration date."

Next, the control unit 21 transmits the extension code expiration date to the terminal 20 via the communication I/F 14 (E270).

The control unit 11 then determines whether to terminate the process (E290), and if it determines to continue the process (E290: NO), it returns to E210. If it determines to terminate the process (E290: YES), it terminates the server-side code expiration date extension process.

Also, if no code expiration date extension request information is received from the terminal 20 (E210: NO), the control unit 11 proceeds to E290.

When the extension code expiration date is received from the server 10 via the communication I/F 22 (D270), the control unit 21 updates the code expiration date stored in the terminal display code stock data 2831 in association with the corresponding code number with the received extension code expiration date (D280).

The control unit 21 then determines whether to terminate the process (D290), and if it determines to continue the process (D290: NO), it returns to D210. If it determines to terminate the process (D290: YES), it terminates the terminal-side code expiration date extension process.

Furthermore, if it is determined that the code expiration date extension condition is not met (D220: NO), if it is determined that the device is not online (D230: NO), or if it is determined that the authentication result is "NG" (D250: NO), the control unit 11 proceeds to D290.

In this process, when the extension code expiration date is received from the server 10, the terminal 20 may display information indicating that the code expiration date has been extended (for example, a message indicating that the code expiration date has been extended or an image indicating that the code expiration date has been extended) on the display unit 24 via a push notification, or, if a payment application is running, may display the information on the payment application screen of the display unit 24.

Furthermore, authentication processing does not necessarily need to be performed in this process, and may be omitted.

<Effects of the second modified example (2)>
This modified example shows a configuration in which the terminal 20 transmits code expiration date extension request information (not limited to this, but an example of information requesting the server to extend the first expiration date) to the server 10 via the communication I/F 22.
As an example of the effect obtained by such a configuration, it is possible to request the server to extend the first expiration date.

In addition, this modified example shows a configuration in which the terminal 20 performs a process (not limited to this, but an example of a process related to extending the first expiration date) of obtaining the extension code expiration date from the server 10 based on the execution of an authentication process (not limited to this, but an example of a process related to authenticating the user of the terminal) by the control unit 21.
As an example of the effect obtained by such a configuration, security can be improved when extending the first expiration date by having the control unit of the terminal perform processing related to extending the first expiration date based on the execution of processing related to authentication of the terminal user.

In this modification, the terminal 20 receives the extension code expiration date transmitted from the server 10 via the communication I/F 22. Then, information indicating that the code expiration date has been extended is displayed in the display area of the terminal 20.
As an example of the effect obtained by such a configuration, it is possible to notify the user of the terminal that the first expiration date has been extended, thereby improving convenience for the user.

<Second Modification Example (3)>
In the second embodiment, instead of the server 10 updating the terminal display code and sending it to the terminal 20 in response to a request from the terminal 20, the server 10 may update the terminal display code and send it to the terminal 20 without a request from the terminal 20, or it may not do so.

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

In this case, by way of example and not limitation, the server 10 performs a terminal display code update process at regular intervals or at specific times.
Alternatively, the server 10 may determine whether the code update condition is met at any time based on the same conditions as the code update condition described above, and if it determines that the code update condition is met, it performs a terminal display code update process.
Then, the server 10 pushes the updated terminal display code and the code expiration date to the terminal 20.

Furthermore, in the second variant (2), rather than the server 10 extending the code expiration date in response to a request from the terminal 20, the server 10 may extend the code expiration date and send it to the terminal 20 without a request from the terminal 20, or it may not do so.

In this case, by way of example and not limitation, the server 10 performs the code expiration date extension process at regular intervals or at specific times.
Alternatively, the server 10 may determine whether the code expiration date extension conditions are met at any time based on conditions similar to the code expiration date extension conditions described above, and if it determines that the code expiration date extension conditions are met, it may perform the code expiration date extension process.
Then, the server 10 pushes the extension code expiration date to the terminal 20.

<Second Modification Example (4)>
In the second embodiment, the process of updating the terminal display code has been described, but the present invention is not limited to this. Instead of the process of updating the terminal display code, the process of generating a new terminal display code may or may not be performed.

Specifically, by way of example and not limitation, new code generation request information requesting the generation of a new terminal display code is sent from terminal 20 to server 10. Based on receiving the new code generation request information from terminal 20, server 10 performs processing similar to the terminal display code generation processing described above to generate a new terminal display code, and stores it in code management data together with information such as the code generation date and time, payment number, and code expiration date. Server 10 can also transmit the generated new terminal display code and information regarding the code expiration date to terminal 20.

<Third Example>
The third embodiment is an embodiment relating to a method for setting a code expiration date (how to set a code expiration date).
The contents described in the third embodiment can be applied to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 6A is a diagram showing an example of information stored in the storage unit 15 of the server 10 in this embodiment.
In this embodiment, the storage unit 15 stores, by way of example and not limitation, an account management database 152, event data 154, and code expiration date setting data 156.

The account management database 152 is management data for each account of the payment application, and an example of the data structure is shown in FIG. 6B.
The account management database 152 stores account management data for each account.

Management data for each account may include, but is not limited to, application ID, credit score, terminal location history data, user schedule data, payment history data, and offline tendency data.

The application ID is the application ID stored in user registration data 153.

The credit score is a representation of the social credibility of the user of the terminal 20 as a number, a rank, or the like.
The credit score is calculated based on, for example and not by way of limitation, the payment history, age, employment status, annual income, etc. of the user of the terminal 20, and is updated as needed.

By way of example and not limitation, the credit score can be quantified using a scoring system ranging from "0 points" to "100 points," with a credit score of "100 points" indicating the user's highest social credibility and a credit score of "0 points" indicating the user's lowest social credibility.

The terminal position history data stores the history of the terminal's position (hereinafter referred to as "terminal position"). As a non-limiting example, the terminal position (hereinafter referred to as "calculated terminal position") calculated by the terminal 20 performing a position calculation process can be transmitted from the terminal 20 to the server 10 each time the terminal position is calculated or at regular intervals, and this calculated terminal position can be stored as the terminal position in the terminal position history data as needed.

In addition, alternatively, when transmitting the aforementioned code generation request information, code update request information, code expiration date extension information, etc. from terminal 20 to server 10, the latest terminal location may or may not be transmitted from terminal 20 to server 10.

The user schedule data is data that stores the user schedule information of the terminal 20 for this application ID. This user schedule data can be updated as needed in synchronization with the user schedule data 2834 (see Figure 5-3) stored in the storage unit 28 of the terminal 20.

The payment history data is the payment history data included in the payment management data for this application ID among the payment management data stored in the payment management database 157.

The offline tendency data is data that analyzes the tendency of the terminal 20 with this application ID to be offline. As a non-limiting example, the server 10 can store, as history, the periods in the offline tendency data when communication with the terminal 20 was not possible in the past.

Held event data 154 is data related to events for which payments can be made using a terminal display code, and stores information such as, but not limited to, the date and time of the event, the location of the event, and the stores participating in the event. This information is obtained in advance by server 10 from the event organizer, etc., and stored in the held event data 154.

Code expiration date setting data 156 is data used to set the code expiration date. This code expiration date setting data 156 defines a method for setting the code expiration date based on criteria such as, but not limited to, credit score, location (terminal location, user location), user schedule, payment history, offline tendency, etc., which are identified from the data included in the account-specific management data described above.

By way of example and not limitation, since the code expiration date is determined by the code generation date and time and the code expiration time, setting the code expiration time is essentially the same as setting the code expiration date.

(1) Credit Score The higher the credit score, the higher the social credibility of the user.
Thus, by way of example and not limitation, it may be possible to set a longer code validity period for a higher credit score. For example, multiple threshold conditions based on thresholds (graded thresholds) for the credit score may be set, and different code validity periods may be set depending on which threshold condition the credit score meets.

For example, if the credit score is "80 points or more," the code validity period can be set to "reference code validity period x 1.2," if the credit score is "60 points or more but less than 80 points," the code validity period can be set to "reference code validity period x 1.0," and if the credit score is "less than 60 points," the code validity period can be set to "reference code validity period x 0.8."

The "reference code validity period" is, by way of example and not limitation, the validity period set by the server 10 as a default.
By way of example and not limitation, the code validity periods such as "6 hours,""12hours,""18hours," and "24 hours" described in the first embodiment can be set as the reference code validity period.

(2) Terminal location (user location)
The code expiration date setting data 156 defines, by way of example and not limitation, conditions for setting the code expiration date based on the terminal location.
For example, the server 10 may set locations with high security (such as pinpoint locations or areas within a certain range) and locations with low security.
"Safety" here means that extending the code validity period is unlikely to pose any risk.

Examples of highly secure locations include, but are not limited to, locations where the terminal 20 is unlikely to be stolen by others (such as locations where the user is unlikely to leave the terminal 20 behind), such as the location of the user's home of the terminal 20 or an area nearby.
Examples of low security locations include, but are not limited to, locations where the terminal 20 is unlikely to be stolen by others (such as locations where the user is unlikely to leave the terminal 20 behind), such as the location of a restaurant such as an izakaya or an area nearby.

In this case, by way of example and not limitation, it may be possible to specify that if the terminal location is in a highly secure location, the code validity period should be set to a longer period than if the terminal location is in a less secure location.

For example, if the terminal location is in a highly secure location, the code validity period can be set to "reference code validity period x 1.2", and if the terminal location is in a less secure location, the code validity period can be set to "reference code validity period x 0.8".

(3) User Schedule The code expiration date setting data 156 defines, by way of example and not limitation, conditions for setting the code expiration date based on the user schedule.
For example, if a user is scheduled to attend a specific event within a predetermined time or within a predetermined number of days, there is a high possibility that payment will be made using a terminal display code.

For this reason, as a non-limiting example, if the user of terminal 20 is scheduled to attend a specific event within a specified time or number of days, the code validity period can be set to a period longer than the reference code validity period.

(4) Payment History The code expiration date setting data 156 defines, by way of example and not limitation, conditions for setting the code expiration date based on the payment history of the user of the terminal 20 .
If the payment history shows that the user of terminal 20 tends to make payments at the same store at regular intervals (for example, on a certain day of the week or a certain day of the month), there is a high possibility that the user of terminal 20 will also make payments at the same store the next time.

For this reason, as a non-limiting example, if the user of terminal 20 tends to make payments at the same store at regular intervals, the code validity period can be set to a period longer than the reference code validity period.

It is also possible to set the code validity period based on the frequency or number of times the user of the terminal 20 makes payments.
Specifically, the frequency (hereinafter referred to as "payment frequency") and number (hereinafter referred to as "number of payments") of payments made in a unit period are calculated based on the payment history data associated with the application ID.Then, the higher the payment frequency or the greater the number of payments, the longer the code validity period can be set.

(5) Offline Tendency The code expiration date setting data 156 defines, by way of example and not limitation, conditions for setting the code expiration date based on offline tendency.
If the terminal 20 frequently goes offline, the code validity period must be set long, otherwise there is a risk that payment will not be possible in an emergency.

As a non-limiting example, the frequency (hereinafter referred to as the "offline frequency") or number of times (hereinafter referred to as the "number of offline occurrences") that the terminal 20 goes offline during a unit period is calculated. Then, the higher the offline frequency or the greater the number of offline occurrences, the longer the code validity period can be set.

The above determination items are merely examples, and the settings can be changed as appropriate.
For example, the terminal 20 may have the user select one code validity period from among multiple code validity period candidates, and the selected code validity period may be transmitted from the terminal 20 to the server 10. The server 10 may associate the code validity period received from the terminal 20 with the application ID of the terminal 20, but this may not be the case.

In this embodiment, the control unit 11 of the server 10 performs, by way of example and not limitation, a code expiration date setting process before performing the terminal display code generation process (C320 in FIG. 4-14), the terminal display code update process (E120 in FIG. 5-2), and the code expiration date extension process (E220 in FIG. 5-5).

In the code expiration date setting process, the control unit 11 may, by way of example and not limitation, reference the code expiration date setting data 156 and set the code expiration date based on at least one of the multiple judgment items listed above, or may set the code expiration date based on a combination of these. For example, a user with a high credit score and a high offline frequency or number of offline visits may, or may not, be set with a longer expiration date than a user with the same credit score.

<Effects of the Third Embodiment>
The third embodiment shows a configuration in which the code expiration date is set by the server 10 based on information about the user of the terminal 20 .
As an example of the effect obtained by such a configuration, the terminal can cause the server to carry out settlement based on the first expiration date that is appropriately set based on the information of the user of the terminal.

In addition, the third embodiment shows a configuration in which the information about the user of the terminal 20 includes the user's credit score.
As an example of the effect obtained by such a configuration, the terminal can cause the server to make a settlement based on a first expiration date that is appropriately set based on the credit score of the terminal user.

Furthermore, the third embodiment shows a configuration in which the information about the user of the terminal 20 includes information about the user's location or information about the terminal's location.
As an example of the effect obtained by such a configuration, the terminal can have the server make a payment based on location information of the terminal user or a first expiration date that is appropriately set based on the location information of the terminal.

In the third embodiment, the information about the user of the terminal 20 includes user schedule information.
As an example of the effect obtained by such a configuration, the terminal can cause the server to carry out settlement based on the first expiration date that is appropriately set based on information about the schedule of the terminal user.

In addition, the third embodiment shows a configuration in which the user information of the terminal 20 includes payment history and payment frequency (or number of payments) based on the user's terminal display code (not limited to, but an example of payment information based on the user's code information).
As an example of the effect obtained by such a configuration, the terminal can have the server make a payment based on a first expiration date that is appropriately set based on payment information that is based on the code information of the terminal user.

Furthermore, the third embodiment shows a configuration in which the code expiration date is set based on the event information (not limited to this, but an example of information related to an event) acquired by the server 10 .
As an example of the effect obtained by such a configuration, the terminal can cause the server to make a settlement based on a first expiration date that is appropriately set based on information about the event acquired by the server.

<Fourth Example>
The fourth embodiment is an example of a measure to be taken when the code expiration date passes before the code display date. In this case, the code expiration date passes before the code display date, so the terminal display code displayed on the code display screen may become unusable.

The contents described in the fourth embodiment can be applied to any of the other embodiments and other modified examples.
Furthermore, the same components as those already mentioned are given the same reference numerals and will not be described again.

FIG. 7A is a diagram showing an example of the flow of a first code display process, which is an example of the code display process executed by the code display processing unit 2113 of the terminal 20 in this embodiment.
First, the code display processing unit 2113 determines a terminal display code to be displayed from among the terminal display codes stored in the terminal display code stock data 2831 (F110).

When a single code obtained from the server 10 is stored on the terminal 20 while online, the terminal display code stored in the first terminal display code stock data 2831A (see Figure 4-9) is determined to be the terminal display code to be displayed.

On the other hand, when multiple (two or more) codes obtained from the server 10 are stored on the terminal 20 while online, the oldest terminal display code (the terminal display code with the nearest code expiration date) among the terminal display codes stored in the second terminal display code stock data 2831 (see Figure 4-15) is selected as the terminal display code to be displayed, for example and not by way of limitation.

Then, the code display processing unit 2113 determines whether the remaining time until the code expiration date is shorter than the aforementioned code display time based on the code expiration date stored in association with the terminal display code determined in F110 and the time measured by the clock unit 29A (F120).

If it is determined that the remaining time until the code expiration date is shorter than the code display time (F120: YES), the code display processing unit 2113 deletes the terminal display code determined in F110 from the terminal display code stock data 2831 (F130). Then, the code display processing unit 2113 displays an error screen on the display unit 24 (F140), including, for example and not limitation, a message indicating that the terminal display code cannot be displayed, and then terminates the first code display process.

On the other hand, if it is determined that the remaining time until the code expiration date is not shorter than the code display time (F120: NO), the code display processing unit 2113 causes the display unit 24 to display a first code display screen including a code image of the terminal display code determined in F110 (F150). In this case, as described above, information regarding the code expiration date and information regarding the code display date may or may not be displayed on the first code display screen. The code display processing unit 2113 then terminates the first code display process.

In this process, if the remaining time until the code expiration date is shorter than the code display time, the terminal display code is deleted and the terminal display code is no longer displayed on the display unit 24.

In this process, if the remaining time until the code expiration date is shorter than the code display time, the terminal display code is deleted and the terminal display code is not displayed on the display unit 24, but this is not limited to this.

Specifically, as a memory area for temporarily storing information, a buffer that reserves the code display time is provided in the memory unit 28 of the terminal 20, by way of example and not limitation. For example, if the code display time is set to "5 minutes," a buffer that reserves "5 minutes" of time is provided.

In this case, because the code display time is reserved in the buffer, the control unit 21 of the terminal 20 processes the remaining code display time as "the actual remaining code display time + the code display time." Therefore, even though the actual remaining code expiration time is shorter than the code display time, the control unit 21 determines that the remaining code expiration time is equal to or greater than the code display time, and a code display screen including the terminal display code to be displayed is displayed on the display unit 24.

FIG. 7B is a diagram showing an example of the flow of a second code display process, which is another example of the code display process executed by the code display processing unit 2113 of the terminal 20 in this embodiment.
The same steps as those in the above-described process are denoted by the same reference numerals, and the repeated explanation will be omitted.

In this process, steps F130 and F140 in the process in Figure 7-1 are replaced with steps F230 and F240, respectively.

After F110, if it is determined that the remaining time until the code expiration date is shorter than the code display time (F120: YES), the code display processing unit 2113 performs code display expiration date change processing (F230). Specifically, by way of example and not limitation, the code display time is set to the same time as the remaining time until the code expiration date. In other words, the code display date is shortened so that the code expiration date and the code display date are the same.

Then, the code display processing unit 2113 causes the display unit 24 to display a second code display screen including a code image of the terminal display code determined in F110 (F240). In this case, as described above, information regarding the code expiration date and information regarding the changed code display expiration date may or may not be displayed on the second code display screen. Then, the code display processing unit 2113 ends the second code display process.

In this process, if the remaining time until the code expiration date is shorter than the code display time, the code display date is shortened so that the code expiration date and the code display date are the same, and the code display screen is displayed on the display unit 24.

FIG. 7C is a diagram showing an example of the flow of a third code display process, which is another example of the code display process executed by the code display processing unit 2113 of the terminal 20 in this embodiment.
The same steps as those in the above-described process are denoted by the same reference numerals, and the repeated explanation will be omitted.

In this process, steps F110, F130, and F140 in the process in Figure 7-1 are replaced with steps F310, F330, and F340, respectively.

In this process, multiple (two or more) codes obtained from the server 10 while online are stored on the terminal 20, meaning that data for multiple terminal display codes is stored in the second terminal display code stock data 2831B.

First, the code display processing unit 2113 determines, as a non-limiting example, the oldest terminal display code (the terminal display code with the nearest code expiration date) from among the terminal display codes stored in the second terminal display code stock data 2831B as the terminal display code to be displayed (F310).

If it is subsequently determined that the remaining time until the code expiration date is shorter than the code display time (F120: YES), the code display processing unit 2113 performs a terminal display code change process (F330). Specifically, by way of example and not limitation, among the terminal display codes stored in the second terminal display code stock data 2831B, the oldest terminal display code (the terminal display code with the nearest code expiration date) whose remaining time until the code expiration date is equal to or greater than the code display time is changed to the terminal display code to be displayed.

Then, the code display processing unit 2113 causes the display unit 24 to display a third code display screen including a code image of the terminal display code changed in F330 (F340). In this case, as described above, information regarding the code expiration date and information regarding the code display expiration date may or may not be displayed on the third code display screen. Then, the code display processing unit 2113 ends the third code display process.

In this process, if the remaining time until the code expiration date is shorter than the code display time, the terminal display code whose remaining time until the code expiration date is equal to or greater than the code display time is changed to be displayed, and the code display screen is displayed on the display unit 24.

In this process, the terminal display code is changed to the code to be displayed before the code display screen is displayed, but the present invention is not limited to this.
Specifically, after the code display processing unit 2113 displays the terminal display code to be displayed on the code display screen, it determines whether the remaining time until the code expiration date is shorter than the code display time. If this condition is met, it can perform a terminal display code change process to change the currently displayed terminal display code to a terminal display code whose remaining time until the code expiration date is equal to or longer than the code display time, and reflect this on the currently displayed code display screen. In other words, the terminal display code may or may not be changed while the code display screen is being displayed.

In addition to the various processes described above, by way of example and not limitation, if it is determined that the remaining time until the code expiration date is shorter than the code display time, the code expiration date associated with the terminal display code to be displayed can be extended.

Specifically, by way of example and not limitation, if it is determined that the remaining time until the code expiration date is shorter than the code display time, the control unit 21 extends the code expiration date so that the time (date and time) at which the code expiration date ends is the same as the time (date and time) at which the code display date and time ends.

When the terminal 20 is online, it can communicate with the server 10, and can communicate with the server 10 using a process similar to the terminal-side code expiration date extension process described above (see Figure 5-5), causing the server 10 to extend the code expiration date associated with the terminal display code to be displayed.

However, when offline, the terminal 20 cannot communicate with the server 10. Therefore, when offline, the above process is essentially a process of extending the code expiration date on the terminal 20 side.

Also, as an example and not a limitation, as shown in Figures 4-17, 4-18, and 4-19, the code display screen displayed on the display unit 24 of the terminal 20 can display information on the code expiration date in addition to the terminal display code image and payment number.
However, as shown in FIG. 4-16, for example, it is possible to display the information on the code display period on the code display screen but not the information on the code expiration date.

In this case, as mentioned above, by way of example and not limitation, the code display expiration date can be shortened so that it is the same as the code expiration date, and then the code display screen can display information about the code display expiration date without displaying information about the code expiration date.
In other words, the code expiration date can be integrated into the code display date, so that the code expiration date information is not displayed, but the code display date information is displayed. In this case, the code expiration date becomes essentially the same as the code display date.

<Effects of the Fourth Embodiment>
The fourth embodiment shows a configuration in which, when information about the code expiration date and the remaining time until the code expiration date is displayed on the code display screen, this information is changed from the code expiration date to the set expiration date and displayed on the code display screen.
As an example of the effect obtained by such a configuration, when the first expiration date is displayed in the display area of the terminal, by changing the first expiration date to the set expiration date and displaying it in the display area, it becomes possible to handle cases where the first expiration date expires before the display expiration date of the code information on the terminal, for example, thereby improving user convenience.

Fifth Example
If the server 10 sets a long period as the code expiration date associated with the terminal display code, security is low, and there is an increased risk that the terminal display code stored in the terminal 20 will be stolen by someone else.

In this embodiment, the terminal 20 transmits code generation request information requesting the generation of multiple (two or more) terminal display codes to the server 10 via the communication I/F 22. Upon receiving the code generation request information, the server 10 performs the terminal display code generation process.

In this embodiment, in the terminal display code generation process, the control unit 11 of the server 10 generates multiple terminal display codes with different code expiration start times (or start date and time) and end times (or end date and time). The data for the multiple generated terminal display codes is then stored in the code management database 159.

FIG. 8 shows an example of the code management database 159 stored in the storage unit 15 of the server 10 in this embodiment.
This code management database 159 is similar to the code management database 159 shown in FIGS. 4-6, but the data of the terminal display code stored together with the application ID in each code management data is partially different.

Specifically, the code management data stores, along with the application ID, two sets of terminal display codes (four in total), each set consisting of two terminal display codes, with the same code generation date and time but different code expiration date and time.

In this display example, four pieces of data, code numbers "C-n1" to "C-n4," are stored as data for a terminal display code with the code generation date and time set to "June 10, 2019, 9:00 AM" for the terminal 20 with application ID "U0001" or the user of the terminal 20.

The two terminal display codes with code numbers "C-n1" and "C-n2" have a code expiration period of "June 10, 2019, 9:00:00 to June 10, 2019, 14 hours, 59 minutes, 59 seconds." In other words, these two terminal display codes have a code expiration start time of "9:00," which is the code generation time, and a code validity time of "6 hours."
On the other hand, the two terminal display codes with code numbers "C-n3" and "C-n4" have a code expiration period of "June 10, 2019, 15:00:00 to June 10, 2019, 20:59:59." In other words, these two terminal display codes have a code expiration start time of "15:00," six hours after the code generation time, and a code validity period of "6 hours."

As such, the two terminal display codes with code numbers "C-n1" and "C-n2" and the two terminal display codes with code numbers "C-n3" and "C-n4" have the same code validity period, but the start times of the code validity periods are different, resulting in different code validity periods.

In this embodiment, the server 10 generates multiple terminal display codes as described above based on the code generation request information received from the terminal 20. Then, by way of example and not limitation, the server 10 transmits the multiple generated terminal display codes to the terminal 20 along with their respective code numbers and code expiration dates.

The terminal 20 receives multiple terminal display codes sent from the server 10, along with their respective code numbers and expiration dates. The terminal 20 then stores the received information in the terminal display code stock data 2831 in the memory unit 28.

<Effects of the Fifth Embodiment>
In the fifth embodiment, based on code generation request information (not limiting, but an example of information related to a request for transmission of code information) transmitted from the terminal 20, the terminal 20 receives, via the communication I/F 22, a first terminal display code image and a first payment number (not limiting, but an example of sixth code information) associated with a first code expiration date by the server 10, and a second terminal display code image and a second payment number (not limiting, but an example of seventh code information) associated with a second code expiration date by the server 10. The fifth embodiment shows a configuration in which the start time of the first code expiration date is different from the start time of the second code expiration date, and the end time of the first code expiration date is different from the end time of the second code expiration date.
As an example of the effect obtained by such a configuration, the terminal can receive and store multiple code information with different expiration start and end times, thereby increasing security and reducing the risk of the terminal display code stored in the terminal's memory being stolen by others.

<Fifth Modification>
In the fifth embodiment, in the terminal display code generation process, the server 10 generates multiple terminal display codes with different start times (or start date and time) and end times (or end date and time) of the code expiration date and transmits them to the terminal 20, but this is not limited to this.

As a non-limiting example, the server 10 may, but need not, generate and transmit to the terminal 20 multiple terminal display codes with different code expiration start times (or start dates and times) but the same code expiration end time (end date and time). In this case, the server 10 may generate terminal display codes with different code expiration times so that the code expiration end times (end dates and times) are the same.

Furthermore, as a non-limiting example, the server 10 may, or may not, generate and transmit to the terminal 20 multiple terminal display codes that have different end times (or end dates and times) of the code expiration period but the same start time (start date and time) of the code expiration period.

In addition, the number of terminal display codes with the same code expiration date (the number of terminal display codes in one set) and the number of terminal display codes with different code expiration dates (the number of sets) can be set in any way.

REFERENCE SIGNS LIST 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 (6)

A program executed by a terminal that processes payment based on code information,
receiving, from the server by a communication unit of the terminal, first code information associated with a first expiration date by the server;
and storing the received first code information in a storage unit of the terminal by a control unit of the terminal,
the payment-related process includes a process of displaying information indicating an offline state and the first code information in a display area of the terminal;
the payment is executed by the server based on the time when the first code information displayed in the display area is read by the code reader device and the first expiration date;
If the process related to the payment is performed in an offline state, after the online state is established, receiving payment information related to the payment from the server by the communication unit;
The terminal executes the process relating to the extension of the first expiration date by the control unit. 2. The program according to claim 1,
The process relating to the extension of the first expiration date includes a process of receiving information relating to the extended first expiration date from the server. 3. The program according to claim 2,
the process relating to the extension of the first expiration date includes a process of requesting the server to extend the first expiration date,
Information regarding the extended first expiration date is transmitted from the server based on the requesting process. 3. The program according to claim 2,
Information about the extended first expiration date is transmitted from the server without the terminal requesting the server to extend the first expiration date. An information processing method for a terminal that processes payment based on code information,
receiving, from the server by a communication unit of the terminal, first code information associated with a first expiration date by the server;
storing the received first code information in a storage unit of the terminal by a control unit of the terminal;
the payment-related process includes a process of displaying information indicating an offline state and the first code information in a display area of the terminal;
the settlement is executed by the server based on the time when the first code information displayed in the display area is read by the code reader device and the first expiration date;
If the process related to the payment is performed in an offline state, after the online state is established, receiving payment information related to the payment from the server by the communication unit;
The method includes performing a process related to the extension of the first expiration date by the control unit. A terminal that processes payment based on code information,
a communication unit that receives, from the server, first code information associated with a first expiration date by the server;
a control unit that controls storing the received first code information in a storage unit of the terminal;
the payment-related process includes a process of displaying information indicating an offline state and the first code information in a display area of the terminal;
the settlement is executed by the server based on the time when the first code information displayed in the display area is read by the code reader device and the first expiration date;
When the process related to the payment is performed in an offline state, the communication unit receives payment information related to the payment from the server after the process becomes online,
The control unit performs a process related to the extension of the first expiration date.