Payment device, electronic payment program, and electronic payment system

Abstract

Reduces processing separate from electronic payments. [Solution] The terminal device 1[q] includes an information transmitting unit 111 that transmits a request for two types of tokens KK[q], i.e., an online token KX[q] and an offline token KY[q], during a token response waiting period TW; an information acquiring unit 112 that acquires the token KK[q] supplied in response to the request from the information transmitting unit 111; and a display control unit 114 that displays a code image GG[q] based on the token KK[q]. When the information acquiring unit 112 acquires the offline token KY[q], it stores the offline token KY[q] in a storage device 12. When the information acquiring unit 112 acquires an online token KX[q] during the token response waiting period TW, the display control unit 114 displays the code image GG[q] based on the online token KX[q]. When the information acquiring unit 112 does not acquire a token KK[q] during the token response waiting period TW, it displays the code image GG[q] based on the offline token KY[q] stored in the storage device 12.

Description

[Technical field]

[0001] The present invention relates to a payment device, an electronic payment program, and an electronic payment system. [Background technology]

[0002] A technology relating to electronic payment is becoming widespread, in which a terminal device (an example of a "terminal") such as a smartphone displays a code image based on a token supplied from a payment device, and the displayed code image is read by a store terminal such as a POS terminal installed in a store, etc. For example, Patent Document 1 discloses two types of technology relating to electronic payment: online electronic payment, which is executed by displaying an online code image on the terminal device based on an online token supplied from the payment device at the timing of payment when the terminal device and the payment device can communicate with each other, and offline electronic payment, which is executed by displaying an offline code image on the terminal device based on an offline token supplied from the payment device and stored in the terminal device about once a week when it is difficult for the terminal device and the payment device to communicate with each other. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7391263 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in the conventional technology, the terminal device acquires the offline token from the payment device at a timing unrelated to the timing of electronic payment. In other words, in the conventional technology, the terminal device needs to execute a process to acquire the offline token separately from the electronic payment. Therefore, in the conventional technology, for example, it is necessary to adjust the execution timing of the process to acquire the offline token separately from the electronic payment, which may make the schedule adjustment of the process in the terminal device complicated.

[0005] The present invention has been made in consideration of the above-mentioned circumstances, and one of the problems to be solved is to provide a technology that eliminates the need to adjust the timing of the process of obtaining an offline token separately from electronic payment. [Means for solving the problem]

[0006] In order to solve the above problems, the electronic payment program of the present invention is an electronic payment program installed in a terminal, which causes a processor of the terminal to function as a request unit that requests two types of tokens, a first token and a second token, during a first period from the start of the electronic payment program until a first time has elapsed, an acquisition unit that acquires tokens supplied in response to a request from the request unit, and a display control unit that displays a code image based on the tokens on a display device, wherein the acquisition unit stores the second token in a storage device if it acquires the second token, and the display control unit displays a code image based on the first token on the display device if the acquisition unit acquires the first token during the first period, and displays the code image based on the second token stored in the storage device on the display device if the acquisition unit does not acquire the token during the first period.

[0007] Furthermore, the electronic payment program of the present invention is an electronic payment program installed in a terminal, which causes a processor of the terminal to function as a request unit that requests two types of tokens, a first token and a second token, during a first period from the start of the electronic payment program until a first time has elapsed, an acquisition unit that acquires tokens supplied in response to a request from the request unit, and a display control unit that displays a code image based on the tokens on a display device, wherein the acquisition unit, when acquiring the second token, stores the second token in a storage device, and the display control unit, when acquiring the first token by the acquisition unit during the first period, displays a code image based on the first token on the display device, and when the communication status of the terminal is offline during the first period, displays the code image based on the second token stored in the storage device on the display device.

[0008] In addition, a payment device according to the present invention is a payment device capable of communicating with a terminal, and includes a reception unit that receives a token request from the terminal to request issuance of a token, and a supply unit that, when the reception unit receives the token request, supplies the terminal with two types of tokens, a first token and a second token associated with a user of the terminal, wherein the first token is an online token used in the payment device to determine whether to execute a payment process corresponding to the user when the payment device is capable of communicating with the terminal, and the second token is an offline token used in the payment device to determine whether to execute a payment process corresponding to the user when the payment device is unable to communicate with the terminal.

[0009] Moreover, the electronic payment system according to the present invention is an electronic payment system comprising a terminal having an electronic payment program installed and a payment device, wherein the terminal comprises a request unit that requests two types of tokens, a first token and a second token, from the payment device during a first period from the start of the electronic payment program until a first time has elapsed, an acquisition unit that acquires tokens supplied from the payment device in response to a request from the request unit, and a display control unit that causes a code image based on the tokens to be displayed on a display device, wherein the acquisition unit, when acquiring the second token, stores the second token in a storage device, and the display control unit, when acquiring the first token by the acquisition unit during the first period, displays a code image based on the first token on the display device, and when the acquisition unit does not acquire the token during the first period, displays a code image based on the second token stored in the storage device on the display device.

[0010] Moreover, the electronic payment system according to the present invention is an electronic payment system comprising a terminal having an electronic payment program installed and a payment device, wherein the terminal comprises a request unit that requests two types of tokens, a first token and a second token, from the payment device during a first period from the start of the electronic payment program until a first time has elapsed, an acquisition unit that acquires tokens supplied from the payment device in response to a request from the request unit, and a display control unit that displays a code image based on the tokens on a display device, wherein when the acquisition unit acquires the second token, it stores the second token in a storage device, and when the acquisition unit acquires the first token during the first period, it displays a code image based on the first token on the display device, and when the communication status of the terminal is offline during the first period, it displays the code image based on the second token stored in the storage device on the display device. Effect of the Invention

[0011] According to the present invention, it becomes easier to adjust the schedule of processing in a terminal device compared to the conventional techniques. [Brief description of the drawings]

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

[0013] 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, since the embodiments described below are preferred specific examples of the present invention, various technically preferable limitations are imposed. However, the scope of the present invention is not limited to these embodiments unless otherwise specifically stated to limit the present invention in the following description.

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

[0015] <A.1. Overview of Electronic Payment System Sys> With reference to FIGS. 1 to 3, an overview of the electronic payment system Sys will be described.

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

[0017] As shown in FIG. 1, the electronic payment system Sys includes a payment device 3, a store device 5 capable of communicating with the payment device 3 via a network NW, and one or more terminal devices 1 capable of communicating with the payment device 3 via the network NW, and provides services related to electronic payment to the user U of the terminal device 1.

[0018] In the present embodiment, as an example, a case where the electronic payment system Sys includes a plurality of terminal devices 1 is assumed. Specifically, in the present embodiment, a case where the electronic payment system Sys includes Q terminal devices 1 is assumed. Here, the value Q is a natural number satisfying "Q ≧ 2". Further, hereinafter, among the Q terminal devices 1 included in the electronic payment system Sys, the q-th terminal device 1 is referred to as terminal device 1[q]. Here, the variable q is a natural number satisfying "1 ≦ q ≦ Q". Further, hereinafter, the user U using the terminal device 1[q] is referred to as user U[q].

[0019] The terminal device 1[q] (an example of a "terminal") is, for example, a mobile terminal such as a smartphone or a tablet terminal, and is carried by the user U[q]. In this embodiment, an electronic payment program PG-T is installed in the terminal device 1[q]. The terminal device 1[q] executes the electronic payment program PG-T to launch an electronic payment application (hereinafter, may be referred to as a "payment app"). 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 user U[q] of the terminal device 1[q] can pay for the service by electronic payment by displaying a code image GG based on the token KK acquired from the payment device 3 on the terminal device 1[q] using the payment app running on the terminal device 1[q].

[0020] In the following, the code image GG displayed on the terminal device 1[q] is referred to as the code image GG[q]. The code image GG[q] is, for example, a barcode or a two-dimensional code. In the present embodiment, as an example, it is assumed that the code image GG[q] is a barcode. In addition, in the following, the token KK provided from the payment device 3 to the terminal device 1[q] is referred to as the token KK[q].

[0021] In this embodiment, it is assumed that the store where the in-store device 5 is installed is a physical store that exists in the real world, that is, a brick-and-mortar store. Also, in this embodiment, it is assumed that the service provided at the store is the sale of goods or the provision of services. That is, in this embodiment, when a user U[q] of a terminal device 1[q] receives goods or services at a store where the in-store device 5 is installed, the user U[q] can pay the price of the goods or services by electronic payment.

[0022] The store device 5 is, for example, a POS (Point of Sales) register. When a user U[q] of a terminal device 1[q] pays for a service provided by a store by electronic payment, the store device 5 reads a code image GG[q] displayed on the terminal device 1[q]. Next, the store device 5 generates payment information DP[q] by adding store payment information to a payment code CC[q], which is a value indicated by the read code image GG[q], and supplies the generated payment information DP[q] to the payment device 3. Here, the store payment information is information including, for example, store identification information for uniquely identifying a store that provided a service to the user U[q], a payment amount to be paid by the user U[q] as a payment for the service provided to the user U[q], and a payment date and time, which is the date and time when the payment is made.

[0023] The payment device 3 executes a payment process based on the payment information DP[q] when it is supplied with the payment information DP[q] from the store device 5. Here, the payment process is a process for finalizing a payment from the user U[q] of the terminal device 1[q] to a store as a consideration for a service provided by the store when the user U[q] of the terminal device 1[q] receives the service from the store.

[0024] In this embodiment, as an example, it is assumed that the payment device 3 manages the usage fee of the terminal device 1[q] by the user U[q]. Here, the usage fee of the terminal device 1[q] includes, for example, the purchase price of the terminal device 1[q] and the communication fee incurred when the terminal device 1[q] communicates. In this embodiment, the payment device 3 withdraws the usage fee of the terminal device 1[q] from the bank account of the user U[q] registered in advance in the payment device 3 on the payment date of each month. In the following, the usage fee of the terminal device 1[q] may be referred to as "telephone fee". In addition, in this embodiment, as an example, it is assumed that the payment device 3 manages electronic money of the user U[q] that can be used at the terminal device 1[q]. In this embodiment, it is assumed that the electronic money managed by the payment device 3 is so-called prepaid electronic money, and the user U[q] can use the electronic money equivalent to the charged amount by charging the electronic money in advance. However, the present invention is not limited to such an embodiment. The electronic money managed by the payment device 3 may be so-called post-paid electronic money that can be used within a predetermined upper limit. In addition, in this embodiment, as an example, it is assumed that the payment device 3 is capable of communicating with a credit card server operated by a credit card company, and that payment for user U[q] is possible using a credit card issued by the credit card company for user U[q].

[0025] In this embodiment, the payment device 3 can perform payment processing for user U[q] of terminal device 1[q] using a payment method selected by user U[q] from three payment methods: combined telephone bill payment, prepaid balance payment, and credit card payment. Here, the telephone bill combined payment is a payment method in which the user U[q] makes a payment to the store by combining the telephone bill with the usage fee of the terminal device 1[q]. Also, the prepaid balance payment is a payment method in which the user U[q] makes a payment to the store using the electronic money of the user U[q] managed by the settlement device 3. Also, the credit card payment is a payment method in which the user U[q] makes a payment to the store using the credit card of the user U[q].

[0026] Furthermore, in this embodiment, as described above, the payment device 3 pays out the token KK[q] in response to a request from the terminal device 1[q], and supplies the paid-out token KK[q] to the terminal device 1[q].

[0027] Below, we will explain an example of the operation of the electronic payment system Sys when the terminal device 1[q] and the payment device 3 are capable of communicating with each other and the electronic payment system Sys of this embodiment provides an electronic payment service to the user U[q] of the terminal device 1[q] (hereinafter, this may be referred to as "online electronic payment"). First, when a user U[q] of a terminal device 1[q] receives a service at a store where a store device 5 is installed and pays for the service by online electronic payment, the user U[q] operates the terminal device 1[q] to start a payment application on the terminal device 1[q]. Next, when the payment application is started, the terminal device 1[q] requests a token KK[q] from the payment device 3. Next, the payment device 3 supplies the token KK[q] to the terminal device 1[q] in response to the request from the terminal device 1[q]. Next, the terminal device 1[q] generates a payment code CC[q] based on the token KK[q] supplied from the payment device 3, and displays a code image GG[q] representing the payment code CC[q]. Next, the in-store device 5 reads the code image GG[q] displayed on the terminal device 1[q] to generate payment information DP[q] including the payment code CC[q] indicated by the code image GG[q] and store payment information, and supplies the payment information DP[q] to the payment device 3. Next, the payment device 3 executes a payment process based on the payment information DP[q] supplied from the in-store device 5, thereby finalizing the payment from the user U[q] to the store.

[0028] In the above-mentioned online electronic payment, the payment device 3 issues a token KK[q] in response to a request from the terminal device 1[q]. Therefore, the online electronic payment can be executed only when the terminal device 1[q] and the payment device 3 can communicate with each other, and cannot be executed when the terminal device 1[q] and the payment device 3 have difficulty communicating with each other. Therefore, the electronic payment system Sys according to this embodiment executes the payment process using the payment information DP[q] generated based on the token KK[q] stored in the terminal device 1[q] when the terminal device 1[q] and the payment device 3 have difficulty communicating with each other.

[0029] Below, we will explain an example of the operation of the electronic payment system Sys in this embodiment when communication between the terminal device 1[q] and the payment device 3 is difficult and the electronic payment system Sys provides electronic payment services to the user U[q] of the terminal device 1[q] (hereinafter, this may be referred to as "offline electronic payment"). First, when a user U[q] of a terminal device 1[q] receives a service at a store where a store device 5 is installed and pays for the service by offline electronic payment, the user U[q] operates the terminal device 1[q] to start a payment application on the terminal device 1[q]. Next, when the payment application is started, the terminal device 1[q] generates a payment code CC[q] based on the token KK[q] stored in the terminal device 1[q] 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] including the payment code CC[q] indicated by the code image GG[q] and store payment information, and supplies the payment information DP[q] to the payment device 3. Next, the payment device 3 executes a payment process based on the payment information DP[q] supplied from the store device 5 to confirm the payment from the user U[q] to the store.

[0030] As described above, the electronic payment system Sys of this embodiment is capable of performing two types of electronic payment: online electronic payment when the terminal device 1[q] and the payment device 3 can communicate with each other, and offline electronic payment when it is difficult for the terminal device 1[q] and the payment device 3 to communicate with each other. Therefore, compared to a configuration in which only online electronic payment is possible, it is possible to improve the convenience for the user U[q] of the terminal device 1[q].

[0031] In the following, the token KK[q] that the terminal device 1 obtains from the payment device 3 in online electronic payment and that is used to generate the payment code CC[q] will be referred to as the online token KX[q], and the token KK[q] that is stored in the terminal device 1[q] in offline electronic payment and that is used to generate the payment code CC[q] will be referred to as the offline token KY[q]. In addition, in the following, in online electronic payment, the payment code CC[q] that the terminal device 1[q] generates from the online token KX[q] may be referred to as the online payment code CX[q], and in offline electronic payment, the payment code CC[q] that the terminal device 1[q] generates from the offline token KY[q] may be referred to as the offline payment code CY[q]. In addition, in the following, in online electronic payments, the code image GG[q] displayed by the terminal device 1[q] based on the online payment code CX[q] may be referred to as online code image GX[q], and in offline electronic payments, the code image GG[q] displayed by the terminal device 1[q] based on the offline payment code CY[q] may be referred to as offline code image GY[q]. In the following, the payment process performed by the payment device 3 in online electronic payment may be referred to as online payment process, and the payment process performed by the payment device 3 in offline electronic payment may be referred to as offline payment process.

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

[0033] As shown in FIG. 2, the terminal device 1[q] includes 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 interconnects these devices.

[0034] The storage device 12 is a recording medium readable by the control device 11. The storage device 12 includes, for example, a volatile memory such as a random access memory (RAM) that functions as a working area for the control device 11, and a non-volatile memory such as an electrically erasable programmable read-only memory (EEPROM) that stores various information, and stores user identification information DID[q], acquired offline token information KYY[q], offline token related information DYY, a business operator identification token KZ, setting information DS, and an electronic payment program PG-T.

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

[0036] The acquired offline token information KYY[q] is information including one or more offline tokens KY[q] acquired by the terminal device 1[q] from the payment device 3. In this embodiment, it is assumed that the terminal device 1[q] has acquired the offline token KY[q] M times from the payment device 3 during the period from the first activation (initial activation) of the payment app in the terminal device 1[q] to the present. Here, the value M is a natural number that satisfies "M≧1". In the following, the offline token KY[q] acquired m-th from the payment device 3 among the M offline tokens KY[q] acquired by the terminal device 1[q] from the payment device 3 is referred to as the offline token KY[q][m]. Here, the variable m is a natural number that satisfies "1≦m≦M".

[0037] In this manner, 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 aspect. 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, the terminal device 1[q] may delete an expired offline token KY[q][m] (specifically, an offline token KY[q][m] for which the end point of the offline token validity period information DTY[q][m] indicated by the offline token validity period information DTY[q][m] described later has arrived) from among M offline tokens KY[q][1] to KY[q][M] acquired from the payment device 3. Specifically, when the end point of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] included in the offline token related information DYY stored in the storage device 12 is a time earlier than the current time (i.e., when the validity period has expired), the terminal device 1[q] may delete the offline token KY[q][m] corresponding to the offline token validity period TY[q][m] indicating the expiration (i.e., the expired offline token KY[q]) from the acquired offline token information KYY[q]. In this case, the acquired offline token information KYY[q] includes only offline tokens KY[q] within the validity period. Furthermore, for example, the terminal device 1[q] may delete offline tokens KY[q][1] to KY[q][M-1] other than the most recently acquired offline token KY[q][M] among the M offline tokens KY[q][1] to KY[q][M] acquired from the payment device 3. Specifically, upon acquiring the latest offline token KY[q][M] from the payment device 3, the terminal device 1[q] may delete the offline token KY[q][M-1] acquired previously. In this case, the acquired offline token information KYY[q] will include only the latest offline token KY[q][M].

[0038] The offline token related information DYY includes M pieces of offline token validity period information DTY[q][1] to DTY[q][M] that correspond one-to-one to the M offline tokens KY[q][1] to KY[q][M], M encryption keys KS[q][1] to KS[q][M] that correspond one-to-one to the M offline tokens KY[q][1] to KY[q][M], and offline blockage information DHY. In this embodiment, the offline token related information DYY includes M pieces of offline token validity period information DTY[q][1] to DTY[q][M] and M pieces of encryption keys KS[q][1] to KS[q][M], but the present invention is not limited to this embodiment. The offline token related information DYY may include at least the offline token validity period information DTY[q][M] corresponding to the offline token KY[q][M] acquired last among the M pieces of offline token validity period information DTY[q][1] to DTY[q][M], and the encryption key KS[q][M] corresponding to the offline token KY[q][M] acquired last among the M encryption keys KS[q][1] to KS[q][M]. For example, the terminal device 1[q] may delete the encryption key KS[q][m] corresponding to the expired offline token KY[q][m] (specifically, the encryption key KS[q][m] corresponding to the offline token KY[q][m] for which the end point of the offline token validity period information DTY[q][m] indicated by the offline token validity period information DTY[q][m] has arrived) among the M encryption keys KS[q][1] to KS[q][M] acquired from the payment device 3. Specifically, when the end point of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] included in the offline token related information DYY stored in the storage device 12 is a time in the past than the current time (i.e., when the offline token KY[q][m] has expired), the 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. In this case, the offline token related information DYY includes only the encryption key KS[q] corresponding to the offline token KY[q] that has not expired. Furthermore, for example, the terminal device 1[q] may delete the encryption keys KS[q][1] to KS[q][M-1] other than the last acquired encryption key KS[q][M] among the M encryption keys KS[q][1] to KS[q][M] acquired from the payment device 3. Specifically, upon acquiring the latest encryption key KS[q][M] from the payment device 3, the terminal device 1[q] may delete the encryption key KS[q][M-1] acquired previously. In this case, the offline token related information DYY will include only the latest encryption key KS[q][M].

[0039] 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 payment, that is, the offline token validity period TY[q][m], which is the validity period of the offline token KY[q][m]. In this embodiment, it is assumed that the offline token validity period TY[q][m] is a period starting from the time of generation of the offline token KY[q][m] and ending at the time when the offline token validity period TSY has elapsed from the time of generation of the offline token KY[q][m]. Here, in this embodiment, as an example, it is assumed that the offline token validity period TSY is set to "one week". That is, in this embodiment, as an example, it is assumed that the validity period of the offline token KY[q] is one week.

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

[0041] The offline blockage information DHY is information used to determine whether or not to display the offline code image GY[q] on the terminal device 1[q] in offline electronic payment. Specifically, the offline blockage information DHY is information indicating whether or not the payment device 3 is capable of executing offline payment processing. More specifically, the offline blockage information DHY may be information indicating whether or not the function of the payment device 3 for executing offline payment processing is operating without being blocked.

[0042] The business operator identification token KZ includes business operator identification information DKZ for identifying the payment business operator that manages the payment device 3.

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

[0044] The token response information DSW indicates a waiting time of the terminal device 1 from when the terminal device 1 requests the payment device 3 for the token KK (or from when the payment application is started in the terminal device 1 [q]) until the token KK is supplied to the terminal device 1 (hereinafter referred to as a "token response waiting time TSW", an example of a "first time"). In this embodiment, the terminal device 1 waits for the supply of the token KK from the payment device 3 until the token response waiting time TSW has elapsed since the terminal device 1 requested the token KK from the payment device 3. Then, the terminal device 1 stops waiting for the supply of the token KK from the payment device 3 at the timing when the token response waiting time TSW has elapsed since the terminal device 1 requested the token KK from the 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". Note that, hereinafter, the period from when the terminal device 1 requests the token KK from the payment device 3 until the token response waiting time TSW has elapsed may be referred to as a token response waiting period TW (an example of a "first period"). The token response waiting period TW is not limited to a period from when the terminal device 1 requests a token KK from the payment device 3 until a certain time has elapsed. For example, the token response waiting period TW may be a period from when the payment app is started to when the payment app is closed. In this case, the token response waiting time TSW may be a time length from when the payment app is started to when the payment app is closed.

[0045] The online token validity information DSX indicates the length of time (hereinafter referred to as "online token validity time TSX") during which the online token KX[q] can be used for online electronic payment (hereinafter referred to as "online token validity period TX[q]"). In this embodiment, as an example, it is assumed that the online token validity time TSX is set to "5 minutes". However, the present invention is not limited to this aspect. The online token validity time TSX may be any time longer than the token response waiting time TSW. Also, in this embodiment, the online token validity period TX[q] is a period that starts from the generation of the online token KX[q] and ends at the time that the online token validity time TSX has elapsed since the generation of the online token KX[q].

[0046] The offline token validity information DSY indicates the offline token validity time TSY. As described above, the offline token validity time TSY is the time length of the offline token validity period TY[q][m] during which the offline token KY[q][m] can be used in offline electronic payment. Also, as described above, in this embodiment, as an example, it is assumed that the offline token validity time TSY is set to "one week". However, the present invention is not limited to this aspect. The offline token validity time TSY may be any time longer than the online token validity time TSX.

[0047] The update time information DSC is information indicating the update unit time TC. Here, the update unit time TC is an update cycle of the terminal time value AG based on the terminal time TG, which is the current time managed in the terminal device 1[q]. In this embodiment, as an example, it is assumed that the update unit time TC is set to "1 minute". In addition, in this embodiment, as an example, it is assumed that the terminal time value AG is a value that expresses the terminal time TG in the order of "minutes". For example, in this embodiment, when the terminal time TG is "18:25:37", the terminal time value AG may be "1825" by deleting "37 seconds" from the terminal time TG. However, the present invention is not limited to such an aspect. The update unit time TC may be shorter than the offline token validity time TSY. In addition, the update unit time TC may be shorter than the online token validity time TSX.

[0048] The control device 11 includes a processor. The processor provided in the control device 11 includes, for example, one or more central processing units (CPUs). However, the processor provided in the control device 11 may include hardware such as a graphics processing unit (GPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a field programmable gate array (FPGA) in addition to the one or more CPUs, or in place of a part or all of the one or more CPUs. The processor provided in the control device 11 executes an electronic payment program PG-T stored in the storage device 12 and operates in accordance with 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.

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

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

[0051] 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.

[0052] In online electronic payment, 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 payment, 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.

[0053] The display device 13 is hardware for displaying various information. As the display device 13, various display panels such as a liquid crystal display panel and an organic EL display panel can be adopted. 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.

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

[0055] The communication device 15 is hardware for communicating with an external device that exists 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. In addition, the information acquisition unit 112 acquires various information from the payment device 3 via the communication device 15.

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

[0057] As shown in FIG. 3, the payment device 3 includes a control device 31, a storage device 32, a communication device 35, and a bus 300 that interconnects these devices.

[0058] The storage device 32 is a recording medium readable by the control device 31. The storage device 32 is configured to include, for example, a volatile memory such as a RAM that functions as a working area for the control device 31, and a non-volatile memory such as an 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, payment management information DKP, setting information DS, and a control program PG-S.

[0059] The user management information DU has Q records in one-to-one correspondence with the 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 above-mentioned user identification information DID[q], electronic money balance information DPR[q], telephone charge information DTL[q], credit card information DCR[q], point information DPT[q], and user payment information DSH[q].

[0060] The electronic money balance information DPR[q] is information that indicates the balance of electronic money held by the user U[q]. The telephone charge information DTL[q] is information indicating the telephone charge to be paid by the user U[q] (that is, the charge for using the terminal device 1[q]). The credit card information DCR[q] is information about a credit card owned by the user U[q] and registered by the user U[q] in the payment device 3 via the terminal device 1[q]. Specifically, the credit card information DCR[q] indicates, for example, the card number, expiration date, etc. of the credit card owned by the user U[q]. The point information DPT[q] is information about points granted to the user U[q] by the payment device 3. In this embodiment, it is assumed that the payment device 3 grants points to the user U[q], so that the user U[q] can use electronic money in an amount equivalent to the granted points. The user payment information DSH[q] is information that indicates the payment method selected by the user U[q].

[0061] The online token payout information DKX has one or more records that correspond one-to-one to one or more online tokens KX paid out by the payment device 3. Each record of the online token payout information DKX includes the online token KX[q] paid out by the payment device 3, the user identification information DID[q] of the user U[q] corresponding to the terminal device 1[q] to which the online token KX[q] is paid out, 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]").

[0062] The offline token issuance information DKY has one or more records in one-to-one correspondence with one or more offline tokens KY issued by the payment device 3. Each record of the offline token issuance information DKY includes an offline token KY[q] issued by the payment device 3, an encryption key KS[q] issued by the payment device 3 in correspondence with the offline token KY[q], user identification information DID[q] of a user U[q] corresponding to the terminal device 1[q] to which the offline token KY[q] is issued, and 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 apparatus 3 may delete, from among the multiple records contained in the offline token payout information DKY, a record for which the end point of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q][m] has arrived. Specifically, when the end point of the offline token validity period TY[q][m] indicated by the offline token validity period information DTY[q] is a time earlier than the current time (i.e., when it has expired), the payment apparatus 3 may delete, from among the multiple offline tokens KY included in the offline token payout information DKY, the offline token KY[q][m] corresponding to that offline token validity period information DTY[q][m] (i.e., the expired offline token KY[q][m]), and may also delete, from among the multiple encryption keys KS included in the offline token payout information DKY, the encryption key KS[q][m] corresponding to that offline token validity period information DTY[q][m] (i.e., the expired encryption key KS[q][m]). Furthermore, the payment apparatus 3 may delete, in the offline token issuance information DKY, records other than the record corresponding to the latest offline token KY[q][M] from among the M records corresponding to the M offline tokens KY[q][1] to KY[q][M] issued to the user U[q]. In other words, the payment apparatus 3 may delete, in the offline token issuance information DKY, offline tokens KY[q] other than the last issued offline token KY[q][M] from among the M offline tokens KY[q][1] to KY[q][M] issued to the user U[q]. Furthermore, the payment apparatus 3 may delete, in the offline token issuance information DKY, encryption keys KS[q] other than the last issued encryption key KS[q][M] from among the M encryption keys KS[q][1] to KS[q][M] issued to the user U[q].

[0063] The payment management information DKP has one or more records that correspond one-to-one to one or more electronic payments executed in the electronic payment system Sys. Each record of the payment management information DKP includes payment information DP[q] corresponding to each electronic payment.

[0064] The control device 31 includes a processor. The processor provided in the control device 31 includes, for example, one or more CPUs. However, the processor provided in the control device 31 may include hardware such as a GPU, a DSP, an ASIC, a PLD, or an FPGA in addition to the one or more CPUs, or in place of a part 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 in accordance with the control program PG-S, thereby functioning as an information supply unit 311, an information acceptance unit 312, and a payment processing unit 313.

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

[0066] The information receiving unit 312 is an example of a “receiving unit” and receives an online token request, an online blockage information request, an offline token request, and an offline blockage information request from the terminal device 1[q]. The information receiving unit 312 also receives payment information DP[q] from the in-store device 5.

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

[0068] 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.

[0069] <A.2. Operation of the Electronic Settlement System Sys> Hereinafter, with reference to FIGS. 4 to 11, an outline of the operation of the electronic settlement system Sys will be described.

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

[0071] 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 settlement, the control device 11 of the terminal device 1[q] executes the electronic settlement program PG-T based on the operation of the user U[q] to start the settlement application (S11).

[0072] Next, the control device 11 of the terminal device 1[q] judges whether the communication state of the terminal device 1[q] is online (S12). Specifically, the control device 11 may judge whether the communication state of the terminal device 1[q] is online by using, for example, a communication state monitoring function of the terminal device 1[q] by the operating system of the terminal device 1[q]. Here, "the communication state of the terminal device 1[q] is online" may be, for example, a state in which the terminal device 1[q] can communicate with an external device that exists outside the terminal device 1[q], or a state in which the radio wave intensity of the wireless communication is equal to or greater than a predetermined intensity when the terminal device 1[q] performs wireless communication. Note that, in the sequence chart shown in FIG. 4, it is assumed that the communication state of the terminal device 1[q] is online.

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

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

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

[0076] Then, the control device 31 of the payment device 3 supplies the online token KX[q] to the terminal device 1[q] in response to the online token request supplied from the terminal device 1[q] in step S23 (S24). Specifically, in step S24, the control device 31 first generates an 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].

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

[0078] Next, the information transmitting 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 telegram requesting offline blockage information DHY.

[0079] Then, the control device 31 of the payment device 3 supplies offline blockage information DHY to the terminal device 1[q] in 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 offline payment processing can be executed in the payment device 3, and generates offline blockage information DHY indicating the determination result. Then, the information supply unit 311 of the control device 31 supplies the generated offline blockage information DHY to the terminal device 1[q].

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

[0081] Then, 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] in response to the offline token request supplied from the terminal device 1[q] in step S33 (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].

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

[0083] Next, the information acquisition unit 112 of the terminal device 1[q] acquires the offline token KY[q] and the encryption key KS[q] provided from the payment device 3 in step S34, and stores the acquired offline token KY[q] and encryption key KS[q] in the storage device 12 (S35). 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 offline token KY[q] acquired in step S35 to the acquired offline token information KYY[q] as the offline token KY[q][M], and adds the encryption key KS[q] acquired in step S35 to the offline token related information DYY as the encryption key KS[q][M]. In addition, in this embodiment, as an example, a case is assumed in which the information acquisition unit 112 stores the offline blockage information DHY acquired in step S32 in the storage device 12. In addition, if the memory device 12 already stores offline blockage information DHY, the information acquisition unit 112 overwrites the offline blockage information DHY already stored in the memory device 12 with the offline blockage information DHY newly acquired in step S32.

[0084] Furthermore, the code generating unit 113 of the terminal device 1[q] determines whether or not the execution function of the online payment processing in the payment device 3 is in a blocked state, based on the online blockage information DHX acquired by the information acquiring unit 112 in step S22 (S41). Note that the sequence chart shown in Fig. 4 assumes a case where the execution function of the online payment processing in the payment device 3 is not in a blocked state, that is, a case where the payment device 3 is able to execute the online payment processing. Hereinafter, a case where the execution function of the online payment processing in the payment device 3 is in a blocked state may be referred to as an "online blocked state".

[0085] 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] including the online token KX[q].

[0086] Thereafter, 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 causes the display device 13 to display the online code image GX[q] based on the generated display information (S43). Specifically, in step S43, the display control unit 114 causes the display device 13 to display the online code image display screen G1 including the online code image GX[q].

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

[0088] As shown in FIG. 5, the online code image display screen G1 includes an online code image GX[q], a payment method display area A1, and a point use selection button B1.

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

[0090] The point use selection button B1 is a button for selecting whether or not to use points given to the user U[q] in online electronic payment. Although not shown in FIG. 4 and the like, in this embodiment, as an example, it is assumed that when the user U[q] changes whether or not to use points using the point use selection button B1 on the online code image display screen G1, the change content is notified to the payment device 3 from the terminal device 1[q].

[0091] The payment method display area A1 displays the payment method of the user U[q] when the user U[q] uses electronic payment in the electronic payment system Sys. Specifically, the display control unit 114 displays the payment method of the user U[q] in the payment method display area A1 based on the user payment information DSH[q]. Note that, although not shown in FIG. 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 of user U[q] displayed in payment method display area A1 can be changed on a payment method selection screen GS, which will be described below.

[0092] FIG. 6 is a schematic diagram showing an example of the payment method selection screen GS.

[0093] 6, the payment method selection screen GS includes three radio buttons RB including a radio button RB1 for selecting telephone bill combined payment as a payment method in electronic payment, a radio button RB2 for selecting prepaid balance payment as a payment method in electronic payment, and a radio button RB3 for selecting credit card payment as a payment method in electronic payment, a decision button BS1 for deciding 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. By pressing the decision button BS1 while selecting any one of the three radio buttons RB on the payment method selection screen GS, the user U[q] can select the payment method corresponding to the selected radio button RB as the payment method for the user U[q] in the electronic payment system Sys.

[0094] Let us return to the explanation given in FIG. As shown in FIG. 4, the in-store device 5 uses a barcode reader or the like provided in the in-store device 5 to perform a process of reading the code image GG[q] (online code image GX[q]) included in the screen (online code image display screen G1) displayed on the display device 13 of the terminal device 1[q] (S44). The in-store device 5 then generates store payment information (store identification information, payment amount, payment date and time) based on the service content provided to the user U[q] by the store in which the in-store device 5 is installed, and generates payment information DP[q] including 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 in-store device 5 transmits the payment information DP[q] generated in step S61 to the payment device 3 (S62).

[0095] Next, the settlement processing unit 313 of the settlement device 3 checks 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).

[0096] <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.

[0097] 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 the price 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).

[0098] 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.

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

[0100] Next, the code generation unit 113 of the terminal device 1[q] acquires 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] including the offline token KY[q][M].

[0101] Thereafter, the display control unit 114 of the terminal device 1[q] generates display information for displaying an 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 causes the display device 13 to display the offline code image GY[q] based on the generated display information (S54). Specifically, in step S54, the display control unit 114 causes the display device 13 to display an offline code image display screen G2 including the offline code image GY[q].

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

[0103] As shown in FIG. 8, the offline code image display screen G2 includes an offline code image GY[q], a payment method display area A2, and a point use selection button B2.

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

[0105] Let us return to the explanation given in FIG. As shown in FIG. 7, the in-store device 5 performs a 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). The in-store device 5 then generates store payment information based on the service content provided to the user U[q] by the store in which the in-store device 5 is installed, and generates payment information DP[q] including 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 in-store device 5 transmits the payment information DP[q] generated in step S61 to the payment device 3 (S62).

[0106] Next, the payment processing unit 313 of the payment device 3 checks the validity of the token KK[q] (offline token KY[q][M]) included in the payment code CC[q] (offline payment code CY[q]) based on the payment code CC[q] (offline payment code CY[q]) included in the payment information DP[q] provided from the in-store device 5 (S63). Note that the sequence chart shown in FIG. 7 assumes that the token KK[q] (offline token KY[q][M]) is valid. Thereafter, the payment processing unit 313 of the payment device 3 executes the payment process (offline payment process) (S64). Then, the information supply unit 311 of the settlement device 3 transmits a register billing response indicating the result of the settlement process (offline settlement process) in step S64 to the in-store device 5 (S65).

[0107] Fig. 9 is a sequence chart showing another example of the operation of the electronic payment system Sys when the electronic payment system Sys executes offline electronic payment. In Fig. 9, it is assumed that the electronic payment system Sys cannot execute online electronic payment because the terminal device 1[q] fails to acquire the online token KX[q] from the payment device 3.

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

[0109] Next, the information transmission unit 111 of the terminal device 1[q] transmits an online blockage information request to the payment device 3 (S21). However, the sequence chart shown in FIG. 9 assumes a case where there is no response from the payment device 3 to the online blockage information request. Further, the information transmitting unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S23). However, the sequence chart shown in Fig. 9 assumes a case where there is no response from the payment device 3 to the online token request. That is, as described above, the sequence chart shown in Fig. 9 assumes a case where the terminal device 1[q] fails to acquire the online token KX[q] from the payment device 3. Also, the information transmitting unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S31). However, the sequence chart shown in Fig. 9 assumes a case where there is no response from the payment device 3 to the offline blockage information request. Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an offline token request to the payment device 3 (S33). However, the sequence chart shown in Fig. 9 assumes a case where there is no response from the payment device 3 to the offline token request.

[0110] 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 blockage information DHY stored in the storage device 12 (S51). Note that the sequence chart shown in Fig. 9 assumes a case where the payment device 3 is not in an offline blocked state, that is, a case where the payment device 3 is able to execute offline payment processing.

[0111] Thereafter, the electronic payment system Sys performs the processes of steps S52 to S55 and steps S61 to S65 to perform offline electronic payment.

[0112] Fig. 10 is a sequence chart showing another example of the operation of the electronic payment system Sys when the electronic payment system Sys executes offline electronic payment. In Fig. 10, it is assumed that the electronic payment system Sys cannot execute online electronic payment because the payment device 3 is in an online blocked state.

[0113] As shown in FIG. 10, when the user U[q] of the terminal device 1[q] receives service provision at a store where the store device 5 is installed and pays the consideration for the service by electronic payment, the above-described 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 in 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 congestion information DHX, online token KX[q], offline congestion 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 congestion state based on the online congestion 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 congestion 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 congestion state, the code generation unit 113 of the terminal device 1[q] determines whether the settlement device 3 is in an offline congestion state based on the offline congestion 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 congestion state, that is, when the settlement device 3 can execute offline settlement processing.

[0114] 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).

[0115] <A.2.3. Operation of the Electronic Payment System Sys at First Startup> FIG. 11 is a sequence chart showing an example of the operation of the electronic payment system Sys when the payment application is launched for the first time in the terminal device 1[q] and the electronic payment system Sys executes electronic payment.

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

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

[0118] Next, the information transmitting 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 the setting information DS.

[0119] Then, the control device 31 of the payment device 3 supplies the setting information DS to the terminal device 1[q] in response to the setting information request supplied from the terminal device 1[q] in step S13 (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].

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

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

[0122] In the present embodiment, as an example, a case has been described in which the terminal device 1[q] transmits a setting information request to the payment device 3 in step S13, and then transmits a business operator identification token request to the payment device 3 in step S15, but the present invention is not limited to this aspect. The terminal device 1[q] may transmit a setting information request to the payment device 3 after transmitting a business operator identification token request to the payment device 3. Furthermore, the terminal device 1[q] may transmit the setting information request and the business operator identification token request to the payment device 3 simultaneously (for example, in the same message).

[0123] 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 operator identification token KZ supplied from the payment device 3 in step S16, and stores the acquired setting information DS and operator identification token KZ in the memory device 12 (S17).

[0124] Thereafter, the electronic payment system Sys performs the processes from step S21 onward to carry out the electronic payment.

[0125] In this embodiment, an example has been described in which the payment device 3 supplies the setting information DS and the operator identification token KZ to the terminal device 1[q] when the payment app is launched for the first time on the terminal device 1[q], but the present invention is not limited to this example.

[0126] 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 application startup notification (not shown) indicating that the settlement application 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 application startup notification. Further, for example, when a settlement application 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.

[0127] Also, for example, when the merchant identification information DKZ is changed, the settlement device 3 may supply a merchant identification token KZ indicating the changed merchant identification information DKZ to the terminal device 1[q]. Specifically, when the merchant identification information DKZ is changed and a settlement application startup notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply a merchant identification token KZ based on the changed merchant identification information DKZ to the terminal device 1[q] as a response to the settlement application startup notification. In this case, the frequency at which the terminal device 1[q] acquires the merchant 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 merchant identification token KZ is lower than the frequency at which it acquires the offline token KY[q]. Also, for example, when a settlement application startup notification is supplied from the terminal device 1[q] to the settlement device 3, the settlement device 3 may supply the merchant identification token KZ to the terminal device 1[q] regardless of whether the merchant identification information DKZ has been changed.

[0128] <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 the terminal device 1[q] is offline, when the terminal device 1[q] fails to acquire the online token KX[q] from the payment device 3, and when the payment device 3 is in an online blocked state. Therefore, compared with a mode in which the electronic payment system can perform only online electronic payment, for example, it is possible to reduce the possibility that when a user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed, it is difficult to pay the price of the service by electronic payment. As a result, according to this embodiment, it is possible to reduce the decrease in convenience of payment for the user U[q] who receives a service at a store where the store device 5 is installed.

[0129] In addition, in this embodiment, when the payment application is started in the terminal device 1[q] (see step S11) and electronic payment is executed, the terminal device 1[q] acquires the online token KX[q] (see step S24) and also acquires the offline token KY[q] (see step S34) from the payment device 3. That is, in this embodiment, the terminal device 1[q] acquires the offline token KY[q] from the payment device 3 at the timing when the terminal device 1[q] and the payment device 3 perform communication related to electronic payment. Therefore, according to this embodiment, it is possible to reduce the number of processes other than electronic payment in the terminal device 1[q], compared to a case where the terminal device 1[q] acquires the offline token KY[q] from the payment device 3 at a timing unrelated to the timing when electronic payment is performed, such as a predetermined timing. As a result, according to this embodiment, it is possible to reduce the complexity of schedule adjustment of processes in the terminal device 1[q], compared to a case where the terminal device 1[q] acquires the offline token KY[q] from the payment device 3 at a timing unrelated to the timing when electronic payment is performed.

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

[0131] Also, in this embodiment, the terminal device 1[q] displays the online code image GX[q] on the display device 13 only when the online congestion information DHX indicates that the payment device 3 is not in an online congestion state, and also displays the offline code image GY[q] on the display device 13 only when the offline congestion information DHY indicates that the payment device 3 is not in an offline congestion state. That is, according to this embodiment, when it is difficult to execute online electronic payment, 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 payment, the display of the offline code image GY[q] on the terminal device 1[q] can be suppressed. Therefore, according to this embodiment, for example, compared with a mode of displaying the code image GG[q] without considering the congestion information DH, the labor of the user U[q] related to the display of the code image GG[q] can be reduced.

[0132] <A.3. Outline of the Payment Code CC[q]> Hereinafter, with reference to FIG. 12, the outline of the payment code CC[q] (online payment code CX[q] and offline payment code CY[q]) will be described.

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

[0134] As shown in FIG. 12, the online settlement code CX[q] includes a merchant identification token KZ, an online token KX[q], an appropriation 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 appropriation value VJ, and a code type value VV.

[0135] 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 1-digit data composed of a single-digit number (0 to 9). However, the code value VZ may be 1-digit data composed of a single alphanumeric character (a single-digit number or a single alphabet).

[0136] 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 1-digit data composed of a single-digit number (0 to 9). However, the code value VX may be 1-digit data composed of a single alphanumeric character (a single-digit number or a single alphabet).

[0137] 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 1-digit data composed of a single-digit number (0 to 9). However, the code value VY may be 1-digit data composed of a single alphanumeric character (a single-digit number or a single alphabet).

[0138] The time encryption code TT[q] is LT-digit data consisting of LT code values ​​VT[1] to VT[LT]. Here, the value LT is a natural number that satisfies "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 encryption 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 one-digit data consisting of one digit number (0 to 9). However, the code value VT may be one-digit data consisting of one alphanumeric character (one digit number or one alphabet).

[0139] The allocation value VJ is one-digit data consisting of a single digit (0 to 9). However, the allocation value VJ may be a one-bit value, a number of two or more digits, or an alphanumeric character of one or more digits.

[0140] The code type value VV is one-digit data consisting of one digit (0-9). However, the code type value VV may be a one-bit value, a number of two or more digits, or an alphanumeric character of one or more digits. A value indicating the type of the payment code CC[q] is set in the code type value VV. Specifically, when the payment code CC[q] is an online payment code CX[q], a value indicating that the payment code CC[q] is the online payment code CX[q], for example, "1", is set in the code type value VV. Hereinafter, the value indicating that the payment code CC[q] is the online payment code CX[q] is referred to as the "online code value". Also, when the payment code CC[q] is an offline payment code CY[q], a value indicating that the payment code CC[q] is the offline payment code CY[q], for example, "2", is set in the code type value VV. Hereinafter, the value indicating that the payment code CC[q] is the offline payment code CY[q] is referred to as the "offline code value".

[0141] The following describes the process by which the code generating unit 113 generates a payment code CC[q] (hereinafter referred to as the "code generating process"). In the following, the process by the code generating unit 113 to generate an online payment code CX[q] is referred to as the "online code generating process". In the following, the process by the code generating unit 113 to generate an offline payment code CY[q] is referred to as the "offline code generating process".

[0142] In the online code generation process, the code generation unit 113 sets an online code value (e.g., "1") for the code type value VV. Then, the code generation unit 113 generates an online payment code CX[q] by arranging in a predetermined order 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 appropriated value VJ, and the code type value VV.

[0143] 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 deletes the portion representing "seconds" from the terminal time TG and leaves the portions representing "minutes" and "hours" to generate the terminal time value AG. Next, in the offline code generation process, the code generation unit 113 generates a time encryption code TT[q] by encrypting the terminal time value AG using the encryption key KS[q][M] corresponding to the offline token KY[q][M] that was last acquired among the M encryption keys KS[q][1] to KS[q][M] stored in the storage device 12. That is, in this embodiment, it is assumed that the time encryption code TT[q] is a 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") for the code type value VV. Then, in the offline code generation process, the code generation unit 113 generates an offline payment code CY[q] by arranging in a predetermined order the business identification token KZ stored in the memory 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 this embodiment, it is assumed that the number of digits of the online payment code CX[q] is equal to the number of digits of the offline payment code CY[q].

[0144] As described above, in this embodiment, the code generation unit 113 updates the terminal time value AG at a period of the 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 a 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 appropriated value VJ, and the code type value VV in a predetermined order.

[0145] In the following, the time encryption code TT[q] that has been updated (n+1) times may be referred to as the time encryption code TT[q][n]. That is, in the following, the time encryption code TT[q] that has never been updated may be referred to as the time encryption code TT[q][1], and the time encryption code TT[q] that has been updated once may be referred to as the time encryption code TT[q][2]. Here, the variable n is a natural number that satisfies "1≦n".

[0146] As described above, 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.

[0147] 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.

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

[0149] 13 to 16 are flowcharts showing an example of the operation of the terminal device 1[q] when electronic payment is performed in the electronic payment system Sys. The flowcharts shown in Fig. 13 to 16 start when a payment application is launched in the terminal device 1[q].

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

[0151] If the result of the determination in step S101 is positive, that is, if the communication state of the terminal device 1[q] is online, the information transmission unit 111 of the terminal device 1[q] transmits an online blockage information request to the payment device 3 (S103). The process of step S103 corresponds to the process of step S21 described above.

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

[0153] Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S109). The process of step S109 corresponds to the process of step S23 described above.

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

[0155] Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S115). The process of step S115 corresponds to the process of step S31 described above.

[0156] Then, if there is no response to the offline blockage information request from the payment device 3 (S117: N), the control device 11 of the terminal device 1[q] proceeds to step S121. 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 (S117: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the offline blockage information DHY (S119).

[0157] Furthermore, the information transmitting unit 111 of the terminal device 1[q] transmits an offline token request to the payment device 3 (S121). Note that the process of step S121 corresponds to the process of step S33 described above.

[0158] Then, when there is no response to the offline token request from the payment device 3 (S123: N), the control device 11 of the terminal device 1[q] advances the process to step S131. On the other hand, when the communication device 15 receives the offline token KY[q] and the encryption key KS[q] transmitted from the payment device 3 as a response to the offline token request (S123: Y), the information acquisition unit 112 of the terminal device 1[q] stores the offline token KY[q] and the 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 the encryption key KS[q] provided from the payment device 3. Next, the information acquisition unit 112 adds the acquired offline token KY[q] to the acquired offline token information KYY[q] as the latest offline token KY[q][M], and also adds the acquired encryption key KS[q] to the offline token related information DYY as the latest encryption key KS[q][M]. The process of step S125 corresponds to the process of step S35 described above.

[0159] As shown in Fig. 14, the code generation unit 113 of the terminal device 1[q] judges whether the payment device 3 is not in an online blocked state (S131). Specifically, in step S131, the code generation unit 113 judges whether the information acquisition unit 112 has acquired online blockage information DHX in step S107 and whether the online blockage information DHX indicates that the payment device 3 is not in an online blocked state. The process of step S131 corresponds to the process of step S41 described above.

[0160] If the result of the judgment in step S131 is negative, i.e., if the information acquisition unit 112 has not acquired 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 blocked state, the control device 11 of the terminal device 1[q] proceeds to step S151. Also, even if the result of the judgment 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.

[0161] 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 an online code generation process to generate an online payment code CX[q] (S135). The process of step S135 corresponds to the process of step S42 described above.

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

[0163] Next, the control device 11 of the terminal device 1[q] determines whether the 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 an end operation has been performed, the control device 11 of the terminal device 1[q] ends the series of processes related to the flowcharts shown in FIGS.

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

[0165] In this embodiment, it is assumed that the online code image update opportunity is deemed to have arrived when any one or more of the three update conditions J1, namely, the online token time condition J11, the online code image display condition J12, and the online code image operation condition J13, are met. Here, the online token time condition J11 is a condition that a time equivalent to the online token valid time TSX (5 minutes in this embodiment) has elapsed since the online code image GX[q] was displayed on the display device 13. The online code image display condition J12 is a condition that the online code image display screen G1 including the online code image GX[q] transitions from background display to foreground display on the display device 13. The online code image operation condition J13 is a condition that a pull-down operation is performed in a state in which the online code image display screen G1 including the online code image GX[q] is displayed on the display device 13.

[0166] If the result of the determination in step S141 is negative, that is, if the opportunity to update the online code image has not arrived, the control device 11 returns the process to step S137 and causes the display device 13 to continue displaying the online code image GX[q]. If the result of the determination in step S141 is positive, that is, if a trigger for updating the online code image has arrived, the information transmitting unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S143).

[0167] Then, when there is no response from the payment device 3 to the online token request in step S143 (S145: N), the control device 11 of the terminal device 1[q] advances the process to step S151. On the other hand, when the communication device 15 receives the online token KX[q] transmitted from the payment device 3 as a response to the online token request in step S143 (S145: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the online token KX[q] (S147), advances the process to step S135, and generates an online payment code CX[q] in step S135 based on the online token KX[q] acquired in step S147.

[0168] 15, the code generation unit 113 of the terminal device 1[q] determines whether the payment device 3 is not in an offline blocked state (S151). Specifically, in step S151, the code generation unit 113 determines whether the information acquisition unit 112 has acquired the offline blockage information DHY in step S119, and whether the offline blockage information DHY indicates that the payment device 3 is not in an offline blocked state. The process of step S151 corresponds to the process of step S51 described above.

[0169] If the result of the judgment in step S151 is negative, i.e., if the information acquisition unit 112 has not acquired 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 blocked state, the control device 11 of the terminal device 1[q] proceeds to step S171.

[0170] If the result of the judgment in step S151 is positive, i.e., if the offline blockage information DHY indicates that the payment device 3 is not in an offline blocked state, the code generation unit 113 of the terminal device 1[q] judges whether the latest offline token KY[q][M] stored in the memory device 12 is valid (S153). Specifically, in step S153, the code generation unit 113 judges whether or not one or more offline tokens KY[q][1] to KY[q][M] are stored in the storage device 12 and whether or not the offline token validity period TY[q][M] corresponding to the latest offline token KY[q][M] stored in the storage device 12 is a period including the current time. If the result of the judgment is positive, the code generation unit 113 acquires the latest offline token KY[q][M] from the storage device 12. The process of step S153 corresponds to the process of step S52 described above.

[0171] If the result of the judgment in step S153 is negative, i.e., if the offline token KY[q] is not stored in the memory device 12, or if the latest offline token KY[q][M] stored in the memory device 12 has expired, the control device 11 of the terminal device 1[q] proceeds to step S171.

[0172] 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 an offline payment explanation screen G3 (S155). Note that the process of step S155 may be omitted.

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

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

[0175] The offline payment explanation display area A3 is an area where text is displayed to explain offline electronic payment to the user U[q]. The explanation screen skip button CB3 is a button for accepting an operation from the user U[q] to skip the display of the offline payment explanation screen G3 from the next time onwards. The offline payment confirmation button B3 is a button for accepting an operation from the user U[q] to approve the execution of the offline electronic payment.

[0176] Returning to the explanation of FIG. 15, when the 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 an offline code generation process and generates an offline payment code CY[q] based on the offline token KY[q][M] acquired from the storage device 12 in step S153 (S157). The process of step S157 corresponds to the process of step S53 described above.

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

[0178] Next, the control device 11 of the terminal device 1[q] determines whether or not the 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 an end operation has been performed, the control device 11 of the terminal device 1[q] ends the series of processes related to the flowcharts shown in FIGS.

[0179] If the result of the determination in step S161 is negative, that is, if the end operation has not been performed, the code generating unit 113 of the terminal device 1[q] determines whether or not an opportunity to update the offline code image has arrived (S163). Here, the opportunity to update the offline code image is an opportunity to update the offline code image GY[q] displayed on the display device 13.

[0180] In this embodiment, it is assumed that the offline code image update opportunity occurs when at least one of the two update conditions J2, the offline code image display condition J22 and the offline code image operation condition J23, is satisfied. Here, the offline code image display condition J22 is a condition that the offline code image display screen G2 including the offline code image GY[q] transitions from background display to foreground display on the display device 13. Also, the offline code image operation condition J23 is a condition that a pull-down operation is executed in a state in which the offline code image display screen G2 including the offline code image GY[q] is displayed on the display device 13.

[0181] If the result of the judgment in step S163 is positive, that is, if the opportunity to update the offline code image has arrived, the control device 11 of the terminal device 1[q] advances the process to step S101 and executes again a series of processes related to the flowcharts shown in Figures 13 to 16.

[0182] If the result of the judgment in step S163 is negative, i.e., if the opportunity to update the offline code image has not arrived, the code generation unit 113 of the terminal device 1[q] judges whether the 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 judgment in step S165 is negative, i.e., 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 the processing to step S159 and continues to display the offline code image GY[q] on the display device 13.

[0183] If the result of the judgment in step S165 is positive, i.e., if the terminal time value AG has been updated and the 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).

[0184] 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 advances the process to step S159 to display the updated offline code image GY[q] on the display device 13. Specifically, in step S169, the code generation unit 113 generates the updated offline payment code CY[q] by arranging in a predetermined order 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 allocation value VJ, and the code type value VV.

[0185] As shown in FIG. 16, when the offline code generation process is difficult, such as when the offline is blocked (S151:N) or when a valid offline token KY[q] does not exist in the storage device 12 (S153:N), the display control unit 114 of the terminal device 1[q] causes the display device 13 to display an online payment standby screen (not shown), which is a screen that notifies the user U[q] that the online electronic payment is waiting to be executed (S171).

[0186] Then, the information transmission unit 111 of the terminal device 1[q] determines whether the terminal device 1[q] and the payment device 3 can communicate with each other (S173). Then, the information transmission unit 111 waits until the terminal device 1[q] and the payment device 3 can communicate with each other.

[0187] When the terminal device 1[q] and the payment device 3 become able to communicate with each other (S173: Y), the information transmitting unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S175). Then, when there is no response to the online token request from the payment device 3 (S177: N), the control device 11 of the terminal device 1[q] returns the process to step S175 to resend the online token request. On the other hand, when the communication device 15 receives the online token KX[q] transmitted from the payment device 3 as a response to the online token request (S177: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the online token KX[q] (S179).

[0188] 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, and generates an online payment code CX[q] (S181).

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

[0190] Next, the control device 11 of the terminal device 1[q] determines whether or not the 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 an end operation has been performed, the control device 11 of the terminal device 1[q] ends the series of processes related to the flowcharts shown in FIGS.

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

[0192] If the result of the determination in step S187 is negative, that is, if the opportunity to update the online code image has not arrived, the control device 11 returns the process to step S183 and causes the display device 13 to continue displaying the online code image GX[q]. If the result of the determination in step S187 is positive, that is, if the opportunity to update the online code image has arrived, the information transmitting unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S189).

[0193] Then, when there is no response from the payment device 3 to the online token request in step S189 (S191:N), the control device 11 of the terminal device 1[q] advances the process to step S171. On the other hand, when the communication device 15 receives the online token KX[q] transmitted from the payment device 3 as a response to the online token request in step S189 (S191:Y), the information acquisition unit 112 of the terminal device 1[q] acquires the online token KX[q] (S193) and advances the process to step S181, thereby generating the online payment code CX[q] based on the online token KX[q] acquired in step S193.

[0194] In this way, according to this embodiment, offline electronic payment is performed when online electronic payment is difficult, such as when the online state is blocked (S131:N) or when acquisition of the online token KX[q] fails (S133:N). Therefore, compared to a mode in which the electronic payment system is capable of only online electronic payment, it is possible to reduce the possibility that when a user U[q] of the terminal device 1[q] receives a service at a store where the store device 5 is installed, the user U[q] of the terminal device 1[q] has difficulty in paying the price of the service by electronic payment.

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

[0196] 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 with an aspect where 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, an aspect where 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 becomes difficult to pay the price of the service by electronic settlement can be reduced.

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

[0198] FIG. 18 is a flowchart showing an example of the operation of the settlement device 3 when the online token generation process is executed in the settlement device 3. Here, the online token generation process is a process of generating the 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.

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

[0200] Next, the control device 31 of the settlement 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 starting from the generation of the online token KX[q] and ending at the time when the online token KX[q] is generated, the online token validity period TSX (e.g., 5 minutes) has elapsed.

[0201] Then, the control device 31 of the settlement 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 the user U[q] of the 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.

[0202] Then, the information supply unit 311 of the settlement apparatus 3 supplies the online token KX[q] generated in step S303 to the terminal apparatus 1[q] (S309), and ends the online token generation process.

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

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

[0205] Next, the control device 31 of the settlement 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 starting from the generation of the offline token KY[q] and ending at the time when the offline token KY[q] is generated, the offline token validity period TSY (for example, one week) having elapsed since the generation of the offline token KY[q]. Furthermore, the control device 31 of the settlement device 3 generates an encryption key KS[q] (S327).

[0206] 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 the user U[q] of the 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.

[0207] 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.

[0208] 20 and 21 are flowcharts showing an example of the operation of the payment device 3 when the payment-related process is executed in the payment device 3. Here, the payment-related process includes a process of confirming the validity of the token KK[q] in the payment device 3 and a payment process executed by the payment device 3. When the payment device 3 receives payment information DP[q] from the store device 5, the payment device 3 starts the payment-related process.

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

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

[0211] 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 advances the process to step S361. If the result of the judgment in step S345 is positive, i.e., 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] accepted in step S341 (S347).

[0212] Next, the settlement processing unit 313 of the settlement device 3 determines whether or not 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 advances the process to step S357.

[0213] If the result of the judgment in step S349 is positive, i.e., if the online token KX[q] extracted in step S347 is present in the online token payout information DKX, the payment processing unit 313 of the payment device 3 determines, by referring to the online token payout information DKX, 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 judgment in step S351 is negative, i.e., 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 payment processing unit 313 of the payment device 3 proceeds to step S357.

[0214] If the result of the judgment in step S351 is positive, i.e., if the online token validity period TX[q] corresponding to the online token KX[q] extracted in step S347 includes the current time, the payment processing unit 313 of the payment device 3 executes online payment processing (S353) and confirms the payment from the 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 payment information DP[q] in step S341 is located. Then, the information supply unit 311 of the payment device 3 sends a cash register charging response (S355) to the store where the store device 5 that sent the payment information DP[q] in step S341 is installed, which is a notification that the payment from user U[q] based on the payment information DP[q] has been confirmed, and terminates the payment-related processing.

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

[0216] As shown in FIG. 21, if the result of the judgment in step S345 is negative, i.e., 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] accepted in step S341 (S361).

[0217] Next, the payment processing unit 313 of the payment apparatus 3 determines whether or not 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 payment processing unit 313 of the payment apparatus 3 advances the process to step S381.

[0218] If the result of the judgment in step S363 is positive, i.e., if the offline token KY[q] extracted in step S361 is present in the offline token issuance information DKY, the payment processing unit 313 of the payment device 3 determines, by referring to the offline token issuance information DKY, 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 judgment in step S365 is negative, i.e., 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 payment processing unit 313 of the payment device 3 proceeds to step S381.

[0219] If the result of the judgment in step S365 is positive, 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 payment processing unit 313 of the payment device 3 judges whether or not an offline token KY[q] identical to the offline token KY[q] included in the payment information DP[q] accepted in step S341 has been supplied during the period from a time twice the update unit time TC in the past (for example, two minutes before the present) to the time when the payment information DP[q] was accepted in step S341 (hereinafter sometimes referred to as the "same token prohibition period") (S367). If the result of the judgment in step S367 is positive, i.e., if an offline token KY[q] identical to the offline token KY[q] included in the payment information DP[q] accepted in step S341 has been accepted during the same token prohibition period, the payment processing unit 313 of the payment device 3 proceeds to step S381.

[0220] If the result of the judgment in step S367 is negative, i.e., if an offline token KY[q] identical to the offline token KY[q] included in the payment information DP[q] accepted in step S341 has not been accepted during the same token prohibition period, the payment processing unit 313 of the payment device 3 extracts the time encryption code TT[q] from the offline payment code CY[q] included in the payment information DP[q] accepted in step S341 (S369).

[0221] Moreover, the payment processing unit 313 of the payment apparatus 3 refers to the offline token payout information DKY to identify the encryption key KS[q] corresponding to the offline token KY[q] extracted in step S361 (S371).

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

[0223] Here, the server time value AM is a value based on the server time TM, which is the current time managed in the payment device 3, and is a value updated at a period of the update unit time TC. Specifically, in this embodiment, as an example, it is assumed that the server time value AM is a value that expresses the server time TM in the order of "minutes". For example, in this embodiment, when the server time TM is "18:25:37", the server time value AM may be "1825" by deleting "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 a slight error between the server time TM and the terminal time TG. In this case, the server time value AM may be a different value from the terminal time value AG. Further, the future time value AMf is a value based on a time that is an update unit time TC in the future than the server time TM. Specifically, in this embodiment, as an example, it is assumed that the future time value AMf is a value that represents a time that is an update unit time TC (e.g., one minute) in the future than the server time TM in the order of minutes. For example, if the server time TM is "18:25:37", the future time value AMf may be "1826", which is obtained by deleting "37 seconds" from "18:26:37", a time that is one minute in the future than the server time TM. Furthermore, the past time value AMp is a value based on a time that is an update unit time TC in the past than the server time TM. Specifically, in this embodiment, as an example, it is assumed that the past time value AMp is a value that represents a time that is an update unit time TC (e.g., one minute) in the past than the server time TM in the order of minutes. For example, if the server time TM is "18:25:37", the past time value AMp may be "1824", which is obtained by deleting "37 seconds" from "18:24:37", a time that is one minute in the past than the server time TM.

[0224] In the following, the value obtained by encrypting the server time value AM with the encryption key KS[q] is referred to as the server time encryption code CM (an example of a "first time code"), the value obtained by encrypting the future time value AMf with the encryption key KS[q] is referred to as the future time encryption code CMf (an example of a "second time code"), and the value obtained by encrypting the past time value AMp with the encryption key KS[q] is referred to as the past time encryption code CMp (an example of a "third time code"). 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 a "time code"). That is, in step S373, the payment 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].

[0225] Next, the payment processing unit 313 of the payment 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).

[0226] If the result of the judgment in step S375 is positive, i.e., if the time encryption code CMM generated in step S373 matches the time encryption code TT[q] extracted in step S369, the payment processing unit 313 of the payment device 3 executes offline payment processing (S377) and confirms the payment from the 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 payment information DP[q] in step S341 is located. Then, the information supply unit 311 of the payment device 3 sends a cash register charging response (S379) to the store where the store device 5 that sent the payment information DP[q] in step S341 is installed, which is a notification that the payment from user U[q] based on the payment information DP[q] has been confirmed, and terminates the payment-related processing.

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

[0228] As described above, in this embodiment, the payment device 3 can execute two types of payment processing, online payment processing and offline payment processing. Therefore, for example, compared with an embodiment in which the payment device 3 can execute only online payment processing, the convenience of the user U[q] who uses electronic payment can be improved.

[0229] Also, in this embodiment, when two or more pieces of settlement 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 settlement device 3 restricts the offline settlement process based on the settlement information DP[q] supplied after the second time. Therefore, according to this embodiment, it is possible to restrict unauthorized settlements using the offline token KY[q], and the security risk in the case where the offline token KY[q] is leaked can be reduced.

[0230] Also, in this embodiment, in the settlement-related process, in addition to the server time value AM, the settlement 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 settlement code CY[q]. Therefore, according to this 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 settlement device 3, the user U[q] of the terminal device 1[q] can use offline electronic settlement. As a result, according to this embodiment, for example, in the settlement-related process, 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 settlement can be improved, and the convenience of the user U[q] using electronic settlement can be improved.

[0231] <B. Second Embodiment> Hereinafter, the second embodiment of the present invention will be described with reference 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 appropriately omitted.

[0232] 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] generates an online payment code CX[q] and displays an online code image GX[q] after acquiring an offline token KY[q], but in the electronic payment system Sys according to the second embodiment, when performing online electronic payment, the terminal device 1[q] generates an online payment code CX[q] and displays an online code image GX[q] in priority to acquiring an offline token KY[q].

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

[0234] As described above, in the sequence chart of online electronic payment according to the first embodiment shown in FIG. 4, in the electronic payment system Sys, after the processing of steps S21 to S24 relating to the acquisition of an online token KX[q] by the terminal device 1[q] and the processing of steps S31 to S35 relating to the acquisition of an offline token KY[q] by the terminal device 1[q], the processing of steps S41 to S43 relating to the display of an online code image GX[q] by the terminal device 1[q] is performed. In contrast, the sequence chart of 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 relating to the acquisition of an online token KX[q] by the terminal device 1[q] and the processing of steps S41 to S43 relating to the display of an online code image GX[q] by the terminal device 1[q], the processing of steps S31 to S35 relating to the acquisition of an offline token KY[q] by the terminal device 1[q] is executed.

[0235] That is, in the second embodiment, display of the online code image GX[q] is given priority over acquisition of the offline token KY[q]. Therefore, according to the second embodiment, the time until the online code image GX[q] is displayed is shortened compared to the mode in which the online code image GX[q] is displayed after acquisition of the offline token KY[q], and online electronic payment can be quickly performed. In the second embodiment, the token response waiting period TW may be, for example, a period from the start of the payment application to the end of the payment application, or may be a period including, for example, a period from the start of the payment application to the elapse of the token response waiting time TSW and a period from the start or end of the display of the online code image GX[q] to the elapse of a predetermined time.

[0236] Figures 23 to 27 are flowcharts showing an example of the operation of the terminal device 1[q] when electronic payment is executed in the electronic payment system Sys according to the second embodiment. The flowcharts shown in Figures 23 to 27 are started when a payment application is launched in the 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 processes of steps S115 to S125 are not present and that the processes of steps S201 to S231 are present.

[0237] As shown in FIG. 23, when the payment application is launched in the terminal device 1[q], the control device 11 of the terminal device 1[q] executes the processes of steps S101 to S113 described above. Specifically, the control device 11 of the terminal device 1[q] first judges whether the communication state of the terminal device 1[q] is online (S101). If the result of the judgment in step S101 is negative, the control device 11 of the terminal device 1[q] advances the process to step S151. If the result of the judgment in step S101 is positive, the information transmission unit 111 of the terminal device 1[q] transmits an online blockage information request to the payment device 3 (S103). Then, when the online blockage information DHX is received (S105: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the online blockage information DHX (S107). In addition, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S109). Then, when the 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).

[0238] Next, the control device 11 of the terminal device 1[q] executes the processes of steps S131 to S133 described above. Specifically, the control device 11 of the terminal device 1[q], the code generation unit 113 of the terminal device 1[q], determines whether the payment device 3 is not in an online blocked state (S131). If the result of the determination in step S131 is negative, the control device 11 of the terminal device 1[q] advances the process 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 the terminal device 1[q] advances the process to step S221.

[0239] As shown in FIG. 24, the control device 11 of the terminal device 1[q] executes the processes of steps S135 to S139 described above. Specifically, when 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 an online payment code CX[q] (S135). Then, the display control unit 114 of the terminal device 1[q] causes the display device 13 to display the online code image GX[q] (S137). Next, the control device 11 of the terminal device 1[q] determines whether or not a termination operation has been performed (S139).

[0240] Next, if the result of the determination in step S139 is positive, the control device 11 of the terminal device 1[q] executes the processes of steps S201 to S211. Specifically, the information transmission unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S201). The process of step S201 corresponds to the process of step S31 described above. Then, when there is no response to the offline blockage information request from the payment device 3 (S203:N), the control device 11 of the terminal device 1[q] advances the process to step S207. On the other hand, when 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 the terminal device 1[q] acquires the offline blockage information DHY (S205). Also, the information transmission unit 111 of the terminal device 1[q] transmits an offline token request to the payment device 3 (S207). The process of step S207 corresponds to the process of step S33 described above. Then, when there is no response to the offline token request from the payment device 3 (S209:N), the control device 11 of the terminal device 1[q] ends a series of processes related to the flowcharts shown in Figures 23 to 27. On the other hand, when the communication device 15 receives the offline token KY[q] and the encryption key KS[q] transmitted from the payment device 3 as a response to the offline token request (S209:Y), the information acquisition unit 112 of the terminal device 1[q] stores the offline token KY[q] and the encryption key KS[q] in the storage device 12 (S211), and ends a series of processes related to the flowcharts shown in Figures 23 to 27.

[0241] Furthermore, if the result of the determination in step S139 is negative, the control device 11 of the terminal device 1[q] executes the processes of steps S141 to S147 described above. Specifically, the code generation unit 113 of the terminal device 1[q] judges whether or not an opportunity to update the online code image has arrived (S141). If the result of the judgment 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 judgment in step S141 is positive, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S143). Then, if there is no response to the online token request in step S143 from the payment device 3 (S145:N), the control device 11 of the terminal device 1[q] advances the process to step S151. On the other hand, if the communication device 15 receives the online token KX[q] sent from the payment device 3 in response to the online token request in step S143 (S145:Y), the information acquisition unit 112 of the terminal device 1[q] 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.

[0242] As shown in FIG. 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 of steps S221 to S231. Specifically, the information transmission unit 111 of the terminal device 1[q] transmits an offline blockage information request to the payment device 3 (S221). Then, when there is no response to the offline blockage information request from the payment device 3 (S223: N), the control device 11 of the terminal device 1[q] advances the process to step S227. On the other hand, when 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 (S223: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the offline blockage information DHY (S225). Also, the information transmission unit 111 of the terminal device 1[q] transmits an offline token request to the payment device 3 (S227). Then, when there is no response to the offline token request from the payment device 3 (S229: N), the control device 11 of the terminal device 1[q] advances the process to step S151. On the other hand, when the communication device 15 receives the offline token KY[q] and the encryption key KS[q] sent from the payment device 3 in response to the offline token request (S229:Y), the information acquisition unit 112 of the terminal device 1[q] stores the offline token KY[q] and the encryption key KS[q] in the storage device 12 (S231).

[0243] Next, the control device 11 of the terminal device 1[q] executes the processes of steps S151 to S155 described above. Specifically, the code generation unit 113 of the terminal device 1[q] judges whether the payment device 3 is not in an offline blocked state (S151). If the result of the judgment in step S151 is negative, the control device 11 of the terminal device 1[q] advances the process to step S171. If the result of the judgment in step S151 is positive, the code generation unit 113 of the terminal device 1[q] judges whether the latest offline token KY[q][M] stored in the storage device 12 is valid (S153). If the result of the judgment in step S153 is negative, the control device 11 of the terminal device 1[q] advances the process to step S171. If the result of the judgment in step S153 is positive, 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), and advances the process to step S157.

[0244] 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 generating 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 of step S157 corresponds to the process of 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 of step S159 corresponds to the process of step S54 described above. Next, the control device 11 of the terminal device 1[q] judges whether or not a termination operation has been performed (S161). If the result of the judgment in step S161 is positive, the control device 11 of the terminal device 1[q] terminates a series of processes related to the flowcharts shown in FIG. 23 to FIG. 27. If the result of the judgment in step S161 is negative, the code generating unit 113 of the terminal device 1[q] judges whether or not an offline code image update opportunity has arrived (S163). If the result of the judgment in step S163 is positive, the control device 11 of the terminal device 1[q] advances the process to step S101 and executes again a series of processes according to the flowcharts shown in Figs. 23 to 27. If the result of the judgment in step S163 is negative, the code generation unit 113 of the terminal device 1[q] judges 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 judgment in step S165 is negative, the control device 11 of the terminal device 1[q] returns the process to step S159 and continues to display the offline code image GY[q] on the display device 13. If the result of the judgment in step S165 is positive, 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). 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, thereby displaying the updated offline code image GY[q] on the display device 13.

[0245] As shown in FIG. 27, if the result of the determination in step S151 is negative, or if the result of the determination 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 the terminal device 1[q] causes the display device 13 to display an online payment standby screen (S171). Then, the information transmission unit 111 of the terminal device 1[q] waits until the terminal device 1[q] and the payment device 3 are able to communicate with each other (S173). After that, when the terminal device 1[q] and the payment device 3 are able to communicate with each other, the information transmission unit 111 of the terminal device 1[q] transmits an online token request to the payment device 3 (S175). Then, when the communication device 15 receives the online token KX[q] transmitted from the payment device 3 (S177: Y), the information acquisition unit 112 of the terminal device 1[q] acquires the online token KX[q] (S179). Next, the code generation unit 113 of the 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] judges whether or not a termination operation has been performed (S185). If the result of the judgment in step S185 is positive, the control device 11 of the terminal device 1[q] terminates a series of processes related to the flowcharts shown in Figs. 23 to 27. If the result of the judgment in step S185 is negative, the code generation unit 113 of the terminal device 1[q] judges whether or not an opportunity to update the online code image has arrived (S187). If the result of the judgment 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 judgment 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 there is no response from the payment apparatus 3 to the online token request in step S189 (S191: N), the control device 11 of the terminal device 1[q] advances the process 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 from the payment device 3 as a response to the online token request according to step S189 (S191: Y), it acquires the online token KX[q] (S193), proceeds with the process to step S181, and generates an online payment code CX[q] based on the online token KX[q] acquired in step S193.

[0246] 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 acquiring the offline token KY[q], the time until the online code image GX[q] is displayed is shortened, and rapid execution of online electronic payment becomes possible.

[0247] <C. Modification Example> 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 that does not conflict with each other. In the modification examples exemplified below, for elements whose operations and functions are equivalent to those of the embodiments, the reference numerals referred to in the above description are reused, and the detailed descriptions thereof are appropriately omitted.

[0248] <C.1. Modification Example 1> In the first and second embodiments described above, an example has been described in which the terminal device 1[q] acquires the offline token KY[q] after acquiring the online token KX[q] during electronic payment. 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 payment.

[0249] 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.

[0250] 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. In this regard, it is different from the sequence chart of the online electronic payment according to the first embodiment shown in FIG. 4.

[0251] 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, the possibility that it is even difficult to perform offline electronic payment can be reduced.

[0252] <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.

[0253] 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.

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

[0255] Specifically, as shown in Fig. 29, in this modification, the control device 11 of the terminal device 1[q] executes the process of step S12 and then transmits a blockage information request to the payment device 3 (S71). Here, the blockage information request is a telegram requesting the online blockage information DHX and the offline blockage information DHY. Then, the control device 31 of the settlement device 3 supplies the online blockage information DHX and the offline blockage information DHY to the terminal device 1[q] in response to the blockage information request supplied from the terminal device 1[q] in step S71 (S72).

[0256] Next, the control device 11 of the terminal device 1[q] transmits 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, the control device 31 of the payment device 3 supplies the online token KX[q], the offline token KY[q], and the encryption key KS[q] to the terminal device 1[q] in response to the token request supplied from the terminal device 1[q] in step S73 (S74). After that, the electronic payment system Sys executes the processes of step S35, steps S41 to S44, and steps S61 to S65.

[0257] According to this modification, at the timing when electronic payment is made, an offline token KY[q] is obtained from the payment device 3 and the offline token KY[q] is stored in the storage device 12. Therefore, according to this embodiment, when online electronic payment is difficult due to poor communication or the like, it is possible to reduce the possibility that offline electronic payment will also become difficult to execute.

[0258] <C.3. Variant Example 3> In the above-described first embodiment, second embodiment, and variant examples 1 and 2, the terminal device 1[q] is illustrated and described as an example of a case where, at the time of 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 an aspect. The terminal device 1[q] may transmit an online token request and an online block information request as the same message at the time of electronic payment.

[0259] 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 online electronic payment.

[0260] 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.

[0261] 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, it transmits a payment application start notification 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, in response to the payment app startup notification supplied from the terminal device 1[q] in step S81, the control device 31 of the payment device 3 executes 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.

[0262] According to this modification example, in response to the payment app 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]. Therefore, 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.

[0263] <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. Some 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].

[0264] <C.5. Modification Example 5> In the above-mentioned first and second embodiments and modified examples 1 to 4, the blocking information DH is information indicating whether the payment device 3 can execute the payment process, but the present invention is not limited to such an embodiment. The blocking information DH may be information indicating whether the payment device 3 can execute the payment process by each payment method.

[0265] Specifically, in this modified example, the online blockage information DHX includes online combined payment blockage information DHX1 indicating whether online payment processing by telephone charge combined payment is executable or not, online balance payment blockage information DHX2 indicating whether online payment processing by prepaid balance payment is executable or not, and online card payment blockage information DHX3 indicating whether online payment processing by credit card payment is executable or not. Here, the online combined payment blockage information DHX1 may be information indicating whether the function of the payment device 3 for executing online payment processing by telephone charge combined payment is operating without being blocked. Also, the 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 being blocked. Also, the 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 being blocked. In the following, the online combined payment blockage information DHX1, the online balance payment blockage information DHX2, and the online card payment blockage information DHX3 may be collectively referred to as individual online blockage information DHX0. In addition, in this modification, the offline blockage information DHY includes offline combined payment blockage information DHY1 indicating whether offline payment processing by telephone charge combined payment is executable or not, offline balance payment blockage information DHY2 indicating whether offline payment processing by prepaid balance payment is executable or not, and offline card payment blockage information DHY3 indicating whether offline payment processing by credit card payment is executable or not. Here, the 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 charge combined payment is operating without being blocked. Furthermore, the 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 being blocked. Furthermore, the 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 being blocked. In the following, the offline combined payment blockage information DHY1, the offline balance payment blockage information DHY2, and the offline card payment blockage information DHY3 may be collectively referred to as individual offline blockage information DHY0.

[0266] In this modified example, in response to a request for online blockage information from terminal device 1[q], the payment device 3 may supply to the terminal device 1[q] the individual online blockage information DHX0 corresponding to the payment method selected by user U[q] of terminal device 1[q], from among the three individual online blockage information DHX0 contained in the online blockage information DHX. In addition, in this modification, the payment device 3 may supply the terminal device 1[q] with the individual offline blockage information DHY0 corresponding to the payment method selected by the user U[q] of the terminal device 1[q], among the three individual offline blockage information DHY0 included in the offline blockage information DHY, in response to an offline blockage information request from the terminal device 1[q]. In this modification, the payment device 3 may supply the terminal device 1[q] with the three individual offline blockage information DHY0 included in the offline blockage information DHY in response to an offline blockage information request from the terminal device 1[q].

[0267] In the above-mentioned first and second embodiments and modified examples 1 to 4, the payment device 3 supplies 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], but the present invention is not limited to such an embodiment. 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 to one or more payment methods selectable by the user U[q] of the terminal device 1[q].

[0268] Specifically, in this modification, the payment device 3 supplies the terminal device 1[q] with an offline token KY1[q] for combined payment, which is an offline token KY[q] corresponding to combined payment for telephone charges, an offline token KY2[q] for balance payment, which is an offline token KY[q] corresponding to prepaid balance payment, and an offline token KY3[q] for card payment, which is an offline token KY[q] corresponding to credit card payment, in response to an offline token request from the terminal device 1[q]. In the following, the offline token KY1[q] for combined payment, the offline token KY2[q] for balance payment, and the offline token KY3[q] for card payment may be collectively referred to as individual offline token KY0[q]. In other words, in this modification, the payment device 3 supplies the terminal device 1[q] with three individual offline tokens KY0[q] corresponding one-to-one to the three types of payment methods that can be selected by the user U[q] of the terminal device 1[q], in response to an offline token request from the terminal device 1[q].

[0269] In this modified example, the code generating 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 the user U[q] of the terminal device 1[q]. Specifically, in this modified example, the code generating unit 113 of the terminal device 1[q] generates an offline payment code CY[q] based on the offline token KY1[q] for combined payment when the payment method selected by the user U[q] of the terminal device 1[q] is combined payment with telephone charges, generates an offline payment code CY[q] based on the offline token KY2[q] for balance payment when the payment method selected by the user U[q] of the terminal device 1[q] is prepaid balance payment, and generates an offline payment code CY[q] based on the offline token KY3[q] for card payment when the payment method selected by the user U[q] of the terminal device 1[q] is credit card payment.

[0270] In addition, in this modified example, the display control unit 114 of the terminal device 1[q] determines, on the display device 13, whether or not to display an offline code image GY[q] based on an individual offline token KY0[q] corresponding to the payment method selected by the user U[q] of the terminal device 1[q], based on the individual offline blockage information DHY0 corresponding to the payment method selected by the user U[q] of the terminal device 1[q]. Specifically, in this modified example, when the payment method selected by user U[q] of terminal device 1[q] is combined telephone bill payment, a decision is made based on the offline combined payment blockage information DHY1 as to whether or not to display an offline code image GY[q] based on the offline token KY1[q] for combined payment; when the payment method selected by user U[q] of terminal device 1[q] is prepaid balance payment, a decision is made based on the offline balance payment blockage information DHY2 as to whether or not to display an offline code image GY[q] based on the offline token KY2[q] for balance payment; and when the payment method selected by user U[q] of terminal device 1[q] is credit card payment, a decision is made based on the offline card payment blockage information DHY3 as to whether or not to display an offline code image GY[q] based on the offline token KY3[q] for card payment.

[0271] Note that, in this modified example, the settlement device 3 may supply three online tokens KX[q] to the terminal device 1[q], which correspond one-to-one to three types of payment methods that the user U[q] of the terminal device 1[q] can select. Further, in this modified example, the settlement device 3 may supply one online token KX[q] to the terminal device 1[q], which corresponds to one payment method selected by the user U[q] of the terminal device 1[q] among the three online tokens KX[q] that correspond one-to-one to the three types of payment methods that the user U[q] of the terminal device 1[q] can select.

[0272] As described above, according to this modified 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 the mode that does not consider the payment method.

[0273] <C.6. Modified Example 6> In the above-described first embodiment, second embodiment, and modified examples 1 to 5, the case where the blockage information DH is supplied from the settlement device 3 has been exemplified and described, but the present invention is not limited to such a mode. A mode in which the blockage information DH is not supplied from the settlement device 3 to the terminal device 1[q] may be employed.

[0274] FIG. 31 is a sequence chart showing an example of the operation of the electronic settlement system Sys when the electronic settlement system Sys according to the modified example 6 executes online electronic settlement.

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

[0276] 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].

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

[0278] <D.1. Supplementary Note 1> The following explains Supplementary Note 1.

[0279] <Supplementary Note 1-1> The electronic payment program PG-T according to Appendix 1-1 is an electronic payment program PG-T installed in a terminal device 1[q], and controls a processor of the terminal device 1[q] to include an information transmission unit 111 that transmits a request for two types of tokens KK[q], an online token KX[q] and an offline token KY[q], during a 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 the token KK[q] supplied in response to the transmission of the request from the information transmission unit 111, and a display control unit 113 that displays a code image GG[q] based on the token KK[q] on a display device 13. The display control unit 114 functions as an information acquisition unit 112 and, 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. 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 addition, in Appendix 1, the token response waiting time TSW is an example of a “first time”, the token response waiting period TW is an example of a “first period”, the online token KX[q] is an example of a “first token”, and the offline token KY[q] is an example of a “second token”.

[0280] According to Supplementary Note 1-1, at the timing 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, so there is no need to execute a process to acquire the offline token KY[q] separately from the timing of electronic payment. Therefore, there is no need to adjust the execution timing of the process to acquire the offline token KY[q] separately from the timing 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 memory device 12, making it possible to make electronic payments regardless of the communication state.

[0281] In addition, in Supplementary Note 1-1, the "request 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] separately from a request for an online token KX[q]. In this case, the information acquisition unit 112 may acquire the online token KX[q] provided in response to the request for the online token KX[q], and may acquire the offline token KY[q] provided in response to the request for the offline token KY[q]. In addition, in Supplementary Note 1-1, the "request for two types of tokens KK[q]" may mean that the terminal device 1[q] makes a single request, for example, a request for a token KK[q], or a payment application startup notification. In this case, the information acquisition unit 112 may acquire the online token KX[q] and the offline token KY[q] provided in response to the request for the token KK[q], or the payment application startup notification.

[0282] <Appendix 1-2> The electronic payment program PG-T according to Supplementary Note 1-2 is an electronic payment program PG-T installed in a terminal device 1[q], and controls a processor of the terminal device 1[q] to include an information transmitting unit 111 that transmits a request for two types of tokens KK[q], an online token KX[q] and an offline token KY[q], during a 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 acquiring unit 112 that acquires the token KK[q] supplied in response to the transmission of the request from the information transmitting unit 111, and a display unit 113 that displays a code image GG[q] based on the token KK[q] on a display device 13. The display control unit 114 functions as a display control unit, and 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. When the communication state of the terminal device 1[q] is offline 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 Supplementary Note 1-2, at the timing 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, so there is no need to execute a process to acquire the offline token KY[q] separately from the timing of electronic payment. Therefore, there is no need to adjust the execution timing of the process to acquire the offline token KY[q] separately from the timing of electronic payment. In addition, according to Appendix 1-2, even if the communication state 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 memory device 12, making it possible to make electronic payments regardless of the communication state.

[0284] <Appendix 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, and is characterized in that, when the communication state of the terminal device 1[q] is online during the token response waiting period TW and the information acquisition unit 112 does not acquire the token KK[q] during the token response waiting period TW, the display control unit 114 displays, on the display device 13, a code image GG[q] based on the offline token KY[q] stored in the memory device 12.

[0285] 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 memory device 12, making it possible to make electronic payments regardless of the communication state.

[0286] <Appendix 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, wherein the information acquisition unit 112 acquires an online token KX[q] and an offline token KY[q] from the payment device 3, and the online token KX[q] is a token KK[q] used in the payment device 3 to decide whether to execute a payment process corresponding to user U[q] of terminal device 1[q] when the terminal device 1[q] is in a state where it can 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 execute a payment process corresponding to user U[q] of terminal device 1[q] when the terminal device 1[q] is in a state where it cannot communicate with the payment device 3.

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

[0288] <Appendix 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, and is 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, and acquires token response information DSW indicating a token response waiting time TSW from the payment device 3. In addition, in Supplementary Note 1, the token response information DSW is an example of "time information".

[0289] According to Supplementary Note 1-5, the payment device 3 is able to adjust the token response waiting time TSW, making it possible to dynamically switch the display mode of the code image GG[q] depending on the situation of the terminal device 1[q].

[0290] <Appendix 1-6> The electronic payment program PG-T of Appendix 1-6 is the electronic payment program PG-T described in Appendix 1-1 to Appendix 1-5, and is characterized in that the information sending 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 addition, in Supplementary 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".

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

[0292] <Appendix 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, and is 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.

[0293] According to Supplementary Note 1-7, it is possible to shorten the time until the code image GG[q] is displayed, compared to a mode in which the code image GG[q] is displayed based on the offline token KY[q] last acquired during the token response waiting period TW.

[0294] <Appendix 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 by 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 by 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].

[0295] 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 acquisition timing of the offline token KY[q] separately from the acquisition timing of the online token KX[q]. Therefore, according to Supplementary Note 1-8, it is 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 is possible even when the communication state in the terminal device 1[q] deteriorates and online electronic settlement becomes difficult.

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

[0297] <Supplementary Note 2-1> The electronic payment program PG-T relating to Appendix 2-1 is characterized in that it causes the processor of a terminal device 1[q] capable of communicating with the payment device 3 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 blockage information DHY indicating whether the 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 is capable of executing offline payment processing.

[0298] According to supplementary note 2-1, when the offline blockage information DHY indicates that the payment device 3 is capable of executing the offline payment process, the terminal device 1[q] displays the offline code image GY[q]. In other words, according to supplementary note 2-1, when the payment device 3 has difficulty executing the offline payment process, the display of the offline code image GY[q] on the terminal device 1[q] can be suppressed. Therefore, compared to a mode in which the terminal device 1[q] displays the offline code image GY[q] even when the payment device 3 has difficulty executing the offline payment process, it is possible to reduce the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q].

[0299] In addition, the electronic payment program PG-T relating to Appendix 2-1 may be characterized in that it causes the processor of the terminal device 1[q] capable of communicating with the payment device 3 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 blockage information DHY indicating whether or not the 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 blockage information DHY indicates that the payment device 3 is capable of executing the offline payment processing. In addition, the electronic payment program PG-T according to Appendix 2-1 controls a processor of a terminal device 1[q] capable of communicating with the payment device 3 to receive an online token KX[q] used for online payment processing executed in the payment device 3 when the payment device 3 and the terminal device 1[q] are able to communicate with each other, an offline token KY[q] used for offline payment processing executed in the payment device 3 when it is difficult for the payment device 3 to communicate with the terminal device 1[q], online blockage information DHX indicating whether online payment processing can be executed in the payment device 3, and offline blockage information DHX indicating whether offline payment processing can be executed in the payment device 3. The system may also function as an information acquisition unit 112 that acquires information DHY from the payment device 3, and a display control unit 114 that displays an online code image GX[q] based on the online token KX[q] on the display device 13 when the online blockage information DHX indicates that the payment device 3 is capable of performing online payment processing, and 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 perform online payment processing and the offline blockage information DHY indicates that the payment device 3 is capable of performing offline payment processing.

[0300] <Appendix 2-2> The electronic payment program PG-T according to Appendix 2-2 is the electronic payment program PG-T described in Appendix 2-1, characterized in that, when the offline blockage information DHY indicates that the payment device 3 is unable to execute offline payment processing, the information acquisition unit 112 waits until the payment device 3 and the terminal device 1[q] become able to communicate, and when the payment device 3 and the terminal device 1[q] become able to communicate, acquires from the payment device 3 an online token KX[q] used for the online payment processing executed in the payment device 3 when the payment device 3 and the terminal device 1[q] are able to communicate, and the display control unit 114, when the information acquisition unit 112 acquires the online token KX[q], causes the display device 13 to display an online code image GX[q] based on the online token KX[q].

[0301] According to Appendix 2-2, when the payment device 3 has difficulty in performing offline payment processing, the terminal device 1[q] displays an online code image GX[q] corresponding to the online payment processing, so that a type of electronic payment can be performed according to the operating status of the payment device 3.

[0302] <Appendix 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, characterized in that the payment device 3 is capable of offline payment processing using one or more payment methods including one payment method, the offline blockage information DHY indicates whether offline payment processing can be executed using 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 the one or more payment methods from the payment device 3, and the display control unit 114, when the offline blockage information DHY indicates that the payment device 3 is capable of executing offline payment processing using the one payment method, displays on the display device 13 an offline code image GY[q] based on one individual offline token KY0[q] used for the one payment method, among the one or more individual offline tokens KY0[q]. In addition, in Appendix 2, one payment method is an example of a "first payment method", an individual offline token KY0[q] is an example of an "offline token", and one individual offline token KY0[q] is an example of a "first offline token".

[0303] According to Supplementary Note 2-3, when the offline blockage 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 the one payment method. In other words, according to Supplementary Note 2-3, when the payment device 3 has difficulty performing offline payment 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 the payment device 3 has difficulty performing 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 a mode in which the terminal device 1[q] displays the offline code image GY[q] corresponding to the one payment method.

[0304] <Appendix 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 the one or more payment methods that the payment device 3 can support when the payment device 3 executes offline payment processing include other payment methods different from the one payment method, and the display control unit 114 restricts the display of the offline code image GY[q] based on other individual offline tokens KY0[q] corresponding to the other payment methods, among the one or more individual offline tokens KY0[q], on the display device 13 when the offline blockage information DHY indicates that the payment device 3 has difficulty executing offline payment processing using the other payment method. In addition, in Supplementary Note 2, the other payment method is an example of a "second payment method", and the other individual offline token KY0[q] is an example of a "second offline token".

[0305] According to Supplementary Note 2-4, when the offline blockage information DHY indicates that the payment device 3 has difficulty in executing 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 methods. Therefore, even when the payment device 3 has difficulty in executing offline payment processing using other payment methods, it is possible to reduce the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q], compared to a mode in which the terminal device 1[q] displays the offline code image GY[q] corresponding to the other payment methods.

[0306] <Appendix 2-5> The electronic payment program PG-T of Appendix 2-5 is the electronic payment program PG-T described in Appendix 2-1 to Appendix 2-4, characterized in that an offline token validity period TY[q] is set for the offline token KY[q], and the display control unit 114 displays an offline code image GY[q] based on the offline token KY[q] on the display device 13 when it is within the offline token validity period TY[q] of the offline token KY[q]. In addition, in Supplementary Note 2, the offline token validity period TY[q] is an example of a “validity period”.

[0307] According to Supplementary Note 2-5, when the terminal device 1[q] has an offline token KY[q] within the validity period, the terminal device 1[q] displays an offline code image GY[q] based on the offline token KY[q]. In other words, when the terminal device 1[q] does not have an offline token KY[q] within the validity period, the terminal device 1[q] can restrict the display of the offline code image GY[q] based on the offline token KY[q]. Therefore, even when the terminal device 1[q] does not have an offline token KY[q] within the validity period, it is possible to reduce the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q], compared to the mode of displaying the offline code image GY[q] based on the offline token KY[q].

[0308] <Appendix 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 regarding the offline token validity period TY[q] corresponding to the offline token KY[q], and the display control unit 114 displays an 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 time TSY, which is the time length of the offline token validity period TY[q]. In addition, in Supplementary Note 2, the offline token validity information DSY is an example of "token validity information", and the offline token validity time TSY is an example of "length of validity period".

[0309] According to Appendix 2-6, even if a user does not have an offline token KY[q] within the valid period, the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q] can be reduced compared to the display of an offline code image GY[q] based on the offline token KY[q].

[0310] <Appendix 2-7> The electronic payment program PG-T relating to Appendix 2-7 is characterized in that it causes the processor of the terminal device 1[q] capable of communicating with the payment device 3 to function 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 blockage information DH indicating whether the 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 blockage information DH indicates that the payment device 3 is capable of executing the payment processing.

[0311] According to Supplementary Note 2-7, when the blockage information DH indicates that the payment device 3 is able to execute the payment process, the terminal device 1[q] displays the code image GG[q]. In other words, according to Supplementary Note 2-7, when the payment device 3 has difficulty executing the payment process, the display of the code image GG[q] on the terminal device 1[q] can be suppressed. Therefore, compared to the mode in which the terminal device 1[q] displays the code image GG[q] even when the payment device 3 has difficulty executing the payment process, it is possible to reduce the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q].

[0312] <Appendix 2-8> The payment device 3 of Appendix 2-8 is a payment device 3 capable of communicating with a terminal device 1[q], and is equipped with a payment processing unit 313 that executes offline payment processing when communication between the terminal device 1[q] and the payment device 3 is difficult, and an information supply unit 311 that supplies the terminal device 1[q] with offline blockage information DHY indicating whether or not offline payment processing can be executed in the payment processing unit 313, and an offline token KY[q] used for the offline payment processing, and is characterized in that the terminal device 1[q] is capable of displaying an offline code image GY[q] based on the offline token KY[q] when the offline blockage information DHY indicates that the payment device 3 is capable of executing offline payment processing.

[0313] According to Supplementary Note 2-8, the payment device 3 supplies the terminal device 1[q] with offline blockage information DHY indicating whether the offline payment process can be executed in the payment device 3, so that when the payment device 3 has difficulty executing the offline payment process, the display of the offline code image GY[q] in the terminal device 1[q] can be suppressed. Therefore, compared to a mode in which the terminal device 1[q] displays the offline code image GY[q] even when the payment device 3 has difficulty executing the offline payment process, it is possible to reduce the possibility of causing unnecessary trouble to the user U[q] of the terminal device 1[q].

[0314] <Appendix 2-9> The payment device 3 according to Supplementary Note 2-9 is the payment device 3 described in Supplementary Note 2-8. The payment processing unit 313 is capable of performing offline payment 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 payment processing using each of the plurality of payment methods can be executed, which is characterized by this.

[0315] According to Supplementary Note 2-9, when it is difficult for the payment device 3 to execute offline payment 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. For this reason, even when it is difficult for the payment device 3 to execute offline payment 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.

[0316] <Supplementary Note 2-10> The payment device 3 according to Supplementary Note 2-10 is the payment 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 characterized by this.

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

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

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

[0320] According to Addendum 3-1, the time encryption code TT[q] is determined based on the terminal time TG, and therefore the update period of the time encryption code TT[q] can be shorter than the update period of the offline token KY[q]. Therefore, according to Addendum 3-1, the security of electronic payment using the offline code image GY[q] can be improved compared to a mode in which the offline code image GY[q] is generated based only on the offline token KY[q]. In addition, in Appendix 3-1, the offline code image GY[q] is displayed based on the operator identification token KZ in addition to the offline token KY[q], thereby improving the security of electronic payment using the offline code image GY[q] compared to a configuration in which the offline code image GY[q] is displayed based only on the offline token KY[q].

[0321] <Appendix 3-2> The electronic payment program PG-T of 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]. In addition, in Supplementary Note 3, the update unit time TC is an example of a "unit time".

[0322] According to Supplementary Note 3-2, the offline code image GY[q] is displayed using a time encryption code TT[q] that is updated at a period shorter than the validity period of the offline token KY[q]. Therefore, according to Supplementary Note 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 at each update unit time TC, and the security of electronic payment using the offline code image GY[q] can be improved.

[0323] <Appendix 3-3> The electronic payment program PG-T according 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) the 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 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.

[0324] According to Supplementary Note 3-2, since the offline code image GY[q] can be updated every update unit time TC, the security of electronic payment using the offline code image GY[q] can be improved.

[0325] <Appendix 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, and is characterized in that the information acquisition unit 112 acquires update time information DSC indicating the update unit time TC from the payment device 3. In addition, in Supplementary Note 3, the update time information DSC is an example of "time information".

[0326] According to Supplementary Note 3-4, the update cycle of the offline code image GY[q] can be adjusted by the payment device 3, which enables flexible operation regarding the security of electronic payment.

[0327] <Appendix 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 an online token KX[q] associated with a user U[q] of the terminal device 1[q] from the payment device 3, and the display control unit 114 displays an 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 an online code image GX[q] based on the online token KX[q] and the business identification token KZ on the display device 13 when communication between the terminal device 1[q] and the payment device 3 is possible. In addition, in Appendix 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”.

[0328] According to Supplementary Note 3-5, the offline code image GY[q] displayed during offline electronic payment is different from the online code image GX[q] displayed during online electronic payment. Therefore, in this embodiment, from the viewpoint of security of electronic payment, flexible operation is possible taking into account the characteristics of both offline and online electronic payment.

[0329] <Appendix 3-6> The electronic payment program PG-T of 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 the same as the sum of the number of digits LY of the offline token KY[q] and the number of digits LZ of the operator identification token KZ.

[0330] According to Appendix 3-6, the number of digits of the token contained in the offline code image GY[q] displayed during offline electronic payment is the same as the number of digits of the token contained in the online code image GX[q] displayed during online electronic payment, thereby simplifying processing in the terminal device 1[q] compared to a configuration in which the number of digits of the two is different.

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

[0332] According to Appendix 3-7, the number of digits of the offline payment code CY[q] indicated by the offline code image GY[q] displayed during offline electronic payment is 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. This makes it possible to simplify processing in the in-store device 5 that reads the code image GG[q] (online code image GX[q] or offline code image GY[q]) compared to a case in which the number of digits of the two is different, and also makes it possible to simplify processing in the payment device 3 that executes processing related to electronic payment based on the payment code CC[q] (online payment code CX[q] or offline payment code CY[q]).

[0333] <Appendix 3-8> The terminal device 1[q] according to Appendix 3-8 is a terminal device 1[q] capable of communicating with the payment device 3, and is characterized in that it comprises an information acquisition unit 112 that acquires from the payment device 3 an offline token KY[q] and an encryption key KS[q] associated with a user U[q] of the terminal device 1[q], and a display control unit 114 that causes the display device 13 to display an offline code image GY[q] based on the offline token KY[q], a business identification token KZ that identifies the payment business related to the payment device 3, and a time encryption code TT[q] obtained by encrypting a terminal time value AG based on a terminal time TG, which is the current time of the terminal device 1[q], with the encryption key KS[q].

[0334] According to Appendix 3-8, the time encryption code TT[q] is determined based on the terminal time TG, and can be made shorter than the update period of the offline token KY[q]. This improves the security of electronic payments using the offline code image GY[q] compared to a configuration in which the offline code image GY[q] is generated based only on the offline token KY[q].

[0335] <Appendix 3-9> The payment device 3 according to Supplementary Note 3-9 is a payment device 3 capable of communicating with a terminal device 1[q], and includes an information supply unit 311 that supplies the terminal device 1[q] with an offline token KY[q] associated with a user U[q] of the terminal device 1[q] and an encryption key KS[q] associated with the offline token KY[q] among a plurality of encryption keys KS, and an offline code image GY[q] displayed on the terminal device 1[q], the offline token KY[q], a business operator 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 of the terminal device 1[q], which is updated every update unit time TC, using the encryption key KS[q], and receives one payment information DP[q] including the offline token KY[q] and the time encryption code TT[q] from a store device 5 that has read the offline code image GY[q] based on the offline token KY[q], and a payment processing unit 313 that executes a payment process corresponding to a user U[q] of the terminal device 1[q] when any of three time encryption codes CMM matches the time encryption code TT[q] indicated by the one payment information DP[q]: a server time encryption code CM obtained by encrypting a server time value AM based on a server time TM managed by the payment device 3 using an encryption key KS[q] identified from among multiple encryption keys KS based on the offline token KY[q] included in the one payment information DP[q]; a future time encryption code CMf obtained by encrypting a future time value AMf based on a time that is the update unit time TC future than the server time TM using the encryption key KS[q]; and a past time encryption code CMp obtained by encrypting a past time value AMp based on a time that is the update unit time TC past the server time TM using the encryption key KS[q]. In addition, in Appendix 3, the server time encryption code CM is an example of a "first time code," the future time encryption code CMf is an example of a "second time code," the past time encryption code CMp is an example of a "third time code," and the time encryption code CMM is an example of a "time code."

[0336] According to Appendix 3-9, the time encryption code TT[q] is determined based on the terminal time TG, and can be made shorter than the update period of the offline token KY[q]. This improves the security of electronic payments using the offline code image GY[q] compared to a configuration in which the offline code image GY[q] is generated based only on the offline token KY[q].

[0337] <Appendix 3-10> The payment device 3 of Appendix 3-10 is the payment device 3 described in Appendix 3-9, characterized in that when the payment processing unit 313 receives other payment 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 payment information DP[q] to when twice the update unit time TC has elapsed, the payment processing unit 313 does not execute payment processing based on the other payment information DP[q].

[0338] According to Supplementary Note 3-10, the execution of payment processing based on other payment information DP[q] is restricted, so that the possibility of fraudulent electronic payments being made can be reduced compared to an embodiment where no restrictions are placed.

[0339] <Appendix 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 operator identification token KZ that identifies the settlement operator 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 process 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 process based on the other settlement information DP[q] when the information reception unit 312 receives the other settlement information DP[q] including the offline token KY[q] and the time encryption code TT[q] during the same token prohibition period until the time twice the update unit time TC has elapsed since the information reception unit 312 received the single settlement information DP[q].

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

[0341] <D.4. Supplementary Note 4> The following describes Supplementary Note 4.

[0342] <Supplementary Note 4-1> The electronic payment program PG-T relating to Appendix 4-1 is characterized in that it causes the processor of the terminal device 1[q] to function as an information acquisition unit 112 that acquires a token KK[q] (online token KX[q] or offline token KY[q]) associated with a user U[q] of the terminal device 1[q] and a business operator identification token KZ from the payment device 3 at different times, 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 addition, in Appendix 4, the token KK[q] is an example of a "first token", the operator identification token KZ is an example of a "second token", and the offline code image GY[q] is an example of a "code image".

[0343] According to Supplementary Note 4-1, in addition to the token KK[q], the code image GG[q] is displayed based on the business identification token KZ acquired at a timing different from the token KK[q]. Therefore, according to Supplementary Note 4-1, the security of electronic payment using the code image GG[q] can be improved compared to the mode in which the code image GG[q] is generated based only on the token KK[q].

[0344] <Appendix 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 with which the information acquisition unit 112 acquires the token KK[q] from the payment device 3 is higher than the frequency with which the information acquisition unit 112 acquires the business identification token KZ from the payment device 3.

[0345] According to Appendix 4-2, the security of electronic payments can be improved compared to a case in which the token KK[q] and the carrier identification token KZ are obtained with the same frequency.

[0346] <Appendix 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, and is characterized in that, when the information acquisition unit 112 acquires a token KK[q] from the payment device 3 at multiple different times and acquires a carrier identification token KZ from the payment device 3 at multiple different times, 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 carrier identification token KZ among the multiple carrier identification tokens KZ acquired by the information acquisition unit 112.

[0347] According to supplementary note 4-3, even if one or both of the token KK[q] and the business identification token KZ are leaked from the terminal device 1[q], the code image GG[q] is displayed using the latest token KK[q] and the latest business identification token KZ acquired after that. Therefore, according to supplementary note 4-3, the security of electronic payment can be improved compared to a mode in which the token KK[q] and the business identification token KZ are not updated.

[0348] <Appendix 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 identification token KZ includes business identification information DKZ that identifies the payment business operator that manages the payment device 3.

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

[0350] <Appendix 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 started for the first time, 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.

[0351] According to Supplementary Note 4-5, even when the merchant identification information DKZ for identifying the payment merchant changes, it is possible to perform electronic payment using the terminal device 1[q] simply 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.

[0352] <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.

[0353] <E. Others> (1) In the above-described embodiment (including modified examples, the same applies below), storage device 12 and storage device 32 are exemplified by ROM and RAM, but may be a flexible disk, a magneto-optical disk (e.g., a compact disk, a digital versatile disk, a Blu-ray (registered trademark) disk), a smart card, a flash memory device (e.g., a card, a stick, a key drive), a CD-ROM (Compact Disc-ROM), a register, a removable disk, a hard disk, a floppy (registered trademark) disk, a magnetic strip, a database, a server, or any other suitable storage medium. The program may also be transmitted from a network via a telecommunications line. The program may also be transmitted from a communications network NET via a telecommunications line.

[0354] (2) In the above-described embodiments, the described information, signals, etc. may be represented using any of a variety of different technologies. For example, data, instructions, commands, information, signals, bits, symbols, chips, etc. that may be referred to throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or magnetic particles, optical fields or photons, or any combination thereof.

[0355] (3) In the above-described embodiment, the input / output information, etc. may be stored in a specific location (e.g., memory) or may be managed using a management table. The input / output information, etc. may be overwritten, updated, or added. The output information, etc. may be deleted. The input information, etc. may be transmitted to another device.

[0356] (4) In the above-described embodiments, the determination may be made based on a value represented using one bit (0 or 1), a Boolean value (true or false), or a numerical comparison (e.g., comparison with a predetermined value).

[0357] (5) The order of the process steps, sequences, flow charts, etc. illustrated in the above-described embodiments may be changed without causing any inconsistency. For example, the methods described in this disclosure present elements of various steps using an example order, and are not limited to the particular order presented.

[0358] (6) Each function illustrated in Figures 2 and 3 is realized by any combination of at least one of hardware and software. Furthermore, the method of realizing each functional block is not particularly limited. That is, each functional block may be realized by using one device that is physically or logically combined, or may be realized by using two or more devices that are physically or logically separated and directly or indirectly connected (for example, by using wires, wirelessly, etc.). The functional block may be realized by combining the one device or the multiple devices with software.

[0359] (7) The programs exemplified in the above-described embodiments 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., regardless of whether they are called software, firmware, middleware, microcode, hardware description language, or by other names.

[0360] Additionally, software, instructions, information, etc. may be transmitted or received over a transmission medium. For example, if the software is transmitted from a website, server, or other remote source using wired and / or wireless technologies (such as coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL)), and / or wireless technologies (such as infrared, microwave, etc.), then these wired and / or wireless technologies are included within the definition of transmission media.

[0361] (8) In each of the above embodiments, the terms “system” and “network” are used interchangeably.

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

[0363] (10) In the above-described embodiment, the terminal device 1[q] may be a mobile station (MS). A mobile station may be referred to by those skilled in the art as a subscriber station, a mobile unit, a subscriber unit, a wireless unit, a remote unit, a mobile device, a wireless device, a wireless communication device, a remote device, a mobile subscriber station, an access terminal, a mobile terminal, a wireless terminal, a remote terminal, a handset, a user agent, a mobile client, a client, or some other suitable term. In the present disclosure, the terms "mobile station", "user terminal", "user equipment (UE)", "terminal", etc. may be used interchangeably.

[0364] (11) In the above-mentioned embodiments, the terms "connected" and "coupled" or any variation thereof refer to 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" to 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, "connected" may be read with "access". As used in this disclosure, two elements may be considered to be "connected" or "coupled" to each other using at least one of one or more wires, cables, and printed electrical connections, as well as electromagnetic energy having wavelengths in the radio frequency range, microwave range, and light (both visible and invisible) range, as some non-limiting and non-exhaustive examples.

[0365] (12) In the above embodiments, the phrase "based on" does not mean "based only on," unless otherwise specified. In other words, the phrase "based on" means both "based only on" and "based at least on."

[0366] (13) The terms "determining" and "determining" as used in this disclosure may encompass a wide variety of actions. "Determining" and "determining" may include, for example, judging, calculating, computing, processing, deriving, investigating, looking up, search, inquiry (e.g., searching in a table, database, or other data structure), ascertaining, and the like. Also, "determining" and "determining" may include receiving (e.g., receiving information), transmitting (e.g., sending information), input, output, accessing (e.g., accessing data in a memory), and the like. In addition, "judgment" and "decision" can include considering resolving, selecting, choosing, establishing, comparing, etc., to be a "judgment" or "decision." In other words, "judgment" and "decision" can include considering some action to be a "judgment" or "decision." In addition, "judgment" can be interpreted as "assuming," "expecting," "considering," etc.

[0367] (14) In the above embodiments, when "include," "including," and variations thereof are used, these terms are intended to be inclusive, similar to the term "comprising." Furthermore, the term "or" used in this disclosure is not intended to be an exclusive or.

[0368] (15) In this disclosure, where articles have been added by translation, such as a, an, and the in English, the disclosure may include that the nouns following these articles are in the plural.

[0369] (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 "combined" may also be interpreted in the same way as "different."

[0370] (17) Each aspect / embodiment described in this disclosure may be used alone, in combination, or switched according to execution. In addition, notification of specific information (e.g., notification that "X is the case") is not limited to explicit notification, but may be implicit (e.g., not notifying the specific information).

[0371] Although the present disclosure has been described in detail above, it is clear to those skilled in the art that the present disclosure is not limited to the embodiments described in the present disclosure. The present disclosure can be implemented as modified and altered forms without departing from the spirit and scope of the present disclosure as defined by the claims. Therefore, the description of the present disclosure is for illustrative purposes only and does not have any limiting meaning on the present disclosure. [Explanation of symbols]

[0372] 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. An electronic payment program installed on a terminal, A processor of the terminal, a request unit that requests two types of tokens, a first token and a second token, during a first period from when the electronic payment program is started until a first time has elapsed; an acquisition unit that acquires a token provided in response to a request from the request unit; a display control unit that causes a display device to display a code image based on the token; and make it work. The acquisition unit is When the second token is acquired, the second token is stored in a storage device; The display control unit is When the acquisition unit acquires the first token during the first period, displaying a code image based on the first token on a display device; In a case where the acquisition unit has acquired the second token in a period prior to the first period and stored the acquired second token in the storage device, If the acquisition unit does not acquire the token during the first period, displaying on the display device a code image based on the second token stored in the storage device; The request unit is In the first period, after issuing a first token request to request the first token, issuing a second token request requesting the second token; An electronic payment program comprising:

2. An electronic payment program installed on a terminal, A processor of the terminal, a request unit that requests two types of tokens, a first token and a second token, during a first period from when the electronic payment program is started until a first time has elapsed; an acquisition unit that acquires a token provided in response to a request from the request unit; a display control unit that causes a display device to display a code image based on the token; and make it work. The acquisition unit is When the second token is acquired, the second token is stored in a storage device; The display control unit is When the acquisition unit acquires the first token during the first period, displaying a code image based on the first token on a display device; In a case where the acquisition unit has acquired the second token in a period prior to the first period and stored the acquired second token in the storage device, In the first period, if the communication state of the terminal is offline, displaying on the display device a code image based on the second token stored in the storage device; The request unit is In the first period, after issuing a first token request to request the first token, issuing a second token request requesting the second token; An electronic payment program comprising:

3. The display control unit is In a case where the acquisition unit has acquired the second token in a period prior to the first period and stored the acquired second token in the storage device, In the first period, when the communication state of the terminal is an online state and the acquisition unit does not acquire the token, displaying on the display device a code image based on the second token stored in the storage device; 3. The electronic payment program according to claim 2.

4. The acquisition unit is Obtaining the first token and the second token from a payment device; The first token is When the terminal is capable of communicating with the payment device, an online token used in the payment device to determine whether or not to execute a payment process corresponding to a user of the terminal; The second token is When the terminal cannot communicate with the payment device, An offline token used in the payment device to determine whether or not to execute a payment process corresponding to a user of the terminal.

3. The electronic payment program according to claim 1 or 2.

5. The acquisition unit is Obtaining the first token and the second token from a payment device; acquiring time information indicating the first time from the payment device; 3. The electronic payment program according to claim 1 or 2.

6. The acquisition unit is In the first period, After obtaining the first token, obtaining the second token; 3. The electronic payment program according to claim 1 or 2.

7. A payment device capable of communicating with a terminal, a reception unit that receives a token request from the terminal to request issuance of a token; a supply unit that supplies two types of tokens, a first token and a second token associated with a user of the terminal, to the terminal when the reception unit receives the token request; Equipped with The first token is When the payment device is capable of communicating with the terminal, an online token used in the payment device to determine whether or not to execute a payment process corresponding to the user; The second token is When the payment device cannot communicate with the terminal, an offline token used in the payment device to determine whether or not to execute a payment process corresponding to the user; The supply unit includes: When the reception unit receives the token request from the terminal, providing the first token to the terminal, and then providing the second token to the terminal; A payment device comprising:

8. An electronic payment system comprising: a terminal having an electronic payment program installed thereon; and a payment device, The terminal includes: a request unit that requests two types of tokens, a first token and a second token, from the payment device during a first period from when the electronic payment program is started until a first time has elapsed; an acquisition unit that acquires a token provided from the payment device in response to a request from the request unit; a display control unit that causes a display device to display a code image based on the token; Equipped with The acquisition unit is When the second token is acquired, the second token is stored in a storage device; The display control unit is When the acquisition unit acquires the first token during the first period, displaying a code image based on the first token on a display device; In a case where the acquisition unit has acquired the second token in a period prior to the first period and stored the acquired second token in the storage device, If the acquisition unit does not acquire the token during the first period, displaying on the display device a code image based on the second token stored in the storage device; The request unit is In the first period, after issuing a first token request to request the first token, issuing a second token request requesting the second token; An electronic payment system comprising:

9. An electronic payment system comprising: a terminal having an electronic payment program installed thereon; and a payment device, The terminal includes: a request unit that requests two types of tokens, a first token and a second token, from the payment device during a first period from when the electronic payment program is started until a first time has elapsed; an acquisition unit that acquires a token provided from the payment device in response to a request from the request unit; a display control unit that causes a display device to display a code image based on the token; Equipped with The acquisition unit is When the second token is acquired, the second token is stored in a storage device; The display control unit is When the acquisition unit acquires the first token during the first period, displaying a code image based on the first token on a display device; In a case where the acquisition unit has acquired the second token in a period prior to the first period and stored the acquired second token in the storage device, In the first period, if the communication state of the terminal is offline, displaying on the display device a code image based on the second token stored in the storage device; The request unit is In the first period, after issuing a first token request to request the first token, issuing a second token request requesting the second token; An electronic payment system comprising:

Images