Payment devices, terminals, and electronic payment programs

Abstract

To reduce security risks in electronic payments. [Solution] The terminal device 1[q] includes an information acquisition unit 112 that acquires an offline token KY[q] associated with user U[q] of the terminal device 1[q] and an encryption key KS[q] from the payment device 3, and a display control unit 114 that displays an offline code image GY[q] on the display device 13, which is based on the offline token KY[q], a business identification token KZ that identifies the payment business operator related to the payment device 3, and a time encryption code TT[q] obtained by encrypting the terminal time value AG, which is the current time of the terminal device 1[q], with the encryption key KS[q].

Description

Technical Field

[0001] The present invention relates to a settlement device, a terminal, and an electronic settlement program.

Background Art

[0002] In a terminal device such as a smartphone (an example of a "terminal"), a technology related to electronic settlement is widespread, in which a code image based on a token supplied from a settlement device is displayed, and the displayed code image is read by a store terminal such as a POS terminal installed in a store or the like. For example, Patent Document 1 discloses a technology related to electronic settlement in which, based on a token supplied from a settlement device, a code image is displayed on a terminal device, and information based on the code image is transmitted from a store terminal that has read the displayed code image to the settlement device, and the settlement device performs settlement processing.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in the conventional technology, there was a security risk when performing electronic settlement using a code image based on a token, such as when the token supplied from the settlement device was leaked.

[0005] The present invention has been made in view of the above circumstances, and one of the problems to be solved is to provide a technology that can reduce the security risk in electronic settlement compared to the conventional technology.

Means for Solving the Problems

[0006] To solve the above problems, the electronic payment program according to the present invention is characterized in that the processor of a terminal that can communicate with a payment device functions as an acquisition unit that acquires a first token associated with the user of the terminal and an encryption key from the payment device, and a display control unit that displays a first code image on a display device based on the first token, a second token that identifies a payment business operator related to the payment device, and an encryption code obtained by encrypting a value based on the current time of the terminal using the encryption key.

[0007] Furthermore, the terminal according to the present invention is a terminal capable of communicating with a payment device, and is characterized by comprising: an acquisition unit that acquires a first token associated with the user of the terminal and an encryption key from the payment device; and a display control unit that causes a first code image to be displayed on a display device, based on the first token, a second token that identifies a payment business operator related to the payment device, and an encryption code obtained by encrypting a value based on the current time of the terminal using the encryption key.

[0008] Furthermore, the payment device according to the present invention is a payment device that can communicate with a terminal, and includes a supply unit that supplies to the terminal a first token associated with the user of the terminal and one encryption key from a plurality of encryption keys associated with the first token, and a receiving unit that receives first payment information including the first token and the encryption code from a store device that has read a first code image displayed on the terminal, which is based on the first token, a second token that identifies a payment business operator related to the payment device, and an encryption code obtained by encrypting a value based on the current time of the terminal, which is updated every unit of time, using the one encryption key, and the first payment information The device is characterized by comprising: a settlement unit that executes a settlement process corresponding to the user of the terminal when any of three time codes—a first time code obtained by encrypting a value based on the current time of the settlement device using one encryption key identified from among a plurality of encryption keys based on the first token contained in the report; a second time code obtained by encrypting a value based on a time that is a unit time in the future of the current time of the settlement device using one encryption key; and a third time code obtained by encrypting a value based on a time that is a unit time in the past of the current time of the settlement device using one encryption key—matches the encryption code indicated by the first settlement information. [Effects of the Invention]

[0009] According to the present invention, it is possible to reduce security risks in electronic payments compared to conventional technologies. [Brief explanation of the drawing]

[0010] [Figure 1] This is a block diagram showing an example of the configuration of the electronic payment system Sys according to the first embodiment of the present invention. [Figure 2] This is a block diagram showing an example of the configuration of terminal device 1[q]. [Figure 3] This is a block diagram showing an example of the configuration of payment device 3. [Figure 4] This is a sequence chart illustrating an example of the operation of the electronic payment system Sys. [Figure 5]It is a schematic diagram showing an example of an online code image display screen G1. [Figure 6] It is a schematic diagram showing an example of a payment method selection screen GS. [Figure 7] It is a sequence chart showing an example of the operation of an electronic payment system Sys. [Figure 8] It is a schematic diagram showing an example of an offline code image display screen G2. [Figure 9] It is a sequence chart showing an example of the operation of an electronic payment system Sys. [Figure 10] It is a sequence chart showing an example of the operation of an electronic payment system Sys. [Figure 11] It is a sequence chart showing an example of the operation of an electronic payment system Sys. [Figure 12] It is a schematic diagram showing an example of the data configuration of a payment code CC[q]. [Figure 13] It is a flowchart showing an example of the operation of a terminal device 1[q]. [Figure 14] It is a flowchart showing an example of the operation of a terminal device 1[q]. [Figure 15] It is a flowchart showing an example of the operation of a terminal device 1[q]. [Figure 16] It is a flowchart showing an example of the operation of a terminal device 1[q]. [Figure 17] It is a schematic diagram showing an example of an offline payment explanation screen G3. [Figure 18] It is a flowchart showing an example of the operation of a payment device 3. [Figure 19] It is a flowchart showing an example of the operation of a payment device 3. [Figure 20] It is a flowchart showing an example of the operation of a payment device 3. [Figure 21] It is a flowchart showing an example of the operation of a payment device 3. [Figure 22] It is a sequence chart showing an example of the operation of an electronic payment system Sys according to the second embodiment of the present invention. [Figure 23]It is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 24] It is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 25] It is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 26] It is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 27] It is a flowchart showing an example of the operation of the terminal device 1[q]. [Figure 28] It is a sequence chart showing an example of the operation of the electronic payment system Sys according to Modification 1 of the present invention. [Figure 29] It is a sequence chart showing an example of the operation of the electronic payment system Sys according to Modification 2 of the present invention. [Figure 30] It is a sequence chart showing an example of the operation of the electronic payment system Sys according to Modification 3 of the present invention. [Figure 31] It is a sequence chart showing an example of the operation of the electronic payment system Sys according to Modification 6 of the present invention.

Embodiments for Carrying Out the Invention

[0011] Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings. In each figure, the dimensions and scales of each part are appropriately different from the actual ones. Further, the embodiments described below are preferred specific examples of the present invention, and thus various technically preferable limitations are imposed. However, the scope of the present invention is not limited to these embodiments unless otherwise specified in the following description to limit the present invention.

[0012] <A. First Embodiment> Hereinafter, the first embodiment of the present invention will be described.

[0013] <A.1. Outline of the Electronic Payment System Sys> The outline of the electronic payment system Sys will be described while referring to FIGS. 1 to 3.

[0014] Figure 1 is a block diagram showing an example of the configuration of the electronic payment system Sys.

[0015] As shown in Figure 1, the electronic payment system Sys comprises a payment device 3, a store device 5 that can communicate with the payment device 3 via a network NW, and one or more terminal devices 1 that can communicate with the payment device 3 via a network NW, and provides electronic payment services to the user U of the terminal device 1.

[0016] In this embodiment, as an example, we assume that the electronic payment system Sys has multiple terminal devices 1. Specifically, in this embodiment, we assume that the electronic payment system Sys has Q terminal devices 1. Here, the value Q is a natural number satisfying "Q≧2". Furthermore, below, the q-th terminal device 1 among the Q terminal devices 1 provided by the electronic payment system Sys will be referred to as terminal device 1[q]. Here, the variable q is a natural number satisfying "1≦q≦Q". Furthermore, below, the user U who uses terminal device 1[q] will be referred to as user U[q].

[0017] Terminal device 1[q] (an example of a "terminal") is, for example, a mobile device such as a smartphone or tablet, and is carried by user U[q]. In this embodiment, the electronic payment program PG-T is installed on terminal device 1[q]. By executing the electronic payment program PG-T, terminal device 1[q] launches an electronic payment application (hereinafter sometimes referred to as the "payment app"). When user U[q] of terminal device 1[q] receives a service at a store where the store device 5 is installed, they can pay for the service by electronic payment by using the payment app running on terminal device 1[q] to display a code image GG based on the token KK obtained from the payment device 3 on terminal device 1[q].

[0018] Hereinafter, the code image GG displayed on terminal device 1[q] will be referred to as code image GG[q]. Code image GG[q] is, for example, a barcode or a two-dimensional code. In this embodiment, as an example, we assume that code image GG[q] is a barcode. Furthermore, hereafter, the token KK supplied from payment device 3 to terminal device 1[q] will be referred to as token KK[q].

[0019] In this embodiment, it is assumed that the store where the store device 5 is installed is a physical store located in the real world, i.e., a real store. Furthermore, in this embodiment, it is assumed that the services provided at the store are the sale of goods or the provision of services. In other words, in this embodiment, when a user U[q] of terminal device 1[q] receives goods or services at the store where the store device 5 is installed, the user U[q] can pay for such goods or services electronically.

[0020] Store device 5 is, for example, a POS (Point of Sales) register. When user U[q] of terminal device 1[q] pays for services provided by the store via electronic payment, store device 5 reads the code image GG[q] displayed on terminal device 1[q]. Next, store device 5 generates payment information DP[q] by adding store payment information to the payment code CC[q], which is the value indicated by the read code image GG[q], and supplies the generated payment information DP[q] to payment device 3. Here, store payment information includes, for example, store identification information to uniquely identify the store that provided services to user U[q], the payment amount that user U[q] should pay as consideration for the services provided to user U[q], and the payment date and time, which is the date and time when the payment is made.

[0021] When payment device 3 receives payment information DP[q] from store device 5, it executes payment processing based on said payment information DP[q]. Here, payment processing is the process of confirming payment from user U[q] of terminal device 1[q] to the store as consideration for the service received from the store.

[0022] Furthermore, in this embodiment, as an example, we assume that the payment device 3 manages the usage fees for terminal device 1[q] by user U[q]. Here, the usage fees for terminal device 1[q] include, for example, the purchase price of terminal device 1[q] and communication charges incurred when terminal device 1[q] communicates. In this embodiment, for example, on the payment date of each month, the payment device 3 deducts the usage fees for terminal device 1[q] from the bank account of user U[q] that has been registered with the payment device 3 in advance. In the following, the usage fees for terminal device 1[q] may be referred to as "telephone charges". Furthermore, in this embodiment, as an example, we assume that the payment device 3 manages the electronic money of user U[q] that is available at terminal device 1[q]. In this embodiment, we assume that the electronic money managed by the payment device 3 is so-called prepaid electronic money, and that user U[q] can use electronic money equivalent to the amount charged by pre-charging the electronic money. However, the present invention is not limited to this embodiment. The electronic money managed by the payment device 3 may also be so-called postpaid electronic money that can be used within a predetermined upper limit. Furthermore, in this embodiment, as an example, we assume that the payment device 3 is able to communicate with a credit card server operated by a credit card company, and that user U[q] can make payments using a credit card issued by the credit card company.

[0023] In this embodiment, the payment device 3 can perform payment processing on terminal device 1[q] corresponding to user U[q] using the payment method selected by user U[q] from among three payment methods: telephone bill combined payment, prepaid balance payment, and credit card payment. Here, combined telephone bill payment is a payment method in which the usage fee for terminal device 1[q] is added to the payment method and the user U[q] pays the store. Prepaid balance payment is a payment method in which the user U[q] pays the store using the electronic money managed by payment device 3. Credit card payment is a payment method in which the user U[q] pays the store using the user U[q]'s credit card.

[0024] Furthermore, in this embodiment, as described above, the payment device 3 issues tokens KK[q] in response to a request from terminal device 1[q] and supplies the issued tokens KK[q] to terminal device 1[q].

[0025] The following describes an example of the operation of the electronic payment system Sys according to this embodiment when the terminal device 1[q] and the payment device 3 are able to communicate, and the electronic payment system Sys provides electronic payment services to the user U[q] of the terminal device 1[q] (hereinafter sometimes referred to as "online electronic payment"). First, when user U[q] of terminal device 1[q] receives a service at a store where store device 5 is installed and pays for the service via online electronic payment, user U[q] operates terminal device 1[q] to launch the payment application on terminal device 1[q]. Next, when the payment application is launched, terminal device 1[q] requests token KK[q] from payment device 3. Next, payment device 3 supplies token KK[q] to terminal device 1[q] in response to the request from terminal device 1[q]. Next, terminal device 1[q] generates a payment code CC[q] based on the token KK[q] supplied by payment device 3 and displays a code image GG[q] representing the payment code CC[q]. Next, the store device 5 reads the code image GG[q] displayed on the terminal device 1[q] to generate payment information DP[q], which includes the payment code CC[q] indicated by the code image GG[q] and the store payment information, and supplies this payment information DP[q] to the payment device 3. Next, the payment device 3 executes the payment process based on the payment information DP[q] supplied from the store device 5, thereby confirming the payment from user U[q] to the store.

[0026] In the online electronic payment described above, the payment device 3 issues a token KK[q] in response to a request from the terminal device 1[q]. Therefore, online electronic payment can only be performed when the terminal device 1[q] and the payment device 3 can communicate, and cannot be performed when communication between the terminal device 1[q] and the payment device 3 is difficult. Accordingly, in the case where communication between the terminal device 1[q] and the payment device 3 is difficult, the electronic payment system Sys according to this embodiment performs payment processing using payment information DP[q] generated based on the token KK[q] stored in the terminal device 1[q].

[0027] The following describes an example of the operation of the electronic payment system Sys according to this embodiment when communication between terminal device 1[q] and payment device 3 is difficult, and when the electronic payment system Sys provides electronic payment services to user U[q] of terminal device 1[q] (hereinafter sometimes referred to as "offline electronic payment"). First, when user U[q] of terminal device 1[q] receives a service at a store where store device 5 is installed and pays for the service via offline electronic payment, user U[q] operates terminal device 1[q] to launch the payment application on terminal device 1[q]. Next, when the payment application is launched, terminal device 1[q] generates a payment code CC[q] based on the token KK[q] stored in terminal device 1[q] and displays a code image GG[q] representing the payment code CC[q]. Next, store device 5 reads the code image GG[q] displayed on terminal device 1[q] and generates payment information DP[q] including the payment code CC[q] indicated by the code image GG[q] and store payment information, and supplies this payment information DP[q] to payment device 3. Next, payment device 3 executes the payment process based on the payment information DP[q] supplied by store device 5, thereby confirming the payment from user U[q] to the store.

[0028] As described above, the electronic payment system Sys according to this embodiment can perform two types of electronic payments: online electronic payment when terminal device 1[q] and payment device 3 can communicate, and offline electronic payment when terminal device 1[q] and payment device 3 cannot communicate. Therefore, compared to an embodiment where only online electronic payment is possible, it can improve the convenience of the user U[q] of terminal device 1[q].

[0029] In the following, the token KK[q] acquired by terminal device 1 from payment device 3 in online electronic payment and used to generate payment code CC[q] will be referred to as online token KX[q], and the token KK[q] stored in terminal device 1[q] in offline electronic payment and used to generate payment code CC[q] will be referred to as offline token KY[q]. Furthermore, in the following, the payment code CC[q] generated by terminal device 1[q] from online token KX[q] in online electronic payments may be referred to as the online payment code CX[q], and the payment code CC[q] generated by terminal device 1[q] from offline token KY[q] in offline electronic payments may be referred to as the offline payment code CY[q]. Furthermore, in the following, the code image GG[q] displayed by terminal device 1[q] based on the online payment code CX[q] in online electronic payments may be referred to as the online code image GX[q], and the code image GG[q] displayed by terminal device 1[q] based on the offline payment code CY[q] in offline electronic payments may be referred to as the offline code image GY[q]. Furthermore, in the following, the payment processing performed by payment device 3 in online electronic payments may be referred to as online payment processing, and the payment processing performed by payment device 3 in offline electronic payments may be referred to as offline payment processing.

[0030] Figure 2 is a block diagram showing an example of the configuration of terminal device 1[q].

[0031] As shown in Figure 2, the terminal device 1[q] comprises a control device 11, a storage device 12, a display device 13, an input device 14, a communication device 15, and a bus 100 that connects these devices to each other.

[0032] The storage device 12 is a recording medium that can be read by the control device 11. The storage device 12 is configured to include, for example, volatile memory such as RAM (Random Access Memory) that functions as a work area for the control device 11, and non-volatile memory such as EEPROM (Electrically Erasable Programmable Read-Only Memory) that stores various information, and stores user identification information DID[q], acquired offline token information KYY[q], offline token related information DYY, business operator identification token KZ, setting information DS, and electronic payment program PG-T.

[0033] The user identification information DID[q] is identification information used to uniquely identify user U[q] of terminal device 1[q] from among the Q users U[1] to U[Q] managed by payment device 3.

[0034] The acquired offline token information KYY[q] is information containing one or more offline tokens KY[q] acquired by terminal device 1[q] from payment device 3. In this embodiment, it is assumed that terminal device 1[q] has acquired offline tokens KY[q] M times from payment device 3 during the period from when the payment application was first launched (initial launch) on terminal device 1[q] to the present. Here, the value M is a natural number satisfying "M≧1". Below, the offline token KY[q] acquired by terminal device 1[q] from payment device 3 on the mth time will be referred to as offline token KY[q][m]. Here, the variable m is a natural number satisfying "1≦m≦M".

[0035] Thus, in this embodiment, it is assumed that the acquired offline token information KYY[q] includes M offline tokens KY[q][1] to KY[q][M] acquired by the terminal device 1[q] from the payment device 3. However, the present invention is not limited to this embodiment. The acquired offline token information KYY[q] only needs to include at least the last acquired offline token KY[q][M] among the M offline tokens KY[q][1] to KY[q][M] acquired by the terminal device 1[q] from the payment device 3. For example, terminal device 1[q] may delete expired offline tokens KY[q][m] (specifically, offline tokens KY[q][m] whose expiration date has arrived, as indicated by the offline token validity period information DTY[q][m] described later) from the M offline tokens KY[q][1] to KY[q][M] acquired from payment device 3. Specifically, terminal device 1[q] may delete offline tokens KY[q][m] corresponding to the expired offline token validity period TY[q][m] (i.e., expired offline tokens KY[q]) from acquired offline token information KYY[q] if the expiration date of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] stored in the offline token-related information DYY stored in the storage device 12 is in the past time (i.e., expired). In this case, acquired offline token information KYY[q] will only include offline tokens KY[q] that are still within their validity period. Furthermore, for example, terminal device 1[q] may delete offline tokens KY[q][1] to KY[q][M-1] from the M offline tokens KY[q][1] to KY[q][M] acquired from payment device 3, except for the last acquired offline token KY[q][M]. Specifically, terminal device 1[q] may delete previously acquired offline tokens KY[q][M-1] when it acquires the latest offline token KY[q][M] from payment device 3. In this case, the acquired offline token information KYY[q] will contain only the latest offline token KY[q][M].

[0036] The offline token-related information DYY includes M offline tokens KY[q][1]~KY[q][M] and M offline token validity period information DTY[q][1]~DTY[q][M] corresponding one-to-one, M cryptographic keys KS[q][1]~KS[q][M] corresponding one-to-one, and offline blocking information DHY. In this embodiment, we assume, as an example, that the offline token-related information DYY includes M offline token validity period information DTY[q][1]~DTY[q][M] and M cryptographic keys KS[q][1]~KS[q][M], but the present invention is not limited to this embodiment. The offline token-related information DYY only needs to include at least the offline token validity period information DTY[q][M] corresponding to the last acquired offline token KY[q][M] among the M offline token validity period information DTY[q][1]~DTY[q][M], and the cryptographic key KS[q][M] corresponding to the last acquired offline token KY[q][M] among the M cryptographic keys KS[q][1]~KS[q][M]. For example, terminal device 1[q] may delete the encryption key KS[q][m] corresponding to the expired offline token KY[q][m] from the M encryption keys KS[q][1] to KS[q][M] obtained from payment device 3 (specifically, the encryption key KS[q][m] corresponding to the offline token KY[q][m] whose expiration date has arrived, as indicated by the offline token validity period information DTY[q][m]). Specifically, terminal device 1[q] may delete the encryption key KS[q][m] corresponding to the expired offline token KY[q][m] from the offline token related information DYY stored in storage device 12 if the expiration date of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] stored in storage device 12 is in the past time (i.e., the offline token KY[q][m] has expired). In this case, the offline token-related information DYY will only include the cryptographic key KS[q] corresponding to the offline token KY[q] that is within its validity period. Furthermore, for example, terminal device 1[q] may delete all encryption keys KS[q][1] to KS[q][M-1] from the M encryption keys KS[q][1] to KS[q][M] obtained from payment device 3, except for the last encryption key KS[q][M] obtained. Specifically, terminal device 1[q] may delete previously obtained encryption keys KS[q][M-1] when it obtains the latest encryption key KS[q][M] from payment device 3. In this case, the offline token-related information DYY will contain only the latest encryption key KS[q][M].

[0037] The offline token validity period information DTY[q][m] indicates the period during which the offline token KY[q][m] can be used in offline electronic payments, i.e., the validity period of the offline token KY[q][m], which is the offline token validity period TY[q][m]. In this embodiment, it is assumed that the offline token validity period TY[q][m] is a period that starts from the time of creation of the offline token KY[q][m] and ends at a time that has elapsed from the time of creation of the offline token KY[q][m] by the offline token validity period TSY. Here, in this embodiment, as an example, it is assumed that the offline token validity period TSY is set to "1 week". In other words, in this embodiment, as an example, it is assumed that the validity period of the offline token KY[q] is 1 week.

[0038] The encryption key KS[q][m] is information used to generate the offline payment code CY[q] in offline electronic payments.

[0039] The offline blocking information DHY is information used in offline electronic payment to determine whether or not to display the offline code image GY[q] on the terminal device 1[q]. Specifically, the offline blocking information DHY indicates whether or not the payment device 3 is capable of performing offline payment processing. More specifically, the offline blocking information DHY may indicate whether or not the functions of the payment device 3 for performing offline payment processing are operating without being blocked.

[0040] The business identification token KZ includes business identification information DKZ, which identifies the payment service provider managing payment device 3.

[0041] The configuration information DS includes token response information DSW, online token validity information DSX, offline token validity information DSY, and update time information DSC.

[0042] The token response information DSW indicates the waiting time of terminal device 1 (hereinafter referred to as "token response waiting time TSW," an example of the "first time") from the time terminal device 1 requests token KK from payment device 3 (or from the time the payment application is launched in terminal device 1[q]) until token KK is supplied to terminal device 1. In this embodiment, terminal device 1 waits for the supply of token KK from payment device 3 from the time terminal device 1 requests token KK from payment device 3 until the token response waiting time TSW has elapsed. Then, at the time when the token response waiting time TSW has elapsed from the time terminal device 1 requests token KK from payment device 3, terminal device 1 stops waiting for the supply of token KK from payment device 3. Here, in this embodiment, as an example, it is assumed that the token response waiting time TSW is set to "10 seconds." In the following, the period from the time terminal device 1 requests token KK from payment device 3 until the token response waiting time TSW has elapsed may be referred to as the token response waiting period TW (an example of the "first period"). Furthermore, the token response waiting period TW is not limited to the period from when terminal device 1 requests token KK from payment device 3 until a certain amount of time has elapsed. For example, the token response waiting period TW may be the period from the start of the payment application to the end of the payment application. In this case, the token response waiting time TSW may be the length of time from the start of the payment application to the end of the payment application.

[0043] The online token validity information DSX indicates the duration (hereinafter referred to as "online token validity time TSX") of the period during which the online token KX[q] can be used in online electronic payments (hereinafter referred to as "online token validity period TX[q]"). In this embodiment, as an example, we assume that the online token validity time TSX is set to "5 minutes". However, the present invention is not limited to this embodiment. The online token validity time TSX only needs to be longer than the token response waiting time TSW. In this embodiment, the online token validity period TX[q] is a period that starts from the time of creation of the online token KX[q] and ends at a time that has elapsed from the time of creation of the online token KX[q] by the online token validity time TSX.

[0044] The offline token validity information DSY indicates the offline token validity period TSY. As described above, the offline token validity period TSY is the length of the offline token validity period TY[q][m] during which the offline token KY[q][m] can be used in offline electronic payments. Also, as described above, in this embodiment, as an example, we assume that the offline token validity period TSY is set to "1 week". However, the present invention is not limited to this embodiment. The offline token validity period TSY only needs to be longer than the online token validity period TSX.

[0045] The update time information DSC is information indicating the update unit time TC. Here, the update unit time TC is the update cycle of the terminal time value AG based on the terminal time TG, which is the current time managed by terminal device 1[q]. In this embodiment, as an example, we assume that the update unit time TC is set to "1 minute". Also, in this embodiment, as an example, we assume that the terminal time value AG is a value obtained by expressing the terminal time TG in the order of "minutes". For example, in this embodiment, if the terminal time TG is "18:25:37", the terminal time value AG may be "1825", obtained by removing "37 seconds" from the terminal time TG. However, the present invention is not limited to such embodiments. The update unit time TC may be shorter than the offline token validity period TSY. Also, the update unit time TC may be shorter than the online token validity period TSX.

[0046] The control device 11 is configured to include a processor. The processor provided in the control device 11 is configured to include, for example, one or more CPUs (Central Processing Units). However, the processor provided in the control device 11 may be configured to include hardware such as a GPU (Graphics Processing Unit), DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), PLD (Programmable Logic Device), FPGA (Field Programmable Gate Array), etc., in addition to one or more CPUs, or in place of some or all of one or more CPUs. The processor provided in the control device 11 executes the electronic payment program PG-T stored in the storage device 12 and operates according to the electronic payment program PG-T, thereby functioning as an information transmission unit 111, an information acquisition unit 112, a code generation unit 113, and a display control unit 114.

[0047] The information transmission unit 111 is an example of a "request unit," and during the token response waiting period TW, from the start of the payment application in terminal device 1[q] until the token response waiting time TSW has elapsed, it transmits an online token request to the payment device 3 requesting the online token KX[q] and an offline token request requesting the offline token KY[q]. In addition, during the token response waiting period TW, the information transmission unit 111 transmits an online blockage information request to the payment device 3 requesting the online blockage information DHX and an offline blockage information request requesting the offline blockage information DHY. Here, online blocking information DHX is information used to determine whether or not to display the online code image GX[q] on terminal device 1[q] in online electronic payment. Specifically, online blocking information DHX is information indicating whether or not payment device 3 is capable of executing online payment processing. More specifically, online blocking information DHX may be information indicating whether or not the functions of payment device 3 for executing online payment processing are operating without being blocked. In the following, online blocking information DHX and offline blocking information DHY may be collectively referred to as blocking information DH.

[0048] The information acquisition unit 112 is an example of an "acquisition unit" and acquires online token KX[q], offline token KY[q], online block information DHX, and offline block information DHY supplied from the payment device 3 in response to a request from the terminal device 1[q].

[0049] The code generation unit 113 generates an online payment code CX[q] based on the online token KX[q] acquired by the information acquisition unit 112. The code generation unit 113 also generates an offline payment code CY[q] based on the offline token KY[q] acquired by the information acquisition unit 112 and stored in the storage device 12.

[0050] In online electronic payments, the display control unit 114 causes the display device 13 to display an online code image GX[q] based on the online payment code CX[q] generated by the code generation unit 113. In offline electronic payments, the display control unit 114 causes the display device 13 to display an offline code image GY[q] based on the offline payment code CY[q] generated by the code generation unit 113.

[0051] The display device 13 is hardware for displaying various types of information. The display device 13 can employ various display panels, such as a liquid crystal display panel or an organic EL display panel. In this embodiment, the display device 13 displays various images, such as an online code image GX[q] and an offline code image GY[q], under the control of the display control unit 114.

[0052] The input device 14 is hardware for receiving operations from user U[q] of terminal device 1[q]. The input device 14 can be, for example, a keyboard, mouse, microphone, switch, button, sensor, or a combination of these devices. The display device 13 and the input device 14 may be configured as a single unit. In this case, for example, a touch panel may be used as both the display device 13 and the input device 14.

[0053] The communication device 15 is hardware for communicating with an external device located outside the terminal device 1[q] via the network NW. In this embodiment, the information transmission unit 111 transmits various information to the payment device 3 via the communication device 15. The information acquisition unit 112 acquires various information from the payment device 3 via the communication device 15.

[0054] Figure 3 is a block diagram showing an example of the configuration of the payment device 3.

[0055] As shown in Figure 3, the payment device 3 comprises a control device 31, a storage device 32, a communication device 35, and a bus 300 that connects these devices to each other.

[0056] The storage device 32 is a recording medium that can be read by the control device 31. The storage device 32 is configured to include, for example, a volatile memory such as RAM that functions as a work area for the control device 31, and a non-volatile memory such as EEPROM that stores various information, and stores user management information DU, online token payout information DKX, offline token payout information DKY, business operator identification information DKZ, settlement management information DKP, setting information DS, and control program PG-S.

[0057] The user management information DU has Q records that correspond one-to-one with Q users U[1] to U[Q] managed by the payment device 3. Each record of the user management information DU includes, in addition to the user identification information DID[q] described above, electronic money balance information DPR[q], telephone charge information DTL[q], credit card information DCR[q], points information DPT[q], and user payment information DSH[q].

[0058] Electronic money balance information DPR[q] is information that shows the balance of electronic money held by user U[q]. The telephone charge information DTL[q] is information indicating the telephone charges that user U[q] should pay (i.e., the usage fee for terminal device 1[q]). Credit card information DCR[q] is information about a credit card owned by user U[q] that user U[q] has registered with payment device 3 via terminal device 1[q]. Specifically, credit card information DCR[q] indicates, for example, the card number, expiration date, etc., of the credit card owned by user U[q]. The point information DPT[q] is information regarding points awarded by the payment device 3 to user U[q]. In this embodiment, it is assumed that when the payment device 3 awards points to user U[q], user U[q] becomes able to use electronic money equivalent to the amount of points awarded. User payment information DSH[q] is information indicating the payment method selected by user U[q].

[0059] Online token payout information DKX has one or more records that correspond one-to-one with one or more online tokens KX issued by settlement device 3. Each record of online token payout information DKX includes the online token KX[q] issued by settlement device 3, the user identification information DID[q] of user U[q] corresponding to the terminal device 1[q] to which the online token KX[q] was issued, and information indicating the online token validity period TX[q] corresponding to the online token KX[q] (hereinafter referred to as "online token validity period information DTX[q]").

[0060] The offline token issuance information DKY has one or more records that correspond one-to-one with one or more offline tokens KY issued by the payment device 3. Each record of the offline token issuance information DKY includes the offline token KY[q] issued by the payment device 3, the cryptographic key KS[q] issued by the payment device 3 in accordance with the offline token KY[q], the user identification information DID[q] of user U[q] corresponding to the terminal device 1[q] to which the offline token KY[q] was issued, and the offline token validity period information DTY[q][m] indicating the offline token validity period TY[q][m] corresponding to the offline token KY[q]. Furthermore, the payment device 3 may delete records from among the multiple records in the offline token payout information DKY where the end of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] has arrived. Specifically, if the end of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q] is in the past time (i.e., the token has expired), the payment device 3 may delete the offline token KY[q][m] corresponding to the offline token validity period information DTY[q][m] (i.e., the expired offline token KY[q][m]) from among the multiple offline token KYs included in the offline token payout information DKY, and also delete the cryptographic key KS[q][m] corresponding to the offline token validity period information DTY[q][m] (i.e., the expired cryptographic key KS[q][m]) from among the multiple cryptographic keys KS included in the offline token payout information DKY. Furthermore, in the offline token payout information DKY, the payment device 3 may delete records from the M records corresponding to the M offline tokens KY[q][1] to KY[q][M] that were issued in accordance with user U[q], except for the record corresponding to the most recent offline token KY[q][M]. In other words, in the offline token payout information DKY, the payment device 3 may delete offline tokens KY[q] from the M offline tokens KY[q][1] to KY[q][M] that were issued in accordance with user U[q], except for the last offline token KY[q][M]. Also, in the offline token payout information DKY, the payment device 3 may delete encryption keys KS[q] from the M encryption keys KS[q][1] to KS[q][M] that were issued in accordance with user U[q], except for the last encryption key KS[q][M].

[0061] The payment management information DKP has one or more records that correspond one-to-one with one or more electronic payments performed in the electronic payment system Sys. Each record in the payment management information DKP contains payment information DP[q] corresponding to each electronic payment.

[0062] The control device 31 is configured to include a processor. The processor provided in the control device 31 is configured to include, for example, one or more CPUs. However, the processor provided in the control device 31 may be configured to include hardware such as a GPU, DSP, ASIC, PLD, FPGA, etc., in addition to one or more CPUs, or in place of some or all of the one or more CPUs. The processor provided in the control device 31 executes a control program PG-S stored in the storage device 32 and operates according to the control program PG-S, thereby functioning as an information supply unit 311, an information receiving unit 312, and a settlement processing unit 313.

[0063] The information supply unit 311 is an example of a "supply unit" and, in response to a request from the terminal device 1[q], supplies the online token KX[q], online blocking information DHX, offline token KY[q], and offline blocking information DHY to the terminal device 1[q].

[0064] The information receiving unit 312 is an example of a "receiving unit" and receives online token requests, online blockage information requests, offline token requests, and offline blockage information requests from the terminal device 1[q]. The information receiving unit 312 also receives payment information DP[q] from the store device 5.

[0065] The settlement processing unit 313 is an example of a "settlement unit" and executes settlement processing based on settlement information DP[q]. Specifically, in online electronic payments, the settlement processing unit 313 executes online settlement processing based on settlement information DP[q], and in offline electronic payments, it executes offline settlement processing based on settlement information DP[q].

[0066] The communication device 35 is hardware for communicating with external devices such as the terminal device 1[q] and the store device 5 that exist outside the settlement device 3 via the network NW. In the present embodiment, the information supply unit 311 supplies various types of information to the terminal device 1[q] via the communication device 35. Further, the information reception unit 312 acquires various types of information from the terminal device 1[q] and the store device 5 via the communication device 35.

[0067] <A.2. Operation of the Electronic Payment System Sys> Hereinafter, an outline of the operation of the electronic payment system Sys will be described while referring to FIGS. 4 to 11.

[0068] <A.2.1. Operation of the Electronic Payment System Sys in Online Electronic Payment> FIG. 4 is a sequence chart showing an example of the operation of the electronic payment system Sys when the electronic payment system Sys executes online electronic payment.

[0069] As shown in FIG. 4, when the user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed and pays the price of the service by electronic payment, the control device 11 of the terminal device 1[q] executes the electronic payment program PG-T based on the operation of the user U[q] to start the payment application (S11).

[0070] Next, the control device 11 of terminal device 1[q] determines whether the communication status of terminal device 1[q] is online (S12). Specifically, the control device 11 may determine whether the communication status of terminal device 1[q] is online by, for example, using the communication status monitoring function of terminal device 1[q] provided by the operating system of terminal device 1[q]. Here, "the communication status of terminal device 1[q] is online" means, for example, that terminal device 1[q] is in a state where it can communicate with an external device located outside of terminal device 1[q], or that when terminal device 1[q] performs wireless communication, the radio wave strength related to the wireless communication is above a predetermined strength. Note that the sequence chart shown in Figure 4 assumes that the communication status of terminal device 1[q] is online.

[0071] Next, the information transmission unit 111 of terminal device 1[q] transmits an online blockage information request to payment device 3 (S21). Here, the online blockage information request is a message requesting online blockage information DHX.

[0072] Then, in step S21, the control device 31 of the payment device 3 supplies online blocking information DHX to the terminal device 1[q] as a response to the online blocking information request supplied from the terminal device 1[q] (S22). Specifically, in step S22, the control device 31 first determines whether or not the online payment process in the payment device 3 can be executed, and generates online blocking information DHX indicating the result of that determination. Then, the information supply unit 311 of the control device 31 supplies the generated online blocking information DHX to the terminal device 1[q].

[0073] Next, the information transmission unit 111 of terminal device 1[q] transmits an online token request to payment device 3 (S23). Here, an online token request is a message requesting the online token KX[q].

[0074] Then, in step S23, the control device 31 of the payment device 3 supplies the online token KX[q] to the terminal device 1[q] as a response to the online token request supplied by the terminal device 1[q] (S24). Specifically, in step S24, the control device 31 first generates the online token KX[q] corresponding to the user U[q] of the terminal device 1[q]. Then, the information supply unit 311 of the control device 31 supplies the generated online token KX[q] to the terminal device 1[q].

[0075] In this embodiment, as an example, the case in which terminal device 1[q] transmits an online blockage information request to payment device 3 in step S21 and then transmits an online token request to payment device 3 in step S23 has been described, but the present invention is not limited to this embodiment. Terminal device 1[q] may transmit an online blockage information request to payment device 3 after transmitting an online token request to payment device 3. Alternatively, terminal device 1[q] may transmit both the online token request and the online blockage information request to payment device 3 simultaneously (for example, in the same message).

[0076] Next, the information transmission unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S31). Here, the offline blockage information request is a message requesting offline blockage information DHY.

[0077] Then, in step S31, the control device 31 of the payment device 3 supplies offline blockage information DHY to the terminal device 1[q] as a response to the offline blockage information request supplied from the terminal device 1[q] in step S31 (S32). Specifically, in step S32, the control device 31 first determines whether or not the offline payment process in the payment device 3 can be executed, and generates offline blockage information DHY indicating the result of that determination. Then, the information supply unit 311 of the control device 31 supplies the generated offline blockage information DHY to the terminal device 1[q].

[0078] Next, the information transmission unit 111 of terminal device 1[q] transmits an offline token request to payment device 3 (S33). Here, an offline token request is a message requesting the offline token KY[q].

[0079] Then, in step S33, the control device 31 of the payment device 3 supplies the offline token KY[q] and the encryption key KS[q] to the terminal device 1[q] as a response to the offline token request supplied by the terminal device 1[q] (S34). Specifically, in step S34, the control device 31 first generates the offline token KY[q] and the encryption key KS[q] corresponding to the user U[q] of the terminal device 1[q]. Then, the information supply unit 311 of the control device 31 supplies the generated offline token KY[q] and encryption key KS[q] to the terminal device 1[q].

[0080] In this embodiment, as an example, the case in which terminal device 1[q] transmits an offline blockage information request to payment device 3 in step S31 and then transmits an offline token request to payment device 3 in step S33 has been described, but the present invention is not limited to this embodiment. Terminal device 1[q] may transmit an offline blockage information request to payment device 3 after transmitting an offline token request to payment device 3. Alternatively, terminal device 1[q] may transmit both the offline token request and the offline blockage information request to payment device 3 simultaneously (for example, in the same message).

[0081] Next, in step S34, the information acquisition unit 112 of the terminal device 1[q] acquires the offline token KY[q] and encryption key KS[q] supplied from the payment device 3, and stores the acquired offline token KY[q] and encryption key KS[q] in the storage device 12 (S35). Note that since the acquisition of the offline token KY[q] in step S35 is the Mth acquisition (latest acquisition), the information acquisition unit 112 adds the acquired offline token information KYY[q] as offline token KY[q][M], and adds the encryption key KS[q] acquired in step S35 as encryption key KS[q][M] to the offline token-related information DYY. In this embodiment, as an example, we assume that the information acquisition unit 112 stores the offline blockage information DHY acquired in step S32 in the storage device 12. If the storage device 12 already stores offline blockage information DHY, the information acquisition unit 112 will overwrite the offline blockage information DHY already stored in the storage device 12 with the newly acquired offline blockage information DHY in step S32.

[0082] Furthermore, the code generation unit 113 of terminal device 1[q] determines whether the online payment processing execution function in payment device 3 is blocked based on the online blockage information DHX acquired by the information acquisition unit 112 in step S22 (S41). Note that the sequence chart shown in Figure 4 assumes that the online payment processing execution function in payment device 3 is not blocked, that is, that payment device 3 is capable of executing online payment processing. Hereafter, the state in which the online payment processing execution function in payment device 3 is blocked may be referred to as "online blocked state".

[0083] Next, the code generation unit 113 of the terminal device 1[q] generates an online payment code CX[q] based on the online token KX[q] acquired by the information acquisition unit 112 in step S24 (S42). Specifically, in step S42, the code generation unit 113 generates an online payment code CX[q] that includes the online token KX[q].

[0084] Subsequently, the display control unit 114 of the terminal device 1[q] generates display information for displaying the online code image GX[q] representing the online payment code CX[q] based on the online payment code CX[q] generated by the code generation unit 113 in step S42, and displays the online code image GX[q] on the display device 13 based on the generated display information (S43). Specifically, in step S43, the display control unit 114 displays the online code image display screen G1, which includes the online code image GX[q], on the display device 13.

[0085] Figure 5 is a schematic diagram showing an example of the online code image display screen G1.

[0086] As shown in Figure 5, the online code image display screen G1 comprises an online code image GX[q], a payment method display area A1, and a point usage selection button B1.

[0087] As described above, the online code image GX[q] is a barcode representing the online payment code CX[q]. However, the present invention is not limited to this embodiment. The online code image GX[q] may be, for example, a two-dimensional code representing the online payment code CX[q].

[0088] The point usage selection button B1 is a button used in online electronic payment to select whether or not to use points awarded to user U[q]. Although not shown in Figure 4, etc., in this embodiment, as an example, it is assumed that when user U[q] changes whether or not to use points using the point usage selection button B1 on the online code image display screen G1, the change is notified from terminal device 1[q] to payment device 3.

[0089] The payment method display area A1 displays the payment method used by user U[q] when U[q] uses electronic payment in the electronic payment system Sys. Specifically, the display control unit 114 displays the payment method of user U[q] in the payment method display area A1 based on the user payment information DSH[q]. Although not shown in Figure 4, etc., in this embodiment, as an example, it is assumed that the payment device 3 supplies the user payment information DSH[q] to the terminal device 1[q] in response to a request from the terminal device 1[q]. The payment method for user U[q] displayed in payment method display area A1 can be changed on the payment method selection screen GS, which is described below.

[0090] Figure 6 is a schematic diagram showing an example of the payment method selection screen in GS.

[0091] As shown in Figure 6, the payment method selection screen GS includes three radio buttons RB, including radio button RB1 for selecting telephone bill combined payment as a payment method in electronic payment, radio button RB2 for selecting prepaid balance payment as a payment method in electronic payment, and radio button RB3 for selecting credit card payment as a payment method in electronic payment; a confirmation button BS1 for confirming the payment method in electronic payment; and a credit registration button BS2 for displaying a screen (not shown) for registering credit card information DCR[q] on the display device 13. User U[q] can select the payment method corresponding to the selected radio button RB as the payment method for user U[q] in the electronic payment system Sys by selecting one of the three radio buttons RB on the payment method selection screen GS and pressing the confirmation button BS1.

[0092] Return to the explanation in Figure 4. As shown in Figure 4, the store device 5 uses a barcode reader or the like provided in the store device 5 to read the code image GG[q] (online code image GX[q]) contained in the screen (online code image display screen G1) displayed on the display device 13 of the terminal device 1[q] (S44). Subsequently, the store device 5 generates store payment information (store identification information, payment amount, payment date and time) based on the services provided by the store where the store device 5 is installed to user U[q], and generates payment information DP[q] which includes the generated store payment information and the payment code CC[q] (online payment code CX[q]) indicated by the code image GG[q] (online code image GX[q]) read in step S44 (S61). Then, the store device 5 transmits the payment information DP[q] generated in step S61 to the payment device 3 (S62).

[0093] Next, the settlement processing unit 313 of the settlement device 3 confirms the validity of the token KK[q] (online token KX[q]) included in the settlement code CC[q] (online settlement code CX[q]) based on the settlement code CC[q] (online settlement code CX[q]) included in the settlement information DP[q] supplied from the store device 5 (S63). In the sequence chart shown in FIG. 4, it is assumed that the token KK[q] (online token KX[q]) is valid. After that, the settlement processing unit 313 of the settlement device 3 executes settlement processing (online settlement processing) (S64). Then, the information supply unit 311 of the settlement device 3 transmits a register charging response indicating the result of the settlement processing (online settlement processing) in step S64 to the store device 5 (S65).

[0094] <A.2.2. Operation of the Electronic Payment System Sys in Offline Electronic Payment> FIG. 7 is a sequence chart showing an example of the operation of the electronic payment system Sys when the electronic payment system Sys executes offline electronic payment. In FIG. 7, it is assumed that the electronic payment system Sys cannot execute online electronic payment due to the communication state of the terminal device 1[q] being in an offline state.

[0095] As shown in FIG. 7, when the user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed and pays for the对价 of the service by electronic payment, the control device 11 of the terminal device 1[q] starts the settlement application by executing the electronic payment program PG-T based on the operation of the user U[q] (S11).

[0096] Next, the control device 11 of the terminal device 1[q] determines whether the communication state of the terminal device 1[q] is an online state (S12). As described above, in the sequence chart shown in FIG. 7, it is assumed that the result of the determination in step S12 is negative, that is, the communication state of the terminal device 1[q] is in an offline state.

[0097] If the result of the determination in step S12 is negative, the code generation unit 113 of terminal device 1[q] determines whether the offline payment processing execution function in payment device 3 is blocked based on the offline blockage information DHY stored in the storage device 12 (S51). Note that the sequence chart shown in Figure 7 assumes that the offline payment processing execution function in payment device 3 is not blocked, that is, that payment device 3 is capable of performing offline payment processing. Hereinafter, the state in which the offline payment processing execution function in payment device 3 is blocked may be referred to as "offline blocked state".

[0098] Next, the code generation unit 113 of the terminal device 1[q] obtains the latest offline token KY[q][M] from the storage device 12 (S52). Then, the code generation unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on the offline token KY[q][M] (S53). Specifically, in step S53, the code generation unit 113 generates an offline payment code CY[q] that includes the offline token KY[q][M].

[0099] Subsequently, the display control unit 114 of the terminal device 1[q] generates display information for displaying the offline code image GY[q] representing the offline payment code CY[q] based on the offline payment code CY[q] generated by the code generation unit 113 in step S53, and displays the offline code image GY[q] on the display device 13 based on the generated display information (S54). Specifically, in step S54, the display control unit 114 displays the offline code image display screen G2, which includes the offline code image GY[q], on the display device 13.

[0100] Figure 8 is a schematic diagram showing an example of the offline code image display screen G2.

[0101] As shown in Figure 8, the offline code image display screen G2 comprises an offline code image GY[q], a payment method display area A2, and a point usage selection button B2.

[0102] As described above, the offline code image GY[q] is a barcode representing the offline payment code CY[q]. In this embodiment, as an example, it is assumed that in the offline code image display screen G2, the two-dimensional code representing the offline payment code CY[q] is also displayed as the offline code image GY[q]. The payment method display area A2 shows the payment method used by user U[q] when U[q] uses electronic payment in the electronic payment system Sys. The point usage selection button B2 is a button that displays the current selection status of user U[q] regarding whether or not to use the points awarded to user U[q] in offline electronic payments.

[0103] Return to Figure 7 for the explanation. As shown in Figure 7, the store device 5 performs the process of reading the code image GG[q] (offline code image GY[q]) contained in the screen (offline code image display screen G2) displayed on the display device 13 of the terminal device 1[q] (S55). Subsequently, the store device 5 generates store payment information based on the services provided by the store where the store device 5 is installed to user U[q], and generates payment information DP[q] which includes the generated store payment information and the payment code CC[q] (offline payment code CY[q]) indicated by the code image GG[q] (offline code image GY[q]) read in step S55 (S61). Then, the store device 5 transmits the payment information DP[q] generated in step S61 to the payment device 3 (S62).

[0104] Next, the payment processing unit 313 of the payment device 3 verifies the validity of the token KK[q] (offline token KY[q][M]) contained in the payment code CC[q] (offline payment code CY[q]) contained in the payment information DP[q] supplied from the store device 5 (S63). Note that the sequence chart shown in Figure 7 assumes that the token KK[q] (offline token KY[q][M]) is valid. Subsequently, the settlement processing unit 313 of the settlement device 3 performs settlement processing (offline settlement processing) (S64). Then, the information supply unit 311 of the payment device 3 transmits a register charge response to the store device 5 indicating the result of the payment processing (offline payment processing) in step S64 (S65).

[0105] Figure 9 is a sequence chart showing another example of the operation of the electronic payment system Sys when it performs an offline electronic payment. In Figure 9, we assume that the electronic payment system Sys is unable to perform an online electronic payment because terminal device 1[q] failed to obtain the online token KX[q] from payment device 3.

[0106] As shown in Figure 9, when user U[q] of terminal device 1[q] receives a service at a store where store device 5 is installed and pays for the service by electronic payment, the processes of steps S11 and S12 described above are executed. Note that the sequence chart shown in Figure 9 assumes that the result of the determination in step S12 is positive, that is, the communication status of terminal device 1[q] is online.

[0107] Next, the information transmission unit 111 of terminal device 1[q] transmits an online blockage information request to payment device 3 (S21). However, the sequence chart shown in Figure 9 assumes that there is no response from payment device 3 to the online blockage information request. Furthermore, the information transmission unit 111 of terminal device 1[q] transmits an online token request to payment device 3 (S23). However, the sequence chart shown in Figure 9 assumes that there is no response from payment device 3 to the online token request. That is, as described above, the sequence chart shown in Figure 9 assumes that terminal device 1[q] fails to obtain the online token KX[q] from payment device 3. Furthermore, the information transmission unit 111 of terminal device 1[q] transmits an offline blockage information request to payment device 3 (S31). However, the sequence chart shown in Figure 9 assumes that there is no response from payment device 3 to the offline blockage information request. Furthermore, the information transmission unit 111 of terminal device 1[q] transmits an offline token request to payment device 3 (S33). However, the sequence chart shown in Figure 9 assumes that there is no response from payment device 3 to the offline token request.

[0108] Then, the code generation unit 113 of the terminal device 1[q] determines whether or not the payment device 3 is in an offline blocked state based on the offline blocked information DHY stored in the storage device 12 (S51). Note that the sequence chart shown in Figure 9 assumes that the payment device 3 is not in an offline blocked state, that is, that the payment device 3 is capable of performing offline payment processing.

[0109] Subsequently, the electronic payment system Sys performs offline electronic payment by executing the processes in steps S52 to S55 and steps S61 to S65.

[0110] Figure 10 is a sequence chart showing another example of the operation of the electronic payment system Sys when it performs offline electronic payment. In Figure 10, we assume a case where the electronic payment system Sys cannot perform online electronic payment because payment device 3 is in an online blocked state.

[0111] As shown in FIG. 10, when the user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed and pays the price of the service by electronic payment, the above-described processes of steps S11 and S12, steps S21 to S24, and steps S31 to S35 are executed. In the sequence chart shown in FIG. 10, it is assumed that the result of the determination in step S12 is affirmative, that is, the communication state of the terminal device 1[q] is an online state. Also, in the sequence chart shown in FIG. 10, as shown in steps S31 to S34, it is assumed that there is a supply of online occlusion information DHX, online token KX[q], offline occlusion information DHY, and offline token KY[q] from the settlement device 3. Thereafter, the code generation unit 113 of the terminal device 1[q] determines whether the settlement device 3 is in an online occlusion state based on the online occlusion information DHX acquired by the information acquisition unit 112 in step S22 (S41). In the sequence chart shown in FIG. 10, as described above, it is assumed that when the settlement device 3 is in an online occlusion state, that is, when the settlement device 3 cannot execute online settlement processing. When the result of the determination in step S41 is negative, that is, when the settlement device 3 is in an online occlusion state, the code generation unit 113 of the terminal device 1[q] determines whether the settlement device 3 is in an offline occlusion state based on the offline occlusion information DHY stored in the storage device 12 (S51). In the sequence chart shown in FIG. 10, it is assumed that when the settlement device 3 is not in an offline occlusion state, that is, when the settlement device 3 can execute offline settlement processing.

[0112] Thereafter, the electronic payment system Sys performs offline electronic payment by executing the processes of steps S52 to S55 and steps S61 to S65 (steps after S55 are not shown).

[0113] <A.2.3. Operation of the Electronic Payment System Sys at First Startup> Figure 11 is a sequence chart showing an example of the operation of the electronic payment system Sys when the payment application is first launched on terminal device 1[q] and the electronic payment system Sys performs the electronic payment.

[0114] As shown in Figure 11, when user U[q] of terminal device 1[q] pays for services received at a store where store device 5 is installed by electronic payment, and even if the payment application has never been launched on terminal device 1[q], the control device 11 of terminal device 1[q] launches the payment application by executing the electronic payment program PG-T based on the operation of user U[q] (S11).

[0115] Next, the control device 11 of terminal device 1[q] executes the process of step S12 described above. Note that the sequence chart shown in Figure 11 assumes that the result of the determination in step S12 is positive, that is, that the communication state of terminal device 1[q] is online.

[0116] Next, the information transmission unit 111 of the terminal device 1[q] transmits a setting information request to the payment device 3 (S13). Here, the setting information request is a message requesting setting information DS.

[0117] Then, in step S13, the control device 31 of the payment device 3 supplies the setting information DS to the terminal device 1[q] as a response to the setting information request supplied by the terminal device 1[q] (S14). Specifically, in step S14, the control device 31 first acquires the setting information DS stored in the storage device 32. Then, the information supply unit 311 of the control device 31 supplies the acquired setting information DS to the terminal device 1[q].

[0118] Furthermore, the information transmission unit 111 of terminal device 1[q] transmits a business identification token request to payment device 3 (S15). Here, a business identification token request is a message requesting a business identification token KZ.

[0119] Then, in step S15, the control device 31 of the payment device 3 supplies the business identification token KZ to the terminal device 1[q] as a response to the business identification token request supplied by the terminal device 1[q] (S16). Specifically, in step S16, the control device 31 first generates the business identification token KZ based on the business identification information DKZ stored in the storage device 32. Then, the information supply unit 311 of the control device 31 supplies the generated business identification token KZ to the terminal device 1[q].

[0120] In this embodiment, as an example, the terminal device 1[q] sends a configuration information request to the payment device 3 in step S13, and then sends a business identification token request to the payment device 3 in step S15. However, the present invention is not limited to this embodiment. The terminal device 1[q] may send a configuration information request to the payment device 3 after sending a business identification token request to the payment device 3. Alternatively, the terminal device 1[q] may send both the configuration information request and the business identification token request to the payment device 3 simultaneously (for example, in the same message).

[0121] Next, the information acquisition unit 112 of the terminal device 1[q] acquires the setting information DS supplied from the payment device 3 in step S14 and the business operator identification token KZ supplied from the payment device 3 in step S16, and stores the acquired setting information DS and business operator identification token KZ in the storage device 12 (S17).

[0122] Subsequently, the electronic payment system Sys performs the electronic payment by executing the processes from step S21 onward.

[0123] In this embodiment, the configuration information DS and the business identification token KZ are supplied from the payment device 3 to the terminal device 1[q] when the payment application is first launched on the terminal device 1[q]. However, the present invention is not limited to this embodiment.

[0124] For example, when the setting information DS is changed, the settlement device 3 may supply the changed setting information DS to the terminal device 1[q]. Specifically, when the setting information DS is changed and a settlement app startup notification (not shown) indicating that the settlement app has been started in the terminal device 1[q] is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply the changed setting information DS to the terminal device 1[q] as a response to the settlement app startup notification. Further, for example, when a settlement app startup notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply the setting information DS to the terminal device 1[q] regardless of whether the setting information DS has been changed.

[0125] Also, for example, when the business operator identification information DKZ is changed, the settlement device 3 may supply a business operator identification token KZ indicating the changed business operator identification information DKZ to the terminal device 1[q]. Specifically, when the business operator identification information DKZ is changed and a settlement app startup notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply a business operator identification token KZ based on the changed business operator identification information DKZ to the terminal device 1[q] as a response to the settlement app startup notification. In this case, the frequency at which the terminal device 1[q] acquires the business operator identification token KZ is lower than the frequency at which it acquires the online token KX[q]. Also, in this case, the frequency at which the terminal device 1[q] acquires the business operator identification token KZ is lower than the frequency at which it acquires the offline token KY[q]. Also, for example, when a settlement app startup notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply the business operator identification token KZ to the terminal device 1[q] regardless of whether the business operator identification information DKZ has been changed.

[0126] <Summary of the operation of the electronic payment system Sys> As described above, in this embodiment, the electronic payment system Sys performs offline electronic payment when online electronic payment is difficult, such as when the communication state of terminal device 1[q] is offline, when terminal device 1[q] fails to obtain the online token KX[q] from payment device 3, or when payment device 3 is in an online blocked state. Therefore, compared to, for example, an embodiment in which the electronic payment system can only perform online electronic payment, it is possible to reduce the possibility that user U[q] of terminal device 1[q] will have difficulty paying for services by electronic payment when receiving services at a store where store device 5 is installed. As a result, according to this embodiment, the decrease in convenience for payment for user U[q] who receives services at a store where store device 5 is installed can be reduced.

[0127] Furthermore, in this embodiment, when the payment application is launched on terminal device 1[q] (see step S11) and electronic payment is executed, terminal device 1[q] acquires an online token KX[q] from payment device 3 (see step S24) and also acquires an offline token KY[q] (see step S34). In other words, in this embodiment, terminal device 1[q] acquires the offline token KY[q] from payment device 3 at the time when terminal device 1[q] and payment device 3 communicate regarding electronic payment. Therefore, according to this embodiment, it is possible to reduce the number of processes other than electronic payment on terminal device 1[q] compared to a configuration in which terminal device 1[q] acquires the offline token KY[q] from payment device 3 at a time unrelated to the timing of electronic payment, such as a predetermined timing. As a result, according to this embodiment, it is possible to reduce the complexity of scheduling processes on terminal device 1[q] compared to a configuration in which terminal device 1[q] acquires the offline token KY[q] from payment device 3 at a time unrelated to the timing of electronic payment.

[0128] Also, in the present embodiment, the terminal device 1[q] stores the offline token KY[q] acquired from the settlement device 3 in the storage device 12 at the timing when electronic settlement is performed. Therefore, according to the present embodiment, when online electronic settlement becomes difficult due to communication failure or the like, it is possible to reduce the possibility that even offline electronic settlement becomes difficult to execute.

[0129] Also, in the present embodiment, the terminal device 1[q] displays the online code image GX[q] on the display device 13 only when the online block information DHX indicates that the settlement device 3 is not in the online blocked state, and also displays the offline code image GY[q] on the display device 13 only when the offline block information DHY indicates that the settlement device 3 is not in the offline blocked state. That is, according to the present embodiment, when it is difficult to execute online electronic settlement, the display of the online code image GX[q] on the terminal device 1[q] can be suppressed, and when it is difficult to execute offline electronic settlement, the display of the offline code image GY[q] on the terminal device 1[q] can be suppressed. Therefore, according to the present embodiment, for example, compared with a mode of displaying the code image GG[q] without considering the block information DH, the labor of the user U[q] related to the display of the code image GG[q] can be reduced.

[0130] <A.3. Outline of the settlement code CC[q]> Hereinafter, the outline of the settlement code CC[q] (online settlement code CX[q] and offline settlement code CY[q]) will be described while referring to FIG. 12.

[0131] FIG. 12 is a diagram showing an example of the data configuration of the online settlement code CX[q] and the offline settlement code CY[q].

[0132] As shown in FIG. 12, the online settlement code CX[q] includes a merchant identification token KZ, an online token KX[q], an allocated value VJ, and a code type value VV. Further, the offline settlement code CY[q] includes a merchant identification token KZ, an offline token KY[q], a time encryption code TT[q][n], an allocated value VJ, and a code type value VV.

[0133] The merchant identification token KZ is LZ-digit data composed of LZ code values VZ[1] to VZ[LZ]. Here, the value LZ is a natural number satisfying "LZ≧2". Also, in the present embodiment, it is assumed that each code value VZ is single-digit data composed of a single-digit number (0 to 9). However, the code value VZ may be single-digit data composed of a single alphanumeric character (a single-digit number or a single alphabet).

[0134] The online token KX[q] is LX-digit data composed of LX code values VX[1] to VX[LX]. Here, the value LX is a natural number satisfying "LX≧4". Also, in the present embodiment, it is assumed that each code value VX is single-digit data composed of a single-digit number (0 to 9). However, the code value VX may be single-digit data composed of a single alphanumeric character (a single-digit number or a single alphabet).

[0135] The offline token KY[q] is LY-digit data composed of LY code values VY[1] to VY[LY]. Here, the value LY is a natural number satisfying "LY≧2" and "LY<LX". Also, in the present embodiment, it is assumed that each code value VY is single-digit data composed of a single-digit number (0 to 9). However, the code value VY may be single-digit data composed of a single alphanumeric character (a single-digit number or a single alphabet).

[0136] The time-cryptographic code TT[q] is LT-digit data composed of LT code values ​​VT[1] to VT[LT]. Here, the value LT is a natural number satisfying "LT≧2" and "LT+LY=LX". That is, in this embodiment, the sum of the number of digits LY of the offline token KY[q] and the number of digits LT of the time-cryptographic code TT[q][n] is equal to the number of digits LX of the online token KX[q]. Also in this embodiment, it is assumed that each code value VT is a single-digit data composed of a single digit (0 to 9). However, the code value VT may also be a single-digit data composed of a single alphanumeric character (a single digit or a single letter).

[0137] The allocated value VJ is a single-digit data consisting of a single digit (0-9). However, the allocated value VJ may be a 1-bit value, a number with two or more digits, or a 1-digit or more alphanumeric string.

[0138] The code type value VV is a single-digit data consisting of a single number (0-9). However, the code type value VV may be a 1-bit value, a number with two or more digits, or a 1 or more alphanumeric string. The code type value VV is set to a value that indicates the type of payment code CC[q]. Specifically, if payment code CC[q] is an online payment code CX[q], the code type value VV is set to a value that indicates payment code CC[q] is an online payment code CX[q], for example, "1". Hereafter, the value that indicates payment code CC[q] is an online payment code CX[q] will be referred to as the "online code value". Also, if payment code CC[q] is an offline payment code CY[q], the code type value VV is set to a value that indicates payment code CC[q] is an offline payment code CY[q], for example, "2". Hereafter, the value that indicates payment code CC[q] is an offline payment code CY[q] will be referred to as the "offline code value".

[0139] The following describes the process by which the code generation unit 113 generates the payment code CC[q] (hereinafter referred to as the "code generation process"). In the following, the process by which the code generation unit 113 generates the online payment code CX[q] will be referred to as the "online code generation process". Also, in the following, the process by which the code generation unit 113 generates the offline payment code CY[q] will be referred to as the "offline code generation process".

[0140] In the online code generation process, the code generation unit 113 sets an online code value (for example, "1") to the code type value VV. Then, the code generation unit 113 generates an online payment code CX[q] by arranging the business identification token KZ stored in the storage device 12, the online token KX[q] acquired by the information acquisition unit 112 from the payment device 3, the redemption value VJ, and the code type value VV in a predetermined order.

[0141] In the offline code generation process, the code generation unit 113 generates a terminal time value AG based on the terminal time TG managed by the terminal device 1[q]. Specifically, the code generation unit 113 generates the terminal time value AG by removing the part representing "seconds" from the terminal time TG and leaving the parts representing "minutes" and "hours". Next, in the offline code generation process, the code generation unit 113 generates a time-encrypted code TT[q] by encrypting the terminal time value AG using the encryption key KS[q][M] corresponding to the last acquired offline token KY[q][M] from among the M encryption keys KS[q][1] to KS[q][M] stored in the storage device 12. In other words, in this embodiment, it is assumed that the time-encrypted code TT[q] is the value obtained by encrypting the terminal time value AG using the encryption key KS[q][M]. Furthermore, in the offline code generation process, the code generation unit 113 sets an offline code value (for example, "2") to the code type value VV. Then, in the offline code generation process, the code generation unit 113 generates the offline payment code CY[q] by arranging the business identification token KZ stored in the storage device 12, the offline token KY[q] acquired by the information acquisition unit 112 from the payment device 3, the time encryption code TT[q] generated by the code generation unit 113, the allocation value VJ, and the code type value VV in a predetermined order. In this embodiment, it is assumed that the number of digits in the online payment code CX[q] and the number of digits in the offline payment code CY[q] are equal.

[0142] As described above, in this embodiment, the code generation unit 113 updates the terminal time value AG at a period of update unit time TC. Specifically, in this embodiment, the code generation unit 113 updates the terminal time value AG every minute. When the terminal time value AG is updated, the code generation unit 113 updates the time encryption code TT[q] with the value obtained by encrypting the updated terminal time value AG with the encryption key KS[q][M], and updates the offline payment code CY[q] with the updated time encryption code TT[q]. Specifically, the updated offline payment code CY[q] is generated by arranging the business operator identification token KZ, the offline token KY[q], the updated time encryption code TT[q], the allocation value VJ, and the code type value VV in a predetermined order.

[0143] In the following, a time-cryptographic code TT[q] that has undergone (n+1) updates may be referred to as time-cryptographic code TT[q][n]. That is, a time-cryptographic code TT[q] that has never been updated may be referred to as time-cryptographic code TT[q][1], and a time-cryptographic code TT[q] that has undergone one update may be referred to as time-cryptographic code TT[q][2]. Here, the variable n is a natural number satisfying "1 ≤ n".

[0144] Thus, in this embodiment, the offline settlement code CY[q] includes, in addition to the offline token KY[q] that is updated every offline token valid time TSY (for example, one week), a time encryption code TT[q] that is updated every update unit time TC (for example, one minute), which is a time shorter than the offline token valid time TSY. That is, in this embodiment, the offline settlement code CY[q] is updated every update unit time TC, which is the update period of the time encryption code TT[q]. Therefore, according to this embodiment, compared with the mode in which the offline settlement code CY[q] is configured without including the time encryption code TT[q], the security risk associated with the leakage of the offline settlement code CY[q] can be reduced.

[0145] Also, in this embodiment, the offline settlement code CY[q] includes, in addition to the offline token KY[q], a merchant identification token KZ obtained at a timing different from that of the offline token KY[q]. Therefore, according to this embodiment, compared with the mode in which the offline settlement code CY[q] is configured without including the merchant identification token KZ, the security risk associated with the leakage of the offline settlement code CY[q] can be reduced. Similarly, in this embodiment, the online settlement code CX[q] includes, in addition to the online token KX[q], a merchant identification token KZ obtained at a timing different from that of the online token KX[q]. Therefore, according to this embodiment, compared with the mode in which the online settlement code CX[q] is configured without including the merchant identification token KZ, the security risk associated with the leakage of the online settlement code CX[q] can be reduced.

[0146] <A.4. Operation of Terminal Device 1[q]> Hereinafter, referring to FIGS. 13 to 17, an outline of the operation of the terminal device 1[q] when electronic settlement is executed will be described.

[0147] Figures 13 to 16 are flowcharts illustrating an example of the operation of terminal device 1[q] when electronic payment is performed in the electronic payment system Sys. Note that the flowcharts shown in Figures 13 to 16 begin when the payment application is launched on terminal device 1[q].

[0148] As shown in Figure 13, when the payment application is launched on terminal device 1[q], the control device 11 of terminal device 1[q] determines whether the communication status of terminal device 1[q] is online or not (S101). Note that the process in step S101 corresponds to the process in step S12 described above. If the result of the determination in step S101 is negative, that is, if the communication state of terminal device 1[q] is offline, the control device 11 of terminal device 1[q] proceeds to step S151.

[0149] If the result of the determination in step S101 is positive, that is, if the communication status of terminal device 1[q] is online, the information transmission unit 111 of terminal device 1[q] sends an online blockage information request to payment device 3 (S103). Note that the processing in step S103 corresponds to the processing in step S21 described above.

[0150] Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the online blockage information request (S105:N), it proceeds to step S109. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the online blockage information DHX transmitted from the payment device 3 by the communication device 15 as a response to the online blockage information request (S105:Y), it acquires the online blockage information DHX (S107).

[0151] Furthermore, the information transmission unit 111 of terminal device 1[q] transmits an online token request to payment device 3 (S109). Note that the processing in step S109 corresponds to the processing in step S23 described above.

[0152] Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the online token request (S111:N), it proceeds to step S115. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the online token KX[q] transmitted from the payment device 3 by the communication device 15 as a response to the online token request (S111:Y), it acquires the online token KX[q] (S113).

[0153] Furthermore, the information transmission unit 111 of terminal device 1[q] transmits an offline blockage information request to payment device 3 (S115). Note that the processing in step S115 corresponds to the processing in step S31 described above.

[0154] Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the offline blockage information request (S117:N), it proceeds to step S121. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the offline blockage information DHY transmitted from the payment device 3 by the communication device 15 as a response to the offline blockage information request (S117:Y), it acquires the offline blockage information DHY (S119).

[0155] Furthermore, the information transmission unit 111 of the terminal device 1[q] sends an offline token request to the payment device 3 (S121). Note that the processing in step S121 corresponds to the processing in step S33 described above.

[0156] Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the offline token request (S123:N), it proceeds to step S131. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the offline token KY[q] and encryption key KS[q] transmitted from the payment device 3 by the communication device 15 as a response to the offline token request (S123:Y), it stores the offline token KY[q] and encryption key KS[q] in the storage device 12 (S125). Specifically, in step S125, the information acquisition unit 112 acquires the offline token KY[q] and encryption key KS[q] supplied from the payment device 3. Next, the information acquisition unit 112 adds the acquired offline token KY[q] as the latest offline token KY[q][M] to the acquired offline token information KYY[q], and adds the acquired encryption key KS[q] as the latest encryption key KS[q][M] to the offline token related information DYY. Note that the process in step S125 corresponds to the process in step S35 described above.

[0157] As shown in Figure 14, the code generation unit 113 of the terminal device 1[q] determines whether or not the payment device 3 is in an online blocked state (S131). Specifically, in step S131, the code generation unit 113 determines whether or not the information acquisition unit 112 acquired online blocked information DHX in step S107, and whether or not the online blocked information DHX indicates that the payment device 3 is not in an online blocked state. Note that the processing in step S131 corresponds to the processing in step S41 described above.

[0158] If the result of the determination in step S131 is negative, that is, if the information acquisition unit 112 did not acquire the online blockage information DHX in step S107, or if the online blockage information DHX indicates that the payment device 3 is in an online blockage state, the control device 11 of the terminal device 1[q] proceeds to step S151. Furthermore, even if the result of the determination in step S131 is positive, if the information acquisition unit 112 has not acquired the online token KX[q] in step S113 (S133:N), the control device 11 of the terminal device 1[q] proceeds to step S151.

[0159] If the result of the determination in step S131 is positive, and the information acquisition unit 112 acquires the online token KX[q] in step S113 (S133:Y), the code generation unit 113 of the terminal device 1[q] executes the online code generation process and generates the online payment code CX[q] (S135). The process in step S135 corresponds to the process in step S42 described above.

[0160] Then, the display control unit 114 of the terminal device 1[q] generates display information for displaying the online code image GX[q] which represents the online payment code CX[q], and based on this display information, causes the display device 13 to display the online code image GX[q] (S137). Note that the process in step S137 corresponds to the process in step S43 described above.

[0161] Next, the control device 11 of the terminal device 1[q] determines whether or not user U[q] has performed an operation to terminate the payment application (hereinafter referred to as the "termination operation") using the input device 14 (S139). If the result of the determination in step S139 is positive, that is, if the termination operation is performed, the control device 11 of the terminal device 1[q] terminates the series of processes related to the flowcharts shown in Figures 13 to 16.

[0162] If the result of the determination in step S139 is negative, that is, if the termination operation has not been performed, the code generation unit 113 of the terminal device 1[q] determines whether or not an online code image update trigger has arrived, which is an opportunity to update the online code image GX[q] (S141). Here, an online code image update trigger is an opportunity for the online code image GX[q] displayed on the display device 13 to be updated.

[0163] In this embodiment, it is assumed that an online code image update trigger occurs when one or more of the three update conditions J1—online token time condition J11, online code image display condition J12, and online code image operation condition J13—are met. Here, online token time condition J11 is the condition that a time equivalent to the online token validity period TSX (5 minutes in this embodiment) has elapsed since the online code image GX[q] was displayed on the display device 13. Online code image display condition J12 is the condition that the online code image display screen G1 containing the online code image GX[q] transitions from background display to foreground display on the display device 13. Online code image operation condition J13 is the condition that a pull-down operation is performed while the online code image display screen G1 containing the online code image GX[q] is displayed on the display device 13.

[0164] If the result of the determination in step S141 is negative, that is, if an online code image update opportunity has not occurred, the control device 11 returns to step S137 and continues to display the online code image GX[q] on the display device 13. If the result of the determination in step S141 is positive, that is, if an online code image update trigger has arrived, the information transmission unit 111 of the terminal device 1[q] sends an online token request to the payment device 3 (S143).

[0165] Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the online token request related to step S143 (S145:N), it proceeds to step S151. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the online token KX[q] transmitted from the payment device 3 by the communication device 15 as a response to the online token request related to step S143 (S145:Y), it acquires the online token KX[q] (S147) and proceeds to step S135, in which step S135 it generates an online payment code CX[q] based on the online token KX[q] acquired in step S147.

[0166] As shown in Figure 15, the code generation unit 113 of the terminal device 1[q] determines whether or not the payment device 3 is in an offline blocked state (S151). Specifically, in step S151, the code generation unit 113 determines whether or not the information acquisition unit 112 acquired offline blocked information DHY in step S119, and whether or not the offline blocked information DHY indicates that the payment device 3 is not in an offline blocked state. Note that the processing in step S151 corresponds to the processing in step S51 described above.

[0167] If the result of the determination in step S151 is negative, that is, if the information acquisition unit 112 did not acquire the offline blockage information DHY in step S119, or if the offline blockage information DHY indicates that the payment device 3 is in an offline blockage state, the control device 11 of the terminal device 1[q] proceeds to step S171.

[0168] If the result of the determination in step S151 is positive, that is, if the offline blockage information DHY indicates that the payment device 3 is not in an offline blockage state, the code generation unit 113 of the terminal device 1[q] determines whether the latest offline token KY[q][M] stored in the storage device 12 is valid or not (S153). Specifically, in step S153, the code generation unit 113 determines whether one or more offline tokens KY[q][1] to KY[q][M] are stored in the storage device 12, and whether the offline token validity period TY[q][M] corresponding to the latest offline token KY[q][M] stored in the storage device 12 includes the current time. If the result of this determination is affirmative, the code generation unit 113 retrieves the latest offline token KY[q][M] from the storage device 12. Note that the processing in step S153 corresponds to the processing in step S52 described above.

[0169] If the result of the determination in step S153 is negative, that is, if the offline token KY[q] is not stored in the storage device 12, or if the latest offline token KY[q][M] stored in the storage device 12 has expired, the control device 11 of the terminal device 1[q] proceeds to step S171.

[0170] If the result of the determination in step S153 is positive, that is, if the latest offline token KY[q][M] stored in the storage device 12 is valid, the display control unit 114 of the terminal device 1[q] causes the display device 13 to display the offline payment explanation screen G3 (S155). Note that the processing in step S155 may be omitted.

[0171] Figure 17 is a schematic diagram showing an example of the offline payment explanation screen G3.

[0172] As shown in Figure 17, the offline payment explanation screen G3 includes an offline payment explanation display area A3, an explanation screen skip button CB3, and an offline payment confirmation button B3.

[0173] Offline payment explanation display area A3 is an area where text explaining offline electronic payment is displayed to user U[q]. The explanation screen skip button CB3 is a button that accepts input from user U[q] indicating that the offline payment explanation screen G3 should be skipped from the next time onward. The offline payment confirmation button B3 is a button that accepts an operation from user U[q] to confirm the execution of the offline electronic payment.

[0174] Return to Figure 15 for explanation. As shown in Figure 15, when user U[q] presses the offline payment confirmation button B3 on the offline payment explanation screen G3 displayed on the display device 13 in step S155, the code generation unit 113 of the terminal device 1[q] executes the offline code generation process and generates the offline payment code CY[q] based on the offline token KY[q][M] obtained from the storage device 12 in step S153 (S157). Note that the process in step S157 corresponds to the process in step S53 described above.

[0175] Then, the display control unit 114 of the terminal device 1[q] generates display information for displaying the offline code image GY[q] which represents the offline payment code CY[q], and based on this display information, causes the display device 13 to display the offline code image GY[q] (S159). Note that the process in step S159 corresponds to the process in step S54 described above.

[0176] Next, the control device 11 of the terminal device 1[q] determines whether or not user U[q] has performed a termination operation using the input device 14 (S161). If the result of the determination in step S161 is positive, that is, if the termination operation is performed, the control device 11 of the terminal device 1[q] terminates the series of processes related to the flowcharts shown in Figures 13 to 16.

[0177] If the result of the determination in step S161 is negative, that is, if the termination operation has not been performed, the code generation unit 113 of the terminal device 1[q] determines whether or not an offline code image update trigger has arrived (S163). Here, an offline code image update trigger is an event in which the offline code image GY[q] displayed on the display device 13 is updated.

[0178] In this embodiment, it is assumed that an offline code image update trigger occurs when one or more of the two update conditions J2, namely the offline code image display condition J22 and the offline code image operation condition J23, are met. Here, the offline code image display condition J22 is the condition that the offline code image display screen G2 containing the offline code image GY[q] transitions from background display to foreground display on the display device 13. The offline code image operation condition J23 is the condition that a pull-down operation is performed while the offline code image display screen G2 containing the offline code image GY[q] is displayed on the display device 13.

[0179] If the result of the determination in step S163 is positive, that is, if an offline code image update trigger has arrived, the control device 11 of the terminal device 1[q] proceeds to step S101 and executes again the series of processes related to the flowcharts shown in Figures 13 to 16.

[0180] If the result of the determination in step S163 is negative, that is, if an offline code image update trigger has not occurred, the code generation unit 113 of the terminal device 1[q] determines whether or not an update trigger for the time encryption code TT[q] has occurred due to the updating of the terminal time value AG (S165). If the result of the determination in step S165 is negative, that is, if the opportunity to update the time encryption code TT[q] has not arrived, the control device 11 of the terminal device 1[q] returns to step S159 and continues to display the offline code image GY[q] on the display device 13.

[0181] If the result of the determination in step S165 is positive, that is, if the terminal time value AG is updated and an opportunity to update the time encryption code TT[q] has arrived, the code generation unit 113 of the terminal device 1[q] updates the time encryption code TT[q] by encrypting the updated terminal time value AG with the encryption key KS[q][M] (S167).

[0182] Then, the code generation unit 113 of the terminal device 1[q] updates the offline payment code CY[q] with the updated time encryption code TT[q] (S169), and proceeds to step S159, causing the display device 13 to display the updated offline code image GY[q]. Specifically, in step S169, the code generation unit 113 generates the updated offline payment code CY[q] by arranging the business identification token KZ stored in the storage device 12, the latest offline token KY[q][M] stored in the storage device 12, the updated time encryption code TT[q], the payment value VJ, and the code type value VV in a predetermined order.

[0183] As shown in Figure 16, the display control unit 114 of the terminal device 1[q] displays an online payment waiting screen (not shown) on the display device 13 (S171) when offline code generation is difficult, such as when the device is in an offline blocked state (S151:N) or when there is no valid offline token KY[q] in the storage device 12 (S153:N), which notifies the user U[q] that the device is waiting to execute online electronic payment.

[0184] Then, the information transmission unit 111 of the terminal device 1[q] determines whether or not communication is possible between the terminal device 1[q] and the payment device 3 (S173). The information transmission unit 111 then waits until communication becomes possible between the terminal device 1[q] and the payment device 3.

[0185] When terminal device 1[q] and payment device 3 become able to communicate (S173:Y), the information transmission unit 111 of terminal device 1[q] sends an online token request to payment device 3 (S175). Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the online token request (S177:N), it returns the process to step S175 and resends the online token request. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the online token KX[q] transmitted from the payment device 3 by the communication device 15 as a response to the online token request (S177:Y), it acquires the online token KX[q] (S179).

[0186] Next, the code generation unit 113 of the terminal device 1[q] executes an online code generation process using the online token KX[q] acquired in step S179 to generate an online payment code CX[q] (S181).

[0187] Then, the display control unit 114 of the terminal device 1[q] generates display information for displaying the online code image GX[q] representing the online payment code CX[q] using the online payment code CX[q] generated in step S181, and based on this display information, causes the display device 13 to display the online code image GX[q] (S183).

[0188] Next, the control device 11 of the terminal device 1[q] determines whether or not user U[q] has performed a termination operation using the input device 14 (S185). If the result of the determination in step S185 is positive, that is, if the termination operation is performed, the control device 11 of the terminal device 1[q] terminates the series of processes related to the flowcharts shown in Figures 13 to 16.

[0189] If the result of the determination in step S185 is negative, that is, if the termination operation has not been performed, the code generation unit 113 of the terminal device 1[q] determines whether or not an online code image update trigger has arrived (S187).

[0190] If the result of the determination in step S187 is negative, that is, if an online code image update opportunity has not occurred, the control device 11 returns the process to step S183 and continues to display the online code image GX[q] on the display device 13. If the result of the determination in step S187 is positive, that is, if an online code image update trigger has arrived, the information transmission unit 111 of the terminal device 1[q] sends an online token request to the payment device 3 (S189).

[0191] Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the online token request related to step S189 (S191:N), it proceeds to step S171. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the online token KX[q] transmitted from the payment device 3 by the communication device 15 as a response to the online token request related to step S189 (S191:Y), it acquires the online token KX[q] (S193) and proceeds to step S181, thereby generating an online payment code CX[q] based on the online token KX[q] acquired in step S193.

[0192] Thus, according to this embodiment, offline electronic payment is performed when online electronic payment is difficult, such as in the case of an online blockage (S131:N) or when the acquisition of the online token KX[q] fails (S133:N). Therefore, compared to, for example, an electronic payment system that can only perform online electronic payments, it is possible to reduce the possibility that a user U[q] of terminal device 1[q] will have difficulty paying for services by electronic payment when receiving services at a store where store device 5 is installed.

[0193] Further, according to the present embodiment, when an offline code image GY[q] is being displayed (see step S159) and an opportunity for updating the offline code image arrives (S163: Y), an attempt is made to acquire the online token KX[q] again (see step S109). Therefore, according to the present embodiment, when online electronic settlement is primarily difficult and offline electronic settlement is being executed, it becomes possible to revert to online electronic settlement.

[0194] Also, according to the present embodiment, when in an offline blocked state (S151: N), and when there is no valid offline token KY[q] in the storage device 12 (S153: N), etc., when it is difficult to perform the offline code generation process, an attempt is made to acquire the online token KX[q] again (see step S175). Therefore, compared to a mode in which an attempt is not made to acquire the online token KX[q] when it is difficult to perform the offline code generation process, that is, a mode in which the code generation process is abandoned when it is difficult to perform the offline code generation process, when the user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed, the possibility that it will be difficult to pay the price of the service by electronic settlement can be reduced.

[0195] <A.5. Operation of the Settlement Device 3> Hereinafter, referring to FIGS. 18 to 21, an outline of the operation of the settlement device 3 when electronic settlement is executed will be described.

[0196] FIG. 18 is a flowchart showing an example of the operation of the settlement device 3 when an online token generation process is executed in the settlement device 3. Here, the online token generation process is a process of generating an online token KX[q] in response to an online token request from the terminal device 1[q] when electronic settlement is executed in the electronic settlement system Sys.

[0197] As shown in Figure 18, when an online token request is sent from the terminal device 1[q], the information receiving unit 312 of the payment device 3 receives the online token request (S301).

[0198] Next, the control device 31 of the payment device 3 generates an online token KX[q] (S303). Furthermore, the control device 31 of the payment device 3 determines the online token validity period TX[q] (S305). Specifically, in step S305, the control device 31 determines the online token validity period TX[q] as a period that starts from the time of creation of the online token KX[q] and ends at a time that has elapsed from the time of creation of the online token KX[q] by the online token validity period TSX (for example, 5 minutes).

[0199] Then, the control device 31 of the payment device 3 updates the online token payout information DKX (S307). Specifically, in step S307, the control device 31 adds a new record to the online token payout information DKX, and stores in the new record the user identification information DID[q] corresponding to user U[q] of terminal device 1[q], the online token KX[q] generated in step S303, and the online token validity period TX[q] determined in step S305.

[0200] Then, the information supply unit 311 of the payment device 3 supplies the online token KX[q] generated in step S303 to the terminal device 1[q] (S309), and terminates the online token generation process.

[0201] Figure 19 is a flowchart illustrating an example of the operation of payment device 3 when offline token generation processing is performed in payment device 3. Here, offline token generation processing is the process of generating offline token KY[q] in response to an offline token request from terminal device 1[q] when electronic payment is performed in the electronic payment system Sys.

[0202] As shown in Figure 19, when an offline token request is sent from the terminal device 1[q], the information receiving unit 312 of the payment device 3 receives the offline token request (S321).

[0203] Next, the control device 31 of the payment device 3 generates an offline token KY[q] (S323). Furthermore, the control device 31 of the payment device 3 determines the offline token validity period TY[q] (S325). Specifically, in step S325, the control device 31 determines the offline token validity period TY[q] as a period that starts from the time of generation of the offline token KY[q] and ends at the time when the offline token validity period TSY (for example, one week) has elapsed from the time of generation of the offline token KY[q]. Furthermore, the control device 31 of the payment device 3 generates the cryptographic key KS[q] (S327).

[0204] Then, the control device 31 of the payment device 3 updates the offline token payout information DKY (S329). Specifically, in step S329, the control device 31 adds a new record to the offline token payout information DKY, and stores in the new record the user identification information DID[q] corresponding to user U[q] of terminal device 1[q], the offline token KY[q] generated in step S323, the offline token validity period TY[q] determined in step S325, and the encryption key KS[q] generated in step S327.

[0205] Then, the information supply unit 311 of the payment device 3 supplies the offline token KY[q] generated in step S323 and the encryption key KS[q] generated in step S327 to the terminal device 1[q] (S331), and terminates the offline token generation process.

[0206] Figures 20 and 21 are flowcharts illustrating an example of the operation of payment device 3 when payment-related processing is performed in payment device 3. Here, payment-related processing includes processing to verify the validity of token KK[q] in payment device 3 and payment processing to be performed by payment device 3. When payment information DP[q] is supplied from store device 5, payment device 3 starts payment-related processing.

[0207] As shown in Figure 20, when payment information DP[q] is transmitted from the store device 5, the information receiving unit 312 of the payment device 3 receives the payment information DP[q] (S341).

[0208] Next, the settlement processing unit 313 of the settlement device 3 extracts the code type value VV from the settlement code CC[q] included in the settlement information DP[q] received in step S341 (S343). Then, the settlement processing unit 313 of the settlement device 3 determines whether the code type value VV extracted in step S343 represents an online code value (S345). That is, in step S345, the settlement processing unit 313 determines whether the settlement code CC[q] included in the settlement information DP[q] received in step S341 is an online settlement code CX[q].

[0209] If the result of the determination in step S345 is negative, that is, if the payment code CC[q] included in the payment information DP[q] is the offline payment code CY[q], the payment processing unit 313 of the payment device 3 proceeds to step S361. If the result of the determination in step S345 is positive, that is, if the payment code CC[q] included in the payment information DP[q] is the online payment code CX[q], the payment processing unit 313 of the payment device 3 extracts the online token KX[q] from the online payment code CX[q] included in the payment information DP[q] received in step S341 (S347).

[0210] Next, the settlement processing unit 313 of the settlement device 3 determines whether the online token KX[q] extracted in step S347 exists in the online token payout information DKX (S349). If the result of the determination in step S349 is negative, that is, if the online token KX[q] extracted in step S347 does not exist in the online token payout information DKX, the settlement processing unit 313 of the settlement device 3 proceeds to step S357.

[0211] If the result of the determination in step S349 is positive, that is, if the online token KX[q] extracted in step S347 exists in the online token payout information DKX, the settlement processing unit 313 of the settlement device 3 refers to the online token payout information DKX and determines whether the online token validity period TX[q] corresponding to the online token KX[q] extracted in step S347 is a period that includes the current time (S351). If the result of the determination in step S351 is negative, that is, if the online token validity period TX[q] corresponding to the online token KX[q] extracted in step S347 does not include the current time, the settlement processing unit 313 of the settlement device 3 proceeds to step S357.

[0212] If the result of the determination in step S351 is positive, that is, if the online token validity period TX[q] corresponding to the online token KX[q] extracted in step S347 includes the current time, the settlement processing unit 313 of the settlement device 3 executes online settlement processing (S353) and confirms the payment from user U[q] corresponding to the online token KX[q] extracted in step S347 to the store where the store device 5 that sent the settlement information DP[q] in step S341 is located. Then, the information supply unit 311 of the payment device 3 sends a register charge response (S355) to the store where the store device 5 that sent the payment information DP[q] in step S341 is located, notifying that the payment from user U[q] based on the payment information DP[q] has been confirmed, and terminates the payment-related processing.

[0213] On the other hand, if the result of the determination in step S349 is negative, and if the result of the determination in step S351 is negative, the information supply unit 311 of the payment device 3 sends a notification (S357) to the store where the store device 5 that sent the payment information DP[q] in step S341 is located, indicating that the payment from user U[q] based on the payment information DP[q] has failed, and terminates the payment-related processing.

[0214] As shown in Figure 21, if the result of the determination in step S345 is negative, that is, if the payment code CC[q] included in the payment information DP[q] is the offline payment code CY[q], the payment processing unit 313 of the payment device 3 extracts the offline token KY[q] from the offline payment code CY[q] included in the payment information DP[q] received in step S341 (S361).

[0215] Next, the settlement processing unit 313 of the settlement device 3 determines whether the offline token KY[q] extracted in step S361 exists in the offline token payout information DKY (S363). If the result of the determination in step S363 is negative, that is, if the offline token KY[q] extracted in step S361 does not exist in the offline token payout information DKY, the settlement processing unit 313 of the settlement device 3 proceeds to step S381.

[0216] If the result of the determination in step S363 is positive, that is, if the offline token KY[q] extracted in step S361 exists in the offline token payout information DKY, the settlement processing unit 313 of the settlement device 3 refers to the offline token payout information DKY and determines whether the offline token validity period TY[q] corresponding to the offline token KY[q] extracted in step S361 is a period that includes the current time (S365). If the result of the determination in step S365 is negative, that is, if the offline token validity period TY[q] corresponding to the offline token KY[q] extracted in step S361 does not include the current time, the settlement processing unit 313 of the settlement device 3 proceeds to step S381.

[0217] If the result of the determination in step S365 is affirmative, that is, if the offline token validity period TY[q] corresponding to the offline token KY[q] extracted in step S361 includes the current time, the settlement processing unit 313 of the settlement device 3 determines whether the same offline token KY[q] as the one included in the settlement information DP[q] received in step S341 was supplied during the period from a time twice the update unit time TC past the time the settlement information DP[q] was received in step S341 (for example, 2 minutes before the present) to the time the settlement information DP[q] was received in step S341 (hereinafter sometimes referred to as the "same token prohibition period") (S367). If the result of the determination in step S367 is positive, that is, if the same offline token KY[q] as the offline token KY[q] included in the settlement information DP[q] received in step S341 was received during the same token prohibition period, the settlement processing unit 313 of the settlement device 3 proceeds to step S381.

[0218] If the result of the determination in step S367 is negative, that is, if no offline token KY[q] identical to the offline token KY[q] included in the settlement information DP[q] received in step S341 has been received during the same token prohibition period, the settlement processing unit 313 of the settlement device 3 extracts the time encryption code TT[q] from the offline settlement code CY[q] included in the settlement information DP[q] received in step S341 (S369).

[0219] Furthermore, the settlement processing unit 313 of the settlement device 3 identifies the cryptographic key KS[q] corresponding to the offline token KY[q] extracted in step S361 by referring to the offline token payout information DKY (S371).

[0220] Next, the settlement processing unit 313 of the settlement device 3 encrypts the server time value AM, the future time value AMf, and the past time value AMp using the encryption key KS[q] identified in step S371 (S373).

[0221] Here, the server time value AM is a value based on the server time TM, which is the current time managed by the payment device 3, and is updated at intervals of the update unit time TC. Specifically, in this embodiment, as an example, we assume that the server time value AM is a value obtained by expressing the server time TM in the order of minutes. For example, in this embodiment, if the server time TM is "18:25:37", the server time value AM may be "1825", obtained by removing "37 seconds" from the server time TM. Therefore, if the server time TM and the terminal time TG are the same time, the server time value AM will be the same value as the terminal time value AG. However, in reality, there may be some error between the server time TM and the terminal time TG. In this case, the server time value AM and the terminal time value AG may be different values. Furthermore, the future time value AMf is a value based on a time that is one update unit time TC in the future of the server time TM. Specifically, in this embodiment, as an example, we assume that the future time value AMf is a value expressed in the order of minutes that is one update unit time TC (for example, 1 minute) in the future of the server time TM. For example, if the server time TM is "18:25:37", the future time value AMf may be "1826", which is obtained by removing "37 seconds" from "18:26:37", a time that is one minute in the future of the server time TM. Furthermore, the past time value AMp is a value based on a time that is one update unit time TC earlier than the server time TM. Specifically, in this embodiment, as an example, we assume that the past time value AMp is a value expressed in the order of minutes that is one update unit time TC (for example, 1 minute) earlier than the server time TM. For example, if the server time TM is "18:25:37", the past time value AMp may be "1824", which is obtained by removing "37 seconds" from "18:24:37", a time that is one minute earlier than the server time TM.

[0222] In the following, the value obtained by encrypting the server time value AM with the encryption key KS[q] will be referred to as the server time encryption code CM (an example of the "first time code"), the value obtained by encrypting the future time value AMf with the encryption key KS[q] will be referred to as the future time encryption code CMf (an example of the "second time code"), and the value obtained by encrypting the past time value AMp with the encryption key KS[q] will be referred to as the past time encryption code CMp (an example of the "third time code"). Furthermore, in the following, the server time encryption code CM, the future time encryption code CMf, and the past time encryption code CMp may be collectively referred to as the time encryption code CMM (an example of the "time code"). In other words, in step S373, the settlement processing unit 313 generates three time encryption codes CMM: a server time encryption code CM obtained by encrypting the server time value AM with the encryption key KS[q], a future time encryption code CMf obtained by encrypting the future time value AMf with the encryption key KS[q], and a past time encryption code CMp obtained by encrypting the past time value AMp with the encryption key KS[q].

[0223] Next, the settlement processing unit 313 of the settlement device 3 determines whether any of the three time encryption codes CMM generated in step S373 matches the time encryption code TT[q] extracted in step S369 (S375).

[0224] If the result of the determination in step S375 is positive, that is, if the time encryption code CMM generated in step S373 matches the time encryption code TT[q] extracted in step S369, the settlement processing unit 313 of the settlement device 3 executes offline settlement processing (S377) and confirms the payment from user U[q] corresponding to the offline token KY[q] extracted in step S361 to the store where the store device 5 that sent the settlement information DP[q] in step S341 is located. Then, the information supply unit 311 of the payment device 3 sends a register charge response (S379) to the store where the store device 5 that sent the payment information DP[q] in step S341 is located, notifying that the payment from user U[q] based on the payment information DP[q] has been confirmed, and terminates the payment-related processing.

[0225] On the other hand, if the result of the determination in step S363 is negative, if the result of the determination in step S365 is negative, if the result of the determination in step S367 is positive, and if the result of the determination in step S375 is negative, the information supply unit 311 of the payment device 3 sends a notification (S381) to the store where the store device 5 that sent the payment information DP[q] in step S341 is installed, indicating that the payment from user U[q] based on the payment information DP[q] has failed, and terminates the payment-related processing.

[0226] As described above, in this embodiment, the payment device 3 is capable of performing two types of payment processing: online payment processing and offline payment processing. Therefore, compared to, for example, an embodiment in which the payment device 3 is capable of performing only online payment processing, the convenience of the user U[q] using electronic payment can be improved.

[0227] Also, in the present embodiment, when two or more pieces of payment information DP[q] including the same offline token KY[q] are supplied during the same token prohibition period having a time length twice that of the update unit time TC, the payment device 3 restricts the offline payment process based on the payment information DP[q] supplied the second time and later. Therefore, according to the present embodiment, it is possible to restrict unauthorized payments using the offline token KY[q], and it is possible to reduce the security risk in the case where the offline token KY[q] is leaked or the like.

[0228] Also, in the present embodiment, in payment-related processing, in addition to the server time value AM, the payment device 3 uses the future time value AMf and the past time value AMp to verify the validity of the time encryption code TT[q] included in the offline payment code CY[q]. Therefore, according to the present embodiment, even if there is an error between the terminal time TG managed by the terminal device 1[q] and the server time TM managed by the payment device 3, the user U[q] of the terminal device 1[q] can use offline electronic payment. As a result, according to the present embodiment, for example, in payment-related processing, compared with the mode of verifying the validity of the time encryption code TT[q] based only on the server time value AM, the possibility that the user U[q] can use electronic payment can be improved, and the convenience of the user U[q] using electronic payment can be improved.

[0229] <B. Second Embodiment> Hereinafter, the second embodiment of the present invention will be described while referring to FIGS. 22 to 27. In addition, for elements whose operations and functions are the same as those in the first embodiment in each of the embodiments illustrated below, the reference numerals used in the description of the first embodiment are reused, and the detailed description of each is omitted as appropriate.

[0230] The electronic payment system Sys according to the second embodiment has the same configuration as the electronic payment system Sys according to the first embodiment. In the electronic payment system Sys according to the first embodiment, when performing online electronic payment, the terminal device 1[q] performed the generation of the online payment code CX[q] and the display of the online code image GX[q] after acquiring the offline token KY[q]. However, in the electronic payment system Sys according to the second embodiment, when performing online electronic payment, the terminal device 1[q] performs the generation of the online payment code CX[q] and the display of the online code image GX[q] with priority over acquiring the offline token KY[q].

[0231] Figure 22 is a sequence chart showing an example of the operation of the electronic payment system Sys when the electronic payment system Sys according to the second embodiment performs an online electronic payment.

[0232] As described above, in the sequence chart of the online electronic payment according to the first embodiment shown in Figure 4, in the electronic payment system Sys, after the processing of steps S21 to S24 related to the acquisition of the online token KX[q] by the terminal device 1[q] and the processing of steps S31 to S35 related to the acquisition of the offline token KY[q] by the terminal device 1[q], the processing of steps S41 to S43 related to the display of the online code image GX[q] by the terminal device 1[q] was executed. In contrast, the sequence chart of the online electronic payment according to the second embodiment shown in Figure 22 differs from the first embodiment in that, in the electronic payment system Sys, after the processing of steps S21 to S24 related to the acquisition of the online token KX[q] by the terminal device 1[q] and the processing of steps S41 to S43 related to the display of the online code image GX[q] by the terminal device 1[q], the processing of steps S31 to S35 related to the acquisition of the offline token KY[q] by the terminal device 1[q] is executed.

[0233] In other words, in the second embodiment, the display of the online code image GX[q] is prioritized over the acquisition of the offline token KY[q]. Therefore, according to the second embodiment, compared to the embodiment in which the online code image GX[q] is displayed after the acquisition of the offline token KY[q], the time until the online code image GX[q] is displayed is shortened, enabling the rapid execution of online electronic payments. In the second embodiment, the token response waiting period TW may be, for example, the period from the start of the payment application to the end of the payment application. Alternatively, the token response waiting period TW may include, for example, the period from the start of the payment application until the token response waiting time TSW has elapsed and the period from the start or end of the display of the online code image GX[q] until a predetermined time has elapsed.

[0234] Figures 23 to 27 are flowcharts illustrating an example of the operation of terminal device 1[q] when electronic payment is performed in the electronic payment system Sys according to the second embodiment. The flowcharts shown in Figures 23 to 27 begin when the payment application is launched on terminal device 1[q]. Note that the flowcharts shown in Figures 23 to 27 differ from the flowcharts according to the first embodiment shown in Figures 13 to 16 in that the processing in steps S115 to S125 is absent, while the processing in steps S201 to S231 is present.

[0235] As shown in Figure 23, when the payment application is launched on terminal device 1[q], the control device 11 of terminal device 1[q] executes the processes described in steps S101 to S113 above. Specifically, the control device 11 of terminal device 1[q] first determines whether the communication status of terminal device 1[q] is online (S101). If the result of the determination in step S101 is negative, the control device 11 of terminal device 1[q] proceeds to step S151. If the result of the determination in step S101 is positive, the information transmission unit 111 of terminal device 1[q] sends an online blockage information request to the payment device 3 (S103). Then, if the online blockage information DHX is received (S105:Y), the information acquisition unit 112 of terminal device 1[q] acquires the said online blockage information DHX (S107). The information transmission unit 111 of terminal device 1[q] also sends an online token request to the payment device 3 (S109). Then, when an online token KX[q] is received (S111:Y), the information acquisition unit 112 of the terminal device 1[q] acquires the online token KX[q] (S113).

[0236] Next, the control device 11 of the terminal device 1[q] executes the processes described in steps S131 to S133 above. Specifically, the control device 11 of terminal device 1[q], and the code generation unit 113 of terminal device 1[q], determine whether or not the payment device 3 is in an online blocked state (S131). If the result of the determination in step S131 is negative, the control device 11 of terminal device 1[q] proceeds to step S221. Even if the result of the determination in step S131 is positive, if the information acquisition unit 112 has not acquired the online token KX[q] in step S113 (S133:N), the control device 11 of terminal device 1[q] proceeds to step S221.

[0237] As shown in Figure 24, the control device 11 of the terminal device 1[q] executes the processes described in steps S135 to S139 above. Specifically, if the result of the determination in step S131 is positive, and the information acquisition unit 112 acquires the online token KX[q] in step S113 (S133:Y), the code generation unit 113 of the terminal device 1[q] generates the online payment code CX[q] (S135). Then, the display control unit 114 of the terminal device 1[q] displays the online code image GX[q] on the display device 13 (S137). Next, the control device 11 of the terminal device 1[q] determines whether or not the termination operation has been performed (S139).

[0238] Next, if the result of the determination in step S139 is positive, the control device 11 of terminal device 1[q] executes the processes in steps S201 to S211. Specifically, the information transmission unit 111 of terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S201). Note that the processing in step S201 corresponds to the processing in step S31 described above. Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the offline blockage information request (S203:N), it proceeds to step S207. On the other hand, if the communication device 15 receives the offline blockage information DHY transmitted from the payment device 3 as a response to the offline blockage information request (S203:Y), the information acquisition unit 112 of terminal device 1[q] acquires the offline blockage information DHY (S205). Also, the information transmission unit 111 of terminal device 1[q] transmits an offline token request to the payment device 3 (S207). Note that the processing in step S207 corresponds to the processing in step S33 described above. Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the offline token request (S209:N), it terminates the series of processes related to the flowchart shown in Figures 23 to 27. On the other hand, if the information acquisition unit 112 of terminal device 1[q] receives the offline token KY[q] and encryption key KS[q] transmitted from the payment device 3 to the communication device 15 as a response to the offline token request (S209:Y), it stores the offline token KY[q] and encryption key KS[q] in the storage device 12 (S211), and terminates the series of processes related to the flowchart shown in Figures 23 to 27.

[0239] Furthermore, if the result of the determination in step S139 is negative, the control device 11 of terminal device 1[q] executes the processes in steps S141 to S147 described above. Specifically, the code generation unit 113 of terminal device 1[q] determines whether or not an online code image update trigger has arrived (S141). If the result of the determination in step S141 is negative, the control device 11 returns the process to step S137 and continues to display the online code image GX[q] on the display device 13. If the result of the determination in step S141 is positive, the information transmission unit 111 of terminal device 1[q] sends an online token request to the payment device 3 (S143). Then, if the payment device 3 does not respond to the online token request related to step S143 (S145:N), the control device 11 of terminal device 1[q] proceeds the process to step S151. On the other hand, when the information acquisition unit 112 of the terminal device 1[q] receives the online token KX[q] transmitted from the payment device 3 by the communication device 15 as a response to the online token request related to step S143 (S145:Y), it acquires the online token KX[q] (S147), proceeds to step S135, and in step S135, generates an online payment code CX[q] based on the online token KX[q] acquired in step S147.

[0240] As shown in Figure 25, if the result of the determination in step S131 is negative, or if the result of the determination in step S133 is negative, the control device 11 of the terminal device 1[q] executes the processes in steps S221 to S231. Specifically, the information transmission unit 111 of terminal device 1[q] transmits an offline blockage information request to payment device 3 (S221). Then, if there is no response from payment device 3 to the offline blockage information request, the control unit 11 of terminal device 1[q] proceeds to step S227. On the other hand, if the communication device 15 receives the offline blockage information DHY transmitted from payment device 3 as a response to the offline blockage information request, the information acquisition unit 112 of terminal device 1[q] acquires the offline blockage information DHY (S225) (S225). Also, the information transmission unit 111 of terminal device 1[q] transmits an offline token request to payment device 3 (S227). Then, if there is no response from payment device 3 to the offline token request, the control unit 11 of terminal device 1[q] proceeds to step S151. On the other hand, when the information acquisition unit 112 of the terminal device 1[q] receives the offline token KY[q] and encryption key KS[q] transmitted from the payment device 3 by the communication device 15 as a response to the offline token request (S229:Y), it stores the offline token KY[q] and encryption key KS[q] in the storage device 12 (S231).

[0241] Next, the control device 11 of terminal device 1[q] executes the processes described in steps S151 to S155 above. Specifically, the code generation unit 113 of terminal device 1[q] determines whether or not the payment device 3 is in an offline blocked state (S151). If the result of the determination in step S151 is negative, the control device 11 of terminal device 1[q] proceeds to step S171. If the result of the determination in step S151 is positive, the code generation unit 113 of terminal device 1[q] determines whether or not the latest offline token KY[q][M] stored in the storage device 12 is valid (S153). If the result of the determination in step S153 is negative, the control device 11 of terminal device 1[q] proceeds to step S171. If the result of the determination in step S153 is positive, the display control unit 114 of terminal device 1[q] displays the offline payment explanation screen G3 on the display device 13 (S155) and proceeds to step S157.

[0242] As shown in FIG. 26, the control device 11 of the terminal device 1[q] executes the processes of steps S157 to S169. Specifically, the code generation unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on the offline token KY[q][M] stored in the storage device 12 (S157). The process in step S157 corresponds to the process in step S53 described above. Then, the display control unit 114 of the terminal device 1[q] displays an offline code image GY[q] based on the generated offline payment code CY[q] (S159). The process in step S159 corresponds to the process in step S54 described above. Next, the control device 11 of the terminal device 1[q] determines whether or not a termination operation has been performed (S161). If the result of the determination in step S161 is positive, the control device 11 of the terminal device 1[q] terminates the series of processes related to the flowcharts shown in Figures 23 to 27. If the result of the determination in step S161 is negative, the code generation unit 113 of the terminal device 1[q] determines whether or not an offline code image update trigger has arrived (S163). If the result of the determination in step S163 is affirmative, the control unit 11 of terminal device 1[q] proceeds to step S101 and executes the series of processes related to the flowcharts shown in Figures 23 to 27 again. If the result of the determination in step S163 is negative, the code generation unit 113 of terminal device 1[q] determines whether or not an opportunity to update the time encryption code TT[q] due to the update of the terminal time value AG has arrived (S165). If the result of the determination in step S165 is negative, the control unit 11 of terminal device 1[q] returns to step S159 and continues to display the offline code image GY[q] on the display device 13. If the result of the determination in step S165 is affirmative, the code generation unit 113 of terminal device 1[q] updates the time encryption code TT[q] by encrypting the updated terminal time value AG with the encryption key KS[q][M] (S167). Then, the code generation unit 113 of the terminal device 1[q] updates the offline payment code CY[q] with the updated time encryption code TT[q] (S169), and proceeds to step S159, causing the display device 13 to display the updated offline code image GY[q].

[0243] As shown in FIG. 27, when the determination result in step S151 is negative, or when the determination result in step S153 is negative, the control device 11 of the terminal device 1[q] executes the processes of steps S171 to S193. Specifically, the display control unit 114 of terminal device 1[q] displays an online payment waiting screen on the display device 13 (S171). Then, the information transmission unit 111 of terminal device 1[q] waits until terminal device 1[q] and payment device 3 can communicate (S173). After that, when terminal device 1[q] and payment device 3 can communicate, the information transmission unit 111 of terminal device 1[q] sends an online token request to payment device 3 (S175). Then, when the communication device 15 receives the online token KX[q] transmitted from payment device 3 (S177:Y), the information acquisition unit 112 of terminal device 1[q] acquires the online token KX[q] (S179). Next, the code generation unit 113 of terminal device 1[q] generates an online payment code CX[q] based on the acquired online token KX[q] (S181). Then, the display control unit 114 of the terminal device 1[q] displays the online code image GX[q] on the display device 13 based on the generated online payment code CX[q] (S183). Next, the control device 11 of the terminal device 1[q] determines whether or not a termination operation has been performed (S185). If the result of the determination in step S185 is positive, the control device 11 of the terminal device 1[q] terminates the series of processes related to the flowcharts shown in Figures 23 to 27. If the result of the determination in step S185 is negative, the code generation unit 113 of the terminal device 1[q] determines whether or not an online code image update trigger has arrived (S187). If the result of the determination in step S187 is negative, the control device 11 returns the process to step S183 and continues to display the online code image GX[q] on the display device 13. If the result of the determination in step S187 is positive, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S189). Then, if the control device 11 of terminal device 1[q] does not receive a response from the payment device 3 to the online token request related to step S189 (S191:N), it proceeds to step S171.When the information acquisition unit 112 of the other party's terminal device 1[q] receives the online token KX[q] transmitted by the communication device 15 from the settlement device 3 as a response to the online token request according to step S189 (S191: Y), it acquires the online token KX[q] (S193), advances the process to step S181, and generates an online settlement code CX[q] based on the online token KX[q] acquired in step S193.

[0244] As described above, in the second embodiment, the terminal device 1[q] preferentially executes the acquisition of the online token KX[q] (steps S101 to S113) and the display of the online code image GX[q] (steps S131 to S137) rather than the acquisition of the offline token KY[q] (steps S201 to S211). Therefore, according to the second embodiment, compared with the mode of displaying the online code image GX[q] after the acquisition of the offline token KY[q], the time until the online code image GX[q] is displayed is shortened, and rapid execution of online electronic settlement becomes possible.

[0245] <C. Variation> Each of the above embodiments can be variously modified. Specific modification modes are exemplified below. Two or more modes arbitrarily selected from the following examples can be appropriately combined within a range where they do not conflict with each other. In the variation examples exemplified below, for elements whose operations and functions are equivalent to those in the embodiments, the reference numerals referred to in the above description are reused, and the detailed description of each is appropriately omitted.

[0246] <C.1. Variation 1> In the first and second embodiments described above, an example has been described and explained in which the terminal device 1[q] acquires the offline token KY[q] after acquiring the online token KX[q] during electronic settlement. However, the present invention is not limited to such a mode. The terminal device 1[q] may acquire the online token KX[q] after acquiring the offline token KY[q] during electronic settlement.

[0247] FIG. 28 is a sequence chart showing an example of the operation of the electronic payment system Sys according to Modification 1 when performing online electronic payment.

[0248] As shown in FIG. 28, in the sequence chart of the online electronic payment according to this modification, in the electronic payment system Sys, after the processing of steps S31 to S34 related to the acquisition of the offline token KY[q] by the terminal device 1[q], the processing of steps S21 to S24 related to the acquisition of the online token KX[q] by the terminal device 1[q] is executed. This is different from the sequence chart of the online electronic payment according to the first embodiment shown in FIG. 4.

[0249] According to this modification, at the timing of electronic payment, the offline token KY[q] is acquired from the payment device 3 and the offline token KY[q] is stored in the storage device 12. Therefore, according to this embodiment, when it is difficult to perform online electronic payment due to communication failure or the like, it is possible to reduce the possibility that even offline electronic payment becomes difficult to execute.

[0250] <C.2. Modification 2> In the above-described first embodiment, second embodiment, and Modification 1, the mode in which the terminal device 1[q] executes the acquisition of the online token KX[q] and the acquisition of the offline token KY[q] at different timings during electronic payment has been exemplified and described. However, the present invention is not limited to such a mode. The terminal device 1[q] may acquire the online token KX[q] and the offline token KY[q] simultaneously during electronic payment.

[0251] FIG. 29 is a sequence chart showing an example of the operation of the electronic payment system Sys according to Modification 2 when performing online electronic payment.

[0252] As shown in Figure 29, the sequence chart for online electronic payment according to this modified example differs from the sequence chart for online electronic payment according to the first embodiment shown in Figure 4 in that, in the electronic payment system Sys, the processing of steps S71 to S74 is executed instead of the processing of steps S21 to S24 and steps S31 to S34.

[0253] Specifically, as shown in Figure 29, in this modified example, the control device 11 of the terminal device 1[q] sends a blockage information request to the settlement device 3 after executing the process in step S12 (S71). Here, the blockage information request is a message requesting online blockage information DHX and offline blockage information DHY. Then, in response to the blockage information request supplied from terminal device 1[q] in step S71, the control device 31 of the payment device 3 supplies online blockage information DHX and offline blockage information DHY to terminal device 1[q] (S72).

[0254] Next, the control device 11 of the terminal device 1[q] sends a token request to the payment device 3 (S73). Here, the token request is a message requesting the online token KX[q] and the offline token KY[q]. Then, in response to the token request supplied from terminal device 1[q] in step S73, the control device 31 of the payment device 3 supplies the online token KX[q], the offline token KY[q], and the cryptographic key KS[q] to terminal device 1[q] (S74). Subsequently, the electronic payment system Sys executes the processes in steps S35, S41-S44, and S61-S65.

[0255] According to this modified version, at the time of electronic payment, the offline token KY[q] is obtained from the payment device 3 and stored in the storage device 12. Therefore, according to this embodiment, if online electronic payment is difficult due to communication failure or the like, the possibility that offline electronic payment will also become difficult to execute can be reduced.

[0256] <C.3. Variant Example 3> In the above-described first embodiment, second embodiment, and variant examples 1 and 2, when the terminal device 1[q] performs an electronic payment, an online block information request (or an offline block information request, or a block information request) is transmitted to the payment device 3 separately from an online token request (or an offline token request, or a token request). However, the present invention is not limited to such a mode. The terminal device 1[q] may transmit an online token request and an online block information request as the same message during an electronic payment.

[0257] FIG. 30 is a sequence chart showing an example of the operation of the electronic payment system Sys according to Variant Example 3 when performing an online electronic payment.

[0258] As shown in FIG. 30, in the sequence chart of the online electronic payment according to this variant example, in the electronic payment system Sys, the process of step S81 is executed instead of the processes of steps S21, S23, S31, and S33, and the processes of steps S14 and S16 are executed. This is different from the sequence chart of the online electronic payment according to the first embodiment shown in FIG. 4.

[0259] Specifically, as shown in FIG. 30, in this variant example, after the control device 11 of the terminal device 1[q] executes the process of step S12, a payment application start notification is transmitted to the payment device 3 (S81). Here, as described above, the payment application start notification is a notification indicating that the payment application has been started in the terminal device 1[q]. Then, the control device 31 of the payment device 3, as a response to the payment application startup notification supplied from the terminal device 1[q] in step S81, performs the supply of the setting information DS to the terminal device 1[q] (S14), the supply of the operator identification token KZ (S16), the supply of the online block information DHX (S22), the supply of the online token KX[q] (S24), the supply of the offline block information DHY (S32), and the supply of the offline token KY[q] and the encryption key KS[q] (S34). After that, the electronic payment system Sys executes the processes of step S35, steps S41 to S44, and steps S61 to S65.

[0260] According to this modification example, in response to the payment application startup notification transmitted from the terminal device 1[q] to the payment device 3, various types of information including the online token KX[q] and the offline token KY[q] are supplied from the payment device 3 to the terminal device 1[q]. For this reason, according to this modification example, for example, compared with a mode in which the terminal device 1[q] transmits an online block information request separately from the online token request to the payment device 3, the control in the terminal device 1[q] can be simplified.

[0261] <C.4. Modification Example 4> In the above-described first embodiment, second embodiment, and modification examples 1 to 3, the token response waiting time TSW, the online token valid time TSX, the offline token valid time TSY, and the update unit time TC are illustrated and described as being notified from the payment device 3 as the setting information DS. However, the present invention is not limited to such a mode. Part or all of the token response waiting time TSW, the online token valid time TSX, the offline token valid time TSY, and the update unit time TC may be stored as fixed values in the storage device 12 of the terminal device 1[q].

[0262] <C.5. Modification Example 5> In the first and second embodiments and modifications 1 to 4 described above, the case in which the blocking information DH is information indicating whether or not the payment device 3 is capable of performing payment processing was explained as an example, but the present invention is not limited to such embodiments. The blocking information DH may also be information indicating whether or not the payment device 3 is capable of performing payment processing according to each payment method.

[0263] Specifically, in this modified example, the online blockage information DHX includes online combined payment blockage information DHX1, which indicates whether online payment processing by combined telephone bill payment is possible; online balance payment blockage information DHX2, which indicates whether online payment processing by prepaid balance payment is possible; and online card payment blockage information DHX3, which indicates whether online payment processing by credit card payment is possible. Here, online combined payment blockage information DHX1 may be information indicating whether the function of the payment device 3 for executing online payment processing by combined telephone bill payment is operating without blockage. Online balance payment blockage information DHX2 may be information indicating whether the function of the payment device 3 for executing online payment processing by prepaid balance payment is operating without blockage. Online card payment blockage information DHX3 may be information indicating whether the function of the payment device 3 for executing online payment processing by credit card payment is operating without blockage. In the following, online combined payment blockage information DHX1, online balance payment blockage information DHX2, and online card payment blockage information DHX3 may be collectively referred to as individual online blockage information DHX0. Furthermore, in this modified example, the offline blockage information DHY includes offline combined payment blockage information DHY1, which indicates whether offline payment processing by telephone bill combined payment is possible; offline balance payment blockage information DHY2, which indicates whether offline payment processing by prepaid balance payment is possible; and offline card payment blockage information DHY3, which indicates whether offline payment processing by credit card payment is possible. Here, offline combined payment blockage information DHY1 may be information indicating whether the function of the payment device 3 for executing offline payment processing by telephone bill combined payment is operating without blockage. Also, offline balance payment blockage information DHY2 may be information indicating whether the function of the payment device 3 for executing offline payment processing by prepaid balance payment is operating without blockage. Also, offline card payment blockage information DHY3 may be information indicating whether the function of the payment device 3 for executing offline payment processing by credit card payment is operating without blockage. In the following, offline combined payment blockage information DHY1, offline balance payment blockage information DHY2, and offline card payment blockage information DHY3 may be collectively referred to as individual offline blockage information DHY0.

[0264] Furthermore, in this modified example, the payment device 3 may, in response to an online blockage information request from the terminal device 1[q], supply to the terminal device 1[q] the individual online blockage information DHX0 from among the three individual online blockage information DHX0 included in the online blockage information DHX that corresponds to the payment method selected by the user U[q] of the terminal device 1[q]. Furthermore, in this modified example, the payment device 3 may, in response to an offline blockage information request from the terminal device 1[q], supply to the terminal device 1[q] the individual offline blockage information DHY0 from the three individual offline blockage information DHY0 included in the offline blockage information DHY that corresponds to the payment method selected by the user U[q] of the terminal device 1[q]. Furthermore, in this modified example, the payment device 3 may, in response to an offline blockage information request from the terminal device 1[q], supply to the terminal device 1[q] the three individual offline blockage information DHY0 included in the offline blockage information DHY.

[0265] Furthermore, in the first and second embodiments and modified examples 1 to 4 described above, the payment device 3 is shown supplying the terminal device 1[q] with an online token KX[q] common to multiple payment methods and an offline token KY[q] common to multiple payment methods, regardless of the payment method selected by the user U[q] of the terminal device 1[q]. However, the present invention is not limited to such embodiments. For example, the payment device 3 may supply the terminal device 1[q] with one or more offline tokens KY[q] that correspond one-to-one with one or more payment methods that the user U[q] of the terminal device 1[q] can select.

[0266] Specifically, in this modified example, in response to an offline token request from terminal device 1[q], payment device 3 supplies terminal device 1[q] with: offline token KY1[q] for combined payment, which is an offline token KY[q] corresponding to combined telephone bill payment; offline token KY2[q] for balance payment, which is an offline token KY[q] corresponding to prepaid balance payment; and offline token KY3[q] for card payment, which is an offline token KY[q] corresponding to credit card payment. In the following, offline token KY1[q] for combined payment, offline token KY2[q] for balance payment, and offline token KY3[q] for card payment may be collectively referred to as individual offline token KY0[q]. That is, in this modified example, in response to an offline token request from terminal device 1[q], payment device 3 supplies terminal device 1[q] with three individual offline tokens KY0[q] that correspond one-to-one with the three payment methods that user U[q] of terminal device 1[q] can select.

[0267] In this modified example, the code generation unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on an individual offline token KY0[q] corresponding to the payment method selected by user U[q] of the terminal device 1[q]. Specifically, in this modified example, the code generation unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on an offline token KY1[q] for combined payment when the payment method selected by user U[q] of the terminal device 1[q] is combined telephone bill payment, generates an offline payment code CY[q] based on an offline token KY2[q] for balance payment when the payment method selected by user U[q] of the terminal device 1[q] is prepaid balance payment, and generates an offline payment code CY[q] based on an offline token KY3[q] for card payment when the payment method selected by user U[q] of the terminal device 1[q] is credit card payment.

[0268] Furthermore, in this modified example, the display control unit 114 of the terminal device 1[q] determines whether or not to display the offline code image GY[q] based on the individual offline token KY0[q] corresponding to the payment method selected by user U[q] of the terminal device 1[q] to the display device 13, based on the individual offline block information DHY0 corresponding to the payment method selected by user U[q] of the terminal device 1[q]. Specifically, in this modified example, if the payment method selected by user U[q] of terminal device 1[q] is telephone bill combined payment, the presence or absence of the offline code image GY[q] based on the combined payment offline token KY1[q] is determined based on the offline combined payment blockage information DHY1. If the payment method selected by user U[q] of terminal device 1[q] is prepaid balance payment, the presence or absence of the offline code image GY[q] based on the balance payment offline token KY2[q] is determined based on the offline balance payment blockage information DHY2. If the payment method selected by user U[q] of terminal device 1[q] is credit card payment, the presence or absence of the offline code image GY[q] based on the card payment offline token KY3[q] is determined based on the offline card payment blockage information DHY3.

[0269] Note that in this modification example, the payment device 3 may supply three online tokens KX[q] corresponding one-to-one to three types of payment methods selectable by the user U[q] of the terminal device 1[q] to the terminal device 1[q]. Further, in this modification example, the payment device 3 may supply one online token KX[q] corresponding to one payment method selected by the user U[q] of the terminal device 1[q] out of the three online tokens KX[q] corresponding one-to-one to three types of payment methods selectable by the user U[q] of the terminal device 1[q] to the terminal device 1[q].

[0270] As described above, according to this modification example, since the display presence or absence of the offline code image GY[q] can be finely controlled according to the blockage status for each payment method selected by the user U[q] of the terminal device 1[q], it is possible to reduce the labor of the user U[q] and improve the convenience of the user U[q] as compared with an aspect that does not consider the payment method.

[0271] <C.6. Modification Example 6> In the above-described first embodiment, second embodiment, and modification examples 1 to 5, the case where the blockage information DH is supplied from the payment device 3 has been illustrated and described, but the present invention is not limited to such an aspect. An aspect in which the blockage information DH is not supplied from the payment device 3 to the terminal device 1[q] may be employed.

[0272] FIG. 31 is a sequence chart showing an example of the operation of the electronic payment system Sys when the electronic payment system Sys according to the modification example 6 performs an online electronic payment.

[0273] As shown in FIG. 31, in the sequence chart of the online electronic payment according to this modification example, in the electronic payment system Sys, it is different from the sequence chart of the online electronic payment according to the first embodiment shown in FIG. 4 in that the processes of steps S21, S22, S31, S32, and S41 related to the exchange of the blockage information DH do not exist.

[0274] According to this modification example, since the process of supplying the online block information DHX from the settlement device 3 to the terminal device 1[q] and the process of supplying the offline block information DHY from the settlement device 3 to the terminal device 1[q] are not performed, compared with the mode of supplying the online block information DHX and the offline block information DHY from the settlement device 3 to the terminal device 1[q], it is possible to shorten the processing time from the start of the settlement application to the display of the online code image GX[q].

[0275] <D. Supplementary Note> Aspects related to the above embodiments and modification examples are appended below. For the sake of easy understanding of each aspect, in the following, descriptions with reference signs of the drawings are appended, but the present invention is not intended to be limited to the illustrated aspects.

[0276] <D.1. Supplementary Note 1> The following describes Supplementary Note 1.

[0277] <Supplementary Note 1-1> The electronic payment program PG-T relating to Appendix 1-1 is an electronic payment program PG-T installed in terminal device 1[q], and during the token response waiting period TW from the start of the electronic payment program PG-T until the token response waiting time TSW has elapsed, the processor of terminal device 1[q] includes an information transmission unit 111 that transmits requests for two types of tokens KK[q], online token KX[q] and offline token KY[q], an information acquisition unit 112 that acquires tokens KK[q] supplied in response to the transmission of requests from the information transmission unit 111, and a display system that displays a code image GG[q] based on tokens KK[q] on the display device 13. The display control unit 114 functions as follows: When the information acquisition unit 112 acquires an offline token KY[q], it stores the offline token KY[q] in the storage device 12; when the information acquisition unit 112 acquires an online token KX[q] during the token response waiting period TW, the display control unit 114 displays a code image GG[q] based on the online token KX[q] on the display device 13; and when the information acquisition unit 112 does not acquire a token KK[q] during the token response waiting period TW, it displays a code image GG[q] based on the offline token KY[q] stored in the storage device 12 on the display device 13. In Note 1, the token response waiting time TSW is an example of "first hour," the token response waiting period TW is an example of "first period," the online token KX[q] is an example of "first token," and the offline token KY[q] is an example of "second token."

[0278] According to Appendix 1-1, at the time of electronic payment, the online token KX[q] and the offline token KY[q] are acquired, and the acquired offline token KY[q] is stored in the storage device 12. Therefore, there is no need to perform a separate process to acquire the offline token KY[q] from the time of electronic payment. Consequently, there is no need to adjust the timing of the process to acquire the offline token KY[q] separately from the time of electronic payment. Furthermore, according to Appendix 1-1, even if the online token KX[q] or offline token KY[q] cannot be obtained during the token response waiting period TW, the code image GG[q] can be displayed based on the offline token KY[q] stored in the storage device 12, thus enabling electronic payment regardless of the communication status.

[0279] Furthermore, in Appendix 1-1, "requests for two types of tokens KK[q]" may mean that the terminal device 1[q] makes two requests, for example, a request for an offline token KY[q] in addition to a request for an online token KX[q]. In this case, the information acquisition unit 112 may acquire the online token KX[q] supplied in response to the request for the online token KX[q] and the offline token KY[q] supplied in response to the request for the offline token KY[q]. Also, in Appendix 1-1, "requests for two types of tokens KK[q]" may mean that the terminal device 1[q] makes a single request, for example, a request for token KK[q] or a payment application activation notification. In this case, the information acquisition unit 112 may acquire the online token KX[q] and the offline token KY[q] supplied in response to the request for token KK[q] or the payment application activation notification.

[0280] <Notes 1-2> The electronic payment program PG-T relating to Appendix 1-2 is an electronic payment program PG-T installed in terminal device 1[q], and includes an information transmission unit 111 that transmits requests for two types of tokens KK[q], online token KX[q] and offline token KY[q], during the token response waiting period TW from the start of the electronic payment program PG-T until the token response waiting time TSW has elapsed, an information acquisition unit 112 that acquires tokens KK[q] supplied in response to the transmission of requests from the information transmission unit 111, and a display device 13 that displays a code image GG[q] based on tokens KK[q]. The display control unit 114 functions as follows: When the information acquisition unit 112 acquires an offline token KY[q], it stores the offline token KY[q] in the storage device 12; when the information acquisition unit 112 acquires an online token KX[q] during the token response waiting period TW, the display control unit 114 displays a code image GG[q] based on the online token KX[q] on the display device 13; and when the communication status of the terminal device 1[q] is offline during the token response waiting period TW, it displays a code image GG[q] based on the offline token KY[q] stored in the storage device 12 on the display device 13.

[0281] According to Appendix 1-2, at the time of electronic payment, the online token KX[q] and the offline token KY[q] are acquired, and the acquired offline token KY[q] is stored in the storage device 12. Therefore, there is no need to perform a separate process to acquire the offline token KY[q] from the time of electronic payment. Consequently, there is no need to adjust the timing of the process to acquire the offline token KY[q] separately from the time of electronic payment. Furthermore, according to Appendix 1-2, even if the communication status is poor during the token response waiting period TW, the code image GG[q] can be displayed based on the offline token KY[q] stored in the storage device 12, thus enabling electronic payment regardless of the communication status.

[0282] <Notes 1-3> The electronic payment program PG-T relating to Appendix 1-3 is the electronic payment program PG-T described in Appendix 1-2, characterized in that, during the token response waiting period TW, if the communication status of the terminal device 1[q] is online and the information acquisition unit 112 did not acquire the token KK[q] during the token response waiting period TW, the display control unit 114 displays a code image GG[q] based on the offline token KY[q] stored in the storage device 12 on the display device 13.

[0283] According to Appendix 1-3, even if the online token KX[q] or offline token KY[q] cannot be obtained during the token response waiting period TW, the code image GG[q] can be displayed based on the offline token KY[q] stored in the storage device 12, thus enabling electronic payment regardless of the communication status.

[0284] <Notes 1-4> The electronic payment program PG-T relating to Appendix 1-4 is the electronic payment program PG-T described in Appendix 1-1 to Appendix 1-3, characterized in that the information acquisition unit 112 acquires an online token KX[q] and an offline token KY[q] from the payment device 3, the online token KX[q] is a token KK[q] used in the payment device 3 to decide whether to perform payment processing corresponding to user U[q] of terminal device 1[q] when terminal device 1[q] is able to communicate with the payment device 3, and the offline token KY[q] is a token KK[q] used in the payment device 3 to decide whether to perform payment processing corresponding to user U[q] of terminal device 1[q] when terminal device 1[q] is unable to communicate with the payment device 3.

[0285] According to Appendix 1-4, since the online token KX[q] and the offline token KY[q] are acquired at the time of electronic payment, there is no need to acquire the offline token KY[q] separately from the time of electronic payment. Therefore, compared to the method in which the offline token KY[q] is acquired separately from the time of electronic payment, the timing adjustment of processing in terminal device 1[q] is simplified. Furthermore, according to Appendix 1-4, since offline tokens KY[q] are acquired in addition to online tokens KX[q] at the time of electronic payment, it is possible to prepare in advance so that offline electronic payment is possible in the event that online electronic payment becomes difficult due to poor communication conditions.

[0286] <Notes 1-5> The electronic payment program PG-T relating to Appendix 1-5 is the electronic payment program PG-T described in Appendix 1-1 to Appendix 1-4, characterized in that the information acquisition unit 112 acquires the online token KX[q] and the offline token KY[q] from the payment device 3, and acquires token response information DSW indicating the token response waiting time TSW from the payment device 3. Note 1 states that the token response information DSW is an example of "time information".

[0287] According to Appendix 1-5, the payment device 3 can adjust the token response waiting time TSW, so that the display mode of the code image GG[q] can be dynamically switched depending on the situation in which the terminal device 1[q] is located.

[0288] <Notes 1-6> The electronic payment program PG-T relating to Appendix 1-6 is the electronic payment program PG-T described in Appendix 1-1 to Appendix 1-5, characterized in that the information transmission unit 111 issues an online token request requesting an online token KX[q] during the token response waiting period TW, and then issues an offline token request requesting an offline token KY[q]. In Note 1, the online token request is an example of a "first token request," and the offline token request is an example of a "second token request."

[0289] According to Appendix 1-6, during the token response waiting period TW, an online token request is issued prior to the offline token request. Therefore, during the token response waiting period TW, the code image GG[q] can be displayed based on the first token KK[q] obtained. This makes it possible to shorten the time until the code image GG[q] is displayed compared to the method in which the code image GG[q] is displayed based on the last token KK[q] obtained during the token response waiting period TW.

[0290] <Notes 1-7> The electronic payment program PG-T relating to Appendix 1-7 is the electronic payment program PG-T described in Appendix 1-1 to Appendix 1-6, characterized in that the information acquisition unit 112 acquires the offline token KY[q] after acquiring the online token KX[q] during the token response waiting period TW.

[0291] According to Appendix 1-7, compared to the method of displaying the code image GG[q] based on the last offline token KY[q] obtained during the token response waiting period TW, it becomes possible to shorten the time until the code image GG[q] is displayed.

[0292] <Notes 1-8> The settlement device 3 according to Supplementary Note 1-8 is a settlement device 3 capable of communicating with the terminal device 1[q], and includes an information reception unit 312 that receives a token request for requesting the issuance of a token KK[q] from the terminal device 1[q], and an information supply unit 311 that supplies two types of tokens KK[q], namely, an online token KX[q] and an offline token KY[q], associated with the user U[q] of the terminal device 1[q] to the terminal device 1[q] when the information reception unit 312 receives the token request. The online token KX[q] is a token KK[q] used in the settlement device 3 to determine the execution of settlement processing corresponding to the user U[q] when the settlement device 3 can communicate with the terminal device 1[q], and the offline token KY[q] is a token KK[q] used in the settlement device 3 to determine the execution of settlement processing corresponding to the user U[q] when the settlement device 3 has difficulty communicating with the terminal device 1[q].

[0293] According to Supplementary Note 1-8, since the offline token KY[q] is acquired at a timing corresponding to the timing when the terminal device 1[q] acquires the online token KX[q], there is no need to adjust the timing of acquiring the offline token KY[q] separately from the timing of acquiring the online token KX[q]. Therefore, according to Supplementary Note 1-8, it becomes easy to adjust the processing schedule in the terminal device 1[q]. Also, according to Supplementary Note 1-8, since the offline token KY[q] is acquired at a timing corresponding to the timing when the terminal device 1[q] acquires the online token KX[q], it is possible to prepare in advance so that offline electronic settlement can be performed even when the communication state in the terminal device 1[q] deteriorates and online electronic settlement becomes difficult.

[0294] <D.2. Supplementary Note 2> Hereinafter, Supplementary Note 2 will be described.

[0295] <Supplementary Note 2-1> The electronic payment program PG-T relating to Appendix 2-1 is characterized in that the processor of a terminal device 1[q] that can communicate with the payment device 3 functions as an information acquisition unit 112 that acquires from the payment device 3 an offline token KY[q] used for offline payment processing executed in the payment device 3 when communication between the payment device 3 and the terminal device 1[q] is difficult, and offline blockage information DHY indicating whether or not offline payment processing can be executed in the payment device 3, and a display control unit 114 that displays an offline code image GY[q] based on the offline token KY[q] on the display device 13 when the offline blockage information DHY indicates that the payment device 3 can execute offline payment processing.

[0296] According to Appendix 2-1, when the offline blocking information DHY indicates that the payment device 3 is capable of performing offline payment processing, the terminal device 1[q] displays the offline code image GY[q]. In other words, according to Appendix 2-1, the display of the offline code image GY[q] in the terminal device 1[q] can be suppressed when the payment device 3 is unable to perform offline payment processing. Therefore, compared to the configuration in which the terminal device 1[q] displays the offline code image GY[q] even when the payment device 3 is unable to perform offline payment processing, the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q] can be reduced.

[0297] Furthermore, the electronic payment program PG-T relating to Appendix 2-1 may be characterized in that the processor of the terminal device 1[q], which can communicate with the payment device 3, is configured to function as an information acquisition unit 112 that acquires from the payment device 3 an offline token KY[q] used for offline payment processing executed in the payment device 3 when communication between the payment device 3 and the terminal device 1[q] is difficult, and offline blocking information DHY indicating whether or not offline payment processing can be executed in the payment device 3, and a display control unit 114 that displays an offline code image GY[q] based on the offline token KY[q] on the display device 13 when it is difficult to execute online payment processing executed in the payment device 3 when communication between the payment device 3 and the terminal device 1[q] is possible, and the offline blocking information DHY indicates that the payment device 3 can execute offline payment processing. Furthermore, the electronic payment program PG-T relating to Appendix 2-1 includes the processor of terminal device 1[q] that can communicate with payment device 3, an online token KX[q] used for online payment processing executed in payment device 3 when payment device 3 and terminal device 1[q] can communicate, an offline token KY[q] used for offline payment processing executed in payment device 3 when payment device 3 and terminal device 1[q] cannot communicate, online blocking information DHX indicating whether online payment processing can be executed in payment device 3, and offline blocking information indicating whether offline payment processing can be executed in payment device 3. The system may also be characterized by comprising: an information acquisition unit 112 that acquires information DHY from the payment device 3; and a display control unit 114 that, when online blocking information DHX indicates that the payment device 3 is capable of performing online payment processing, displays an online code image GX[q] based on the online token KX[q] on the display device 13; and when it is difficult to perform online payment processing and offline blocking information DHY indicates that the payment device 3 is capable of performing offline payment processing, displays an offline code image GY[q] based on the offline token KY[q] on the display device 13.

[0298] <Note 2-2> The electronic payment program PG-T relating to Appendix 2-2 is the electronic payment program PG-T described in Appendix 2-1, characterized in that the information acquisition unit 112 waits until the payment device 3 and the terminal device 1[q] can communicate when the offline blockage information DHY indicates that the payment device 3 is unable to perform offline payment processing, and when the payment device 3 and the terminal device 1[q] can communicate, it acquires the online token KX[q] from the payment device 3, which is used for online payment processing that is executed in the payment device 3 when the payment device 3 and the terminal device 1[q] can communicate, and the display control unit 114 displays the online code image GX[q] based on the online token KX[q] on the display device 13 when the information acquisition unit 112 has acquired the online token KX[q].

[0299] According to Appendix 2-2, if the payment device 3 is unable to perform offline payment processing, the terminal device 1[q] displays an online code image GX[q] corresponding to online payment processing, thereby enabling the execution of a type of electronic payment corresponding to the operating status of the payment device 3.

[0300] <Notes 2-3> The electronic payment program PG-T relating to Appendix 2-3 is the electronic payment program PG-T described in Appendix 2-1 or Appendix 2-2, wherein the payment device 3 is capable of offline payment processing using one or more payment methods, including one payment method; the offline blocking information DHY indicates whether or not offline payment processing can be performed for each of the one or more payment methods in the payment device 3; the information acquisition unit 112 acquires one or more individual offline tokens KY0[q] corresponding to one or more payment methods from the payment device 3; and the display control unit 114 displays an offline code image GY[q] based on one individual offline token KY0[q] used for one payment method from among the one or more individual offline tokens KY0[q] on the display device 13 when the offline blocking information DHY indicates that the payment device 3 is capable of performing offline payment processing using one payment method. Furthermore, in Appendix 2, one payment method is an example of the "first payment method," and individual offline token KY0[q] is an example of an "offline token."

[0301] According to Appendix 2-3, when the offline blocking information DHY indicates that the payment device 3 is capable of performing offline payment processing using one payment method, the terminal device 1[q] displays the offline code image GY[q] corresponding to that payment method. In other words, according to Appendix 2-3, when the payment device 3 is unable to perform offline payment processing using one payment method, the display of the offline code image GY[q] corresponding to that payment method in the terminal device 1[q] can be suppressed. Therefore, even when the payment device 3 is unable to perform offline payment processing using one payment method, the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q] can be reduced compared to the configuration in which the terminal device 1[q] displays the offline code image GY[q] corresponding to that payment method.

[0302] <Note 2-4> The electronic payment program PG-T relating to Appendix 2-4 is the electronic payment program PG-T described in Appendix 2-3, wherein when the payment device 3 performs offline payment processing, the one or more payment methods that the payment device 3 can handle include other payment methods different from one payment method, and the display control unit 114 restricts the display on the display device 13 of the offline code image GY[q] based on one or more individual offline tokens KY0[q] that correspond to the other payment method, when the offline blocking information DHY indicates that the payment device 3 is unable to perform offline payment processing using the other payment method. Note 2 states that other payment methods are examples of "second payment methods," and other individual offline tokens KY0[q] are examples of "second offline tokens."

[0303] According to Appendix 2-4, when the offline blocking information DHY indicates that the payment device 3 is unable to perform offline payment processing using other payment methods, the terminal device 1[q] restricts the display of the offline code image GY[q] corresponding to the other payment method. Therefore, even when the payment device 3 is unable to perform offline payment processing using other payment methods, the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q] is reduced compared to the configuration in which the terminal device 1[q] displays the offline code image GY[q] corresponding to the other payment method.

[0304] <Note 2-5> The electronic payment program PG-T relating to Appendix 2-5 is the electronic payment program PG-T described in Appendix 2-1 to Appendix 2-4, wherein the offline token KY[q] has an offline token validity period TY[q] set, and the display control unit 114 displays the offline code image GY[q] based on the offline token KY[q] on the display device 13 when the offline token validity period TY[q] of the offline token KY[q] is within the limit. Note 2 states that the offline token validity period TY[q] is an example of a "validity period".

[0305] According to Appendix 2-5, terminal device 1[q] displays the offline code image GY[q] based on the offline token KY[q] if it has an offline token KY[q] within its validity period. In other words, terminal device 1[q] can restrict the display of the offline code image GY[q] based on the offline token KY[q] if it does not have an offline token KY[q] within its validity period. Therefore, even when the user does not have an offline token KY[q] within its validity period, the possibility of causing unnecessary trouble to the user U[q] of terminal device 1[q] can be reduced compared to the method of displaying the offline code image GY[q] based on the offline token KY[q].

[0306] <Note 2-6> The electronic payment program PG-T relating to Appendix 2-6 is the electronic payment program PG-T described in Appendix 2-1 to Appendix 2-5, characterized in that the information acquisition unit 112 acquires offline token validity information DSY relating to the offline token validity period TY[q] corresponding to the offline token KY[q], and the display control unit 114 displays the offline code image GY[q] based on the offline token KY[q] on the display device 13 when the elapsed time since the information acquisition unit 112 acquired the offline token KY[q] is less than or equal to the offline token validity period TSY, which is the length of the offline token validity period TY[q]. Note 2 states that Offline Token Validity Information DSY is an example of "Token Validity Information," and Offline Token Validity Time TSY is an example of "Validity Period Length."

[0307] According to Appendix 2-6, even when the user does not have an offline token KY[q] within its validity period, the possibility of causing unnecessary trouble to the user U[q] of terminal device 1[q] can be reduced compared to the method of displaying the offline code image GY[q] based on the offline token KY[q].

[0308] <Note 2-7> The electronic payment program PG-T relating to Appendix 2-7 is characterized in that the processor of a terminal device 1[q] that can communicate with the payment device 3 functions as an information acquisition unit 112 that acquires from the payment device 3 a token KK[q] used for payment processing executed in the payment device 3 when communication between the payment device 3 and the terminal device 1[q] is difficult, and blocking information DH indicating whether or not payment processing can be executed in the payment device 3, and a display control unit 114 that displays a code image GG[q] based on the token KK[q] on the display device 13 when the blocking information DH indicates that the payment device 3 can execute payment processing.

[0309] According to Appendix 2-7, terminal device 1[q] displays code image GG[q] when the blocking information DH indicates that payment device 3 is able to perform payment processing. In other words, according to Appendix 2-7, the display of code image GG[q] in terminal device 1[q] can be suppressed when payment device 3 is unable to perform payment processing. Therefore, compared to the configuration in which terminal device 1[q] displays code image GG[q] even when payment device 3 is unable to perform payment processing, the possibility of causing unnecessary trouble to user U[q] of terminal device 1[q] can be reduced.

[0310] <Note 2-8> The payment device 3 relating to Appendix 2-8 is a payment device 3 that can communicate with terminal device 1[q] and comprises a payment processing unit 313 that performs offline payment processing when communication between terminal device 1[q] and payment device 3 is difficult, an information supply unit 311 that supplies offline blocking information DHY indicating whether or not offline payment processing can be performed in the payment processing unit 313, and an offline token KY[q] used for offline payment processing to terminal device 1[q], and is characterized in that terminal device 1[q] can display an offline code image GY[q] based on the offline token KY[q] when the offline blocking information DHY indicates that payment device 3 can perform offline payment processing.

[0311] According to Appendix 2-8, the payment device 3 supplies offline blocking information DHY to the terminal device 1[q] indicating whether or not offline payment processing can be performed in the payment device 3. Therefore, if the payment device 3 is unable to perform offline payment processing, the display of the offline code image GY[q] in the terminal device 1[q] can be suppressed. For this reason, compared to the configuration in which the terminal device 1[q] displays the offline code image GY[q] even when the payment device 3 is unable to perform offline payment processing, the possibility of causing unnecessary trouble for the user U[q] of the terminal device 1[q] can be reduced.

[0312] <Note 2-9> The settlement device 3 according to Supplementary Note 2-9 is the settlement device 3 described in Supplementary Note 2-8. The settlement processing unit 313 is capable of performing offline settlement processing using a plurality of payment methods. The information supply unit 311 supplies a plurality of individual offline tokens KY0[q] corresponding to the plurality of payment methods to the terminal device 1[q]. The offline block information DHY indicates whether offline settlement processing by each of the plurality of payment methods can be executed, which is a feature.

[0313] According to Supplementary Note 2-9, when it is difficult for the settlement device 3 to execute offline settlement processing using one payment method, the display of the offline code image GY[q] corresponding to the one payment method on the terminal device 1[q] can be suppressed. Therefore, even when it is difficult for the settlement device 3 to execute offline settlement processing using one payment method, compared with the mode in which the terminal device 1[q] displays the offline code image GY[q] corresponding to the one payment method, the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q] can be reduced.

[0314] <Supplementary Note 2-10> The settlement device 3 according to Supplementary Note 2-10 is the settlement device 3 described in Supplementary Note 2-8 or Supplementary Note 2-9. The information supply unit 311 supplies offline token validity information DSY regarding the offline token validity period TY[q], which is the validity period of the offline token KY[q], to the terminal device 1[q], which is a feature.

[0315] According to Supplementary Note 2-10, the settlement device 3 can adjust the validity period of the offline token KY[q].

[0316] <D.3. Supplementary Note 3> Hereinafter, Supplementary Note 3 will be described.

[0317] <Supplementary Note 3-1> The electronic payment program PG-T relating to Appendix 3-1 is characterized in that the processor of a terminal device 1[q] that can communicate with the payment device 3 functions as an information acquisition unit 112 that acquires an offline token KY[q] associated with the user U[q] of the terminal device 1[q] and an encryption key KS[q] from the payment device 3, and a display control unit 114 that displays an offline code image GY[q] on the display device 13, based on the offline token KY[q], a business identification token KZ that identifies the payment business operator related to the payment device 3, and a time encryption code TT[q] obtained by encrypting the terminal time value AG, which is the current time of the terminal device 1[q], with the encryption key KS[q]. In Note 3, the offline token KY[q] is an example of the "first token," the business identification token KZ is an example of the "second token," the terminal time TG is an example of the "current time of the terminal," the terminal time value AG is an example of the "value based on the current time of the terminal," the time encryption code TT[q] is an example of the "encryption code," and the offline code image GY[q] is an example of the "first code image."

[0318] According to Appendix 3-1, since the time-cryptographic code TT[q] is determined based on the terminal time TG, it can be made shorter than the update cycle of the offline token KY[q]. Therefore, according to Appendix 3-1, the security of electronic payments using the offline code image GY[q] can be enhanced compared to a configuration in which the offline code image GY[q] is generated based solely on the offline token KY[q]. Furthermore, in Appendix 3-1, since the offline code image GY[q] is displayed based on the business identification token KZ in addition to the offline token KY[q], the security of electronic payments using the offline code image GY[q] can be enhanced compared to the method of displaying the offline code image GY[q] based only on the offline token KY[q].

[0319] <Note 3-2> The electronic payment program PG-T relating to Appendix 3-2 is the electronic payment program PG-T described in Appendix 3-1, characterized in that the terminal time value AG is updated every update unit time TC, and the update unit time TC is shorter than the offline token validity period TY[q], which is the validity period of the offline token KY[q]. Note 3 states that the update unit time TC is an example of a "unit time".

[0320] According to Appendix 3-2, the offline code image GY[q] is displayed using the time-cryptographic code TT[q], which is updated at a shorter interval than the expiration date of the offline token KY[q]. Therefore, according to Appendix 3-2, even when the offline code image GY[q] is displayed based on the offline token KY[q], the offline code image GY[q] can be updated every update unit time TC, thereby enhancing the security of electronic payments using the offline code image GY[q].

[0321] <Note 3-3> The electronic payment program PG-T relating to Appendix 3-3 is the electronic payment program PG-T described in Appendix 3-2, characterized in that the time encryption code TT[q] is updated when at least (at the latest) update unit time TC has elapsed since the offline code image GY[q] was displayed on the display device 13, and the display control unit 114 updates the offline code image GY[q] displayed on the display device 13 based on the updated time encryption code TT[q], the offline token KY[q], and the business operator identification token KZ when at least (at the latest) the update unit time TC has elapsed since the offline code image GY[q] was displayed on the display device 13.

[0322] According to Appendix 3-2, since the offline code image GY[q] can be updated every update unit time TC, the security of electronic payments using the offline code image GY[q] can be enhanced.

[0323] <Note 3-4> The electronic payment program PG-T relating to Appendix 3-4 is the electronic payment program PG-T described in Appendix 3-2 or Appendix 3-3, characterized in that the information acquisition unit 112 acquires update time information DSC indicating the update unit time TC from the payment device 3. Note 3 states that the update time information DSC is an example of "time information".

[0324] According to Appendix 3-4, the update cycle of the offline code image GY[q] can be adjusted by the payment device 3, thus enabling flexible operation regarding the security of electronic payments.

[0325] <Notes 3-5> The electronic payment program PG-T relating to Appendix 3-5 is the electronic payment program PG-T described in Appendix 3-1 to Appendix 3-4, characterized in that the information acquisition unit 112 acquires the online token KX[q] associated with the user U[q] of the terminal device 1[q] from the payment device 3, and the display control unit 114 displays the offline code image GY[q] on the display device 13 when communication between the terminal device 1[q] and the payment device 3 is difficult, and displays the online code image GX[q] based on the online token KX[q] and the business operator identification token KZ on the display device 13 when communication between the terminal device 1[q] and the payment device 3 is possible. In Note 3, the online token KX[q] is an example of a "third token," and the online code image GX[q] is an example of a "second code image."

[0326] According to Appendix 3-5, the offline code image GY[q] displayed during offline electronic payment is a different image from the online code image GX[q] displayed during online electronic payment. Therefore, in this embodiment, flexible operation is possible that takes into account the characteristics of both offline and online electronic payments from the standpoint of electronic payment security.

[0327] <Note 3-6> The electronic payment program PG-T relating to Appendix 3-6 is the electronic payment program PG-T described in Appendix 3-5, characterized in that the number of digits LX of the online token KX[q] is equal to the sum of the number of digits LY of the offline token KY[q] and the number of digits LZ of the business identification token KZ.

[0328] According to Appendix 3-6, by making the number of digits in the token contained in the offline code image GY[q] displayed during offline electronic payment the same as the number of digits in the token contained in the online code image GX[q] displayed during online electronic payment, the processing in terminal device 1[q] can be simplified compared to the configuration in which the number of digits in the two are different.

[0329] <Note 3-7> The electronic payment program PG-T relating to Appendix 3-7 is the electronic payment program PG-T described in Appendix 3-6, characterized in that the display control unit 114 displays an offline code image GY[q] based on an offline payment code CY[q] including an offline token KY[q], a business identification token KZ, and a time encryption code TT[q] on the display device 13 when communication between the terminal device 1[q] and the payment device 3 is difficult, and displays an online code image GX[q] based on an online payment code CX[q] including an online token KX[q] and a business identification token KZ on the display device 13 when communication between the terminal device 1[q] and the payment device 3 is possible, and the number of digits of the offline payment code CY[q] and the number of digits of the online payment code CX[q] are the same. In Note 3, offline payment code CY[q] is an example of a "first payment code," and online payment code CX[q] is an example of a "second payment code."

[0330] According to Appendix 3-7, in order to make the number of digits of the offline payment code CY[q] indicated by the offline code image GY[q] displayed during offline electronic payment the same as the number of digits of the online payment code CX[q] indicated by the online code image GX[q] displayed during online electronic payment, the processing at the store device 5 that reads the code image GG[q] (online code image GX[q] or offline code image GY[q]) can be simplified compared to the configuration in which the number of digits of the two differs. Furthermore, the processing at the payment device 3 that executes the electronic payment processing based on the payment code CC[q] (online payment code CX[q] or offline payment code CY[q]) can be simplified.

[0331] <Note 3-8> The terminal device 1[q] relating to Appendix 3-8 is a terminal device 1[q] that can communicate with a payment device 3, and is characterized by comprising: an information acquisition unit 112 that acquires an offline token KY[q] associated with the user U[q] of the terminal device 1[q] and an encryption key KS[q] from the payment device 3; and a display control unit 114 that displays an offline code image GY[q] on a display device 13, which is based on the offline token KY[q], a business identification token KZ that identifies a payment business operator related to the payment device 3, and a time encryption code TT[q] obtained by encrypting a terminal time value AG based on the terminal time TG, which is the current time of the terminal device 1[q], with the encryption key KS[q].

[0332] According to Appendix 3-8, since the time-cryptographic code TT[q] is determined based on the terminal time TG, it can be made shorter than the update cycle of the offline token KY[q]. Therefore, compared to the configuration in which the offline code image GY[q] is generated based solely on the offline token KY[q], the security of electronic payments using the offline code image GY[q] can be enhanced.

[0333] <Note 3-9> The payment device 3 relating to Appendix 3-9 is a payment device 3 that can communicate with terminal device 1[q], and includes an information supply unit 311 that supplies to terminal device 1[q] an offline token KY[q] associated with user U[q] of terminal device 1[q] and an encryption key KS[q] associated with the offline token KY[q] from among a plurality of encryption keys KS, and an information supply unit 311 that supplies to terminal device 1[q] an offline token KY[q] associated with the offline token KY[q] of terminal device 1[q], and an information supply unit 311 that reads an offline code image GY[q] displayed on terminal device 1[q], which is based on an offline token KY[q], a business identification token KZ that identifies a payment business operator related to payment device 3, and a time encryption code TT[q] obtained by encrypting the terminal time value AG of terminal device 1[q], which is updated every update unit time TC, using the encryption key KS[q], and receives a single payment information DP[q] including the offline token KY[q] and the time encryption code TT[q] from a store device 5 that reads the offline code image GY[q] displayed on terminal device 1[q], which includes an offline token KY[q], a business identification token KZ that identifies a payment business operator related to payment device 3, and a time encryption code TT[q] obtained by encrypting the terminal time value AG of terminal device 1[q], which is updated every update unit time TC, using the encryption key KS[q], and receives payment information DP[q] including the offline token KY[q] and the time encryption code TT[q] from a store device 5 that reads the offline code image GY[q] which is based on an offline token KY[q], a business identification token KZ that identifies a payment business operator related to payment device 3, and an information supply unit 311 that supplies to terminal device 1[q] an offline token KY[q] associated with user U[q] The system is characterized by comprising: a notification receiving unit 312; and a settlement processing unit 313 that, when any of three time encryption codes CMM are matched with the time encryption code TT[q] indicated by a settlement information DP[q], executes a settlement process corresponding to user U[q] of terminal device 1[q], using an encryption key KS[q] identified from among multiple encryption keys KS based on an offline token KY[q] contained in a settlement information DP[q], to encrypt a server time encryption code CM obtained by encrypting a server time value AM based on a server time TM managed by settlement device 3 using an encryption key KS[q]; a future time encryption code CMf obtained by encrypting a future time value AMf based on a time update unit time TC later than the server time TM using an encryption key KS[q]; and a past time encryption code CMp obtained by encrypting a past time value AMp based on a time update unit time TC earlier than the server time TM using an encryption key KS[q], the system executes a settlement process corresponding to user U[q] of terminal device 1[q]. In addition, in Appendix 3, the server time encryption code CM is an example of the "first time code," the future time encryption code CMf is an example of the "second time code," the past time encryption code CMp is an example of the "third time code," and the time encryption code CMM is an example of the "time code."

[0334] According to Appendix 3-9, since the time-cryptographic code TT[q] is determined based on the terminal time TG, it can be made shorter than the update cycle of the offline token KY[q]. Therefore, compared to the configuration in which the offline code image GY[q] is generated based solely on the offline token KY[q], the security of electronic payments using the offline code image GY[q] can be enhanced.

[0335] <Note 3-10> The settlement device 3 relating to Appendix 3-10 is the settlement device 3 described in Appendix 3-9, characterized in that the settlement processing unit 313 does not execute settlement processing based on the other settlement information DP[q] if it receives another settlement information DP[q] including an offline token KY[q] and a time encryption code TT[q] during the same token prohibition period from when the information receiving unit 312 receives one settlement information DP[q] until twice the update unit time TC has elapsed.

[0336] According to Appendix 3-10, by restricting the execution of payment processing based on other payment information DP[q], the possibility of fraudulent electronic payments can be reduced compared to a configuration without such restrictions.

[0337] <Note 3-11> The settlement device 3 according to Supplementary Note 3-11 is a settlement device capable of communicating with the terminal device 1[q], and includes an information supply unit 311 that supplies the offline token KY[q] associated with the user U[q] of the terminal device 1[q] and the encryption key KS[q] to the terminal device 1[q]; an offline code image GY[q] displayed on the terminal device 1[q], which is based on the offline token KY[q], the merchant identification token KZ that identifies the settlement merchant related to the settlement device 3, and the time encryption code TT[q] obtained by encrypting the terminal time value AG of the terminal device 1[q] updated every update unit time TC using the encryption key KS[q]. The information reception unit 312 receives the single settlement information DP[q] including the offline token KY[q] and the time encryption code TT[q] from the store device 5 that has read the offline code image GY[q]. The settlement processing unit 313 executes the settlement processing corresponding to the user U[q] of the terminal device 1[q] based on the single settlement information DP[q]. The settlement processing unit 313 does not execute the settlement processing based on the other settlement information DP[q] when the other settlement information DP[q] including the offline token KY[q] and the time encryption code TT[q] is received during the same token prohibition period from the time when the information reception unit 312 receives the single settlement information DP[q] until the time twice the update unit time TC has elapsed. This is the feature.

[0338] According to Supplementary Note 3-11, in order to limit the execution of the settlement processing based on the other settlement information DP[q], it is possible to reduce the possibility of unauthorized electronic settlement compared with the non-limiting mode.

[0339] <D.4. Supplementary Note 4> Hereinafter, Supplementary Note 4 will be described.

[0340] <Supplementary Note 4-1> The electronic payment program PG-T relating to Appendix 4-1 is characterized in that the processor of the terminal device 1[q] functions as an information acquisition unit 112 that acquires a token KK[q] (online token KX[q] or offline token KY[q]) associated with the user U[q] of the terminal device 1[q] and a business operator identification token KZ from the payment device 3 at different timings, and a display control unit 114 that displays a code image GG[q] (online code image GX[q] or offline code image GY[q]) based on the token KK[q] and the business operator identification token KZ on the display device 13. In Note 4, token KK[q] is an example of a "first token," business identification token KZ is an example of a "second token," and offline code image GY[q] is an example of a "code image."

[0341] According to Appendix 4-1, the code image GG[q] is displayed based on the business identification token KZ, which is acquired at a different time than the token KK[q], in addition to the token KK[q]. Therefore, according to Appendix 4-1, the security of electronic payments using the code image GG[q] can be enhanced compared to a configuration in which the code image GG[q] is generated based solely on the token KK[q].

[0342] <Note 4-2> The electronic payment program PG-T relating to Appendix 4-2 is the electronic payment program PG-T described in Appendix 4-1, characterized in that the frequency at which the information acquisition unit 112 acquires token KK[q] from the payment device 3 is higher than the frequency at which the information acquisition unit 112 acquires business operator identification token KZ from the payment device 3.

[0343] According to Appendix 4-2, compared to acquiring token KK[q] and business identification token KZ at the same frequency, this method enhances the security of electronic payments.

[0344] <Note 4-3> The electronic payment program PG-T relating to Appendix 4-3 is the electronic payment program PG-T described in Appendix 4-1 or Appendix 4-2, characterized in that the display control unit 114 displays on the display device 13 a code image GG[q] based on the latest token KK[q] among the multiple tokens KK[q] acquired by the information acquisition unit 112 and the latest business identification token KZ among the multiple business identification tokens KZ acquired by the information acquisition unit 112, when the information acquisition unit 112 acquires tokens KK[q] at multiple different timings and business identification tokens KZ from the payment device 3 at multiple different timings.

[0345] According to Appendix 4-3, even if either or both of the token KK[q] and the business identification token KZ are leaked from terminal device 1[q], the code image GG[q] will be displayed using the most recently acquired token KK[q] and the most recently acquired business identification token KZ. Therefore, according to Appendix 4-3, the security of electronic payments can be enhanced compared to a configuration in which the token KK[q] and business identification token KZ are not updated.

[0346] <Note 4-4> The electronic payment program PG-T relating to Appendix 4-4 is the electronic payment program PG-T described in Appendix 4-1 to Appendix 4-3, characterized in that the business operator identification token KZ includes business operator identification information DKZ that identifies the payment business operator managing the payment device 3.

[0347] According to Appendix 4-4, even if the business identification information DKZ that identifies the payment business operator changes, electronic payment using terminal device 1[q] becomes possible simply by supplying the business identification token KZ from payment device 3 to terminal device 1[q], without modifying the electronic payment program PG-T.

[0348] <Notes 4-5> The electronic payment program PG-T according to Supplementary Note 4-5 is the electronic payment program PG-T described in Supplementary Note 4-4. After the electronic payment program PG-T is installed in the terminal device 1[q], when the electronic payment program PG-T is first started, the information acquisition unit 112 acquires the merchant identification token KZ from the payment device 3. When the information acquisition unit 112 acquires the merchant identification token KZ from the payment device 3 at a plurality of different timings, the display control unit 114 causes the display device 13 to display the code image GG[q] based on the latest merchant identification token KZ among the plurality of merchant identification tokens KZ acquired by the information acquisition unit 112. This is the gist of the invention.

[0349] According to Supplementary Note 4-5, even when the merchant identification information DKZ for identifying the payment merchant is changed, it is possible to perform electronic payment using the terminal device 1[q] only by supplying the merchant identification token KZ from the payment device 3 to the terminal device 1[q] without modifying the electronic payment program PG-T.

[0350] <Supplementary Note 4-6> The electronic payment program PG-T according to Supplementary Note 4-6 is the electronic payment program PG-T described in Supplementary Notes 4-1 to 4-5. When communication between the terminal device 1[q] and the payment device 3 is difficult, the display control unit 114 causes the display device 13 to display the code image GG[q] (offline code image GY[q]). This is the gist of the invention.

[0351] <E. Others> (1) In the embodiments described above (including modified examples; the same applies hereinafter), the storage device 12 and storage device 32 are exemplified by ROM and RAM, but can also be flexible disks, magneto-optical disks (e.g., compact disks, digital multipurpose disks, Blu-ray® disks), smart cards, flash memory devices (e.g., cards, sticks, key drives), CD-ROMs (Compact Disc-ROMs), registers, removable disks, hard disks, floppy® disks, magnetic strips, databases, servers, and other suitable storage media. The program may also be transmitted from a network via a telecommunications line. The program may also be transmitted from a communication network NET via a telecommunications line.

[0352] (2) In the embodiments described above, the information, signals, etc. may be represented using any of the various different techniques. For example, the data, instructions, commands, information, signals, bits, symbols, chips, etc. that may be mentioned throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0353] (3) In the embodiments described above, the input and output information may be stored in a specific location (e.g., memory) or managed using a management table. The input and output information may be overwritten, updated, or appended to. The output information may be deleted. The input information may be transmitted to other devices.

[0354] (4) In the embodiments described above, the determination may be made by a value represented using 1 bit (0 or 1), by a boolean value (true or false), or by a numerical comparison (for example, a comparison with a predetermined value).

[0355] (5) The processing procedures, sequences, flowcharts, etc., exemplified in the embodiments described above may be rearranged in order, as long as they do not contradict each other. For example, the methods described in this disclosure present various step elements using an exemplary order and are not limited to the specific order presented.

[0356] (6) Each function illustrated in Figures 2 and 3 is implemented by any combination of at least one of hardware and software. Furthermore, the method of implementing each function block is not particularly limited. That is, each function block may be implemented using one device that is physically or logically coupled, or it may be implemented using two or more physically or logically separated devices that are directly or indirectly connected (for example, using wired or wireless connections). A function block may also be implemented by combining the one or more devices with software.

[0357] (7) The programs illustrated in the embodiments described above should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., whether they are called software, firmware, middleware, microcode, hardware description languages ​​or by other names.

[0358] Furthermore, software, instructions, information, etc., may be transmitted and received via a transmission medium. For example, if software is transmitted from a website, server, or other remote source using at least one of wired technology (such as coaxial cable, fiber optic cable, twisted pair, or digital subscriber line (DSL)) and wireless technology (such as infrared or microwave), then at least one of these wired and wireless technologies is included in the definition of a transmission medium.

[0359] (8) In each of the above-mentioned forms, the terms “system” and “network” shall be used interchangeably.

[0360] (9) The information, parameters, etc. described in this disclosure may be expressed using absolute values, relative values ​​from a given value, or other corresponding information.

[0361] (10) In the embodiments described above, the terminal device 1[q] may be a mobile station (MS). A mobile station may also be referred to by those skilled in the art as a subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, client, or several other appropriate terms. In this disclosure, terms such as “mobile station,” “user terminal,” “user equipment (UE),” and “terminal” may be used interchangeably.

[0362] (11) In the embodiments described above, the terms “connected,” “coupled,” or any variation thereof, mean any direct or indirect connection or coupling between two or more elements, and may include the presence of one or more intermediate elements between two elements that are “connected” or “coupled” with each other. The coupling or connection between elements may be a physical coupling or connection, a logical coupling or connection, or a combination thereof. For example, “connection” may be reinterpreted as “access.” As used in this disclosure, two elements may be considered to be “connected” or “coupled” with each other using at least one of one or more wires, cables and printed electrical connections, and, in some non-limiting and non-exclusive examples, electromagnetic energy having wavelengths in the radio frequency domain, microwave domain and optical (both visible and invisible) domain.

[0363] (12) In the embodiments described above, the phrase “based on” does not mean “based solely on” unless otherwise specified. In other words, the phrase “based on” means both “based solely on” and “based at least on.”

[0364] (13) The terms “determining” and “determining” as used in this disclosure may encompass a wide variety of actions. “Determining” may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, searching, inquiry (e.g., searching in a table, database or other data structure), and ascertaining. “Determining” may also include, for example, receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, and accessing (e.g., accessing data in memory). Furthermore, "judgment" and "decision" can include considering something as having been "judged" or "decided" after resolving, selecting, choosing, establishing, comparing, etc. In other words, "judgment" and "decision" can include considering something as having been "judged" or "decided" after some action. Also, "judgment (decision)" can be reinterpreted as "assuming," "expecting," or "considering."

[0365] (14) Where the terms “include,” “including,” and variations thereof are used in the embodiments described above, these terms are intended to be inclusive, as is the term “comprising.” Furthermore, the term “or” as used in this disclosure is not intended to be exclusive OR.

[0366] (15) In the present disclosure, if articles are added by translation, such as a, an, and the in English, the present disclosure may include the fact that the noun following these articles is plural.

[0367] (16) In this disclosure, the term “A and B are different” may mean “A and B are different from each other.” The term may also mean “A and B are each different from C.” Terms such as “separate” and “combine” may be interpreted in the same way as “different.”

[0368] (17) Each aspect / embodiment described herein may be used individually, in combination, or switched between as needed in practice. Furthermore, notification of certain information (e.g., notification that "X is") is not limited to explicit notification, but may also be implicit (e.g., by not providing such notification).

[0369] Although the present disclosure has been described in detail above, it will be clear to those skilled in the art that the present disclosure is not limited to the embodiments described herein. The present disclosure can be implemented in modified and altered forms without departing from the intent and scope of the present disclosure as defined by the claims. Accordingly, the descriptions in the present disclosure are illustrative and not restrictive in any way. [Explanation of Symbols]

[0370] 1[q]...Terminal device, 3...Payment device, 5...Store device, 11...Control device, 12...Storage device, 13...Display device, 14...Input device, 15...Communication device, 31...Control device, 32...Storage device, 35...Communication device, 111...Information transmission unit, 112...Information acquisition unit, 113...Code generation unit, 114...Display control unit, 311...Information supply unit, 312...Information reception unit, 313...Payment processing unit.

Claims

1. The processor of the terminal that can communicate with the payment device, An acquisition unit that obtains a first token associated with the user of the terminal and an encryption key from the payment device, A display control unit that causes a display device to display a first code image based on the first token, a second token that identifies a payment business operator relating to the payment device, and an encrypted code obtained by encrypting a value based on the current time of the terminal using the encryption key, to make it work An electronic payment program characterized by the following features.

2. The value based on the current time of the aforementioned terminal is updated every unit of time. The aforementioned unit time is shorter than the validity period of the first token. The electronic payment program according to claim 1, characterized in that...

3. The encryption code is updated when at least the unit time has elapsed since the first code image was displayed on the display device. The display control unit updates the first code image displayed on the display device based on the updated cryptographic code, the first token, and the second token, when at least the unit time has elapsed since the first code image was displayed on the display device. The electronic payment program according to claim 2, characterized in that

4. The acquisition unit acquires time information indicating the unit time from the payment device. The electronic payment program according to claim 2, characterized in that

5. The acquisition unit is, A third token associated with the user of the terminal is obtained from the payment device. The display control unit, When communication between the terminal and the payment device is difficult, the first code image is displayed on the display device. When the terminal and the payment device can communicate, the display device will display a second code image based on the second token and the third token. The electronic payment program according to claim 1, characterized in that...

6. The number of digits in the aforementioned third token is The number of digits matches the sum of the number of digits in the first token and the number of digits in the cryptographic code. The electronic payment program according to claim 5, characterized in that...

7. The display control unit, When communication between the terminal and the payment device is difficult, A first code image based on a first payment code, including the first token, the second token, and the cryptographic code, is displayed on the display device. When the terminal and the payment device can communicate, The display device is used to display a second code image based on a second payment code, which includes the second token and the third token. The number of digits in the first payment code is the same as the number of digits in the second payment code. The electronic payment program according to claim 6, characterized in that

8. A terminal capable of communicating with a payment device, An acquisition unit that obtains a first token associated with the user of the terminal and an encryption key from the payment device, A display control unit that causes a display device to display a first code image based on the first token, a second token that identifies a payment business operator relating to the payment device, and an encrypted code obtained by encrypting a value based on the current time of the terminal using the encryption key, Equipped with, A terminal characterized by the following features.

9. A payment device capable of communicating with a terminal, A supply unit that supplies to the terminal a first token associated with the user of the terminal and one encryption key from among a plurality of encryption keys associated with the first token, A receiving unit receives first payment information, including the first token and the encrypted code, from a store device that has read a first code image displayed on the terminal, which is based on the first token, a second token that identifies a payment business operator relating to the payment device, and an encrypted code obtained by encrypting a value based on the current time of the terminal, which is updated every unit of time, using the first encryption key. A settlement unit that executes a settlement process corresponding to the user of the terminal when any of three time codes—a first time code obtained by encrypting a value based on the current time of the settlement device using one encryption key identified from among the plurality of encryption keys based on the first token contained in the first settlement information; a second time code obtained by encrypting a value based on a time unit in the future of the current time of the settlement device using one encryption key; and a third time code obtained by encrypting a value based on a time unit in the past of the current time of the settlement device using one encryption key—matches the encryption code indicated in the first settlement information. Equipped with, A payment device characterized by the following features.

10. The aforementioned settlement unit, If the receiving unit receives second payment information, including the first token and the cryptographic code, during the period from the time it receives the first payment information until twice the unit time has elapsed, it will not perform payment processing based on the second payment information. The payment device according to claim 9, characterized in that it is a payment device.

Images